0

Having an assemblty program like this works fine for me which I dont know why

section .data
    name: db "abcdef"
section .text
global _start
_start:
    std
    mov rsi, name+5
    mov rdi, name+1050   ; should be pointing to non mapped memory
    mov rcx, 6
    rep movsb
; calling sys_exit

isn't this is supposed to write to a part of memory that is still not mapped since no brk or sbrk calls have been made yet to increase program break (ie; program break = .data end) ,with no .bss section in the program and we are writing in an area far beyond 6 bytes that are supposed to be allocated to .data.

trincot
  • 317,000
  • 35
  • 244
  • 286
KMG
  • 1,433
  • 1
  • 8
  • 19
  • 2
    Protection works by page granularity, normally 4096 bytes. Use a bigger offset. Even then, you might accidentally have another writable section mapped after `.data` (usually `.bss`) although in your simple example you don't seem to have that. – Jester Oct 02 '20 at 11:34
  • @Jester so does this means that ```.text``` is in a separate page right ? – KMG Oct 02 '20 at 11:39
  • 2
    Stop your process at a breakpoint inside GDB and look at `/proc//maps` (and `.../smaps`) for it. Yes, `.text` will be in a read-only + exec page, not read-write. (Although note that executables built from asm often end up with executable `.data` thanks to surprising defaults in the toolchain: [Why data and stack segments are executable?](https://stackoverflow.com/q/7863200) / [Unexpected exec permission from mmap when assembly files included in the project](https://stackoverflow.com/q/58260465). But `.text` will still be read-only and executable) – Peter Cordes Oct 02 '20 at 11:43

0 Answers0