Un guide : l'ingénierie inverse de l'obfuscation de code

Les chiffres de l'obscurcissement du code sont l'une des approches de sécurité des applications les plus populaires pour empêcher le piratage des applications. C'est l'un des efforts AppSec les plus fréquemment suggérés par les spécialistes de la sécurité du monde entier, et il prend souvent en charge les exigences de sécurité très minimales de votre application. Cette stratégie est fréquemment utilisée comme mécanisme de défense majeur contre les tentatives de piratage et protège contre les menaces typiques telles que l'injection de code, l'ingénierie inverse et la falsification des informations personnelles des clients et des utilisateurs d'applications.

Obfuscation du code ?

La pratique consistant à obscurcir les exécutables de sorte qu'ils ne soient plus compréhensibles, intelligibles ou pratiques est connue sous le nom d'obscurcissement du code. Le code source a été obscurci au point qu'il est incompréhensible et difficile pour un tiers à saisir, et encore moins à exécuter. L'interface utilisateur de l'utilisateur final ou la sortie prévue du code ne sont pas affectées par l'obscurité. C'est juste une mesure de précaution pour rendre le code inutile à tout pirate potentiel qui a accès au code exécutable d'un logiciel.

Pourquoi est-il nécessaire d'obscurcir le code ?

L'obscurcissement du code est particulièrement important pour les logiciels open source, qui présentent un inconvénient important en termes de piratage à des fins personnelles. Les développeurs garantissent que la propriété intellectuelle de leur produit est protégée contre les risques de sécurité, les accès illégaux et la découverte de failles d'application en rendant un programme difficile à désosser.

Quel que soit le type de technique d'obscurcissement utilisé, cette approche restreint le code source dangereux et garantit divers niveaux de sécurité du programme. Les raisons de temps, de coût et de ressources favorisent toutes l'abandon de votre code lorsqu'il est obscurci puisque le code décompilé est rendu illisible.

Techniques d'obscurcissement de code

L'obscurcissement fonctionne à différents niveaux : il peut être implémenté au niveau de la structure du code sémantique/lexical ou au niveau de la structure des données/du flux de contrôle. Les stratégies d'obscurcissement diffèrent également en fonction de l'action sur le code. Essentiellement, l'équipe de sécurité détermine le type d'obscurcissement à utiliser sur le code en coopération avec l'équipe de développement.

Obfuscation devrait être renommé.

Cette approche implique de nommer les variables de manière confuse afin que le but réel de leur utilisation soit intelligemment caché. Les décompilateurs ont du mal à comprendre le flux de contrôle car les méthodes et les variables sont renommées avec diverses notations et numéros. Cette méthode d'obscurcissement est couramment utilisée pour masquer le code d'application des plates-formes Java, .NET et Android. Ceci est classé comme obscurcissement de la mise en page car il cible directement le code source pour fournir une couche de protection pour l'application.

Obfuscation des données

Cette méthode se concentre sur les structures de données utilisées dans le code, ce qui empêche le pirate d'accéder au véritable objectif du programme. Cela peut impliquer de modifier la façon dont les données sont stockées en mémoire par le logiciel et la façon dont ces données sont traitées pour produire le résultat final. Cette procédure peut se faire de différentes manières :

1. Obfuscation de l'agrégation
La façon dont les données sont enregistrées dans le logiciel change en conséquence. Les tableaux, par exemple, peuvent être divisés en plusieurs sous-tableaux qui peuvent ensuite être référencés tout au long du programme.

2. Obfuscation du stockage des données
Cela a un impact sur la façon dont les données sont stockées en mémoire. Les développeurs peuvent, par exemple, alterner entre le stockage des variables locales et globales pour masquer la véritable nature du comportement des variables.

3. Obfuscation à la demande
Cette approche modifie l'ordre des données sans modifier la fonctionnalité de l'extrait de code/programme. Les développeurs y parviennent en créant un module distinct qui est appelé pour chaque instance de la référence de variable.

4. Chaînes de cryptage
Cette technique crypte toutes les chaînes lisibles, ce qui donne un code illisible. Lorsque le logiciel est exécuté, ils doivent être déchiffrés au moment de l'exécution.

5. Obfuscation du flux de contrôle/code
La manière dont le contrôle est transmis d'une partie de la base de code à une autre est cruciale pour établir l'objectif du programme. Obscurcir ce flux est souvent la manière la plus rentable de pervertir le flux du jeu. Cette stratégie d'obscurcissement tient les pirates à distance en les empêchant de comprendre comment et pourquoi le code suit un chemin spécifique.

L'inclusion d'instructions aléatoires et inattendues, ainsi que d'instructions de changement de casse inutiles (code mort) qui ne seraient jamais exécutées, est l'un des moyens les plus courants d'accomplir cette stratégie d'obscurcissement. Ces affirmations n'ont d'autre fonction que de rendre perplexe le pirate ciblé. Dans le cas de l'orientation conditionnelle du programme, ce changement dans la séquence des instructions d'exécution du programme est extrêmement utile.

L'obscurcissement est en cours de débogage.

Les informations de débogage sont souvent utiles pour déterminer des informations vitales sur le déroulement et les défauts du programme en décompilant et en recompilant le code source. Il est essentiel de masquer ces données d'identification en modifiant leurs identités, leurs numéros de ligne ou en désactivant complètement l'accès aux données de débogage.

L'obscurcissement doit être traité.

Les erreurs de programmation de la mémoire se sont généralisées dans les attaques, en particulier dans les langages non sécurisés pour la mémoire comme C et C++. Les failles de sécurité sont souvent causées par des erreurs telles que l'accès incontrôlé à la baie. L'approche d'obscurcissement d'adresse rend la rétro-ingénierie difficile puisque les adresses virtuelles du code et les données du programme sont randomisées à chaque fois que le code converti est exécuté. Par conséquent, la majorité des attaques par erreur de mémoire sont non déterministes, avec une très faible probabilité de succès.

Codage personnalisé

Les développeurs utilisent cette approche pour chiffrer les chaînes avec un algorithme personnalisé, puis fournissent une fonction de décodage pour récupérer le code d'origine.

Arguments passés à l'exécution

Il est possible de modifier le programme de manière à ce qu'il attende des paramètres à l'exécution. Pour décoder les variables, l'utilisateur doit disposer à la fois du code et de la clé de déchiffrement.

Pour développer une méthode de défense en couches pour protéger les applications contre diverses menaces de sécurité, l'équipe de sécurité peut choisir de déployer plusieurs techniques en même temps.

Conclusion

En résumé, la mauvaise direction à elle seule est inefficace pour lutter contre les problèmes de sécurité avancés. Il est plus difficile de désobscurcir le code en raison de la disponibilité des logiciels d'intelligence artificielle et de la compétence des pirates, mais ce n'est pas impossible. Par conséquent, la cryptographie n'est pas la panacée pour tous les problèmes de sécurité logicielle.
L'équipe de développement peut utiliser diverses approches d'obfuscation de code pour sécuriser son code dans un environnement non approuvé, en fonction des besoins de sécurité, de la nature du programme et des performances de référence. Celles-ci doivent être réalisées en tenant compte des avantages et des inconvénients de chaque approche. D'autres initiatives AppSec, telles que le chiffrement, RASP, les réglementations sur la conservation des données, etc., doivent être prises en charge par cette stratégie. Lorsqu'il est combiné avec des solutions RASP comme AppSealing, il devient un antidote puissant aux problèmes de sécurité d'aujourd'hui.