Can C# be compiled into machine language?

  • Thread starter Thread starter Reshat Sabiq
  • Start date Start date
R

Reshat Sabiq

Hi,

I'm currently doing most of my development in Java. The
only reason i'm considering alternatives is because Java
is decompilable, and thus one's source code is
unprotected for the most part when shipped as a desktop
app (obfuscation is good, but i'd like it to be more
secure). Thus, i'm considering alternatives for Desktop
apps.
Do i understand correctly that C# .NET can always be
decompiled, like Java? Or is there an option to compile
even C# into pure machine language? That will be losing
the advantages of Managed code, but i just wonder about
flexibilities of compiling C# into managed or unmanaged
code upon choice.

P.S. I also came across news that MS considers providing
some kind of encryption support for .NET. If that's true,
will that be strong enough to ensure code confidentiality
for managed code?

Thanks,
rs.
 
Hi,

Reshat Sabiq said:
Hi,

I'm currently doing most of my development in Java. The
only reason i'm considering alternatives is because Java
is decompilable, and thus one's source code is
unprotected for the most part when shipped as a desktop
app (obfuscation is good, but i'd like it to be more
secure). Thus, i'm considering alternatives for Desktop
apps.
Do i understand correctly that C# .NET can always be
decompiled, like Java?
Click to expand...

Yup, unless obfuscated - like java.

Or is there an option to compile
even C# into pure machine language? That will be losing
the advantages of Managed code, but i just wonder about
flexibilities of compiling C# into managed or unmanaged
code upon choice.
Click to expand...

There is ngen utility which precompiles. Though the il code is still there
and framework is still required.
P.S. I also came across news that MS considers providing
some kind of encryption support for .NET. If that's true,
will that be strong enough to ensure code confidentiality
for managed code?
Click to expand...

The only solution is to obfuscate the code - there are some 3rd parites plus
one stripped down is shipped with vs.net 2003.
 
There is one more possible solution that may fit the OP's needs:
http://www.remotesoft.com/linker/

From this site:
Salamander .NET Linker and mini-deployment tool allows you to link .NET
assemblies together into a single file, and to deploy your application
without installation of the whole Microsoft .NET Framework. The linker links
MSIL code on demand putting together only the required classes and methods,
and it is capable of linking into the Microsoft .NET framework class
libraries. The mini-deployment tool then builds a minimum set of the
Microsoft .NET runtime to ship with your application. This usually results
in installation size of a few mega bytes, rather than tens of mega bytes,
and the installation takes much less time without rebooting machines.

Code Protection

There is one problem none of the current obfuscators address, that is, no
matter how good the obfuscation is, there are system library calls and other
external references scattered over in your code (see red in below). Since
these calls are external references, obfuscators will have to leave them
unchanged. However, these references help a lot to understand the decompiled
code, because they are well documented and public APIs. The linker removes
or reduces such public APIs by linking the framework APIs into your own
code, and thus makes your code much more difficult to decompile after
obfuscation. Below shows sample MSIL code before and after the linker is
used.
 
In addition, I hope everyone understands that machine language CAN be
reverse-engineered. In fact machine language is very much like byte code,
and there are tools out there that take PEs and give you readable code back.
The issue is that machine code is mixed with headers and literal data (not
in a nice standardized way like .NET or Java), so you have to look at how
the compiler put the stuff together. However, compilers are predictable. If
I know a piece of executable code came from VC++ or Borland C++, then I can
remove a lot of the mystery about where the data stops and the code begins.
Once you know that, it's only marginally more difficult to reverse-engineer
those binaries than it is for .NET or Java.

If you want something more secure, you can take your .NET code and write the
important bits in a .NET DLL rather than the main assembly. Then, encrypt
the DLL using a symmetric cypher with a key derrived from the signed main
assembly (so the key isn't present) and create a digest for it. If you want
to create something a little more concrete, you can also derrive the key
from certificates you issue, and ensure that the certs are valid. To run the
code, the main assembly has to derrive the exact key, and unencrypt the DLL
into a buffer. You can then load the assembly from the decrypted byte
buffer.

This basically stops people from examining the contents of the file. You
could never run ILDASM on it, for instance, unlike some obfuscation methods
which simply obscure names. However, any program (reguardless of what
language it's written in) once loaded into memory is vulnerable to
reverse-engineering.

-Rob Teixeira [MVP]
 
Hi,

Yes, I've heard of it.
However I not that keen on using it...(i've never tried it though)
 
-----Original Message-----
Hi,



Yup, unless obfuscated - like java.

Or is there an option to compile

There is ngen utility which precompiles. Though the il code is still there
and framework is still required.
Click to expand...
Can the output of ngen be obtained on the developer's
machine and shipped to the client instead of the regular
C# compiled code?
It looks like the only things ngen can convert to native
are static and final methods and variables. Am i right
about that? Does it also inline some methods that it can
inline?
What percentage of ngen-generated code can still be
decompiled? If i'm right in the previous paragraph, then
i guess more than 85% of the code can still be decompiled
after ngen in most cases.
The only solution is to obfuscate the code - there are some 3rd parites plus
one stripped down is shipped with vs.net 2003.
Click to expand...
From my experience with decompilers, most of them end up
changing method and variable names into meaningless short
strings, and that pretty much it. Some go a little deeper
obfuscating the logic, although then one starts
thinking "does this hurt performance?". It helps, but
often times not enough. Are .NET obfuscators in the same
category?Thanks!
 
Reshat Sabiq said:
Can the output of ngen be obtained on the developer's
machine and shipped to the client instead of the regular
C# compiled code?
It looks like the only things ngen can convert to native
are static and final methods and variables. Am i right
about that? Does it also inline some methods that it can
inline?
What percentage of ngen-generated code can still be
decompiled? If i'm right in the previous paragraph, then
i guess more than 85% of the code can still be decompiled
after ngen in most cases.
Click to expand...

AFAIK ngen code is linked to source one - it isn't the tool meant to
obfuscate - just to speed up first execution (it compiles all the code).

From my experience with decompilers, most of them end up
changing method and variable names into meaningless short
strings, and that pretty much it. Some go a little deeper
obfuscating the logic, although then one starts
thinking "does this hurt performance?". It helps, but
often times not enough. Are .NET obfuscators in the same
category?
Click to expand...

Yep.
 
This basically stops people from examining the contents of the file. You
could never run ILDASM on it, for instance, unlike some obfuscation methods
which simply obscure names. However, any program (reguardless of what
language it's written in) once loaded into memory is vulnerable to
reverse-engineering.
Click to expand...

So true. There is no way to protect digital data.
You can just make a bit more difficult to read and that's it.
I think that the best way to protect your program is added value (support,
updates, etc) and not hidding the code.
 
-----Original Message-----
some obfuscation
methods

So true. There is no way to protect digital data.
You can just make a bit more difficult to read and that's it.
I think that the best way to protect your program is added value (support,
updates, etc) and not hidding the code.
Click to expand...

In princinple, it is true. Yet i don't think MS Office
will be shipped in decompilable fashion any time soon. :)

Thanks,
rs.
 
So true. There is no way to protect digital data.
In princinple, it is true. Yet i don't think MS Office
will be shipped in decompilable fashion any time soon. :)

Thanks,
rs.
Click to expand...

*All* code, unless specifically transformed into a non-operational and
unreadable form (such as using keyed stream or block cipher encryption) is
suseptable to decompilation.
There are PE decompilers that can turn winword.exe and excel.exe into very
readable forms.
And while the tools themselves do more work to transform native binaries
into readable form than ILDASM does, to the potential hacker, it's still one
push of a button :-)

I think a lot of people fail to recognize that CIL is VERY much like x86
assembly. You have PUSHes, POPs, JUMPs, ADDs, etc. It's not entirely
different. The biggest difference being that meta-data and CIL standards
allow the organization of the code/data to be more predictable, as well as
adds descriptive names to types and members.

-Rob Teixeira [MVP]
 
Color me confused (although this has been a very
interesting thread).

I can imagine lots of reasons for Microsoft obscuring
code which go way beyond what the average person would
want to do, not the least of which is detouring would be
hackers.

As far as protecting code, i assume anyone who WANTS to
steal your code would pirate and reproduce it in
Thailand, not reverse engineer it. I would assume it
would be a pretty high honor to write code good enough
for people to want to read it, especially after the least
bit of obfuscation.

Am I missing something?
 
Yes, the only benefit obscuring provides is for something
that is commercial or not desired to be open source. This
excludes web apps, because the code is on the server and
can be restricted there well enough. That's why i am a
big fan of Java on the server side. This also excludes
open-source projects.

Btw., could someone recommend a native (C++) decompiler?
I'd like to see what kind of output they provide, and
whether that output is interpretable.

Thanks for all the replies,
rs.
 
Back
Top