Im Kompilat klar lesbare Passwörter...
Im Kompilat klar lesbare Passwörter...
Also, man muss ja manchmal etwas vor dem Nutzer verbergen. Etwa ein FTP-Passwort, wenn das Programm sich nur im Hintergrund beim FTP-Server melden soll, etwa um eine Anwesenheitsmeldung zu hinterlassen.
Mir ist klar, dass ich sowas besser über ein PHP-Skript machen sollte, aber die Frage geht in eine andere Richtung:
WARUM schreiben alle Compiler, die ich kenne, Strings in Reinschrift in das Executable (kann leider nur über Windows sprechen)?
Könnte man die nicht wenigstens byteverschieben oder irgendwie verschlüsseln, damit nicht jeder, der das Notepad öffnen kann, alles mitlesen darf? Das kann man händisch machen, ist klar, aber warum gibt es keinen impliziteren Weg, Strings im Executable nicht lesbar zu hinterlassen? Wenn ich da mein FTP-Passwort auch nur als Zeichenkette an die Funktion OpenFTP () übergebe kann jeder kleine Junge auf meinen FTP-Server zugreifen. Das ist doch fahrlässig.
Warum ist das so? Ist eine Auto-Verschlüsselung/-Konvertierung von Strings so zeitfressend, dass man das bei den Compilerbauern als nicht serienreif einstuft?
Mir ist klar, dass ich sowas besser über ein PHP-Skript machen sollte, aber die Frage geht in eine andere Richtung:
WARUM schreiben alle Compiler, die ich kenne, Strings in Reinschrift in das Executable (kann leider nur über Windows sprechen)?
Könnte man die nicht wenigstens byteverschieben oder irgendwie verschlüsseln, damit nicht jeder, der das Notepad öffnen kann, alles mitlesen darf? Das kann man händisch machen, ist klar, aber warum gibt es keinen impliziteren Weg, Strings im Executable nicht lesbar zu hinterlassen? Wenn ich da mein FTP-Passwort auch nur als Zeichenkette an die Funktion OpenFTP () übergebe kann jeder kleine Junge auf meinen FTP-Server zugreifen. Das ist doch fahrlässig.
Warum ist das so? Ist eine Auto-Verschlüsselung/-Konvertierung von Strings so zeitfressend, dass man das bei den Compilerbauern als nicht serienreif einstuft?
Re: Im Kompilat klar lesbare Passwörter...
Ob das ein guter Weg wäre?
Kompiliert als ASCII-Executable:


Code: Alles auswählen
Procedure$ ConvertString (String$, Key. c)
Protected offset
Protected len = Len (String$)
For offset = 0 To len
PokeC (@String$ + offset, PeekC (@String$ + offset) - Key)
Next
ProcedureReturn PeekS (@String$, len)
EndProcedure
Procedure$ ReconvertString (Convert$, Key. c)
Protected offset
Protected len = Len (Convert$)
For offset = 0 To len
PokeC (@Convert$ + offset, PeekC (@Convert$ + offset) + Key)
Next
ProcedureReturn PeekS (@Convert$, len)
EndProcedure
Debug ReconvertString ("81", 18)

Re: Im Kompilat klar lesbare Passwörter...
Warum sollten die Compiler die Strings irgendwie verschlüsseln? Das ist doch unsinnig. Die Exe muss doch mit den Strings arbeiten.
Und ganz ehrlich: Das mit FTP ist eine blöde Idee. Du kannst zwar das Passwort verschlüsselt in die Exe einbauen *ABER* du musst den Schlüssel zum entschlüsseln *auch* in der Exe speichern.
Sollte irgendwer mitbekommen, das dein Programm eine FTP-Verbindung zum schreiben öffnest und ein bischen Ahnung von der Sache hat, dann zerlegt er dir deinen FTP-Server. Das ist nur eine Frage der Zeit.
Abgesehen davon musst du verhindern, das zwei Programme zeitgleich auf den FTP-Server zugreifen, sonst wird dein Zähler zerstört.
Es gibt eine einfache Regel: Alles was man den User in die Hand drückt (dazu gehört die Exe) muss man als unsicher, manipulierbar und auslesbar ansehen. Passwörter in der Exe zu speichern ist schlicht zu gefährlich.
Kann PureBasic eigentlich Sftp? Wenn nein - würde es überhaupt etwas bringen das Passwort zu verschlüsseln wenn es für FTP unverschlüsselt gesendet wird?
Und ganz ehrlich: Das mit FTP ist eine blöde Idee. Du kannst zwar das Passwort verschlüsselt in die Exe einbauen *ABER* du musst den Schlüssel zum entschlüsseln *auch* in der Exe speichern.
Sollte irgendwer mitbekommen, das dein Programm eine FTP-Verbindung zum schreiben öffnest und ein bischen Ahnung von der Sache hat, dann zerlegt er dir deinen FTP-Server. Das ist nur eine Frage der Zeit.
Abgesehen davon musst du verhindern, das zwei Programme zeitgleich auf den FTP-Server zugreifen, sonst wird dein Zähler zerstört.
Es gibt eine einfache Regel: Alles was man den User in die Hand drückt (dazu gehört die Exe) muss man als unsicher, manipulierbar und auslesbar ansehen. Passwörter in der Exe zu speichern ist schlicht zu gefährlich.
Kann PureBasic eigentlich Sftp? Wenn nein - würde es überhaupt etwas bringen das Passwort zu verschlüsseln wenn es für FTP unverschlüsselt gesendet wird?
CodeArchiv Rebirth: Deutsches Forum Github Hilfe ist immer gern gesehen!
- ts-soft
- Beiträge: 22292
- Registriert: 08.09.2004 00:57
- Computerausstattung: Mainboard: MSI 970A-G43
CPU: AMD FX-6300 Six-Core Processor
GraKa: GeForce GTX 750 Ti, 2 GB
Memory: 16 GB DDR3-1600 - Dual Channel - Wohnort: Berlin
Re: Im Kompilat klar lesbare Passwörter...
Soweit ich weiß, kann PB weder SFTP noch FTPS. Verschlüsselung des Passwortes bringt also rein gar nichts, man kannGPI hat geschrieben:Kann PureBasic eigentlich Sftp? Wenn nein - würde es überhaupt etwas bringen das Passwort zu verschlüsseln wenn es für FTP unverschlüsselt gesendet wird?
es spätestens bei der Übergabe als Klartext abgreifen. Diejenigen DAUs, die es so nicht in Erfahrung bringen, können
auch keine Strings aus der Exe lesen
Gruß
Thomas
PureBasic 5.73 LTS | SpiderBasic 2.30 | Windows 10 Pro (x64) | Linux Mint 20.1 (x64)
Nutella hat nur sehr wenig Vitamine. Deswegen muss man davon relativ viel essen.

Nutella hat nur sehr wenig Vitamine. Deswegen muss man davon relativ viel essen.

Re: Im Kompilat klar lesbare Passwörter...
Eine Möglichkeit ist es verschlüsselte String per Include einzubinden und zur Laufzeit entschlüsseln.
Code: Alles auswählen
DataSection
StartPass:
IncludeBinary "Data\passwort.sec"
EndPass:
EndDataSection
Alles ist möglich, fragt sich nur wie...
Projekte ThreadToGUI / EventDesigner V3 / OOP-BaseClass-Modul
Downloads auf MyWebspace / OneDrive
Projekte ThreadToGUI / EventDesigner V3 / OOP-BaseClass-Modul
Downloads auf MyWebspace / OneDrive
Re: Im Kompilat klar lesbare Passwörter...
Nja, die kann sie ja vorher entschlüsseln ...GPI hat geschrieben:Warum sollten die Compiler die Strings irgendwie verschlüsseln? Das ist doch unsinnig. Die Exe muss doch mit den Strings arbeiten.
Der liegt dann aber wenigstens nicht leserlich in Reinschrift drin, sondern muss mühseelig aus dem Maschinencode geklaubt werden ...GPI hat geschrieben:Du kannst zwar das Passwort verschlüsselt in die Exe einbauen *ABER* du musst den Schlüssel zum entschlüsseln *auch* in der Exe speichern.
Es können doch mehrere Instanzen einen FTP-Account gleichzeitig nutzen, oder irre ich?Abgesehen davon musst du verhindern, das zwei Programme zeitgleich auf den FTP-Server zugreifen, sonst wird dein Zähler zerstört.
Wenn das nicht der richtige Weg ist, sich anzumelden, also lieber ein PHP-Skript, welches eine Datei auf dem Server schreibt?
Das ist doch genau das Selbe, nur umständlicher, als wenn ich die verschlüsselten Zeichen direkt in einem String speichere, oder?mk-soft hat geschrieben:Eine Möglichkeit ist es verschlüsselte String per Include einzubinden und zur Laufzeit entschlüsseln.
Re: Im Kompilat klar lesbare Passwörter...
Unnötige Resourcenverschwendunges_91 hat geschrieben:Nja, die kann sie ja vorher entschlüsseln ...
Genau das wird aber früher oder später passieren. Das ist nur eine Frage der Zeit.Der liegt dann aber wenigstens nicht leserlich in Reinschrift drin, sondern muss mühseelig aus dem Maschinencode geklaubt werden ...
Dürfte das nicht auch konfigurationssache sein? Ansonsten seh ich eher das Problem, das auf die Datei zeitgleich zugegriffen wird.Es können doch mehrere Instanzen einen FTP-Account gleichzeitig nutzen, oder irre ich?![]()
Auf jeden Fall.Wenn das nicht der richtige Weg ist, sich anzumelden, also lieber ein PHP-Skript, welches eine Datei auf dem Server schreibt?
Jup, weil du auch hier erst entschlüsseln musst und der Schlüssel in der Exe ist.mk-soft hat geschrieben:Das ist doch genau das Selbe, nur umständlicher, als wenn ich die verschlüsselten Zeichen direkt in einem String speichere, oder?
CodeArchiv Rebirth: Deutsches Forum Github Hilfe ist immer gern gesehen!
- TroaX
- Beiträge: 699
- Registriert: 08.03.2013 14:27
- Computerausstattung: PC: Ryzen 9 3950X, 96 GB RAM, RX6800XT, 2.5 TB SSD, 21:9 Display, Linux Mint | Lappi: Ryzen 7 5800H, 16 GB RAM, 1 TB SSD, Linux Mint
- Wohnort: NRW
- Kontaktdaten:
Re: Im Kompilat klar lesbare Passwörter...
Allgemein ist das Speichern eines Passwortes für ein kleines Tool nicht gerade leicht umzusetzen. Aber erstmal zur Frage: Wurde ja schon beantwortet. Unnötiger Ressourcenverbrauch bei genereller Verschlüssellung und das für nur einen oder zwei Variablenwerte, die es brauchen. Schlüssel muss auch gespeichert werden, damit das entschlüsseln klappt. Wenn der Compiler dies von Haus aus regelt, ist die Wahrscheinlichkeit groß, das der Schlüssel am Anfang der Datei liegen wird und somit für Editoren oder sogar Hex-Editoren leicht auszulesen ist.
Ich habe dafür auch keine plausible Lösung. Aber wenn ich auf die schnelle einen Ansatz dafür finden müsste, würde ich das Programm normal nach dem Passwort fragen lassen und dieses dann zur Laufzeit generisch verschlüsseln sowie in eine extra Datei schreiben. Der Schlüssel würde auch dynamisch erzeugt werden. Die Frage ist dann nur, wohin mit dem Schlüssel. Denn da wäre spätestens mein Problem. Aber ich würde es wirklich zur Laufzeit der fertigen Anwednung verschlüsseln und nicht in die Executable packen.
Ich habe dafür auch keine plausible Lösung. Aber wenn ich auf die schnelle einen Ansatz dafür finden müsste, würde ich das Programm normal nach dem Passwort fragen lassen und dieses dann zur Laufzeit generisch verschlüsseln sowie in eine extra Datei schreiben. Der Schlüssel würde auch dynamisch erzeugt werden. Die Frage ist dann nur, wohin mit dem Schlüssel. Denn da wäre spätestens mein Problem. Aber ich würde es wirklich zur Laufzeit der fertigen Anwednung verschlüsseln und nicht in die Executable packen.
PC: Ryzen 9 3950X | 96 GB RAM | RX6800XT | 2,5 TB NVMe | Linux Mint
Notebook: 16" 3:2 | Ryzen 7 5800H | 16 GB RAM | Radeon Vega | 1TB NVMe | Linux Mint
NAS: N150 Mini-PC | 16 GB RAM | Debian 13+CasaOS
Coding: Purebasic, Spiderbasic, GDevelop, PHP
Blog: https://techtroax.de
Repos: https://codeberg.org/TroaX
Notebook: 16" 3:2 | Ryzen 7 5800H | 16 GB RAM | Radeon Vega | 1TB NVMe | Linux Mint
NAS: N150 Mini-PC | 16 GB RAM | Debian 13+CasaOS
Coding: Purebasic, Spiderbasic, GDevelop, PHP
Blog: https://techtroax.de
Repos: https://codeberg.org/TroaX
Re: Im Kompilat klar lesbare Passwörter...
es_91: Wenn Du nur die Strings vor DAUs verstecken willst, dann reicht wohl auch das packen der EXE mit einem EXE-Packer (UPX oder so). Evtl. gibts sogar Packer die man nicht so einfach wieder entpacken kann?
"Never run a changing system!" | "Unterhalten sich zwei Alleinunterhalter... Paradox, oder?"
PB 6.12 x64, OS: Win 11 24H2 x64, Desktopscaling: 150%, CPU: I7 12700 H, RAM: 32 GB, GPU: Intel(R) Iris(R) Xe Graphics | NVIDIA GeForce RTX 3070
Useralter in 2025: 57 Jahre.
PB 6.12 x64, OS: Win 11 24H2 x64, Desktopscaling: 150%, CPU: I7 12700 H, RAM: 32 GB, GPU: Intel(R) Iris(R) Xe Graphics | NVIDIA GeForce RTX 3070
Useralter in 2025: 57 Jahre.
Re: Im Kompilat klar lesbare Passwörter...
Das Problem bzw. der Nachteil von solchen zusätzlichen Executable-Packers wie UPX ist, dass die Gefahr groß ist, dass ein Antivirenprogramm eine Virusmeldung anzeigt.
Und wenn der "DAU"-User die angezeigte Meldung sieht, denkt er, die Anwendung wäre verseucht oder nicht sicher und würde die EXE-Datei löschen (lassen).
Und wenn der "DAU"-User die angezeigte Meldung sieht, denkt er, die Anwendung wäre verseucht oder nicht sicher und würde die EXE-Datei löschen (lassen).

