Quelle fonction a été utilisée pour coder ces mots de passe dans AFX?

Question

J'essaie de définir le format d'un fichier de mots de passe utilisé par une DLL LOGIN dont la source est introuvable. L’outil d’administration a été écrit en AFX. J’espère donc qu’il donnera peut-être un indice sur l’algorithme utilisé pour coder les mots de passe.

À l'aide de l'outil d'administration, nous avons deux mots de passe codés. Le premier est & Quot; dinosaur123456789 & Quot; et l'hex du cryptage est ici:

Les valeurs hexadécimales obtenues pour le mot de passe d'un dinosaure sont

00h: 4A 6E 3C 34 29 32 2E 59 51 6B 2B 4E 4F 20 47 75; Jn & Lt; 4) 2.YQk + NO Gu 10h: 6A 33 09; j3. 20h: 64 69 6E 6F 73 61 75 72 31 32 33 34 35 36 37 38; dinosaure12345678 30h: 39-30; 90

Un autre mot de passe " gertcha " est codé comme e8h: 4D 35 4C 46 53 5C 7E; GROUT M5LFS \ ~

J'ai essayé de rechercher un XOR commun, mais je n'ai rien trouvé. Les mots de passe ont la même longueur dans le fichier de mots de passe, je suppose donc qu'il s'agit d'un encodage réversible (c'était d'un autre âge!). Je me demande si les classes AFX ont pu disposer d'un moyen qui serait utilisé pour ce genre de chose?

Si quelqu'un peut travailler sur l'encodage, ce serait formidable!

Merci, Matthew

[edit:] D'abord, je passe à autre chose et je vais laisser le passé derrière nous dans la nouvelle solution. Il aurait été bien d’utiliser les anciennes données quand même. En effet, si quelqu'un veut le résoudre comme un casse-tête, j'aimerais quand même pouvoir l'utiliser.

Pour ceux qui veulent s’essayer, j’ai deux mots de passe.

Tout 'a' - un mot de passe avec 19 a: 47 7D 47 38 58 57 7C 73 59 2D 50; G} G8XW | sY-P 79 68 29 3E 44 52 31 6B 09; yh) > DR1k.

All 'b' - un mot de passe avec 16 b. 48 7D 2C 71 78 67 4B 46 49 48 5 5F; H}, qxgKFIH_ 69 7D 39 79 5E 09; i} 9a ^.

Cela m’a convaincu qu’il n’y avait pas de solution simple et qu’il y avait un retour d’information.

Answer 1

Bien, j’ai fait une analyse cryptographique rapide dessus, et jusqu’à présent, je peux vous dire que chaque mot de passe semble commencer par sa valeur ascii + 26. L’octet suivant semble être la différence entre le premier caractère du mot de passe et le second, ajouté à sa valeur ascii. La lettre 3d, je n'ai pas encore compris. Je pense qu'il est prudent de dire que vous avez affaire à une sorte de chiffrement de retour, c'est pourquoi XOR ne fournit rien. Je pense que chaque valeur d’octets dépendra de la valeur précédente.

Je peux continuer, mais ça prend beaucoup de temps. J'espère que cela peut vous aider à démarrer ou peut-être à vous donner quelques idées.

Answer 2

Mais comme la longueur de la sortie est identique à celle de l'entrée, cela ressemble à un chiffrement à clé fixe. Ce peut être un xor trivial.

Je suggère de tester les mots de passe suivants:

 * AAAAAAAA
 * aaaaaaaa
 * BBBBBBBB
 * ABABABAB
 * BABABABA
 * AAAABBBB
 * BBBBAAAA
 * AAAAAAAAAAAAAAAA
 * AAAAAAAABBBBBBBB
 * BBBBBBBBAAAAAAAA

Cela devrait peut-être nous permettre de casser le chiffrement sans ingénierie inverse de la DLL.

Answer 3

La dll peut-elle encoder des mots de passe à caractère unique? Ou même un mot de passe à zéro caractère?

Vous allez commencer par les cas de test les plus triviaux.

Answer 4

Vous envisagez peut-être ce problème sous le mauvais angle. Je pense que la meilleure raison pour comprendre comment les hachages de mots de passe sont créés est de procéder au reverse engineering de la DLL de connexion.

Je recommanderais IDA Pro pour cette tâche. Cela vaut bien le prix de l’aide qu’il vous donne, c’est l’inversion du code exécutable en un assembleur lisible. Il existe d'autres désassembleurs gratuits si vous ne voulez pas payer d'argent, mais je n'ai rien trouvé d'aussi puissant que IDA Pro. Un désassembleur / débogueur statique gratuit que je recommanderais serait PEBrowse de SmidgeonSoft , car il permet de piquer rapidement autour d’un système fonctionnant en temps réel et supporte bien la PDB pour le chargement des symboles de débogage.