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.
Dann nimm doch einem Basic-Compiler ala VB6. Dieser kann nativen Maschinencode erzeugen. Also keine Symbole mehr im Klartext. :)
Dafür biete ich meinen Kunden eine Anwendung die zwar sicher ist, aber auf 64bit Maschinen gar nicht läuft.
du kannst den erzeugten Intermediate Code durch einen Obfuscator laufen lassen. Diassemblen kann man zwar trotzdem, ist aber ziemlich unleserlich ..
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.
VB6 auch? Hatte schon riesige Probleme unter Vista damit. Windows 7 garnicht zu reden.
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.
Hi Alex W. ... so oder so ähnlich muß Windows entstanden sein! :)) Z8
>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.
@dödel: Schon mal mit Ida oda Olly einen laufenden Prozess debugt? Liegt auch nur im RAM.
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.
betrachte das vb-programm als proof of concept. jetzt besorgst du dir eine echte programmiersprache und machst das ordendlich.
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.
Und selbst wenn, dann ließe sich das Reverse-Engineering trotzdem nicht verhindern.
oh doch, brauchst nur bei m$ richtig teuer einkaufen gehen und schon kann windows mit dem programm nichts mehr anfangen....
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.
die meisten (gratis) obfuscatoren machen nur das äquivalent von debug meldungen entfernen.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.