Passwörter

**Andy**

Hi,
in letzter Zeit wurden einige Anfragen gestellt bzgl. der Speicherung von Passwörtern bei kompilierten Scripten. Der Sinn sei mal dahingestellt...

Am einfachsten ist es, die Passwörter direkt in der EXE-Datei zu speichern aber wo dort?
Man könnte auf die Idee kommen, ein Passwort im PE-Header der EXE zu speichern, aber einige Virenscanner überprüfen diesen Bereich und warnen mit Vorhandensein von bspw. "Dropper.Gen" (jaja, im DOS-Stub wurde "früher" auch gerne mal rumgeschrieben und sog. Dropper eingefügt, was aber absolut garnichts mit einem Virus o.ä. zu tun hat)
Dann könnte man weitere ungenutzte Bereiche innerhalb der EXE-Datei beschreiben, aber dazu müsste man einigen nicht unerheblichen Aufwand betreiben (in Assembler ist alles sooo viel einfacher 8 ) !
Am allereinfachsten ist es, man hängt das Passwort einfach an die EXE an

Spoiler anzeigen

[autoit]

;Password an EXE-Datei anhängen

[/autoit] [autoit][/autoit] [autoit]

$password = InputBox("Password in Exe speichern", "Bitte Password eingeben", "")
If StringLen($password) = 0 Then Exit (MsgBox(0, "Password in Exe speichern", "Programm abgebrochen! Bitte gültiges Password eingeben"))

[/autoit] [autoit][/autoit] [autoit]

$exefile = FileOpenDialog("Password in Exe speichern", @ScriptDir, "(*.EXE)")
If $exefile = "" Then Exit (MsgBox(0, "Password in Exe speichern", "Programm abgebrochen! Bitte EXE-Datei auswählen"))

[/autoit] [autoit][/autoit] [autoit]

$file = FileOpen($exefile, 17) ;Datei binär öffnen
FileSetPos($file, 0, 2) ;Position auf letztes byte
FileWrite($file, $password) ;schreiben
FileFlush($file) ;sicher ist sicher
FileClose($file) ;schliessen

[/autoit]

Es macht Sinn, das Passwort zu "hashen", erstens ist es dann unleserlich, zweitens auch halbwegs "sicher", da es nirgendwo im Klartext steht!

Wie fragt man das Passwort in der gestarteten EXE-Datei ab?

Spoiler anzeigen

[autoit]

;zu schützende Scriptdatei
;in eine EXE kompilieren
$password = InputBox("Password", "Bitte Password eingeben:", "")

[/autoit] [autoit][/autoit] [autoit]

$file = FileOpen(@ScriptFullPath, 16) ;EXE-datei öffnen
FileSetPos($file, -StringLen($password), 2) ;Position auf Ende der Datei
$pw = BinaryToString(FileRead($file, StringLen($password))) ;Password aus EXE lesen
fileclose($file)

[/autoit] [autoit][/autoit] [autoit]

MsgBox(0, "Password", "Das Password " & $password & " ist " & stringleft("richtig!",($pw = $password)*8)&stringleft("falsch!",($pw <> $password)*7))

[/autoit] [autoit][/autoit] [autoit][/autoit]

Also zuerst das zu schützende Script zu einer EXE kompilieren.
Dann das 1. Script aufrufen und damit dann das einzugebende Passwort an die EXE anhängen.
EXE aufrufen und Passwort eingeben.

Wer mag, kann das Passwort auch in der *.AU3-Datei einfügen
Einfach als Kommentar in die letzte Scriptzeile schreiben, dann funktioniert auch die Au3-Version

James · AutoIt Version (Prod): 3.3.14.2

Aber wenn man das Passwort sowieso hasht, muss es dann noch extra gesichert (in diesem Fall "versteckt") werden? Mit dem Hash könnte ein potentieller Angreifer doch sowieso nichts anfangen, oder? Man könnte statt MD5 ja auch SHA-256d benutzen.

**Andy**

Hi,
das würde zutreffen, wenn bspw. nur ein Passwort verwendet wird. Dann kann man es natürlich "hartkodiert" direkt im Script verwenden. Was aber alles nichts nützt, denn wenn dekompiliert wird ist es völlig schnurz, ob das Passwort im Klartext oder gehashed oder sonstwie verschlüsselt im Script steht.
Der Hash oder die Verschlüsselung machen nur dann Sinn, wenn sie "außerhalb" des Scriptes stehen, bspw. in der Registry oder in einer Datei (*.ini)
Verschlüsselte Passwörter in externe Dateien (Registry oder *.ini) schreiben ist imho suboptimal. Ist die Passwortdatei beschädigt oder nicht im Zugriff, gibt es Stress!
Die EXE ist immer im Zugriff, man braucht nur eine Datei und kann beliebig viele und große Passwörter anhängen.

James · AutoIt Version (Prod): 3.3.14.2

Achso, ok, jetzt habe ich verstanden, wie du das meinst. Man könnte so also das Programm mehreren Leuten mit unterschiedlichen Passwörtern geben, ohne es jedes mal neu "kompilieren" zu müssen. Da ist diese Variante natürlich besser.
Und wie du schon angedeutet hast: Wenn man sein Programm wirklich sichern will muss man eben auf eine richtige Programmiersprache umsteigen (z.B. Assembly).

MfG James

**Andy**

Zitat

Wenn man sein Programm wirklich sichern will muss man eben auf eine richtige Programmiersprache umsteigen (z.B. Assembly).

Sobald man an die ausführbare Datei herankommt ist es völlig unerheblich mit welchen Mitteln gesichert oder verschlüsselt wurde!
Dann ist es nur eine Frage des Aufwandes und der Hartnäckigkeit, ein Programm zu knacken.

James · AutoIt Version (Prod): 3.3.14.2

Zitat von Andy

Dann ist es nur eine Frage des Aufwandes und der Hartnäckigkeit, ein Programm zu knacken.

Und des Talents, und das werden 99% der Benutzer je nach den vorgenommenen Sicherheitsmaßnahmen nicht haben. Aber du hast natürlich Recht, 100% schützen kann man ein Programm nie. Reverse Engineering ist zum Glück noch ein Bereich, in dem nicht nur das Drücken eines Buttons in einem beliebigen Tool ausreicht (denke ich zumindest).

Commander21

Also gibt es theoretisch wie praktisch keinen Weg eine kompilierte Datei
so mit einem Passwort zu schützen, dass praktisch niemand mehr ohne das
Passwort die Datei öffnen kann?

Wie sieht es denn mit einem Schutz gegen das dekompilieren aus?
Lässt sich evtl. der gance Code i.wie so verschlüsseln, dass es zwar
die ausführbare EXE aber nicht mehr ein potenzieller "Hacker" lesen kann?
Oder lässt sich die EXE sonst i.wie vor dem Dekompilieren schützen?

PainTain

Zitat von Commander21

Also gibt es theoretisch wie praktisch keinen Weg eine kompilierte Datei
so mit einem Passwort zu schützen, dass praktisch niemand mehr ohne das
Passwort die Datei öffnen kann?

Wie sieht es denn mit einem Schutz gegen das dekompilieren aus?
Lässt sich evtl. der gance Code i.wie so verschlüsseln, dass es zwar
die ausführbare EXE aber nicht mehr ein potenzieller "Hacker" lesen kann?
Oder lässt sich die EXE sonst i.wie vor dem Dekompilieren schützen?

Für AutoIt gab/gibt es Versuche, das Dekompilieren zu verhindern.
Aber auch die haben ihre Schwachstellen.
AutoIt ist eben eine Skriptsprache.

Wenn du nicht willst, das dein Programm dekompiliert wird, musst du schon auf nativ kompilierte Sprachen wie C, C++, etc zurückgreifen (oder auch Perseus :D)
(Disassemblieren & Reverse Engineering sind wieder ein anderer Bereich )
Du wirst ein Programm niemals 100% schützen können, wie James bereits sagte.

James · AutoIt Version (Prod): 3.3.14.2

Du kannst das Programm durch Verschlüsseln und andere Methoden natürlich schwerer "hackbar" machen, aber es ist trotzdem möglich und wird auch immer möglich sein.
Zu 1) Du kannst die Datei verschlüsseln und ein Programm zum entschlüsseln mitliefern (oder sie sich selbst entschlüsseln lassen im Falle eines Programmes). Aber was bringt dir das? Wenn das Programm nur mit dem Passwort gestartet werden kann, wieso willst du es dann überhaupt veröffentlichen? Und wenn du es nicht veröffentlichst, dann brauchst du es auch nicht vor "Hackern" zu schützen.

(All diese Methoden sind mit AutoIt sowieso nur schwer bzw. gar nicht umsetzbar.)

Commander21

Naja, die Frage war jetzt nicht auf ein existierendes Script bezogen, sondern eher allgemein gehalten.

Hab jetzt mal was probiert.
Das ist dabei raus gekommen. (Bitte nicht verhauen wenn ihr den Code seht xD)

Spoiler anzeigen

[autoit]

#include <String.au3>

[/autoit] [autoit][/autoit] [autoit]

$passwort = InputBox ("Passwort", "Bitte Passwort eingeben", "", "*")
If @error = 0 Then
$cryptPW = InputBox ("Entschlüsseln", "Bitte Passwort zum entschlüsseln eingeben", "", "*")
If @error = 0 Then
$encrypt = _StringEncrypt (0, "40FE62E944538CD591CC3B3064D55DCD", $cryptPW)
If $encrypt = $passwort Then
MsgBox (64, "Erfolg", "Richtiges Passwort")
Else
MsgBox (16, "Fehler", "Falsches Passwort")
EndIf
Else
MsgBox (16, "Fehler", "Abgebrochen")
EndIf
Else
MsgBox (16, "Fehler", "Abgebrochen")
EndIf

[/autoit]

(Das Passwort dafür ist "passwort")

Es verschlüsselt das Passwort, so braucht man auch gleich zwei Passwörter um das Programm nutzen zu können.
(Ich bin sicherlich nicht der erste der da drauf kommt, ich weis)
Leider kann man ein fertiges Script immer noch dekompilieren, die Passwortabfrage raus schneiden und
neu kompilieren...

James · AutoIt Version (Prod): 3.3.14.2

Zitat von Commander21

Leider kann man ein fertiges Script immer noch dekompilieren, die Passwortabfrage raus schneiden und neu kompilieren...

Eben. Ich zitiere an dieser Stelle einfach mal Andy:

Zitat von Andy

Jeder Anfänger im Knacken von Programmen per Passwortabfrage lernt in der ersten Viertelstunde, wie man per Debugger einen Haltepunkt an der Passwortabfrage setzt, und diese dann einfach überspringt oder auskommentiert.
Für absolute Vollidioten ohne jegliche Ahnung gibt es Youtube-Tutorials, die diese Vorgehensweisen bis ins allerkleinste Vorführen...
Soviel zum "Sinn" einer Passwortabfrage in einem Programm!

Nun dazu, dass man das Passwort (wie auch immer) verschlüsselt im Zugriff des Programms ablegt. Ob das Passwort im Klartext in einer Textdatei, oder nach (wieauchimmer)-Verschlüsselung irgendwoanders abgespeichert ( was unterscheidet eine dll von einer anderen Datei? ) ist, spielt keine Rolle. Vorhanden ist vorhanden und somit "knackbar" oder zumindest verwendbar.

Commander21

Man könnte höchstens jede Funktion die das Programm beinhaltet einzeln abfragen, bzw. in die Abfrage zum start des Programms mit einbeziehen. Das heist, jedes mal wenn man einen Button klickt, wird das Passwort vom Start des Programms abgefragt (ohne dass es es neu eingeben muss.) Aber das wäre erstens ein rießen Aufwand und zweitens ebenfalls knackbar, wenn auch
mit sehr viel mehr aufwand.

Was mich aber mal interessieren würde, (ich kenn mich da überhaupt nicht aus)
Wie schaffen das manche Programme, ihre Passwörter von z.B. einer MySQL Datenbank zu holen, ohne
dass im Code i.welche Angaben zu den Zugangsdaten stehen?

Wenn ich ein Passwort z.B. von einem FTP Server hole muss ich ja auch erstmal im Code selbst die Zugangsdaten zu diesem
bereitstellen oder sie aus einer lokalen Datei auslesen.

PS: Zur not einfach das Programm aus z.B. einem mit einem Passwort geschütztem WinRar Archiv aus öffnen.
Sowas soll ja angeblich "unknackbar" sein...

name22

@commander Aber was hindert mich daran, das Archiv einmal zu entpacken und die Datei dann nach belieben ohne Passwortschutz weiter zu verteilen?

PainTain

Zitat von Commander21

Was mich aber mal interessieren würde, (ich kenn mich da überhaupt nicht aus)
Wie schaffen das manche Programme, ihre Passwörter von z.B. einer MySQL Datenbank zu holen, ohne
dass im Code i.welche Angaben zu den Zugangsdaten stehen?

Wenn ich ein Passwort z.B. von einem FTP Server hole muss ich ja auch erstmal im Code selbst die Zugangsdaten zu diesem
bereitstellen oder sie aus einer lokalen Datei auslesen.

Sowas kannst du mithilfe eines Webservers und einer API in PHP bewerkstelligen

**Andy**

Hi,

Zitat

Sowas soll ja angeblich "unknackbar" sein...

Da muss ich dich enttäuschen, "knackbar" ist mit genügend Aufwand ALLES!
Aber der Reihe nach...

Zitat

PS: Zur not einfach das Programm aus z.B. einem mit einem Passwort geschütztem WinRar Archiv aus öffnen.

Toll, dann hast du eine "sichere" Datei, aber im Speicher steht das Script (Programm) im Klartext

Zitat

Man könnte höchstens jede Funktion die das Programm beinhaltet einzeln abfragen, bzw. in die Abfrage zum start des Programms mit einbeziehen. Das heist, jedes mal wenn man einen Button klickt, wird das Passwort vom Start des Programms abgefragt (ohne dass es es neu eingeben muss.) Aber das wäre erstens ein rießen Aufwand und zweitens ebenfalls knackbar, wenn auch
mit sehr viel mehr aufwand.

Ansich eine gute Idee! Problem ist aber dabei die "Faulheit" des Programmierers, oft genutzte Programmschritte in Funktionen/Calls abzulegen, bspw. CheckPSWD(). Wenn der Einsprungpunkt für diese Funktion einmal gefunden ist, dann reicht idR. ein einfaches RET in der compilierten Datei, um diese Funktion niemals auszuführen...

Allerdings könnte man auch die 20 Zeilen für die Passwortabfrage 100 Mal im Script verteilen, ggf. sogar in verschiedenen Versionen bzw. Programmcodes.
Und wenn man schon dabei ist, könnte man sich ein Script schreiben, dass den Quellcode extrem "aufbläht" mit mehr oder weniger sinnfreien Funktionen. Wenn zwischen 5 aufeinanderfolgenden Scriptzeilen plötzlich 250 Zeilen Code stehen, dann wird es schwierig, da noch durchzublicken.
Obfuscator drüberlaufen lassen und man hat es dem Angreifer seitens Quellcode schonmal schön schwer gemacht... Ob die EXE nun 500KB oder 500MB groß ist, interessiert heute sowieso niemanden mehr

Zitat

Wie schaffen das manche Programme, ihre Passwörter von z.B. einer MySQL Datenbank zu holen, ohne
dass im Code i.welche Angaben zu den Zugangsdaten stehen?

naja, das ist einfach^^, die Passwortabfrage im Programm wird verschlüsselt oder gehashed, und dieser Schlüssel oder Hash wird an die Datenbank geschickt."Passt" der Schlüssel, kommt ein Freischaltcode von der Datenbankanwendung zurück.
Wieso nimmt man dann nicht einfach eine Datei? Weil die Datenbananwendung wiederum ein externes Programm ist, was incl. verschlüsselter Daten wieder "etwas mehr" Sicherheit bietet.

Zitat

Wenn ich ein Passwort z.B. von einem FTP Server hole muss ich ja auch erstmal im Code selbst die Zugangsdaten zu diesem
bereitstellen oder sie aus einer lokalen Datei auslesen.

Richtig, ein FTP-Server (bzw. das Protokoll) ist aber auch so ziemlich das "unsicherste" was es gibt
Bei meinem FTP-Server ist nach dem ersten Login-Fehlversuch EINE STUNDE Pause angesagt...
Bei meiner Bank konnte ich noch im letzten Jahr in dieser Zeit mit Millionen Passwörtern auf mein Konto-Login schiessen Soviel zum Thema "Sicherheit" implementieren!
Die Datenübertragung bei FTP erfolgt ebenfalls im Klartext.
Daher ist das Passwort (bei Onlineabfragen) recht einfach mit einem PHP-Script auf der Serverseite "abzufragen".
Und wenn man schon so weit ist, dann kann man ggf. Berechnungen oder Daten genauso vom PHP-Script rechnen lassen.
Die großen Systemhäuser machen sich diese Mühe schon garnicht mehr, sondern lassen ihre Programme direkt als Web-App laufen, incl. sämtlicher Userdaten in der "Cloud". Wer da noch ernshaft daran glaubt, dass diese "online" verschlüsselten Daten sicher sind , dem ist sowieso nicht mehr zu helfen
Alda, wir müssen deine Daten an sämtlicher Regierungsbehörden weitergeben, und auch an sonst jeden der zahlt, aber dein Passwort wird ehrlich nirgendwo gepeichert, isch schwör!!!

Commander21

Spoiler anzeigen

Zitat von Andy

Hi,

Da muss ich dich enttäuschen, "knackbar" ist mit genügend Aufwand ALLES!
Aber der Reihe nach...

Toll, dann hast du eine "sichere" Datei, aber im Speicher steht das Script (Programm) im Klartext

Ansich eine gute Idee! Problem ist aber dabei die "Faulheit" des Programmierers, oft genutzte Programmschritte in Funktionen/Calls abzulegen, bspw. CheckPSWD(). Wenn der Einsprungpunkt für diese Funktion einmal gefunden ist, dann reicht idR. ein einfaches RET in der compilierten Datei, um diese Funktion niemals auszuführen...

Allerdings könnte man auch die 20 Zeilen für die Passwortabfrage 100 Mal im Script verteilen, ggf. sogar in verschiedenen Versionen bzw. Programmcodes.
Und wenn man schon dabei ist, könnte man sich ein Script schreiben, dass den Quellcode extrem "aufbläht" mit mehr oder weniger sinnfreien Funktionen. Wenn zwischen 5 aufeinanderfolgenden Scriptzeilen plötzlich 250 Zeilen Code stehen, dann wird es schwierig, da noch durchzublicken.
Obfuscator drüberlaufen lassen und man hat es dem Angreifer seitens Quellcode schonmal schön schwer gemacht... Ob die EXE nun 500KB oder 500MB groß ist, interessiert heute sowieso niemanden mehr

naja, das ist einfach^^, die Passwortabfrage im Programm wird verschlüsselt oder gehashed, und dieser Schlüssel oder Hash wird an die Datenbank geschickt."Passt" der Schlüssel, kommt ein Freischaltcode von der Datenbankanwendung zurück.
Wieso nimmt man dann nicht einfach eine Datei? Weil die Datenbananwendung wiederum ein externes Programm ist, was incl. verschlüsselter Daten wieder "etwas mehr" Sicherheit bietet.

Richtig, ein FTP-Server (bzw. das Protokoll) ist aber auch so ziemlich das "unsicherste" was es gibt
Bei meinem FTP-Server ist nach dem ersten Login-Fehlversuch EINE STUNDE Pause angesagt...
Bei meiner Bank konnte ich noch im letzten Jahr in dieser Zeit mit Millionen Passwörtern auf mein Konto-Login schiessen Soviel zum Thema "Sicherheit" implementieren!
Die Datenübertragung bei FTP erfolgt ebenfalls im Klartext.
Daher ist das Passwort (bei Onlineabfragen) recht einfach mit einem PHP-Script auf der Serverseite "abzufragen".
Und wenn man schon so weit ist, dann kann man ggf. Berechnungen oder Daten genauso vom PHP-Script rechnen lassen.
Die großen Systemhäuser machen sich diese Mühe schon garnicht mehr, sondern lassen ihre Programme direkt als Web-App laufen, incl. sämtlicher Userdaten in der "Cloud". Wer da noch ernshaft daran glaubt, dass diese "online" verschlüsselten Daten sicher sind , dem ist sowieso nicht mehr zu helfen
Alda, wir müssen deine Daten an sämtlicher Regierungsbehörden weitergeben, und auch an sonst jeden der zahlt, aber dein Passwort wird ehrlich nirgendwo gepeichert, isch schwör!!!

Alles anzeigen

Danke für die super Auskunft
Jetzt versteh ich das ganze System schonmal etwas besser.