Blöde Frage zum Thema ZipCrypto

[Sherlock]

Uwe Raabe hat in einem seiner Blogbeiträge https://www.uweraabe.de/Blog/2017/03...rd-encryption/ eine recht übersichtliche Implementierung der ZipCrypto Entschlüsselung präsentiert. Die Implementierung folgt, wie er auch selbst erläuterte, den originalen PKWare Erläuterungen. Jetzt bin ich dabei mir das Thema insgesamt etwas genauer anzusehen, da ich gerne Konfigurationsdateien (einfache Inis) verschlüsselt speichern möchte. Erster Schritt war die TZip Komponente zu verwenden, und unverschlüsselt einfach nur die Ini-Datei zu zippen. Entpacken "on the fly" bzw. im Speicher mit Memorystreams geht auch gut, so daß keine Dateien als Laufzeitartefakte entstehen. Jetzt wollte ich zum Spaß mal ZipCrypto anwenden, daß Embarcadero das als eine von zwei möglichen Verfahren nennt, und AES256 ganz sicher aufwendiger für einen simplen Test wird. Lange Rede kurzer Sinn: Es kommt im 32Bit Compilat zu einem Integer-Überlauf, wenn in der Methode DecryptBuffer die Multiplikation durchgeführt wird:

Delphi-Quellcode:

Result := word(temp * (temp xor 1)) shr 8;

Klar ist der Code von 2017 mit Delphi 10.1 erstellt worden, aber zu Delphi 11.3 sind ja nun nicht so viele schlimme Dinge passiert...oder doch? Hat jemand eine Idee dazu? Uwe? :mrgreen:

Sherlock

[Uwe Raabe]

Hast du schon die neueste Version von GitHub versucht?
https://github.com/UweRaabe/EncryptedZipFile

[Sherlock]

Nein, noch nicht. Toll, daß Du da noch weiter dran gearbeitet hast. Stoße jetzt auf einen anderen Fehler, allerdings habe ich das zip mit 7zip erstellt, nicht mit Deiner Unit. Ändere das noch und melde mich...

Sherlock

[Uwe Raabe]

Sowohl TZipFile als auch TEncryptesZipFile unterstützen nur eine sehr kleine Auswahl an Komprimierungs- und Verschlüsselungsmethoden. Insofern ist ein erfolgreiches Einlesen von mit anderen Tools erzeugten Zips eher Glücksache. Funktionieren sollte allerdings das Einlesen selbst erstellter Zips.

[KodeZwerg]

PeaZip ist ein interessantes Projekt mit dem Thema komprimierte Archivierung, es ist Quelloffen allerdings in/für Lazarus geschrieben.
Falls Du weiterhin Probleme hast, kannst Du ja mal das Binary von PeaZip laden und testen ob es in Deinem Falle funktioniert und dann entweder sofort oder mit Anpassungen für Delphi die verwendeten units einbinden und nutzen.

[himitsu]

Es gibt auch PAS-Header für die 7z.dll.

[Sherlock]

Also, hab es eingegrenzt. Unverschlüsselt funktioniert es, verschlüsselt mit Deiner Unit läuft es in einen Fehler. Hier was ich mache:

Delphi-Quellcode:

  var
    myIni: TMemIniFile;
    myZip: TEncryptedZipFile; // Oder zum Testen TZipFile
    myStream: TMemoryStream;
    myFileStream: TFileStream;
  begin
    FileName := 'example.ini.zip';
    Path := TPath.Combine(TPath.GetDocumentsPath, FileName)
    myFile := Path;
    try
      MyFileStream := TFileStream.Create(myFile, fmOpenRead);
      myStream := TMemoryStream.Create;
      myZip := TEncryptedZipFile.Create('passwort');
//      myZip := TZipFile.Create;  // Mit einer nicht passwortgeschützten Version geht es
      MyFileStream.Position := 0;
      myZip.Open(MyFileStream, zmRead);
      myZip.Read(0, myStream, myHeader);
      myIni := TMemIniFile.Create(myStream);  // <- an dieser Stelle gibt es einen EZDecompression Error mit Message "Data Error"
      fDebugLevel := myIni.ReadInteger('local', 'dbgLvl', 1); // Hier kommen wir nicht mehr hin...   
    finally
      myIni.Free;
      myZip.Close;
      myZip.Free;
      myStream.Free;
      myFileStream.Free;
    end;

Der Fehler ist dann tiefer drinnen, beim Versuch TZDecompressionStream.Read auszuführen kommt es dann zu diesem Fehler. Der Stream hat zwar eine korrekte Länge ist aber ausschließlich mit Nullen gefüllt. Wenn ich tiefer gehe bin ich wieder bei Dir in der Unit, beim TDecryptstream.Read, was aber bisher noch nicht zu einem Fehler führte...

Danke an Himitsu und Kodezwerg...ich hab mich erstmal verbissen. Es müsste eine Kleinigkeit sein, die ich aber übersehe. WEnn ich noch mehr als zwei Tage brauche, dann schaue ich mir mal PeaZip an. Ich möchte gerne externe DLLs vermeiden.

Sherlock

[himitsu]

Delphi-Quellcode:

myZip.Read(0, myStream, myHeader);
myStream.Position := 0;  
myIni := TMemIniFile.Create(myStream);

[edit] Nee, leider nicht. TMemIniFile.LoadValues setzt die Position auf 0 [/edit]


Diese Read-Funktion "schreibt" ja in diesen Stream, womit der nun am Ende steht, und sie setzt ihn leider danach nicht an den anfang zurück.

Auch viele Lese-Funktionen lesen dann ab der aktuellen Stelle, und nach dem Stream-Ende gibt es dann nichts mehr.
Aber einen Fehler sollte es dann eigentlich auch nicht geben, da eine "leere" INI-Datei eigentlich gültig ist.



Hmmmm, dann bleibt wohl nur noch, laut ""Data Error", dass der Stream nicht entschlüsselt werden kann.
Vielleicht unbekanntes oder falsches Format. Aber dann hätte ich einen Fehler schon beim .Read erwartet.
Somit bleibt nur noch mitten zwischen den Daten ein Problem ... die Klasse denkt sie kann es verstehen und raucht dann in etwas Unbekanntes, oder sie hat einen Bug.

[Sherlock]

Ich vermute mal, daß Uwe den Weg über den Stream einfach nicht im Kopf hatte, als er das implementierte.

Sherlock

[Uwe Raabe]

Das Read auf einen Stream macht in der Tat schon länger Ärger. Problematisch sind dabei die Seek-Operationen, denn das decrypten geschieht synchron und dann bringt ein Seek backwards den State durcheinander.

Alternativ zu TStream könntest du mal das Overload mit TBytes versuchen. Da wird zwar intern auch das Read mit Stream verwendet, aber nur mit einem einzigen Read-Call - das funktioniert. Mit den Bytes erzeugst du dann einfach einen TBytesStream.

Eventuell könnte man das Read-Stream-Problem lösen, wenn man im Decrypt Stream gleich beim Create alles entschlüsselt und in einen Puffer schreibt. Braucht dann halt etwas mehr Speicher.

[himitsu]

Beim Entpacken gibt es ja auch solche Probleme, bzw. auch andere Ver-/Entschlüsselungsstreams ebenfalls.

Oftmals wird dann wieder an den Anfang gesprungen und bis zum neuen Offset alles neu gelesen (entschlüsselt/entpackt/...)
Einige speichern sich zwischendrin auch alle 'nem gewissen Abstand den Status und brauch das dann nicht komplett von Anfang, sondern nur vom letzten Snapshot aus zu machen.

[mytbo]

Zitat:

Zitat von Sherlock (Beitrag 1525802)

...ich hab mich erstmal verbissen.

Wie es mit mORMot (ZIP-Datei mit optional AES verschlüsselten Einträgen) umzusetzen ist, habe ich in diesem Artikel beschrieben. Quelltext im Anhang des Artikels. Umgesetzt in den Funktionen LoadStream/SaveStream.

Bis bald...
Thomas

[KodeZwerg]

Von mORMot kann auch ich die unit SynLZ empfehlen, die stellt Kompressions-Stream methoden zur Verfügung und benötigt keine extras... doch eine include datei soweit ich mich erinnere...
Das habe ich schon des öfteren in Verbindung mit anderen Krypto streams verwendet, die Kompression ist gut.
https://github.com/synopse/mORMot/blob/master/SynLZ.pas

[Sherlock]

So, ich war letzte Woche leider kurzfristig außer Gefecht. Vielen Dank für alle Rückmeldungen. Ich kann zum einen vermelden @Uwe, daß der Weg über Read(Index: Integer; out Bytes: TBytes) wunderbar funktioniert (meine Datei ist entpackt lächerliche 400Bytes groß) und zum anderen, daß ich vermutlich dabei bleiben werde. Da für meine Zwecke eine grobe "Obfuskation" ausreichend sein dürfte. Dazu werde ich vermutlich noch ein bis zwei Schritte durchführen, um die Datei als Zip unkenntlich/unlesbar zu machen (Dateiendung, PK Header, vielleicht auch fehlerhafter CRC) mal sehen, was mir so einfällt, und wofür Zeit bleibt. Ich werde also kein größeres Framework installieren müssen, für diese kleine Aufgabe. Danke nochmals allen, für die Ideen.

Sherlock

[Uwe Raabe]

Zitat:

Zitat von Sherlock (Beitrag 1526223)

daß der Weg über Read(Index: Integer; out Bytes: TBytes) wunderbar funktioniert

Wie ich schon erwähnt hatte, ist es leider so dass der über Read zurückgegeben Stream nicht frei positionierbar ist und vermutlich nur in einem Stück gelesen werden kann und dabei die Größe bekannt sein muss. Das ist im Grunde auch was das Read Overload mit den TBytes macht.

Ich werde da wohl auch nichts mehr dran ändern, da ein möglicher Fix vermutlich auch über ein TBytes gehen würde und dafür lohnt sich der Aufwand einfach nicht.