reverse engineering

There is an article on this:

Brent Rector, ".NET Obfuscation and Intellectual Property," Windows Developer, pp. 20-25, Aug. 2002

It would be better to confront your boss with this article rather than what is said in this forum.

Quote:

---

Originally posted by alanr
I have not used SoftICE for a long time, I can say that as of 1998 when I quit working for the NSA, there were in-house "rumors" that MS had worked with some of the lead NSA engineers to create a strategy to embedd some of the the debug info into the actual Release version of the .exe. If this actually happened then or more recently, this could in theory, make it possible for the NSA to decompile..... This was a "rumor" I thought it would be interesting to some of the posters here.... Anybody else heard anythign about this....

---

I am not a programmer by formal training, so forgive me if my comment sounds stupid.

I have Visual Studio .NET Enterprise Architect and I only use the Visual C++ component. When my "Release" program crashes under XP, a dialog box pops up with a button labeled "Debug." Pressing that button brings up another box with two choices. (I forget what they are) Pressing the first choice, causes the IDE to find the exact line of C++ code that caused the crash. How is this possible without some debug info in the "Release" program?

If you are interested, I will post images of the dialog boxes.

Browse, debug and/or map file information is being produced.

Debug information can be produced for any build, though it may not be as complete as for debug code. This is useful for tracking Dr. Watson errors.

You can turn all this off in the project property settings.

This pertains to unmanaged code:

Unless the debug information is embedded in the executable (by default it is not in .NET) if you run the application on another computer without any related source, debug (.pdb) or map files present, even if .NET is present, you will only be able to debug in assembly.

Quote:

---

Originally posted by CallMeJoe
Browse, debug and/or map file information is being produced.

Debug information can be produced for any build, though it may not be as complete as for debug code. This is useful for tracking Dr. Watson errors.

You can turn all this off in the project property settings.

This pertains to unmanaged code:

Unless the debug information is embedded in the executable (by default it is not in .NET) if you run the application on another computer without any related source, debug (.pdb) or map files present, even if .NET is present, you will only be able to debug in assembly.

---

Thank you. I will try to locate these on the project properties dialog.

You can always turn off all of the debug information, symbols etc. when you build your project. The .exe will then contain nothing but executable code. While this can still be decompiled, the resulting code will be, more or less, gibberish. All the local variable names will be gone, for example. But with enough effort, someone could, of course, figure out your algorithms.

There are several techniques you can use to fight this, though (If you're really really really that worried about it). For example, you could take a simple loop like:

for (int i=0; i<numThingies;i++)
{
//Do John's amazing wizbang algorithm;
}

and turn it into something like


globals.cpp
.
.
.
double *Theta = malloc(sizeof(double));
Theta=0;

mysource.cpp
.
.
.
extern Theta;

int dummy=14;
int i = numThingies-1;

while (cos(Theta))
{
//do some similarly obfuscated version of John's amazing wizbang algorithm

dummy++ = i--?(Theta=PI+34.782):(dummy=i)
}

I'm going to be a little lazy tonight and not test this piece of code before posting it, but you get the point (I don't remember if you're allowed to do assignments in the selection statement). Given any real world case with even a moderately complex algorithm, a little obsfucation will turn even the best reverse engineering efforts into an absolute nightmare. Also, if they just decide to give up, and just steal the code without figuring it out, it would be pretty simple to demonstrate that they stole your code (an easter egg of sorts).

You can actually get code obsfuscaters, and run your source files through them before you build (they do a much better job than I could ever do in the 2 minutes it's taken to write this e-mail).

My suggestion, though, would be to relax about it. If I *REALLY* wanted to steal someone elses code (not that I ever would, by the way), it would be so much easier to just get a job working at the rival company, or to find some disgruntled engineer and bribe him.

-John

okay...first, I forgot to dereference my Theta's.

next, it SHOULD read

dummy++ = i--?(Theta=PI+34.782) : (dummy=i)

my compiler barfs when it sees emoticons.

lastly, I didn't write an e-mail....I wrote a post.

so, like, can ya' tell I'm new to this?

-John :)

and to top it all off, aruzinsky already mentioned obsfuscation about 5 posts ago.

sheesh...so I'll go sit in the corner now and try to look cool.....quietly...
:cool:
-John

>>I have not used SoftICE for a long time, I can say that as of >>1998 when I quit working for the NSA, there were in->>house "rumors" that MS had worked with some of the lead

are they knocking on your door yet for posting that little tidbit LOL

I have always wondered what would happen if i got off the highway on the nsa private exit ramp LOL

Quote:

---

there were in->>house "rumors" that MS had worked with some of the lead ...

---

Did you forget a piece of your sentence or did the NSA censor this away? ;)

Ok. We have ALOT of people leaving messages here that do not know what they are talking about, and there has consequently been ALOT of errata posted. So let me give some good sources of information to get those looking for the real...

First, this all rests on disassembly of a standard PE file. To understand what this entails, STUDY THE PE FORMAT. There are some real good sources of info on this. Check out Matt Pietrick's (_THE_ Matt Pietrick incarnate) series of articles on MSJ (at microsoft's site). You will soon find that without debug symbol information in the program, there is no way to get the symbols elsewhere. Even NSA can't get them if they are not there, so inspection of a file's PE structure can tell you exactly how much information you can extract. In other words, DON'T MAKE YOUR NAMES HARD TO READ IN SOURCE CODE UNLESS YOU LIKE MAKING YOUR LIFE MORE DIFFICULT. You just end up making furthur devolopment by others in your company hellish.

Second, the symbol information that a disassembler CAN find in a symbol-stripped file is found in the import/export tables. So debuggers like Soft-Ice are often used to first trackdown execution to API calls, then moving on to subsequent actions that may be related. DumpPE will insert these symbols for you (its a PE viewer / disassembler that comes with masm). This is important if you want to obfuscate. But there are better methods. Several have posted already the two most important anti-cracking methods: polymorphic code, and dynamically encrypted/decrypted code. Coupled with checksumming/hashing of run code and disabling of breakpoint/debug APIs (possible through API interception or interrupt handling at the kernel level), you can make code theoretically as difficult to crack as, say, factoring a large two-prime product (ie. you CAN make theoretical time to crack important code areas in the hundreds of years...)

But this requires you get down and learn assembly. Writing in Visual C++ leaves your code quite easy to interpret (some have said it is hard, but that is not at all true unless you don't know assembly, which is like saying a C++ source is hard to read if you don't know C++). Functions are still separated into blocks in the exact same order that the original C++ functions were written (compile-order for multiple file projects). Each c++ function call has a standard c++ calling pattern that lets you decipher byte size of arguments. Again Matt Pietrick has some great MSJ articles on just this topic. And this does NOT take days of work figuring out. So if you REALLY have sensitive code, you can code the skeleton app in VC++, but you need to learn assembly and fixup your code, shuffling around the assembly and building rewrite routines and encrypters/decrypters to actually get any security.

One last comment. Many people disassemble Windows all the time. To many, its a hobby. Its the only way you'll find out how to use the undocumented APIs of Windows and (since disassemblers of Word and other Microsoft software noticed that these programs often use undocumented APIs) it is one of the strongest parts of the antitrust case against microsoft.

Quote:

---

One last comment. Many people disassemble Windows all the time. To many, its a hobby. Its the only way you'll find out how to use the undocumented APIs of Windows and (since disassemblers of Word and other Microsoft software noticed that these programs often use undocumented APIs) it is one of the strongest parts of the antitrust case against microsoft.

---

Very good point galathaea :) Its good you joined us on discussion with such worthy comment !

Interesing idea.

People have learnt how to defend their homes, but we didn't yer learn how to defend computer software. This is because we live in homes since our origin, but have been creating software for our computers during only last decade. Which is approx 0.01% of our civilisations age. And this discussion reminds of bunch of cavemen (count me in ;) trying to create a fence for the neighbouring tribe but so far only having made one - for ourselves (barely). And hackers appear as bunch of cavemen from north, having heard there is some fresh meat for winter in the caves.

Give this time gentlemen, time ! ;)

With time we will learn to defend our software just as good as our homes.

I just reread my post and realized some of it sounded kind of snotty, and I don't really have the position to sound snotty. I just got into disassembly for the same reasons as the original point of this thread and I am still learning. I just got irked when I saw some points made by people stating as FACT what was really just conjecture. Much of the information I have learned about this important field was derived from going to hacker/cracker sites and reading articles on MSJ (now MSDN Magazine). I always found it unusual that Microsoft gives very little information on how their system works, sticking mainly with a "here's what to do, you don't need to know about anything else" attitude, whereas hacker/crackers are some of the only ones out there giving the detailed "here's whats really going on" info. There ARE those (Solomon/Russinovich, Schreiber, Pietrek, Richter, et al.) in the "mainstream" that are answering these important questions, and much University research on the particulars of security, etc. against RE, but still...

I am sorry I entered this thread too late to point out that Soft-ICE is not the only kernel level debugger available to those wanting to get started. Microsoft includes a pair of fairly good KDs in its Win2000 Device Driver Kit, but these were only available for free until the end of September. Such is the will of MS. Soft-ICE, though the defacto BEST, is not cheap.

But, it is important to note that the defeatest attitudes of some of the posts is as wrong as some of the "disassembly can be done, but not by mortals" posts. It is important to know the facts, so that in the business world we can take the actions needed to protect our intellectual property. Protection does not mean merely stripping our files of symbols, but that is the first step. Other methods are available to truly protect ourselves.

Also, it is important to point out that in Network environments, other methods have been used for security, such as splitting up a program into DLLs and Services located on several computers and using verifications... This is truly a burgeoning (sp?) field.

Excellent Point galathaea! Bravo....

I think it is obvious that you have the source code if looking at a debug version. But creating a release version usually removes all the source. You could this test by simply searching for one of your variable names within the exe file.
Further in most cases the exe will be smaller than the source code.
If you could get the source from any exe Microsoft would either try to hire you or have you arrested ;-)