MSIL

  • Thread starter Thread starter Aaron
  • Start date Start date
A

Aaron

I know when you compile a .NET app c# or vb the code is converted to MSIL. I
was just wondering is it 100% reversible? If so, does that mean someone can
steal all your source code just by decopiling the dll or exe?

Aaron
 
It will never be 100% reversible since each compiler may perform different
optimizations and therefore the original high language source cannot be
determined, but in general there are tool which will decompile MSIL code.
There are tools that will allow you to obfuscate the compiled code to make
it more difficult to know what you code is doing.
 
Aaron,

Well, it won't be reversible to the point where you can see the variable
names that you used, but it can be reversed to a great degree. Check out
Reflector by Lutz Roeder for a good example of what is possible.

Hope this helps.
 
* "Aaron said:
I know when you compile a .NET app c# or vb the code is converted to MSIL. I
was just wondering is it 100% reversible? If so, does that mean someone can
steal all your source code just by decopiling the dll or exe?
Click to expand...

Let's say "it's reversible". There are certain tools available to do
that (Anakrino, Reflector, ...).
 
So does this mean that if MS decided to write office 12 in .NET, hackers
would be able to almost reconstruct the entire source code?

Also I found a program that is suppose to convert .net to native code? Can
someone explain the advantage and disadvantage of this?
 
:)

Sunny
So does this mean that if MS decided to write office 12 in .NET, hackers
would be able to almost reconstruct the entire source code?

Also I found a program that is suppose to convert .net to native code? Can
someone explain the advantage and disadvantage of this?
Click to expand...
 
Aaron said:
So does this mean that if MS decided to write office 12 in .NET, hackers
would be able to almost reconstruct the entire source code?
Click to expand...

In theory, yes. Obfustication should go along way, probably far enough.
Complicated obfustication will usually make the work required to decompile
and understand a product high enough that it won't be done. As it stands, I
wouldn't try to decompile a lage standard, unobfusticated assemblyand
understand it completely. The variable names, etc aren't very good. I think
decompilation serves far more to help understand how things work when you
already know basically what they do than it owuld to reconstruct an entire
application.

Grab an obfusticator, compile some .NET app(an OSS one will do), obfusticate
it and then decompile it and see waht you think of the results.
Also I found a program that is suppose to convert .net to native code? Can
someone explain the advantage and disadvantage of this?
Click to expand...

Main advantage is that you don't have to worry about distributing the
framework, assuming you mean one of the native converters that are made for
that purpose., and that there is no startup JIT time(which, IMHO, people
blow out of proportion). I don't know how these products deal with garbage
collection, reflection, etc however, you may also loose metadata.

Disadvantages are generally
1) Security: If there is a serious bug in the .NET framework that opens a
security vulnerability, merely upgrading the framework won't be sufficent,
your application will have to be recompiled with the patched framework so it
has correct code, which means you can't rely on Microsofts update
distribution backbone to get your app patched in this circumstance.
2) Portability: Native code is pretty much stuck to hte processor type it is
working on. I don't know how they work explicitly but it might tie you to a
particular OS as well.
3) Efficency: Native compilation may not be capable of opimizing as well and
won't benifit from new JIT optimizations whenever teh framework is upgraded

This isn't to say that either option is definatly better, just some of the
problems and advantages I could see. Doesn't the site where you found the
program rant about its advantages atleast?
 
There is one thing with code deconstruction or reverse engineering -
practicality. The Computer Science theory views the program as a set of
instruction for Turing machines, theoretically capable of being executed by
a head reading the magnetic tape in both directions. If you go down to
assembly level, you will notice that by large the operations performed are
moving the data, comparing the data and jumping to the different parts of
the program as a result of those moves and comparisons.

So, back to your question - would anyone be able to dis-assemble a large
..NET app? In a nutshell - yes. Would it be practical to do it? Probably no,
unless someone is willing to dedicate months and months of their life to
this project. Plus the incentives are not that great - you have the code
de-constructed, you can look at the methods they employed when writing it,
so what? It's not like there are no free office suites out there.

The same theory goes for encryption. It's possible to break AES and others
by brute force, but when it takes you $10 mln in computer time to achieve
that, would you do that? Probably no. Would NSA do that if it's deeemed a
priority? Probably yes.
 
Those are really wise words :)
The problem is piracy and legal stuff, reverse enginnering is to be
though about by military or others who have BIIIIIIG secrets
 
The local variable names are available in the pdb file if you have
access to it. Our Decompiler.NET product generates code that looks
almost identitical to your original source code including local
variable names when you have the symbol file present with the DLL. You
can download and try it out for FREE from
http://www.junglecreatures.com/

Jonathan Pierce
President
Jungle Creatures, Inc.
http://www.junglecreatures.com/


Nicholas Paldino said:
Aaron,

Well, it won't be reversible to the point where you can see the variable
names that you used, but it can be reversed to a great degree. Check out
Reflector by Lutz Roeder for a good example of what is possible.

Hope this helps.


--
- Nicholas Paldino [.NET/C# MVP]
- (e-mail address removed)

Aaron said:
I know when you compile a .NET app c# or vb the code is converted to MSIL. I
was just wondering is it 100% reversible? If so, does that mean someone can
steal all your source code just by decopiling the dll or exe?

Aaron
Click to expand...
Click to expand...
 
thanks nicholas. i've just started using Reflector and it works really nice
:-). unfortunately Reflector itself does create files but this add-in does:
http://www.denisbauer.com/NETTools/FileDisassembler.aspx

jonathan, I tried your tool but PDB file option did not work. how do i find
PDB files? also, to my big disappointment I noticed that your tool is not
free as you mentioned :-(. it wrote strange messages about buying commercial
version in most of the decompiled files and the code does not compile as it
says.


Jonathan Pierce said:
The local variable names are available in the pdb file if you have
access to it. Our Decompiler.NET product generates code that looks
almost identitical to your original source code including local
variable names when you have the symbol file present with the DLL. You
can download and try it out for FREE from
http://www.junglecreatures.com/

Jonathan Pierce
President
Jungle Creatures, Inc.
http://www.junglecreatures.com/


"Nicholas Paldino [.NET/C# MVP]" <[email protected]> wrote
in message news: said:
Aaron,

Well, it won't be reversible to the point where you can see the variable
names that you used, but it can be reversed to a great degree. Check out
Reflector by Lutz Roeder for a good example of what is possible.

Hope this helps.


--
- Nicholas Paldino [.NET/C# MVP]
- (e-mail address removed)

Aaron said:
I know when you compile a .NET app c# or vb the code is converted to
Click to expand...
MSIL.
I
was just wondering is it 100% reversible? If so, does that mean
Click to expand...
someone
can
steal all your source code just by decopiling the dll or exe?

Aaron
Click to expand...
Click to expand...
Click to expand...
 
Hi Alan,

The pdb file is created when you compile your assembly with debugging
information. It will be created in your bin directory alongside your
dll or exe and is needed to debug assemblies at the source code level.
Our Decompiler.NET product will read these symbol files if present in
order to retain your local variable names in the decompiled code.
Local variable names are not present in the assembly file itself, so
Decompiler.NET generates local variable names based on their type if
the symbol file is not available with the assembly.

The Decompiler.NET product is not free but the evaluation version can
be downloaded for free in order for you to evaluate the product's
capabilities.

The product is priced very low considering that it produces higher
level and more accurate code than the competitors, we provide better
support with free updates, and the product includes full obfuscation
capabilities.

Please make sure that you check often for updated versions of the
product since they are posted often to the web site.

The eval version should still produce code that compiles 100% since it
generates stubs for methods that are being disabled and returns value
values and out parameter values.

If you have an example of output that does not compile, please send it
to me at (e-mail address removed) and I'll address the issue
immediately.

I look forward to your experience evaluating the product.

Jonathan



Alan Morgan said:
thanks nicholas. i've just started using Reflector and it works really nice
:-). unfortunately Reflector itself does create files but this add-in does:
http://www.denisbauer.com/NETTools/FileDisassembler.aspx

jonathan, I tried your tool but PDB file option did not work. how do i find
PDB files? also, to my big disappointment I noticed that your tool is not
free as you mentioned :-(. it wrote strange messages about buying commercial
version in most of the decompiled files and the code does not compile as it
says.


Jonathan Pierce said:
The local variable names are available in the pdb file if you have
access to it. Our Decompiler.NET product generates code that looks
almost identitical to your original source code including local
variable names when you have the symbol file present with the DLL. You
can download and try it out for FREE from
http://www.junglecreatures.com/

Jonathan Pierce
President
Jungle Creatures, Inc.
http://www.junglecreatures.com/


"Nicholas Paldino [.NET/C# MVP]" <[email protected]> wrote
in message news: said:
Aaron,

Well, it won't be reversible to the point where you can see the variable
names that you used, but it can be reversed to a great degree. Check out
Reflector by Lutz Roeder for a good example of what is possible.

Hope this helps.


--
- Nicholas Paldino [.NET/C# MVP]
- (e-mail address removed)

I know when you compile a .NET app c# or vb the code is converted to
Click to expand...
MSIL.
I
was just wondering is it 100% reversible? If so, does that mean
Click to expand...
someone
can
steal all your source code just by decopiling the dll or exe?

Aaron
Click to expand...
Click to expand...
Click to expand...
 
The pdb file is created when you compile your assembly with debugging
information. It will be created in your bin directory alongside your
dll or exe and is needed to debug assemblies at the source code level.
Click to expand...

i can't find any PDB files. sucks.
The product is priced very low considering that it produces higher
Click to expand...

it is bad that you reverse-engineer full source code and make money with it
:-(
The eval version should still produce code that compiles 100% since it
generates stubs for methods that are being disabled and returns value
values and out parameter values.
Click to expand...

the compiler was reporting error with arrays not being valid. unfortunately
i already deleted assembly and uninstalled decompiler.net so i can't tell
what the error was.
 
Alan Morgan said:
i can't find any PDB files. sucks.
Click to expand...
Are you compiling your own code, or trying to decompile someone elses
assembly? People do not normally ship debugging symbol files with the
release version of their product, but you will get a pdb file if you
compile with debugging.
it is bad that you reverse-engineer full source code and make money with it
:-(
Click to expand...

Why? There are may uses for the tool, including obfuscating your own
code, optimizing your code, translating your code across languages,
learning about other implementations, etc. The product serves a
valuable need not filled by the Microsoft provided tools. Believe me,
I have spent over two years developing the product and the income
derived from it does not justify the development effort. I priced it
low intentionally to make it accessible to small developers who need
it, and to encourage customers to consider the other products that we
developing that have not yet been released.
the compiler was reporting error with arrays not being valid. unfortunately
i already deleted assembly and uninstalled decompiler.net so i can't tell
what the error was.
Click to expand...

Why did you delete your test assembly? If you send it to me or tell me
where you got it, I'll be able to reproduce your error. Did you
compile it yourself? What compiler or language was used? Was the
assembly already obfuscated? Obfuscators often deliberately attempt to
prevent code from decompiling with various tricks and overloading
techniques.

Jonathan
 
Alan,

I was able to figure out the issue from your mention of arrays. Thanks
for reporting this. Decompiler.NET generates empty default values for
return values and out parameters in methods where the eval version is
replacing the method body with an empty stub. This allows the stub
methods to still compile correctly. There was a bug that didn't
generate a valid array value for these returned stub method values, so
you were getting errors on stub methods that returned arrays. This has
been fixed in the latest posted version. Please take another look at
the product when you have time and report any issues that you
encounter. We always fix any bugs reported to us as soon as we can
reproduce them and post updated versions immediately. In this case,
you provided enough information to reproduce the issue and the fix was
trivial. We fully test the application each time we ship it but we
don't usually test in evaluation mode so this bug slipped through the
cracks.

Thanks again for reporting it.

Jonathan Pierce
President
Jungle Creatures, Inc.
http://www.junglecreatures.com/
 
Back
Top