Programmcode soll für Anwender nicht lesbar sein

[aggitron]

Hallo,

bin nicht der große Programmierer, daher mag sich die Frage etwas komisch anhören.
Habe ein großes Problem mit einer Batch Datei. In dieser sind FTP Befehle hinterlegt.
Außerdem aber auch die entsprechenden Zugangsdaten (Benutzer, Passwort) in Klarschrift.
Wie kann ich diese für den Anwender unlesbar machen? Er darf auch nichts sehen sein wenn er über 'bearbeiten' im Kontextmenü der *.bat geht!
Ich würde die Datei mit meinen geringen Kenntnissen auch als VB Script oder in C# schreiben können, nur leider weiß ich auch nicht so recht wie das dort laufen müsste.

 

[maxpayne80]

Ein kleiner Workaround wäre ersteinmal der bat to exe konverter:

http://www.computerbild.de/download/Bat-To-Exe-Converter-2345613.html

Man kann sicherlich auch weiter rankommen an die Daten wenn man will, nur ist es ersteinmal nicht mehr per texteditor sichtbar

 

[aggitron]

Danke für die schnelle Antwort. Diese Möglichkeit habe ich schon in Betracht gezogen. Allerdings haben die meisten AV Programme damit wohl Probleme.

 

[maxpayne80]

Ja, das ist richtig, habe ich auch schon bemerkt ;(

 

[Spezi]

Hi,

wenn die bat-Datei wirklich eine FTP-Verbindung aufbaut dann kannst du diese Batch-Datei sichern wie du willst, denn mit einem Netzwerk-Sniffer-Programm kriegt man das Schnell raus, ohne überhaupt in das Skript rein gucken zu müssen.

Hier hilft wenn dann nur SFTP oder ähnliches.

 

[HaGGi.13]

Schreib es in VBS noch mal neu (ist nicht viel komplizierter als eine bat) und das kannst du dann verschlüsseln.

Hier ist dann eine HowTo wie du deine VBS dann verschlüsseln kannst.
VBS verschlüsseln

Das ist zwar recht leicht wieder zu knacken, aber der "normale" User kommt da nicht so schnell ran.
Außer er will umbedingt und kann mit google umgehen...


Selbst C# kann man leicht decompilen, dafür gibts ja .NET Reflector. Aber da kann man noch anders wieder arbeiten, mit einer Datei Bspw. welche dann die Logindaten enthält, allerdings würde ich die dann mit AES verschlüsseln.

 

[Rossibaer]

Bei C# kannst du die Klassen System.Net.FtpWebRequest und System.Net.FtpWebResponse verwenden um mit einem FTP Server zu kommunizieren, desweiteren hat FtpWebRequest eine Property "EnableSsl" die man auf True stellt und somit eine Verschlüsselung der Übertragung erreicht. Auch interessant ist die Eigenschaft FtpWebRequest.UsePassive, sodaß auch bei Firewalls keine Probleme entstehen sollten. Der Vorteil des ganzen wäre, dass du dich nicht mit einem Batch und dessen Problemen (Login-Daten, Verschlüsselung usw.) rumschlagen musst und direkt auf die .Net Framework Komponenten zugreifen kannst. Klar gibt es für .Net Assemblies den .Net Reflector womit sich der Code aus der Exe Datei wieder extrahieren lässt. Aber für diesen Zweck kannst du auch noch einen Obfuscator (viele gibts als Freeware) drüber laufen lassen, sodaß es schwerer wird, den Code mit Hilfe von Disassemblern wie .Net Reflector zu lesen. Die Login-Daten kannst du in einer Textdatei verschlüsselt (z.B. System.Security.Cryptography.RijndaelManaged) ablegen, wobei auch hier wieder der Schlüssel in irgendeiner Form für das Programm verfügbar sein muss. Wenn du ganz auf Nummer sicher gehen willst, dann könntest du auch noch den Code für die Übertragung/Verschlüsselung emittieren und dynamisch aufrufen, statt fest in das Programm zu kompilieren. Aber das würde wahrscheinlich für den Anfang erstmal zu weit gehen. Was du jedoch sehen kannst ist die Tatsache das du mit einer Programmiersprache weit aus mehr Möglichkeiten hast, als mit einer Batch-Datei.

Wahrscheinlich willst du bei einer Batch-Datei die ftp.exe (von Windows) ansteuern. Diese ist jedoch in Bezug auf Kommunikation mit Servern hinter Firewalls fast unbrauchbar. Ebenso gibts Probleme bei NAT Routern, da in der ftp.exe, wie ich sie kenne, kein Passiv-Modus unterstützt wird.

Also dann, viel Erfolg bei deinem Vorhaben...
Rossibaer

 

[asdfman]

Was redet ihr denn alles für einen Blödsinn?

Egal was OP macht, man kann die Zugangsdaten aus den übertragenen Paketen auslesen.
Das grundlegende Konzept bedarf Änderung. An den Symptomen herumzufummeln nützt
überhaupt nichts.

Und die grandiose Idee, die Zugangsdaten MIT AES VERSCHLÜSSEN !!EINSELF zeigt ja mal
nichts weiter, als dass der gute Herr gar keine Ahnung hat, was er da redet. Sinn der Sache
wäre nämlich überhaupt nicht vorhanden.

Übel. Echt.

€: Bitte keine Verwarnung oder so. Mit den Schmerzen vom Kopf auf den Tisch hauen nach
Lektüre des Threads bin ich schon genug gestraft

 

[Backslash]

Trotz der etwas "starken" Ausdrucksweise muss ich asdfman inhaltlich vollkommen rechtgeben
Unfug. Leider nur purer Unfug.

Entweder die Daten sind im Programm hinterlegt oder nicht. Wenn ja wird es immer möglich sein sie auszulesen.
Hinzu kommt die schon erwähnte Unsicherheit von FTP selbst, das normalerweise keine Verschlüsselung nutzt.

Mögliche Lösungen:

• Den User die Zugangsdaten selbst eingeben lassen. Verhindert aber nicht das Abfangen der gesendeten Daten, deshalb:
• Zusätzlich ein anderes Protokoll verwenden (wie z.B. das auch schon erwähnte SFTP oder (weiter unten erwähnt) FTPS)

 

[HaGGi.13]

Ja, na klar ist es nicht schön bei FTP...
Es geht aber darum, wenn sich die Daten aus irgendeinen Grund mal ändern sollten, muss man so, wenn sie im Code hinterlegt sind, immer wieder an das Projekt und eine neue *.exe compilen. (Ich beziehe mich nur auf die Lösung mit C#.)
Bei dem Vorschlag die Logindaten mit AES verschlüsselt in einer Datei (das kann eine *.ini oder vllt. etwas overhead aber auch möglich eine *.xml sein) abzulegen hat nur die Bewandtnis die Daten ohne große Probleme ändern zu können. Natürlich bedarf das dann ein weiteres kleines Tool mit welchem man dann diese Datei erstellen und editieren kann.

Das war jedenfalls meine Intention an der Sache.

 

[asdfman]

Man könnte sie aber genausogut im Klartext speichern, weil die Daten ja unverschlüsselt über die Leitung
gehen. Deshalb ist die Idee, die Logindaten zu verschlüsseln, völlig nutzlos. Außerdem muss ein Schlüssel
vorhanden sein, den man im Zweifelsfall aus dem Binary auslesen kann, um die Daten damit zu entschlüsseln.

Wie bereits gesagt, OP benötigt ein sinnvolles Konzept und keine nutzlosen Vorschläge, die ihn am Ende des
Tages doch keinen cm weiter bringen.

 

[CoolHandLuke]

Was soll das Programm denn überhaupt machen? Nur Daten von einem FTP-Server runterladen? Hier vielleicht einen gemeinsamen Nutzer anlegen, wo auch ruhig die Zugangsdaten "erschnüffelt" werden können, der nur über Leserechte auf dem Server verfügt. Oder einen Webserver verwenden und via wget Daten runterladen. Gibt hier unzählige Alternativen. Kritische Zugangsdaten aber in Binärdateien oder xml-Dokumenten zu speichern halte ich aber, wie schon zuvor von anderen bereits angemerkt, auch für Unsinn.

 

[HaGGi.13]

Da gebe ich dir ja recht, aber da kommt es nun wirklich drauf an wo er es einsetzen möchte. Wenn es in einer Firma Anwendung findet, wo nicht gerade Leute sitzen die alle WireShark o.Ä. installiert haben und den ganzen lieben langen Tag rum sniffen oder nichts weiter zu tun haben, als Dateien nach diversen Inhalten zu durchsuchen, sollte es gehen.
Für einen anderen Einsatz, wo wirklich Sicherheit benötigt wird, sprich auch Leute vorhanden sind die an diese Daten ran kommen können und wollen, ob es nun die Datei ist oder die Logindaten, ist es Quark.

Aber gut, brauch man hier jetzt auch nicht weiter aus bauen...

 

[aggitron]

Ich ziehe mir mal das Wichtigste heraus:

Wenn ich auf Nummer sicher gehen will, sollte ich also C# und SFTP nutzen. Und variable Daten (damit ist nicht der Zugang gemeint) schreib ich in eine *.ini Datei.

 

[Rossibaer]

Jetzt muss ich auch mal etwas abstinken!

@asdfman: Hast du momentan Schlafentzug oder was?! Einmal kurz die RFC studiert und schon bist du der Guru? Also mal von vorn, gem. RFC 959 bietet FTP keine Verschlüsselung für den Datenkanal (Port 20) und den Controlkanal (Port 21). Soweit geh ich da noch mit. Aber und jetzt kommt der Knackpunkt - wenn wir hier schon beim Griff ins Klo sind - gem. RFC 4217 gibt es die Möglichkeit beide Kanäle mittels SSL für Außenstehende zu verschlüsseln. Das ganze nennt sich dann mal eben FTP over SSL (oder kurz FTPS). Das .Net Framework bietet ab Version 2.0 eben genau diese Variante an, in dem man für das Request Objekt die Eigenschaft UseSsl aktiviert. Danach kannst du soviel sniffen wie du willst, oder alternativ weiter mit deinem Schädel auf der Tischplatte rumhämmern. Also schraub deinen Elan zurück!

Die nächste Sache wäre, das man jetzt das hartcodierte Password irgendwie vor den Augen 3. schützt und das ist das eigentliche Problem: Man kann es sicherlich verschlüsselt ablegen, wo auch hier bereits genug Varianten angeboten wurden, aber irgendwie schiesst man sich wieder ins eigene Knie. Denn wo ist das Passwort das gebraucht wird um das Passwort für die Übertragung zu entschlüsseln? Das kann man beliebig tief verschachteln, nur wirklichen Schutz bietet es nicht. Also wäre es doch bestimmt sinnvoll ein Passwort für jeden Benutzer einzustellen und dieses dann beim Senden oder Empfangen vorher abzufragen. Denn alles was auf der Platte oder sonstwo im PC gespeichert wird, ist nicht sicher. Immer diese Paranoia...

 

[aggitron]

Der Nutzer bekommt vom senden nix mit! Das will er auch gar nicht.

 

[Backslash]

Aha, wie soll man das jetzt verstehen?

 

[aggitron]

Der Nutzer erstellt in einer Prozesskette diverse Dateien die automatisch an ein, ihm fremdes, System übertragen werden. Dort kann er diese Dateien dann verarbeiten.
Wie die Dateien dort hinkommen wissen die meisten gar net. Das interessiert sie auch nicht. Hauptsache sie können damit arbeiten.

 

[asdfman]

Na, wenn sie es weder wissen, noch es sie interessiert, warum den Vorgang verstecken?

Rossibaer: Schlafe in der letzten Zeit wunderbar. Danke der Nachfrage. Du sagst selbst, ein fest eigecodetes
Passwort lässt sich nicht effektiv verstecken. Sehe nicht, wie du mir da widersprichst, dass das Konzept von
OP schwerwiegende Mängel hat. Auch stimmst du mir ja zu, dass standard-FTP keine Verschlüsselung unter-
stützt.
Habe jetzt gesehen, dass du OP direkt vor mir SSL ans Herz gelegt hast, die Anderen aber alle nicht. Das hilft
aber, wie du selbst gesagt hast, dann doch nicht weiter, so lange die Anmeldedaten fest hinterlegt sind.

 

[aggitron]

Es ist einfach ein unschönes Leck.
Was würdet ihr den nun als angemessene Maßnahme empfehlen?