Aegis : pourquoi le code change-t-il à 60 secondes ?

01. Passez de 59 à 60 secondes

Cliquez sur les deux boutons de temps ci-dessous. Avec la clé de test publique fixée, 59 secondes donnent 287082; 60 secondes donnent 359152. Revenez à 30 secondes : le premier code réapparaît, car 30 et 59 appartiennent à la même période.

Ces valeurs utilisent les secondes écoulées depuis l’époque Unix, pas les secondes affichées sur votre horloge. La démonstration implémente le TOTP standard avec la clé ASCII publique 12345678901234567890. Elle ne lit aucun coffre Aegis et n’utilise aucun secret de compte.

02. Trouvez la méthode fondée sur le temps dans l’APK

Le rapport officiel REA a inspecté Aegis v3.4.3 avec REA 6.1.0. Pour suivre la même piste, obtenez cette version, notez son empreinte et recherchez la classe TOTP. Les commandes ci-dessous utilisent REA 6.4.0.

npx -y [email protected] inspect-android-package "/absolute/path/aegis-v3.4.3.apk" --json
npx -y [email protected] search-android-classes "/absolute/path/aegis-v3.4.3.apk" Totp --json

Utilisez le nom exact de classe renvoyé pour inspecter ses membres. La surcharge de getOtp qui accepte un horodatage est utile, car elle permet de fournir le temps directement. Sélectionnez-la dans l’inventaire au lieu de supposer que la première méthode portant ce nom convient.

Utilise REA pour inspecter la classe TotpInfo dans /absolute/path/aegis-v3.4.3.apk. Sélectionne la surcharge de getOtp qui accepte un horodatage. Suis ses appels à travers l’encodage du compteur, HMAC, la troncature et le formatage décimal. Retrouve la période, la fonction de hachage et le nombre de chiffres par défaut. Cite chaque méthode inspectée et distingue les valeurs par défaut des réglages propres à chaque compte. N’exécute pas l’APK.

03. Retrouvez le calcul complet

Trouver une division par 30 n’est que le début. Le rapport du projet relie cinq étapes : ramener le temps à un compteur par arrondi inférieur ; encoder ce compteur sur huit octets en ordre gros-boutiste ; calculer HMAC avec la clé ; sélectionner une valeur positive sur 31 bits dans le hachage ; la ramener à six chiffres en conservant les zéros initiaux.

Suivez les appels de méthodes renvoyés au lieu de vous fier à des noms de code familiers. Dans la version inspectée, l’optimisation a placé les fonctions auxiliaires de génération sous kotlin.ExceptionsKt. Le rapport distingue aussi les valeurs par défaut — SHA-1, six chiffres et 30 secondes — des réglages propres à chaque compte.

04. Reconstruisez la règle et testez les limites

Implémentez indépendamment le comportement retrouvé, puis utilisez des vecteurs de référence publics. Testez juste avant et après un changement de période, un résultat commençant par zéro et des sorties à six et huit chiffres. Deux périodes adjacentes n’ont pas nécessairement des codes différents, même si c’est le cas dans cet exemple.

Écris une petite implémentation TOTP indépendante de ce comportement. Utilise uniquement les clés de test publiques du RFC 6238. Vérifie les six horodatages de référence SHA-1 à huit chiffres et leurs restes à six chiffres. Teste les limites 29/30 et 59/60 et préserve les zéros initiaux. Explique tout écart avec la méthode inspectée ; ne prétends pas reconstruire le coffre ou l’application Android.

05. Comprenez ce que signifient « 133 vérifications »

Le projet indique une concordance sur 133 entrées entre un banc de test JVM assemblé à partir de méthodes décompilées sélectionnées et des reconstructions indépendantes. Il n’a pas lancé l’APK original. Cela étaye le calcul choisi, pas une équivalence complète de l’application.

Pour ce site, nous avons écrit une démonstration WebCrypto distincte et vérifié les six vecteurs SHA-1 publiés avec deux longueurs de code, ainsi que chaque seconde entière de 0 à 120, face à une implémentation HMAC Node séparée. Nous n’avons pas reproduit l’investigation originale de l’APK ni son banc de test Java.

Vous découvrez l’outil ? Qu’est-ce que REA ? · Comment nous vérifions nos guides