Vernünftiger C++/DLL Obfuscator

Quote:

Originally Posted by MrSm!th Im Gegensatz zu Themida macht es UPX nicht einmal im Ansatz schwerer.

richtig, weil man es sogar wieder mit UPX entpacken kann

Quote:

Originally Posted by MrSm!th Im Gegensatz zu Themida macht es UPX nicht einmal im Ansatz schwerer.

Wenn du den UPX-header abänderst, wird es ein klitze klein wenig erschwert und wenn man Kosten/Aufwand abwägt lohnt sich das allemal. Immerhin wird die Exe zusätzlich noch kleiner

Quote:

Originally Posted by MrSm!th Wow, das macht übrigens auch jeder bessere Packer und das voll automatisiert. Wenn übrigens wer die Themida VM anschmeißt, kannste in den meisten Fällen einpacken. Lohnt sich nicht für viele Ziele, sich damit rumzuschlagen.

Gibt genug mögliche Angriffsszenarien und Heuristiken für Prozess-Level VMs allgemein, wurde auch 2009 im VR besprochen (Link zu einem ähnlichem Dokument):
[Only registered and activated users can see links. Click Here To Register...]

Quote:

Originally Posted by MrSm!th Ne, da gibt's schon deutlich bessere und sicherere Ansätze. Wie gesagt, die Sicherheit in die Hand des Servers zu legen ist z.B. ein guter Ansatz, den man noch mit anderen kombinieren kann.

Natürlich ein Sicherheitsmechanismus für sich alleine ist ja auch schwachsinning. Ich kann mir freilich einen Atombunker bauen mit allem was die Technik zu bieten hat, wenn ich dann aber den Schlüssel unter der Hausmatte verstecke, bringt mir alle Technik nichts. Meine Ideen waren eher als Anregungen gedacht und nicht als "Seht her das ist unschlagbar".

Quote:

Originally Posted by MrSm!th Den Kampf verlierst du. Noch dazu ist es Unsinn.

Würde ich nicht zwingend pauschalieren, kannst ja relativ leicht mit nen paar Zeilen Code automatisieren lassen, bevor du es compilest.

Quote:

Originally Posted by .XerXes richtig, weil man es sogar wieder mit UPX entpacken kann

Wenn man den Standard UPX-header verändert wird es minimal erschwert (ich habe ja nirgends geschrieben, dass es ein effektiver Schutz ist, ich meinte lediglich, dass UPX als Packer mit leichten Modifikationen nur Vorteile bietet).

Quote:

Gibt genug mögliche Angriffsszenarien und Heuristiken für Prozess-Level VMs allgemein, wurde auch 2009 im VR besprochen (Link zu einem ähnlichem Dokument):

Ich habe nie behauptet, dass es unknackbar ist.

Quote:

Natürlich ein Sicherheitsmechanismus für sich alleine ist ja auch schwachsinning. Ich kann mir freilich einen Atombunker bauen mit allem was die Technik zu bieten hat, wenn ich dann aber den Schlüssel unter der Hausmatte verstecke, bringt mir alle Technik nichts. Meine Ideen waren eher als Anregungen gedacht und nicht als "Seht her das ist unschlagbar".

Ich weiß nicht, wie du auf "ein Mechanismus alleine" kommst. Davon habe ich nichts geschrieben und auch du hast ja gleich mehrere aufgelistet.
Mir ging es eher darum, dass du erst fertige Packer kritisierst und dann Mechanismen aufzählst, die gute Packe allesamt unterstützen.

Quote:

Würde ich nicht zwingend pauschalieren, kannst ja relativ leicht mit nen paar Zeilen Code automatisieren lassen, bevor du es compilest.

Doch, das kann man pauschalisieren. In der Regel verlierst du.
Und es ist ein unsinniger Kampf. Das macht man einfach nicht. Dass das gerade von einem Performancefanatiker wie dir kommt, kann ich nicht ganz nachvollziehen.
Auch wenn man es automatisieren kann, Obfuscation auf Quelltextebene ist bei nativen Sprachen Schwachsinn.

Quote:

Wenn man den Standard UPX-header verändert wird es minimal erschwert (ich habe ja nirgends geschrieben, dass es ein effektiver Schutz ist, ich meinte lediglich, dass UPX als Packer mit leichten Modifikationen nur Vorteile bietet).

Na gut, das kann man sich auch so denken, hat aber wenig mit dem Thema zu tun, da es dir ja primär um die Größe geht.

Quote:

Originally Posted by MrSm!th Das macht man einfach nicht. Dass das gerade von einem Performancefanatiker wie dir kommt, kann ich nicht ganz nachvollziehen. Auch wenn man es automatisieren kann, Obfuscation auf Quelltextebene ist bei nativen Sprachen Schwachsinn.

"Performancefanatiker", gefällt mir. :D
Ja aus diesem Grund benutze ich auch keinerlei derartige Tools/Programme.
Wenn jemand etwas so außergewöhnliches gemacht/erfunden hat, dass es die Menschheit verändern könnte (bissel arg übertrieben), dann sollte derjenige sowieso ein Patent anmelden, ist der beste Schutz, den man kriegen kann.

Ansonsten ist Open-Source in meinen Augen immernoch das Beste, selbst für Spiele/Programme, die man verkaufen möchte.

Denn wenn man es einmal realistisch sieht, dann kommt man um jeden Schutz irgendwie herum und anstatt noch einmal ewig viele Tage in Schutz zu stecken und damit nicht nur Geld/Zeit zu verlieren, sondern auch noch Performance, könnte man sein Programm einfach weiterentwickeln und Open-Source machen.

Damit bin ich zwar jetzt ein klein wenig vom Thema abgekommen, aber als endgültigen Rat, wenn ich einmal realistisch betrachte, was ich machen würde, kann ich dir nur sagen:

Vergiss die Protections, wenn du kein Fan von Open-Source bist und dein Programm trotzdem gut ist, ist es entweder von sich aus so groß/komplex geworden, dass analysieren eh wenig Spaß macht oder aber es lohnt sich sowieso kein Schutz, weil dieses Programm nichts außergewöhnliches ist.

Edit:
Zusätzlich verkaufen sich Programme mit Source-Code im Allgemeinen besser als diejenigen ohne. ;)

Ich würde erstmal schauen, ob sich der Aufwand lohnt. Denk dran, wer es knacken will, wird es knacken. Wenn dein Programm also nicht gerade eine Weltneuheit ist, auf die jeder geil ist, würde ich mir das ganze Getuhe gleich sparen.
90% der "Cracke"r werden ja schon überfordert damit sein, dass sich die Dll nicht mit dem .NET reflector öffnen lässt.

Quote:

Originally Posted by Shadow992 Edit: Zusätzlich verkaufen sich Programme mit Source-Code im Allgemeinen besser als diejenigen ohne. ;)

Quelle?

Quote:

Originally Posted by Shadow992 Denn wenn man es einmal realistisch sieht, dann kommt man um jeden Schutz irgendwie herum und anstatt noch einmal ewig viele Tage in Schutz zu stecken und damit nicht nur Geld/Zeit zu verlieren, sondern auch noch Performance, könnte man sein Programm einfach weiterentwickeln und Open-Source machen.

Versteh ich nicht. Nur weil ein Kopierschutz geknackt werden kann, sollte man es direkt OpenSource machen?
Das macht eventuell bei sehr großen Projekten wie einer Game Engine Sinn, wo man die großen Kunden durch Linzenzen im Auge hat, aber bei (nehm ich jetzt mal an) einem kleinen Projekt wie ein Hack oder Bot?
Wer kauft denn den dann noch?

Quote:

Originally Posted by Shadow992 Vergiss die Protections, wenn du kein Fan von Open-Source bist und dein Programm trotzdem gut ist, ist es entweder von sich aus so groß/komplex geworden, dass analysieren eh wenig Spaß macht oder aber es lohnt sich sowieso kein Schutz, weil dieses Programm nichts außergewöhnliches ist.

Wat, also sind nur große / komplexe Projekte gut?
Und warum sollten Analysten an großen Projekten keinen Spaß haben?
Die Cracker die ich kenne, arbeiten lieber ne Woche lang an nem komplexen Projekt als 5 Minuten an einem Kackhaufen. Vorallem hat die Größe mit der Schwierigkeit des Crackens doch nichts zutun.
Das Programm kann noch so riesig sein, wenn die Schutzfunktion nur eine kleine poplige Funktion ist, macht das absolut keinen Unterschied ob es ein riesiges oder ein 5 Zeilen Programm ist.

Und Themida finde ich keine dumme Sache.
Vorausgesetzt man benutzt die neuste Version, für die es keine direkten Unpacker gibt wo man nur doch den EP patchen muss...
Das würde wenigstens schonmal die meisten abhalten. Wenn dann jemand kommt der es direkt manuell unpacken kann, hättest auch mit allem anderen verloren. Dann isses halt gecrackt.

Edit:
Nicht falsch verstehen, OpenSource is ne dolle Sache.
Aber als kleiner Entwickler der sich ein bischen was dazu verdienen will, eher nicht.
Eventuell wenn du in einer Linux Community unterwegs bist, eine neue dolle Lib entwickelst, und dafür Spenden sammelst.
In so einer Community wären die Mitglieder sicher bereit Kohle springen zu lassen.
Aber Release hier mal einen Hack open source und frag die Leute nach Geld. Viel Glück.

Quote:

auch mit allem anderen verloren

Nein, nicht unbedingt. Ich kann nur zum Xten mal die Methode erwähnen, die Sicherheit außerhalb des Einflussbereiches eines Crackers zu platzieren: auf einem Server.

Quote:

Ansonsten ist Open-Source in meinen Augen immernoch das Beste, selbst für Spiele/Programme, die man verkaufen möchte.

Je nachdem, von welcher Marktnische man profitiert, kann das durchaus der Fall sein. Im Verhältnis zu meinem Aufwand ist mein Verdienst recht hoch, allerdings beginnen bei mir auch diese Probleme, die der TE hat. Ich hab meine Programme aus Faulheit nicht ausreichend gesichert und bekomme nun die Rechnung dafür.

Für Netzwerkübertragung würde ich grundsätzlich SSL/RSA empfehlen. Dazu gibt es viele Tutorials und allzu kompliziert ist das auch nicht, wenn man alles richtig macht.

Quote:

Aber Release hier mal einen Hack open source

Äpfel und Birnen, hm? Cheats sind meines Erachtens nach ein ganz anderes Thema, da das ein Wettlauf zwischen Cheat- und Spieleentwicklern ist und man da durch OSS herbe Nachteile hätte. Als Beispiel kann man da Organner nehmen: Nach etlichen Jahren hat es Valve mal endlich geschafft, ihn zu detecten. Wäre Organner OSS gewesen, hätte das einen anderen Lauf genommen. Wäre VAC nun OSS, würden die Entwickler von Organner nicht so einen Stress schieben.

Warum denn Äpfel und Birnen, der Thread Ersteller meinte nur etwas von einer "DLL" die in C++ geschrieben wurde.
Näher ging er auf sein Projekt doch nicht ein. Deshalb vermute ich einfach mal dass es sich um einen Hack / Bot / Ähnliches Tool handelt.
Mit der Detection hast du natürlich recht, aber das mal aussen vor, würde man mit einem Open Source Hack / Bot vermutlich kein Geld machen.

Quote:

Originally Posted by MrSm!th Nein, nicht unbedingt. Ich kann nur zum Xten mal die Methode erwähnen, die Sicherheit außerhalb des Einflussbereiches eines Crackers zu platzieren: auf einem Server.

Damit hast du natürlich Recht.