Runbook : Trigona (RNG / IV OFB)

Corpus#

Outils : PyGhidra (analyse headless), objdump, pefile, scripts maison dans tools/ (list_functions.py, decompile_addr.py, decompile_by_name.py, find_api_callers.py, find_constant_refs.py, find_string_refs.py, find_data_refs.py, crack_api_hash.py, trigona_iv_poc.py). Aucune exécution réelle de l'échantillon.

Deux fonctions touchent au seed, une seule compte#

Sur le build 2023, FUN_004073a4 lit QueryPerformanceCounter/ GetTickCount dans une variable locale, appelle Random(MaxInt), puis appelle un pointeur de fonction, sans jamais écrire la valeur QPC lue nulle part. Prise seule, elle laisserait croire que Randomize() est du code mort et que RandSeed reste à 0. Ce n'est pas le cas.

La recherche des références de données sur l'adresse de RandSeed (find_data_refs.py, DAT_004ed008) fait sortir une seconde fonction, FUN_004e6cac, qui elle écrit réellement dans RandSeed :

FUN_004d55c8(&local_8, 4);       // 4 octets de bruit temporel genuine
iVar1 = FUN_004d413c(&local_8);  // 4 octets -> entier 32 bits
*(int *)PTR_DAT_004f4078 = iVar1; // ecriture dans RandSeed

Vérification par désassemblage brut (pas seulement le C décompilé) :

4e6cd4: mov edx, [0x4f4078]
4e6cda: mov [edx], eax

et lecture des octets bruts de .data à l'adresse 0x4f4078 : 08 d0 4e 00 = 0x004ed008 en little-endian, soit exactement l'adresse de RandSeed. FUN_004e6cac est appelée de manière inconditionnelle, en tout premier dans entry (004ebdeb), avant tout autre traitement.

FUN_004d55c8/FUN_004d413c ne sont pas une source faible : elles collectent le bruit de gigue via des paires QueryPerformanceCounter consécutives (FUN_004d54a4, 1000 itérations x 8 bits, plus 8 tours de Sleep(1)), la même technique haute qualité utilisée pour la clé maîtresse AES. RandSeed est donc correctement initialisé avec de l'entropie réelle dès le démarrage, sur les quatre builds (vérifié explicitement sur 2023, 2025, 2026 ; structurellement identique sur 2024 vu l'adresse-à-adresse identique avec 2025). Le code mort de FUN_004073a4 existe bien, mais c'est un artefact inoffensif à côté du vrai mécanisme de seed.

Conséquence pour l'analyse : abandon complet de l'hypothèse initiale. La vraie faiblesse à chercher n'est pas "graine nulle/prévisible" mais la manière dont ce flux Random(), correctement seedé une fois, est ensuite consommé.

Reconstruction de l'architecture réelle (build 2023, i386)#

1. entry (004eb98c) appelle FUN_004e6cac() (seed réel), puis FUN_004073f4(10) (délai de démarrage), puis lance deux threads (FUN_00409df4/CreateThread) avec points d'entrée LAB_004e5984 et DAT_004e6a54.
2. Le thread 004e5984 (force la création de fonction Ghidra via CreateFunctionCmd, non détectée par l'auto-analyse) : - appelle FUN_004e3228 une seule fois, au tout début, qui génère 32 octets de cle via le même collecteur de gigue haute qualité (FUN_004d54a4) ; - boucle ensuite sur les 26 lettres de lecteur (A: à Z:, iVar5 != 0x1a) et appelle FUN_004e5220 pour chaque lecteur prêt, en réutilisant la même cle tout du long ; - effacé la clé en mémoire seulement après la boucle complète.
3. FUN_004e5220 -> FUN_004e45b4 -> FUN_004e34e4 construit l'IV par fichier : do { uVar1 = FUN_004073f4(0x100); // Random(256) *(char*)(*param_1 + iVar2) = (char)uVar1; iVar2++; } while (iVar2 != 0x10); // 16 octets Aucun re-seed entre les appels : chaque octet est le tirage suivant du même flux LCG global (DAT_004ed008).
4. FUN_004e2bdc construit le footer écrit en fin de fichier chiffré. Le paramètre param_3 de cette fonction est exactement l'adresse de l'IV généré à l'étape 3 ; FUN_00407104 (memcpy) le copie en clair à l'offset 2 du footer (16 octets), avant taille de fichier, nom original et identifiant de campagne, suivi d'un motif fixe de 4 octets 0x53 ('S') répétés à intervalles réguliers (marqueur de format).
5. Pour les fichiers de plus de 1 Mio, FUN_004e3a08 boucle par blocs de 0x100000 (1 Mio) et appelle FUN_004e37bc -> FUN_004db93c à chaque tour (voir section dédiée ci-dessous sur le défaut de réutilisation de flux). FUN_004e3aac/FUN_004e37bc avec un 0x80000 (512 Ko) fixe et un offset fichier codé en dur à 0 est un chemin distinct, réserve aux petits fichiers tenant en un seul appel.

Défaut majeur : le registre OFB repart du même IV à chaque bloc de 1 Mio#

Découverte en poussant la vérification du build 2026 au-delà de la question initiale "clé/IV suffisamment aléatoires", puis retrouvée à l'identique sur le build 2023 par retour en arrière : la boucle de traitement des fichiers de plus de 1 Mio ne fait jamais progresser l'IV (ni l'état OFB) d'un bloc au suivant. Chaque bloc de 1 Mio d'un même fichier est chiffré avec exactement le même flux de clé.

Build 2023 (i386) : FUN_004e3a08 boucle avec DVar1 = 0x100000 et appelle FUN_004e37bc(param_1, DVar1, param_2, param_4, param_5, local_8, local_14, local_10) a chaque tour ; seul local_14/local_10 (position dans le fichier) avance, param_2 (le pointeur d'IV) est identique à tous les tours. FUN_004e37bc transmet ce pointeur à FUN_004db93c, qui réinitialisé le registre OFB depuis *param_3 en tête de fonction, à chaque appel :

FUN_00407104((longlong*)*param_3,(longlong*)local_c,(longlong*)0x10); // registre = IV
for (...) { registre = Encrypt(registre); ciphertext = plaintext ^ registre; }

Le chaînage interne à un seul appel (donc à un seul bloc de 1 Mio) est correct ; c'est l'absence de progression entre deux appels qui casse tout.

Build 2026 (x64) : même défaut, code totalement différent. La boucle FUN_00441870/FUN_00441960 appelle FUN_00441360 par bloc de 1 Mio en transmettant le même pointeur d'IV (param_4) à chaque tour. FUN_00441360 appelle FUN_00437f60, qui appelle FUN_00437da0 (Init clé+IV, copie l'IV dans le contexte AES) puis chaîne correctement le registre OFB à l'intérieur de l'appel, avant de l'effacer en fin de fonction (FUN_00406a30(local_38,0x10,0)) sans jamais le renvoyer à l'appelant. FUN_00437540 est confirmé être une implémentation AES par T-tables classique (DAT_0046b0f8 etc.), donc FUN_00437f60 est bien un DCPrijndael-équivalent en mode OFB, pas un chiffrement maison.

Vérifié sur les deux binaires : aucune écriture vers le pointeur d'IV n'existe entre deux appels consécutifs de la fonction de traitement par bloc. La taille de bloc (0x100000) est identique sur les deux builds.

Preuve de concept : tools/trigona_chunk_reuse_poc.py, avec une vraie implémentation AES-OFB (pycryptodome), reproduit ce comportement exact sur un fichier synthétique de deux blocs de 1 Mio. Résultat vérifié : XOR direct des deux blocs de texte chiffré = XOR exact des deux blocs de texte clair sur les 1 048 576 octets ; avec 64 octets de texte clair connus pour le premier bloc, les 64 octets correspondants du second bloc sont récupérés à l'identique.

Portée non entièrement revirifiée : confirmé par désassemblage sur 2023 et 2026 uniquement. Très probable sur 2024/2025 vu l'identité totale du reste du code entre ces builds et 2023, mais pas revérifié instruction par instruction (voir section Non résolu).

Vérification LCG : constantes et wrapper (identiques sur les 4 builds)#

Fonction d'avancement, identique partout (const_refs sur 0x8088405) :

DAT_xxx = DAT_xxx * 0x8088405 + 1;

c'est exactement System.Random/RandSeed du RTL Borland/Delphi.

Construction de l'IV par fichier, retrouvée identique : - 2023 : FUN_004e34e4, boucle iVar2 != 0x10 sur FUN_004073f4(0x100) - 2025 : FUN_0042fa98, boucle iVar2 != 0x10 sur FUN_004049d0(0x100) (adresses identiques 2024/2025, non re-vérifié octet à octet sur le binaire 2024 UPX-unpacked distinct, mais même layout mémoire confirmé par ailleurs sur plusieurs autres fonctions)

Build 2026 (x64) : architecture RNG remaniée, tranchée après poursuite de l'analyse#

Poursuite demandée explicitement pour trancher le point laissé ouvert. Deux générateurs distincts coexistent sur ce build, avec des sorts différents.

Clé maîtresse : durcie et rotée dans le temps. - FUN_00434480 est confirmé être MD5 (constantes d'initialisation 0x67452301, 0xefcdab89, 0x98badcfe, 0x10325476, structure Init/Update/Final classique via FUN_004342e0/FUN_00434320/FUN_004343e0), pas SHA-256. - FUN_00405e60, appelée en tout premier dans entry (0045e1fd), lit QueryPerformanceCounter, la XORe avec un tirage Random(MaxInt), et réinjecte le résultat dans RandSeed via FUN_00405e50. Contrairement à FUN_004073a4 sur le build 2023, ici la valeur QPC est réellement utilisée. - FUN_00435990 remplit un pool de 64 octets (DAT_0047c700) via 64 tirages Random(256) (le LCG faible) -- un remplissage provisoire, appelé à être recouvert. - FUN_00436510(0x10) puis FUN_00436510(0xf0) (16 puis 240 tours, message de progression retrouvé dans le binaire : "Generate randomizer noice. Please await 15 seconds...") appellent chacun FUN_00435a50, qui mesure le nombre d'itérations d'une boucle d'attente active entre deux changements de valeur de GetTickCount (une vraie source de gigue système), combine ce compte avec 2 octets extraits du pool courant, puis FUN_00435bb0 XOR ce résultat (après hachage MD5 de plusieurs vues permutées) directement dans DAT_0047c700. Le pool est donc réellement réamorcé par du bruit temporel authentique 256 fois avant que quoi que ce soit n'en soit extrait pour un usage cryptographique -- le hachage nécessaire pour ce remaniement a bien été localisé, il ne s'agit pas de MD5 servant seul de source d'aléa mais de vecteur de mélange. - L'extraction réelle de la clé passé par FUN_00436c70 -> FUN_004367e0 (le pool durci, pas le LCG brut) : FUN_004403e0 génère 32 octets ainsi, utilisés comme clé maîtresse par FUN_004404a0 ("Generate master key." / "Encrypt internal data." / "Init tail." -- messages de debug retrouvés dans le binaire). - FUN_004404a0 est appelé depuis l'intérieur des threads de fichiers (FUN_0044e520, FUN_0044e990, FUN_00450a90, FUN_00450e30, FUN_0045cb40, FUN_0044ce60, FUN_00449990, FUN_0045c300), pas seulement une fois au démarrage. Trace dans FUN_00449990 (le parcours-et-chiffrement par lecteur, appelé une fois par lecteur comme sur 2023) : la régénération de clé est conditionnée par le temps écoulé depuis la dernière génération (GetTickCount() - *param_10 comparé à un seuil configure), vérifiée avant CHAQUE fichier. La clé tourne donc périodiquement dans le temps, pas seulement une fois par lecteur comme sur 2023-2025 -- une fenêtre d'exposition par clé plus petite, sans toutefois réduire à zéro le risque de collision (le nombre de fichiers traités pendant une fenêtre de rotation dépend d'un seuil non déterminé sans exécution réelle).

IV par fichier : toujours le LCG faible, non durci. FUN_00441130 (appelée juste avant la sélection du chemin de chiffrement adapté à la taille du fichier, dans FUN_00443320) génère les 16 octets de l'IV ainsi :

do {
    uVar1 = FUN_00405ec0(0x100);        // Random(256), LCG BRUT, pas le pool durci
    *(char*)(*param_1 + iVar2) = (char)uVar1;
    iVar2++;
} while (iVar2 != 0x10);

Mécanisme identique, instruction pour instruction, à FUN_0042fa98 (2025) et FUN_004e34e4 (2023). Le durcissement appliqué à la clé n'a pas été applique à l'IV : deux générateurs distincts dans le même binaire, un corrige, l'autre non.

Conclusion pour ce build : la clé maîtresse est saine et désormais rotée dans le temps (amélioration réelle par rapport à 2023-2025) ; l'IV par fichier reste vulnérable de façon identique aux builds précédents ; et le défaut indépendant de réutilisation de flux intra-fichier par bloc de 1 Mio (section dédiée plus haut) est confirmé présent sur ce build aussi, ce qui rend la question de la qualité de la clé largement secondaire pour tout fichier de plus de 1 Mio.

Preuve de concept (IV prédictible)#

tools/trigona_chunk_reuse_poc.py : voir la section dédiée au défaut de réutilisation de flux intra-fichier plus haut, PoC AES-OFB réelle (pycryptodome) sur ce défaut la, indépendant de la piste LCG ci-dessous.

tools/trigona_iv_poc.py : réimplémentation exacte du LCG (mult=0x8088405, inc=1, mod 2^32) et de la construction d'IV (16x Random(256)). Démontré, à partir d'une graine de départ totalement inconnue :

1. génération de l'IV du "fichier 1"
2. récupération exacte de l'état interne à partir de ce seul IV (recherche sur les 24 bits bas seulement, rejet quasi immédiat des mauvais candidats des le deuxième octet comparé, quelques secondes en Python pur)
3. prédiction exacte de l'IV du "fichier 2" (vérifié bit a bit contre la valeur réelle)

Exécution vérifiée : la graine plantée (0xCAFEBABE) est retrouvée à l'identique, et les deux IV prédits correspondent exactement aux IV réels.

Calcul de la borne d'anniversaire sur l'espace d'état 32 bits : environ 54 500 fichiers chiffrés par le même thread suffisent pour une probabilité de 50% qu'au moins deux fichiers reçoivent un IV strictement identique (même clé, même flux non re-seede), ce qui est une échelle réaliste pour un partage fichier ou un parc de plusieurs lecteurs locaux.

Non résolu#

• Format exact du wrapping de la clé maîtresse (RSA ou autre) : aucune chaîne RSA1/BEGIN PUBLIC KEY trouvée dans le binaire 2023 ; mécanisme d'enveloppement de clé non retracé au-delà de la construction du footer.
• Deuxième thread (partages réseau, point d'entrée DAT_004e6a54) non retracé indépendamment ; très probablement mêmes fonctions partagées que le thread lecteurs locaux, non confirmé instruction par instruction.
• Défaut de réutilisation de flux intra-fichier (bloc de 1 Mio) : confirmé par désassemblage sur 2023 et 2026 uniquement. Non revérifié indépendamment sur 2024/2025 (très probable vu l'identité du reste du code entre ces builds, mais pas confirmé instruction par instruction).
• Seuil exact de rotation de clé sur le build 2026 (durée ou nombre de fichiers entre deux régénérations) : logique de rotation confirmée, valeur du seuil non déterminée sans exécution réelle.