3 ms·
Early developers used to put NOPs into code, so they would have a place to insert hex patches later on. At a minimum they could plug in a branch instruction, bo
by cosmicray 16y ago
Early developers used to put NOPs into code, so they would have a place to insert hex patches later on. At a minimum they could plug in a branch instruction, bounce down to the end of the code segment, put a longer sequence of code there, then branch back. Old school stuff.
- 1amzave 16y agoModern compilers may actually do this as well, though for slightly different reasons -- GCC (at the right optimization level) likes to put branch targets and functions at aligned addresses, so you often end up with little pads of NOP instructions scattered throughout your binaries (run 'objdump -d' on something built with 'gcc -O2' to see firsthand, if you're interested). I actually have a mostly-written LD_PRELOAD library lying around that exploits this for purposes more like the ones you describe though -- hot-patching code in memory at program load to dispatch system calls via little dynamically-generated trampolines so you can insert calls to arbitrary tracing functions. Perhaps I'll polish it up a bit and toss it on github...
- calloc 16y agoSomething along these lines: http://timetobleed.com/rewrite-your-ruby-vm-at-runtime-to-hot-patch-useful-features/ http://timetobleed.com/rewrite-your-ruby-vm-at-runtime-to-ho...
- DCoder 16y agoNowadays MSVC supports the /hotpatch command line option, which inserts fillers like "mov edx, edx" or "lea edi, [edi]" at the start of each function for the same purpose.
- abhijitr 16y agoSee also: Detours library by MSFT research(http://research.microsoft.com/en-us/projects/detours/ http://research.microsoft.com/en-us/projects/detours/). It doesn't require you to recompile your binaries to add NOPs.
- rlpb 16y agoOut of interest, why does this need a NOP? Why not replace an existing instruction with a branch, bounce down to the end of the code segment, put a longer sequence of code there, put the instruction that you replaced there, and then jump back? Is it that the patch could be conditional and not incur as much of a performance penalty if the condition isn't met and the patch doesn't run? Would this have made a significant difference to performance?
- kenjackson 16y agoDepending on the instruction, it might not be long enough for a branch. Then you'll have to replace two instructions, and if the program is executing (doing a live/hot patch) then you may have to be extra careful that code hasn't executed the first, but not yet the second instruction.