Entwickler-Ecke
Algorithmen, Optimierung und Assembler - Verschlüsselung Erkennen
Flamefire - Do 15.01.09 13:30
Titel: Verschlüsselung Erkennen
Hallo,
ich hab ein Programm, dass einen Buffer entschlüsselt. Und ich hätte gern gewusst, welcher Algorhitmus verwendet wurde.
Ich kann beliebige Eingaben machen, und mir das "entschlüsselte" Ergebnis angucken.
Bisher habe ich folgendes:
Beim Entschlüsseln wird folgendes gemacht:
Die CRC32 Tabelle wird geladen (Daten davon z.b.
hier [
http://www.finalsolutions.ch/])
Dann wird das Startpunkt der Tabelle um die Länge des Buffers verschoben.
Danach geht er vom letzten zum zweiten Byte durch und entschlüsselt es folgendermaßen:
Quelltext
1:
2:
3:
4:
5:
6:
7:
8:
9:
10:
11:
| While...
begin
tmp:=akt. Byte;
tmp2:=Byte vor akt. Byte (PByte(@akt.Byte-1)^)
tmp2:=PByte(PCRCTable+tmp2)^;
tmp:=tmp XOR tmp2;
tmp:=tmp XOR Byte(Länge);
tmp:=tmp XOR i;
akt.Byte:=tmp;
Inc(i);
end; |
wobei i am Anfang 1 ist
danach werden die ersten 8 Byte mit 2 4-Byte werten überschrieben (weiß ne wo die her kommen)
die ersten 4 Byte werden weiter entschlüsselt durch:
aktByte:=aktByte XOR (PorigCRCTable+aktByte)^
für die zweiten 4 Byte wird ein Key verwendet:
Quelltext
1:
2:
3:
4:
5:
6:
| aktKey:=Key;
while...
begin
aktByte:=Byte(aktByte+(aktKey SAR 8));
aktKey:=aktKey*constA+constB;
end; |
die restlichen Bytes im packet werden dann ebenfalls nochmal entschlüsselt. Auch hier fehlt mir wieder das Wissen wie.
Kommt das jemand bekannt vor? Kennt jemand den Algorhitmus?
Wäre sehr schön, wenn ich schnell eine Antwort bekäme.
Bsp
| Zitat: |
0000000000000000000000000000000000000000000000000000000000000000000000000000000000
0000000000000000000000000000000000000000000000000000000000000000000000000000000000
0000000000000000000000000000000000000000000000000000000000000000000000000000000000
0000000000000000000000000000000000 |
wird entschlüsselt zu
| Zitat: |
78BB0346076F3753CAAE94C48BFF4919F145BD59C6B22D3470E720A9E2CB3BC253B9A92305DBE14A24
5B0CD4B8E33DFA78616A6A1F6F7F065897E7DC6CCFD4D3055E79EF01CED35E0D3E34CDF7FEA95B2C44
8CBDD2ED21D6AEA96700C69BCC9F4B82770BD9BE7C70090D47F20D565D78122BA337CE6C5B188123C0
88DEBB4FA53BCABEA0AD06C68B4DA142D9 |
Moderiert von 
Narses: Umbrüche in die Code-Zitate eingefügt
Flamefire - Fr 16.01.09 12:35
Update der Infos:
nachdem die entschlüsslung durch die CRC32-Tabelle vorgenommen wurde (1. Code im 1.Post) werden die ersten 4 Byte mittels "aktByte:=aktByte XOR (PorigCRCTable+aktByte)^ "
entschlüsselt
der rest wird dann mittels eines algos entschlüsselt, der zum teil aus einer generierten tabelle besteht (SEHR ähnlich den Blowfish s-Boxen und p-boxen), einer 8-Byte Blockverschlüsselung, und zum andren teil aus dem schon geposteten Code (mit SAR-Anweisung)
dabei werden auch zum Teil schon verschlüsselte Stellen nochmal mit dem andren Alog-Teil verschlüsselt
Die Tabelle wird anscheinend mit Hilfe eines Algos erstellt, der wiederum auf der CRC32-Tabelle beruht und ebenfalls den Cipher (1.Teil-Algo) und die "SAR-Teil"-Verschlüsselung auf die Tabelle anwendet.
Dabei bleibt der InitialKey ("Key") aus "aktKey:=Key; " immer gleich.
Welche Verschlüsselung benutzt denn CRC32 als Basis?
Ich dachte bisher, das ist nur ein Prüfteil.
Martok - Fr 16.01.09 17:33
Die CRC-Tabelle ist in der Verwendung hier eigentlich nur ein (beliebiger) Seed. Dürfte vermutlich auch mit anderen Daten ähnlicher Größe (4*256=1024byte) klappen.
Flamefire hat folgendes geschrieben  : |
| Die Tabelle wird anscheinend mit Hilfe eines Algos erstellt, der wiederum auf der CRC32-Tabelle beruht und ebenfalls den Cipher (1.Teil-Algo) und die "SAR-Teil"-Verschlüsselung auf die Tabelle anwendet. |
... was meine erste Annahme bestätigt... hier wird also ein zweiter Schlüssel erstellt, indem der erste mit dem "echten" Schlüssel verrührt wird. Denke mal, aus dieser Eigenschaft findet man sowas am ehesten...
Flamefire - Sa 17.01.09 17:20
ich hab mich anscheinend geirrt, was das erstellen der tabelle angeht.
die tabelle ist verschlüsselt in einer datei gespeichert und wird am anfang geladen entschlüsselt und dann nicht mehr verändert
Die encipher funktion und die Tabelle scheinen tatsächlich Blowfish zu sein, nur angepasst auf einen Buffer als Tabelle bestehend aus 4094 Byte: SBox; 72 Byte PBox
(Anhand der Größe kam ich auf Blowfish)
jetzt spielen aber noch weitere Funktionen eine Rolle:
(In der 2. war ein Fehler!!!)
1 (4 Byte Block):
aktByte:=aktByte XOR (PorigCRCTable+aktByte)^
2 (4 Byte Block):
Delphi-Quelltext
1:
2:
3:
4:
5:
6:
7:
| aktKey:=Key;
while 1.-4.Byte
begin
oldByte:=aktByte;
aktByte:=Byte(aktByte+(aktKey SAR 8));
aktKey:=(aktKey+oldByte)*constA+constB;
end; |
3 (8 Byte Block): Der Blowfish-Teil
Diese Funktionen werden anscheinend in einer mir nicht bekannten Reihenfolge (da sehr obfuscateter Code) über den zu entschlüsselnden Buffer gejagt.
Dabei werden auch DWORDS 2 mal (von verschiedenen Funktionen) entschlüsselt
Es gibt also mehrere Keys: den Blowfish Key, der aber in der Tabelle schon drin ist
die CRC-Tabelle anscheinend als Seed (lt Martok)
und die 3 DWords der 2. Funktion (InitKey, Summand, Faktor)
Hilft das weiter?
Entwickler-Ecke.de based on phpBB
Copyright 2002 - 2011 by Tino Teuber, Copyright 2011 - 2025 by Christian Stelzmann Alle Rechte vorbehalten.
Alle Beiträge stammen von dritten Personen und dürfen geltendes Recht nicht verletzen.
Entwickler-Ecke und die zugehörigen Webseiten distanzieren sich ausdrücklich von Fremdinhalten jeglicher Art!