Protéger l'exécutable de l'ingénierie inverse?

Question

J'ai été envisagent comment protéger mon code C/C++ à partir de démontage et d'ingénierie inverse. Normalement, je n'aurait jamais admis ce problème moi-même dans mon code; toutefois, le protocole actuel, j'ai travaillé ne doit jamais être inspecté ou compréhensibles, pour la sécurité des personnes différentes.

Maintenant, c'est un sujet nouveau pour moi, et l'internet n'est pas vraiment ingénieux pour la prévention contre le reverse engineering , mais plutôt dépeint des tonnes d'informations sur comment désosser

Certaines des choses que j'ai pensé jusqu'à présent sont:

• L'injection de Code (appel mannequin fonctions avant et après réel les appels de fonction)
• Code obfustication (mangles le démontage de la binaire)

• Écrire mes propres routines de démarrage (plus difficile pour les débogueurs de se lier à l')

  void startup();  
  int _start()   
  {  
      startup( );  
      exit   (0)   
  }  
  void startup()  
  {  
      /* code here */  
  }
  

• Moment de l'exécution pour les débogueurs (et de la force de sortie si elle est détectée)

• Fonction des trampolines

   void trampoline(void (*fnptr)(), bool ping = false)  
   {  
     if(ping)  
       fnptr();  
     else  
       trampoline(fnptr, true);  
   }
  

• Inutile allocations et deallocations (pile change beaucoup de choses)

• Inutile factice des appels et des trampolines (tonnes de sauter dans le démontage de sortie)
• Des tonnes de casting (pour obscurci démontage)

Je veux dire que ce sont certaines des choses que j'ai pensé mais ils peuvent tous être travaillé autour et ou compris par le code des analystes étant donné le délai de droit. Est-il rien d'autre alternative que j'ai?

Answer 1

mais ils peuvent tous être travaillé autour et ou compris par code analysists donné le délai de droit.

Si vous donnez aux gens un programme qu'ils sont en mesure d'exécuter, puis ils seront également en mesure de rétro-conception donné assez de temps. C'est la nature des programmes. Dès que le binaire est disponible à quelqu'un qui veut déchiffrer, vous ne pouvez pas éviter une éventuelle reverse-engineering. Après tout, l'ordinateur doit être en mesure de le déchiffrer afin de l'exécuter, et l'homme est tout simplement un ordinateur plus lent.

Answer 2

Ce que l'Ambre a dit est tout à fait exact. Vous pouvez faire de l'ingénierie inverse plus difficile, mais on ne peut pas l'empêcher. Vous ne devriez jamais faire confiance "sécurité" qui s'appuie sur la prévention de l'ingénierie inverse.

Cela dit, le meilleur des anti-rétro-ingénierie des techniques que j'ai vu ne portait pas sur obfusquer le code, mais au lieu de lui casser les outils que l'on utilise habituellement pour comprendre comment le code fonctionne. La recherche de moyens créatifs pour briser désassembleurs, des débogueurs, etc est à la fois susceptible d'être plus efficace et aussi intellectuellement plus satisfaisant que de générer seulement les piles de l'horrible code spaghetti. Cela n'a rien à bloquer une personne déterminée, mais elle augmente la probabilité que J Aléatoire Cracker promener et de travailler sur quelque chose de plus facile à la place.

Answer 3

Coffre-fort Net Sentinelle (anciennement Aladdin). Mises en garde bien de leur API suce, la documentation suce, et ceux-ci sont grandes par rapport à leur SDK outils.

J'ai utilisé leur matériel méthode de protection (Sentinel HASP HL) pendant de nombreuses années. Il nécessite une propriété clé USB fob qui agit comme la "licence" pour le logiciel. Leur SDK crypte et dissimule vos exécutables et les bibliothèques, et permet de lier les différentes fonctionnalités de votre application, à des traits gravés dans la clé. Sans une clé USB fournie et activé par le donneur de licence, le logiciel ne peut pas déchiffrer et donc ne sera pas exécuté. La Clé utilise même une personnalisation de l'USB protocole de communication (en dehors de mon domaine de connaissances, je ne suis pas un pilote de périphérique gars), il est difficile de construire une clé virtuelle, ou altérer la communication entre le moteur d'exécution wrapper et d'une clé. Leur SDK n'est pas très développeur sympathique, et c'est assez douloureux pour intégrer l'ajout de protection avec un processus de génération automatique (mais possible).

Avant la mise en œuvre du HASP HL de protection, il y avait 7 connu pirates qui avaient dépouillé le dotfuscator 'protections' du produit. Nous avons ajouté le MORAILLON de protection en même temps qu'une mise à jour majeure du logiciel, qui effectue une lourde calcul sur la vidéo en temps réel. Du mieux que je peux dire à partir de profilage et l'analyse comparative, le HASP HL de protection que de ralentir le calcul intensif de 3% environ. Depuis que le logiciel a été publié il ya environ 5 ans, pas un nouveau pirate de la produit a été trouvé. Les logiciels qu'il protège d'une forte demande dans son segment de marché, et le client est conscient que plusieurs concurrents activement à désosser (sans succès jusqu'à présent). Nous savons qu'ils ont essayé de solliciter l'aide de quelques groupes en Russie, la publicité pour un service de casser la protection des logiciels, que de nombreux posts sur divers forums de discussion et les forums ont inclus les versions les plus récentes du produit protégé.

Récemment, nous avons essayé de leur licence de logiciel solution (HASP SL) sur un petit projet, qui a été assez simple de se mettre au travail si vous êtes déjà familier avec le HL de produit. Il semble fonctionner; il n'y a aucun actes de piraterie, mais ce produit est beaucoup plus faible dans la demande..

Bien sûr, aucune protection ne peut être parfait. Si quelqu'un est suffisamment motivée et a de graves argent à dépenser, je suis sûr que les protections offertes par le PROGRAMME pourrait être contournée.

Answer 4

Le meilleur anti désassembleur de trucs, en particulier sur la variable longueur de mot jeux d'instructions sont en assembleur/code machine, pas de C. Par exemple

CLC
BCC over
.byte 0x09
over:

Le désassembleur de résoudre le problème qu'une branche de destination est le deuxième octet dans un multi-octet de l'instruction. Une instruction set simulator aura pas de problème. La ramification à la les adresses, que vous pouvez causer à partir de C, il est également le démontage difficile, voire impossible. Instruction set simulator aura pas de problème avec elle. À l'aide d'un simulateur de trier direction de destinations pour vous peut aider le processus de démontage. Le code compilé est relativement propre et facile pour un désassembleur. Donc, je pense, un assemblage est requis.

Je pense que c'était vers le début de Michael Abrash Zen de l'Assemblée de la Langue où il a montré un simple anti désassembleur et anti-debugger truc. Le 8088/6 avait une prélecture de la file d'attente de ce que vous avez fait était d'avoir une instruction qui a modifié la prochaine instruction ou un couple à l'avance. Si le pas à pas puis vous avez effectué la modification de l'instruction, si votre instruction set simulator n'a pas de simuler le matériel complètement, vous avez exécuté la modification de l'instruction. Sur du matériel réel d'un fonctionnement normal de la vraie instruction serait déjà dans la file d'attente et la modification de l'emplacement de la mémoire n'est pas causer de dommages, aussi longtemps que vous n'avez pas l'exécution de la chaîne d'instructions à nouveau. Vous pourriez probablement toujours utiliser un truc comme ça aujourd'hui, comme en pipeline processeurs aller chercher l'instruction suivante. Ou si vous savez que le matériel a une instruction séparée et cache de données, vous pouvez modifier un certain nombre d'octets à l'avance si vous alignez ce code dans la ligne de cache correctement, la modification de l'octet ne sera pas écrite à travers le cache d'instructions, mais le cache de données, et une instruction set simulator que ne pas avoir de cache simulateurs de ne pas s'exécuter correctement. Je pense que les seules solutions logiciels ne sont pas va vous recevoir très loin.

Le ci-dessus sont anciens et bien connus, je ne sais pas assez sur les outils actuels pour savoir si ils ont déjà ce genre de choses. L'auto-modifiant le code peut/va remonter le débogueur, mais l'homme peut/va étroite sur le problème et ensuite voir l'auto de modifier le code et de le contourner.

Il a utilisé pour être que les pirates devrait prendre environ 18 mois, afin de travailler sur quelque chose, de dvd par exemple. Maintenant, ils sont en moyenne autour de 2 jours à 2 semaines (si motivé) (blue ray, iphone, etc). Que signifie pour moi si j'ai passer plus de quelques jours sur la sécurité, je risque de perdre mon temps. La seule véritable sécurité, vous obtiendrez, c'est par le biais de matériel (par exemple, vos instructions sont cryptées et seul le cœur de processeur à l'intérieur de la puce décrypte juste avant l'exécution, de façon à ne pas exposer la restitution des instructions). Que pourriez-vous acheter en mois au lieu de plusieurs jours.

Aussi, lire Kevin Mitnick du livre l'Art de La Tromperie. Une telle personne pourrait prendre un téléphone et avez-vous ou un collègue de travail, la main sur les secrets du système en pensant que c'est un manager ou d'un autre collègue ou ingénieur en matériel informatique dans une autre partie de la société. Et votre sécurité est soufflé. La sécurité n'est pas tout au sujet de la gestion de la technologie, je dois gérer aussi les humains.

Answer 5

Prenez, par exemple, l' algorithme AES. C'est une très, très algorithme publique, et il est TRÈS sécurisé. Pourquoi? Deux raisons: Il a été examiné par beaucoup de gens intelligents, et le "secret" n'est pas de l'algorithme lui-même - le secret est la clé qui est l'une des entrées de l'algorithme. C'est une bien meilleure approche pour la conception de votre protocole d'un "secret" qui est à l'extérieur de votre code, plutôt que de faire le code secret. Le code peut toujours être interprétée peu importe ce que vous faites, et (idéalement) générés secret ne peut être mise en péril par une massive approche par force brute ou par vol.

Je pense que d'une question intéressante est de savoir "Pourquoi voulez-vous vous dissimuler votre code?" Vous voulez rendre difficile pour les attaquants à se fissurer vos algorithmes? Afin de rendre plus difficile pour eux de trouver des bogues exploitables dans votre code? Vous n'auriez pas besoin d'obfuscation de code si le code était inviolable en premier lieu. La racine du problème est crackable logiciel. Fixer la racine de votre problème, ne se contentent pas de camoufler.

Aussi, plus la confusion que vous faites de votre code, plus il sera difficile pour VOUS de trouver les bogues de sécurité. Oui, il sera difficile pour les pirates, mais vous avez besoin de trouver des bugs aussi. Le Code doit être facile à maintenir ans à partir de maintenant, et même bien écrit, clair code peut être difficile à maintenir. Ne pas faire pire.