Das uncrackbare Programm - ein Ansatz?

dann emuliert man halt nicht, sondern identifiziert die vergleiche die zur programmsicherheit gemacht werden ... (vgl. der verzweigungen zwischen einer ordentlichen installation und einer anderen)


wohin man das ganze auch treibt, der angreifer hat immer den vorteil, dass er lediglich eine lücke finden muss, die du nicht bedacht hast ... während du besser an alle gedacht haben solltest ... sofern diese anzahl endlich ist ...
 
Es muss unendlich "Lücken" geben, denn man kann beweisen, dass die Funktionalität auf einer gültigen Maschine mit gültigem Key stets reproduzierbar ist auf einer beliebig anderen Maschine X mit gültigem Key.

Wenn einmal der Key und eine gültige Maschine bekannt ist -> GameOver und zwar notwendig.
 
Es muss unendlich "Lücken" geben, denn man kann beweisen, dass die Funktionalität auf einer gültigen Maschine mit gültigem Key stets reproduzierbar ist auf einer beliebig anderen Maschine X mit gültigem Key.

Wenn einmal der Key und eine gültige Maschine bekannt ist -> GameOver und zwar notwendig.

Das ist ohne Zweifel tatsächlich der Fall. Die Frage ist nur, ob es dennoch eine Methode geben kann, welche den Aufwand für den Angreifer so extrem erhöht, dass das Programm in der Praxis damit unknackbar wird. So wie ja auch die RSA-Verschlüsselung bei unbekanntem Key zu knacken ist. Nur halt eben mit so immensem Rechenaufwand, dass die theoretisch existierende Möglichkeit keinen praktischen Nutzen mehr darstellt.

Dies ist im Prinzip mein Gedanke: eine Möglichkeit zu finden, die ähnlich wie bei der Verschlüsselung einfach so aufwendig ist, dass der Versuch den Schutz zu knacken von Vornherein nicht sinnvoll ist.

Dies wiederum kann, sofern überhaupt irgendwie möglich, wohl nur mit Hilfe einer Automatik bewerkstelligt werden. Quasi nach dem Ansatz, dass der Software-Autor einen entscheidenden Vorteil hat - nämlich den, dass aus einer sehr kleinen Menge an Input (z.B. einige Zeilen Source-Code oder eine kleine Menge an Daten) eine riesige Menge an Output erzeugt werden kann (Präprozessor, Compiler, etc.). Soll heißen, wenn der Software-Autor es schaffen würde, einen Automatismus zu verwenden, der vom Angreifer nur manuell rückgängig zu machen ist, dann hätte er sein Ziel erreicht.

Ich denke dass es dafür, auf einer formalen Ebene gesehen, weder Beweis noch Gegenbeweis gibt. Aktuell zumindest.
 
ich behaupte mal, dass mit steigender komplexität für den angreifer zwangsläufig die komplexität für den autor steigt, da die wirklich effizienten "steine" die man einem angreifer in den weg legen kann, wirklich geistige anstrenungen auf beiden seiten bedeuten ... und in dem fall wird eine komerzielle software irgendwann unrentabel ... die interessante frage lautet daher eigentlich wie findet man bei vertretbarer preformance, fehleranfälligkeit, wartungsfreundlichkeit und kosten eine möglichst hartnäckige hürde an der sich ein angreifer möglichst lange die zähne ausbeißt, oder eine anderweitige option die dafür sorgt dass sich die leute mit den entsprechenden fähigkeiten nicht dafür interessieren dieses problem zu lösen, oder bei der lösung mitzuwirken ...

sony hat mit der ps3 unfreiwillig den beweis geliefert ... siehe 27c3
 
Zuletzt bearbeitet:
ar08:
Dies ist im Prinzip mein Gedanke: eine Möglichkeit zu finden, die ähnlich wie bei der Verschlüsselung einfach so aufwendig ist, dass der Versuch den Schutz zu knacken von Vornherein nicht sinnvoll ist.
Sowohl GrafZahl, als auch ich, haben ja bereits darauf hingewiesen, dass dieses Prinzip in Bezug auf die Kryptografie gültig ist, weil es hier unterschiedliche Voraussetzungen gibt...

GrafZahl:
ich behaupte mal, dass mit steigender komplexität für den angreifer zwangsläufig die komplexität für den autor steigt, da die wirklich effizienten "steine" die man einem angreifer in den weg legen kann, wirklich geistige anstrenungen auf beiden seiten bedeuten ...
Das denke ich auch. Wenn man den Nutzen einer aufgeblasenen Komplexität der Schutzmaßnahmen, also die längere Zeit für's cracken, gegen die Nachteile - also z. B. längere Entwicklungszeit, höhere Fehleranfälligkeit und sinkende Performantität - abwiegt, dürften die Nachteile überwiegen oder doch zumindest den Nutzen aufheben...
Das Ergebnis solch einer Kosten-Nutzen-Analyse, dürfte also nachteilig und somit unwirtschaftlich sein.
 
Der sprigende Punkt ist, sich mehr Mühe beim Produkt zu geben.
Viele Angebote auf Steam werden kaum noch mehr raubkopiert, auch viele innovative Smartphone-Games haben Erfolg durch Massenverkauf zu niedrigen Preisen.
Software, die für große Firmen gedacht sind, werden von Firmen auch lizensiert und da ist es nicht soo schlimm, wenn kleine Fische dort rumkopieren.
Die Rolle von Kopierschutzmaßnahmen wird meiner Meinung nach überschätzt. Es gibt viel bessere Chancen, die sowohl den Verkäufern als auch den Konsumenten zu Gute kommen.
 
+++ATH0:
Der sprigende Punkt ist, sich mehr Mühe beim Produkt zu geben.
Wirklich gut gesagt...:thumb_up:
Auch wenn man das z. B. in Redmond nicht gern hören wird!:D

+++ATH0:
Die Rolle von Kopierschutzmaßnahmen wird meiner Meinung nach überschätzt. Es gibt viel bessere Chancen, die sowohl den Verkäufern als auch den Konsumenten zu Gute kommen.
Du sprichst mir wirklich aus dem Herzen...:)
 
Um nochmal hervorzuheben, was GrafZahl schon nannte:

Selbst wenn du einen Schutz baust, der nach deiner Vorstellung eingen guten Schutz gegen RE bietet, heißt das noch lange nicht, das es keinen anderen Weg gibt, die Software zu reversen. Du hattest ja schon RSA angesprochen.

Warum sollte ich mir die Mühe machen eine Zahl in ihre Primfaktoren zu zerlegen, wenn ich eine MITM Atacke durchführen kann?
Andere Analogie: Um einen Satz zu beweisen, muss ich dies allgemeingültig machen. Um einen Satz zu widerlegen muss ich nur ein einziges Gegenbeispiel finden.

Daher hast du als Entwickler keinen Vorteil gegenüber dem Angreifer, wie du ja behauptest, sondern einen gravierenden Nachteil.
 
Daher hast du als Entwickler keinen Vorteil gegenüber dem Angreifer, wie du ja behauptest, sondern einen gravierenden Nachteil.

Ich hab nicht behauptet, dass der Entwickler generell im Vorteil gegenüber dem Angreifer wäre (was ja auch definitiv nicht der Fall ist). Ich bezog mich nur auf einen konkreten Vorteil den der Entwickler hat, nämlich dass er unter Zuhilfenahme vom automatisierten Vorgängen wie z.B. dem Kompilieren durch kleinen Aufwand seinerseits einen (verhältnismäßig) großen Aufwand beim Angreifer verursachen kann.
 
diese automatisierten vorgänge müssen auch erstmal implementiert werden ... da steckt auch eine gewisse entwicklungszeit drin ... zudem hat sowas mitunter unbeabsichtigte nebeneffekte, und lässt sich auch nicht in jeder programmstruktur so einfach benutzen, man denke nur mal an threads und gemeinsame ressourcen ...

da kommt ein ganzer haufen "wenn" und "aber" ... beispielsweise nachteile die nicht unbedingt primär in der verlängerung der entwicklungs zeitspanne liegen, aber dennoch unternehmerische kosten verursachen ... was kostet die behebung von bugs die auf diese art der verschleierung zurückzuführen sind? was kostet die verlängerte testphase (so sie denn verlängert wird) um sicherzustellen dass keine relevante beeinträchtigung der regulären nutzer entsteht? (falls die verlängerte tesphase weg fällt, was kostet die wut der kunden? ... falls nicht, was kostet die spätere markteinführung?)
diese liste könnte ich jetzt noch ein weilchen weiterführen, aber ich denke es ist klar worauf ich hinaus will...

zu sagen "der aufwand auf entwicklerseite sei im gegensatz zum aufwand des crackers vergleichsweise klein" ist in dieser hinsicht irgendwie eine milchmädchen-rechnung ...

aufwand ist nicht zwangsweise der zeitaufwand des programmierers ... den evtl. relativ geringen zeitaufwand des programmierers erkauft man sich bisweilen recht teuer ... zu teuer für meinen geschmack ...
 
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
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-verzichtet-vorerst-auf-Starforce-Kopierschutz-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.
 
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.
 
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?
 
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.
 
Zurück
Oben