Category Archives: Reverse Engineering

D3DTextureRipper – Ripping Textures From D3D9 Games


This tool allows you to rip textures from D3D9 games.  It grabs the textures by hooking device->SetTexture method and dumps it to a file inside your game’s path in a folder called “Textures.”  The textures are generated in BMP format and are named in non-descript names (by address in memory at the time SetTexture is called).

Quickly Patching Binaries With OllyDbg and OllyDump

Quick post here gents. If you’ve been looking to patch a binary you can load it up in IDA, make your changes, commit your changes, make a diff and use a patcher to apply the patch to the original binary. If you’re tinkering with a project in olly and are making modifications to the binary continuously this can get old fast. So go grab yourself OllyDump and you can automatically patch your memory changes by generating a fresh new exe with it.


MemoryUtility – A Binary Modification Library


I’ve found myself reverse engineering a few applications lately.  Usually I like to go about it with a debugger like ollydbg attached and modify the code during runtime and observe the results as I do it.  This is fine, except when you find yourself twenty instructions deep and having to re-type the instructions every time that you hit “Restart” in olly or every time that the process crashes on you.

So I’ve put together a simple library that injects bytes into the target process and that way I don’t have to retype work previously done every time that happens.

IDA Hacking Android Apps – Hero Defense

Here I will show you how to disassemble an android game, and modify its files to obtain an advantage like god-mode using ida pro.  For simplicity purposes I will refer to editing codes with ida in this article as ida hacking.

The ida hack in action can be seen here:


  1. APK Downloader
  2. dex2jar
  3. jd-gui
  4. IDA Pro or similar disassembler (our main tool, and thus the phrase ida hacking)
  5. Binary patcher
  6. ZipSigner

IDA Hacking Tutorial

The steps for this project are as follow:

  1. Download the Hero Defense APK.
  2. Extract its contents.
  3. Turn its dex file into a .jar file.
  4. Dissasemble it.
  5. Dissasemble the shared library containing its API.
  6. Patch the library.
  7. Repackage the APK.
  8. Sign the APK.

The first thing you need to do before you start ida hacking is download the APK.  This can be done by using your android device, or you can do it from your pc using the APK Downloader from evozi.  Once you have the APK downloaded you can rename it to a .zip file and use any zip utility to extract its contents. You will see a classes.dex file at the root of your directory, you can turn this file into a jar with the dex2jar utility.  After you have done that you got yourself a dex2jar.jar file containing all the game’s class files.  You can load those class files using jd-gui and begin reading the code.

[JAVA] Bypassing Licensing Schemes Through Bytecode Modification


I have been meaning to write a bot for Objection!, a game whose purpose is to test your ability to identify objectionable questions during a simulated trial.  While I have a valid key, I am only allowed to install it in one computer at a time.  Since I use my laptop more often than anything else, I installed the game there so I have it handy when I wish to use it for its intended purpose.

In the meantime, I had to come up with a solution so I can use the game on my development machine to write my bot. When I attempted to decompile the code, modify the licensing part, and recompile the code, I was hit with a bunch of repeated declarations and other ambiguous code (about 300 or so errors).  Needles to say…I’m way too lazy to manually resolve all those problems to recompile.  The next best(laziest) option was to modify the bytcode of the compiled classes so that I can do the same thing, without having to worry about recompiling and fixing all the issues.

Creating Custom JAR Loaders With ClassLoaders

[Note] This article is part one of a two part series on making a bot for a java game [/Note]


As part of being in the trial team we were given a game called Objection! which is a really old/DOS-looking kind of game with horrible graphics that allows you to hone your objection skills.  It gets really tough after a while, so I thought it would be fun to inject a dll and dump the questions and make a simple bot. If anything, it would be a good exercise in reverse engineering.

Since it comes bundled in an exe, and it looks old as hell, I assumed the game was written in C and using the WinAPI.  But after popping up IDA and looking inside the exe, I quickly realized that it was nothing more than a JNI class loader, and the game itself came bundled in a jar file called tmgames.jar.  This changes everything, instead of injecting a dll to detour functions from the process, I can build a custom loader to load the jar, and instrument the client’s code at runtime.

The first step in this whole process is taking control of the loading process of the game.  After that we can instrument it.  And so this tutorial is born.


The process breaks down in six steps:

  1. Build a classloader from the gamejar.
  2. Load the class that has the game’s main method.
  3. Get the constructor that you want to call of that class.
  4. Instantiate the class with the constructor and parameter(s) you need.
  5. Find the game’s main method.
  6. Invoke the main method.
package runtime;
import java.lang.reflect.Method;
import java.lang.reflect.Constructor;
public class Main 
	 * @param args
	public static void main(String[] args) 
		URL[] url = new URL[1];
			url[0] = new URL("file:////C://Users//emist//workspace//tmloader//bin//runtime//tmgames.jar");
		catch (Exception ex)
			System.out.println("URL error");
		Loader l = new Loader();
	public static void verifyValidPath(URL url) throws FileNotFoundException
		    File filePath = new File(url.getFile());
		    if (!filePath.exists()) 
		      throw new FileNotFoundException(filePath.getPath());
class Loader
	public void loadobjection(URL[] myJar)
			//Create a classloader.  myJar holds the full path to the game's jar file. 
			URLClassLoader child = new URLClassLoader(myJar, this.getClass().getClassLoader());
			// is the class that holds the main method in the jar
			Class<?> classToLoad = Class.forName("", true, child);
			if(classToLoad == null)
			//game doesn't have a default constructor, so we need to get the reference to public game(String[] args)
			Constructor ctor = classToLoad.getDeclaredConstructor(String[].class);
			if(ctor == null)
				System.out.println("can't find constructor");
			//Instantiate the class by calling the constructor
			String[] args = {"tmgames.jar"};
			Object instance = ctor.newInstance(new Object[]{args});
			if(instance == null)
				System.out.println("Can't instantiate constructor");
			//get reference to main(String[] args)
			Method method = classToLoad.getDeclaredMethod("main", String[].class);
			//call the main method
		catch (Exception ex)

Something to note about this code is that there are many hidden pitfalls.  For example, if you call getDeclaredMethod(“main”) you will have a methodnotfoundexception.  The reason being that you have to match the method declaration.  getDeclaredMethod(“main”, String[].class) matches main(String[] args), while getDeclaredMethod(“main”) looks for main(), which doesn’t exist.

Another thing that can trip you up is that classToLoad.getDeclaredConstructor is required if the class doesn’t have a default constructor.  If you forget to do this, you will get an exception to the effect that the class cannot be instantiated.


If you’re wondering how you find out what methods you need to call and what parameters they take, there’s many ways of going about it.  Personally, since its java I extracted the jar and ran the classes through jad.  Once decompiled its a simple process to figure out what code you need to be calling.


So now you have a class loader to load your jar.  This is the first step in making a working bot.  In the next article I will show you how this fits into a working bot.

Capeze.exe – That Was Easy

Scouring the Internet for reverse engineering tutorials for beginners that are both high quality, and use available targets can be a daunting task.  Its for this reason that when I found a tutorial that used CaptureEze97 I jumped at the opportunity to learn some new tricks in my reverse engineering journey.

For whatever reason, after spending a good thirty minutes to locate the target capeze.exe, I lost the tutorial’s link and found myself with a target and no guidance.  As I wasn’t about to let 30 minutes of my life go to waste, I opened up CaptureEze and attempted to register it.  Unfortunately for me, the makers of the software don’t have the best sense of humor and my request was denied. LOLCODE

Who doesn’t appreciate a good LOLCODE?  I asked myself, as it became clear that it was time to bring out the big guns.  I opened up SoftIce and set a breakpoint on GetWindowTextA, because I expected that api call was going to be called right before my information was going to be compared to the valid registration code.

After stepping back and forth between softice and the caller a few times, I finally reached the entrance to the promised land My input

If you remember from not too long ago, “world” is what I inputed for my company name, and it(or the address to it, I’m not quite sure on that yet) is being pushed in the stack at 00573FAD.  Only a few instructions further down, we find our LOLCODE LOLCODE in Memory

LEA(Load Effective Address) is an instruction that loads the address given on the right into the register given on the left.  In this case it seems the address to LOLCODE is being put into EAX, perhaps in preparation for the comparison to the valid registration code.  Just one instruction down we can see that our suspicions are correct, as we find that a long string of digits is being placed into ECX .

Continuing execution leads us to the expected place, and we can see the string telling us that we have entered an incorrect key loaded in memory. Capeze Incorrect Code

It all seemed to be going well, but you just never know until you test it, so I inputed the key I found before and the expected “thank you” screen poped upThank you for purchasing

All in all it seems reverse engineering unprotected binaries isn’t all that hard.  I will be focusing now on more complicated protection schemes as I attempt to expand my skills and level up.

Thats it for now!

Code Reversal, Because Writing It Is Only Half The Fun

Its 5 am in the morning and I have yet to go to bed.  I’ve been up all night since the new year’s celebration reading an IDA Pro book and playing around with SoftIce.  After spending 2 hours without any success on what is probably a really easy program to crack, I was just about ready to write a failure post and catch some much needed shut-eye.

Instead, just as I was about to give up for the night I managed to crack my first program.  The target-a small program called Start Menu Cleaner, that hasn’t seen an update since the year 2000.  Seemed like a good target to start on, specially since there is a beginners tutorial on it here.  How hard could it be right?

Right off the start I figured it wasn’t going to be as simple as it seemed.  I started Start Menu Cleaner and clicked “Register” and proceeded to enter SoftIce by pressing CTRL+D.  Once inside I set a breakpoint for GetDlgItemTextA and continued to click ok repeatedly on the Start Menu Cleaner dialogue.  To my dismay nothing happened, the breakpoint was never triggered.  I figured maybe the tutorial is outdated so I decided to dig into the binary and try to figure out what functions I could break on.  For starters I knew that the program would output a “Incorrect Code” message when the serial code didn’t match the one it expected so I did a string search in IDA for that and I came up with this IDA Pro Incorrect Code.

Regardless of what this function is supposed to be doing, it is clear that it has two paths of execution, if the comparison fails it goes to the subroutine that prints “Incorrect Code” if it doesn’t, it probably takes you to the area where the cool kids go.  I figured the easiest way to figure out what the code is was to follow the execution backwards so I went into the function call that led me here and I saw the first sign of good news:  IDA Pro lstrcmpA.

lstrcmp is a good sign, it means that when the execution gets here the values for both the code I entered and the code the program expects will both be in memory and easily accessible.  The last thing to do now was to add a breakpoint on lstrcmp, trigger that function call, and browse through the stack and registers to find the value the program is expecting: SoftIce code found

So there you have it, the simplest crack known to man but we all gotta start somewhere.  I still don’t know why SoftIce wasn’t breaking on GetDlgItemTextA, since the program clearly uses it.  On a sidenote, the code I found was 1334-12386-1805-357 which is different from the tutorial’s 1254-11586-1981-389.  I don’t know why that is the case either since I downloaded the binary from the tutorial’s link as well.