.NET assembly

[George]

Hi.
I know that in JAVA it's possible to decompile a .class file to get the
original code. There are applications called obfuscator (or sth similar)
that tries to avoid it.
My question is: Is it the same for .NET? How can I avoid getting the source
code from an exe I compile?

TA

 

[Jon Skeet [C# MVP]]

I know that in JAVA it's possible to decompile a .class file to get the
original code. There are applications called obfuscator (or sth similar)
that tries to avoid it.
My question is: Is it the same for .NET? How can I avoid getting the source
code from an exe I compile?

Yes, it's exactly the same situation.

See http://www.pobox.com/~skeet/csharp/faq/#obfuscation

 

[Miha Markic [MVP C#]]

Hi George,

Yup, the same.
See the link for available obfuscators:

 

[Miha Markic [MVP C#]]

Link
http://msdn.microsoft.com/vcsharp/team/tools/default.aspx

 

[George]

Thanxs for the answers.

But still have one thing to say. I've taking a look to the pages you have
referred, and as you said it's like in Java.

Then if using an obfuscator and a decompiler from the same company,
couldn't it result in having the original code? As the modifications made
on the obfuscation step is known by the decompiler, then it's possible to
get the source back?

I know that that's it's not going to be the general case, but I'm just
thinking aloud

 

[Cor]

Hi George,

It will always be possible to decompile, the only question can be how
difficult is it to do that.

As I always write on this answer, in short past there was somebody active in
this newsgroups who said, I do not need an obfuscator, after some weeks I
cannot read my own programs.

Just a thought

Cor

 

[Jon Skeet [C# MVP]]

Then if using an obfuscator and a decompiler from the same company,
couldn't it result in having the original code? As the modifications made
on the obfuscation step is known by the decompiler, then it's possible to
get the source back?

No, almost certainly not. Obfuscators almost always lose information
(deliberately). They would, for instance, convert several methods with
different names into one hugely overloaded method with a name such as
"A". You might be able to generate a map at obfuscation time so you
know what meant what (a good obfuscator will do this, certainly) but
that information will no longer be present in the assembly.

 

[Valery Pryamikov]

Hi,

No decompiler could produce original program text. even without protecting
program with obfuscators, all comments, program formatting and local
variable names will be missing from decompiled program.

And obfuscation could be done on many different levels.

Note: I have never worked with any of the obfuscators and so, my knowledge
of obfuscation technologies is pure theoretical - mostly my own musings
about what could be done by obfuscators, so be warned before you read the
rest of this mail .

Few years ago I had some thinking about obfuscators as technology got some
ideas. I sent an e-mail to the developmentor's .Net mailing list with idea
for obfuscator. Main idea was an attempt to build analogy between program
execution tree and (parser) grammar tree and I suggested that it should be
possible to use technique similar to one invented with LARL parsers that
flattens the tree into LARL-tables driven function that is analogous with
the original program. I got an answer from Microsoft program manager who was
working with their obfuscator's prototype at the time where he said that it
is a known technique in obfuscator's research. However if you think of that
kind of obfuscation in addition to the standard metadata mangling that is
used in all existing obfuscators, than any attempt to decompile program
would result in code that will be extremely difficult to analyze and
completely different from original (program structure). I believe that
following addition could be done to that obfuscator type that can really
make them being "cryptographically" strong:

if (in simple words) obfuscator would add many more alternative execution
paths to these LARL-tables so that program can randomly choose one of them
depending on some runtime criteria, then debugging of such program will be
made extremely complicated because the same breakpoints could be never hit
on the next program run even with the same program's input data. But that's
just my fantasy...



-Valery





See my blog at:

http://www.harper.no/valery