[HaBo]

**CDW** · 26.01.11, 14:55

Der im Moment verbreitete Ansatz, den Aufwand für den Cracker zu steigern heißt "Code Virtualisierung". Dabei gibt es 2 grobe Ansätze:
1. ein Opcode (Assembly Anweisung) wird durch einen Block ersetzt, der das gleiche macht - nur mit 10-100 Anweisungen. Praktisch gesehen "obfuscation" auf der untersten Stufe.
2. Es wird eine VM erstellt, für die zufällige Opcodes generiert werden (äquivalent zu echten IA-32 bzw 64 Bit Anweisungen). Die Anweisungen im Programm werden zu diesen übersetzt.
In beiden Fällen ist der Aufwand zum "Rückgängigmachen" teilweise enorm (da die Blöcke sehr generisch erstellt werden können, ist ein allgemeiner Unpacker nur sehr schwer umsetzbar. Und für ein einzelnes Programm wird man schon seine 30-50h benötigen, um zumindest die meisten Opcodes zu erkennen und rückgängig zu machen).

Vorteil: diese Verfahren lassen sich zum einen besser austesten (und sind es i.R auch ) und haben weniger Nebeneffekte.
Nachteil: Performanceeinbrüche. Das VM Vorgehen ist erst mit den aktuelleren CPUs überhaupt möglich und sollte sich trotzdem auf wichtige Routinen beschränken.
Auch hier bestehen theoretische Angriffsmöglichkeiten genau wie bei Deinem Ansatz. D.h der Programmier sollte zum einen die Dokumentation der Tools lesen sowie die SDK einsetzen. Zumindest globale Variablen a la "registered == True/False" vermeiden. Dann wird es aber für den "bösen Cracker" schon recht haarig.
Zum anderen werden z.B bei einer Shareware/Demoversion die "Vollfunktionen" asymetrisch verschlüsselt und können nur mit einem gültigen Key freigeschaltet werden.

Wie hier schon mehrfach erwäht: Dein Ansatz ist in dem Sinne nicht neu , aber Du unterschätzt imho ganz gewaltig die Implementationsschwierigkeiten bzw. Nebeneffekte. Neben der pragmatischen Frage, ob überhaupt ein "Ultra-Schutz" notwendig ist (da die gecrackte Version i.R nur von Leuten eingestezt wird, die eher nicht bereit sind, dafür zu zahlen. Sehr schön wurde es hier formuliert:
http://forum.ioncube.com/viewtopic.php?t=3309

[B]nick[/B]

Before we consider that though, it's important to consider what are the benefits of encoding, which surprisingly, in most cases isn't to stop hackers. Go to any warez site and you'll find hacked copies of many windows programs, either with licensing knocked out, key generators or software emulators for hardware dongles. The situation might seem gloomy, hopeless even, but despite this, the providers of the products actually flourish and don't go out of business because for various reasons, most people who are genuinely prepared to purchase won't suddenly become criminals and go searching for stolen code just because they could. The people who do use stolen code typically have no intention to purchase, hence looking for illegal code in the first place, or it's simply their hobby to mindlessly tinker with stolen applications because they've nothing better to do with their life, and the warez forums are essentially their social networks. Either way, there's no lost sale, and ironically, a sale could eventually result that would not have done so otherwise from someone becoming locked into an application and later going for a paid and supported newer version. Recognising this is why some providers actually release earlier versions of their applications for free themselves.

The big win tends to come from ensuring that the genuine potential purchasers have a reason to pay. Providing evaluations in encoded rather than source form is an obvious example, and licensing is another, with a typical licensing method for web applications being per-domain based. It's not being uncommon for users to operate multiple domains, and a potential problem is that after a user has purchased an initial license, if they later try the scripts on a second domain and find that they work, they may not realise that they are supposed to pay for a second license, or they may think that it doesn't apply to them for some reason because the files just work; either way, there is no additional sale when there should be, and a significant loss of revenue. Licensing ensures that the files won't automatically work on a different domain, and makes it likely that the user will purchase an extra license provided that the cost is reasonable and there is sufficient perceived benefit to the user. In essence, it keeps the honest people honest.

Durch den Schutz gibt es zwangsläufig mehr Bugs. Sehr bekannt z.B im Zusammenhang mit Starforce http://www.pcwelt.de/news/Ubisoft-ve...tz-118433.html
(inoffizieller Grund für den Verzicht waren afaik auch die hohen Supportkosten, da auch viele legitime Kunden betroffen waren)
Man bräuchte einfach eine realistische Kalkulation: wieviel verliert man tatsächlich durch "Raubkopierer" (dabei sollte eben berücksichtigt werden, dass bei weitem nicht jeder von denen sich die Software sonst gekauft hätte), welche Kosten entstehen durch den Support, den Mehraufwand beim Testen/Implementieren sowie Verlust der Kunden, die durch Kopierschutzbugs abgeschrekt werden.

ar08 · 26.01.11, 21:44

Zitat:

Zitat von CDW

Man bräuchte einfach eine realistische Kalkulation: wieviel verliert man tatsächlich durch "Raubkopierer" (dabei sollte eben berücksichtigt werden, dass bei weitem nicht jeder von denen sich die Software sonst gekauft hätte), welche Kosten entstehen durch den Support, den Mehraufwand beim Testen/Implementieren sowie Verlust der Kunden, die durch Kopierschutzbugs abgeschrekt werden.

Natürlich - betriebswirtschaftlich gesehen ist fraglich, in wie fern es für einen Hersteller überhaupt Sinn macht, da allzu groß zu investieren. Welches Maß an Aufwand (finanziell und zeitlich) dann letztendlich reingesteckt werden sollte ist sicher von Produkt zu Produkt sehr unterschiedlich.

Ev0luti0n · 14.03.11, 21:54

Ich bin mir im klaren darüber , dass ich wegen meiner folgenden (dummen?) Frage verbal vergewaltigt werde , aber : Warum löscht man nicht aus dem gesamten Programm die Abhängigkeiten von crval? Oder ist das für euch die zu große Arbeit bei x-tausend Seiten Code ?
Hier wird nur von Einsetzungen von true oder false geredet aber nicht vom simplen löschen. Versteh ich da was falsch beim Patchen?

+++ATH0 · 15.03.11, 16:55

Ob man die x Abhängigkeiten "löscht" oder dessen Control-Flow manipuliert, ist in etwa gleich aufwendig.
Dagegen einen korrekten Key oder eine korrekte Maschine zu emulieren ist in dem vorgestellten Szenario die einfachste Lösung.

Anzeige

- Anzeige -

26.01.11, 14:55	#31 (permalink)
CDW Moderator Registriert seit: 20.07.05 Likes: 202	Anzeige Der im Moment verbreitete Ansatz, den Aufwand für den Cracker zu steigern heißt "Code Virtualisierung". Dabei gibt es 2 grobe Ansätze: 1. ein Opcode (Assembly Anweisung) wird durch einen Block ersetzt, der das gleiche macht - nur mit 10-100 Anweisungen. Praktisch gesehen "obfuscation" auf der untersten Stufe. 2. Es wird eine VM erstellt, für die zufällige Opcodes generiert werden (äquivalent zu echten IA-32 bzw 64 Bit Anweisungen). Die Anweisungen im Programm werden zu diesen übersetzt. In beiden Fällen ist der Aufwand zum "Rückgängigmachen" teilweise enorm (da die Blöcke sehr generisch erstellt werden können, ist ein allgemeiner Unpacker nur sehr schwer umsetzbar. Und für ein einzelnes Programm wird man schon seine 30-50h benötigen, um zumindest die meisten Opcodes zu erkennen und rückgängig zu machen). Vorteil: diese Verfahren lassen sich zum einen besser austesten (und sind es i.R auch ) und haben weniger Nebeneffekte. Nachteil: Performanceeinbrüche. Das VM Vorgehen ist erst mit den aktuelleren CPUs überhaupt möglich und sollte sich trotzdem auf wichtige Routinen beschränken. Auch hier bestehen theoretische Angriffsmöglichkeiten genau wie bei Deinem Ansatz. D.h der Programmier sollte zum einen die Dokumentation der Tools lesen sowie die SDK einsetzen. Zumindest globale Variablen a la "registered == True/False" vermeiden. Dann wird es aber für den "bösen Cracker" schon recht haarig. Zum anderen werden z.B bei einer Shareware/Demoversion die "Vollfunktionen" asymetrisch verschlüsselt und können nur mit einem gültigen Key freigeschaltet werden. Wie hier schon mehrfach erwäht: Dein Ansatz ist in dem Sinne nicht neu , aber Du unterschätzt imho ganz gewaltig die Implementationsschwierigkeiten bzw. Nebeneffekte. Neben der pragmatischen Frage, ob überhaupt ein "Ultra-Schutz" notwendig ist (da die gecrackte Version i.R nur von Leuten eingestezt wird, die eher nicht bereit sind, dafür zu zahlen. Sehr schön wurde es hier formuliert: http://forum.ioncube.com/viewtopic.php?t=3309 [B]nick[/B] Before we consider that though, it's important to consider what are the benefits of encoding, which surprisingly, in most cases isn't to stop hackers. Go to any warez site and you'll find hacked copies of many windows programs, either with licensing knocked out, key generators or software emulators for hardware dongles. The situation might seem gloomy, hopeless even, but despite this, the providers of the products actually flourish and don't go out of business because for various reasons, most people who are genuinely prepared to purchase won't suddenly become criminals and go searching for stolen code just because they could. The people who do use stolen code typically have no intention to purchase, hence looking for illegal code in the first place, or it's simply their hobby to mindlessly tinker with stolen applications because they've nothing better to do with their life, and the warez forums are essentially their social networks. Either way, there's no lost sale, and ironically, a sale could eventually result that would not have done so otherwise from someone becoming locked into an application and later going for a paid and supported newer version. Recognising this is why some providers actually release earlier versions of their applications for free themselves. The big win tends to come from ensuring that the genuine potential purchasers have a reason to pay. Providing evaluations in encoded rather than source form is an obvious example, and licensing is another, with a typical licensing method for web applications being per-domain based. It's not being uncommon for users to operate multiple domains, and a potential problem is that after a user has purchased an initial license, if they later try the scripts on a second domain and find that they work, they may not realise that they are supposed to pay for a second license, or they may think that it doesn't apply to them for some reason because the files just work; either way, there is no additional sale when there should be, and a significant loss of revenue. Licensing ensures that the files won't automatically work on a different domain, and makes it likely that the user will purchase an extra license provided that the cost is reasonable and there is sufficient perceived benefit to the user. In essence, it keeps the honest people honest. Durch den Schutz gibt es zwangsläufig mehr Bugs. Sehr bekannt z.B im Zusammenhang mit Starforce http://www.pcwelt.de/news/Ubisoft-ve...tz-118433.html (inoffizieller Grund für den Verzicht waren afaik auch die hohen Supportkosten, da auch viele legitime Kunden betroffen waren) Man bräuchte einfach eine realistische Kalkulation: wieviel verliert man tatsächlich durch "Raubkopierer" (dabei sollte eben berücksichtigt werden, dass bei weitem nicht jeder von denen sich die Software sonst gekauft hätte), welche Kosten entstehen durch den Support, den Mehraufwand beim Testen/Implementieren sowie Verlust der Kunden, die durch Kopierschutzbugs abgeschrekt werden. __________________ Noch mal, für alle Pseudo-Geeks: 1+1=0. -> 10 wäre Überlauf! Selig, wer nichts zu sagen hat und trotzdem schweigt.

Themen-Optionen
Druckbare Version zeigen Jemanden per E-Mail auf dieses Thema hinweisen
Ansicht
Linear-Darstellung Zur Hybrid-Darstellung wechseln Zur Baum-Darstellung wechseln

14.03.11, 21:54	#33 (permalink)
Ev0luti0n Registriert seit: 06.03.11 Likes: 0	Ich bin mir im klaren darüber , dass ich wegen meiner folgenden (dummen?) Frage verbal vergewaltigt werde , aber : Warum löscht man nicht aus dem gesamten Programm die Abhängigkeiten von crval? Oder ist das für euch die zu große Arbeit bei x-tausend Seiten Code ? Hier wird nur von Einsetzungen von true oder false geredet aber nicht vom simplen löschen. Versteh ich da was falsch beim Patchen?

15.03.11, 16:55	#34 (permalink)
+++ATH0 Member of Honour Registriert seit: 02.04.05 Likes: 76	Ob man die x Abhängigkeiten "löscht" oder dessen Control-Flow manipuliert, ist in etwa gleich aufwendig. Dagegen einen korrekten Key oder eine korrekte Maschine zu emulieren ist in dem vorgestellten Szenario die einfachste Lösung.

[HaBo]

Das uncrackbare Programm - ein Ansatz?