TZipFile verschlüsselte RAW-Datei hinzufügen

[himitsu]

Tachchen,

wenn man kein Passwort angibt, dann wird eine verschlüsselte Datei "direkt" ausgelesen (im verschlüsselten Zustand)

wenn ich sie aber einer neuen ZIP wieder hinzufügen will, dann wird mein übergebener CRC32 im LocalHeader/CentralHeader überschieben (neu berechnet).
und wenn dann irgendjemand beim nachfolgenden "richtigen" Entschlüsseln den CRC prüft, dann ist Dieser natürlich falsch, weil CRC der verschlüsselten Daten, nicht von den Entschlüsselten.

* den CentralHeader bei Add kann ich nicht angeben, da hierbei IsEncrypted mit False überschrieben wird
* Password kann ich nicht angeben, da dann "nochmal" verschlüsselt wird (und die Verschlüsselungsfunktion/-klasse lässt sich ach nicht durch einen Dummy ersetzen)
* nachträglich über OnProgress lässt sich der CRC auch nicht überschreiben, weil dort ein falscher Header (FCurrentHeader) übergeben wird und das auch noch (absichtlich) falsch, ohne const/var
* der LocalHeader wird sofort in die Datei geschrieben an die CentralHeader komm ich auch nicht mehr ran (eine Kopie davon lesen ja, aber eben nicht schreibend)
* es gibt eine Kopie des LocalHeader, die global lesbar wäre, aber es ist halt eine Kopie dieses Records und somit bringt es nichts dort reinzuschreiben

[add]
Irgendwie hab ich bisher Cryptor: IZipCryptor übersehn ... mal sehn ...
Sah erst nur des fest eingebaute und nicht änderbare TZipCryptStream (ohne den Cryptor-Parameter zu bemerken)

[add2]
Ich glaub langsam es geht nicht, ohne nachträglich den ZipStream nochmal anzupacken. (dann kann ich die ZIP aber gleich komplett alles selbst machen)
procedure TZipFile.Add(Data: TStream; LocalHeader: TZipHeader; CentralHeader: PZipHeader);
* Passwort gesetzt, da wird zu Beginn der CRC berechnet (vor Verschlüsselung)
* kein Password, da wird nachher beim Komprimieren der CRC berechnet
* CentralHeader übergeben, da wird IsEncrypted überschrieben (Password müsste also gesetzt sein)

Aber beim TZipFile.Read ist das CheckCrc standardmäßig False ... man könnte also hoffen es könnte der CRC vieleicht auch egal sein. (falls das ZielProgramm nicht explizit True setzt und falls Emba seine ZipKlasse auch selbst benutzt ... sie wäre aber auch saudämlich, würden sie stattdessen selbst nicht was ordentliches nutzen)