1

I'm trying to inject code to change the byte value of a CMP in an executable from 0 to 2 at runtime, in order to effectively no-op a boolean comparison as part of an effort to insert my own behavior. I have the offset of that single 0x00 byte in the file, as well as what I had thought was its virtual address - the file offset + the image base + the virtual address of the .text section.

However, I was surprised by the fact that when I looked at this virtual address at runtime, I was in a completely different place in the code, in the middle of a bunch of 0xCC bytes.

Looking at it more, I found out that in general my presumed virtual addresses are inconsistent. For example, here's a few opcodes at virtual address 0x00ebf5e0 (offset + imagebase + .text virtualaddr) as displayed by Ghidra:

55                push ebp
8B EC             mov  ebp, esp
83 EC 1C          sub  esp, 0x1c
A1 90 74 43 01    mov  eax, dword ptr [0x1437490]
33 C5             xor  eax, ebp
89 45 FC          mov  dword ptr [ebp - 4], eax

And here is a few opcodes dumped in memory, by directly reading from the same address ((unsigned int8_t*)0x00ebf5e0):

8B 01             mov  eax, dword ptr [ecx]
89 45 F8          mov  dword ptr [ebp - 8], eax
89 5D E4          mov  dword ptr [ebp - 0x1c], ebx
83 FB 10          cmp  ebx, 0x10
72 04             jb   0x11
8B 3E             mov  edi, dword ptr [esi]
EB 02             jmp  0x13
8B FE             mov  edi, esi

I've tried pretty much anything I could - directly addressing, obtaining the image base pointer through psapi.h GetModuleInformation (which unsurprisingly turned out to be equal to 0x400000), including and not including the 0x1000 (.text vaddr), etc. The only interesting result this has brought is that at the very start of the image base, the bytes and opcodes do in fact check out - which has me thinking that this issue has something to do with alignment.

Note: As per dumpbin, the executable has relocations stripped. It is also 32 bit.

Improve this question
4
  • Have you tried to directly search for the bytes that you expect to find at 0x00ebf5e0 in memory?
    – macro_controller
    Commented Jan 28, 2020 at 13:30
  • @macr0controller I was suggested this. I would really prefer not to have to scan it like that since the executable is pretty big. If I have to do signatures I'll do them, but even out of sheer curiosity I still would love to know what's going on here. (to answer your question directly, no, I did not)
    – Zatherz
    Commented Jan 28, 2020 at 13:50
  • I suggest it because if you find it, it could share some light on your issue, which eventually could lead to the root cause.
    – macro_controller
    Commented Jan 28, 2020 at 16:03
  • @macr0controller I tried it - I can't even find the exact same opcode in the executable in memory. I have no idea what's going on in here; the addresses are apparently relocated for some reason but the CMP should be unchanged, right? This whole thing has me so confused. I even dumped the entire image from memory and analyzed it in Ghidra and nothing makes sense. Also, would you happen to know any other place where I could ask other knowledgeable people about this?
    – Zatherz
    Commented Jan 28, 2020 at 17:19

1 Answer 1

Reset to default
1

I started from scratch, used OllyDbg to find the opcodes as they are in memory and then wrote my heuristics for finding certain opcodes of interest also operate on the image in memory. There were some weird differences such as a certain MOV operating on EBP as opposed to ESI on disk (which I now think is related to thread-local storage, since apparently the Windows linker does rewrite things?), but I managed to get it work.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.