Verschleierte AES-Entschlüsselungs-Assembly

Question

Ich habe kürzlich meinen Weg durch eine ganze Ladung Assembly gesiebt, um herauszufinden, wie ein Programm einige Daten entschlüsselt. Bisher habe ich herausgefunden, wie die IV extrahiert wird, dass die IV 16 Byte lang ist und dass die Entschlüsselungsmethode Cipher Block Chaining verwendet. Folglich glaube ich, dass die verwendete Verschlüsselungsmethode AES-128-CBC ist.

Der nächste Schritt bestand darin, zu versuchen, den Schlüssel zu identifizieren, der zum Entschlüsseln verwendet wird. Das Problem besteht darin, dass die Assembly für die Verschlüsselung der einzelnen Blockchiffren ungefähr 2,5 MB groß ist. Was ich jedoch beobachtet haben, ist, dass es alle sehr ähnlicher Form vorliegt, beispielsweise ein Ausschnitt:

add.w  r0, r12, #0x13 
str.w  r0, [lr, #0x44] 
tst.w  r0, #0xff 
mov  r0, r12 
it   eq 
eoreq  r0, r12, #0x75 

add.w  r1, r12, #0x5d 
str.w  r1, [sp, #0xf00] 
tst.w  r1, #0xff 
it   eq 
addeq  r0, #0x3b 

r12 enthält die verschlüsselten Daten, aus einem in Argument übergeben geladen (r0) wie folgt:

mov  r4, r0 
add.w  lr, sp, #0x1000 
ldrb.w  r12, [r4] 

Alle der Montage in das Unterprogramm des Prototyps Form, teilweise zu den verschlüsselten Daten hinzugefügt versetzt ist, gespeichert, geprüft gegen 0xff (immer0xff) und dann einige oper Als Ergebnis wird entweder XOR, OR, ADD oder MOV ausgeführt, was sich auf ein anderes Register auswirkt (in den Beispielen ist dies r0).

Sieht Ihnen dies nach AES-128 und stimmen Sie zu, dass die Verschlüsselung absichtlich verschleiert wurde, um den Schlüssel zu verbergen? Wenn ja, wie wurde es verschleiert und wäre es möglich, den Schlüssel zu finden?

Zusatzinfo

Here's a link auf die volle ASM-Datei für die Verschlüsselung Subroutinenblock Chiffre.

Und this is a link an die Unterroutine, die CBC verwendet und das oben genannte Unterprogramm aufruft, auf das in der Hauptfrage verwiesen wird.

Answer 1

Es ist sehr einfach zu prüfen, ob AES verwendet wird.
AES/Rijndael verwendet eine große Tabelle mit magischen Konstanten.
Ohne diese magischen Zahlen kann AES nicht funktionieren.
Sie können diese Zahlen von jeder Referenzimplementierung leicht abrufen; Denken Sie daran, bei Bedarf große/kleine Endian zu kompensieren (ich überprüfe immer beide Varianten).

Auch Rijndael ist ein sehr starker Benutzer der XOR Anweisung, es verwendet or nicht und es verwendet keine Addition.

Wenn Sie AES bestätigen/ausschließen möchten, suchen Sie nach den magischen Zahlen. Die Routine muss die Nummern aus einer Tabelle irgendwo im Speicher (Diskette) lesen. Es kann die Zahlen in der Assembly nicht dekodieren, da es den Klartext/Chiffretext verwendet, um Zahlen in einem Array nachzuschlagen und xoder Daten damit.

Sie können das nicht tun, wenn Sie die Zahlen in Registern halten.

Von dem, was ich nur sehen kann, die Montage sieht es nicht wie AES überhaupt.

Test-AES Code-Review mit nur
Vielleicht ist der beste Test für AES, bei Code nur auf der Suche ist es gegen die Referenzimplementierung von init_key zu vergleichen.AES verwendet bestimmten Code, um den geheimen Schlüssel zu initialisieren, damit er vom Algorithmus verwendet werden kann.

Sie können den AES Referenz-Quellcode finden Sie hier: https://tls.mbed.org/aes-source-code
(Oder überall nur im Internet, wenn Sie eine andere Sprache C bevorzugen).