Why I Developed TripWire

After BinEdit, I got into a kind of "hacking binge" mental state. I had successfully hacked and resurrected the game BipBop 2 and a few other games as well. It was fun to see what kind of things I was capable of.

A Rude Shock!

But hacking only gets harder, I found out. BinEdit allowed me to sift through Bip Bop 2's assembly code. But many programs have a little devil in them called "EXE File Protection."

Code dissembly using BinEdit only turns up paths that exist the moment the program starts. If any path of the program exists after the start of assembly instruction processing, BinEdit will not be able to trace it. Furthermore, some code does not "want" itself to be traced, because the program distributors did not intend for people like me to dissemble their code (of course, they certainly expected it).

There are several commercially distributed programs that stop BinEdit after only a few lines of assembly code. This means the code has, at the very least, a dissembler stopper as a protective device. So I guess my hacking days are over. Sniff--

But Wait...

It didn't take too much intuition at this point to realize that if other people protect their programs, then mine might also be vulnerable. I needed to make some protection of my own, something that would discourage people like myself from breaking and entering.

I built TripWire to perform basic EXE file protection. To date, this has been my most challenging project ever. It required all of my notes from the BinEdit project and then some!

All in all, TripWire isn't the best protector out there, but it isn't the worst, either. My motive for protecting my files is time: reverse engineering takes time, and time is a resource. Now, if someone wants to break into my files badly enough, that person will do it regardless. Fact of life.

But protection adds time and possibly money to a hacker's schedule. Slowing down the process of reverse engineering will guarantee a longer shelf life for one's software.

How to Use TripWire

Have declared in your program a static character array of at least 100 bytes. This buffer should begin with the null-terminated string, "Insert the loader here." The remainder of the buffer may contain anything else, but don't count on the contents being meaningful in the body of your program.

Now type "TRIPWIRE filename" on the command line. The EXE extension should be present in the name. If the file was successfully rigged, you will get a confirmation message. Otherwise, you will get an error message.

Run the file and see if it works! Be sure to keep FILE.000 in the same directory as the "cooked" EXE file. It is necessary for loading and decryption.

Great...Now What Just Happened?

If you look for changes in your program, well...nothing should be different. Which is a good thing--you want the program to be intact despite the protection.

Underneath the surface, however, is enough ice to sink the Titanic. Here are the things TripWire did to your EXE:

  1. Dissembler stopper: this is a basic code setup that uses tricky stack logic to make the program seem like it is making a far return at the very beginning. This halts path tracing in dissemblers like BinEdit.
  2. Relocation table destruction: the table of automatic relocation entries in the EXE file is erased. Now relocation must happen manually. The table is stored in an undisclosed location. In order to observe a true instance of runnable code, a hacker must wait for the relocation to occur--this requires time-consuming tasks such as single-stepping.
  3. Loader/Decryptor assembly: the mechanism for loading and decryption is not stored in the EXE file. Rather, it is stored in a data file that must be loaded at run-time. The data file is itself encrypted.
  4. Untraceable code: Once the loader/decryptor assembly has taken place, a series of hard-to-trace jumps and calls occur. This type of protection is killer--a hacker will have to be very patient about single-stepping, or else very bored.
  5. False paths: throughout the program's run-time assembly and decryption code, many snippets of code will appear to be legitimate. In fact, much of it is not. I have TripWire put actual code samples from various other projects of mine into the cooked EXE file. It may look like useful code to a hacker, but it is in fact a ruse! Patience must now drag to the end of eternity.
Why Are You Telling All These Secrets...?

Because really good commercial-grade EXE file protection, for Win32 and other operating systems, is much, MUCH more sophisticated. I provide this info as a case-in-point so that people interested in this topic can understand what must be done to protect files.

TripWire provides "back-of-the-envelope" protection. Enough protection to dissuade a lot of people from trying anything.

Download TripWire
Projects
Downloads

Home | What's New | Links | Contact Info
Copyright 2004 Christopher Allen.