How to Prevent reverse engineering .NET

  • Thread starter Thread starter sudhakar
  • Start date Start date
S

sudhakar

Is there any way i can prevent reverse engineering in .NET ? Obfuscators
seem to be one solution. But, how can one rely on obfuscators since it
changes the assembly (even though most of them claim that they just rename
the variables) ? Is there any better solutions ?

Thanks
-s
 
Hi,
Is there any way i can prevent reverse engineering in .NET ?
Obfuscators seem to be one solution. But, how can one rely on
obfuscators since it changes the assembly (even though most of them
claim that they just rename the variables) ? Is there any better
solutions ?
Click to expand...

No, there's no other solution afaik ... However, there should be no problem
at all, the final obfuscated application runs, doesn't it? If you change
something in the source code, you just need to obfuscate again ...

Regards,

Frank Eller
www.frankeller.de
 
Obfuscators work by hiding the intent of the internal functions and variables
and setting them up as overloads (rather nasty to reverse engineer, but not
impossible). For obfuscators to be of the most value, your methods will
offload most of their work to internal routines.

Yes, they do change assemblies, but assemblies are made up of byte code,
known as IL, so you effectively make it very hard to reverse engineer, with
very little risk.

---

Gregory A. Beamer
MVP; MCP: +I, SE, SD, DBA

***************************
Think Outside the Box!
***************************
 
The other solution is to use one of the frameworks that encrypts the IL,
which means you incur overhead for decrypting before running. An even better
solution for code safey, but not often worth the hit.


---

Gregory A. Beamer
MVP; MCP: +I, SE, SD, DBA

***************************
Think Outside the Box!
***************************
 
Cowboy (Gregory A. Beamer) - MVP said:
The other solution is to use one of the frameworks that encrypts the
IL, which means you incur overhead for decrypting before running. An
even better solution for code safey, but not often worth the hit.
Click to expand...

And of course if the code is able to decrypt the IL, so can a suitably
dedicated cracker. It's really just security through obscurity unless
you've got an actual *secret* key, and if the code has to be able to
run without external resources, it can't really be secret.
 
Is there any way i can prevent reverse engineering in .NET ?
Obfuscators seem to be one solution. But, how can one rely on
obfuscators since it changes the assembly (even though most of them
claim that they just rename the variables) ? Is there any better
solutions ?

Thanks
-s
Click to expand...

From what I understand (although I've never used code obfuscators myself so
take my advice with a grain of salt) the problems that arise from code
obfuscation result from the more advanced techniques such as control flow
obfuscation (rearranging the code by adding gotos). Changing the names of
variables and procedures should be pretty safe.
 
Adding to Jon's comments:

'Prevention' is a subjection term.

Putting special locks on the doors and windows of your house will discourage
a reasonably large percentage of burglars, but a determined burglar will get
in if he really wants to.

Its' a matter of the 80/20 rule however I feel that with obfuscated code it
would be more like 99/1.

While security is important, overdoing it can easily lead to rendering the
whole thing unusable.
 
Stephany Young said:
Adding to Jon's comments:

'Prevention' is a subjection term.

Putting special locks on the doors and windows of your house will
discourage a reasonably large percentage of burglars, but a determined
burglar will get in if he really wants to.

Its' a matter of the 80/20 rule however I feel that with obfuscated code
it would be more like 99/1.

While security is important, overdoing it can easily lead to rendering the
whole thing unusable.
Click to expand...

As long as you have a scenario where the ciphertext (your obfuscated IL) and
the cleartext (machine instructions for CPU) have to be available on the
machine of the potential attacker, then by definition your code is
crackable. The only way to completely secure the code would be to make the
cleartext unavailable, which would mean that people wouldn't be able to run
your program.

This is in fact the reason that DRM is inherently doomed. It depends on the
attackers not using information installed on their machines.
 
Back
Top