Are .net exes real executables?

Question

I've noticed in .net its extremely easy to reverse engineer exe's. Is this because .net executables are merely instruction code for the .net engine, and because of this .net is an interpreted language? And never executed natively?

I must admit, I've never had any performance issues with .net code and so this is why I'm in doubt.

Could someone please explain this to me?

Thanks for the answers so far, does anyone know why Microsoft decided to create this method of requiring a framework, if I remember correctly in the days of vb6 code was compiled to native. Is there a very good reason for .net code having to run through an interpreter now>

Answer 1

As a freetime-mono-developer I'm inclined to answer the last part of your question (Is there a very good reason for .net code having to run through an interpreter now ?): Yes: Portability

Answer 2

The question should be what is a "real" executable.

Executable .NET assemblies are stored in the Portable Executable (PE) format which is one of the file formats used for executable files in Windows.

This is a wrapper format telling the OS all the necessary information to execute the contained code.

In that sense .NET executables are perfectly "real" exes.

However, for .NET assemblies the PE format has been extended:

Microsoft's .NET Framework has extended the PE format with features which support the Common Language Runtime. Among the additions are a CLR Header and CLR Data section. Upon loading a binary, the OS loader yields execution to the CLR via a reference in the PE/COFF IMPORT table. The CLR then loads the CLR Header and Data sections.

The CLR Data section contains two important segments: Metadata and Intermediate Language (IL) code:

• Metadata contains information relevant to the assembly, including the assembly manifest. A manifest describes the assembly in detail including unique identification (via a hash, version number, etc.), data on exported components, extensive type information (supported by the Common Type System (CTS)), external references, and a list of files> within the assembly. The CLR environment makes extensive use of metadata.

• Intermediate Language (IL) code is abstracted, language independent code that satisfies the .NET CLR's Common Intermediate Language (CIL) requirement. The term "Intermediate" refers to the nature of IL code being cross-language and cross-platform compatible. This intermediate language, similar to Java bytecode, allows platforms and languages to support the common .NET CLR. IL supports object-oriented programming (polymorphism, inheritance, abstract types, etc.), exceptions, events, and various data structures. IL code is assembled into a .NET PE for execution by the CLR.

Answer 3

Yes, they are not "real". The exes you're going to create will be MSIL coded. When you run your one of your exes, the code will be converted to machine code by CLR (Common Language Runtime).

MSIL code can be easily decompiled. You can use the .NET Reflector and it is free. Also you can convert your codes from C# to VB.NET or C++ etc when you decompile your exe...

and also you can try Xenocode Postbuild obfuscator it makes your exe Native32 and obfuscated, .NET Reflector will can't decompile your exe if you use this obfuscator. But, it makes your exes a little bigger :)...

Answer 4

When you first load a .Net assembly, the byte code (MSIL) gets compiled to native machine code (Just In Time compilation), and from that point on it runs as native assembler. So .Net assemblies are not interpreted, but you do get a small performance hit when they are first jitted. However jitting has the advantage that the JIT compiler can optimise the assembler for the architecture (CPU instruction set etc) on which the assembly is running, whereas with tradition build-time compilation (as in C++) this is not necessarily the case.

If you prefer you can pre-compiled .Net assemblies using ngen, avoiding the JIT overhead.

Answer 5

.NET is not interpreted. When a code actually executes it is a native code which has been compiled from MSIL thanks to the JIT. The executable contains the MSIL instructions necessary to produce native code.

Answer 6

No, they aren't normal executables. They contain metadata and CIL (Common Intermediate Language) instructions as defined in the CLI Standard (see ECMA-335 - http://www.ecma-international.org/publications/standards/Ecma-335.htm).

As for CIL being interpreted: Most verions of .NEt don't interprete the code, but JIT (Just-In-Time) compile it. That means that when a piece of code is used for the first time in an application run time, the code is compiled to native code and this native code is used from there on. But this is in fact an implementation detail, for example as far as I know Micro framework in purely interpreted.

As for your edit in the question:

The reason is that by having a common representation of the code in metadata and in a common instrcution set is that it gets much easier to interoperate between different languages that way.

Because all languages speak the same, common "low-level" language behind the scenes, they are able to seemlessly integrate with each other.

Answer 7

The .exe file contains byte code that represents IL instructions. When you start the application the JIT compiler compiles this into native code specifically created for your processor.

So, while the executable doesn't contain native code, what's executed is native code. As the JIT compiler can optimise the code for your specific processor, it has the potential to be faster than native code generated to run on any processor.

Answer 8

.NET exes are PE files like other executables but they contain additional sections to contain the IL inside. Look at the last post in this thread to see more detail.

Answer 9

.Net executables contain MSIL (Microsoft Intermediate Language) byte code, similar to Java bytecode. They are not native Intel32 code and cannot run without the .Net framework installed. Apart from MSIL there is a substantial amount of metadata included. You can use Ildasm or Reflector to look into the .Net executables.

Technically, they not interpreted, but JIT (Just-In-Time) compiled to machine code. There is a way to compile them to native code, NGen.exe utility. Sometimes, JIT code can be faster than NGen since it can do runtime analysis.

Answer 10

They are byte code. Theoretically byte code can be faster than native code, so don't take performance into it.