Entwickler-Ecke :: Thema anzeigen - Encoded-Sfx: Verschlüsselung mit Sfx

Entwickler-Ecke

Open Source Projekte - Encoded-Sfx: Verschlüsselung mit Sfx

JayEff - Mo 11.06.07 21:16
Titel: Encoded-Sfx: Verschlüsselung mit Sfx

Hallo Leute!
Ich hab das Programm nun mal ein wenig überarbeitet. Hier nochmal die Beschreibung:

Zitat:

Man verschlüsselt mit meinem Programm eine oder mehrere Dateien: Das Programm akzeptiert den Dateinamen als Parameter aber auch per Drag&Drop, selbstverständlich auch per Open-Dialog. Nun gibt man das Passwort ein, und die Datei wird per Blowfish verschlüsselt. Hierbei wird vorher die Prüfsumme errechnet und in die Ausgabedatei gespeichert. Das Ganze klingt nun reichlich uninteressant, aber:
Die Ausgabedatei ist eine Exe! Sie enthält alles, was benötigt wird, um die verschlüsselte Datei wieder herzustellen, mit Ausnahme vom Passwort, selbstverständlich.
Klappt bei der Entschlüsselung alles, so wird die Überprüfung der Prüfsumme das richtige Passwort bestätigen. Falls die Prüfsummen nicht übereinstimmen, wird ein Fehler ausgegeben.

Dadurch, dass man nun mehrere Dateien in ein Archiv packen kann, sind neue Units dazu gekommen. Die Größe der temp-Datei und damit der Wert, um den die Ausgabedatei größer ist als die Summe ihres Inhalts, steigt damit auf etwa 600 KB.

Es gibt nun eine Projekt-Webseite, in der das Program angeboten wird. Das Delphi-Forum hat den Source übrigens exklusiv ;)
Hier die Seite: http://www.mit-passwort-schuetzen.de
(Nicht aktuell, der Freund, der diese Seite verwaltet ist seit sehr geraumer Zeit offline)
Hier ein direkter Download Link zur .exe (auf meine eigene Seite): [url=http://www.jayy.de/EncodedSFX.exe]*klick*[/url]
Encoded-Sfx-ToDo:

Speicher-Algorithmus SEHR langsam! Fertig
Während des Speicherns/Verschlüsselns reagiert das Programm nicht
Komprimierung einbauen
temp-Datei als Resource in die Exe packen Fertig
Mehrere Dateien in ein Archiv packen Fertig
SaveDialog fürs Output-File gegen die nervigen AntiVir-Warnungen Fertig
ShellExtention: Rechtsklick auf Datei -> "Mit Password schützen" ... o.ä. Fertig
Über die ShellExtention mehrere Dateien der Liste hinzufügen lassen Experimentell!
Unterstützt nun Englisch und Deutsch, wer Übersetzungen schreiben will, einfach mal mit den .lang und .txt Dateien rumspielen ;) Ich würd die Übersetzungen natürlich gern bereitstellen.

Fremdkomponenten/Units abgesehen von der weiter unten geposteten:

Die Klassensammlung DEC [http://www.torry.net/quicksearchd.php?String=Delphi+Encryption+Compedium&Title=Yes]
die Unit md5 [http://www.fichtner.net/delphi/md5/]
die Unit OneInst.pas [http://michael-puff.de/dirindex.php?folder=Developer/Delphi/Importe/Nico/]

Viel Spaß beim ausprobieren ;)

Moderiert von Gausi: Topic aus Freeware Projekte verschoben am Di 12.06.2007 um 18:56

Chryzler - Mo 11.06.07 21:34

Sowas hab ich auch schonmal versucht, ist nie richtig fertig geworden.
Meine bisherigen Eindrücke :):

Enkoder-Form ist maximierbar und größenveränderbar
Beim Dekodieren der Datei "IPMonitor.exe" erscheint "Die Datei "nerien.bin" (45 Byte) soll extrahiert werden." Huh!?
Diese "nerien.bin" lässt sich nicht entschlüsseln: "Passwort falsch"
Nach dem Wegklicken der Meldung "Passwort falsch" bleibt ein Fortschrittsfenster zurück. -> ALT+F4

Also ich würde das als Pre-Alpha einschätzen. Sinnvolles Arbeiten ist bis jetzt jedenfalls noch nicht möglich. :|

JayEff - Mo 11.06.07 22:02

bei mir hat z.B. mit einer MP3-Datei alles einwandfrei funktioniert :gruebel: - Moment.
Ah ja. Veralteter Source in der temp datei. Ich änders...
Ist mir schleierhaft. Alles, was prima funktioniert hat, funktioniert einfach nicht mehr. :autsch:

JayEff - Mo 11.06.07 22:20

:autsch: Nun, ich hatte wohl aus irgendeinem Grund eine Zeile rausgenommen, die lautete ... f := Filename; das Ganze sorgte dafür, dass die BeginUpdateResource als Dateinamen '' bekam und ein ungültiges Handle zurückgab. Ein Glück gibt's GetLastError...! Bitte nochmal versuchen ... :(

Chryzler - Di 12.06.07 14:23

Jo, jetzt gehts schon besser. Folgende Verbesserungen sind mir noch aufgefallen:

Enkoder-Form ist maximierbar und größenveränderbar.
Die temp-Datei mit herumzuschleppen ist keine gute Idee, versuch die Datei als Resource zu verwenden
Der Dekoder-Overhead ist ~400 KB, das ist ziemlich viel. Die temp-Datei mit UPX zu behandeln könnte helfen.
Wenn die Datei beim Dekodieren bereits existiert, und man "Nein" wählt, könnte man sie ja unter einem anderen Namen abspeichern.

Sinspin - Di 12.06.07 16:40

Feines Tool.
Sowas steht schon seit langem auf der ToDo Liste meines Verschlüsslungstools.

mögliche Erweiterungen:
- eine Liste von Dateien oder Verzeichnissen erlauben,
- Komprimieren vor dem Verschlüsseln (das erhöht die Geschwindigkeit der Verschlüsselung und macht das ganze schwehrer knackbar,
- Tempdatei als Ressource in die Exe integrieren, oder die gleiche Exe zum ein und auspacken nehmen.

Chryzler - Di 12.06.07 17:37

Was natürlich noch cooler währe, wenn der Dekoder die Datei nicht auf die Festplatte schreibt, sondern nur in den Arbeitsspeicher, und von dort aus die EXE startet. Dann braucht man immer das Passwort, um die EXE zu starten. Allerdings habe ich null Ahnung, wie man sowas realisieren könnte.

JayEff - Di 12.06.07 18:13

Chryzler hat folgendes geschrieben:

Was natürlich noch cooler währe, wenn der Dekoder die Datei nicht auf die Festplatte schreibt, sondern nur in den Arbeitsspeicher, und von dort aus die EXE startet.

Niemand hindert dich daran, die Datei nach Benutzung wieder zu löschen ;) Ich denke, das macht das Ganze unnötig kompliziert und außerdem dachte ich daran, dass man auf die Art auch Dateien transportieren kann, das wäre aber nicht möglich, wenn man bei jedem mal, wenn man die Datei benutzen will, das PW eingeben muss. Z.B. bei Übergabe einer MP3-Datei, die man in seine Bibliotek eingliedern will, wäre es unpraktisch, wenn die mp3-Datei als .exe vorliegen würde ;)
Ich dachte tatsächlich mehr an ein selbstextrahierendes Archiv.

Kleines Update: Temp-Exe hab ich durch UPX gejagt, dadurch ist sie nur noch 280 KB groß. Da die Kompilate nur in der Binary.zip sind, ist das auch nur da ergänzt. (gebt mir 3 min für's hochladen ;) )
Vorher hatte die temp-Datei übrigens eine Größe von 597 kb :shock:

Das Zippen Vorm verschlüsseln lohnt sich z.B. bei komprimierten Audio/Video-Formaten nicht, aber ich schreib's auf die ToDo - Ich könnte ja zum Programm dazu schreiben, dass es empfohlen wird, die Daten vorher zu zippen ;)

Mehrere Daten in eine Exe zu packen ist sicherlich möglich, wäre aber im Augenblick ein ganz schöner Aufwand :| Würde vll auch den Overhead der Dekodierdatei vergrößern. Ich denke, ich verweise dafür auch darauf, dass man die Daten vorher in ein Archiv zusammen-zippen und dieses dann verlüsseln kann. ;)

Im Hauptprogramm ist BorderStyle nun auf bsDialog, wieder nur im Binary - wegen so 'ner kleinigkeit muss ich doch nicht den Source updaten oder? ;)

Ich hab grade gesehen, dass in der KryptedExe eine Zeile falsch ist: Ganz unten muss man aus dem Close; ein Application.Terminate; machen, sonst bleibt das Programm offen.

Sinspin - Di 12.06.07 19:36

Das Entschlüsseln in den Speicher und anschließendes Ausführen hat aber den Vorteil das nicht jemand in der Zwischenzeit die entschlüsselte Exe kopieren kann.
Will man das Programm nutzen muss man immer das Passwort richtig eingeben.
Wie das mit dem in den Speicher Auspacken und Ausführen geht ist eine gute Frage. Bei UPX wird es ja irgendwie gemacht.

Chryzler - Di 12.06.07 19:39

JayEff hat folgendes geschrieben:

Chryzler hat folgendes geschrieben:

Was natürlich noch cooler währe, wenn der Dekoder die Datei nicht auf die Festplatte schreibt, sondern nur in den Arbeitsspeicher, und von dort aus die EXE startet.

Schon klar, ich hätte wenn dann auch die Funktion optional gemacht. War ja nur ne Idee ^^.
Dann hab ich grad noch gesehen, dass beim Eingeben des Passwortes im Dekodierer kein PasswordChar gesetzt ist, im Enkodierer schon. Sollte schnell zu beheben sein. :) Aber ansonsten gefällt mir dein Prog eigentlich ganz gut.

JayEff hat folgendes geschrieben:

Kleines Update: Temp-Exe hab ich durch UPX gejagt, dadurch ist sie nur noch 280 KB groß. Da die Kompilate nur in der Binary.zip sind, ist das auch nur da ergänzt. (gebt mir 3 min für's hochladen ;) )
Vorher hatte die temp-Datei übrigens eine Größe von 597 kb :shock:

Kleiner Tipp: Die neue UPX-Version (3.00 oder so) unterstützt den LZMA-Algorithmus, also praktisch 7Zip (upx.exe --lzma Datei). Damit hab ich sogar bei der aktuellen "temp" 254 KB geschafft.

JayEff - Di 12.06.07 21:00

Chryzler hat folgendes geschrieben:

Kleiner Tipp: Die neue UPX-Version (3.00 oder so) unterstützt den LZMA-Algorithmus, also praktisch 7Zip (upx.exe --lzma Datei). Damit hab ich sogar bei der aktuellen "temp" 254 KB geschafft.

aaach .. die 26 kb.. Haarspalterei ;)
Aber was das "Funktion perfekt machen" betrifft: Das ist auch in meinem Interesse und das Komprimieren ist kein Problem - aber mehrere Dateien in eine exe zu packen ... hat denn diese zip-unit eigentlich die Funktion, mehrere Dateien in ein Archiv zu packen, schon von Haus aus? :) Dann würd ich das einfach drüber laufen lassen bevor's verschlüsselt wird. Das wäre nett :)

Im Dekoder-Programm wollte ich komplett ohne Form auskommen, darum ist die Eingabe eine InputBox. Ist es möglich, bei ner InputBox einen PasswortChar zu setzen? Wenn nicht, würd ich halt kurz ne eigene Form dazu einbauen. Macht die temp halt wieder etwas größer.

Sinspin - Mi 13.06.07 20:02

ich nutze zum zippen eine übersetzungen von 7zip in delphi. die routine bekommt dabei einfach eine datei übergeben die dann komprimiert wird. ich kümmere mich dabei selber darum das ich aus einzelnen dateien eine erstelle.
ich speichere einfach den name, das datum, die attribute und den offset den die datei in der zieldatei hat. dann schreibe ich die informationen, und die dateien selber, einfach hintereinander in eine datei.

JayEff - Mi 13.06.07 20:07

Sinspin hat folgendes geschrieben:

ich speichere einfach den name, das datum, die attribute und den offset den die datei in der zieldatei hat. dann schreibe ich die informationen, und die dateien selber, einfach hintereinander in eine datei.

Hm... Verstehe. Augenblicklich bin ich zu faul um mir soetwas zu schreiben (Zumal das müdliche Abi ansteht :shock: )
Falls du zuufällig eine fertige Funktion/Prozedur hast, die das ganze für mich erledigt und das vielleicht sogar noch OpenSource ist und darüber hinaus dir eine Erwähnung in den Credits (Ach ja, ToDo: Credits einfügen :shock: ) nach eigenen Wünschen genug ist ... :mrgreen:

hui1991 - Mi 13.06.07 21:42

hm.. sobald die größe der tmp datei die exe dann hat, hört das programm auf, also 280KB.
Ich weiß auch nicht warum das genau da aufhört ^^
Naja und wenn ich eine Datei wähle die unter 280KB hat steht dort Erfolgreich und dann kommt diese Meldung im Anhang.

JayEff - Mi 13.06.07 22:17

Bei mir kamen mit der UPX-gepackten temp mehrere AntiVir-Warnungen gefolgt von einem absturz des explorers ohne wiederkehr. Ich lade gerade die alte, ungepackte temp hoch... :autsch:

Sinspin - Do 14.06.07 12:17

diesen antivir scheiß hatte ich neulich auch als ich eine neue version eines programmes gepackt habe.
Ich habe die "virenhaltige" version an antivir gesendet und bis heute keine antwort erhalten. nur das seit einem update der antivir dateien der fehler nicht mehr kommt.

JayEff - Do 14.06.07 17:46

Neue Version oben.

Optionsfenster mit bisher nur dieser Option: Als ShellEx eintragen (siehe erster Post)
Speichern-Algo ist nun schnell :D

Sinspin - Do 14.06.07 22:59

Ich habe mal meine Klasse die ich für das zusammenfassen von Dateien geschrieben habe ein bisschen umgearbeitet und als Open Source deklariert.
Das ganze gibt es zusammen mit einer Demo die den Funktionsumfang beschreibt.
Die Demo könnte man jetzt fast mit dem vergleichen was TAR unter Linux macht. Nur das Verzeichnisse nicht beachtet werden. (das habe ich bisher einfach noch nicht eingefügt. vlt. kommt es irgendwann noch)

Selbst verfreilicht kann den Code jeder verwenden. Schließlich ist er Open Source.

JayEff - Do 14.06.07 23:06

Genial! Ich werd's gleich morgen einbauen! Danke! :D

Sinspin - Do 14.06.07 23:21

Ich habe mal über deine "Temp".exe weg geschaut. Da ist ja so ein haufen Kram drinne, das ist ja kein Wunder das die so groß ist! Du solltest versuchen diese ohne eine Application Variable zu erstellen und auch wirklich nur die nötigsten Units einzubinden.

Zitat:

Augenblicklich bin ich zu faul um mir soetwas zu schreiben (Zumal das müdliche Abi ansteht :shock: )

Das kommt mir bekannt vor, ich konnte das proggen auch nie lassen. Aber fertig bin ich trotzdem geworden.
Also: viel Erfolg bei den Prüfungen. :zustimm:

JayEff - Do 14.06.07 23:28

Units, die tatsächlich nicht gebraucht werden, werden ja wegoptimiert - aber das Application-Objekt wird von der Unit Forms bereitgestellt, und ohne die gibt's keine Gauge/Progressbar/Form überhaupt. :(
Aber darum kümmere ich mich, sobald ich eine Komprimierung und deine FileOps drin hab.

JayEff - Fr 15.06.07 00:04

Dein Test-Programm wirft beim Kompilieren extrem viele Fehlermeldungen. Mal abgesehen von

Zitat:

[Fehler] formTest.pas(34): Undefinierter Bezeichner: 'TFileListEntry'

kommen 6 "Operator oder Semikolon fehlt" und einige "X erwartet aber Y gefunden" (Wobei X und Y "END;", "THEN" oder ")" o.ä. sind) :cry:
Edit: sämtliche meldungen verschwinden, wenn man aus TFileListEntry TFileList macht :shock: Fehler deinerseits? :gruebel:
Edit2: Durch deine Deklaration

Delphi-Quelltext

1:
2:
3:
4:

type
  TFileMode=(fmOpenRead=SysUtils.fmOpenRead,
             fmOpenWrite=SysUtils.fmOpenWrite,
             fmOpenReadWrite=SysUtils.fmOpenReadWrite);

sind die fmOpenRead etc aus SysUtils nicht mehr benutzbar. (Es gibt keine Überladene version von (z.B.) FileStream.Create, die man so aufrufen kann)
Habe alle Vorkommnisse von TFileMode mit Word ersetzt und die Deklaration entfernt. Damit ist das ganze zwar nicht mehr DAU-proved aber man muss halt drauf achten, nur fmOpenRead, Write, und ReadWrite zu benutzen.

Sinspin - Fr 15.06.07 00:26

:oops: Das kommt davon wenn man ganz schnell noch was umbenennt! Ich habe den Fehler behoben und das Zip neu hochgeladen.

das mit dem FileMode ist mir nie aufgefallen da ich im gesammten projekt nur mit den FileOps arbeite.
Bezüglich der Komprimierung hätte ich auch noch was zu bieten.

JayEff - Fr 15.06.07 01:01

Die neue Version mit der Fähigkeit, mehrere Dateien zusammenzufassen, ist nun oben. Der Overhead ist auf 605 kb gestiegen, aber eigentlich kann man damit leben, finde ich :(
Bitte testen! :D

Sinspin - Fr 15.06.07 01:16

ich habe mal ein paar dateien zusammengefasst. nach der meldung "erfolgreich" kam die meldung "zugriff verweigert".
bei dem versuch die exe zu starten habe ich diese meldung erhalten:

---------------------------
D:\temp\Input\big.exe
---------------------------
D:\temp\Input\big.exe ist keine zulässige Win32-Anwendung.

---------------------------
OK
---------------------------

Sinspin - Fr 15.06.07 01:20

Die Source sind unvollständig! Fehlende units: md5, HCMngr, fileOps, filesToStream!

JayEff - Fr 15.06.07 01:30

Ach ja. Ich hatte vergessen, eine ShowMessage rauszunehmen.
Hmmm? Unvollständig? Ich lade gleich die neuesten Versionen rauf - wesshalb deine big.exe nicht funktioniert hat, kann ich mir nicht erklären :gruebel:
Mit den gleich (gib mir 1-2 min) hochgeladenen Dateien waren *meine* Tests erfolgreich.

edit: neueste Versionen sind oben.

Sinspin - Fr 15.06.07 02:21

Gleicher Fehler wieder: Die Exe ist etwas mehr als 10MB groß. (müsste hinkommen, nachdem was ich da reingeladen habe).

Mein DllSpy sagt folgendes:

Quelltext

1:
2:
3:
4:
5:
6:
7:
8:
9:
10:
11:
12:
13:
14:
15:
16:
17:

DOS Header untersuchen...
Datei ist ausführbar.
PE offset: 256
PE Header lesen...
PE Datei erkannt.
PE Informationen erstellen.
Sections laden.
CODE
DATA
BSS
.idata
Import Directory laden.
.tls
.rdata
.rsrc1
Resource Directory laden.
Level: 0 : ResDir (0) Named:4942 ID:43A5 TimeDate:37336F7F Vers:21467.31680 Char:4ABF4EBE

Die letzte Zeile deutet an das da was gehörig in die Hose gegangen ist.
(habe auch eine schöne Zugriffsverletzung bekommen)

Warum packst du das eigentlich in eine Ressource? Man kann das ganze doch einfach an die Exe anhängen. Ganz hinten dran schreibt man dann eine eindeutige Kennung die klarstellt das was an die Exe angehangen ist und wie groß das ganze ist. So lässt sich feststellen welcher Teil der Datei dann kopiert und entschlüsselt werden muss.

JayEff - Fr 15.06.07 02:25

Macht doch keinen großen Unterschied, ob es eine Resource ist, oder nicht.
Ich habe es wie gesagt erfolgreich getestet, unter Anderem an 4 MP3s, die zusammen etwas mehr als 18 MB ergaben.
Versuch es doch mal mit dem Source und sieh, woran's im compiler(debugger) hängen bleibt.

hui1991 - Fr 15.06.07 06:56

Hi,

also ich hab mir jetzt die neue Version runtergeladen, es funktioniert.
606KB sind groß, wenn einer mit DSL Lite unterwegs sind, weil das ewig dauert bis man das sendet.
Hoffentlich kannste das irgendwie noch kleiner machen. ^^

So und noch viel Spaß beim Programmieren ^^

MfG
hui1991

JayEff - Fr 15.06.07 14:19

hui1991 hat folgendes geschrieben:

Hoffentlich kannste das irgendwie noch kleiner machen.

Das ist die Frage: Ich könnte vielleicht eine Konsolenapp draus machen, das würde die Größe wahrscheinlich vierteln oder so. Müssts mal versuchen. Vielleicht mach ich eine Option rein, mit der man wählen kann, ob man eine Konsolen-Exe will oder eine mit Fenster :D
Erstmal mach ich mich an temp=>resource. Ist ja ne Kleinigkeit.

Edit: Eben versucht, durch das weglassen der Form und der dazugehörigen Units erreiche ich eine Verkleinerung der temp um 20 kb. :party: :cry:

Ich lade die Exe hoch, die die temp als resource drin hat.

Sinspin - Fr 15.06.07 20:18

Ich würde mich ja gerne mal mit dem Debugger durch dein Programm durchtasten. Aber dazu fehlen mir einfach ein paar Units. Denn in deinem Source Paket sind ja nur Unit1 und Unit2 dabei. Es fehlen aber noch md5, HCMngr, fileOps und filesToStream.
Solange du die nicht mit in dein Päkchen schnürst oder zumindest eine Referenz auf die Herkunft der Units lieferst, ist das ganze ja auch noch kein Open Source. Denn es ist ja keiner in der Lage deinen Quelltext selber zu übersetzen.

Sinspin - Fr 15.06.07 20:33

Mir scheint als vergisst du den Aufruf zum entleeren der Dateiliste (RemoveAll). Oder du gibst die Instanz von TFileList beim Beenden des Programmes nicht frei.

JayEff - Sa 16.06.07 19:54

Sinspin hat folgendes geschrieben:

Es fehlen aber noch md5, HCMngr, fileOps und filesToStream.

Sinspin hat folgendes geschrieben:

Da sind fileOps und filesToStream drin ;)
HCMngr ist im DEC welches im ersten Post verlinkt ist.
md5 hab ich tatsächlich vergessen, gleich mal schaun, dass ich sie verlinke :oops:

edit: Tatsache, ich hatte beides im Hauptprogramm vergessen :shock: Ist nun oben.

JayEff - Sa 23.06.07 20:48

Update: Das Hinzufügen mehrerer Dateien über die Shellextention bzw. über Öffnen-Mit... ist jetzt eingebaut. Wie gut es funktioniert ist die Frage, ich würde mich sehr freuen, wenn ihr diese Funktion ausgiebig testen könntet. Ich vermute, dass da immernoch ein wenig der Wurm drin ist... hier [http://www.delphi-forum.de/viewtopic.php?t=73700] findet ihr den Code, der diese Funktion ermöglicht. Könnt ihr euch mal ansehen, falls ihr einen Fehler findet. Ich werd oben auch gleich die OneInst.pas verlinken.

Danke fürs Testen!

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!