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?