Compiler C # en natif?
Je pense que je suis quelque peu confus quant à la compilation de code octet .NET en code natif, ou peut-être que je suis confus quant au résultat final. Alors, soyez indulgent avec moi alors que j'essaie de trier ce que je pense comprendre afin que vous puissiez m'aider à comprendre ce qui me manque.
Ce que j'aimerais faire, c'est compiler mon application écrite en C # vers le code natif normal comme je le ferais si je l'avais écrite en C. Mon raisonnement n'a rien à voir avec la performance, mais plutôt avec un certain degré de protection. Je comprends que mon objectif final n'est pas impossible (ou même vraiment difficile à contourner), mais j'ai juste l'impression qu'il est plus difficile d'inverser l'assemblage x86 que d'inverser ce que Reflector me donne.
En ce moment, si je jette mon application C # dans Reflector, je récupère essentiellement mon code source. En général, lorsque je jette mes applications C/C++ non gérées dans IDAPro et utilise le décompilateur HexRays, je ne récupère pas tout à fait le même degré de décompilation et je dois recourir au patinage via le démontage x86 pour comprendre le flux logique. Je crois comprendre qu'une telle grande décompilation vient de Reflector en raison de l'application étant dans MSIL au lieu du code natif plus laconique que HexRays essaie de décompiler.
Je n'ai aucune inquiétude quant à la machine cliente ayant encore besoin des runtimes .NET, je n'essaie pas de contourner tout cela. Je voudrais exécuter des programmes d'obfuscation de logiciels normaux comme upx sur mon programme, et le faire comme un binaire .NET échoue.
C'était ma compréhension de this question connexe que ngen fait ce que je veux. J'ai essayé d'utiliser ngen. Mais après avoir copié le fichier de sortie du C:\Windows\assemblies\...\applicationName.ni.exe répertoire vers un endroit où je peux double-cliquer, et essayer de l'exécuter produit une erreur indiquant qu'il ne s'agit pas d'une "application Win32 valide". De plus, lorsque je lance le applicationName.ni.exe dans Reflector, j'obtiens la même sortie que je l'ai fait à partir du applicationName.exe. Puisque applicationName.ni.exe est censé être du code natif, je m'attendais à ce que Reflector fasse une erreur, mais ce n'est pas le cas. Si c'est comme ça que je suis censé faire cela, pourquoi Reflector m'a-t-il toujours donné une si grande décompilation?
Donc, pour résumer à nouveau ma question principale: comment puis-je compiler mon programme .NET dans un binaire natif que Reflector ne décompilera pas si facilement? Ou quelles sont les meilleures pratiques pour protéger un produit écrit dans un langage .NET contre les reverse-ingénieurs débutants?
Si j'ai besoin d'un outil différent, je préférerais quelque chose de gratuit et pas quelque chose comme Codewall .
Merci!
MISE À JOUR: Je comprends que ce que je recherche pourrait limiter certaines des fonctionnalités du langage comme Reflection, mais je pense que je suis d'accord avec ça . Aucun de mon code ne fait explicitement Assembly.Load appels ou quoi que ce soit du genre. Mais ne pourrait-on pas simplement les remplacer par GetProcAddress/LoadLibrary appelle quand même?
Je viens validé. Net Native on VS2015 & Windows 8.1 (une fois configuré correctement, examinez .proj pour valider) et construire pour une architecture particulière (peut-être exagéré, non validé), produira un fichier natif qui vous donnera le code "plus difficile à rétroconcevoir" que vous recherchez et qui pour moi n'était pas activé lire . dll via DotPeek (décompilateur .Net gratuit de JetBrains).
Ce n'est pas ainsi que fonctionne ngen.exe. Il exécute simplement le compilateur JIT à l'avant pour générer le module .ni.exe ou .ni.dll. Ce fichier binaire ne contient pas de métadonnées, uniquement le code machine généré à partir de l'IL pour les corps de méthode. Le CLR doit toujours trouver l'assemblage d'origine. Ce n'est qu'alors qu'il peut déterminer qu'une image ngen-ed est disponible afin qu'il puisse utiliser le code machine à partir de celui-ci plutôt que de le générer à partir de l'IL de l'assembly.
Ngen.exe accélère le temps de démarrage à chaud de votre application, c'est tout.
Mon conseil habituel à quiconque pourrait être intéressé par le démontage de mes assemblages est de les diriger vers sourceforge.net. Il a des téraoctets de code source, écrits et maintenus par des programmeurs qui sont généralement meilleurs que moi. Parfois même avec de bons commentaires. Si votre obfuscateur ne fonctionne pas bien, cherchez-en un meilleur. Il y a beaucoup de.
Hier, à Build 2014 , Microsoft a annoncé . NET Native . Selon la FAQ , "... Dans un premier temps, nous nous concentrons sur les applications du Windows Store avec .NET Native. À plus long terme, nous continuerons d'améliorer le natif compilation pour toutes les applications .NET. "
Si vous souhaitez protéger votre code, un obfuscateur est l'approche typique. Dotfuscator participe à une course aux armements avec réflecteur depuis un certain temps et nous l'utilisons sur nos produits. En pratique, cependant, un être humain qualifié peut facilement lire du code obscurci.
La compilation en code natif va à l'encontre de l'objectif d'avoir un langage géré. Le principal avantage est de permettre au runtime cible de JIT l'IL en quelque chose qui est de manière optimale acceptable pour le CPU cible. Si vous voulez le contraire, vous utiliseriez quelque chose comme option anticipée en mono .
Spoon (auparavant Xenocode) a n produit qui pourrait répondre à vos besoins . Nous l'utilisons pour une interface utilisateur d'installation basée sur WPF, nous n'avons donc pas besoin de bootstrap .net pour charger le programme d'installation lui-même.
NGEN ajoute du code natif, mais il ne supprime pas le MSIL. Par conséquent, tout outil fonctionnant sur le MSIL peut toujours fonctionner. Vous en avez également besoin pour la réflexion, ce qui serait très difficile pour un vrai compilateur natif.
ceci est un obfuscateur gratuit, ce qui est plutôt bon: eazfuscator
C'est enfin possible en utilisant le compilateur natif .NET de Microsoft
Il compile automatiquement la version finale des applications écrites en code managé (C # ou Visual Basic) et qui ciblent le .NET Framework et Windows 10 en code natif.
..
• Vos applications fourniront les performances supérieures du code natif.
? Vous pouvez continuer à programmer en C # ou Visual Basic.
• Vous pouvez continuer à tirer parti des ressources fournies par le .NET Framework, notamment sa bibliothèque de classes, la gestion automatique de la mémoire et le garbage collection, et la gestion des exceptions.
Pour les utilisateurs de vos applications, .NET Native offre les avantages suivants:
• Temps d'exécution rapides
• Temps de démarrage toujours rapides
• Coûts de déploiement et de mise à jour faibles
• Utilisation optimisée de la mémoire de l'application
Mais .NET Native implique plus qu'une compilation en code natif. Il transforme la façon dont les applications .NET Framework sont créées et exécutées. En particulier:
• Pendant la précompilation, les parties requises du .NET Framework sont liées statiquement à votre application. Cela permet à l'application de s'exécuter avec les bibliothèques locales de l'application du .NET Framework et le compilateur d'effectuer une analyse globale pour fournir des gains de performances. En conséquence, les applications se lancent toujours plus rapidement, même après les mises à jour de .NET Framework.
• Le runtime .NET Native est optimisé pour la précompilation statique et peut ainsi offrir des performances supérieures. Dans le même temps, il conserve les fonctionnalités de réflexion de base que les développeurs trouvent si productives.
• .NET Native utilise le même serveur principal que le compilateur C++, qui est optimisé pour les scénarios de précompilation statique.
https://msdn.Microsoft.com/en-us/library/dn584397 (v = vs.110) .aspx
Ceci n'est disponible qu'avec VS.NET 2015.
Je pourrais prendre du recul et vous demander pourquoi vous recherchez ce type de protection. Je n'essaie pas de faire valoir que vous n'avez pas besoin de la protection, mais je pense que cela vaut la peine de comprendre la motivation.
Par exemple, si vous voulez une protection parce que vous avez un algorithme dans votre système où il serait dévastateur pour la sécurité si quelqu'un en faisait la rétro-ingénierie, alors vous devrez peut-être envisager une approche différente. Cela signifie qu'il y a une faille dans l'algorithme et aucune quantité d'obscurcissement ou de compilation native ne vous y aidera.
Si c'est une question d'IP, je pense que l'obfuscation est probablement votre meilleure approche ici. C'est un peu comme mettre une serrure sur votre porte. Quelqu'un peut briser la serrure et entrer, mais ils le font intentionnellement au lieu de simplement marcher dans la porte.
Cela est possible en utilisant le compilateur IL2CPU. IL2CPU est développé par les mêmes personnes qui fabriquent COSMOS (C # Open Source Managed Operating System) et n'est disponible qu'en téléchargeant cosmos. IL2CPU produit des fichiers ASM qui peuvent être compilés via Nasm (certains autres assembleurs peuvent fonctionner mais il est préférable d'utiliser nasm). le seul problème avec IL2CPU est qu'il est intégré au projet Cosmos et qu'il est assez difficile de le faire fonctionner seul.
D'autres réponses mentionnent le compilateur natif .NET De Microsoft, mais ne vous expliquent pas comment procéder.
Ici est un tutoriel utilisant CoreRT sur la façon de compiler votre projet C# En code natif.
Remarque: J'ai également dû commenter la ligne suivante pour que tout fonctionne:
<!-- <add key="helloworld" value="https://api.helloworld.org/v3/index.json" /> -->
Le résultat est un exécutable d'environ 4MB:
En effet, le code n'est plus lisible avec les décompilateurs .NET Et IDA Pro (un désassembleur de code natif) le reconnaît comme du code natif.