decompile

C

Cralis

Hi guys,

Is there a way to stop, or make it very difficult for someone to use
reflection, and decompile a forms application?
 
J

Jason Keats

Cralis said:
Hi guys,

Is there a way to stop, or make it very difficult for someone to use
reflection, and decompile a forms application?

Reflection is not used to decompile applications - it's a mechanism to
discover methods and, perhaps, modify data at run time.

Reflector is an example of a product that can be used to decompile your
application...

http://www.red-gate.com/products/reflector/index.htm

It works like this:
http://www.simple-talk.com/dotnet/.net-tools/.net-reflector-soup-to-nuts/

The .NET obfuscator you choose should (at least) stop Reflector from
working.
 
J

Jeff Johnson

Reflection is not used to decompile applications - it's a mechanism to
discover methods and, perhaps, modify data at run time.

Reflector is an example of a product that can be used to decompile your
application...

http://www.red-gate.com/products/reflector/index.htm

It works like this:
http://www.simple-talk.com/dotnet/.net-tools/.net-reflector-soup-to-nuts/

The .NET obfuscator you choose should (at least) stop Reflector from
working.

Really? "Stop it from working?" I thought the point of obfuscation was to
produce code that was ridiculously hard to read, so even though you can
decompile it (i.e., Reflector will still "work"), what you get back will be
very hard to understand. The key is "very hard." With enough effort anyone
should be able to understand what your code is doing, if not the original
way it was written. (And yes, with enough effort you can understand what any
executable code is doing, but I have a feeling obfuscated code is still
easier to understand than assembler.)
 
A

Arne Vajhøj

Is there a way to stop, or make it very difficult for someone to use
reflection, and decompile a forms application?

There are several available.

Jason has posted a link to a page that lists
some of the many options.

But is it worth the effort?

If it is just general code, then reimplementing from scratch
based on required functionality is usually faster than
decompiling and customizing code without design documentation,
comments in code, local variable names and the information
in the programmers heads.

If it is some critical code like license scheme, then experience
shows that they get cracked even when using obfuscation (assuming
that the software being protected is good enough to make it
interesting).

Arne
 
A

Arne Vajhøj

Really? "Stop it from working?" I thought the point of obfuscation was to
produce code that was ridiculously hard to read, so even though you can
decompile it (i.e., Reflector will still "work"), what you get back will be
very hard to understand. The key is "very hard."

Reflector is a pretty good tool, so I will assume that it can
decompile any output from the C# and VB.NET compilers.

But that does not necesarrily mean that it can decompile
any valid MSIL.

Arne
 
A

Arne Vajhøj

And as if that weren't enough, there is a fundamental logical flaw in
the entire concept of obfuscation: assuming it takes X amount of effort
to copy protect your code (through obfuscation or other means), and it
takes Y amount of effort to break that copy protection, and the value to
you and a hacker of your copy-protected code is Z, then the only way to
ensure it's not worth Y to a hacker to get Z is for X to be more than
it's worth to protect Z.

I don't understand that argument.

Why should Y>Z imply that X>Z ?

Arne
 
A

Arne Vajhøj

First, it's important to keep in mind that I am not trying to put forth
a mathematically rigorous argument. The use of variables is just a way
to try to concisely describe what I'm trying to say.

That out of the way, the point is this: the code has a certain value to
the author (with respect to protecting it) and the hacker (with respect
to defeating the protection), and to a first approximation we can assume
the value is the same for both parties (i.e. "Z").

Making that assumption, it's clear that to invest enough to protect the
code well enough that a hacker won't want to bother, one has to invest
more in protecting the code than the value of protecting it is to the
author.

Basically, if you've put enough effort into the protection to stop a
hacker, you've put more effort into the protection than can be justified
by the value of the protection. The hacker always wins (especially since
the author has to protect against all hackers, but the hacker only has
to break through the protection once).

It does not make any sense at all.

Your argument does only make sense if X=Y. And that sounds
very unlikely.

Let me use an analogy in data transport. I need to send some
secure data that is worth 1 million dollar. Now I spend 10 cent
of CPU time on AES encrypting the data. And it will cost the
hacker a billion dollar is CPU time to brute force crack it.
Good idea to encrypt.

Arne
 
A

Arne Vajhøj

I would be very surprised if it couldn't. It does, after all, have an IL
display option, and it's easier to decompile to IL than to one of the
higher-level languages.

It can per definition disassemble to IL.

The question is whether it can decompile to C#/VB.NET.

I don't know about MSIL, but for Java byte code the obfuscator
writers has created some nasty manipulations.

Try look at:
http://www.sable.mcgill.ca/publications/techreports/sable-tr-2006-5.pdf
section 6.8 !

Arne

PS: Note that I don't consider obfuscation efficient for the securing
information embedded in the code - I am just skeptical about whether
Reflector or similar tools can decompile all valid MSIL to
C#/VB.NET!
 
A

Arne Vajhøj

Arne said:
[...]
Basically, if you've put enough effort into the protection to stop a
hacker, you've put more effort into the protection than can be justified
by the value of the protection. The hacker always wins (especially since
the author has to protect against all hackers, but the hacker only has
to break through the protection once).

It does not make any sense at all.

Your argument does only make sense if X=Y. And that sounds
very unlikely.

Did you bother to read my comment pointing out that I am not trying to
put forth a mathematically rigorous argument?

Just replace the mathematical formulation with English text.

Your statement does still not make any sense.

It is logical flawed not just mathematical flawed.
Your framing as a
mathematically rigorous equation of my comments is a straw-man.

No. It is the exact equivalent. It is just easier and more
precise to describe problems mathematically.
That said, I find it reasonably likely (as I said, to a first
approximation). There are a number of hidden costs to copy-protection,
even on top of the basic cost of implementation. These include increased
difficulty of debugging (especially if obfuscation is part of the
solution, as I already mentioned) and pissing off customers.

At the same time, a single hacker can render all of your efforts moot.
The vast majority of users of the software that are taking advantage of
the hacked version have a nominal cost of zero. If you compare to the
inconvenience suffered by paying customers who have to deal with the
barriers copy-protection creates, the users of the hacked version
actually come out ahead.

That is a completely different argument.

Which I BTW agree with.
Encryption doesn't do any good when the key is on the client's computer.
It's not a very apt analogy. In fact, if anything it's a good example of
the superior solution I suggested: don't give anyone you don't trust
access to the code in the first place. That approach is much more
analogous to your encryption scenario than obfuscation is.

You are completely missing the point.

We have:
- a cost to protect
- a cost to break protection
- a value

And the point is only the relation between those 3 numbers.

The same relation as in this example could certainly exist
for obfuscation.
Still, you are welcome to your opinion. If you want to waste time
copy-protecting your software, please feel free.

If you read my posts as if I am recommending obfuscation, then
one of us need to improve in English !!!!

Arne
 
A

Arne Vajhøj

Ah. I see what you mean. No, I think it's practically guaranteed that it
can't decompile arbitrary IL back to C# or VB.NET. After all, neither
language is a complete implementation of the features in IL.

But it is not necessary to see C# or VB.NET to divine the secrets of
obfuscated code. :)

True.

I think it is a terminology question, I use:
decompile = to C#/VB.NET source
disassmble = to IL source

Arne
 
Joined
Nov 21, 2009
Messages
79
Reaction score
0
You can never completely stop but you can make it reasonably difficult by using an obfuscator like Crypto Obfuscator. In the end you want maximum protection with minimum hassle.
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Top