Question:
Dans quels secteurs la rétro-ingénierie [code] est-elle utilisée?
dyasta
2013-04-14 22:42:16 UTC
view on stackexchange narkive permalink

Bien que nous sachions tous à quel point l'ingénierie inverse du code peut être amusante, je me demande quelles industries légitimes, à part l'industrie anti-X, l'ingénierie inverse du code? Bien que cela puisse parfois être nécessaire dans de nombreux rôles techniques, je parle davantage des emplois où il s'agit d'une responsabilité principale. Je soupçonne qu'il y a très peu d'emplois pour lesquels l'ingénierie inverse est une compétence nécessaire, ou peu qui seraient admis, mais je ne sais pas avec certitude. Oui, c'est bien sûr toujours une compétence complémentaire!

Six réponses:
Ange
2013-04-15 00:42:26 UTC
view on stackexchange narkive permalink

Wiki de la communauté: n'hésitez pas à modifier

En tant que compétence principale

  • analyse de logiciels malveillants
  • criminalistique numérique et Réponse aux incidents
  • Évaluation de la sécurité, test du stylet
    • Ce site Web / logiciel / processeur est-il vraiment sécurisé? lequel est le plus sûr?
  • développement d'exploitations

    • si vis pacem, para bellum
  • détection de plagiat (si une entreprise en poursuit une autre parce qu'elle prétend avoir volé son code source)

  • émulation
    • adaptation d'anciens jeux aux médias plus récents
    • adapter le matériel plus ancien au plus récent
      • émuler d'anciennes clés de protection pour les logiciels qui ne sont plus pris en charge
  • récupération du code source
    • car la sauvegarde peut échoue
  • récupération de logique métier / récupération de processus (concernant les systèmes hérités)
    • car il est difficile de documenter correctement toutes les bizarreries, les solutions de contournement et les solutions intelligentes

En tant que compétence secondaire

  • comprendre en quoi consiste un programme
    • car trop souvent, on n'a pas le temps de documenter le fonctionnement d'un outil interne
Igor Skochinsky
2013-04-15 02:21:41 UTC
view on stackexchange narkive permalink

En voici quelques-unes auxquelles vous ne pensez généralement pas:

  • Ateliers de tuning automobile. De nombreux réglages de voitures modernes sont essentiellement du piratage de micrologiciels.
  • Développement de compilateurs. Lorsque vous créez une chaîne d'outils qui produit du code sur lequel d'autres personnes vont s'appuyer, il est bon de disposer d'un outil externe pour vérifier la cohérence.
  • Développement de logiciels généraux. Bien que les débogueurs suffisent généralement, vous devez parfois REER votre propre programme pour comprendre ce qui se passe. Ou regardez à l'intérieur d'une bibliothèque que vous utilisez lorsque les documents sont incomplets, erronés ou tout simplement manquants.
  • Vérifier ce que font vos concurrents (à la fois logiciels et matériels).
Quant au premier point, je peux vous dire qu'il y a une différence entre les gens qui emballent * cette * expérience sous leurs ceintures et ceux qui la vendent / l'offrent.
+1 pour le commentaire sur RE dans le cadre du processus de développement logiciel. Je ne peux pas vous dire combien de fois IDA m'a sauvé le cul pendant le développement, où j'ai une erreur de l'éditeur de liens qui me rend fou, et j'ouvre simplement les objets incriminés dans le désassembleur et tout devient clair. De même pour les choses que je jurerais sont des "erreurs de compilation" qui s'avèrent être de ma faute. Et cette expérience m'aide également à déboguer beaucoup mieux mon logiciel.
Bons points! Surtout sur les produits concurrents de l'ingénierie inverse. Je me souviens avoir dû renverser d'autres emballeurs lorsque PECompact était en développement il y a plus de dix ans, car je ne pouvais pas comprendre comment dans le monde ils étaient si serrés. J'ai trouvé la réponse en inversant: BCJ2 (x86 jmp / optimisation du décalage d'appel). À l'époque, c'était une révélation!
+1 pour le piratage de firmware et le développement de firmware. En fait, je me suis retrouvé à faire des RE triviaux lors du développement de petits projets de robotique ou d'autres projets matériels / logiciels ... Et de nombreuses entreprises, bien que ne mentionnant pas explicitement l'ingénierie inverse comme une très «rédacteur technique» et non un véritable développeur de logiciels.
Dougall
2013-04-15 05:16:23 UTC
view on stackexchange narkive permalink

Personne ne semble encore avoir mentionné la compatibilité. Je sais que ce n'est pas la chose la plus importante pour laquelle l'inversion est utilisée, mais créer un logiciel compatible avec des formats de fichiers ou des protocoles propriétaires est très important, assez courant et explicitement protégé par la loi dans certains pays.

Souvent , un développeur peut utiliser l'inversion comme une «compétence complémentaire», mais dans de nombreux cas, il serait logique que ce soit le travail de quelqu'un. Par exemple, lorsque vous utilisez des techniques de salle blanche, ou si le format de fichier ou le protocole est excessivement complexe.

Remko
2013-04-16 02:13:24 UTC
view on stackexchange narkive permalink

Probablement une niche, mais mes compétences en RE aident souvent à faire fonctionner les applications (CR) dans des environnements virtuels tels que Citrix XenApp / XenDesktop.

J'écris beaucoup sur ces expériences sur mon blog.

Avertissement d'auto-promotion : voici quelques exemples récents:

broadway
2013-04-15 00:10:02 UTC
view on stackexchange narkive permalink

Le secteur de la sécurité est probablement le plus gros utilisateur de la rétro-ingénierie. Analyse des logiciels malveillants, analyse des binaires pour les vulnérabilités de sécurité potentielles et analyse des correctifs pour écrire des signatures de produits de sécurité.



Ce Q&R a été automatiquement traduit de la langue anglaise.Le contenu original est disponible sur stackexchange, que nous remercions pour la licence cc by-sa 3.0 sous laquelle il est distribué.
Loading...