4 ms·
Well yes, as said here, it's more of a linker thing and not so much a language or assembly thing. On Windows you could do the below to have a single, executable
by BruceEel 3y ago
Well yes, as said here, it's more of a linker thing and not so much a language or assembly thing. On Windows you could do the below to have a single, executable, readable and writable section. Not sure whether it still works anno 2023.
It's generally considered a bad idea from a security standpoint
#pragma comment(linker,"/MERGE:.data=.text /MERGE:.rdata=.text /MERGE:.flat=.text /SECTION:.text,EWR ")
- taway1237 3y agoThe article is about call+pop "trick" in assembly, linker is not relevant here.
- _nalply 3y agoRight, but that trick is not so useful if you have a different section than .text only, and that's what GP is referring to.
- taway1237 3y agoI disagree. For me it's useful mostly for position independent shellcode prologue, which has no sections to speak of, and may get embedded in a "normal" executable or something that is not an executable at all (useful in a bootloader, or for injecting code to another process, or self-relocating code, etc). I use this "trick" all the time and I never felt the need to mess with a linker for this. But it's a good hint, I hope I didn't sound overly negative.
- _nalply 3y agoYour point is interesting. I didn't think about this use case. Inject code with ptrace. Like the LD_PRELOAD trick but you don't even need LD_PRELOAD, just attach and bamboozle the running process into running some code you provided. In such cases sections don't exist, but pages. Right.
- Dwedit 3y agoIt happens to be a lot easier to reverse-engineer a program where the sections are not combined, and you can predict that strings will reliably be in the .rdata section. While it does save a few KB, it just makes things so much nicer for the next people who need to patch features into the binary manually.