I have googled, watched several videos, read the PE spec, and even read some blogs. I am at a loss on how to patch out a message box. I am working through a CTF whose first task is to disable a nag screen. I'd like to completely remove the call to MessageBoxW for completeness sake and because the amount of struggling I'm doing now has told me there is some value in learning to do this.
The code is here:
004015fc 6a 30 PUSH 0x30 004015fe 68 88 45 PUSH u_NAG!_00404588 = u"NAG!" 40 00 00401603 68 88 45 PUSH u_NAG!_00404588 = u"NAG!" 40 00 00401608 6a 00 PUSH 0x0 0040160a ff 15 6c CALL dword ptr [->USER32.DLL::MessageBoxW] = 00004dd4 30 40 00
Naturally, simply patching the call with nops does not work. If I patch from the first push through the call with NOPs the executable will start and die once it hits this point, as expected. The dynamic disassembly:
0011160A | 90 | nop | 0011160B | 90 | nop | 0011160C | 6C | insb | 0011160D | 3011 | xor byte ptr ds:[ecx],dl | 0011160F | 008B 0D643011 | add byte ptr ds:[ebx+1130640D],cl |
So something is being relocated and I cannot find it. In fact from above the patching by the loader is obvious. Some of the messed up bytes are the relocated address
0x0011306C. Though, I'm not sure where the bytes after are coming from...I'm guessing there's now misalignment?
Going back to the original call the base address is
0x00400000, which means the address where the function is mapped in memory is at offset
306C. Going to that offset in Ghidra I see:
0040306c d4 4d 00 00 addr USER32.DLL::MessageBoxW
Which makes sense. Firing it up in PE-Bear I checked the import address table:
and indeed 306C is the offset into the IAT. But when I look at the relocation table I don't see any address that looks like
160a (the address to the call) where I would expect a patch to be:
(Truncated because the table is huge)
So I am at a loss at how to completely bypass this thing. Could anyone point me to some resources or give me an idea of what I'm doing wrong so I can understand this process a little better?