[Graphitemaster] is helping to demystifying the process of tailoring functions for dynamic loading. His tutorial shows how make a dynamic function that prints “Hello World” to the standard output. This is of course rudimentary, but if you have no prior experience with the topic you might be surprised at what actually goes into it.
Normally your compiled code has addresses in it that tell the processor where to go next. The point of dynamic loading is that the code can be put anywhere, and so static addresses simply will not work. The code above shows how a simple printf statement normally compiles. The callq line is a system call that needs to be replaced with something that will play nicely in the registers. [Graphitemaster] takes it slow in showing how to do this. Of course a dynamic function alone isn’t going to be much good. So the tutorial finishes by illustrating how to program a dynamic code loader.
Am I the only one who read that as “dynamite”?
https://github.com/andrewchambers/ShellCodeLinker
i made a tool that does this automatically under mingw by moving the code and data together and resolving the relocatiosn at runtime.
I’d like to point a few things here (I’m the author of that blog post). The way hack a day describes it is to say the least incorrect. The callq instruction doesn’t invoke a system call directly. Instead it’s setup to call a function that at that point doesn’t exist. Instead it’s patched in by a dynamic loader (for printf) also known as lazy-loading. Some other subtle things not really communicated well; the addresses the description of this post states it tells the processor where to go next. This is false, it tells the processor where to load memory from. The issue is this memory doesn’t exist. In order to stay PI (Position Independent) you need to ensure your code is PIC (so there are no load/stores that use absolute addresses). Modern dynamic linkers use relocation tables to relocate data and patch these things so that data does exist at runtime. If you have anymore questions regarding this, please feel free to submit a comment here or on the Bit Hacking blog. I’m going to write a better tutorial on how to implement an actual linker someday which works nicer and can be used for embedded projects. Thanks guys!
I don’t know many people who understand assembly code concepts like compiling, linking, relocating, position independence, relative calls, etc thoroughly enough to actually write about them clearly. As a technical writer I understand the process and often get the result wrong, especially when I have a deadline. At least I have peer reviews before my material is published, I guess HAD doesn’t have that – it’s written, and it’s out. You can tell by the plethora or spelling and grammatical mistakes which would get caught otherwise (that wasn’t a criticism btw, that’s just the process).
As for your blog post, I find it very interesting, thanks for writing it. Takes me back to my 68K assembler days.
*plethora of…
You see? :)
Nice primer, but reading this just enforced my views on how superior the 68K is compared to x86 when it comes to write relocatable/re-entering code.
Right. That’s why when the 68K lost it’s prominence and Intel and it’s segmented addressing took over, I dumped ASM and went 100% C.
BTW – I accidentally ‘reported’ your comment. It’s early in the morning, eyes are tired, and I saw ‘Rep…’ thinking it was ‘Reply’, and clicked it – there wasn’t a confirmation step :/ (@HAD can you fix that, will probably lower your workload over time ;-))