Comme indiqué dans ma question précédente, j'ai été infecté par un virus de cryptage qui crypte deux blocs de 1024 octets d'un fichier donné (premier 1024 et dernier 1024) dans un type de cryptage CFB XOR personnalisé. J'ai pu mettre la main sur un décrypteur qu'une autre victime a payé (bien sûr, cela ne fonctionne pas pour moi car différentes clés) et trouver la fonction de décryptage dans IDA, mais le code généré par C était mauvais et tout l'EXE est obscurci avec une méthode personnalisée. Un utilisateur de stackexchange l'a converti en C # pour que je le comprenne mieux (Merci Edward) Pour plus d'informations à ce sujet, consultez le dernier message:
Dump IDA Pro C pour Fonction de décryptage
Donc au point. Le cryptage que ce type utilise est à peu près XOR avec une certaine ruse, donc la fonction de cryptage est à peu près la même que le décryptage. Dans le décrypteur contient une clé de 20 octets, j'ai trouvé cela en comparant 4 décrypteurs différents ensemble que les victimes ont payé, tous n'ayant qu'une différence de 20 octets tous dans la même zone, et en le confirmant plus tard dans l'IDA lorsqu'il est poussé sur le
Même si la clé est de 20 octets, seulement 16 sont utilisés dans le cryptage et 4 est utilisé pour générer un en-tête pour chaque fichier crypté afin que le décrypteur puisse les trouver plus tard. Donc, dans ida, cela ressemble à quelque chose comme ceci:
Dword: C4 67 0E 46Dword: 99 2F D3 E4 40 BD 87 EB 8F 35 04 96 3B CE 8D 73
Je suppose que c'est 4 des octets sont utilisés dans chaque 512 blocs chiffrés, deux 512 blocs étant CFB l'un à l'autre pour former 2 1024 blocs de données chiffrées. Désolé si cela n'a pas de sens.
Malheureusement, le Decrypter est lourdement obscurci comme je l'ai dit, et utilise également des tonnes de JMP et de fonctions indésirables qui étaient impossibles à lire. Il a fallu une éternité pour trouver uniquement la fonction de décryptage.
Donc, pour le code, Ceci est le code nettoyé pour la fonction de décryptage (chiffrement également).
int mystery (char * buff, int bufsize, int nonce1, int nonce2) {int result = 0; // ch est le prochain octet (caractère) dans le tampon char ch = 0;
nombre int = taille bufs; char * ptr = buff; int x; for (x = nonce1; count; --count) {// ce bit de supercherie remplace juste les 8 bits bas // de x par les 8 bits bas de (x + ch) en négligeant le report, le cas échéant x = (x & ~ 0xff) | ((x + ch) & 0xff); // XOR le tampon avec la valeur x calculée * ptr ^ = x; // lire le caractère suivant dans ch ch = * ptr ++; // obscurcir en ajoutant nonce2 x + = nonce2; // si x = 0x12345678, cela le rendrait 0x34567812 // pour les entiers 32 bits. Juste une rotation à gauche de 8 bits. x = (x<<8) | ((x >> ((sizeof (int) -1) * 8)) & 0xff); } résultat = x; // renvoie le dernier x calculé qui peut être utilisé pour chaîner tous // les blocs ensemble. Autrement dit, la valeur de retour x est // probablement passée en tant que nonce1 pour encoder le bloc suivant. return result;} Au-dessus de 2 INT, les nonce nommés sont générés à partir des 16 octets d'une manière ou d'une autre.
Donc, fondamentalement, moi, et beaucoup d'autres se demandent si c'est à tous Brute force-capable ou fissurable comme XOR régulier? Bien sûr, je ne connais pas ma clé, mais presque tout le monde aurait au moins un fichier brut et chiffré pour une attaque en texte brut comme XOR si possible.
Ci-dessous, le même déchiffré (texte brut) et chiffré fichier qui va avec ce décrypteur, ainsi que le décrypteur lui-même en tant que ressources. L'exemple de clé ci-dessus est également la clé de ce décrypteur. (malheureusement sans ordre particulier)
Fichier déchiffré (texte brut)
(Cet EXE n'est en aucun cas malveillant et n'affectera aucun fichier lorsqu'il est exécuté car il détecte des fichiers cryptés. Je l'ai exécuté des centaines de fois sur mon ordinateur personnel sans faute. Il peut être attaché à un débogueur et exécuté en toute sécurité. Virus total dit autrement simplement parce que c'est un exe connu situé avec l'infection.)
Pour terminer, je crois en IDA, la fonction 4075F3 génère les nonces, mais ne peut pas être à 100%
Je suis désolé pour cela étant si long, c'est assez difficile à expliquer en même temps.