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:
-
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.
-
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.
-
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.
-
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.
-
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
|
