Comme ce n'est pas difficile à deviner, la théière, c'est moi.
L'autre jour, j'ai voulu rechercher la source d'un utilitaire, évidemment créé à l'aide d'outils AMS (fichier .cdd à côté de .exe et quelques lua * .dll). Il y a quelques années, j'ai analysé en détail un programme créé par des moyens similaires et l'idée d'emballer .cdd, qui est une archive zip régulière avec un mot de passe, est disponible. Eh bien, sans hésitation,
j'ai poussé
AMSUnpacker et
j'ai reçu une erreur de déballage. Eh bien, à partir de ce moment, le plaisir a commencé ...
La première pensée qui m'est venue à l'esprit était que le fichier était emballé avec autre chose que UPX (que j'ai naturellement décompressé). Eh bien, je ne l'ai juste pas vérifié (DIE, Exeinfo PE, Nauz File Detector) et tout le monde me convainc que non, ce n'est pas emballé. Eh bien, je pense que je vais comparer le banal .exe en utilisant Total Commander avec le programme précédemment décompressé et celui-ci, et il s'est avéré que .exe est très différent (j'avais l'habitude de comparer d'autres programmes sur AMS et la différence était uniquement en octets uniques, en fait, dans un mot de passe écrit en texte clair juste en .exe lui-même et dans la partie ressources). Il est devenu clair qu'il s'agit soit d'une sorte de modification, mais simplement d'une nouvelle version d'AMS. J'ai cru en ce dernier avec difficulté, sachant (enfin, je pensais d'abord que je savais) que les développeurs avaient battu le programme depuis longtemps, mais n'ont pas commencé à le vérifier si c'était le cas ou non, et il n'aurait presque rien donné.
J'ai commencé à fouiller dans plus de détails, en quelque sorte dans x64dbg, avec lequel sur «You», j'ai trouvé dans l'ancienne version du programme un endroit où le mot de passe est «lu». Après avoir fouillé le même x64dbg dans la "nouvelle" version, il s'est avéré qu'ils ne sont pas si différents, mais il contient simplement plus de fonctions que dans l'ancienne. J'ai trouvé un endroit similaire où, au lieu de la convoitée
<adresse où le mot de passe est stocké>, il y avait une sorte de
mov <quelque chose là-bas> et plusieurs appels à d'autres fonctions, et quelques lignes sous le code sont similaires à celle de l'ancienne version.
(à gauche est l'ancienne version, à droite la nouvelle)Et ici, j'étais triste, car mes connaissances en débogueur ne sont clairement pas suffisantes pour comprendre tout cela.
Il y avait une pensée - pour trouver un autre programme similaire non compressable et comparer leur .exe. Un tel programme a été trouvé par le même auteur que celui que j'ai essayé de déballer. Et la comparaison des fichiers a donné son résultat. En plus des différences mineures, un bloc entier de diverses données a été trouvé:
Et la joie d'avoir trouvé cet endroit unique où apparemment le mot de passe était contenu, et la déception qu'il ne s'agissait clairement pas d'un mot de passe, sous la forme comme dans les versions précédentes.
Il n'y avait pas d'autre choix que de comprendre le débogueur. Tout le "problème" est que je connais l'assembleur au niveau de plusieurs commandes, avec une représentation très superficielle de ce qu'ils font, et le débogueur lui-même est au niveau de plusieurs vidéos regardées sur youtube et avec peu d'expérience dans son utilisation, principalement par la "méthode poke".
Après une heure de fonctionnement du débogueur et d'innombrables redémarrages, j'ai trouvé en quelque sorte un endroit où les octets convoités sont lus et un peu plus tard, j'ai trouvé un morceau de code qui fait une certaine manipulation de ces octets:
Il a fallu beaucoup de temps pour comprendre ce qui se faisait là-bas.
D'une certaine manière, j'ai compris qu'il s'agit d'une sorte de pavé de chiffrement, où il y a deux tables, l'une est un mot de passe crypté, où le caractère correspondant indique simplement la position dans le deuxième bloc-notes.
En général, en remplaçant les valeurs du tableau inférieur par les valeurs correspondantes du tableau supérieur, nous obtenons un tableau d'octets:
7B 10 DD 5A 4D 26 72 EE B2 2A 04 2B 6E F7 14 E2 F9 14 F8 9E 8A 99 28 AE B8 4B C0 D7 42 DA AD .
Pour quels autres tableaux d'octets uniques, avant et après avoir eu besoin de décrypter le mot de passe, je ne comprenais pas, mais je ne m'y suis pas vraiment plongé. Je soupçonne qu'il y a des sommes de contrôle ...
Et puis c'est à vous de le convertir en chaîne et de décompresser l'archive .cdd chérie avec ce mot de passe. Un petit problème était que la ligne résultante ne pouvait pas être insérée dans l'archiveur via Ctrl + C -> Ctrl-V, car les personnages "se cassent" dans le presse-papiers (surtout ne se sont pas plongés dans l'essence). Le déballage n'est possible que par programme. Heureusement, il y a une certaine connaissance de C # (dont le niveau en général n'est pas très différent du niveau de connaissance du débogueur) et peu d'expérience dans l'étude du principe de fonctionnement de l'AMSUnpacker mentionné précédemment, qui est également écrit en C # et il n'est pas difficile de voir de quoi il s'agit et comment.
Presque à genoux, il a empilé un utilitaire pour vérifier l'opérabilité de l'algorithme précédemment étudié, et le tour est joué.
Vous pouvez le télécharger
ici .
Le programme, similaire à l'AMSUnpacker mentionné précédemment, crée le dossier extract_cdd à côté du .exe avec le contenu de l'archive .cdd.
Après avoir décompressé avec succès le fichier convoité .cdd, j'ai appris qu'il s'agit de la "nouvelle" version (à partir de fin 2018) AMS 8.5.3.0. Et sur le site Web, ils ont lu sur la nouvelle version:
Fonctionnalité: Amélioration de la sécurité du fichier de données de la version commerciale. . Eh bien, apparemment, cela n'a pas très bien fonctionné ...
J'ai une question pour ceux qui savent, un tel algorithme pour cacher un mot de passe, fait-il partie d'un algorithme de cryptage standard (je veux dire qu'il est maintenant applicable dans les programmes, et non historiquement), ou est-ce, très probablement, les développeurs y ont pensé?
PS Je sais qu'il est plus facile d'obtenir le code source des programmes lua (qui utilise AMS) via le lua * .dll patché, qui surfe sur Internet et / ou le hook externe de la fonction lua_load () dans le même lua * .dll. C'est tout ce que j'ai fait. Dans cette situation, c'était un intérêt purement sportif de comprendre comment obtenir un mot de passe pour .cdd. Et je comprends aussi très bien qu'il est peu probable que quelqu'un en ait besoin et n'a aucune valeur pratique.
J'ai probablement exagéré en ce qui concerne la "théière", car il y a peu d'expérience en programmation et en reverse, mais ce n'est qu'un petit passe-temps "pour moi" et il n'y a pas beaucoup de temps ou de désir pour approfondir cela.
PPS Ceci est mon premier article sur Habré, comme, probablement, généralement le premier de ce type.