Entwickler-Ecke

Freeware Projekte - Crypter


Delete - Mo 09.12.02 10:14
Titel: Crypter
Bitte intensiv testen. Danke

Das Programm ermöglicht es Dateien sicher zu ver- und entschlüsseln.

Features:

Beta: Die Callback-Funktion ist noch nicht implementiert, deswegen fehlt die Fortschrittsanzeige und ein abbrechen ist nicht möglich. Also nicht unbedingt gleich ganze Spielfilme verschlüsseln. :wink:

Link: [url=http://www.luckie-online.de/cgi-bin/load.cgi?downloads/cryptersfx.exe]File-Crypter[/url]


Anonymous - Mo 09.12.02 20:00

Ein nettes kleines Tool. Könnte mir vorstellen es öfters zu benutzen.

Hier einige Punkte die mir aufgefallen sind:

Jedes mal wenn ich auf "Datei öffnen" klicke, lande ich zuerst im "Eigene Dateien" Verzeichnis. Das erste mal ist es noch ok, für alle weitere Öffnungen sollte das Dialogfenster vom letzten Verzeichnis ausgehen. Es könnte ja sein, daß ich mehrere Daten im gleichen Verzeichnis verschlüsseln will.

Dann hab ich bemerkt, daß die kodierten Daten die Endung "encoded" haben. Vielleich wäre es nicht schlecht für diesen Datentyp die Option "Entschlusseln" automatisch vorzuwählen.

Dann noch ein Wunsch: Es wäre gut wenn man das Programm mit einem Parameter starten könnte, d.h. wird ein Dateipfad übergeben, dann kodiert oder dekodiert das Programm die Datei automatisch und beendet das Programm. Auf diese Weise könnte man Batch-Konvertierungen machen.

Und jetzt der letzte Wunsch: Da es soweiso nur zwei Dateien sind, so könnte man doch auch nur eine Datei draus machen. Die Dll als Ressorce dazupacken und bei Bedarf entpacken. Für dich dürfte das kein Problem sein. Der Vorteil wäre der, daß man das Programm hin und her verschieben könnte ohne an die Dll denken zum müssen. Es wäre ein Tool das man einfach so Ungezipt weitergeben kann.


Delete - Mo 09.12.02 20:17

Popov hat folgendes geschrieben:
Ein nettes kleines Tool. Könnte mir vorstellen es öfters zu benutzen.

Danke.

Zitat:

Jedes mal wenn ich auf "Datei öffnen" klicke, lande ich zuerst im "Eigene Dateien" Verzeichnis. Das erste mal ist es noch ok, für alle weitere Öffnungen sollte das Dialogfenster vom letzten Verzeichnis ausgehen. Es könnte ja sein, daß ich mehrere Daten im gleichen Verzeichnis verschlüsseln will.

Muß mal kucken wie einfach das geht.

Zitat:

Dann hab ich bemerkt, daß die kodierten Daten die Endung "encoded" haben. Vielleich wäre es nicht schlecht für diesen Datentyp die Option "Entschlusseln" automatisch vorzuwählen.

Redest du von einem Eintrag im Kontextmenü vom Explorer? Wäre zu überlegen.

Zitat:

Dann noch ein Wunsch: Es wäre gut wenn man das Programm mit einem Parameter starten könnte, d.h. wird ein Dateipfad übergeben, dann kodiert oder dekodiert das Programm die Datei automatisch und beendet das Programm. Auf diese Weise könnte man Batch-Konvertierungen machen.

Auch das wäre zu überlegen. da steckt ja mehr Potential drin wie ich zu erst dachte. danke für die Anregungen.

Zitat:

Und jetzt der letzte Wunsch: Da es soweiso nur zwei Dateien sind, so könnte man doch auch nur eine Datei draus machen. Die Dll als Ressorce dazupacken und bei Bedarf entpacken. Für dich dürfte das kein Problem sein. Der Vorteil wäre der, daß man das Programm hin und her verschieben könnte ohne an die Dll denken zum müssen. Es wäre ein Tool das man einfach so Ungezipt weitergeben kann.

War sowieso für die Final gedacht. Mache ich in solchen Fällen eigentlich immer so, da ich regelmäßig vergesse die DLL in das Archiv zu packen.

Meine eigentliche Testoberfläche ist ein VCL-Programm, aber da es was richtiges werden soll, habe ich schon mal angefangen es richtig zu machen. Es ist nur eine Beta für andere zum Testen der DLL, wie zuverlässig sie funktiniert.
Ein "Speichern unter" kommt eventuell auch noch rein. dann kann man sich selbst den dateinamen aussuchen beim Codieren und Decodieren.
Die Progressbar funktioniert ja auch noch nicht und eine Möglichkeit zum Abbrechen soll ja auch noch rein.

@Mathias: Wenn du das liest, betrachte das mal als Hilfeschrei. Ich habe keinen Plan, wie die Callback-Funktion im Wrapper aussehen muß und wie ich sie dann im eigentlichen Code implementieren muß, damit ich eine Fortschrittsanzeige damit füttern und die ganze Aktion auf ButtonClick abbrechen kann. das wäre erstmal alles damit ich das programm fertig machen kann.


Anonymous - Mo 09.12.02 20:49

Luckie hat folgendes geschrieben:
Zitat:

Dann hab ich bemerkt, daß die kodierten Daten die Endung "encoded" haben. Vielleich wäre es nicht schlecht für diesen Datentyp die Option "Entschlusseln" automatisch vorzuwählen.

Redest du von einem Eintrag im Kontextmenü vom Explorer? Wäre zu überlegen.


Nein, das meinte ich eigentlich weniger. Ich meinte, daß wenn man sich die Datei ausgewählt hat (z.B. "crypter.zip.encoded"), man schon anhand der Dateiendung ".encoded" weiß ob die Datei verschlüsselt ist oder entschlüsselt. Hier wäre es logisch die Datei zu entschlüsseln. Vielleicht baust du noch zu der "Verschlüsseln"/"Entschlüsseln" Auswahl zusätzlich noch "Automatische Erkennung" ein. Ist die Endung nicht ".encoded", dann wird automatisch verschlüsselt, sonst entschlüsselt.

Zitat:
Ein "Speichern unter" kommt eventuell auch noch rein. dann kann man sich selbst den dateinamen aussuchen beim Codieren und Decodieren..


Das bitte aber nur als Option. Es ist schon ok wenn der Name automatisch erkannt wird.


Delete - Mo 09.12.02 20:55

Ach so, jetzt verstehe ich, er soll an hand der Endung erkenn, ob sie schon verschlüsselt ist und dann automatsch "entschlüsseln" vorschlagen. Dann beißt sich das aber mit dem "Speichern unter". Ich dachte nur wenn ich eine Datei von CD-ROM verschlüsseln will, dann wäre das sinnvoll. Aber mal sehen,w as sich so ergibt.

Erst mal muß ich die Progressbar zum rennen bringen, dann kommen die Feinheiten und Popov's Sonderwünsche.


hitstec - Mo 09.12.02 23:43

An sich sieht das Ergebnis schon mal guuut aus.
Aber der Komfort fehlt.

Stell dir vor ich will meine ganze Icon-Sammlung verschlüsseln.
Bis ich da jede Datei einzeln ausgewählt habe ...

Also entweder baust du ein Kommandozeilentool ein oder du machst das mit Listen wie WinZip zum Bsp.

Das Tool ist ziemlich schnell.

Woher hast du den Algo und mit wieviel Bit wird verschlüsselt? Wenn ich mal fragen darf.

:wink:


Delete - Di 10.12.02 01:46

Pack deine Icon-Sammlung vorher mit WinZip und dann laß mein Programm drüber laufen. :wink:

http://www.borfig.com/crypter/dll/


Delete - Di 10.12.02 08:21

Hilfeschreie werden von mir grundsätzlich beantwortet. :)
Also, Luckie, in der PDF-Doku der DLL (Seite 13) findest du eine Beispielfunktion. Ausgehend davon mein Vorschlag für Delphi:

Quelltext
1:
2:
3:
4:
5:
6:
7:
8:
9:
10:
11:
12:
13:
14:
15:
16:
17:
18:
19:
20:
21:
22:
23:
24:
25:
26:
27:
28:
var
  maxvalue : longint;

function TypicalCallBack(reasaon: TCrypterCallBackReason;
  data: longint): integer; stdcall;
begin
  case reason of
    CCBF_FILELENGTH:
      maxvalue := data;
    CCBF_PROGRESS:
      Progressbar1.Position := MulDiv(data,100,maxvalue);
    else begin
      ShowMessage('Och, ´n Fehler');
      Result := 123;
      exit;
    end;
  end;

  // EDIT -->
  Application.ProcessMessages;
  // ist sicher sinnvoll, damit man auch auf "Abbrechen"
  // klicken kann

  Result := 1;
  // ausgehend von dem Hinweis der Doku, dass die Funktion
  // einen Wert ungleich Null zurückgeben MUSS, damit der
  // Prozess weitergeht
end;

In deinem Wrapper brauchst du die Funktion nicht. Du brauchst sie nur in deinem Programm. Im Wrapper ist sie ja bereits als Typ implementiert.


Delete - Di 10.12.02 08:56
Titel: Zum Abbrechen ...
... als Nachtrag. Ich würde das Funktionsergebnis vielleicht von einer globalen Variablen abhängig machen:

Quelltext
1:
2:
3:
4:
5:
6:
7:
8:
9:
10:
var
  iBreak : integer = 1;

function TypicalCallBack(reasaon: TCrypterCallBackReason;
  data: longint): integer; stdcall;
begin
  { ... }

  Result := iBreak;
end;

Klickt jetzt wer auf den Button, wird die Variable auf Null gesetzt:

Quelltext
1:
2:
3:
4:
procedure TForm1.CancelBtnClick(Sender: TObject);
begin
  iBreak := 0;
end;

Der nächste Aufruf der Callback-Funktion wäre dann wohl auch der letzte, wenn man der Doku trauen darf.


Delete - Di 10.12.02 09:04

Langsam, ich bin gerade am arbeiten. In deiner Callback war ein Flüchtigkeitsfehler: 2x case :o).

Jetzt habe ich nur noch ein Problem die Callback in EnCodeFile aufzurufen. Leider muß man anscheinedn die Dateigröße selber bestimmen.


Delete - Di 10.12.02 10:57

Luckie hat folgendes geschrieben:
In deiner Callback war ein Flüchtigkeitsfehler: 2x case :o).

Nein, das ist ein richtiger Fehler. Das ist ein Rest der C-Funktion. Du weißt schon:

Quelltext
1:
2:
3:
4:
switch(reason) {
  case Grund1:
  case Grund2:
}


Delete - Di 10.12.02 11:02

Sind wir unter die Copy and Paste Programmierer gegangen? :wink:


Udontknow - Di 10.12.02 13:51

Hi!

Ein paar Kritikpunkte:

- Kein Drag&Drop von Dateien
- Wenn ich eine Datei enschlüssele, die gar keine kodierte Datei ist, schmiert das Programm ab, Runtime Error.
- Durch die unterschiedliche Grösse der Datei findet man schnell heraus, wo die Passwortprüfsumme ist. Evtl ZLiB benutzen?
- Ausserdem hatte ich eine merkwürdige Begebenheit: Ich habe eine Datei kodiert, der Text war aber genau so wie vorher, nur kamen in die erste Zeile ein paar zusätzliche Zeichen (ich nehme mal an, die ersten 12 Byte sind die Prüfsumme/der Hash für das Passwort). Leider konnte ich das nicht wieder nachvollziehen... :roll:

Cu,
Udontknow[/list]


Delete - Di 10.12.02 14:10

Immer langsam mit den jungen Pferden. Das was ich hier veröffentlicht habe war ja nur um die DLL auf ihre Zuverlässigkeit zu testen.

Aber danke für die Anregungen. Mit den Anregungen von Popov steckt da ja noch einiges Potential drin. Mal sehen, wie ehrgeizig ich bin und was ich davon verwirkliche.

Mittlerweile wurde das Callback-Problem gelöst dank Mathias aka Callback Simmack.


Delete - Mi 11.12.02 04:07

So die nächste Version ist fertig und wir kommen so langsam aus der Beta-Phase raus.

Was ist neu?
- Zielordner ist wählbar
- Dateien können per drag and drop auf das Fenster gezogen werden
- Fortschrittsanzeige
- Abrechen möglich
- DLL ist jetzt einkompiliert und wird bei Bedarf extrahiert

Downloadlink ist noch gültig: [url=http://www.luckie-online.de/downloads/cryptersfx.exe]File-Crypter[/url]


Anonymous - Mi 11.12.02 06:51

Wenn ich das Programm starte und eine Datei per DD auf dem Programm ablege, dann bleibt das Passwortfeld NOT ENABLED.

Das mit Parameter hast du wohl noch nicht eingebunden.

Die automatische Vorauswahl (Verschlüsseln/Entschlüsseln) auch noch nicht.


Delete - Mi 11.12.02 09:06

Ups, irgendwas mußte man ja vergessen. :?


Delete - Mi 11.12.02 09:23

Noch ein kleiner Bug:

Wunschzettel:

Mehr weiß ich nicht. Reicht ja auch. Und während du damit beschäftigt bist, habe ich die volle Kontrolle über die Tutorials. 8)


PS: DLL im Programm verpacken ... hm, ich find´s albern, aber na ja ... :wink:


Delete - Mi 11.12.02 09:48

Angefaneg hat alles als kleines Tool für mich persönlich, dann dachte ich: "Na ja , laß ich es mal testen und eventuell können es auch noch andere brauchen." Und was wird jetzt darauß? So langsam habe ich das gefühl, das wird ein Monster, dass mich auffrißt. :shock:

Also:
# Checkbox zum Löschen der Originaldatei ist schon eingeplant.
# Automatische Erkennung, wäre auch noch drin
# Eine Liste erst in der version 3.x

Was ich definitiv nicht machen werde, ist es in das Explorer-Kontextmenü integrieren. UInd das ganzeinfach aus dem Grund, weil ich es nicht leiden kann wenn sich da was ungewollt einträgt, das gilt dann auch für die Registry. Man könnte das optional machen, aber ich finde das ist dann doch etwas zu viel Overkill für die winzige Idee, die hinter dem kleinen Tool steckte.


DeCodeGuru - Mi 11.12.02 17:42

alles in allem ein schönes Programm. Großes Lob!!!

Zitat:
So langsam habe ich das gefühl, das wird ein Monster, dass mich auffrißt.


Mach mal langsam. Zu viel Arbeit ist auch nit gut. :mrgreen:

Ansonsten würde ich sagen: Mach weiter so und ich werde die Entwicklung des Programm im Auge behalten.


Delete - Mi 11.12.02 17:48

Na dann wollen wir deinen Augen mal wieder was bieten:

[url=http://www.luckie-online.de/downloads/cryptersfx.exe]File-Crypter[/url]


JeanvanHees - Do 12.12.02 08:27

Also ich hab die vorherige versionen nicht ausprobiert aber bei mir passiert nichts wenn ich datei öffnen selectiere... :(


Delete - Do 12.12.02 09:16

Wie passiert nichts? Bei mir geht dann der Datei-öffnen Dialog auf. Was für ein OS?


JeanvanHees - Do 12.12.02 09:50

Windows NT


Delete - Do 12.12.02 09:55

Also getestet ist es unter WinME und Win2000 und da funktioniert es wunderbar. bei ME habe ich nur manchmal den Effekt, dass der Pfad manchmal nicht richtig angezeigt wird. das hat aber keinen Einfluß auf die Funktionsweise des Programmes - sollte zu mindest nicht.


O'rallY - Do 06.02.03 11:36

Ein kleiner Makel ist mir aufgefallen: Wenn man eine Datei Verschlüsselt, wird an den Dateiname *encoded angehängt. Soweit so gut. Doch wenn ich die Datei nun wieder entschlüssele hab ich eine Datei die z.B. so heißt: datei.txt.encoded.decoded
Es wär nicht schlecht wenn du sie dann einfach wieder *.txt nennen könntest.

Und auch nicht schlecht wäre eine Option, dass die Originaldatei nach dem Verschlüsseln gelöscht wird.


Popov - Fr 11.04.03 09:10

@Luckie

Ich hab gestern ein kleinen Praxis-Test gemacht und deinen Crypter angewendet. Dabei sind mir paar Punkte aufgefallen:

Der Button "Datei öffnen" funktioniert nicht. Es öffnet sich kein Dialogfenster. Das ist mir aber schon bei einem anderen Programm von dir aufgefallen (DLLExports). Kann es sein, daß du schon XP Dialogfenster anwendest? Ich konnte mir mit D&D behelfen, aber es ist eben nicht das gleiche.

Das andere scheint heute zu funktionieren. Deshalb war das vorerst.

Übrigens, wolltest du die Dll nicht als Ressorce packen und erst beim bedarf entpacken?


Delete - Fr 11.04.03 09:14

Wieder dein Windows98 oder? :( Mist immer diese Versionskonflikte. ich werde mal kucken. Mit der AdressDB hattets du ja das gleiche Problem. ich werde das mal fixen.
Bei DLLExports habe ich es wieder zrück geändert weil es da unter 98 nicht ging. Sag mir mal du bei der AdressDB Probleme hast.

Die DLL ist in der Ressource drin. :wink:


Delete - Fr 11.04.03 09:24

So beide Datei-Öffnen-Dialoge sind jetzt wie in der AdressDB. Probier mal bitte.


Delete - Sa 12.04.03 08:13

Luckie hat folgendes geschrieben:
Wieder dein Windows98 oder? :( Mist immer diese Versionskonflikte.

Es gibt keinen Versionskonflikt. Nicht, wenn du 100% sicher bist, dass deine Delphi-Version den erweiterten TOpenFilename-Typ beinhaltet.

Quelltext
1:
2:
3:
4:
5:
6:
7:
8:
9:
10:
11:
12:
13:
14:
15:
16:
17:
18:
19:
20:
21:
22:
23:
24:
25:
26:
27:
28:
type
  tagOFNA = packed record
    lStructSize: DWORD;
    hWndOwner: HWND;
    hInstance: HINST;
    lpstrFilter: PAnsiChar;
    lpstrCustomFilter: PAnsiChar;
    nMaxCustFilter: DWORD;
    nFilterIndex: DWORD;
    lpstrFile: PAnsiChar;
    nMaxFile: DWORD;
    lpstrFileTitle: PAnsiChar;
    nMaxFileTitle: DWORD;
    lpstrInitialDir: PAnsiChar;
    lpstrTitle: PAnsiChar;
    Flags: DWORD;
    nFileOffset: Word;
    nFileExtension: Word;
    lpstrDefExt: PAnsiChar;
    lCustData: LPARAM;
    lpfnHook: function(Wnd: HWND; Msg: UINT; wParam: WPARAM; lParam: LPARAM): UINT stdcall;
    lpTemplateName: PAnsiChar;

    // NEU -->
    pvReserved: pointer;
    dwReserved: dword;
    FlagsEx: dword;
  end;

Aber dann brauchst du die Größen (OPENFILENAME_SIZE_VERSION_400) auch nicht selbst deklarieren, die sollte Delphi dann kennen. Der Fehler lässt sich ja auch recht einfach erklären: Die älteren Windows-Versionen können mit den letzten drei Parametern nichts anfangen. Benutzt du also den erweiterten Typen, dann musst du die Größe entsprechend reduzieren, damit das Betriebssystem nur die ihm bekannten Parameter benutzt:

Quelltext
1:
2:
OPENFILENAME_SIZE_VERSION_400A = sizeof(TOpenFileNameA) -
  sizeof(pointer) - (2 * sizeof(dword));

In dem Fall werden also der Pointer (4 Bytes) und die zwei DWORDs (8 Bytes) entfernt, und der Typ entspricht dem Original der CommDlg-Unit.

Dieser Originaltyp allerdings kennt die drei neuen Membervariablen nicht! Wendest du die Konstante OPENFILENAME_SIZE_VERSION_400 hier an, dann entfernst du (wahrscheinlich) "lCustData", "lpfnHook" und "lpTemplateName". (Unter der Voraussetzung, dass die drei genannten Membervariablen auch jeweils 4 Bytes belegen.) Der Typ stimmt also nicht mehr, weil die Größe falsch angegeben wurde, und darum passiert bspw. unter Windows 98 auch nichts.

Was nun den Crypter angeht: Wird die Zeile

Quelltext
1:
ofn.lStructSize := OPENFILENAME_SIZE_VERSION_400                    

durch

Quelltext
1:
ofn.lStructSize := sizeof(TOpenFileName);                    

ersetzt, tritt der Fehler auch nicht mehr auf.


Delete - Sa 12.04.03 08:27

MathiasSimmack hat folgendes geschrieben:

Was nun den Crypter angeht: Wird die Zeile

Quelltext
1:
ofn.lStructSize := OPENFILENAME_SIZE_VERSION_400                    

durch

Quelltext
1:
ofn.lStructSize := sizeof(TOpenFileName);                    

ersetzt, tritt der Fehler auch nicht mehr auf.

So hatte ich es doch erst und dann hat er sich beschwert dass es nicht ginge. War übrigens bei der Export- und Improtfunktion meiner AdressDB genauso. Ich habe es dann extra geändert und dann meinte er es ginge.

Kann es daran liegen, dass du D5 hast und ich D6?

Aber das entscheidende ist doch jetzt: Geht dieser Code

Quelltext
1:
ofn.lStructSize := OPENFILENAME_SIZE_VERSION_400                    

unter Win98 ja oder nein. Bitte eien klare Antwort?


Delete - Sa 12.04.03 09:31

Luckie hat folgendes geschrieben:
Kann es daran liegen, dass du D5 hast und ich D6?

Eigentlich nicht, weil erst D7, IMHO, die komplette neue Deklaration (s. oben) enthält. D6 dürfte auch nur den Originaltypen kennen. Aber da bin ich nicht 100% sicher. Diese Frage könntest du mit Hilfe der Code-Vervollständigung klären, wenn du keinen Zugriff auf die Units hast.

Als Beispiel: ich glaube, dass den Tutorials die Unit "CommDlg_Fragment.pas" beiliegt. Diese enthält den erweiterten TOpenFileName-Typen. Benutze ich diese Unit mit deinem FileCrypter, dann funktioniert es mit der Zuweisung:

Quelltext
1:
ofn.lStructSize := OPENFILENAME_SIZE_VERSION_400;                    

auch unter Win 98 problemlos. Aber das liegt, wie oben erklärt!, daran, dass hier der erweiterte Typ verwendet und größen-reduziert wird, so dass er dem Original aus der CommDlg entspricht. Und dann geht das nämlich auch.

Zitat:
Geht dieser Code

Quelltext
1:
ofn.lStructSize := OPENFILENAME_SIZE_VERSION_400                    

unter Win98 ja oder nein. Bitte eien klare Antwort?

Nein! Nicht bei mir! Und nicht, wenn du vom Quellcode sprichst. Der benutzt nämlich nur die Unit CommDlg. Und die enthält in meinem Fall (D5) nur den alten Typ von TOpenFileName. Das Problem habe ich ja erklärt: der wird jetzt um 12 Bytes gekürzt, und dadurch funktioniert es nicht mehr.

Interessant ist (wie bei DLLExports), dass die kompilierte Version von dir den Dialog anzeigt. Der Fehler beschränkt sich daher für mich nur auf den beiliegenden Quellcode. (Hast du dir eigentlich mal meine modifizierten Versionen von DLLExports angesehen, oder ist die Mail gar nicht angekommen?)


Wenn es bei dir unter Win 2000 so klappt:

Quelltext
1:
ofn.lStructSize := OPENFILENAME_SIZE_VERSION_400;                    

und du keine angepasste oder extra Unit mit dem erweiterten TOpenFileName verwendest, dann muss ich passen: Den Grund für das Funktionieren kann ich dir in dem Fall nicht nennen.


Delete - Sa 12.04.03 09:53

PSDK (GetOpenFileName) hat folgendes geschrieben:
Windows NT 4.0: The OPENFILENAME structure includes additional members on more recent versions of Windows. However, this causes problems for applications on previous versions of Windows. To use the current header files for applications that must run on Windows NT 4.0, either use the #define "/D_WIN32_WINNT=0x0400" or use OPENFILENAME_SIZE_VERSION_400 for the lStructSize member of OPENFILENAME.

Obwohl hier nur von NT4 die Rede ist, gilt das auch für 95 und 98. Wie das bei ME ist, weiß ich nicht. Könnte ein mitlesender ME-Besitzer mal Luckies Quellcode kompilieren und ausprobieren? (Nicht die bereits von Luckie kompilierte Version! Die funktioniert bei mir auch.)


btw: Luckie, du müsstest mal deine Postings kontrollieren. Hier gibt´s einen oder zwei Links, die ins Leere führen (http://www.luckie-online.de/downloads/crypter.zip --> Error 404).


Delete - Sa 12.04.03 18:54

Aaah, ich werde noch mal irre. Jetzt noch mal für den kleinen, arme, irren, Luckie zum Mitschreiben:
Was muß ich machen, damit es auch ohne die Fragement-Datei unter beiden OS läuft?


Delete - Sa 12.04.03 19:02

Auf die Fragmentdatei CommDlg_Fragment verzichten und den alten Typ benutzen. Nach den Tests mit dem Standarddialoge-Beispiel aus den Tutorials funktioniert er auch unter ME, 2000 und XP.

Die Konstanten "OPENFILENAME_SIZE_VERSION_xxx" entfernst du aus dem Quelltext und benutzt stattdessen, wie gehabt,

Quelltext
1:
sizeof(TOpenFileName)                    


Wenn man es genau nimmt, hat von den drei neuen Membervariablen eigentlich nur FlagsEx einen Sinn. Die anderen beiden sind bisher reserviert und Null/nil.

Du könntest auch von mir eine mittlerweile bereinigte Version bekommen. :wink: Allerdings habe ich auch die Sache mit der DLL in den Ressourcen entfernt. Das müsstest du evtl. ergänzen.


Delete - Sa 12.04.03 19:11

Gut, danke. Das wollte ich doch nur wissen. Aber so hatte ich es doch, denke ich. Na egal. Jetzt wird es so gemacht und wer ein veraltetes OS von MS benutzt ist selber schuld. :roll:


Delete - So 13.04.03 07:51

Luckie hat folgendes geschrieben:
Gut, danke.

Bitte. Gern geschehen.

Zitat:
Das wollte ich doch nur wissen. Aber so hatte ich es doch, denke ich.

Das mag sein. Aber dann hast du für die Veröffentlichung die Fragmentdatei aus dem Quellcode wieder entfernt. Dadurch kam es zu dem Fehler. Das ist sowieso der Punkt, den ich nicht so ganz verstehe.
Bei DLLExports hattest du schon geschrieben, der Quellcode wäre aktueller als die Exe. Wenn ich etwas samt Sourcen veröffentliche, dann kompiliere ich die fertige Version immer mit dem Quellcode, den ich veröffentlichen will. Auf die Weise gibt es keinerlei Unterschiede.

Musst mal deine Veröffentlichungspolitik überdenken. :wink:

Zitat:
Na egal. Jetzt wird es so gemacht und wer ein veraltetes OS von MS benutzt ist selber schuld. :roll:

Das hat mit dem OS nichts zu tun. ´s liegt nur am Programmierer, der uns seine Tools aufs Auge drücken will. :twisted:


Delete - So 13.04.03 07:57

MathiasSimmack hat folgendes geschrieben:

Bei DLLExports hattest du schon geschrieben, der Quellcode wäre aktueller als die Exe.

Das war natürlich nicht erst gemeint du Dussel. :wink: Ich kompiliere und bevor ich das Archiv erstelle wird die Exe aus dem Sourceverzeichnis eins nach oben verschoben und dann wird das Archiv erstellt.


Delete - Mo 14.04.03 06:17

So DLLExports jetzt wiede rmit sizeof(TOpenfilename).

@Mathias: Jetzt liegt eine Batch dabei die mir alles abnimmt, kompilieren, in den richtigen Ordner verschiben, Archiv erstellen, umbenennen und in sfx-Archiv konvertieren. Ich suche nur nach einer Möglichkeit, die Batch mit Parametern aufrufen zu können


Popov - Mo 14.04.03 17:49

Achso, hab ich vergessen zu sagen. Jetzt funktioniert es ;)


Delete - Mo 14.04.03 17:53

Ich weiß jetzt ehrlich gesagt nicht was du für eine Version hast. Kuck mal bitte im Quellcode was jetzt für eien Strukturgröße bei TOpenfilename (ofn) angegeben ist.


Popov - Mo 14.04.03 21:30

Die Programmversion ist 2.3

Das andere hier also Codekopie:

Quelltext
1:
2:
3:
4:
5:
6:
7:
8:
  {$EXTERNALSYM OPENFILENAME_SIZE_VERSION_400A} 
  OPENFILENAME_SIZE_VERSION_400A = sizeof(TOpenFileNameA) - 
    sizeof(pointer) - (2 * sizeof(dword)); 
  {$EXTERNALSYM OPENFILENAME_SIZE_VERSION_400W} 
  OPENFILENAME_SIZE_VERSION_400W = sizeof(TOpenFileNameW) - 
    sizeof(pointer) - (2 * sizeof(dword)); 
  {$EXTERNALSYM OPENFILENAME_SIZE_VERSION_400} 
  OPENFILENAME_SIZE_VERSION_400  = OPENFILENAME_SIZE_VERSION_400A;


Delete - Di 15.04.03 07:22

Das sind die Angaben aus der externen Fragmentdatei, die sich (warum auch immer) in Luckies Programm "verirrt" haben. Die sind aber nur hilfreich, wenn man den erweiterten Typ benutzt. - Schau mal in die Funktion "OpenFile", da sollte das hier stehen:

Quelltext
1:
ofn.lStructSize := sizeof(TOpenFileName);                    

Dann funktioniert´s auch.

Ich glaube, die aktuelle Version ist noch nicht online. Das Veröffentlichungsdatum auf Luckies HP ist immer noch der 25. Januar. Das dürfte noch die Version 2.3 sein.

Außerdem wiederhole ich meine Bitte: es gibt zwei Beiträge vom 11.12 (5 Uhr und 18 Uhr) mit zwei ungültigen Links.


Delete - Di 15.04.03 07:40

So der Crypter jetzt auch wieder mit sizeof(TOpenFilename).

Links korrigiert.


Delete - Sa 26.04.03 19:28

Und eine neue Version ist da:
Der Zielordner läßt sich jetzt wählen und das Passwort wird überprüft bei der Eingabe.

Die Links sind noch gültig. [url=http://www.luckie-online.de/cgi-bin/load.cgi?downloads/cryptersfx.exe]Crypter[/url]

Bitte nach Open-Source verschieben, die Sourcen sind jetzt dabei. Danke.


hitstec - Do 17.07.03 15:55

Seit neuestem ist FileCrypter bei der PC-Welt: http://www.pcwelt.de/downloads/utilities/datensicherheit/32542
Ist sogar im Shareware-Newsletter erwähnt worden.

Trotzdem: Nicht mal nach 10 sek. Benutzen des Tools habe ich eine gravierende Sicherheitslücke entdeckt. Für mehr Infos -> PM.


Delete - Do 17.07.03 17:19

So, als zusätzliches Feature wird jetzt die Sicherheit des Passwortes in Prozent angegeben.

Download: [url=http://www.luckie-online.de/cgi-bin/load.cgi?downloads/cryptersfx.exe]Crypter 2.7[/url] (198 KB)


O'rallY - Do 17.07.03 17:26

Wie wertest du denn die Sicherheit aus?
Eine Zahlenfolge wie 123456789 wird nicht als sicher bewertet, warum aber abcdefg?


Delete - Do 17.07.03 17:29

http://www.delphipraxis.net/viewtopic.php?t=7060


Addi - Do 17.07.03 18:00

Schade.

Bin zwar Anfänger aber warum kann man hier nur bei dem Teil einzelne Dateien Verschlüsseln und nicht ganze Ordner bzw. mehrere Dateien?

Wäre echt vorteilhafter.

cu Addi


StefanH - Do 17.07.03 19:03

Addi hat folgendes geschrieben:
Schade.

Bin zwar Anfänger aber warum kann man hier nur bei dem Teil einzelne Dateien Verschlüsseln und nicht ganze Ordner bzw. mehrere Dateien?

Wäre echt vorteilhafter.

cu Addi


Zip sie halt zusammen


Delete - Do 17.07.03 19:05

Addi hat folgendes geschrieben:
Schade.
Bin zwar Anfänger aber warum kann man hier nur bei dem Teil einzelne Dateien Verschlüsseln und nicht ganze Ordner bzw. mehrere Dateien?

Weil ich es so programmiert habe? :wink:
Zitat:

Wäre echt vorteilhafter.

Man muß sich ja Optionen für Updates offen lassen.


JayEff - Mi 02.06.04 22:29

Zurück zur Schlüssel länge: RSA ist Ami werk. die amis erlauben es nicht, Verschlüsselungssofter mit mehr als .. äääh... glaub 64 byte schlüsseln zu exprotieren. ich vermute, die NSA glaubt, sie ist in der lage, so was zu knacken. also falls das Proggy mit mehr als 64 Zeichen arbeitet, und die ami bestimmungen wirrrrklich streng sind, würd ich dir empfehlen das zu begrenzen. aber 46byte RSA gilt dennoch alls die Sicherste Verschlüsselung überhaupt.(mit SSL und diesen Kommerziellen sachen)


Delete - Do 03.06.04 12:01

Warum sollte ich das begrenzen? Ich bin deutscher, wohne in Deutschland, meine HP liegt auf einem deutschen Server, der in Deutschland steht, also nach meinem Gesundenmenschenverstand gilt für mich deutsches Recht. :roll:


Delete - Do 03.06.04 12:35

Luckie hat folgendes geschrieben:
Gesundenmenschenverstand

*kicher*


JayEff - Do 03.06.04 13:06

klar. hab aber auch nie behauptet, das die amerikanische regierung gesunden menschenverstand hat, oder??!! :roll:


Delete - Do 03.06.04 13:27

JayEff hat folgendes geschrieben:
klar. hab aber auch nie behauptet, das die amerikanische regierung gesunden menschenverstand hat, oder??!! :roll:

Also entweder wir diskutieren hier ernsthaft oder wir lassen es beleiben. Verarschen kann ich mich selber. Also warum sollte ich als Deutscher der in Deutschland wohnt irgend etwas mit dem US amerikanischen Gesetzten am Hut haben? :roll:


FaTaLGuiLLoTiNe - Do 03.06.04 13:30

@Luckie
Was mich jetzt mal interessieren würde: Wo steckt bei Dir der Schwindel? In Deinen letzten Beiträgen oder in Deinem Profil?

Gibt es noch ein Bundesland in Deutschland, von dem ich bisher nichts gehört habe? Oder bist Du etwa fanatischer Elvis Presley - Fan?


JayEff - Do 03.06.04 13:34

Ich wollt hier niemanden verarschen! ich hab das ernst gemeint(wenn man von Bush redet...). du sagst, du benutzt den RSA Algorythmus, das heist, du benutzt Ami sachen. aber eigenlich ist es egal, da sowieso nie irgent ein depp von der NSA hier ins hobbyprogramier forum guggt und nach Programmen sucht, die Amerikanische Gesetze verletzen.
ich wollts nur gessagt haben, dass das so ist.


Motzi - Do 03.06.04 22:14

Wieso sollte es Gesetze verletzen..? Das US-Patent für RSA ist am 20. September 2000 abgelaufen, außerdem gibt es für den Export von Kryptographie aus den USA Ausfuhrbestimmungen und wir sind hier nicht in den USA.


JayEff - So 06.06.04 13:28

ach das teil is abgelaufen? na dann issed ja jut^^ also kp mach nen 1024 byte schlüssel...^^


mirage228 - So 06.06.04 14:11

JayEff hat folgendes geschrieben:
ach das teil is abgelaufen? na dann issed ja jut^^ also kp mach nen 1024 byte schlüssel...^^


Ne... 4096er muss schon sein ;)

mfG
mirage228