Text verschlüsseln/entschlüsseln

mumpel

Hallo!

Ich möchte Text (Passwort) entschlüsseln und verschlüsseln. Der bisher gefundene Code wirft Fehler aus. Ich vermute dass im Code veraltete Variablen genutzt werden.

Verschlüsseln:

AutoIt

#include <String.au3>


;Ändere dies nach deinem Geschmack:
$passwort = "test"
;----------------------------------------------


$level1 = _StringReverse($passwort)
$level2 = _StringToHex($level1)
$level3 = _StringEncrypt(1,$level2,"hochgeheim678&f")


Consolewrite("Verschlüsselt: "&$level3)

Alles anzeigen

Entschlüsseln:

AutoIt

#include <String.au3>


$passwort = "588D382D7F395102A3A5DBA8F7C6DC63"
Consolewrite("Passwort: "&(_StringReverse(_HexToString(_StringEncrypt(0,$passwort,"hochgeheim678&f")))))
;Dies ^ ist die Problemzeile

Eine Verschlüsselung ist zwar nicht zwingend, wäre aber eine weitere kleine Hürde. Wie muss das auf die aktuelle Version umgeschrieben werden? Danke!

Gruß, René

**alpines**

Du verwendest eine ziemlich alte Version von AutoIt, es wäre besser du updatest sie mal.
_StringReverse ist schon seit langer Zeit in StringReverse umbenannt worden und in den prebuilt-Funktionen verfügbar und _StringEncrypt flog raus.

Stattdessen kannst du jetzt die _Crypt_EncryptData-UDF verwenden und als Algorithmus RC4 nehmen, das kommt aus dasselbe hinaus.
Die Dokumentation mit einem passenden Beispiel findest du hier: https://www.autoitscript.com/autoit3/docs/l…EncryptData.htm

Damit setzt ich das ganze mal auf gelöst, da der Hauptfehlerpunkt hier die AutoIt-Version ist die schon etwas in die Jahre gekommen ist.
Lass sie dir doch mal mit einer MsgBox von @AutoItVersion ausgeben und verrate uns mal welche du verwendest (3.3.6.0, 3.3.8.1, 3.3.10.2?).

mumpel

Habs hinbekommen. Ist doch nicht so schwer wie es aussieht.

Verschlüsseln:

AutoIt

#include <Crypt.au3>
#include <MsgBoxConstants.au3>
#include <String.au3>
$passwort = "test"


;----------------------------------------------


$level1 = StringReverse($passwort)
$level2 = _StringToHex($level1)


Local $sEncrypted = StringEncrypt(True, $level2, 'password')
FileWrite(@ScriptDir & "\test.txt", $sEncrypted)




Func StringEncrypt($bEncrypt, $sData, $sPassword)
    _Crypt_Startup() ; Start the Crypt library.
    Local $sReturn = ''
    If $bEncrypt Then ; If the flag is set to True then encrypt, otherwise decrypt.
        $sReturn = _Crypt_EncryptData($sData, $sPassword, $CALG_RC4)
    Else
        $sReturn = BinaryToString(_Crypt_DecryptData($sData, $sPassword, $CALG_RC4))
    EndIf
    _Crypt_Shutdown() 
EndFunc

Alles anzeigen

Entschlüsseln:

AutoIt

#include <Crypt.au3>
#include <MsgBoxConstants.au3>
#include <String.au3>
$passwort = "ßÌCnRÕ"


;----------------------------------------------


$level1 = StringReverse($passwort)
$level2 = _StringToHex($level1)






Local $sDecrypted = StringEncrypt(False, $passwort, 'password')
      $hexToString = _HexToString($sDecrypted)
      $level4 =StringReverse($hexToString)
      MsgBox($MB_SYSTEMMODAL, '', $level4)




Func StringEncrypt($bEncrypt, $sData, $sPassword)
    _Crypt_Startup() ; Start the Crypt library.
    Local $sReturn = ''
    If $bEncrypt Then ; If the flag is set to True then encrypt, otherwise decrypt.
        $sReturn = _Crypt_EncryptData($sData, $sPassword, $CALG_RC4)
    Else
        $sReturn = BinaryToString(_Crypt_DecryptData($sData, $sPassword, $CALG_RC4))
    EndIf
    _Crypt_Shutdown()
    Return $sReturn
EndFunc

Alles anzeigen

mumpel

Ich nutze natürlich die aktuelle Version.

**alpines**

Wieso schreibst du dir überhaupt dafür eine eigene Funktion? Du kannst doch direkt die Crypt-Funktion aufrufen.
_Crypt_EncryptData($sString, $sPass, $CALG_RC4) alleine reicht da schon aus (_Crypt_Startup wird automatisch aufgerufen).

Außerdem solltest du vielleicht von RC4 wegwechseln, da das nicht sehr sicher ist.

mumpel

Zitat von alpines

Wieso schreibst du dir überhaupt dafür eine eigene Funktion?

Die habe ich aus dem Internet übernommen.

Zitat von alpines

Außerdem solltest du vielleicht von RC4 wegwechseln, da das nicht sehr sicher ist.

Ich muss mich erstmal in AutoIt einarbeiten. Der Rest kommt dann (hoffentlich) von selsbt.

mumpel

Ich habe jetzt mal mit AES experimentiert. Bei "AES128" gibt es leider ein Problem. Im verschlüsselten Zustand sind Anführungszeichen enthalten. Das führt natürlich dazu dass diese Anführungszeichen als "Abschluss" gelten, der Rest des Schlüssel dann als "ungültiger Inhalt". Bei "AES256" geht es sogar soweit dass mir unbekannte Zeichenfolgen (sieht aus wie Leerzeilen oder White-Spaces) enthalten sind mit denen ich auch nichts anfangen kann. Da bleibt doch nur RC4?

**Musashi**

Hallo @mumpel !

Vorab : Für die Daten den Variablennamen '$passwort' zu verwenden, ist keine glückliche Wahl.

Folgende Zeilen würde ich mir schenken :
$level1 = StringReverse($passwort)
$level2 = _StringToHex($level1)

Die Crypt/Decrypt-Funktion ist völlig ausreichend. Daten vorher zu drehen etc. macht es nicht sicherer, sondern nur unübersichtlich (siehe den Rat von alpines).

Die Daten besser wie folgt speichern :
Local $hFileOpen = FileOpen(@ScriptDir & "\test.txt", BitOR( $FO_OVERWRITE,$FO_BINARY))
FileWrite($hFileOpen, $sEncrypted)
FileClose($hFileOpen)

Die Daten aus 'test.txt' zu kopieren, und in eine Stringvariable einzusetzen wird aufgrund der Sonderzeichen so nicht funktionieren (ist ein Binärstring). Lese die verschlüsselten Daten (test.txt) doch einfach mittels FileRead wieder ein.

Gruß Musashi

xSunLighTx3

Zitat von mumpel

Ich habe jetzt mal mit AES experimentiert. Bei "AES128" gibt es leider ein Problem. Im verschlüsselten Zustand sind Anführungszeichen enthalten. Das führt natürlich dazu dass diese Anführungszeichen als "Abschluss" gelten, der Rest des Schlüssel dann als "ungültiger Inhalt". Bei "AES256" geht es sogar soweit dass mir unbekannte Zeichenfolgen (sieht aus wie Leerzeilen oder White-Spaces) enthalten sind mit denen ich auch nichts anfangen kann. Da bleibt doch nur RC4?

Man kann die auch im String Format lesen, sodass die eigentlich integriert sein dürfen.
Ansonsten kann man die Anführungszeichen durch andere Zeichen ersetzen und später wieder
zurücksetzen. StringReplace() o.Ä ist dafür ganz gut geeignet.
Letzte mir bekannte Möglichkeit wäre Anführungszeichen mit Apostrophen (Hochkomma) im Source ersetzen. Somit können bspw. 'text"text2' gelesen werden.

**Musashi**

Hallo @xSunLighTx3 !

Zitat von xSunLighTx3

Ansonsten kann man die Anführungszeichen durch andere Zeichen ersetzen und später wieder
zurücksetzen. StringReplace() o.Ä ist dafür ganz gut geeignet.

Ich denke nicht, dass StringReplace() in diesem Fall sinnvoll ist.
Wenn Du in einer verschlüsselten Zeichenkette einzelne Zeichen ersetzt, dann liefert die Entschlüsselung nicht das Original zurück. Zudem enthält der Binärstring i.d.R. auch Werte, die in einer normalen Stringvariablen als Steuerzeichen dargestellt werden.

Was die Anführungszeichen anbelangt, hast Du bzgl. Strings Recht.
Möchte man Anführungszeichen innerhalb eines Strings verwenden, gibt es verschiedene Varianten :
-> man nutzt außen ' ==> 'Heute ist ein "schöner" Tag '

-> man nutzt außen " ==> "Heute ist ein 'schöner' Tag "
-> man ersetzt " innen durch "" ==> "Heute ist ein ""schöner"" Tag "

Eine verschlüsselte Zeichenkette kann aber beliebige Vorkommen von ' und " enthalten.

Gruß Musashi

**AspirinJunkie**

Man könnte auch den resultierenden verschlüsselten String per Base32 (oder auch Base64) kodieren. Dann enthält er nur noch Zeichen die so gut wie nirgends mehr Probleme machen sollten.
Heißt auch, dass er vor dem entschlüsseln natürlich wieder aus Base32 zurück gewandelt wird.

Ansonsten verstehe ich das Anführungszeichenproblem nicht ganz. Es tritt doch nur auf wenn der Nutzer die Nachricht direkt in den Programmcode tippt.
Ich gehe aber eher mal davon aus, dass der Nutzer entweder eine Datei einliest oder eventuell die Nachricht über eine Eingabemaske einträgt. Dann macht das Anführungszeichen auch keine Probleme mehr.

mumpel

Zitat von Musashi

Vorab : Für die Daten den Variablennamen '$passwort' zu verwenden, ist keine glückliche Wahl.

Das ist nur im hier geposteten Testcode so. Im Arbeitscode sind natürlich andere Namen.

Zitat von Musashi

Daten vorher zu drehen etc. macht es nicht sicherer, sondern nur unübersichtlich (siehe den Rat von alpines).

Finde ich nicht. Ich habe jetzt aus drei Zeilen eine gemacht. Die Funktion habe ich natürlich auch entfernt.

AutoIt

#RequireAdmin
#Region
#AutoIt3Wrapper_Icon=bl-xl_1.ico
#AutoIt3Wrapper_Compression=4
#AutoIt3Wrapper_Res_Language=1031
#EndRegion
#Region
#EndRegion
#include <Excel.au3>
#include <Crypt.au3>
#include <MsgBoxConstants.au3>
#include <String.au3>


$pdde = "ßÌCnRÕ""
If Not IsAdmin() Then
   MsgBox($MB_SYSTEMMODAL, "AutoIt/SciTE", "Sie verfügen nicht über die erforderlichen Administratorecht." & @CRLF & @CRLF & _
                           "You do not have the required administration rights." & @CRLF & @CRLF & _
			   "Vous ne devez pas l'administrateur requis réel.")
Else
   Local $edde = StringReverse(_HexToString(BinaryToString(_Crypt_DecryptData($pdde, 'password',$CALG_RC4))))
   Local $oExcel = _Excel_Open()
   Local $oWorkbook = _Excel_BookOpen($oExcel, @ScriptDir & "\Test.xlsb", 0, True, $edde, $edde)
EndIf

Alles anzeigen

Zitat von Musashi

Lese die verschlüsselten Daten (test.txt) doch einfach mittels FileRead wieder ein.

Ist das nicht so als würde ich die Kennwörter gleich direkt dem Anwender geben? Ich müsste dann ja die "test.txt" mitgeben. Wenn ich wüsste wie und ob man die "Kennwortdatei" auch in eine dll kompilieren und wie ich den Inhalt später nutzen kann wäre es vielleicht besser.

Zitat von Musashi

(...) Eine verschlüsselte Zeichenkette kann aber beliebige Vorkommen von ' und " enthalten (...)

Eben.

**Musashi**

Hallo @mumpel !

Musashi schrieb : Für die Daten den Variablennamen '$passwort' zu verwenden, ist keine glückliche Wahl.

Zitat von mumpel

Das ist nur im hier geposteten Testcode so. Im Arbeitscode sind natürlich andere Namen.

und : Die Crypt/Decrypt-Funktion ist völlig ausreichend. Daten vorher zu drehen etc. macht es nicht sicherer, sondern nur unübersichtlich (siehe den Rat von @alpines ).

Zitat von mumpel

Finde ich nicht. Ich habe jetzt aus drei Zeilen eine gemacht. Die Funktion habe ich natürlich auch entfernt.

Ich kann leider nur den Code beurteilen, den Du bisher zu der Frage gepostet hast.

Zitat von AspirinJunkie

Ansonsten verstehe ich das Anführungszeichenproblem nicht ganz. Es tritt doch nur auf wenn der Nutzer die Nachricht direkt in den Programmcode tippt.

Nun, genau das macht er aber, auch im aktuellen Code!
siehe : $pdde = "ßÌCnRÕ"" ==> wird in _Crypt_DecryptData($pdde, ...) direkt verwendet.

Ich habe auf Basis Deines älteren Testscriptes mal eine q&d Variante erstellt :

AutoIt

#include <Crypt.au3>
#include <MsgBoxConstants.au3>
#include <String.au3>


Local $hFileOpen
Local $sData     = "Testdaten" ; Daten, die verschlüsselt werden sollen
Local $sPassword = "Password"    ; Passwort


;Verschlüsseln
Local $sEncrypted = _Crypt_EncryptData($sData, $sPassword, $CALG_RC4)
MsgBox($MB_SYSTEMMODAL, "Encrypted", $sData & " verschlüsselt= " & $sEncrypted)
$hFileOpen = FileOpen(@ScriptDir & "\test.txt", BitOR( $FO_OVERWRITE,$FO_BINARY))
FileWrite($hFileOpen, $sEncrypted)
FileClose($hFileOpen)


; Entschlüsseln
$hFileOpen = FileOpen(@ScriptDir & "\test.txt", $FO_READ + $FO_BINARY)
Local $sFileRead = FileRead($hFileOpen)
FileClose($hFileOpen)
Local $sDecrypted = _Crypt_DecryptData($sFileRead, $sPassword, $CALG_RC4)
MsgBox($MB_SYSTEMMODAL, "Decrypted", $sData & " entschlüsselt= " & BinaryToString($sDecrypted))

Alles anzeigen

Die Messagebox bei 'Verschlüsseln' zeigt dir den Binärstring (Du kannst ihn auch in die Console schreiben).
Beim Entschlüsseln, kannst Du statt Einlesen aus Datei, den Anzeigewert der Box auch direkt besetzten, also :
$sFileRead = Binary("0x.....") -> vor _Crypt_Decrypt einbauen, statt FileOpen/Close

Gruß Musashi

mumpel

Zitat von Musashi

(...) Ich habe auf Basis Deines älteren Testscriptes mal eine q&d Variante erstellt (...)

Perfekt! Danke! Nun funktioniert es auch mit AES256.

**Musashi**

Hallo @mumpel !
Nachtrag zu Beitrag 13 :

Zitat von mumpel

Ist das nicht so als würde ich die Kennwörter gleich direkt dem Anwender geben? Ich müsste dann ja die "test.txt" mitgeben.

Ich glaube, Du bringst hier Kennwort und verschlüsselte Daten etwas durcheinander. Die Datei 'test.txt' enthält die verschlüsselten Daten, nützt dem Anwender also wenig. Das Passwort setzt Du im Quellcode selbst. Grundsätzlich sollte man erwähnen, dass AutoIt-Quellcode diesbzgl. nicht gerade sicher ist.

Gruß Musashi

mumpel

Zitat von Musashi

(...) Das Passwort setzt Du im Quellcode selbst (...)

Und den Quellcode bzw. Zeichenfolgen kann man (angeblich) auslesen. Z. B. mit "Strings v2.53" von Sysinternals soll das funktionieren. Gelingt das einem Anwender, und weiss der wie ich es verschlüsselt habe, könnte er an das Passwort kommen.

**alpines**

Zitat von mumpel

Und den Quellcode bzw. Zeichenfolgen kann man (angeblich) auslesen. Z. B. mit "Strings v2.53" von Sysinternals soll das funktionieren. Gelingt das einem Anwender, und weiss der wie ich es verschlüsselt habe, könnte er an das Passwort kommen.

Wenn jemand deinen Code knacken möchte, dann wird er auch das immer schaffen.
Die Frage ist doch, was ist so wichtig, dass du es unbedingt verstecken und sichern möchtest in einem AutoIt Script?

Deinen Key musst du ja nicht als Plaintext im Code speichern, sondern kannst ihn für die Funkion aus mehreren Strings zusammensetzen lassen und ggf. deobfuscatende Funktionen nutzen.

**AspirinJunkie**

Deswegen gehört ein Passwort auch nicht in den Quellcode (auch bei anderen Programmiersprachen).

Sag mal eher was du wirklich machen willst. Also nicht bloß das du was verschlüsseln/entschlüsseln willst sondern was wirklich ganz am Ende damit rauskommen soll.
Was möchtest du warum verschlüsseln und warum muss das Passwort hierbei fest in den Quellcode getackert werden?

mumpel

Verschlüsseln möchte ich damit Anwender nicht so einfach an das Kennwort der Exceldatei kommen. Mit Kennwortschutz ist es nämlich nicht mehr möglich die Excel-Datei mit externen Programmen zu öffnen. Damit möchte ich verhindern dass es zu leicht ist das VBA-Projekt aufzubrechen. Ihr kennt ja sicher die Möglichkeit wie man das VBA-Kennwort, zumindest bei Office 2000-2003-Dateien, mit Hex-Editor "entfernt". Der Schutz verhindert am Ende dass jemand ins VBA-Projekt geht und damit den erforderlichen Schutz (Adminrechte) umgeht. Das hat aber nichts mit mangelnden Vertrauen zu tun, sondern mit dem Schutz von Firmennetzwerken (die Registrierungsdatenbank ist nichts für Spielfreudige).

Zitat von alpines

(...) Die Frage ist doch, was ist so wichtig, dass du es unbedingt verstecken und sichern möchtest in einem AutoIt Script? (...)

Nur Administratoren sollen das Tool nutzen können. Der Quellcode selber ist unwichtig. Den Quellcode selber liefere ich mit, bis auf den Teil der die "Prüfnummer" berechnet (die "Prüfnummer" gibt zusätzliche Rechte frei.). Der Quellcode als HTML, mit Syntax-Highlighting (der VBA-Code wird mit meinem Tool "VBAHTML" in HTML gespeichert).

Extern programmieren kann ich ja nicht.

**AspirinJunkie**

Dein Problem zusammengefasst: Nur Admins sollen eine bestimmte Excel-Datei öffnen dürfen?

Nun falls dem so ist dann ist die Variante mit dem Extra-AutoIt-Skript aus Sicherheitsaspekten her ziemlich schwach.
Solange das Passwort im Skript steht kann es ausgelesen werden - Punkt.
Man kann noch viel machen um es jemanden der es angreift schwerer zu machen aber per se ist keine Sicherheit gegen ein Auslesen gegeben.

Was könnte man stattdessen machen (bin darin kein Experte)?

Excel selbst kann den Zugriff auf bestimmte Nutzer einschränken (z.B. über Active-Directory-Server)
Ein integriertes Makro welches den Admin-Status checkt und ansonsten den Zugriff verweigert bzw. die Mappe freischaltet (keine Ahnung was passiert wenn Makros ausgeschaltet sind)
Allen denen du Zugriff gewähren möchtest das Passwort mitteilen.

Aber mit einem extra Skript wird es nicht phänomenal sicherer.