Depending on the mode of operation (i386 or x86-64) this can be impossible.
i386 mode uses different segment selectors for code and data and code segments can be only executed and/or read (not write!). Unless the data descriptor is mapped to the sabe linear address space that of the codeseg, you can't write in codeseg.
In x86-64 there's no segmentation, but the page write code is in can be marked as read-only.
See Intel SDM volume 3 about protection and memory management.
This code is valid on i386/x86-64 modes (because only READs the msg bytes, don't write on this region):
; i386 mode Win32 hello using only a text segment.
;
; nasm -fwin32 -o test.o test.asm
; ld -s -o test.exe test.o -lkernel32
;
bits 32
section .text
extern __imp__GetStdHandle@4
extern __imp__WriteConsoleA@20
extern __imp__ExitProcess@4
global _start
_start:
; Get STDOUT handle.
push -11
call [__imp__GetStdHandle@4]
push 0
push 0
push msg_len
push msg
push eax
call [__imp__WriteConsoleA@20]
push 0
jmp [__imp__ExitProcess@4]
; Notice: this is in .text section!
; Can read, but can't write!
msg:
db `Hello\r\n`
msg_len equ $ - msg
Try to add mov byte [msg + 5],0 before calling WriteConsoleA and you'll get an 'segmentation fault'.
I'm using 64bit Windows but am writing a 32bit program. When I look at the EXE output from NASM in a hex editor, the Characteristics field in the section header for the .text section, I see the bytes 0x20, 0x00, 0x00, 0x60. The first byte is the one that tells the OS what type of content is in it. 0x20 is code. 0x40 would be data. 0x60 would be both code and data. The last byte says 0x60, and this is the protection byte. The value 0x60 here means that reading and executing are permitted. 0x20 would mean executing code is permitted, 0x40 would mean reading is permitted, and 0x80 would mean writing is permitted. The actual permissions granted is a combination of one or more of these flags. In the case of the .text section output by NASM and GoLink, the value here is 0x60, meaning read and execute permissions are granted, but writing permission is not granted. In OllyDbg, such a section has its permissions shown as "R E". If it also had writing permission, it would show as "RWE". The resulting flag value for such an RWE section would be 0xE0 (the sum of 0x20 + 0x40 + 0x80). And yes, I've tested it by using a hex editor and manually setting the write permission in this way. And it works fine.
I just don't want to have to hexedit my EXE after every single compilation, in order to get my code to work. It would be nice, if NASM provided a way to set these permission flags for each section. Those permission flags would then get stored in the MS style COFF file that's output from the WIN32 format from NASM, and then the linker would be forced to give those permissions to that section when it generated the EXE file. I'm surprised that NASM doesn't have this feature yet. Anybody wanting to make self modifying code will NEED this feature.
Things like EXE compressors (as well as EXE obfuscators to try to stop reverse engineering) do this all the time. When such a tool is run on an EXE, it compresses the code section and puts it in a new section, and replaces the original code section with decompression or decryption code, as well as creating a third section that is uninitialized (the section header says where it should be allocated, but the EXE file itself contains no data or code to fill it). When you run the EXE, it runs the decryption or decompression code, and puts the output of this operation into the third section, and then jumps to that new section. Guess what type of permissions that third section has. Yep, it has both write and execute permissions. So that way the decompressed/decrypted code can be written into the third section and executed.
I'm just wondering if NASM has a feature to assign such access permissions to sections, even if it's not a documented feature. If not a feature now, it should certainly be added as soon as the devs have the time to do so.
Recent Posts