How to prevent Reverse Engineering
All thats been said is without a doubt true. Ive learned by looking at other code and one technique if come accross to prevent reverse engineering has stood out from the rest. I have found the some app's use the ReadProcessMemory() (a windows api func) to veryify that that people have not altered you code. Remember most if not all breakpoint will change the in process memory so if you compare a segment of code while its in memory you can prevent people from inject jmp statements by actually checking veryifying the in proc memory. Break pts are usually an injected "int 3" statement which causes an exception which your debugger will catch and then say hey look we reached a break pt.
So you should beable to prevent people from even puting bp's in critical sections of code and remember dissassembling is alot easier when you can step through a working model of the code
Please stop passing along bogus information.
I want to start out by saying thank you to "Paul McKenzie". He seems to be the only one in this thread that is passing along correct information.
Yes, it is true that SoftIce will allow a user to set a breakpoint on ANY Windows API call. Which also means that the code for detecting SoftIce is a joke. The hacker simply puts a breakpoint on CreateFile() and checks the parameters that are passed to it. This tells them what the user is attempting to do. If it's a check for SoftIce, simply jump over it or make the software think it didn't find it.
As for the concept of your EXE containing your C++ source code...the answer is NO! Assuming that your not an idiot and you are releasing a RELEASE build and not a DEBUG build of your application. Just for the sake of argument, let's say that you did release a DEBUG build and it included COFF style debugging information. In this case, yes you are giving out your source code. Not because it can be reverse engineered but because the COFF style debugging information includes your source in the EXE so a debugger can access it. However, the Microsoft Program Database, which is the default style in VC, does not. It creates a PDB file that contains the debugging information. So what lesson have we learned. :=) Don't release DEBUG versions of your software. However, if you need to be told that, then you should find another profession. :=)
If you build in a SoftIce check like the one someone mentioned earlier, make the function inline. Then include it in multiple places in your application. This will force the hacker to find every instance of this check in order to get the program to run correctly. This won't stop them but it will slow them down. If you don't make it inline then all they have to do is find the function and change it's return value. And every place in your application that calls this function will think SoftIce is not loaded.
The real question when it comes to reverse engineering is "Is it worth my time?". If a hacker has good reason to reverse engineer it then you have a concern. But this stuff is not easy, so hackers don't spend time on it unless they have something to gain from it. For example, like recognition for cracking Windows XP's registration.
If you really have a concern for this stuff check out a product called PECompact.
http://www.collakesoftware.com/PECom...SPECompact.htm
PECompact allows you to compress an EXE file and encrypt it. However, this only makes reverse engineering harder...not impossible. Nothing is impossible, so all you can hope to do is make it hard enough that the hacker says "forget it".
Good luck!
Re: reverse engineering (debug version)
Might I add a little twist to this very interesting thread? ;)
It has been multiply stated that the original (C/C++) source code cannot be obained from a release EXE/DLL. However, higher level source code similar in functionality to the original can be obtained. Several attempts at decompilers do exist, but I'd classify them as "work in progress" as of now. (see for instance http://boomerang.sourceforge.net/ )
Anyhow... moving to my question. When having the debug version of a C/C++ EXE or DLL (including the PDB), it should be possible to recreate the source. It is quite trivial, but lengthy, to do it by hand - stepping into the binary does reveal all kinds of information, including variable/function names, types and so on. Even class structure is embedded as debug information. Yet, I am not able to find any utility that automates the task. Does anyone have any useful information?
