Question:
Enregistrement des étiquettes et des commentaires dans Immunity Debugger
AK-33
2015-08-21 13:47:43 UTC
view on stackexchange narkive permalink

J'utilise Immunity Dbg v1.85 (la dernière version en date). J'ai passé environ une heure à analyser un logiciel malveillant, tout en faisant des commentaires et en renommant des fonctions de quelque chose comme X.00402AC0 à quelque chose de plus utile comme X.password_checker. Après avoir corrigé le logiciel malveillant pour ignorer la fonction de vérification de mot de passe (Copier dans l'exécutable> Toutes les modifications) et l'avoir enregistré dans un nouveau fichier, je vois que tous mes commentaires et modifications d'étiquettes ont disparu lors de l'ouverture de la version corrigée dans le débogueur.

Ce qui est intéressant, c'est que lorsque vous arrêtez le débogueur puis que vous rouvrez l'exécutable d'origine non corrigé, les commentaires et les étiquettes restent. Ce n'est que lorsque vous enregistrez des modifications binaires dans un nouveau fichier qu'elles sont perdues. Inutile de dire que c'est un énorme inconvénient lorsque vous travaillez sur des binaires complexes qui doivent être corrigés et partagés.

Existe-t-il un moyen d'enregistrer les modifications apportées aux étiquettes et les commentaires sur les nouveaux exécutables dans Immunity?

Deux réponses:
Vitaly Osipov
2015-08-23 03:41:41 UTC
view on stackexchange narkive permalink

Google trouve ces liens. Aident-ils?

http://www.openrce.org/forums/posts/2072

http: //fumalwareanalysis.blogspot .com / 2012/01 / tutoriel-analyse-malware-12-debug.html

Merci pour ton aide. J'ai besoin de les étudier en détail et d'expérimenter. Ces didacticiels concernent l'enregistrement des commentaires lors de l'analyse d'un exécutable et la procédure à suivre si les commentaires ne sont pas enregistrés lorsque vous travaillez avec des fichiers DLL appelés par l'exécutable. Lorsque vous corrigez un binaire, vous l'enregistrez dans un nouvel exécutable, et le nouveau fichier UDD n'est pas créé tant que le nouvel exécutable n'est pas ouvert, donc je ne pense pas que les données enregistrées dans l'exécutable original UDD soient jamais transférées.
Dans mes propres recherches, je suis tombé quelque part sur le fait que ce que je veux faire est possible dans OllyDbg 2.0. Je vais peut-être devoir mordre la balle et changer. Ughhh ...
Igor Skochinsky
2017-09-11 21:44:25 UTC
view on stackexchange narkive permalink

Pour préserver les informations du fil de discussion OpenRCE mentionné, j'ai collé les informations pertinentes ici:

D'autres raisons pour lesquelles OllyDbg v1.10 supprime les données .UDD sont :

1) Un changement dans le chemin du fichier par exemple xxx.exe a été déplacé de "c: \ xxx.exe" vers "c: \ new \ xxx.exe".

Vous pouvez définir l'option "Ignorer le chemin et l'extension" pour contourner cette vérification.

2) Une modification de l'heure de dernière écriture du fichier.

Vous pouvez définir l'option "Ignorer l'horodatage" pour contourner cette vérification.

3) A changement dans le CRC de la section de code depuis la dernière session.

Vous pouvez définir l'option "Ignorer CRC de la section de code" pour contourner cette vérification.

Je pense que vous avez le cas 3.



ⓘ
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...