So here's how it all began. My wife plays a lot of PC based puzzle games. Some people work crossword puzzles, some others crack software, she plays puzzle games. So, back in 2005 she found a game that she liked called Mystery case files huntsville. She downloaded it, and asked me to extend her trial time. So, I went looking for a crack. (Why reinvent the wheel if it's already been done?) And I found one. So, I tried it, and it didn't work. Well, that pissed me off, and I decided to have a look at it. I ran it through IDA (my disassembler of choice), and began looking at the code. It was pretty straightforward, they loaded the game into memory without executing it, read a chunk out, decrypted it, wrote it back, and the executed the game. I then looked a little further, and found where they checked to see if you had purchased the game. I kid you not, the function was called "HasProductBeenPurchased", and returned TRUE or FALSE. Basically YES or NO. This was in a .DLL, so I made the simple change to make it always return TRUE (yes). Ran the game, nothing. Exited. I dug through their loader a little more, and found that they were doing an MD5 over the DLL to keep people like me from doing what I was trying to do. The only problem is, the loader itself didn't have any such protection, so I just made it jump like it had received a TRUE retun value, and she was playing along happily, but I was now intrigued! SURELY this was just a single instance of bad protection! I went back to their site, and saw that they had about 100 games available for download. I grabbed a couple, installed them, and looked at the loaders. The loaders were almost all the same! It turns out that this weak protection was on ALMOST ALL of their games. The only exceptions were what was probably the FIRST games they released, and they didn't have the loader system perfected yet, so they just had the game authors call "HasProductBeenPurchased" from inside the game's executable, and then they packed it with a packer called ASProtect. I decided that I was going to write a tool to let my wife register her own games when she wanted to. So, I wrote a loader that allowed me to get around the ASProtect games, and a patcher that allowed me to patch the OTHER games, and a stripper that removed their protection completely.
Seems like this would be a good time to explain the process that they use. When an author gives them a game to distribute, they take the executable and run their packager on it. It reads a chunk of the games executable code out, encrypts it, writes it back, and then renames the executable from .exe to .rwg. (I bet it's the authors initials!). They then throw a loader on that does stuff like allow you to purchase the game, it monitors how long you've played, and doesn't allow you to play after your "trial time" has expired. (It will kill the game, and return you to it when your time is up!). They then pack the whole thing up with an installer, and put it on their website. This protection method means that when you press the "play game" button in their loader, that they have to decrypt that chunk of data in memory, and then launch the game from there. What my loader did was, search for, and replace some strategic bytes in their loader with "$CC" bytes (INT 3) bytes which transferred control back to MY program, and I would read the decrypted data out, and make a patch for the game. It was very "old school" if you will, what with all the searching for bytes, and whatnot. They accomplished this reading and writing of memory via a couple of windows functions called ReadProcessMemory, and WriteProcessMemory. They do just what you would think they would. They allow one process to read/write in another processes memory space.
Well, I decided to update my tool, and bring it to the jet age. I used a technique called "IAT Hooking". What this is, is when their loader loads, they load the windows DLLs that house the Read/Write ProcessMemory functions. When they do this, I intercept them, and instead of them getting the addresses of the windows functions, they get the addresses of my "replacement functions". In these functions, I do things like copy the encrypted executable to a new name, find the location where the encrypted code is in that file, and write the unencrypted code out to that location when they get through unencrypting it. And, the best part, It works on every game they have released since 2005! I bet that's close to, if not over 1000 games!
I was very happy with this tool, and figured that I had exploited them as much as I possibly could. I was wrong. Recently I noticed that their site had added a Macintosh section. And, with Macs being Intel based these days, I figured I'd have a look at their loader on that platform, and see if they were doing the same thing. They are, sorta. Only with 50% more braindead free!
The packaging step is the same, read a chunk of the executable out, encrypt it, and write it back. But the loading/running of the game is different, and COMPLETELY STUPID. Instead of loading the game into memory, and making those changes I mentioned above, they actually make a copy of the encrypted executable, read the encrypted data from it, decrypt it, write it back, and then execute it. So, when the game is running, there is a completely UNPROTECTED copy of the executable on your HDD just WAITING for you to make a copy! They rename it slightly, by adding a "." to the front, but very little good THAT does! So, I'm going to write a tool that will find, and copy the unprotected executable to a safe location, and then when the game exits, I'll delete the encrypted version, AND the loader, and put the good version of the game in it's place. Reducing the size of the bundle on your HDD, and letting you play the game forever.
(shaking head)
Idiots.
