3

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>

JL.
  • 78,954
  • 126
  • 311
  • 459

10 Answers10

7

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.

Community
  • 1
  • 1
Dirk Vollmar
  • 172,527
  • 53
  • 255
  • 316
4

.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.

dbkk
  • 12,643
  • 13
  • 53
  • 60
  • 2
    But they are still PE files like other exes. – Mike Two Oct 09 '09 at 08:35
  • DBKK, if I'm understanding you, .net executables are interpreted then? But this interpretation is extremely efficient due to the fact that the .net executable is already compiled into byte code, when you save it? – JL. Oct 09 '09 at 08:36
  • It's not interpreted, it's Just-In-Time compiled, so there's a slight performance hit just after execution, as the byte code is compiled to native. Once this is done, there's no essential performance difference. – NM. Oct 09 '09 at 08:39
  • Do I need the .net runtime if I use the NGen.exe utility ? – Preets Oct 09 '09 at 08:57
  • 3
    @Preeti: Yes, you need the .NET Framework installed. There are some options to run an application without the framework being installed though, see here: http://stackoverflow.com/questions/953146/running-net-based-application-without-net-framework – Dirk Vollmar Oct 09 '09 at 08:59
  • Thx divo. Though I am a little confused as to how the .net framework builds the link between object methods and their compiled counterparts . It is capable of parsing native code ? – Preets Oct 09 '09 at 09:15
2

.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.

Mike Two
  • 44,935
  • 9
  • 80
  • 96
2

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.

Guffa
  • 687,336
  • 108
  • 737
  • 1,005
  • Does that mean everytime you start up a .net application it gets compiled into native? If YES, its extremely quick... – JL. Oct 09 '09 at 08:39
  • No, compiled assemblies are cached and you can even pre-compile your assemblies to native code using a tool called ngen.exe. – Dirk Vollmar Oct 09 '09 at 08:42
  • If you use ngen, does that mean your IP is safer? And exempt from reflecting? – JL. Oct 09 '09 at 08:45
  • @JL: Yes, it's always compiled when it starts, at least the first time. The reason that it can be so quick is that the language compiler has already done the hard work of parsing the code, translating the byte codes into machine code is much more straight forward. If you use ngen you are back to generating code that can run on any processor. It's harder to reverse engineer the native code, but it's far from safe. Reverse engineering tools has been around almost as long as compilers... – Guffa Oct 09 '09 at 08:50
  • @JL: ngen creates a native image of your assembly which is stored in the global assembly cache (GAC). This image however cannot be loaded without the original assembly. Thus this is only a feature to improve performance for assemblies that take a long time to be jitted (there are also some downsides of creating native images). – Dirk Vollmar Oct 09 '09 at 08:54
1

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

UK-AL
  • 548
  • 4
  • 8
  • Native code has to be compiled to a specific architecture, which is normally the lowest common denominator when on x86. Byte code can be JIT'ED to whatever machine currently supports allowing you take advantage of the more advanced feature the cpu supports. – UK-AL May 03 '17 at 15:29
1

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.

Maximilian Mayerl
  • 11,253
  • 2
  • 33
  • 40
1

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.

Polyfun
  • 9,479
  • 4
  • 31
  • 39
1

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 :)...

PythEch
  • 932
  • 2
  • 9
  • 21
0

.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.

Darin Dimitrov
  • 1,023,142
  • 271
  • 3,287
  • 2,928
0

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

Nils
  • 9,682
  • 6
  • 46
  • 72