Come funziona un autenticatore
generare un codice di accesso?

Chiedi al tuo agente

L'app mostra un codice di accesso che cambia. Vogliamo trovare cosa lo fa cambiare riprodurre questo comportamento.

Un prompt di esempio per il APK scaricato, con l'analisi Android di REA configurata. Ottenere il APK e la configurazione di analisi ↓

Prova il generatore di codice

L'app raggruppa il tempo in blocchi di 30 secondi. Combina il numero di blocco con la chiave dell'account per generare un codice. La stessa chiave e blocco producono lo stesso codice.

Trova il codice con REA

1. Restringere il APK a tre classi

   Agente → REA

   inspect_android_package
   {"path": "aegis-v3.4.3.apk"}
   
   search_android_classes
   {"path": "aegis-v3.4.3.apk",
    "query": "Totp"}

   REA → agente * risultati selezionati

   Package: com.beemdevelopment.aegis
   Version: 3.4.3
   Classes: 3,077
   
   Three matches:
     otp.TotpInfo
     ui.views.TotpProgressBar
     importers.TotpAuthenticatorImporter

   TotpInfo è il candidato di calcolo; gli altri due riguardano la barra di avanzamento e gli account importati. TOTP indica una password una tantum basata sul tempo.

2. Collegare il generatore al display dell'app

   Agente → REA

   inspect_android_class
   {"path": "aegis-v3.4.3.apk",
    "class_name":
     "com.beemdevelopment.aegis.otp.TotpInfo"}
   
   trace_android_references
   {"path": "aegis-v3.4.3.apk",
    "class_name":
     "com.beemdevelopment.aegis.otp.OtpInfo",
    "method_name": "getOtp"}

   REA → agente * metodi e chiamanti

   TotpInfo methods:
     getOtp()      · overload 0
     getOtp(long)  · overload 1
   
   OtpInfo.getOtp callers:
     ui.views.EntryHolder.getOtp
     ui.MainActivity.copyEntryCode

   REA identifica il sovraccarico timestamp e trova i chiamanti del metodo di base. Ispezionare EntryHolder.getOtp poi mostra il display chiamata TotpInfo.getOtp(timestamp).

Le richieste mostrano un percorso di input abbreviato. I nomi delle classi dei risultati omettono il comune com.beemdevelopment.aegis prefisso.

Leggi il calcolo

REA restituisce la conversione dell'orologio, le impostazioni predefinite e i metodi di generazione. I costruttori impostano un intervallo di 30 secondi e sei cifre; il metodo timestamp trasforma i secondi in un numero di blocco.

// TotpInfo defaults and clock
setPeriod(30);
getOtp(System.currentTimeMillis() / 1000);

// OtpInfo default algorithm and digits
this(bArr, "SHA1", 6);

// Block passed to the generator
(long) Math.floor(j / ((double) this._period))

// generateOTP → getHash
byte[] hash = getHash(bArr, str, j);

// getHash: account key + encoded block
Mac mac = Mac.getInstance(str);
mac.init(secretKeySpec);
return mac.doFinal(bArrArray);

// OTP.toString, case 0
this._code % ((int) Math.pow(10.0d, i))

// Keep leading zeroes
while (sb.length() < i) {
    sb.insert(0, "0");
}

// Group time into 30-second blocks
seconds = current_time_ms / 1000
block = floor(seconds / 30)

// Generate a number from the key and block
hash = HMAC_SHA1(account_key,
                 big_endian_8_bytes(block))
number = select_31_bits(hash)

// Format the default six-digit code
code = number % 1_000_000
code = pad_with_zeroes(code, 6)

Estratti da diversi metodi ispezionati, con avvolgimento di linea per la visualizzazione. Il pannello di destra è un riassunto esplicativo. Il codice Aegis è GPL-3.0.

public static OTP generateOTP(byte[] bArr, String str,
        int i, long j)
        throws NoSuchAlgorithmException, InvalidKeyException {
    byte[] hash = getHash(bArr, str, j);
    int i2 = hash[hash.length - 1] & 15;
    return new OTP(
        (hash[i2 + 3] & 255)
        | ((hash[i2] & 127) << 24)
        | ((hash[i2 + 1] & 255) << 16)
        | ((hash[i2 + 2] & 255) << 8), i, 0);
}

Controlla la ricostruzione

Abbiamo assemblato i metodi Java restituiti da REA selezionati in un piccolo programma di test. La loro produzione corrispondeva a una ricostruzione indipendente su 133 casi di prova, compresi i limiti del blocco temporale e i codici che iniziano con zero.

Il generatore corrisponde anche ai sei casi di riferimento SHA-1 pubblicati in RFC 6238. Controlla l'implementazione del browser contro di loro:

I casi di riferimento utilizzano otto cifre. Il controllo verifica anche i loro risultati a sei cifre.

Verifica esegue metodi Java estratti e la nuova demo. L'Android APK è stato ispezionato staticamente.

Ispezionare il APK da soli

Impostare REA su macOS o Linux, quindi scaricare questi due file nella stessa cartella. Su Windows, utilizzare un ambiente Linux come WSL.

Android analysis ha bisogno di un JDK completo 17 o successivo. Selezionalo con JAVA_HOME o PATH. Questo caso ha usato JDK 21.

Puntare REA sul file del provider e ispezionare APK :

REA_JADX_MCP_JAR="$PWD/jadx-headless-mcp-0.7.1-all.jar" \
npx rea-agents@latest inspect-android-package \
  ./aegis-v3.4.3.apk --format json --full-output

Il tuo agente può continuare attraverso CLI di REA utilizzando il prompt sopra. Per MCP, aggiungere REA_JADX_MCP_JAR all'ambiente del server REA e ricollegarlo.

Una prossima domanda: cosa succede quando un account utilizza otto cifre o un intervallo di tempo diverso?

Fonte

• Rilascio ufficiale di Aegis 3.4.3 · Commit sorgente corrispondente · Licenza GPL-3.0
• RFC 6238 casi di riferimento · Dati di prova demo

Ispezionato con REA 6.1.0 il 9 ottobre 2026. Estratti decompilati sono accreditati a Aegis ; il diagramma, il riepilogo leggibile e la ricostruzione del browser sono nuovo materiale didattico.