Désormais il informe sur X.com qu'il a réalisé des scripts qu'il a écrit et qui lui permettent de décrypter tous les fichiers updates de toutes les versions ainsi que la machine virtuelle de la version 1.1.4 (seulement celle là pour le moment). Il prend part au projet du développeur 15432 qui réalise des recherches importantes pour libérer le code du mig flash. Grâce à l'excellent travail de 15432, nous pouvons enfin décrypter le code du firmware de la cartouche flash MIG. Voici ce que nous avons appris jusqu'à présent : 1) MIG est de la Team Xecuter / Gateway, ce qui n'est pas surprenant. Comme l'explique 15432, le code VM de type MIPS utilisé dans le firmware est exactement le même. On trouve également un certain nombre d'autres similitudes, telles que la pile de codes de communication FPGA qui est exactement la même que celle utilisée par le SX Core. 2) Le protocole de communication du linker (basé sur SNOW 2 et AES-CCM) est entièrement implémenté dans le firmware ESP32. MIG a inclus dans le code du firmware un élément clé auparavant introuvable (l'IV utilisé pour SNOW), qui ne pouvait être extrait qu'en décapsulant. 3) Cependant, un élément clé essentiel, la clé AES matérielle Lotus3, n'est pas visible pour l'ESP32. Au lieu de cela, ils l'ont cachée à l'intérieur du FPGA et lui demandent de décrypter les données pertinentes. Cela seul rend impossible le clonage de leur matériel, mais ce n'est pas tout. 4) Le bootloader et le firmware comportent plusieurs niveaux de vérification. Outre le système ESP32 Secure Boot (qui utilise RSA-PSS), le firmware lui-même vérifie deux fois les signatures pendant le processus de mise à jour. 5) De plus, une petite machine virtuelle MIPS gère certaines tâches critiques, notamment la vérification d'une autre signature RSA qui se trouve dans un « bloc sécurisé » (adresse flash 0x1FF000). Ce bloc contient également leurs clés firmware (cryptées) et d'autres éléments importants. 6) Les clés du firmware sont stockées sous forme cryptée et la clé permettant de les décrypter est générée par hachage (HMAC-SHA256) d'un IV unique à la puce dans le chargeur d'amorçage avec une clé HMAC unique à la puce. Cette dernière est programmée pour être effusée et verrouillée en lecture. 7) Le décryptage du fichier « update.s2 » consiste à supprimer la première couche de cryptage TEA, à analyser les métadonnées, à décrypter le code du firmware à l'aide de la clé AES appropriée et, enfin, à décoder le texte en clair obtenu à l'aide de leur algorithme personnalisé basé sur XOR. 8) Ce dernier algorithme basé sur XOR est une véritable abomination qui mélange des valeurs aléatoires et plusieurs sources dans le seul but de rendre le reverse engineering aussi difficile que possible (même Ghidra n'a pas été en mesure de produire une décompilation précise, malgré la prise en charge de Xtensa). Le travail de Hexkyz se trouve ici sous forme de scripts python.
Source: https://www.logic-sunrise.com/forums/to ... decrypter/