Hallo,
ich hab mal eine ganz allgemeine Frage:
angenommen, ich schreibe ein Programm in irgendeiner beliebigen Programmiersprache, kompiliere alles und verbreite meine executable. Das Programm verwaltet sensible Nutzerdaten, die per SSL mit einem Server ausgetauscht werden.
Nun stellt sich mir die Frage, wie ich die Funktionsweise des Programmes am besten vor neugierigen Augen verstecken kann....
Wäre es einem potenziellen Cracker eine Hilfe, wenn er wüsste, in welcher Programmiersprache das Programm geschrieben wurde? Könnte er dann leichterin das Programm einbrechen oder mehr über die interne Funktionsweise erfahren? Oder spielt das keine Rolle?
Mir ist soweit klar, dass es immer Wege gibt, eine ausführbare Datei zu cracken, un zu sehen, wie intern alles funktioniert - ich möchte halt nur ungern noch beim Einbrechen helfen.
Danke für alle Infos
Leichtes Ziel für Cracker?
- Xin
- nur zu Besuch hier
- Beiträge: 8862
- Registriert: Fr Jul 04, 2008 11:10 pm
- Wohnort: /home/xin
- Kontaktdaten:
Re: Leichtes Ziel für Cracker?
Wenn Du in einer Skriptsprache wie PHP/Python/Perl programmierst, musst Du sicher sein, dass der Apache die Skripte nicht selbst rausgibt. Oder sogar die sensiblen Daten direkt - also die Konfiguration zur Datenbank.danibert hat geschrieben:Hallo,
ich hab mal eine ganz allgemeine Frage:
angenommen, ich schreibe ein Programm in irgendeiner beliebigen Programmiersprache, kompiliere alles und verbreite meine executable. Das Programm verwaltet sensible Nutzerdaten, die per SSL mit einem Server ausgetauscht werden.
Nun stellt sich mir die Frage, wie ich die Funktionsweise des Programmes am besten vor neugierigen Augen verstecken kann....
Wäre es einem potenziellen Cracker eine Hilfe, wenn er wüsste, in welcher Programmiersprache das Programm geschrieben wurde? Könnte er dann leichterin das Programm einbrechen oder mehr über die interne Funktionsweise erfahren? Oder spielt das keine Rolle?
Mir ist soweit klar, dass es immer Wege gibt, eine ausführbare Datei zu cracken, un zu sehen, wie intern alles funktioniert - ich möchte halt nur ungern noch beim Einbrechen helfen.
Danke für alle Infos
Es gibt "kompilierende" Sprachen, die nichts anderes tun, als einen kompilierten Interpreter mit dem Skript in eine Datei zu packen. Das gibt natürlich auch Einsicht in die Algorithmen.
Wenn Du sensible Daten sogar im Speicherabbild verstecken willst, dürfen sie auch nie vollständig vorliegen. Ein sensibler String kann also nicht als ganzes übergeben werden, sondern muss Buchstabe für Buchstabe dekodiert werden und dann auch Buchstabe für Buchstabe verarbeitet werden:
Code: Alles auswählen
int sensibleStrLen( char * string )
{
int i;
while( decodeChar( string[ i ] ))
i++;
}
Merke: Wer Ordnung hellt ist nicht zwangsläufig eine Leuchte.
Ich beantworte keine generellen Programmierfragen per PN oder Mail. Dafür ist das Forum da.
Ich beantworte keine generellen Programmierfragen per PN oder Mail. Dafür ist das Forum da.
Re: Leichtes Ziel für Cracker?
Ein potenzieller Cracker findet auch bei den meisten kompilierten Programmen die Programmiersprache relativ einfach heraus (bspw. mit PEiD).
Außerdem können kompilierte Programme von einen Cracker disassembliert werden, womit er zwar keinen Zugang zu deinem Code bekommt, welchen du in irgendeiner Hochsprache geschrieben hast, allerdings zu dem Maschienencode in Assembler, wo er ihn munter nach Lust und Laune editieren/auslesen kann. Wenn du das verhindern willst, beziehungsweise dem Cracker erheblich erschweren, kannst du sogenannte "Obfuscator" einsetzen, dessen Aufgabe es ist, deinen Programmcode auch in Assembler zu verschleiern
Außerdem können kompilierte Programme von einen Cracker disassembliert werden, womit er zwar keinen Zugang zu deinem Code bekommt, welchen du in irgendeiner Hochsprache geschrieben hast, allerdings zu dem Maschienencode in Assembler, wo er ihn munter nach Lust und Laune editieren/auslesen kann. Wenn du das verhindern willst, beziehungsweise dem Cracker erheblich erschweren, kannst du sogenannte "Obfuscator" einsetzen, dessen Aufgabe es ist, deinen Programmcode auch in Assembler zu verschleiern
They say, if you play a Microsoft CD backwards, you hear satanic messages. Thats nothing, cause if you play it forwards, it installs Windows.
- cloidnerux
- Moderator
- Beiträge: 3125
- Registriert: Fr Sep 26, 2008 4:37 pm
- Wohnort: Ram (Gibts wirklich)
Re: Leichtes Ziel für Cracker?
Das Cracken ist unterschiedlich leicht und schwer:
Sprachen des .NET Frameworks lassen sich relaitv einfach auslesen, da sie anders Kompiliert werden kann man mit tools wie Reflector den code auslesen oder mit Programmen wie Crack.NET das Speicherabbild, beide Programme sind Legal und Kostenlos.
Sprachen wie C/C++/D lassen sich nur Disassemblieren und man muss dann die Funktionswiese der Algorithmen selber aus dem Maschienencode herauslesen, ist zwar nicht einfach, funktioniert aber.
Skriptsprachen sind noch einfacher zu knacken, solange einem die Executable oder das Skript vorliegt.
Jetzt stellt sich aber die Frage, welchen Nutzen ein Hacker/Cracker daraus ziehen kann:
Die SSL-Verbindung kann er nicht abhören, mit den Algorithmen kann er nichts machen, da die Daten in der DB PW geschützt sind.
Also muss er die Daten des Speichers auslesen, da würde dann das Wissen um die Algoritmen helfen, also müssen die Daten auch geschützt werden.
Sprachen des .NET Frameworks lassen sich relaitv einfach auslesen, da sie anders Kompiliert werden kann man mit tools wie Reflector den code auslesen oder mit Programmen wie Crack.NET das Speicherabbild, beide Programme sind Legal und Kostenlos.
Sprachen wie C/C++/D lassen sich nur Disassemblieren und man muss dann die Funktionswiese der Algorithmen selber aus dem Maschienencode herauslesen, ist zwar nicht einfach, funktioniert aber.
Skriptsprachen sind noch einfacher zu knacken, solange einem die Executable oder das Skript vorliegt.
Jetzt stellt sich aber die Frage, welchen Nutzen ein Hacker/Cracker daraus ziehen kann:
Die SSL-Verbindung kann er nicht abhören, mit den Algorithmen kann er nichts machen, da die Daten in der DB PW geschützt sind.
Also muss er die Daten des Speichers auslesen, da würde dann das Wissen um die Algoritmen helfen, also müssen die Daten auch geschützt werden.
Redundanz macht wiederholen unnötig.
quod erat expectandum
quod erat expectandum