net framework c# .net compiler-construction native

c# - framework - .net native



¿Compilando C#a Native? (10)

Creo que estoy algo confundido acerca de compilar el código de bytes .NET al código nativo, o tal vez estoy confundido sobre el resultado final. Así que, por favor, tengan paciencia conmigo mientras trato de ordenar lo que creo que entiendo para que puedan ayudarme a descubrir lo que me estoy perdiendo.

Lo que me gustaría hacer es compilar mi aplicación escrita en C # a código nativo regular, como obtendría si la hubiera escrito en C. Mi razonamiento no tiene nada que ver con el rendimiento, sino con cierto grado de protección. Entiendo que mi objetivo final no es imposible (o incluso realmente tan difícil) de eludir, pero siento que invertir el ensamblaje de x86 es más difícil que invertir lo que me da Reflector.

Ahora mismo, si lanzo mi aplicación C # en Reflector, básicamente recupero mi código fuente. Por lo general, cuando lanzo mis aplicaciones C / C ++ no administradas en IDAPro y uso el descompilador HexRays, no recupero el mismo grado de descompilación y tengo que recurrir al desarme de x86 para comprender el flujo lógico. Tengo entendido que dicha gran descompilación proviene de Reflector debido a que la aplicación está en MSIL en lugar del código nativo más conciso que HexRays intenta descompilar.

No me preocupa que la máquina cliente aún necesite los tiempos de ejecución de .NET, no estoy tratando de eludir nada de eso. Me gustaría ejecutar programas normales de ofuscación de software como upx en mi programa, y ​​hacerlo al fallar un binario .NET.

Según entendí de this pregunta relacionada, ngen hace lo que quiero. He intentado usar ngen . Pero después de copiar el archivo de salida del directorio C:/Windows/assemblies/.../applicationName.ni.exe a un lugar en el que pueda hacer doble clic e intentar ejecutarlo produce un error: no es una aplicación Win32 válida. ". Además, cuando lanzo el applicationName.ni.exe en Reflector, obtengo el mismo resultado que hice solo del applicationName.exe . Dado applicationName.ni.exe se supone que applicationName.ni.exe es un código nativo, esperaba que Reflector produjera un error, pero no lo hizo. Si es así como se supone que debo hacer esto, ¿por qué Reflector todavía me dio una gran descompilación?

Entonces, solo para resumir mi pregunta principal nuevamente: ¿Cómo puedo compilar mi programa .NET en un binario nativo que Reflector no descompilará tan fácilmente? ¿O cuáles son algunas de las mejores prácticas para proteger un producto escrito en un lenguaje .NET de los nuevos ingenieros de ingeniería inversa?

Si necesito una herramienta diferente, preferiría algo gratis y no algo como Codewall .

¡Gracias!

ACTUALIZACIÓN: Entiendo que lo que estoy buscando podría limitar algunas de las características del lenguaje como Reflexión, pero creo que estoy bien con eso. Ninguno de mi código hace un Assembly.Load explícito. Assembly.Load llamadas o algo por el estilo. ¿Pero no podrían ser reemplazados con las llamadas GetProcAddress/LoadLibrary todos modos?

Acabo de validar .Net Native en VS2015 y Windows 8.1 (cuando se configura correctamente, examino .proj para validar) y la creación de una arquitectura particular (puede ser una exageración, no se ha validado), producirá un archivo nativo que le dará el " Es más difícil de revertir el código de ingeniería "que está buscando y que no pude leer .dll a través de DotPeek (descompilador .Net gratuito de JetBrains).

Así no es como funciona ngen.exe. Simplemente ejecuta el compilador JIT por adelantado para generar el módulo .ni.exe o .ni.dll. Ese archivo binario no contiene metadatos, solo el código de máquina generado desde el IL para los cuerpos del método. El CLR aún debe encontrar el ensamblaje original. Solo así se puede determinar que hay una imagen ngen-ed disponible para que pueda usar el código de la máquina en lugar de generarla a partir de la IL del ensamblaje.

Ngen.exe acelera el cálido tiempo de inicio de su aplicación, eso es todo.

Mi consejo habitual para cualquier persona que pueda estar interesada en desmontar mis ensamblajes es señalarlos a sourceforge.net. Tiene terabytes de código fuente, escritos y mantenidos por programadores que generalmente son mejores que yo. A veces incluso con buenos comentarios. Si su ofuscador no funciona bien, entonces busque una mejor. Hay muchos.

Ayer, en Build 2014 , Microsoft anunció .NET Native . De acuerdo con las FAQ , "... Inicialmente, nos estamos enfocando en las aplicaciones de la Tienda Windows con .NET Native. A largo plazo continuaremos mejorando la compilación nativa para todas las aplicaciones .NET".

Este es un ofuscador gratuito, que es bastante bueno: eazfuscator

Esto es finalmente posible utilizando el compilador nativo de .NET de Microsoft.

Compila automáticamente la versión de lanzamiento de las aplicaciones que están escritas en código administrado (C # o Visual Basic) y que apuntan a .NET Framework y Windows 10 al código nativo.

..

• Sus aplicaciones proporcionarán el rendimiento superior del código nativo.

• Puedes continuar programando en C # o Visual Basic.

• Puede continuar aprovechando los recursos proporcionados por .NET Framework, incluida su biblioteca de clases, la gestión automática de memoria y la recolección de basura, y el manejo de excepciones.

Para los usuarios de sus aplicaciones, .NET Native ofrece estas ventajas:

• Tiempos de ejecución rápidos.

• Tiempos de arranque consistentemente rápidos

• Bajos costos de implementación y actualización.

• Uso optimizado de la memoria de la aplicación

Pero .NET Native implica más que una compilación de código nativo. Transforma la forma en que se crean y ejecutan las aplicaciones de .NET Framework. En particular:

• Durante la precompilación, las partes requeridas de .NET Framework están vinculadas estáticamente a su aplicación. Esto permite que la aplicación se ejecute con las bibliotecas locales de aplicaciones de .NET Framework, y que el compilador realice un análisis global para entregar ganancias de rendimiento. Como resultado, las aplicaciones se inician con mayor rapidez incluso después de las actualizaciones de .NET Framework.

• El tiempo de ejecución nativo de .NET está optimizado para la precompilación estática y, por lo tanto, puede ofrecer un rendimiento superior. Al mismo tiempo, conserva las características de reflexión principales que los desarrolladores encuentran tan productivas.

• .NET Native utiliza el mismo back-end que el compilador de C ++, que está optimizado para escenarios de precompilación estática.

https://msdn.microsoft.com/en-us/library/dn584397(v=vs.110).aspx

Esto solo está disponible con VS.NET 2015.

Esto es posible usando el compilador IL2CPU. IL2CPU está desarrollado por las mismas personas que crean COSMOS (sistema operativo administrado de código abierto C #) y solo está disponible mediante la descarga de cosmos. IL2CPU produce archivos ASM que pueden compilarse a través de Nasm (algunos ensambladores pueden funcionar pero es mejor usar nasm). El único problema con IL2CPU es que está integrado en el Proyecto Cosmos y es bastante difícil lograr que se ejecute solo.

NGEN agrega código nativo, pero no elimina la MSIL. Por lo tanto, cualquier herramienta que funcione en la MSIL puede seguir funcionando. También necesitas esto para la reflexión, algo que sería muy difícil para un verdadero compilador nativo.

Podría dar un paso atrás y preguntarle por qué está buscando este tipo de protección. No estoy tratando de argumentar que no necesita la protección, pero creo que vale la pena entender la motivación.

Por ejemplo, si desea protección porque tiene un algoritmo en su sistema en el que sería devastador para la seguridad si alguien lo diseñara a la inversa, es posible que deba considerar un enfoque diferente. Esto significa que hay una falla en el algoritmo y ninguna cantidad de ofuscación o compilación nativa lo ayudará.

Si es una cuestión de propiedad intelectual, entonces creo que la ofuscación es probablemente tu mejor enfoque aquí. Es como poner un candado en la puerta. Alguien puede romper la cerradura y entrar, pero lo están haciendo intencionalmente en lugar de simplemente entrar por la puerta.

Si desea proteger su código, un ofuscador es el enfoque típico. Dotfuscator ha estado en una carrera de armamentos con reflector por un tiempo y lo usamos en nuestros productos. En la práctica, sin embargo, un humano experto puede leer fácilmente el código ofuscado.

Compilar en código nativo anula el propósito de tener un lenguaje administrado. El principal beneficio es permitir que el tiempo de ejecución de destino para JIT el IL se convierta en algo que sea óptimo para la CPU de destino. Si desea lo contrario, usaría algo como la opción de anticipación en mono .