reverse engineering

If somebody knows assembly that much , then VC++ can be used much effectively than masm.
And if requires then some of the code can be compiled in masm too , but only with masm we cant achieve coding simplicity for anti cracking code too.

Wow. What a discussion! I'm late, but this topic is always actual.

What about logical protection?
The idea is, make a silent registration check. Later in the code change the logic of some critical functions, so your program would give garbage results.

Give information that the the program is not registered indirectly. When the unregistered program leads to garbage result, don't test your security flag directly. Instead, test some impossible condition in the program that is probbably a result of running the unregisterd program. Then show your messge, at the point where the flag that caused it is far away.

I built logical protection as a second-level. On the beginning, there is only a check if registration is present or not. If not, program exits.
But if this point is cracked and the program runs, then a number of security flags are used to control the program flow without giving any message to the user until program breaks due to some logical error.


What u guys thing abut this method?

Ummmm , Your aproach is one of old/classic way of folling a cracker.But you know a cracker if notes je/jne ja/jna etc instructions paired with test, cmp as cause to change the flags , with a debugger who gives ability to change the assembly just in place , then it's very easy to see who is causing the exit or so.
Running a application 2-3 with each time changing and runing it can show you places where your app. check validity.
There are needs to develop a code which literaly dont tell anything about the registration.

The much safe registration process should have a device driver with it , all validity algorithms should be moved to kernel mode code .The driver will add services to kernel , which enables you to call the driver functions without calling DeviceIoControl.
I will explain you one method on Win98 ..

Win98 has VXD's.
1]Your application starts and loads a VXD.
2]VXD manages to find it's loader (Thread handle ... :p)
3]VXD can read the process EXE now , this way VXD obtains address of few functions in EXE.
4]Now till this EXE spawns few threads which are simply waiting with alterable state.
5]Now application dosent do anything , it just waits .....

Till this point a hacker/cracker is frozen ..........

6]Now the VXD Queues many APC to many threads in EXE.

Here Even the debugger see threads , he's unable to manage them.

7]The APC makes call in threads , thread starts and your app. is working as you wanted. YOu can , for better control , manage number of threads to share the work in timely manner.

A VXD can manage to watch for kernel debuggers to save it's own ***.



:cool: :D :D :D :D

Hmmm, sounds good but, for me, threads are a bit unknown field... I'm writing a single-thread app.

So, you suggest starting another processes that in turn give some crucial data to my app...

Before diving into threads-issues, is your approach platform independant? I mean, you mentioned Win98 has VXD-s. Will it also work under 2000, NT, XP?

It's platform dependant ! , as it involves Device Drivers.
But it's not hard to write 2 device driver , which does same thing one for 9x and anather for WinNT/2000/XP.
Threading is much easier part , no need to study for months.It will take few hours.

And yes to make your code tough against cracks , you must emply methods though enough. So no way , you can choose diff. aproach , it depends how much secure you want to make your app.

But remember Cracking guys use to sit down with PC for days to crack a logic , and the one second ,when they crack your code , your work jumps to zero.

First of all, I must say that no protection will help you in case of VALID serial numbers and registration keys distributed by some _registered_ user across the Web.

P.S. Many feeware code protection programs can be downloaded at http://protools.cjb.net

And many of them are already cracked , like ExePacker.

Todd,

Your name sounds familiar. Did you use to work at Pandesic?

I have tried to peruse this whole thread, and wanted to bring up a few points that may have been overlooked or ignored.

First of all, if you correctly build your project, then the symbols *will* be gone and there is no way to retrieve them. Go into project settings for your application, and under C/C++, make sure "Generate Browse Info" is not checked, and that "Debug Info" is set to none. Also, make sure to not distribute any pdb or pch files with your app. If you follow these guidelines, there is no way a cracker can retrieve your own symbol names. However, there is no guarantee that they couldn't retrieve symbol names for Windows API functions, ATL methods, etc. With optimizations, reverse-engineering an algorithm will be difficult, but still not impossible.

A lot of this thread has focused on how to protect an application against tampering, or how to make registration more robust. Neither of these goals would fit Todd's original problem, ie., protecting the IP inside the binaries. Regardless, as another way to protect against tampering, I suggest using digital certificates.

Lastly, if you really want to protect your IP, you
could implement your central algorithms as a web-service. This would raise other issues, such as: Performance, your app could only run while the computer was connected to the Internet, and you may run into a security problem in protecting use of the web-service. However, if protecting your IP is your highest priority, perhaps something to consider.

Good luck.

- Henri

Unless you obfuscate (make the readable source meaningless in human readable format) your binary file, your source code can, in fact, be retrieved in nearly ANY language. On online test you may try can be found at http://www.remotesoft.com/salamander/ . This one breaks .NET assemblies down to vb.net or C# with over 95% accuracy. Actually if you get their Explorer you can see a list of other languages (and melt ice is useless against it). that can be disassembled with blazing speeds.

There is another tool similar to this one called LSW-DNRB that gives you source examples of how to make your own language plug-ins - so here again - all languages are vulnerable.

I also have found similar tools for flash swx files, vb 3-6, cpp, c, java, and others - most of which are available through the sourceforge.com website from the actual developers themselves - just compile to your platform and go.

All makers of these tools agree that the only way to turn them away from cracking your software is to obfuscate your source in the final binary so that even if they do get your source, they wont want to spend time trying to make sense of it. See the link above for full details.

Seems you havent seent he complete thread , and even never looked into windows executables and compiling procedures.

.NET compiled executables keep much information in executable , because of which is can be decompiled back to almost similar code.

C++ Code compiled with VC++ without debug information , cant be brought back to even 20 % similar C++ code.It can be decompiled to C+ASM code , from which you will never be able to find classes and their members etc.

Krishnaa is absolutely right. I'm getting fed up with people making unsubstantiated claims that c++ code can be "decompiled" back to it's original source code, including function/variable names etc. It's absolute rubbish !

If you can provide a link to a piece of software or collection of articles which show us how to do this, then fine. If you can't, then all you are doing is circulating rumour.

I just want to see some software that can do this. If it can be done, then surely there will be a very rich company providing software solutions enabling me to get the source code for Microsoft Visual Studio .NET

Jase , .NET executables have more SEGMENTS which keeps the information about the code. Have you read .net framework basics ? read it . It's very much similar to JAVA kind of executables.
Have you seen the link given by him ?? there is web based .NET decompiler , it will show source code of .NET executables (Not simple VC++ compiled exe/dll). I tried that , it shows totaly readable , undestandable source code in the language it was developed.

Krishnaa

I am talking about c++ code, not vb, c# or java. These compile to a byte code which is interpreted, therefore reverse engineering this code is perfectly possible.

I'm talking about decompiling compiled c++ code from its assembly. I believe it can be done, but it cannot possibly decompile back to the original function names and variable names. Therefore, code obfuscation such as renaming the function "IsKeyValid()" to something illegible such as "FF7E087F()" is completely unneccesary. All it does is make your code hard to maintain. I know this, because i went down this route myself when advised a year or so ago. I wish i hadn't, because the source is now so obscure in places that it's hard even for me to follow:)

I want to see some software which will take a c++ binary executable (release code), and decompile it back to original function names and variables. Until then, there is no proof, so anybody who says it can be done is just spreading rumour.

I'm not an expert on RE by any means. I know very little about the subject in truth. I'm simply working on the basis that if it can be done, somebody will be selling the software to do it. I'm also working on the assumption that if you open up your exe in notepad, you will find all strings declared in your string table or declared directly in your code between quotes, such as "my text". You will not find any of your variable or function names in the exe. With this being the case, how can you possibly retrieve information that is not there ?

Obfuscation is surely a total waste of time ?

I completely agree with you Alan.

My post was in reply to masterzin, who appeared to claim that it is possible, when we both know that it is not. This is a c++ forum, so naturally it is reasonable to assume we are taling about RE of c++ code.

Your post agrees with me entirely, apart from obfuscating export names from dll's. I was talking specifically about obfuscation in exes. It is completely unecessary. It's fair enough to make critical parts of your code obscure, but renaming functions and variable names is counter-productive, and unnecessary.

As for dll's, I agree with you entirely.

My heart was sinking as I read this thread, but as it continued I brightened. Most of them are right: you cannot directly get back source code from an .exe.

I have SoftIce, I have a dissassembler, a hex editor. Yes, I crack programs for my own enjoyment. SoftIce is one of the best cracking tools one can get, but it CANNOT spit out c source code. So is your source code safe? No!!!

Just because you can't understand assembly output doesn't mean someone else doesn't. ****, there are people out there that probably speak with 1's and 0's. What SoftIce and regular dissassemblers can do is detect whenever a function is called from a .dll. This means that all of the Win32 functions are in danger.

I suggest giving people the runaround. Common places to look is when error messages are given, or text is extracted from a source. Place the function calls to sensitive algorithms far away from where you report and retreive information.

I have no doubt that there is at least someone out there who is sick enough to be able to regenerate entire C++ class structures (without actual names, of course) of the original code simply from assembly. And they could probably be very accurate.

There is a defense against softice though, but I'm not sure it is this "MeltIce" since I can simply change file names. I accidently left it on (I have to restart to toggle it on or off) and tried to run a MS game. It "detected a debugger" and shut down. I never investigated, so your guess is as good as mine.