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.