reverse engineering

I would just like to apologise to Krishnaa for my comments.

I believed he was advocating that the EULA can be ignored, and that you can just pick and choose which parts of it you wish to uphold. If this is is his opinion, then I think this is wrong, wrong, wrong ...

However, after re-reading his posts, I think I may have misunderstood them. It may have been that he was saying "i wish these parts weren't in the eula because i think they are unfair. however, i always uphold the eula as i am legally obliged to do". If this is the case, I apologise :)

Interesting discussion going on. I just want to add one link,

http://www.itee.uq.edu.au/~csmweb/dcc.html

PhD thesis from Queensland University of Technology in 1994.

Hope you enjoy this thesis too.

In the US, it is completely legal to look at the raw bytes of any program you purchase and, indeed, convert them to assembly or some other form for human readability (a recent link by zebbedi goes into this a little). In fact, Microsoft found this out early on when it tried to sue a worker (for Symantec? if my memory serves me) who disassembled some of the GDI for font enhancements to Windows. Microsoft's most pressing legal concern in its recent anti-trust came from the realization by disassemblers that some software products by MS not related to the OS had unfairly used undocumented APIs to provide capabilities in their products that others would have a much more difficult time implementing (see Undocumented Windows by Schumann et al. for a brief intro into these issues).

It is not only legal, but often ethical to do this disassembly. I wouldn't have Nebbett's Native API Reference without it, and some of my product's capabilities would not exist without this knowledge (even with ring0 code, the OS internals would still need to be disassembled). This is one of the strongest reasons for RE in the professional world, to extend capabilities of third-party products (like OSes). Of course, crackers will continue to use disassembly in ways that are not ethical, but their actions are illegal for other reasons not related to RE, and the legal options of companies so compromised are not taken away. However, for sensitive technologies where enforcement of intellectual rights is imperative, the options presented earlier in this thread (polymorphic and encrypted code) do assist in the protection.

did you ever tried to debug a crashed program ?
ms gave you the oppertunity to somehow found the crash of your program [ if you have VC installed ]...
now, isn't VC disassemble the memory dump area?
yeah..it does, so do you still consider it breaking the rules of EULA?
its the same if you disassmble the application with an kernel/system debugger like Softice[must buy it!!] or ollydbg[free]
what ever happens on YOUR memory is no one's concern.
i do agree that spreading patches/keygens hurt the authors, but as far as for big companys it just doesn't effect at all, since they sell lotsa licences...
disassemblers like IDA\Win32ASM are mainly for research decompilation, and they knew that it will serve the RE commnity but they couldn't do anything about it...what do you say?

Quote:

---

do you crack software Bengi ?

---

by james,
i learn this process just because it increases my programming skills drasticly, both in the ASM and (C/C++/VC) world.
the process of learning RE [Reverse Engineering] is really really long and will eventually brings you satisfaction [try it, you will find a whole new world rather than just code a boring application].

*the je/jne lame rutines are there just because the authors were lazy enought to protect thier OWN software.

* mostly you will see that a cracker will try to break your code validiation routine and will spread it proudly with his name tagged and group logo...

* a true cracker [RE] will try not only to reverse that rutine, but also try to improve it, learn it, RECODE it and than will be satisfied with the new knowledge he had gain, not for fame, not for group name, but for his OWN reversing knowledge, from this he will probably make a tutorial, mabye email the authors, or whatever..thats the power of RE.

you can say that RE is illigal..but what is lligal than?
listen to our masters while we obey as thier slaves? [sound a bit harsh..but its the truth]
read -> http://www.woodmann.com/fravia/legal.htm

give RE a chance by studing it and make your software even more protective!

the HCU project had a section for protectionists, but i doubt authors really had time to read anything from it!

How do you protect better than?
-> http://www.woodmann.com/fravia/protecti.htm
-> http://www.woodmann.com/fravia/protec.htm

Some future chaos by a RG [reversing god]:

Quote:

---

The world of the near future will be a "world of software", an half-virtual world, where code will assume today unbelievable massive proportions, where "reality" will not count much for the pavlovian gullible beings that will forget their miserable slave conditions deafened by the concerted (and concocted) "virtuality" that they will Oh so much love. A world of software, a world of code, and therefore, as usual, a world of hidden codes and hidden meanings (as if the world we live in now did not have already enough of them :=(

---

for somehow minimal knowledge, these are THE Reversing Gods:

[Andrew Schulman]~ [Jim Kyle]~ [Matt Pietrek]~ [+ORC]~ [Quine]~ [Stone]~ [Saltine]

and some last words from our famous RG:

Quote:

---

"Give a man a crack, and he'll be hungry again tomorrow,
teach him how to crack, and he'll never be hungry again"

---

I haven't read all of this in detail but Paul and others are right of course. It's not possible to produce the original source of a compiled app if it's shipped with no debug info (and incredibly difficult if not impossible even if it is, depending on the info available which is almost guaranteed to be insufficient). For a release version in particular though, it's just machine code at that point and there is no symbolic info anywhere to be found. All you can do is generate human-readable source from a disassembler app. It will look nothing like the original code though.

Bengi,

As i said earlier, i don't mind RE, if you want to crack my software, go for your life. My point earlier about the EULA was simply an answer to a previous post which stated that there was nothing legally wrong with reversing an application. I reckoned that if you forbid it in the eula, then you're denying people the right to reverse your app. But it seems i was wrong there, as a number of people have pointed out. I wasn't trying to suggest that reversing is *bad*, if that's what people want to do then fine. Everybody's got to have a hobby ...

I'm convinced that in general, the people who will search for a crack because they don't want to pay you $10 or whatever, would never have bought your software in the first place. So it's likely that in the majority of cases, you haven't really lost any custom.

Thats it ..

Jase seems to be understood my meaning.

BTW ,(to all) What good tools you know ?
I use SoftICE , PeBrowseDebugger , TRW2000 on 98 , IDA Disassembler , Win32DASM , Resource Viewer and almost everything from Sysintyernals , API spy , VC++ debugger , WinDBG (sometimes).

IF anybody has better tools let me know.I am freak of such tools.

HI,

To all SoftIce bashers. :-)

I dont think SoftIce can present C/C++ code to the user if the binary is built in release mode.

SoftIce works by deciphering debug symbols from the binary. It understands the debug symbol format as incorporated into the .exe or .dll by Microsoft VC, etc, and uses them alongwith the code base pointed to by the programmer, and helps him debug.

Binaries that are "Release" build donot have these symbols, and cannot be deciphered into exact code.

Yes, they can be presented as assembly, and they can probably also be interpreted into an approximate C/C++ code. But, getting the exact representation of the original code is not possible.

Any comments? :-)

Thanks,
Siddhartha

It's already discusssed , see previous post to this thread.

Siddhartha:
thats IDA's job =)

Hello All ...!!!
Interesting & impressive discussion is going on...A good thread to start with...My first post...!!!
Can anybody here tell me how to get SoftIce...? someone said that it is a freeware? is it? then please share a link so that all here may actually see what SoftIce is? and what is it capable of?

Thanks

It's not freeware friend , how it can be , it's worlds best debugger.

But you might find it cracked , and I recommand you to purchase it from NuMega , it deserves the cost.
If you dont want to purchase softICE now , then no problem , get started with VC++ debugger itself. Few Debuggers are realy free for download like w32dasm , PEBrowseDebugger etc. Main thing is you need to start studying the OS and it's working.

It's certainly not free, that;s for sure ...

http://www.compuware.com/products/devpartner/softice/

And seeing as it costs $800 , i'm surprised any crackers out there are able to use it. That is unless they steal it from somewhere.

Quote:

---

Originally posted by Krishnaa
But you might find it cracked , and I recommand you to purchase it from NuMega , it deserves the cost.

---

Did you pay $800 for it then Krishnaa ? I doubt it :)

As this begins to degenerate into a cracker discussion, this thread is closed now.

If someone has something valuable to add to this discussion -- i.e. something that hasn't already been stated and really adds value to this thread -- please send me a PM.

At the request of some users that participated to this thread, I will reopen it and let the discussion continue. Please keep following two things in mind:

- Discussing how to crack copyrighted software or how to obtain tools to do such activities is prohibited. Also, discussing ways on how to obtain any copyrighted data without paying for it is prohibited. I'm very serious.
- Please do not allow this thread to degenerate into a flamewar.

I do reopen this thread in the hope that it developes into a constructive discussion about software protection and debugging techniques.

Thanx Gabriel Pal !
I agree to you , nobody should start discussing how to crack...instead lets talk about understanding engg. concepts of Reverse Engineering and securing our software.

Okay, im glad we can continue this discussion.. thanks for reopening it.

From my experience the following can help:

1. Avoid commercial protection systems such as well known packers/distributors. Theres always a previously written unpacker available that even the most basic of users can work.

2. If youve got the knowledge try and customize your packing slightly yourself. Change headers etc. Another option is mess with your compilers advanced options. Theres a very good article by "Todd C. Wilson, Fresh Ground Software" where he developed a class called 'AgressiveOptimization'. Now this class not only pre-packs your exe on compilation, whilst it does it it also mixes up the PE table sections making it gibber when decompiled using WinDasm.

3. Remember that debugging using a tool such as Softice, Ollydbg or TRW2000 although all are excellent, become an absolute nightmware when the code starts spawning off threads. If you are going to develop a routine, why not have 10 threads, create a mutex, a bit of syncronization and let each thread take its turn in manipulating your registration data.

4. Custom structures can somtimes cause problems. Maybe try some of these?

5. You can hide string routines from the 'string ref' sections of WDasm simply by turning them from CStrings into char arrays and storing the ASCII value rather than the char itself.

6. Finally my last suggestion, and ive been meaning to actually get round to coding this is i am going to attempt to dump a section of the code out from my application to a seperate object. When the application is registered the missing data will be given to the user and the application will import the data chunk at runtime, sling it in memory and commence execution.

7. If you do generate registration codes, dont generate one when the use enters his name etc and then compare it to the fake register code he entered. Youve just done a favour for the cracker and shown him how to generate a real code. Instead, decrypt the code he entered and see if it matches his name and details.

8. When your comparing, avoid functions like CString.Compare. Intead do a char by char comparison or similar.

9. If you want, avoid common windows messages and API. Instead of using GetWindowText, use SendMessage(WM_GETTEXT).

10. Dont have a nice big display box saying.. 'Thanks for registering'. Move the code which verifies the regcode somewhere completely different, and delay in checking if they entered a valid one or not. You just end up giving the cracker an entry point into your app otherwise.

Just a few simple solutions to keep out the newer wannabe crackers.. coz lets face it youll never beat all of them out there ;)

Yaa , threaded code is hard for debuggers , but many debuggers have ability to trace EIP.
I believe that polymorphic code like encrypted functions with great use of JMP and changing few registers without purpose can secure the code much.

One more idea for securing the code from RE is to place the sensitive algorithms inside a VXD/Device Driver and pass the IOCTLS without many non-understandable arguments.
We can secure our memory area's from being dumped by debuggers like softICE by creating handles (logically) to them , the memory will be allocated by driver and a logical indexed handle will be given to Application , and application will manage all memory to be secured in such manner , memory can be acceses by sending IOCTL's.
A debugger can trap DeviceIoControl to know what mechanism is used to communicate with driver. I am working on finding a method to call the DeviceIoControl unnoticely , but not got better success. I got one solution to use DLL's without statically linking and without calling LoadLibrary and GetProcAddress. => We can find the function address without calling GetProcAddress and check whether the function is being spyed or whether it's modified , if not lets go modify EIP to call it , dont call it direcly using call or JMP , still i am improving that.

Do you have found better algorithms ?

A few recommendations :

1) Never follow your registration validation routines with a MessageBox("Valid/Invalid Key") type response. The cracker can breakpoint the message and find the validation routine very easily. A simple patch of a few bytes will probably render your algorithm useless. Try starting up a thread, and validate in there. You may then want to start a timer, post a message or spawn another thread. The response to the message or timer or new thread will be the result of the validation.

2) Never hardocde string into your code, as these can located in your code very easily. You don't even need softice, you can use notepad.

So ... instead of

Code:

---

CString sMessage = "Thanks for registering the software";

---

... Build up the string character by character. Like so :

Code:

---

CString sMessage = "";
sMessage+="T";
sMessage+="h";
sMessage+="a";
// etc

---

The message no longer appears in your binary. I recommend this approach with ALL sensitive messages which may help the cracker identify places in your code.

3) Do not go to the lengths of making your code completely unreadable to yourself, you will just make your life much harder, and your code will be harder to maintain. Providing you send out a release copy, the function names are NOT in there, no matter what anybody else might say.

So, there is no need to rename

Code:

---

bool m_bIsRegistered;

bool CMyClass::ValidateRegistrationNumber(int nNumber)

---

into

Code:

---

bool m_bShow Window;

bool CMyClass::TranslateParamaters(int nNumber)

---

It may seem like a good idea, but trust me. I did this and now some of my classes are horrible. If you want to know whether or not a symbol is available for the cracker to view, open up your exe in notepad and do a text find for the string, variable name, class name, function name or whatever. If you cannot find the text in the executable, then nor can the cracker. I mean, how could they if it's not there ?

Just some pointers. I'm certainly not an expert, but i believe these points are good advice.

One more thing, have fun :)

Making source code unreadable will protect it from some newbie kind of person from reading and understanding it.

There are cracking wizards who crack your software by patching various places by JMP and make eveything working.

Personally i wouldnt rely on a single bool setting the entire applications registration state. Thats where a JE (74) op code can easily be changed to a JNE (75) or even a JMP (EB). Extremely simple to patch.

Instead, theres a guy on this forum with a webpage called "Sams Simple Samples". On his site theres an excellent example of how to setup function pointers. Well instead of your app returning a bool, return an integer no matter what and dependant on its value, call a different function from its pointer. Great fun to mess with even if you dont want to use and well worth a look.

Function pointer manipulation can be breaked by using API Spying+debugger.

Nice suggestions. My code was simply an example of renaming functions to obfuscate code. I wasn't recommending the use of a single bool to hold the registered state. A more creative solution is required, and yours is good.

I think it's probably better not to store the registered state of the application in memory. It probably a good idea to call your validation routine every time you need to know if the app is registered. Also, don't put all your eggs in one basket. Have several validation routines, each which validates in a different way. Whenever your code needs to know if the application is registered, you could call one of your registration validation functions at random.

Make your code complex and be creative, but remember to keep it tight. You don't want to cripple your apps performance with deliberately redundant code.

Write a bunch of functions that check the validation. Organize each of them in a different manner, so they don't produce the same assembly pattern. Make all of them inline (or better force_inline, if the compiler permits this). Have the functions call a bogus function pointer if they don't find a validation -- i.e. crash the app. Don't use only one validation pattern, but 2 or 3.

Use the functions often, and randomly spread thru your code.

Make up a fake validation routine and use that in a timer, with a messagebox that sais "Not registered" or so. Leave the string as is -- visible in the PE. This will lead a large part of the wannabe crackers on the wrong path.

Good suggestions Gabriel. Particularly the inline validation functions. If they've gotta patch your app, make them patch it in 100 places.

Furthermore, calling on the bogus pointer Gabriel suggest could in fact be the "key is valid" action. Supplying an exception handler futher up in the code will catch the crash and perform the validation.

Just another slant on the theme.

Have anybody worked with finding length of function of any kind.

I can find it when it has prolog and epilog of std. way. But it's problem to determine the length when functions are naked and have multiple returns depending on situations.

Have a look at this snippet:

Code:

---

/*
The ideea behind this snip is to make the code look like
nonsense at a first glance, when dissassembled or watched with a debugger
*/
        LPSTR lpszMessage = "Testing";
        _asm{
                push eax
                push 24
                push lpszMessage
                                /* save EAX */
                call stealth        /* this will put the address of the
                                                next instruction (_emit..) on the stack*/
                _emit        0xea        /*this is the opcode of a absolute far jump;
                                                it will take the next four bytes as operands,
                                                or, at least, it will look like this, dissasembled;
                                                this means that the opcodes for "pop eax" and
                                                "call the_test" will dissapear, being treated as operands by
                                                a disassembler */
stealth:
                pop eax                        /* remove from the stack the address pushed by "call stealth" */
                call the_test                /* call your proc */
                pop eax                        /* Pop twice in EAX, cause with _cdecl*/
                pop eax                        /* the caller must restore the stack*/
                pop eax                        /* restore the EAX, pushed at first */
        }
/*
naturely, if someone takes a closer look, he will notice that "call stealth"
is translated to a call to an address that is not a mnemonix, but inside an instruction;
taking the code and analyzing it with "paper and pencil" can reveal the real
functionality. The problem is, that if one has enough stealth calls, that vary in their
implementation, the hacker's job becomes harder.
*/

---

Simply gr8 idea ! ,whats if call stealth is replaced by
MOV EIP ,stealth :D

You cannot use EIP as move targer AFAIK; i.e. you cannot directly manipulate EIP. But of course that you can "hide" a few well thought "PUSH the_test", and then do a RET **evil grin** ;) It will look like the return point of a proc, when it actually is a call to the_test.

For example: take the address of the proc you want to call. Scramble it using some validation and push it. Do some other work and then do a pop, unscramble, push. Again some other work, then a ret. If the unscrambling wan't successful (i.e. not registered) it will ret into Wallhalla :D

I see ......

What are other options to make EIP contain function address and stack is correctly filled.

In the case of push test_fun and ret , it's neccesory that the function do not accept parameters with cdecl. I tried and the function got corrupted stack.

Eeeeeeeeeeeeeeeha , got it ...It works fine for a naked function , ... ... So it need to be manipulated with naked functions. and naked function will call the actual thing.And to make it toughest we can keep naked functions encrypted in data seg.

Following is the code..

void _declspec (naked) myfunc(void)
{
MessageBox(0,"Hi ","How r you",0);
exit(0);
}


int APIENTRY WinMain(HINSTANCE hInstance,
HINSTANCE hPrevInstance,
LPSTR lpCmdLine,
int nCmdShow)
{
// TODO: Place code here.

void * ptrxx=(void*)myfunc;
__asm{
push ptrxx
ret
}
}

One problem with above code snippet , it's all MyFunc's responsibility to drive the program control , because as MyFunc ends , it will show a great error , because of corrupted stack. Thats why I have called exit(0) in that.

I recommend you guys code the protection schemes in asm directly, using MASM32, and then linking it to your code, since VCPP assembler is very poor.

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.