Entwickler-Ecke
Sonstiges (Delphi) - Code schützen?
Dude566 - Fr 23.01.09 13:39
Titel: Code schützen?
Also, ich habe ein Programm in dem eine Verbindung mit einem php Script auf meinem Server aufgebaut wird.
Nun will ich aber nicht das diese Adresse mit einem HexEditor oder so einfach ausgelesen werden kann.
Gibt es da eine Möglichkeit das ganze irgendwie zu verschleiern oder verschlüsseln?
Gruß
Delete - Fr 23.01.09 14:10
Nein. Man kann nur den Aufwand erhöhen. Aber gänzlich schützen kann man den Code nicht. Wobei hier noch ein zweiter Angriffspunkt hinzukommt, die Übertragung über das Interent. So lange keine sicher Verbindung genutzt wird (https) kann man die Daten einfach mit einem Netzwerksniffer mitlesen.
Dude566 - Fr 23.01.09 14:13
Ok nicht komplett schützen war mir klar, aber zumindest erschweren und so ein Aufwand mit dem Sniffer würde sich bei meinem Programm nicht lohnen.
Es ist ein Spiel, und ich will nur nicht das einer das Hauptverzeichnis kennt.
Also was für Methoden zum Erschweren kann ich anwenden?
Delete - Fr 23.01.09 14:21
Wenn sich der Auewand mit dem Sniffer nicht lohnt, dann lohnt es sich auch nicht das Auslesen der Daten in der Exe zu erschweren. Denn der Aufwand einen Sniffer einzusetzen geht wohl gegen null.
jfheins - Fr 23.01.09 14:23
 Dude566 hat folgendes geschrieben  : |
| Ok nicht komplett schützen war mir klar, aber zumindest erschweren und so ein Aufwand mit dem Sniffer würde sich bei meinem Programm nicht lohnen. |
Welcher Aufwand? Wireshark runterladen, installieren, öffnen, Adresse lesen ;)
| Dude566 hat folgendes geschrieben : |
Es ist ein Spiel, und ich will nur nicht das einer das Hauptverzeichnis kennt.
Also was für Methoden zum Erschweren kann ich anwenden? |
Du könntest die Adresse erst zur Laufzeit zusammenfriemeln, zb: ROT13 verschlüsselt ablegen oder so. Dann kann man sie wenigstens nicht lesen, wenn man die Exe in Notepad öffnet ...
Flamefire - Fr 23.01.09 15:20
es ist sinnlos sowas zu versuchen
wie schon angesprochen, würde ich aacuh einfach mit nem sniffer ran gehn und fertig
es sind genau 3 Mausklicks (das öffnen schon mitgezählt) und ich hätte dein geheimes verzeichnis
wozu soll das geheim bleiben?
nutz einfach htaccess
BenBE - Fr 23.01.09 15:37
| Flamefire hat folgendes geschrieben : |
| nutz einfach htaccess |
:rofl: :rofl: :rofl: :rofl: :rofl: :rofl: :rofl: :rofl: :rofl: :rofl: ...
Der war gut!
Wenn ich das Verzeichnis mitlesen kann, kann ich auch die HTAccess-Authentifizierung mitlesen (von Digest-Auth mal abgesehen). Und selbst wenn ich das nicht kann: Dann hooke ich mich an die richtigen Stellen (z.B. die WS32-API und mach mal eben nen Scan des Prozess-Speichers. Dann nur noch kurz suchen und voilà!
Das ganze Problem bei Webanwendungen ist,
dass keiner der beteiligten Partner vertrauenswürdig ist: Nicht mal dein Server!!! ;-) Und selbst wenn wir einmal davon ausgehen, dass du deinen Server unter Kontrolle hast: Der Client bleibt die Sicherheitslücke, die du nicht schließen kannst, nur Stopfen so gut es geht.
Einen Trick, den Du machen kannst, ist wie bereits erwähnt SSL zu nutzen, darin aber ein weiteres proprietäres Protokoll zu sprechen, was sehr enge Timing-Anforderungen hat. Das lohnt sich aber in den seltensten Fällen und solange ich den Speicher immer noch auswerten kann und alle nötigen Infos sehe, ist das eh egal. Narses hatte da mal was recht nettes an Speicherverschlüsslung gebaut (ist aber leider closed; durfte das nur mal testen zu knacken): Der Aufwand das zu umgehen lag im Bereich weniger Minuten und das selbst nach dem 90% der Lücken gestopft wahren.
Es bringt also nichts: Mach lieber Plausibilitätsprüfungen rein ;-)
Dude566 - Fr 23.01.09 16:24
1.Also wie das mit Wireshark funktioniert ist mir auch klar. Trotzdem wüsste ich gerne eine relativ leichte Methode um den Code zu verschlüsseln.
2.Und wie knackt ihr das bitte schön? :roll:
Also mit einem HexEditor Werte auslesen, oder wie manipuliert ihr so eine Anwendung?
jfheins - Fr 23.01.09 17:11
Was meinst du mit knacken?
Man kann z.B. die Hosts-Datei bearbeiten sodass die Anfragen vom Programm auf localhost eintreffen.
Die Anfrage könnte man dann beliebig verändern und weiterreichen an das PHP Script.
Wenn man aber in Wireshark diorekt sowas hat wie h**p://server.com/savescore.php?score=1200&name=Superman kann man das auch direkt im Browser aufrufen ...
Dude566 - Fr 23.01.09 17:47
Zum Beispiel wenn man eine Passwortabfrage im Programm hat, dann ist das Passwort ja auch im Code vorhanden.
Und das kann doch dann mit einem HexEditor irgendwie ausgelesen werden.
jaenicke - Fr 23.01.09 18:29
| Dude566 hat folgendes geschrieben : |
| Zum Beispiel wenn man eine Passwortabfrage im Programm hat, dann ist das Passwort ja auch im Code vorhanden. |
Wenn die Passwortüberprüfung im Programm stattfindet, wozu brauchst du dort das Passwort im Klartext im Code? :shock:
Normalerweise benutzt man da wenn, dann einen Hash. Nur dass man bei einer simplen if-Abfrage nur einen Sprungbefehl in Assembler ändern muss, es also besonderes Hindernis ist. Aber das Passwort selbst im Klartext im Code? Wozu?
Und wenn du eine Datei o.ä. ver- bzw. entschlüsselst, dann wird da ja nicht der entsprechende Codeteil nur dann ausgeführt, wenn das Passwort stimmt (das wäre ja Schwachsinn), sondern dann wird das Passwort selbst zur Entschlüsselung gebraucht. Ohne das Passwort kann man dann die Entschlüsselung nicht durchführen.
| Dude566 hat folgendes geschrieben : |
| Also wie das mit Wireshark funktioniert ist mir auch klar. Trotzdem wüsste ich gerne eine relativ leichte Methode um den Code zu verschlüsseln. |
Wie wäre es denn mit der schon genannten Möglichkeit? ;-)
| jfheins hat folgendes geschrieben : |
| Du könntest die Adresse erst zur Laufzeit zusammenfriemeln, zb: ROT13 verschlüsselt ablegen oder so. Dann kann man sie wenigstens nicht lesen, wenn man die Exe in Notepad öffnet ... |
BenBE - Fr 23.01.09 18:36
Möglichkeiten zum knacken: Ich injekte Code in deinen Prozess, der jegliche API-Befehle und Call-Befehle aufzeichnet --> Calltree-Informationen
Ich kann dann ferner Argumente und Datenzeiger auslesen --> Data Flow
Ferner kann ich damit aber auch zu jedem beliebigen Zeitpunkt den Speicherinhalt deiner Anwendung beobachten --> Ich finde damit jegliche Änderungen und neu berechneten Informationen.
uall@ogc hatte mal ne Demo veröffentlicht, die sich in jedem Prozess in die WinSock-API geklämmt hat und in Echtzeit mitgeschnitten hat, wieviele Datenbytes empfangen und versendet wurden. Und das war nur ne minimale Demo (die durchaus auch die Daten an sich hätte mitlesen können).
| jaenicke hat folgendes geschrieben : |
| Dude566 hat folgendes geschrieben : | | Zum Beispiel wenn man eine Passwortabfrage im Programm hat, dann ist das Passwort ja auch im Code vorhanden. |
Wenn die Passwortüberprüfung im Programm stattfindet, wozu brauchst du dort das Passwort im Klartext im Code? :shock:
Normalerweise benutzt man da wenn, dann einen Hash. Nur dass man bei einer simplen if-Abfrage nur einen Sprungbefehl in Assembler ändern muss, es also besonderes Hindernis ist. Aber das Passwort selbst im Klartext im Code? Wozu? |
Wenn er sich an seinem eigenen SErver authentifizieren möchte ;-) Daher sag ich ja: Das lässt sich nicht schützen, weil wenn die Clientanwendung das SharedSecret kennt, kann ich auch als Angreifer von diesem erfahren und mich somit als Client ausgeben.
| jaenicke hat folgendes geschrieben : |
| Und wenn du eine Datei o.ä. ver- bzw. entschlüsselst, dann wird da ja nicht der entsprechende Codeteil nur dann ausgeführt, wenn das Passwort stimmt (das wäre ja Schwachsinn), sondern dann wird das Passwort selbst zur Entschlüsselung gebraucht. Ohne das Passwort kann man dann die Entschlüsselung nicht durchführen. |
Das ist dann eine andere Geschichte. Wenn das Passwort nicht stimmt, muss man die Entschlüsslungsversuche ins Leere laufen lassen, damit Bruteforcing soweit es geht erschwert wird. Einen Schutz an sich stellt das aber nicht dar.
| jaenicke hat folgendes geschrieben : |
| Dude566 hat folgendes geschrieben : | | Also wie das mit Wireshark funktioniert ist mir auch klar. Trotzdem wüsste ich gerne eine relativ leichte Methode um den Code zu verschlüsseln. |
Wie wäre es denn mit der schon genannten Möglichkeit? ;-) | jfheins hat folgendes geschrieben : | | Du könntest die Adresse erst zur Laufzeit zusammenfriemeln, zb: ROT13 verschlüsselt ablegen oder so. Dann kann man sie wenigstens nicht lesen, wenn man die Exe in Notepad öffnet ... |
|
Dafür kann man die aber lesen, wenn man sich die EXE im Speicher, bzw. deren Speicherabbild und die zugehörigen Daten anschaut (was ich in einem solchen Fall als Angreifer sofort tun würde ;-) Also wenn mich Wireshark nicht weitergebracht hat ;-)
Flamefire - Fr 23.01.09 18:43
@benbe: das mit htaccess ist trotzdem sinnvoll...je nachdem wofür
warum, soll man das hauptverzeichnis nicht herausfinden dürfen?
weil man vl das hauptverzeichnis dann einsehen kann?
dann schützt man einfach den rest per htaccess außer der datei, die man öffentlich zugreifbar machen will
BenBE - Fr 23.01.09 18:48
| Flamefire hat folgendes geschrieben : |
| @benbe: das mit htaccess ist trotzdem sinnvoll...je nachdem wofür |
Du hast Dir schon einmal die Mühe gemacht, das RFC 2616/2617, insbesondere den Abschnitt zur HTTP Basic Authentification durchzulesen? Daher auch meine Klammerbemerkung bzgl. Digest-Authentification.
Wenn man Masic Auth nutzt, kann ich auch gleich kgar kein Passwort verwenden, da mir der TCP-Datenstrom das Passwort nahezu im Klartext serviert.
| Flamefire hat folgendes geschrieben : |
| warum, soll man das hauptverzeichnis nicht herausfinden dürfen? |
Weil einige ein falsches Verständnis von Sicherheit haben ;-) Auf einem Webserver sind Directory Listings tabu; wenn nicht, ist der Server falsch konfiguriert. Einzige ausnahme bilden statische Download-Verzeichnisse mit öffentlichen Dateien, wo jeder wissen darf, was dort enthalten ist; dies schließt aber ein, dass aus diesen Verzeichnissen heraus kein Quelltext ausgeführt wird!
| Flamefire hat folgendes geschrieben : |
| weil man vl das hauptverzeichnis dann einsehen kann? |
Weil man einem Angreifer zu viele Informationen über sein System verrät :P
| Flamefire hat folgendes geschrieben : |
| dann schützt man einfach den rest per htaccess außer der datei, die man öffentlich zugreifbar machen will |
Dann kann man auch gleich die zu schützenden Daten von den nicht zu schützenden Informationen trennen, was man eh tun sollte.
Flamefire - Sa 24.01.09 14:38
hmm...wie auch immer:
was ist an einer abfrage ála
http://example.de/dir1/geheim/login.php?a=22&b=33 so schlimm?
@Dude566: es wäre gut zu wissen, was es für eine Abfrage ist, und was, wie und warum geschützt werden soll
jaenicke - Sa 24.01.09 14:57
Nur das geheim. :mrgreen:
Geheim ist das ja schließlich dann nicht mehr.
Flamefire - So 25.01.09 10:55
genau darum geht es
warum muss das geheim bleiben?
weil es wird NIE geheim sein, wenn das programm darauf zugreifen soll
Dude566 - So 25.01.09 15:02
Vergesst es einfach, ich wollte nur eine Möglichkeit haben den Text zu verschleiern.
jaenicke - So 25.01.09 15:34
Hast du ja auch oben zweimal angeboten bekommen: :nixweiss:
| jaenicke hat folgendes geschrieben : |
Wie wäre es denn mit der schon genannten Möglichkeit? ;-) | jfheins hat folgendes geschrieben : | | Du könntest die Adresse erst zur Laufzeit zusammenfriemeln, zb: ROT13 verschlüsselt ablegen oder so. Dann kann man sie wenigstens nicht lesen, wenn man die Exe in Notepad öffnet ... |
|
So kannst du es machen, man kommt immer noch relativ einfach dran, es reicht aber nicht die Datei im Editor zu öffnen.
Dude566 - So 25.01.09 17:08
Gut, und wie funktioniert das? Ein Beispiel wäre nicht schlecht. ;)
Dude566 - So 25.01.09 17:59
Ok, danke ich werde es ausprobieren.
Entwickler-Ecke.de based on phpBB
Copyright 2002 - 2011 by Tino Teuber, Copyright 2011 - 2025 by Christian Stelzmann Alle Rechte vorbehalten.
Alle Beiträge stammen von dritten Personen und dürfen geltendes Recht nicht verletzen.
Entwickler-Ecke und die zugehörigen Webseiten distanzieren sich ausdrücklich von Fremdinhalten jeglicher Art!