TOPICS:

FIXING ActiveMark Shockwave (Flash) games with "overlay" data..&
Target: Yahoo! Games, Ancient Tripeaks
Author: Lunar_Dust - Feb 10, 2006..with greets out to CondZero's AM tutorials.

Introduction
Welcome. So you want to do some Activemark reversing and unpacking? Well, first let me say that you should check out CondZero's Basic and Advanced ActiveMark tutorials first and learn how to get to this point. Find them on ARTEAM's site.

This tutorial assumes you are familiar with the normal unpacking techniques as shown in the referenced tutorials and have your file dumped from memory at 2nd layer OEP sucessfully.

So, firstly, acquire the forementioned target as stated in the introduction block, and perform the usual unpack and dump procedures on it. Note that this particular game uses Macromedia Shockwave Flash, as well as an "overlay" - basically the encrypted Activemark data file is attached to the EXE instead of being seperate. We will see how to deal with this. Also, you should be to the point where the IAT is also fixed and already attached to the dump.

This game is ActiveMark 2.7.xx, a very old version.

Ok, with that out of the way, let us continue forward.
Fixing the "overlay" data...

Great job! You've got a dumped file. You did dump at 2nd layer OEP right? Good. Ok but now you have tried to run the game, and it either crashes, or it just won't run at all. Maybe you can even get to the browser screen, but when you press Play! the game crashes. This is because you are missing an important thing: Activemark allows a game developer to choose to encrypt the data that needs to be shipped with his game. At run time AM then decrypts the data on the fly for the game to use. Sometimes you will see some extra files with a game, that appear to not do anything special. If you open them in a Hex Editor you will see the first bytes are "TMSAMVOH". This is an encrypted ActiveMark data file. Now, of course sometimes you will see no such files in the directory along with the game. But why is our Tripeaks game crashing? There appears to be no encrypted data....or does there? Well, take a look at the EXE's size compared to the original one:



Notice the dumped file is MUCH smaller than the original EXE? (Note: My original exe is named Tripeak1.exe because I renamed it) Ok. Now let's look at the original EXE's file header:




Notice that 0x0017D000 comes to 1560576 bytes. That's about the size of our dumped file. So what's going on here? Why is the original file so much bigger in reality on the disk? It's because there is some data actually stuck to the end of the file itself. This data is not part of the actual EXE header. This data is stuck actually to the end of our EXE. We know that the EXE ends at Virtual Address 0x0017D000. We need to see where it "ends" in the real file (known as the "raw size". Take a look at the sections information:



OK. Raw Offset is 0x0017A000, and its Raw Size is 0x1000 bytes, so that means in the file on disk the EXE actually ends at position 0x0017B000. Note this means that the EXE ends as far as the Windows Loader is concerned. The file itself is larger than this of course.

Let's open up the Original EXE in Hex Workshop and go to position 0x0017B000:



Ha! We have found an "encrypted data header". Yup, the encrypted data file is attached to the end of the EXE! So when we run our dumped file, it does not work, because this encrypted data is missing (remember how small our dumped file was) ! We need to grab this data somehow and put it into our dump. But wait - what about that Virtual Address that the data is at? If we paste it into our dump, won't it load at the wrong Virtual Address when the EXE gets loaded and not work then anyway? Well the answer is no. This data does not get loaded with the EXE, remember ? - it's not accounted for in the EXE header. In fact, ActiveMark finds that data by parsing the header itself from the file on disk, and finding the ImageSize, and then it knows the data comes right afterward. How do I know this? I tried different combinations of copying/pasting at different addresses, and this is the way it works. So all we need to do is copy this data from the original EXE and paste it on the end of our dumped file!

To Summarize:

  • Activemark can use encrypted data files.
  • Encrypted data files can be embedded into the protected EXE
  • The encrypted data is attached to the end of the protected file. ("overlay")
  • We can copy this data and paste it unto our dump.

So we need to copy all this data from this point, all the way to the end of the file. One thing to notice is that the "TMSAMVOH" header has that one 0x00 byte before it. Yes, you need to copy that too. I believe this is actually a bug in Activemark, whereas they get the ImageSize of the file, and paste on the encrypted data, but they have an off-by-one error :) They actually insert the data at ImageSize + 1.

Now, select all the data from this header point, all the way to the end of the file:



Be sure to include that final 0x00 byte as well, I missed it once and my program would not run!
Now Edit->COPY !!!!

Now open up your dumped file in the Hex Editor and simply go all the way to the end of the file, and Edit->PASTE, and paste the whole data block to the end of the file. You do not need to edit the PE Header whatsoever. Simply save the file and you are done! Now the game should actually run!

Ok. One thing I found when I moved the game from my reversing system to another system, is I got an error when I tried to run the game:



Then I would proceed to get this message:





Obviously I have enough disk free space, it's just something is not being extracted correctly, or perhaps since on the second machine I did not do an actual Install - (I only copied the dumped program) then I am missing this file. We can find this file however ! When ActiveMark starts a Flash game, it creates a temporary directory and extracts the files into it so it can be run. If you watch CreateFile calls on the original game you will see this occuring. In fact even if we look in LordPE at the game process we can see thus:

NOTE: You must run the original game to get these files !



Notice there is a DLL in my Documents And Settings\<name>\Local Settings\Temp\tempfolder.aaa\ ??? The tempfolder.aaa is created at run time by Activemark when it decrypts the files. If we now go to that folder we can find the file we need:




Yes! There is iml32.dll..so I copied it to my WINNT\SYSTEM32 directory and it fixed the game!


So there we go! The game is now fixed an runnable. Of course if you still have a nag dialog or time limits you need to fix those by other means such as CondZero's tutorials show. One thing to note is this game is protected by very old Activemark, 2.7.xxx, so the code is heavily obfuscated. In fact I could not find the areas to "disable" the browser nag. I did manage to disable the Time checks and Time Limit however quite easily. I also found another more advanced way to defeat the browser but that will be for a future tutorial...

Also, I have used this technique against 2 games. This game, and one other, and it worked on both, so I believe it seems to be the correct procedure. One interesting note: On the second game I did not get any errors such as missing DLLs when running it. However I would like to mention that before I pasted the overlay data correctly on the second game, it would not run AT ALL. Not even to the browser screen! So if your application is not running at all, check for this overlay data and attach it to your dump and it may just fix it.

I also have some other advanced attacks against ActiveMark which I may publish in the future. Right now there never is enough time to share everything !

-Lunar
Hopefully, this tutorial has helped you to learn some new things in some way. I do not take responsiblity for how you use this information! If you enjoy a game you must purchase it.

Happy reversing, Lunar_Dust @2006.