Hallo Leute.
Wie kann ich meine VB2008 Anwendung vor dem Debuggen, Diassemblen,...
schützen?
Habe schon einige Diassembler probiert und bin draufgekommen, das ich
aus meiner EXE wieder Quellcode erzeugen kann :-(
Weis jemand ein gutes Programm (nicht das was bei VS dabei ist) mit dem
ich mein Programm packen, verschlüsseln oder sonstiges kann?
PS.: Schon einige Programme gefunden. Aber Google liefert auch gleich
die Antwort, wie ich das Programm wieder "Cracken" kann :-((
wenn Du wirklich so ein Sicherheitwahn hast:
-EXE voll oder teilweise verschlüsselt auf der Platte ablegen
-beim Start im RAM entschlüssel und laufen lassen
Das wird häufig bei "Verdongelter" Software gemacht. Dabei
ist der Schlüssel in Hardware gehalten. (Dongle) Z8
Bei VB2008 müsste ich die komplette Datei verschlüsseln und per Loader
in den Ram kopieren. Anschliesend müsste ich das Framework noch dazu
bringen meinen Code auszuführen. -> Ein Problem
Das andere Problem ist, sobald das Programm im Ram Debuged wird, sind
sämtliche Symbole usw, im Klartext wieder zum lesen.
Mach dein Programm Opensource und schau zu, dass keine Fehler drin sind.
Dann ist die Chance sehr hoch, dass es niemand disassembliert oder
debugt ;-)
Spaß beiseite: Jedes Programm, das auf einem gewöhnlichen PC unter einem
gewöhnlichen Betriebssystem ausführbar ist, kann auch per Debugger
analysiert werden. Da hilft auch Verschlüsseln nichts, da die einzelnen
Programmabschnitte spätestens zur Ausführung entschlüsselt werden
müssen.
Wenn du einen bahnbrechenden neuen Algorithmus vor anderen schützen
möchtest, besteht die sinnvollste Möglichkeit darin, so undurchsichtig
zu programmieren, dass der Aufwand für die Analyse des Pogramms höher
als der Nutzen ist.
BTW: Viele Programmierer wenden diese Methode unbewusst für alle ihre
Entwicklungen an :)
Höhere Sicherheit erreichst du dadurch, dass das Programm (oder
zumindest die schützenswerten Teile) auf eigener Hardware mit geeigneten
Schutzvorrichtungen (bspw. einem Flash-µC mit aktivietem Ausleseschutz)
ausgeführt wird.
> Das andere Problem ist, sobald das Programm im Ram Debuged wird, sind> sämtliche Symbole usw, im Klartext wieder zum lesen.
Wenn das das Hauptproblem ist: Die Symbole sollten beim Kompilieren
(ggf. mit einer entsprechenden Compiler-/Linker-Option) entfernt werden.
Falls dies bei VB nicht geht: Für Java gibt es so genannte Obfuscators,
die alle Symbole durch unverständliche Buchstabenkombinationen ersetzen,
mit denen niemand etwas anfangen kann. Vielleicht gibt es so etwas auch
für VB.
Ach, Gast hat das auch schon vorgeschlagen :)
> Dafür biete ich meinen Kunden eine Anwendung die zwar sicher ist, aber> auf 64bit Maschinen gar nicht läuft.
bei uns läuft auch jede 32Bit Anwendung auf den 64Bit Systen, das ist
also kein Grund.
Windows liefert eine komplette 32Bit umgebung mit - viel programm von MS
sind auch noch 32Bit.
Ich hatte bis jetzt noch überhaupt keine Probleme mit alten Anwendungen
auf einem MS-Server2008x64.
Aber ich kenn VB nicht, bei uns sind es normale C/C++ Anwedungen.
Wie ist es eigentlich, wenn man den zu sichernden Code in eine DLL
auslagert? Kann man ja auch in .NET machen, soweit ich weiss. Aber lesen
oder disassemblieren kann's ja dann keiner mehr, oder?
Ralf
Baue in den Quellcode irgendwelche unbrauchbaren Funktionen ein die Du
mit :
i=1
if i = 2 then
irgendwelche sinnlosen Aufgaben abarbeiten
endif
ausführst (da i /= 2 ist, wird der code nie ausgeführt, aber
mitcompiliert)
So kannst Du dein Programm aufblähen, und die eigendliche Funktionen
sind nicht sofort ersichtlich.
>Habe schon einige Diassembler probiert und bin draufgekommen, das ich>aus meiner EXE wieder Quellcode erzeugen kann :-(
??? Quellcode wohl kaum.
>Bei VB2008 müsste ich die komplette Datei verschlüsseln und per Loader>in den Ram kopieren. Anschliesend müsste ich das Framework noch dazu>bringen meinen Code auszuführen. -> Ein Problem>Das andere Problem ist, sobald das Programm im Ram Debuged wird, sind>sämtliche Symbole usw, im Klartext wieder zum lesen.
Warum lässt du es nicht einfach bleiben? Wenn du den Unterschied
zwischen Release und Debug nicht kennst, dann behaupte ich mal, wird
sich auch kein Schwein für dein Programm interessieren und du wohl kaum
einen halbwegs ordentlichen Anti-Debug Algorithmus programmieren können.
Alex W. schrieb:
> ausführst (da i /= 2 ist, wird der code nie ausgeführt, aber> mitcompiliert)
Würde ich ja nicht grad drauf wetten. Microsoft baut so tolle Compiler,
die optimieren das ganz sicher auch weg.
Ansonsten, ganz kurze Antwort:
Man kann ein Programm nicht gegen Debuggen und Disassemblieren schützen.
Ein Programm muss schon sehr bahnbrechende Algorithmen enthalten, damit
sich überhaupt jemand die Mühe macht, es zu reverse-engineeren. Und das
trifft auf die allermeisten Programme sicherlich nicht zu.
WinXPembedded kann das ganze laufwerk verscghlüsseln (incl. WinXPe). So
kann ein debuggen verhindert werden. Mithilfe eines Dongles etc ist es
schon möglich! Kenne eine irma die genau das macht!
Debuggen und Reverse-Engineering ist immer möglich, auch wenn du dein
Laufwerk nachts bei Vollmond dreimal gegen die Wand haust und dann
zehnmal verschlüsselst.
Spätestens beim Ausführen des Programmes liegt der Programmtext wieder
unverschlüsselt im Arbeitsspeicher, es sei denn, die CPU kommt mit
verschlüsseltem Code zurecht.
Sven P. schrieb:
> nachts bei Vollmond dreimal gegen die Wand haust und dann> zehnmal verschlüsselst.
Ich würde erst verschlüsseln, und dann gegen die Wand hauen! Die
Warscheinlichkeit nach dem Hauen keine Daten mehr auf das Lafwerk zu
bekommen steigt exponentiell mit der Anzahl der Schläge xD
Und erst recht bei Vollmond*!
*Wieso ist es eigendlich bei Vollmond nacht? Nacht ist doch Dunkelheit!
Und Vollmond bringt Licht! Also ist die Nacht eine Dunkelheit des
Grauens und der Kälte! Deshalb ist es doch Nachts drausen kälter als
drinn!?
lol .. ich bin immer noch für die gute alte methode mit den brandstellen
am datenträger ... ach ja, keine frage, wenn man will kann man jedes
dieser tollen systeme knacken. siehe z.b. die unmanipulierbaren
wählmaschinen.
zwieblum schrieb:
> lol .. ich bin immer noch für die gute alte methode mit den brandstellen> am datenträger ... ach ja, keine frage, wenn man will kann man jedes> dieser tollen systeme knacken.
Yep.
Was mich aber überrascht hat ist, wie simpel das alles unter dem Dot-Net
Geraffel geht.
Ich bin vor eniger Zeit auch ziemlich naiv an die Sache rangegangen. C#
Programm geschrieben und mehr aus Neugier als sonstwas hab ich mal so
ein Teil
http://www.componentsource.com/products/xenocode-fox-profiler/index.html
auf die EXE losgelassen.
Mich hats fast vom Sessel gehauen, was das Teil aus dem Code rausgeholt
hat und welche Qualität der generierte Source Code hatte.
Interessant, dass anscheinend viele dieser Source-Code Generierer auch
einen entsprechenden Obfuscator im Angebot haben. Hier hat MS$ wohl
wieder mal einen Markt geschaffen, den ohne MS$ niemand brauchen würde
:-)
> Mich hats fast vom Sessel gehauen, was das Teil aus dem Code> rausgeholt hat und welche Qualität der generierte Source Code hatte.
Das geht unter Java mit den entsprechenden Recompilern schon länger. Es
verwundert deswegen nicht, dass das bei C#, das ja mehr oder weniger ein
Remake von Java darstellt, genauso ist.
Das "Problem" bei Sprachen wie Java und C# ist, dass für das genze
Reflection-Gedöns sehr viel Information über die Datenstrukturen in den
Bytecode übernommen werden muss. Am Kontrollfluss wird beim Kompilieren
sowieso nicht viel geändert. Beides zusammen reicht aus, um den
Originalquellcode ziemlich authentisch wieder herstellen zu können.
Selbst bei "obfuzierten" Programmen mit verunstalteten Symbolnamen fällt
das Reverse-Engineering immer noch wesentlich leichter als bspw. bei
einem nativ kompilierten C-Programm, weil die Information über den
Aufbau der Datenstrukturen immer noch im Bytecode stecken.
Karl heinz Buchegger schrieb:
> Mich hats fast vom Sessel gehauen, was das Teil aus dem Code rausgeholt> hat und welche Qualität der generierte Source Code hatte.
Dies ist aber nun wirklich kein Bug, sondern ein Feature: Mittels
"Reflection" (in .NET integriert) lässt sich der ganze compilierte
Sourcecode zur Laufzeit untersuchen.
AntiDebug schrieb:
> Hallo Leute.>> Wie kann ich meine VB2008 Anwendung vor dem Debuggen, Diassemblen,...> schützen?> Habe schon einige Diassembler probiert und bin draufgekommen, das ich> aus meiner EXE wieder Quellcode erzeugen kann :-(
Ich nehme jetzt einfach mal an dass dort P-Code erzeugt wird, also das
ganze auf ner .NET-Umgebung laeuft? Dann kannst Du dort im Prinzip
garnichts tun. Moeglicherweise gibt es aehnlich wie bei Java obfuscator,
musst halt mal umsehen.
>Dies ist aber nun wirklich kein Bug, sondern ein Feature: Mittels>"Reflection" (in .NET integriert) lässt sich der ganze compilierte>Sourcecode zur Laufzeit untersuchen.
.net wie auch Java, Html, ... openen source halt. :)
Michael G. schrieb:
> Ich nehme jetzt einfach mal an dass dort P-Code erzeugt wird, also das> ganze auf ner .NET-Umgebung laeuft?
Deshalb heisst das Ganze IL (Intermediate Language) und nicht P-Code.
Es gibt Tools wie Dotfuscator, die den Code unleserlich machen ohne die
Funktion zu verändern.
Habe aber keine Erfahrung damit.
