¿Por qué es tan fácil de descompilar el código .NET IL?

Question

¿Por qué es tan fácil de descompilar .NET IL-código en el código fuente, en comparación con los binarios x86 nativas descompilación? (Reflector produce bastante bueno código fuente mayor parte del tiempo, mientras que la descompilación la salida de un compilador C ++ es casi imposible.)

¿Es porque IL contiene una gran cantidad de metadatos? ¿O es porque IL es una abstracción más alto que las instrucciones x86? Hice un poco de investigación y encontró que los siguientes dos artículos útiles, pero ninguno de ellos responde a mi pregunta.

• MSIL Descompilador Teoría
• C Decompiler - imprimación rápida

Answer 1

Creo que tienes los bits más importantes ya.

• Como usted dice, hay más metadatos disponibles. No sé los detalles de lo que se emite por un compilador C o C ++, pero sospecho ahora más nombres y otros datos similares están incluidos en IL. Basta con mirar a lo que el decompilador sabe acerca de lo que hay en un marco de pila particular, por ejemplo - en lo que respecta a la 86, sólo se sabe cómo la pila es utiliza ; en la IL sabes lo que el contenido de la pila representan (o, al menos, el tipo - no el significado semántico)
• Una vez más, como ya se ha mencionado, IL es una abstracción nivel superior al de x86. x86 no tiene idea de lo que es un método o función llamada es, o un acontecimiento, o una propiedad, etc. IL tiene toda esa información todavía dentro de ella.
• Por lo general compiladores de C y C ++ de optimizar mucho más pesadamente que (por ejemplo) el compilador de C #. Esto es porque el compilador de C # asume que la mayoría de la optimización todavía se pueden realizar más tarde - el JIT. En cierto modo, tiene sentido que el compilador de C # no para tratar de hacer mucho optimización, ya que hay varios bits de información que están disponibles para el JIT pero no el compilador de C #. El código optimizado es más difícil de descomponer, porque es más lejos de ser una representación natural del código fuente original.
• IL fue diseñado para ser JIT-compilado; x86 fue diseñado para ser ejecutado de forma nativa (la verdad a través de micro-código). La información que necesita el compilador JIT es similar a la que un decompilador querría, por lo que un decompilador tiene un tiempo más fácil con IL. De alguna manera esto es realmente sólo una reformulación del segundo punto.

Answer 2

Hay una serie de cosas que hacen il ingeniería inversa bastante fácil.

• Información de tipo. Esto es enorme. En ensamblador x86, hay que inferir los tipos de variables en función de cómo se utilizan.

• estructura. La información sobre la estructura de la aplicación está disponible en más desmontajes il. Esto, combinado con información de tipo, le da una increíble cantidad de datos. Estás trabajando en un nivel bastante alto en este punto (en relación con el ensamblador x86). En ensamblador nativo, que tiene que inferir los diseños de estructura (e incluso el hecho de que son estructuras) en función de cómo se usan los datos. No es imposible, pero mucho que consume más tiempo.

• nombres. Conocer los nombres de las cosas puede ser útil.

Estas cosas, en combinación, significa que tiene un buen montón de datos sobre el ejecutable. Il está trabajando básicamente a un nivel mucho más cerca de la fuente de un compilador de código nativo sería. El nivel más alto es el código de bytes trabaja en la ingeniería inversa más fácil es, en términos generales.

Answer 3

C # y IL casi mapa uno-a-uno. (Esto es menos con algunas nuevas C # 3.0 características.) La cercanía de la aplicación (y la falta de un optimizador en el compilador de C #) hace las cosas 'reversible'.

Answer 4

La extensión respuesta correcta de Brian

Si usted piensa que todo es fácilmente IL decompilable, sugiero escribir un programa C # no trivial e intentar descompilar el código. F # tiene una gran cantidad de transformaciones de código y por lo tanto tiene un mapeo muy pobre de la IL emitida real y la base de código original. En mi humilde opinión, es mucho más difícil mirar descompilada # código F y volver al programa original de lo que es para C # o VB.Net.