www.mikrocontroller.net

Forum: PC-Programmierung Wie VB2008 Anwendung schützen? (Debugger,Diassembler,.)


Autor: AntiDebug (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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 :-((

Autor: Z8 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: AntiDebug (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Z8 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Dann nimm doch einem Basic-Compiler ala VB6. Dieser kann nativen
Maschinencode erzeugen. Also keine Symbole mehr im Klartext. :)

Autor: AntiDebug (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Dafür biete ich meinen Kunden eine Anwendung die zwar sicher ist, aber 
auf 64bit Maschinen gar nicht läuft.

Autor: Gast (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
du kannst den erzeugten Intermediate Code durch einen Obfuscator laufen 
lassen. Diassemblen kann man zwar trotzdem, ist aber ziemlich 
unleserlich ..

Autor: yalu (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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 :)

Autor: Peter (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> 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.

Autor: AntiDebug (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
VB6 auch? Hatte schon riesige Probleme unter Vista damit. Windows 7 
garnicht zu reden.

Autor: Peter (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Ralf (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Alex W. (a20q90)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Z8 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi Alex W.

... so oder so ähnlich muß Windows entstanden sein! :)) Z8

Autor: Dödel (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>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.

Autor: AntiDebug (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@dödel:
Schon mal mit Ida oda Olly einen laufenden Prozess debugt? Liegt auch 
nur im RAM.

Autor: Sven P. (haku) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: zwieblum (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
betrachte das vb-programm als proof of concept. jetzt besorgst du dir 
eine echte programmiersprache und machst das ordendlich.

Autor: mr.chip (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Sven P. (haku) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Und selbst wenn, dann ließe sich das Reverse-Engineering trotzdem nicht 
verhindern.

Autor: zwieblum (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
oh doch, brauchst nur bei m$ richtig teuer einkaufen gehen und schon 
kann windows mit dem programm nichts mehr anfangen....

Autor: Alex W. (a20q90)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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!

Autor: Sven P. (haku) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Alex W. (a20q90)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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!?

Autor: zwieblum (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Karl Heinz (kbuchegg) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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-f...
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 
:-)

Autor: yalu (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> 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.

Autor: Severino R. (severino)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Michael G. (linuxgeek) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Z8 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>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. :)

Autor: zwieblum (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
nö, das heißt "shared source" bei m$

Autor: Severino R. (severino)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: zwieblum (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
die meisten (gratis) obfuscatoren machen nur das äquivalent von debug 
meldungen entfernen.

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.