News for hackers. Stuff that matters.

A comment on Hotpatching a C Function on x86. Parent comment

Re:Hotpatching a C Function on x86 by csl on Friday April 01, 2016 @11:10AM (#11405334)
But that would only be possible from the same process space, right? So only applicable for plugins etc.?

What I'd like to see is hotpatching the function for another process, but I guess that's very hard to do with ASLR. Probably doable with some tricks, though.

Edit: Come to think of it, gdb is able to attach to a running process w/o debug symbols and find function addresses. So in other words, I just need to dig into and grok the gdb source.

[ Parent | on HN ]
Re:Hotpatching a C Function on x86 by dreamlayers on Friday April 01, 2016 @11:37AM (#11405589)
The program being modified doesn't need some feature for loading your code as a plugin. You can instead use https://en.wikipedia.org/wiki/DLL_injection
[ Parent | on HN ]
Re:Hotpatching a C Function on x86 by chatmasta on Friday April 01, 2016 @11:15AM (#11405378)
If you are able to recompile the program, you can disable ASLR. For example on iOS it just requires a change to the MACH-O header of the binary. [0]

But I doubt you could disable ASLR of a running process, for somewhat obvious reasons...

[0] https://github.com/peterfillmore/removePIE

[ Parent | on HN ]
Re:Hotpatching a C Function on x86 by dreamlayers on Friday April 01, 2016 @11:46AM (#11405674)
You can similarly disable ASLR via the header in Windows, though there are ways to override that.

ASLR shouldn't be a big problem though. Only the base address of code in each file (executable or library) is changed, and you can easily find it. Functions within one file are not shuffled around. ASLR only exists to stop you from hard-coding function addresses, to make exploits harder.

[ Parent | on HN ]