1

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:

enter image description here

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)

enter image description here

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?

Thank you!

0

0

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Browse other questions tagged or ask your own question.