Verschlüsselungstool für USB-Stick (AKrypto)

  • Also der Fehler ist aufgetreten als ich die 64bit kompilierte AKrypto Datei getestet habe. also höchstwahrscheinlich währ der Fehler auch aufgetreten wenn ich es mit 64 bit gestartet hätte
    aber es funktioniert ja halt auf 32bit wie ich ja danach auch bemerkt hatte.
    Nichts Wichtiges, es geht alles nur wenn es mit 64bit gestartet wird. liegt aber glaube ich auch an den UDF´s.
    Kannst ja mal erwähnen das es nur unter 32 bit läuft :rolleyes:
    aber sons alles Super^^

    Sind TV-Quizfragen zu einfach? A) Ja B) Harry Potter

    Spoiler anzeigen

    Ich gebe zu dieser Post hat wahrscheinlich nicht viel geholfen,
    aber ich versuche wenigstens zu helfen :rolleyes:

  • Ich habe mir den Fehler mal angesehen. Er liegt erstens an der "_MemoryDll-UDF", die in der bisher eingesetzten Version nicht 64bit tauglich war. Konnte ich ersetzen. Das war die gute Nachricht.

    Nur...

    Die UDF "_AES.au3" (von WARD aus dem englischen Forum), welche eine interne DLL mitbringt, scheint leider auch nicht mit 64bit zu funktionieren. Jedensfalls klappt es mit 32bit noch und sobald ich es unter 64bit-AutoIt teste, ist das erwartete Array kein Array mehr. Also Leer !

    Meine Idee war nun, unter 64bit auf die neuen AutoIt-Internen Funktionen für AES256 zurückzugreifen. Die UDF von WARD habe ich genutzt, damit AES auch auf älteren Windows-Version läuft. Nur finde ich keine identische (interne) Funktion, damit die verschlüsselten Daten untereinander kompatible bleiben.

    Wer also eine AutoIt-Interne (Datenkompatible) Alternative für die WARD-AES-Funktion:

    [autoit]

    _AesEncryptFile($sKey, $sSource, $sDestinationC, "CFB")

    [/autoit]


    kennt, würde mir damit weiterhelfen.

    Zur Nutzung dieses Forum's, ist ein Übersetzer für folgende Begriffe unerlässlich:

    "On-Bort, weier, verscheiden, schädliges, Butten steyling, näckstet, Parr, Porblem, scripe, Kompletenz, harken, manuel zu extramieren, geckukt, würglich, excell, acces oder Compilevorgeng"

    Einmal editiert, zuletzt von Micha_he (24. März 2012 um 09:33)

  • Das mit dem Fehler der "AES.au3" unter dem 64bit-Modus konnte ich mit einem Tip von "Ward" (Originalautor aus dem englischen Forum) lösen. Er hatte bereits neue UDFs geschrieben, welche das Problem nicht haben und diese werde ich im nächsten Release einsetzen.

    Ein offenes Problem im Zusammenhang mit 64bit existiert noch:
    Die Funktion "_ShellExecuteEx()" hat auch ein Problem mit dem 64bit Mode. Ich benötige aber die Prozess-ID der mit ShellExecute() gestarteten Datei.

    Als Aternative hatte ich die StartFile()-Funktion von AspirinJunkie im Auge. Nur beachtet diese Funktion auch nicht alle Registry-Pfade unter HKCR, HKCU\Software\Classes, HKCU\Software\Microsoft\Windows\CurrentVersion\Explorer\FileExts. Ist alles ziemlich umfangreich, an die für den User aktuelle Anwendung für einen Dateityp zu kommen.

    Zweite Alternative:
    Die Funktion "_WinAPI_FindExecutable()". Findet scheinbar sauber die passende Anwendung, leider ohne Info's zur Parameterübergabe. Die Funktion gibt nur die EXE zurück und informiert nicht in, welcher Form die Datei als Parameter hinzugefügt werden muss.

    Eine fertige Funktion, wäre mir schon (aus Zeitgründen) willkommen. Hat sich damit in letzter Zeit jemand beschäftigt ?

    Sonst muss ich mich selbst ransetzen....

    Zur Nutzung dieses Forum's, ist ein Übersetzer für folgende Begriffe unerlässlich:

    "On-Bort, weier, verscheiden, schädliges, Butten steyling, näckstet, Parr, Porblem, scripe, Kompletenz, harken, manuel zu extramieren, geckukt, würglich, excell, acces oder Compilevorgeng"

  • Neue Version 0.510 (Siehe Post #1) mit folgenden Anpassungen:

    - Abbruchfehler beim Neuanlegen einer Datei beseitigt.
    - Fehler bei der Passwortabfrage (geändert in V0.505) korrigiert.
    - _ShellExecuteEx() durch neue Funktion _StartFile2() ersetzt.
    - Fehlerbehandlung bei 0-Byte-Dateien integriert.
    - Dateitypen-Bezeichnung eingedeutscht.
    - Fehler in der relative Adressierung auf GUI-Objekte in der Funktion _ShowFolder() korrigiert.
    - Umbenennen von Dateien/Ordnern per Kontextmenü integriert.
    - Läuft jetzt auch im 64bit-Mode.
    - FileOpen-Fehler in UDF "_AESFile.au3" eingefügt, damit die Funktion _DecryptAll() darauf reagieren kann.

    Viel Spaß beim Testen...

    Zur Nutzung dieses Forum's, ist ein Übersetzer für folgende Begriffe unerlässlich:

    "On-Bort, weier, verscheiden, schädliges, Butten steyling, näckstet, Parr, Porblem, scripe, Kompletenz, harken, manuel zu extramieren, geckukt, würglich, excell, acces oder Compilevorgeng"

    Einmal editiert, zuletzt von Micha_he (29. März 2012 um 16:10)

  • Nutzt Du unter Umständen die aktuelle Beta-Version von AutoIt ?

    Das Programm sollte unter der stable V3.3.8.1 ohne Probleme laufen.

    Edit:
    Habe gerade festgestellt, das hinter dem Stable-Download welcher mit "3.3.8.1" beschriftet ist, eine scheinbar neue stable 3.3.10.2 zur Installation bereit steht.
    Mit dieser neuen 3.3.10.2 ist leider die Abfrage

    [autoit]

    If @AutoItVersion < "3.3.8.0" Then ...

    [/autoit]

    wahr, obwohl eine Version 3.3.10.2 genutzt wird. Warum muss diese Unter-Unterversion nun 2stellig sein ?

    Zur Nutzung dieses Forum's, ist ein Übersetzer für folgende Begriffe unerlässlich:

    "On-Bort, weier, verscheiden, schädliges, Butten steyling, näckstet, Parr, Porblem, scripe, Kompletenz, harken, manuel zu extramieren, geckukt, würglich, excell, acces oder Compilevorgeng"

    4 Mal editiert, zuletzt von Micha_he (14. Januar 2014 um 13:27)

    • Offizieller Beitrag

    Mit dieser neuen 3.3.10.2 ist leider die Abfrage

    [autoit]

    If @AutoItVersion < "3.3.8.0" Then ...

    [/autoit]

    wahr, obwohl eine Version 3.3.10.2 genutzt wird. Warum muss diese Unter-Unterversion nun 2stellig sein ?


    Weil Du einen Stringvergleich (Zeichen für Zeichen von links nach rechts) vornimmst und die "1" nunmal kleiner ist als die "8".
    Am besten verwendest Du "_VersionCompare()":

    [autoit]

    If _VersionCompare(@AutoItVersion, "3.3.8.0") < 0 Then

    [/autoit]
  • Neue Version 0.511 im ersten Beitrag.

    Änderungen:

    • Anpassung an AutoIt V3.3.10.x vorgenommen, indem die Versionskontrolle auf _VersionCompare()
      der Misc.au3-UDF umgestellt wurde. (Danke Oscar, so etwas habe ich gesucht und nicht gefunden !)

    Zur Nutzung dieses Forum's, ist ein Übersetzer für folgende Begriffe unerlässlich:

    "On-Bort, weier, verscheiden, schädliges, Butten steyling, näckstet, Parr, Porblem, scripe, Kompletenz, harken, manuel zu extramieren, geckukt, würglich, excell, acces oder Compilevorgeng"

  • Genial. Mir fehlen die Worte :D

    Steve

    [Blockierte Grafik: http://stefan.blagojevic.at/loading.gif]

    Design, Modellbau, CAD <3
    AutoCAD, ArchiCAD, REVIT (ist ein Scheiss, habe aber das Zertifikat)

    Cinema 4D, RuckZuck Statik Programm

    Michael Bay als Architekt


    Da eine Glasfassade! Booom Sichtbeton! Laminiertes Bild auf Mosaiksteinchen! Granit! Granit! Granit! Sichtbetonwand mit 50° Neigung!
    Holzverkleidung erscheint da! Boooooom!

  • Neues Update V0.512 !

    - Fehlerkorrektur: Bei der Anpassung an AutoIt V3.3.10.2 hatte sich in der verwendeten Funktion "_GUICtrlTreeView_SelectItem()" ein Fehler gezeigt, der das erweitern des TreeView-Wurzelordners beim Start verhinderte. Dieser wurde korrigiert.

    Zur Nutzung dieses Forum's, ist ein Übersetzer für folgende Begriffe unerlässlich:

    "On-Bort, weier, verscheiden, schädliges, Butten steyling, näckstet, Parr, Porblem, scripe, Kompletenz, harken, manuel zu extramieren, geckukt, würglich, excell, acces oder Compilevorgeng"

  • Folgende Änderungen in der V0.52 im Beitrag #1:

    Zur Nutzung dieses Forum's, ist ein Übersetzer für folgende Begriffe unerlässlich:

    "On-Bort, weier, verscheiden, schädliges, Butten steyling, näckstet, Parr, Porblem, scripe, Kompletenz, harken, manuel zu extramieren, geckukt, würglich, excell, acces oder Compilevorgeng"

    Einmal editiert, zuletzt von Micha_he (16. September 2019 um 16:02)

  • Hallo Micha_he

    zunächst mal vielen Dank für die Bereitstellung des Quellcodes.

    Ich möchte Dir dafür ein kleines Feedback zurückgeben. :D

    Mir ist bei einem Test mit kompilliertem AKrypto (x86) aufgefallen, dass

    1.)

    nach ausgeführten Doppelklick (im Listview) auf eine Word-Datei, das Verzeichnis "VaultTemp" angelegt wird.

    Soweit soll das auch so sein und ist so gewünscht.

    Was allerdings ein Sicherheitsproblem darstellen könnte ist, dass wenn man die geöffnete Datei (in meinem Fall eine Word-Datei vom Office 2010) geöffnet lässt, also AKrypto bei geöffneter Word-Datei schließt, dass dann (verständlicher Weise) das Verzeichnis "VaultTemp" wegen dem gültigen Bezug auf die Word-Datei, nicht gelöscht werden kann. Somit bleibt quasi "VaultTemp" ungelöscht und sicht- und einsehbar. Und das unverschlüsselt. Anders verhält es sich mit einer x-beliebigen editierbaren Datei, welche nach der Ausführung von "AKrypto" in Notepad++ geöffnet werden kann. Da wird der Bezug auf die geöffnete Datei getrennt. Anders bei z. B. Office-Dateien.

    a) Ggf. könntest Du eine MSG-Box einzubauen, dass wenn der Ordner "VaultTemp" nicht gelöscht werden kann, dem Benutzer vor dem beenden von "AKrypto" klargemacht wird, dass die geöffnete Datei vor dem beenden von "AKrypto" geschlossen werden muss. Oder AKrypto kann nicht beendet werden solange die Datei "xxx" geöffnet ist.

    b) Das öffnen einer Datei aus dem ListView heraus, deaktiviert wird aber das ist ja nicht Sinn der Sache.

    Ich bin der Meinung, dass etwas dazu getan werden sollte.

    2.)

    Wenn man "AKrypto" öffnet aber keine Dateien oder Ordner darin verschlüsselt hat, sondern jungfräulich wieder schließt, wird erneut ein (ich nenne es mal) Masterkennwort beim nächsten angefragt. Wenn ich jetzt aber das vorher vergebene Passwort eingebe, muss ich es erneut zweimal vergeben. Das ist ein wenig verwirrend für mich gewesen bis ich geblickt habe, dass keine verschlüsselte Passwortdatei angelegt wird.

    Nach dem ersten Start der Software hielte ich einen Tooltip oder eine Nachricht für "Anfänger" gut, welche darauf hinweist, dass Dateien oder Verzeichniss per Drag & Drop eingefügt werden können (als Kopie, denn das Original der Datei bleibt weiterhin unverschlüsselt), welche dann im Ausführungsverzeichnis unter dem Ordner "Vault" verschlüsselt werden.

    3.) Wofür Du nichts kannst aber unter Windows 10 halt echt nervt, ist dass der Windows Defender voll auf die kompillierte .exe anschlägt.

    Grundsätzlich finde ich Deine Software richtig klasse umgesetzt und halte es persönlich für vollkommend ausreichend, um portabel Dateien und Ordner zu verschlüsseln.

  • Danke bazii . Idee 1a und 2 gefallen mir. Habe ich in der neuen V0.53 (Beitrag #1) umgesetzt.

    Zur Nutzung dieses Forum's, ist ein Übersetzer für folgende Begriffe unerlässlich:

    "On-Bort, weier, verscheiden, schädliges, Butten steyling, näckstet, Parr, Porblem, scripe, Kompletenz, harken, manuel zu extramieren, geckukt, würglich, excell, acces oder Compilevorgeng"

  • Gern geschehen und herzlichen Dank für die schnelle und saubere Umsetzung.

    Dass der sehr gut gestaltete Hinweis über "AKrypto" nur beim ersten Start mit einer MsgBox visualisiert wird, finde ich prima gelöst.

    Bei erneutem Test sind mir noch wenige, weitere Kleinigkeiten aufgefallen (Sag' wenns nervt :D).

    1) Beim ausführen von "Beta Run" erscheint folgende Nachricht in der Konsole: error: can't open include file <WinAPIIcons.au3>

    2) Beim ausführen von "Run" erscheint erscheint folgende Nachricht ((bei mir in Zeile 205 "If _VersionCompare(@AutoItVersion, "3.3.8.0") = -1 Then Global $WM_DROPFILES = 0x233":

    $WM_DROPFILES previously declared as a 'Const'

    3) Die ListView-Elemente "Type" und "Size" sind per Mausklick sortierbar, jedoch die Sortierung beider ListView-Spalten wird bei mir nicht richtig ausgeführt.

    4) Da "AKrypto" auf deutscher Sprachführung aufbaut, würde die entsprechende Spaltenbenennung in der Ausgangssprache des ListView Sinn machen.

    5) Wenn ich z. B. ein zusätzliches Tool mit kleinerem Fenster (irgend ein Programm) ausführe und über "AKrypto" lege und nach links oder rechts mit gedrückter linker Maustaste verschiebe, verschiebt sich bei "AKrypto" eines der zweigeteilten Fenster ungewollt mit. Tut nix böses aber fällt auf.

  • Hallo bazii.

    zu1) Ich nutze kein SciTE und kann daher nur raten, das dort eine neue Beta-Version zum Start genutzt wird. AKrypto ist im Normalfall nur bis zu der Version getestet, die im Script steht (meist die letzte Stabil). Wahrscheinlich gibt es in der neuen Version die WinAPIIcons.au3 in den Includes nicht mehr. Must Du mal schauen, was unter Umständen angepasst werden muss, falls Du Interesse daran hast.

    zu2) Ist Normal. Der Au3Check gibt den Fehler aus, weil das deklarieren im IF-Zweig nicht sauber erkannt wird. Ggf. ist mein Workaround auch nicht 100% konform. Die Zeile sollte aber im Script verbleiben ,damit es auch unter der älteren AutoIt-Version läuft, wo die Konstante fehlt.

    zu3) Fehler der in V0.52 entstanden ist, in V0.54 nun wieder korrigiert.

    zu4) Habe ich in V0.54 angepasst.

    zu5) Konnte ich nur feststellen, wenn die Maus beim Verschieben mit gedrückter Maustaste, genau über die Trennlinie zwischen TreeView und ListView kam. Sollte in V0.54 nicht mehr auftreten.

    Gruß

    Micha

    Zur Nutzung dieses Forum's, ist ein Übersetzer für folgende Begriffe unerlässlich:

    "On-Bort, weier, verscheiden, schädliges, Butten steyling, näckstet, Parr, Porblem, scripe, Kompletenz, harken, manuel zu extramieren, geckukt, würglich, excell, acces oder Compilevorgeng"

    Einmal editiert, zuletzt von Micha_he (18. September 2019 um 12:34)

  • Hallo Micha_he

    zu 1)

    Ich habe nun mal einfach die WinAPIIcons.au3 auskommentiert, das Skript kompilliert und getestet. Es sind mir keine Unfunktionalitäten aufgefallen.

    Alles andere ist von Dir prima gelöst worden. Dankeschön.

  • Ein Fehlen würde unter Umständen nur selten auffallen ! Die Funktion _WinAPI_Create32BitHICON() kommt aktuell noch aus der WinApiIcons.au3 und wird für das Icondarstellung des ListView genutzt, wenn für einen betreffenden Dateityp ein IconHandler verwendet wird. Also ziemlich selten...

    Aber normal sollte der Au3Check das ja auch in der Beta bemängeln, wenn eine Funktion nicht verfübar ist.

    Zur Sicherheit schau mal aus welche Includedatei die _WinAPI_Create32BitHICON() bei der betreffenden Beta kommt und ob diese bei den restlichen Includes dabei ist.

    Ansonsten viel Spaß damit.

    Edit: Habe gerade mal nachgesehen. In der Beta V3.3.15.0 ist die Funktion _WinAPI_Create32BitHICON() in der Includedatei 'WinAPIGdi.au3'. Sollte also mit der auskommentierten WinApiIcons.au3 auch unter der Beta einwandfrei laufen.

    Zur Nutzung dieses Forum's, ist ein Übersetzer für folgende Begriffe unerlässlich:

    "On-Bort, weier, verscheiden, schädliges, Butten steyling, näckstet, Parr, Porblem, scripe, Kompletenz, harken, manuel zu extramieren, geckukt, würglich, excell, acces oder Compilevorgeng"

    Einmal editiert, zuletzt von Micha_he (18. September 2019 um 20:45)

  • Neue V0.55 im Beitrag #1

    - Timeout in der Funktion __ExitApp() eingefügt, damit sich gestartete Task beenden können

    - Fangen der Trennlinie TreeView/ListView nur bei aktivem Fenster

    Zur Nutzung dieses Forum's, ist ein Übersetzer für folgende Begriffe unerlässlich:

    "On-Bort, weier, verscheiden, schädliges, Butten steyling, näckstet, Parr, Porblem, scripe, Kompletenz, harken, manuel zu extramieren, geckukt, würglich, excell, acces oder Compilevorgeng"

  • Kleines Update auf V0.552:

    HotKey wird während des Umbenennens von Ordnern und Dateien deaktiviert.

    Neue Versionen siehe Post #1.

    Zur Nutzung dieses Forum's, ist ein Übersetzer für folgende Begriffe unerlässlich:

    "On-Bort, weier, verscheiden, schädliges, Butten steyling, näckstet, Parr, Porblem, scripe, Kompletenz, harken, manuel zu extramieren, geckukt, würglich, excell, acces oder Compilevorgeng"