Runtime patching of MPRESS packed executable disables license checks (Gearotic Motion)

Using software, like taxes, is inevitable. Paying for software, unlike taxes, is optional.
Sometimes changing one bit out of millions can make all the difference.

That is what we will do today.

Target: Gearotic Motion 2 Development version

Tools:

• IDA Pro 5.5
• Visual Studio
• Loader/Patcher by Grant Curell

Background:

GM2 is an executable packed by MPRESS. I was unable to dump it using standard means, the resource table was intact but the program was pulling invalid default settings for text box entries. Instead of dumping the executable correctly, I chose to make a loader application that patched the application after it finished unpacking itself.

The loader application serves the purpose of spawning our target, suspending execution at a certain point, and injecting a patcher dll. It may be possible using readprocessmemory/writeprocessmemory, but the loader includes code for the patcher dll.

I modified the loader/patcher code to run correctly and to accept parameters via the command line. Code can be provided upon request.

The Beginning:

Start IDA and disassemble Gearotic.exe

Notice these warning messages that indicate our exe is packed:

After disassembly finishes, you will see this:

Navigate down this function until you notice a jump to an unlikely location. Set a breakpoint here (F2). It will be marked red.

Now you can run the application (F9) under the local W32 debugger built into IDA.
Execution should break on that instruction,

00D2CF99 jmp     near ptr dword_7D5C00

Choose to step into (F7) and IDA will inform you about its confusion

Select yes, because we will now be executing unpacked instructions. After a bit of autoanalysis, you will search for popa, an instruction that can signal the end of an unpacking routine. Do this by searching for text (Alt + T) and entering values as shown:

make sure your cursor is at EIP for the search to work

Set a breakpoint (F2) on the popa instruction and execute (F9).

Now step into twice (F7) (F7) and you will find yourself at:

.MPRESS1:007644A1 call    sub_7737ED                      ; CODE XREF: .MPRESS1:007D5D23j
.MPRESS1:007644A6 jmp     loc_764324

The addresses may be different, but this is the original entry point (OEP) of the application. At this point, the application is unpacked and we can begin our hunt.

The Hunt:

We know from research that a potential license filename is license.dat. With a little experimentation (and perhaps Sysinternals’ procmon monitoring file accesses) it was found that searching for a case sensitive sequence of bytes (Alt + B) points us in the right direction.

You may then convert the one result into a unicode string (Alt + A, U) and navigate to its XREF. It will take you to a function that attempts to load and process a license file. We will make two patches to this function. The two patches will be shown hilighted below. There are many different ways of approaching this but I will be converting these [JZ] instructions into [JNZ] or [JMP] instructions since we want to fake a zero flag condition.

The addresses in question can be found in IDA’s hex view. Keep in mind these two instructions have different lengths even though they share the same mnemonic. A good resource reference for this are the IA-32 instruction set developer’s manuals.

Your task is to look up the instruction format of what you have (0F 84 xx xx xx xx) and (74 23) and determine what to patch them with to gain correct software operation. I chose to set a hardware breakpoint at the OEP, patch, and remove the breakpoint.

P.S. If you do get a good dump of the program, you should generate an RSA keypair and replace the key in resource blob “BIN”. Then sign your license file with the other key. That’s the ‘proper’ way to go about this. I’m not proper. ü