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 (
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
.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.