Well I was bored tonight and as I've been reversing around I've realized that yeah, they used UPX but they used a custom loader ( read into UPX's documentation to learn what those are ) and they corrupted the UPX pack header and changed the names of the sections to fool any would-be crackers.

Basically what I decided was that reading the UPX pack header and trying to repair it then renaming the sections so UPX would unpack it is a big hassle. I may do it in the future, however, to yeild a perfect unpack, but for the needs and the sake of a bypass to gameguard, there's really no need at all. Another idea ( which is a simple idea to a generic UPX unpacker ) is to make a simple program which will do the following ( this is my idea, and is what I will most likely do for myself to make a simple UPX unpacker that will unpack even corrupted UPX packed files ). Simply put, this is the same exact algorithm anyone would use by-hand to unpack a UPX packed file.

1. Because UPX decompresses the data into the first section before executing the OEP, you must wait for the decompressing loader to finish it's job before you can proceed to dump any useable code from this section.

2. You must reset the OEP once dumping the filled section with unpacked data.

3. Because UPX decompresses all sections into the same final section ( the win32 subsystem doesn't give a shit about sections, it just follows the code and as long as the code references these sections correctly who's the wiser ) you must then distinguish them ( imports/exports, data, rdata, etc.. with exception to relocs [ if file base address is less than 400000 ] and rsrc ) and add fields in the files PE to account for them.

4. You must repair the relocs / imports / etc so the executable runs correctly after the unpacking. This step can be omitted if the file will not be executed but simply studied.

5. You must remove both the loader stub and the packed data stub and remove their information from the PE header to complete the unpacking.

The result is a 100% unpacked file. This is exactly what UPX does ( read the source ) and because it's well-documented, unpacking it perfectly using code would require minimal effort ( since the code is provided.. a modified unpack function would suffice for this task ).

The concept I have is to simply load the executable in question into memory. The addresses in the loader stub will then be reset to point to the correct sections in memory ( the data section, the pack header, the destination or code / UPX0 section ) and then executed until it jmps into the new code section following a popad ( this is the OEP ), on which case the PE and subsequent sections will be rebuilt, the UPX loader and packed data sections will be removed and the OEP modified to suit the new load address, and the resulting file will be saved to u<filename>.<fileext> on the harddrive. This will yeild a 100% perfectly unpacked file on even protected/hacked/modified UPX files such as the gameguard ones.

I am impatient to say the least and because of this I have opted to unpack the file(s) and THEN make an application to create perfect unpacks. Because I choose this method, the unpacked files may be unstable and may not run correctly but contain all viable code intact ( which makes them perfect candidates for study ). When I get around to making this unpacking app, it will be posted here, source and all. For the time being let me tell you exactly how I unpacked these files ( note this method only works for executable files.. a modified approach must be taken to dump .dll files ):

First you need these programs:OllyDbg, OllyDmp ( a plugin for OllyDbg, google it ), and ImpREC

Once you have these you can unpack virtually any file ( lol ).

Starting off, we'll unpack gameguard.des ( this is the only file I'll walk you through ). Firstly copy gameguard.des to the folder you're using as your unpacking folder as to not interfere with the original file. Rename gameguard.des to gameguard.exe. Now open OllyDbg and drag gameguard.exe into it. The exe will load and halt at the EP, giving you a pre-emptive edge. You want to get the UPX loader stub ( that's the code I reversed above ) to fill the .text section of the gameguard file. To do so ( from code to imports.. and UPX does it in that order, imports last before jumping into the original code, the calls you see are to kernel functions such as GetProcAddress which will fill the IAT etc ), you need to get OllyDbg to breakpoint before it takes the final jmp. Scroll down until you see a 'popad' followed by a 'jmp gameguar.<some number>'. You need to put a HARDWARE BREAKPOINT here on execution ( right click on the jmp and go down to breakpoint ). Now that the breakpoint is set, we need to run the program, so click the blue right-facing triangle in the toolbar. Oops . The program generated an exception.. wtf.. not good. Hold shift and press F7, F8, and then F9. You'll see in red letters at the bottom right that the application terminated ( before the loading process even finished ). I want to give you a little lesson in why reversing protected loaders like this is essential to QUICKLY identifying and fixing a problem.

Normally if you were to just load up this exe and try this method ( which is the de-facto cracking method to breaking simple packers like UPX ) it would work great. If this packer was reinforced with protection like this, you would get a termination here. What you'd have to do then is find out WHY, and you'd trace the code piece by piece to find out why it faulted. I'll go ahead and tell you why it faulted. If you read up in the reversed code, near the top there's what I said was debugger detection code. I showed that there was a 'popad' statement that was ONLY CALLED IF A DEBUGGER WAS FOUND. Well guess what boys & girls, we're running a debugger. A debugger WAS found, and thus that popad was taken. This reset all of the registers ( thus ESI didn't point to the data anymore ) and when the mov statement was reached an exception was encountered. This was handled by simply terminating the process ( the default exception handling provided by the win32 subsystem loader ). This is a very VERY simple debugger protection system designed to stop NOOBS ( like most of you ) from getting a peek at the real code by preventing 1 byte from being unpacked if a debugger is loaded.

Now that you know this, repeat the steps up to the clicking the right-facing blue arrow again ( you do not need to repeat the setting of the hardware breakpoint.. it will stay in the debug registers stored in the system's context ). This time, instead of hitting the blue arrow, scroll up to the code that I show is debugger detection code in the semi-reversal. We're going to NOP out the culprit ( a common hack method of bypassing protection.. quick, dirty, and 100% effective .. just like we like it ). See that 'test eax,eax' statement? Double-click the jnz statement after it and make sure the checkbox next to "Fill with NOPs" is checked and type "NOP" in the drop box and hit Assemble. This will place 2 NOP operations in the jnz's place. Now hit the blue right-facing arrow and viola, the application pauses at our breakpoint. Congratz on your first protection crack boys & girls.

What you'll want to do ( I assume you installed OllyDmp before doing this.. ) is to hit 'F7' which will take the jump and poof we're at the OEP. Go to plugins->OllyDmp and click dump debugged process. Click 'Get EIP as OEP' and hit 'Dump'. Save the file as 'ugameguard.exe' and close OllyDbg. Run it through ImpREC and you're finished.

There you go, dumped gameguard.des file. Have fun people. The next section will be started soon, cracking the checksums to use modified files & then the actual patching GameGuard to run without the protection. If anyone has any comments or questions go ahead and ask. The perfect unpacker will be posted here when I get around do making it =).