reverse engineering

I think the term "hacker" has many definitions. See What Is a Hacker? for more.

So what is "internet code"? If it is not software then it must be hardware, or is it a third category that I have not heard of?

We've had this conversation before with the same misconceptions. You CANNOT get the exact C or C++ code back.
Unless you ship debug code :) Once the exe has been stripped, the names of the variables are gone.

With SoftICE or Windows DASM you can get the assembly instructions.

The cracking groups I've watched don't necessarily use SoftICE. WDASM32 works better since you don't have to run a detectable service in the background.

You can make the assembly more obscure but you can't 100% protect from disassembling.

Hi,
Fasinated by your discussion, .net suddenly flash in my head, CLR, which is java runtime of MS, looks very probable to render any code you write under .net platform visible to everybody.
May be compling into local binary will avoid this but at the cost of losing .net flexibility.
Please tell me I am wrong.
Thanks.

My flatm8 has softice on CD - I have recently lost the cource to a project from the harddisk blowing up so I'll bring it in 2mm and:
a) 'decompile' my executable (not much hope but who knows)
and b) try out the above code to see if it detects softice running and exit out of the initinstance. I agree with Paul it's all scare-stories, but if he wants to decompile AutoCad I don't see why I can't decompile Combustion....if ever a software company was greedier than MS its gotta be discreet *(discreet, ha ha - good name ...AND they're owned by AutoCad!)
wish me luck!
Dwiz

Theres hundreds of decompilers out there, and no way to stop them all. If you have a good knowledge of how assembly maps to machine code, then you could write one pretty easily. Then once you have the assembly version then you can use common sense to convert to the language you wanted.

The only things that are lost are function names (which are replaced with memory offsets) and variables (which are replaced with processor register names).

Theres no real way to protect from decompilers; if the computer can "understand" your program, then so can a decompiler.

It's sure that hacker can anyway come to know much about working but never 100%.

There is a very good way to ptotect your sensitive algorithms..

You can write these imp. functions to a DLL ,then encrypt it and copy whole DLL at end of your exe ,or somewhere else in your executable program.
Run time allocate Executable Memory pages and decrypt the functions from DLL there. Dont write independant function in that DLL. Try writing some assembly code at run time into these decrypted function.this will ensure that if somebody else knows to decrypt it then also he wont be able run it.


try antidebugging trics......

To know about antidebugging tips

see
www.anticracking.de
www.absolutelock.de

Kishnaa,

This does help a bit, but there are tools that let you inspect the memory, and hence would get to your DLL code anyways, just after you decypted it :/

There is no way to stop crackers, there are only ways to make it hard for them to accomplish their task.

Sometimes a simple method will confound the average cracker enough to make him abandon your program. The best protection against cracking is :
1) Use some anti-cracking techniques
2) Release frequent updates and make old code unavailable so that patches never work for more than 1 month.

AFAIK our program was cracked only once. Strangely enough, afterwards we got a bunch of emails from hotmail et al. asking us to make build X.Y.Z available again. ;)

I agree with you Yves M.

Thats what I think , we can certainly make our code harder to understand.

If you think you will find many ways to do it.
A program can be polymorphic in that way.

But still nobody can stop the Hackers from doing what they want ...

:)

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....

One bit of advice; before anyone goes charging off trying to defeat "crackers", make sure that your compiled code is genuinely worth protecting.

(And make sure your workstations and source control servers are secure. Novell is paranoid about their code, but when I worked there in the early 90s, several times, for several months one time, their entire network was open to the world--if you correctly guessed a developers username and password--not difficult--you would have had access to all of Novell's source code.)

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 ;-)

I agree with Paul, I've also used Soft Ice since it's 16 bit release and there isn't any way that you can get your c++ source code back. The debug mode for Visual c++ is however able to display more info than a release version but when a release version is build the debug data is removed.

So Soft Ice is not capable of translating an exe back to it's source code.

As some of the people mentioned, hackers is only interested in some pattern but most of the time they look for jmp routines in assembly and they might just change the JE(jump if equal) to JNE (jump if not equal) to bypass copy protection depending of course on the copy protection that is used.

Got to agree that you cannot get the exact source code back. There is only one program I know of that will get you back c++ code from asm and even then although its accurate and gives good results, its not perfect and won't be anywhere near exact.

In Replay to:
You can, in fact, totally reverse-engineer an exectuable into its original C++ source code

who is this kbomb987?
are u a programmer??
&who told u that u can totally reverse-engineer an exectuable into its original C++ source code??

Getting back ur C/C++ code form a EXE is highly impossible thing.

I am totaly agrre with Paul McKenzie Its not JAVA

cmp xx xx
jmp xxxx

from above code nobody can tell which variable is involved or its coming due to if/else statement or for statement or switch statement

So dont worry abt guys nobody can get ur original C++ source code.

Using Soft-Ice u can put break point on system functions deep into the OS kernel.
but everything get in Soft-Ice is in Assembly code so to hack ur EXE using Soft-Ice one should very very strong in Assembly language.
so somebody is very very good in assembly, forget about protecting ur code using functions like IsSoftIce().. its lame protection he/she can esaily get rid of this function

Vinod

the people who thought it possible to get back c++ code make me laugh.
First of all i doubt the even know what the **** an exe is...it's freakin 0's and 1's people, it doesn't run from source, there is no source, the source doesn't come with the program, the source isn't encoded in the bits anywhere.
You can make the bits to assembly because there is an exact realationship between the bitwise words and assembly commands, the processor can handle assembly codes (not c/c++). There is no way of saying "oh gee, these lines of assembly code mean this, so i'll have my program say it's this function...hmmm i'll call it softice". It doesn't work that way. And in response to those who say it does, i ask, why would you BS someone who's asking for help? Show some class.

If the cracker is to crack the s/w by modifying the s/w to 'jump' past the registration code, how would that be possible with anti-virus s/w around, as anti-virus s/w will prohibit any s/w from modifying an exe file.

Anyone knows?

But this isnt an antivirus programs work to watch for cracking programs..thats not illegel activity.
Still you can do it ,but you need to know exactly how the exe modification will be done ,how many ways somebody can do it..
You need to Hook API's for debugging and Creating .opening and read ,write File.There you need to identify the operation going on.
This isnt any simple case to program..And finaly you wont be able to lock all the ways of doing it..Never..

An interesting discussion this has been, and its dragged on for quite a while. Just thought id add my piece for the why two kay and three.

Firstly, get it right.. crackers are software reverse engineers, not hackers.

Secondly.. its physically impossible to get back your original source code using a tool such as softice. It is merely a debugger, and displays, registers and memory. It will show the stepping of the app running in ASM, and allow breakpoints to be set on various API. Granted some tools will reverse engineer your pe file back into source, but alot is lost in the process including function names and variables (as they are reallocated into address spaces). Why is this tool allowed to exist?? I guarantee you can do all that you need to 'crack' an application using MSDEV itself! Ever had the 'debug' application window popup, followed by an ASM dump?

Firstly, dont blame the crackers saying they are evil people, theyre not.. they are merely 'debugging' your code. Whats so illegal about stepping through the memory of the computer that they own? Cracking isnt illegal at all.. distributing cracks is however. Secondly as a programmer you should be 'debugging' your applications aswell. They are merely software engineers with an interest in what is actually going on under the hood! Believe me the majority of the old schoolers probably couldnt write a line of c++ code in their lives, however they certainly can tell you what your program is doing to a greater level of degree than even the majority of authors could these days.

So.. if you want some advice on security.. packing can help, change your pe headers/section headers to keep out the newbies. Dont bother with softice tricks, frogsice can disable them in seconds, failing that sice will do it itself with a few interrupt changes. I wouldnt bother packing too much though, as somewhere in memory it has to be unpacked, and sice can easily dump memory allowing you to rebuild the unpacked pe. Thirdly, dont bother spending hours and hours with some mad encyption routine that even a nasa scientist couldnt follow. Crackers dont care, they wont step through your entire code.. they will dump the section of code at the correct entry point and recompile it into an ASM application to make a keygen.

Next, why not actually ask the crackers? talk to them.. find out theyre worst hates when cracking...Ive managed to recognise several of them in this forum already.

The obvious solution is in the demo version remove code.. you cant crack what isnt there, but whatever you do.. you will never be able to make it impossible.. believe me.

Quote:

---

why not actually ask the crackers? talk to them.. find out theyre worst hates when cracking

---

Visual Basic =) it is 99% pure garbage :D

do you crack software Bengi ?

I would actually love to have a conversation with somebody who's into this. I once found a website in Spanish which used my application as a tutorial for cracking software. It showed step-by-step what you had to do to patch it. I was quite impressed to be honest. I had no security in place, so it was no surprise that it had been cracked, I was just impressed that somebody bothered to do it. And they used it as an example :)

I've tightened it up a lot since, but i guess you can probably still crack it ?

Let's have a chat ...

VB Program realy contain 40 % not required code. Looping via wrappers :( .

I actually enjoy messing with VB, although hated by most. Just load the app into numega smartcheck (same people who made softice), make sure your using the correct options and you step through it without any problems.

I once went into a c++ channel on irc, i was actually booted out because i was also op in a different reverse engineering channel. Their reason, because they didnt want reverse engineers hanging around and working out the methods the coders were using to protect their software. Im sorry but that is just being arrogant.. you will learn far more from a reverse enginerr IMHO than another coder... not to mention the fact the majority certainly dont need to know the coders source code as they operate at a much lower level language and can figure it out themselves, probably with a greater understanding.

My other point is.. sure i program software, sure ive reversed some software, obviously therefore i have run a crack in the past that i have written (dont get me wrong, its nothing to boast about), sure my software was used as a tutorial app by TNT and also WKT cracking groups, but do i complain? **** NO.. its the biggest free advertising campaign you can ever hope to achieve for your software. Just update it slightly afterwards and youll get thousands of hits to no effect. Not to mention like jase says.. if you were remotely professional about programming you would be interested as to what they did and how they did it.

Considered lame? Well.. whos the lame one.. the guy sitting there messing around with the internals of a pc (of which im taught todo at in my computer science degree) or the guy who downloads shareware and then uses a crack rather than paying for it. The evil ones are the 12 year old kids who use cracks, not the crackers themselves. I purchase all my software that i deem fit. If it dont, i dont use it. Simple. Make your software that good that people believe you simply deserve the money. I guarantee that you will never keep up with the reverse engineers. Just search a dupe site and you will find that on average 50+ applications are cracked A DAY!

Soo...

main:
pusha
push eax, arrogance
push ecx, coders_attitude
cmp eax, ecx
jmp bad_boi ; // Unconditional jump covers 99% of coders ;)
jmp exit

bad_boi:
push 0
push 0
push "Oh dear.. you loose"
call messsgebox

exit:
popa

It seems you are into daily bussiness of cracking !

But I think cracking any software esp. which is counting days or asking serial number are toooooooooooo easy to crack , the chalenge is to reverse engineer the logic/working of a software.

Everybody must agree , that today you will find crores of crackes , I dont include all of them in reverse engineer's cast.
Today a reverse engineer should be able to reverse engineer the program logic tooo. Setting the unconditional jmp is the thing of last era.

What do you say ?

Firstly, nope im not on a daily cracking fest... just interested in peoples views.

In terms of understanding the logic I agree entirely. That is my point... trying to find out EXACTLY what a program is doing. It should be standard as part of any coders development stages. How are you sposed to code anything if you dont understand the building blocks?

Im sure that many of you in the commercial world have had source code thrown at them written by another developer and been asked to modify it. Is that not, on a level, reverse engineering? You must first understand what it is doing, and then build on it from there. Cracking is the same form.. only its done from bytes in memory or dissasemblies on disk at a lower level.

And yep your right again with changing a jump point being a thing of the past... unless it was 'metaphorically' coded in the past, which lets face it occurs all too often.

Then like all good things in life its used and abused by the irresponsible because its deemed 'cool'.

zebbedi

Interesting views zeb, and I can't find much fault with what you say. However, when i'm given somebody elses project to maintain, after I've figured how it works and have applied the update or fix, I don't then make the application available for the rest of the world to download for free, while my company sells the software on to it's rightful client.

Reverse engineering is one thing, and something i'm completely cool about. It's publishing the resulting crack/patch that's damaging.

I have a mixed view. I firmly believe that the person who will look for a crack for your software, rather than pay for it, would most likely never had paid for it if a crack didn't exist. And these people are in the minority. The majority are happy to pay you, if your software provides them with some value and is sensibly priced. Overly high expectations on the value of your software is just an incentive for users to search for a crack.

Lastly, I would advise developers who have published software on the internet to regularly look for cracks. Regularly search for cracks in google. If you find them, you need to update your wares. Another good idea is to learn how to use irc. You'll be amazed what you can download from warez channels. And again, once you've found the crack you're in a position to do something about it.

Don't complain, take it as a complement and be proactive in addressing it.

Right , Reverse engg. has got wide defination.

According to me once we purchase a software we have total control over the assembly code, we can read the EXEutable in any way , because running a program is just reading the assmbly and executing it.

I disagree with you entirely Krishnaa.

1) We're not talking about cracking software which you have bought. After all, why would you bother if you have legitimatley purchased it ? We both know that the software is downloaded for free evaluation, and it is then cracked. So your point is nonsense really.

2) The End User Licence Agreement, if worth it's salt, will specifically deny the user the right to reverse engineer the software in any way. In which case, you are breaking the law as per the eula and can be prosecuted. This is taking it to the extreme, and most likely only big companies would attempt to take such action. However, it remains a fact.

Again i will say that i don't personally have much of a problem with reverse engineering. It's part of the modern-day software lifecycle. You should be continually monitoring your applications presence on the web, and updating appropriately.

I know that , But I dont like that rule .

Above sentense is what my opinion about the software we purchased. We should have complete rights over that , this is what I want to say.

It's not a question of what you LIKE, my friend, it's a question of what RIGHT and whats LEGAL.

You agree to be legally bound by certain conditions when you install the software. If you don't LIKE them, don't install it ...

That is what i want to say ...

No no no jase , here discussion mean wwe can talk about our own opinion , see the thread completly it's about the opinions of people.

Quote:

---

Originally posted by jase jennings
It's not a question of what you LIKE, my friend, it's a question of what RIGHT and whats LEGAL. You agree to be legally bound by certain conditions when you install the software. If you don't LIKE them, don't install it ... That is what i want to say ...

---

Quote:

---

Originally posted by jase jennings
2) The End User Licence Agreement, if worth it's salt, will specifically deny the user the right to reverse engineer the software in any way. In which case, you are breaking the law as per the eula and can be prosecuted. This is taking it to the extreme, and most likely only big companies would attempt to take such action. However, it remains a fact.

---

About legality, I have my questions on the specification that the user is denied of reverse engineering. I would have to look this up in the course I had about industrial law, but I think reverse engineering was specifically not forbidden in the law in order to stimulate competition and concurrence. Maybe someone who knows more about this could enlighten us about this. I don't have my little law book at hand.

This is what MS says.

a. Limitations on Reverse Engineering, Decompilation, and Disassembly. You may not reverse engineer, decompile, or disassemble the SOFTWARE PRODUCT, except and only to the extent that such activity is expressly permitted by applicable law notwithstanding this limitation.

b. Separation of Components. The SOFTWARE PRODUCT is licensed as a single product. Its component parts may not be separated for use on more than one computer.

c. Rental. You may not rent, lease, or lend the SOFTWARE PRODUCT.

d. Support Services. Microsoft provides no support for this SOFTWARE PRODUCT.

e. Software Transfer. You may permanently transfer all of your rights under this EULA, provided you retain no copies, you transfer all of the SOFTWARE PRODUCT (including all component parts, the media and printed materials, any upgrades, this EULA, and, if applicable, the Certificate of Authenticity), and the recipient agrees to the terms of this EULA. If the SOFTWARE PRODUCT is an upgrade, any transfer must include all prior versions of the SOFTWARE PRODUCT.

Quote:

---

Originally posted by Krishnaa
No no no jase , here discussion mean wwe can talk about our own opinion , see the thread completly it's about the opinions of people.

---

Sure, you have the right to hold an opinion, and I have the right to think it stinks.

That's all ...

I have actually looked this up before, and even though they state you arent permitted under their UELA or usage rights or whatever to reverse engineer, its not legally binding.. its just made up mumbo jumbo, as you cant put a restriction on manipulating bytes within memory.

You can however sue the **** out of someone if they were to patch your code and then re-sell it or distribute it. Hence cracking is legal, distribution is not.

Just if you want to read on the legal issues of the subject.. you can do so here:

http://www.woodmann.com/fravia/legal.htm

Quote:

---

Originally posted by zebbedi
I have actually looked this up before, and even though they state you arent permitted under their UELA or usage rights or whatever to reverse engineer, its not legally binding.. its just made up mumbo jumbo, as you cant put a restriction on manipulating bytes within memory.

---

I thought so.

Quote:

---

Originally posted by zebbedi
You can however sue the **** out of someone if they were to patch your code and then re-sell it or distribute it. Hence cracking is legal, distribution is not.

---

I think you can resell and distribute code that is reverse engineered, but probably not indeed the original code. You have to be able to show documents, a paper trail that proves you have analysed the code, know what it does and have not simply used copy and paste. At least that is how much I remember from the classes I had.