Blöde Frage zum Thema ZipCrypto

[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 von Sherlock:

...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 von Sherlock:

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.