2

I want to modify next instruction before it fetches, in best answer of This post in foo function, *p points to the next instruction in main function. I want to modify content of where *p points at. For example I want to change the next instruction to a jump instruction. How to I can do this?

void foo()
{
    void** p = search((void**)&p, __builtin_return_address(0));
    // modify content of where *p points at.
}

int main()
{
    
    foo();
    //next instruction. *p points here
    return 0;
}

I want to do this with gcc compiler, on intel Core-i7 3632QM processor.

Peter Cordes
  • 328,167
  • 45
  • 605
  • 847
Javad Yousefi
  • 2,250
  • 4
  • 35
  • 52

2 Answers2

5

For example I want to change the next instruction to a jump instruction. How to I can do this?

On a desktop system with a modern OS, you cannot, unless the program being executed has taken care to have the code held in read-write memory pages. By default, code is loaded in read-only memory pages.

Pascal Cuoq
  • 79,187
  • 7
  • 161
  • 281
  • 1
    I'd be surprised if even making it read-write would work. The Intel core has an XD/XN bit in the MMU, which is used for security purposes to prevent viruses from running data. This effectively segregates code from data in the MMU, preventing executable regions from being updated. If there's any kind of O/S running doing this will throw an exception (and most likely get your code sent to whoever made your virsus scanner). – Evil Dog Pie Dec 15 '14 at 13:50
  • 3
    @MikeofSST I have never experimented with it, but I believe that following the steps in http://stackoverflow.com/a/4169440/139746 would be enough to allow code to be modified. – Pascal Cuoq Dec 15 '14 at 13:55
  • Awesome link - that's like a recipe for a Trojan! :-) I'd want to flush my i-cache before making a call into modified code too, just in case. – Evil Dog Pie Dec 15 '14 at 14:05
  • 1
    This question about the [i-cache](http://stackoverflow.com/q/10989403/3581917) is also interesting. – Evil Dog Pie Dec 15 '14 at 14:10
  • @MikeofSST Regarding the Trojan: in most cases the system protects itself (from new code, anyway—see “return-oriented programming”): if the attacker could execute `mprotect`, they could then more easily execute code of their choice, but they can't execute `mprotect`. Regarding the instruction case, there was a period during which the instructions to ensure that the new code was loaded changed with each generation of processor, but by now it must have stabilized, I guess. – Pascal Cuoq Dec 15 '14 at 14:57
  • That's the beauty of a Trojan - you disguise the executable containing the mprotect as a lolcatz MPEG. The user opens this and says YES to the little pop-up asking if they're sure they want to run it - of course they are, it's a funny cat video, isn't it? Once running this provides a backdoor to download the malicious content and uses mprotect enable whatever good stuff you want to send to it. – Evil Dog Pie Dec 15 '14 at 15:09
3

Just an idea. As it was already mentioned in comments write and execute [usually] can't be set on the same memory range. But any POSIX system should have interface to dynamic linker (dlopen(), dlclose(), ...). So there is a way to modify process memory layout at runtime, which is used by dynamic linker.

If modifying dynamic linker or using the same interfaces as it is using is acceptable option, it may be possible to dump memory segment (or copy it into another range), modify, free original segment and load modified one into the same range.

kestasx
  • 1,091
  • 8
  • 15
  • Many OSes do allow having a page with both write and exec permission simultaneously. They just don't map many (or these days any) pages that way by default in a normal executable. You can `mprotect` to set them. However, on some OSes like OpenBSD, there is a strict W^X policy and an `mprotect(PROT_WRITE|PROT_EXEC)` would return an error. – Peter Cordes Dec 05 '21 at 21:36