Crackschutz für Programme (Plattformunabhängig)

[Patrik Graf]

Also das Ziel ist, einen mit RSA funktionierenden Crackschutz zu coden, der nicht (oder so gut wie nicht) zu knacken ist. Ob das Ergebnis dieses Projekt´s Komerziell genutzt werden soll, sollte meiner Meinung nach abgestimmt werden. Aber das machen wir dann wenn wir wissen wie viel Arbeit in dieses Projekt reingesteckt wurde. Natürlich kann man auch noch darüber nachdenken etwas anderes zum Verschlüsseln zu benutzen, aber ich denke RSA ist da am besten geeignet. Alle die an diesem Projekt Teilnehmen sind gleichberechtigt.

Zur Erklärung:

RSA = Asynchrones Verschlüsselungsverfahren mit einem Private-Key und 2 Public-Key´s. Einer zum Verschlüsseln und zwei zum Entschlüsseln.


Also, bitte meldet euch!! :D

[nj0y]

Ok, also bevor man die Verschlüsselung an sich angeht, sollte man wohl das Prinzip klären :). Zum Thema Virtual Machine: Das ist lahm. Ich hab mal VMware für Windows auf nem K6-2/300 mit 640 MB RAM probiert -> vergeßt es! Aber man könnte ja gewisse Teile des Codes in diese VM auslagern, wo es nicht so sehr auf die Geschwindigkeit ankommt (also z. B. ein paar Teile, die auf eine gültige Serial prüfen und ein paar Teile, die diese Information dann irgendwie nutzen).

Die VM an sich könnte man dann z. B. als DLL oder ActiveX realisieren, damit wäre sie von den meisten Programmiersprachen aus ansprechbar.

Der Code, der verschlüsselt werden muß, muß allerdings auch irgendwie (unabhängig vom Restcode) kompiliert werden können... und sollte ja auch programmiersprachenunabhängig sein.

[nj0y]

Achso, mal ne Frage... Du hast "plattformunabhängig" geschrieben - ich denke, daß die Lösung für Linux völlig anders aussehen würde als für Windows, oder? Oder meintest Du "programmiersprachenunabhängig"?

[Patrik Graf]

Warum nicht plattformunabhängig? Warum sollten nicht die Softwareentwickler unter Linux nicht den selben Crackschutz wie Softwareentwickler für Windows nutzen können? Also, ich denke, das das so ganz OK ist, denn so bekommen wir für dieses Projekt auch den einen oder anderen Linux-Coder (was ja nicht unbedingt schlecht wäre denn man will ja auch was dabei lernen :D) Wenn man das Ding richtig plant, ist es egal, welche Programmiersprache man nimmt oder welche Plattform. Die Grundstrukturen auf denen ein Proggi aufgebaut ist, sind immer die selben :) Falls das nicht mit der Platformunabhängigkeit klappen sollte, können wir´s ja später immernoch lassen, oder :D

[Diogenes]

Logisch. du meinst ja die mathematischen Verfahren und nicht einen Programmierstil, der sich auf eine Sprache oder eine Plattform bezieht.

Das sollte gehen.

[Patrik Graf]

Du hast es erfasst, Diogenes :))

[Diogenes]

Ich hab´ mich ein wenig mit Grafitty unterhalten (per Chat), was er eigentlich geschützt haben will. Es handelt sich dabei um den Code, und zwar während er im Speicher steht und ausgeführt wird. Das wird schwierig.

Meine 1. Idee wäre, ein (allerdings plattformabhängiges Run-time-Modul zu machen, das eine sehr, sehr, sehr unübersichtliche Scriptsprache (den Code) interpretiert. Auch wenn der wunde Punkt schon klar ist (das Modul), ist das vielleicht ein Ansatzpunkt.

[Patrik Graf]

Wäre eine Idee. Jetzt sieht meine Erweiterung der Idee so aus:

Damit die sehr sehr unübersichtliche Scriptsprache noch unübersichtlicher wird und noch schwerer zu lernen ist, empfehle ich, den Verschlüsselten Code als Scriptsprache zu nehmen. Das Runtime-Modul interpretiert diesen Code anhand des Keys. Damit die Scriptsprache trotzdem nicht geknackt werden kann, wird der Key vom Modul geändert, und zwar entweder beim starten oder beim beenden des Proggis. Als Privat-Key wird ein Teil des Codes verwendet. Aus dem wird dann der Public-Key errechnet. Das heißt das Proggi verändert sich ständig (sehr schwer dahinter zu kommen meiner Meinung nach). Das Prob is nur, das sich unser Proggi einen Key merken muß und die Frage ist, wie sich das Proggi den Key merkt. ?(

Eine Möglichkeit wäre hierbei, das der gemerkte Key auch irgentwo im Code abgelegt wird, und zwar an unterschiedlichen Stellen, aber dann weiß muß es auch wissen wo... Zwickmühle. :(

Denkt mal weiter... wem fällt was ein?

[nj0y]

Also von dem selbständernden Code halte ich ehrlich gesagt nicht allzu viel. Ich denke nicht, daß es einen zusätzlich Schutz bedeutet. Eher im Gegenteil, denn der Teil, der sich ständig ändert, ist dann besonders interessant.

Außerdem würde ich um nichts in der Welt den Private-Key mit in den Code reinpacken, dann kann ich nämlich auch gleich symmetrisch verschlüsseln.

Wie das ganze konkret ablaufen soll, daß es plattformübergreifend funktioniert, ist mir allerdings immer noch schleierhaft ;). Aber ich lasse ich da gerne belehren...

[Patrik Graf]

Das Runtime-Modul kümmert sich nur um die Verschlüsselung und Interpretation des Codes. Da das ganze zum Großteil auf Mathematik beruht, ist es egal, auf welcher Plattform oder mit welcher Programmiersprache es gecodet wird. Das einzigste was für die Plattformunabhängigkeit noch zu tu wäre ist, das Bisschen was aussenrum ist der Plattform anzupassen. Das ist aber nicht weiter schwierig (siehe Delphi und Kylix).

Aber mal zurück zum "sich selbständernden Code". Man könnte dem Softwareentwickler selbst die Changse geben sich seine Key´s zu erstellen. Da man ja ein Tool braucht, mit dem das Proggi dann verschlüsselt wird (unser Tool :D), könnte man sich doch an PGP ein Beispiel nehmen. So ist dann später nicht das Runtime-Modul dafür verantwortlich den Code zu ändern, sondern der, der sein Proggi verschlüsselt. So wird jedes Proggi anders Verschlüsselt und man kann diesen Vorgang nicht einfach so verfolgen... :D

Do you know what I mean, man... :D

[Patrik Graf]

Ok, ich habs. Der Entwickler kann, um das Proggi "uncrackbar" zu machen, sein Programm z.B. 100 mal verschieden verschlüsseln. Also hätte er 100 mal das selbe Prog, aber jedes anders verschlüsselt. Der Key ist dann die Serial. Wenn jetzt ein Cracker seine Kopie gecrackt hat und ein demensprechendes Proggi schreibt, können die anderen 99 Kopien nicht damit gecrackt werden :)) . Was meint ihr?

[MeltDown]

hi grafitty,

hört sich echt sehr interessant an; und wenn die verschlüsselung sagen wir mal mit RSA oder AES mit min. 128 oder sogar 256bit erfolgt, müsste der cracker sich schon sehr lange dranhalten.

JEDOCH müsste dass programm min. 2mal verschlüsselt werden, da nämlich bei 1mal verschlüsseln der Cracker dies sehr leicht (naja übertrieben) wieder entschlüsseln könnte. also min 2 mal um wirklich 99.999% warscheinlich auf uncrackbarkeit.

cya

[Patrik Graf]

@MeltDown:

Wunderbar, jetzt müßte man nur noch überlegen, wie man am besten das dazugehörige Runtime-Modul dazu bastelt... ?(

Dazu müßte man wissen, wer konkret Lust darauf hat da mitzubasteln, damit man sich absprechen kann, wer was coded.

Ich denke, 2 Wochen Bedenkzeit kann man da schon machen... :D

[MeltDown]

hi,

ich könnte dazu ein ActiveX DLL (mit VB) hinzusteuern, der die Verschlüsselung übernimmt.

cya

[Patrik Graf]

Wunderbar :D

Jetzt müßte man nur noch überlegen, welche Sprache wohl am besten dafür geeignet ist, die Entschlüsselung in einer Art Interpreter durchzuführen... :(

Ich denk mal ASM, aber ist wohl ziemlich aufwendig das in ASM zu coden...

Ich meine, das mit dem Interpreter ist deswegen notwendig, da man sonnst einfach ein Speicherabbild der entschlüsselten EXE auf die Platte speichern könnte. Wenn´s da nur noch ne andere Möglichkeit gäbe die auf jedem Betriebsystem läuft... ?(

Hat schonma jemand sowas wie einen Interpreter gecoded? Wär nicht schlecht wenn sich jemand melden würde.

[MeltDown]

wenn es auf jedem Betriebssystem laufen müsste, fällt auf jedenfall der ActiveX DLL von VB schonmal flach, da dieses nicht auf Linux, Mac usw.. laufen würde.

aber dass ist kein problem, dann werde ich das(den?) DLL in C++ coden.

Interpreter.... hmm.. denke wir sollten dass Baby dann auch in C++... denke da an Borland Builder coden... so mit richtig schöner GUI usw.. :D :D :D

Könntest du den Part übernehmen ?

cya

[nj0y]

Die DLL (Dynamic Link Library) ;).

Also wenn schon plattformübergreifend, dann aber bitte auch mit Kylix. Der BCB soll erst im Laufe des Jahres für Linux erscheinen.

Wofür eigentlich ne GUI? Für das Drumherum-Programm, das letztendlich die Verschlüsselung über das fertige Programm laufen läßt? Das könnte man ja notfalls auch erstmal als Konsolenanwendung programmieren in normalem C, ist dann automatisch auf allen Systemen lauffähig.

[MeltDown]

lol, also dann "die" :D :D

also dass(den?) GUI soll hat die Eingabe von dem Serial und dass ansteuern/steuern des dll´s übernehmen.

@Grafitty
komm mal in den chan damit wir die einzelheiten usw. besprechen können.

cya

[nj0y]

Also ich würde mich wehren, eine fremde GUI in meinen Programmen zu benutzen - Stichwort "einheitliche Oberfläche" ;). Also doch lieber ohne GUI...

[Patrik Graf]

Hmm... stimmt, warum eigentlich ein GUI...

Man könnte das System doch einfach in DLL´s ausliefern. Dann einfach noch ne Beschreibung dazu wie das Zeug einzubinden ist und fertig ist die Geschichte :D

Da sollte man ja fast eine Abstimmung machen...

[MeltDown]

jo, haste recht

[G'Ron]

mal ne frage jungst, wisst ihr was ihr macht?

es ist rein logisch garnicht möglich einen funktionierenden crackschutz zu programmieren, und in zeiten der GPL sollte die in meiner ich auch absolut kein thema sein.

Also zu eurem Schutz, egal wie ihr ihn verschlüsselt ob mit rsa oder sonst wie, um ein programm aus zu führen, muss der prozessor dieses in einem entschlüsselten zustand bekommen, soll heißen euer programm muss logischer weise immer die arbeit leisten, welche ihr dem cracker aufbrummen wollt.

Euer Programm muss den verschlüsselten krempel entschlüssel und irgenwo im speicher ablegen und? -> wow der cracker nimmt sich den code einfach aus dem speicher und interessiert sich überhaupt nicht mehr für das zeug was ihr da drum rum gestrickt hab.

So funktionier im übriegen auch savedisk und co, und die sind bis jetzt alle gecrackt worden.

Warum sollte sich der cracker die mühe machen, das zeug zu entschlüsseln euer programm erledigt das doch für ihn.

Vielleicht solltet ihr euch erstmal informieren wie man crackt, bevor ihr einen schutz entwickeln könnt, man muss den feind verstehen bevor man ihn besiegen kann.
Und diesen feind kann man nicht besiegen, weil es vollkommen unmöglich ist, ein programm zu sichern, da der rechner es schließlich ausführen können muss, und ein effektiver schutz wäre nur möglich, wenn das nicht möglich wäre ;-)

ich wollte euch einfach nur mal ein wenig zeigen, das so ein schutz nicht sinnvoll ist. ich empfehle euch entweder entsprechendes material zu cracken zu lesen, oder aber euer hier gesammeltes wissen zum verschlüssen, zu benutzen um vielleicht etwas sinnvolles zu schaffen.
Zwischen durch kann ich noch die GNU GPL empfehlen, das ist meiner Meinung nach die Zukunft der Informationsgesellschaft.

Gruß
Stefan

[Jan Krüger]

angenommen, es handelt sich um einen schutz für shareware, müsste man einen schutz so aufbauen, dass nur die teile, die in der eingeschränkten fassung nicht zur verfügung stehen, verschlüsselt werden und dass der freischaltungscode zur erstellung des keys zum entschlüsseln dringend benötigt wird.
aber auch das ist nicht sicher, denn es braucht sich nur ein cracker zu "opfern", das programm zu kaufen (oder bei einem freund, der es gekauft hat, zu analysieren), und schon kennt er den key zum entschlüsseln und kann auf jedem system (wir gehen mal davon aus, dass der code in abhängigkeit der hardwarekonfiguration, des usernamen und irgendeiner e-mail-adresse oder so berechnet wird) einen gültigen key erzeugen. oder einfach ein programm schreiben, das die verschlüsselten teile direkt durch unverschlüsselte ersetzt.

was die GPL angeht, ich stimme zu. alle software, die ich schreibe, wird unter der GPL veröffentlicht werden.

[Dominic Suter]

Nur dass es in der GPL einen Absatz hat, der besagt, dass die Software auch für kommerzielle Zwecke programmiert werden kann...
Ist eine (gute) Software unter der GPL prpgrammiert und kostet dennoch etwas, werden die Hacker schnell am Programm "basteln". Da ist ein Kopierschutz nur legitim...

[Jan Krüger]

software, die unter der GPL programmiert wurde, kann nichts kosten. es kann nur geld für die begleichung der kosten einer übertragung der daten verlangt werden, wenn solche nicht anfallen, bleibt die software komplett kostenlos. außerdem erlaubt die GPL jedem, der die software erhält, sie frei weiterzuverteilen.
bei kommerzieller verteilung der software *muss* der sourcecode mitgegeben werden.
fazit: kopierschutz bei GPL-software ist überflüssig.
nur die LGPL (Lesser General Public License) erlaubt das verkaufen von libraries, die unter deren bedingungen lizenziert sind. aber auch die dürfen dann im kompletten sourcecode weitergegeben werden.

recommended reading: http://www.gnu.org/licenses/gpl.html

[FireBird2002]

Der beste Schutz für Programme scheint immer noch das verstecken des Schutzes zu sein:

1. Man versteckt wichtige teile des Progs im VideoRAM
2. Man erzeugt scheinbar funktioniernde Serials (á la Eagle).
3. Bei Online-Progs könnte sich das Programm zu bestimmten Zeiten bei einem Server melden und zu diesem Seriennummer, spezielle Computerdaten(z.B. Serial bei Intel) und eine Prüfsumme des Progs versenden. Dort werd die ersten Beiden abgelegt und bei jedem Connect verglichen. Wenn diese Daten nicht übereinstimmen, wird das Programm unbrauchbar gemcht (vgl. Pkt. 2).

Das wäre aber schon fast schlimmer als Microsoft...

[K21]

Original geschrieben von FireBird2002
Das wäre aber schon fast schlimmer als Microsoft...

... und vor allem würde es eine internetconnection voraussetzen... denn sonst wäre der schutz wieder zunichte (eine firewall würde ihn auch schon zu nichte machen)

[Jan Krüger]

Nebenbei - die Verbindung ins Internet fängt die Firewall ab und macht Logfiles davon, und dann ist es nur eine Frage von Sekunden, bis der Cracker den Code zum Remote Check aus dem Programm entfernt hat.
Außerdem könnte man einfach Breakpoints auf die Winsock-API-Routinen setzen... ein Crackschutz, der den Winsock-Level umgeht, dürfte extrem umfangreich werden und einen ziemlich hohen Verwaltungsaufwand verursachen.

[Schaf]

btw, eine linux-portierung könnt ihr euch sparen, da will niemand von den linux-usern was wissen - für jede software gibts unter linux ein opensource-pendant.
[eigenemeinung]im allgemeinen ist es irgendwie schon fast sowas wie eine frechheit, unser schönes, freies linux mit kommerzieller software, die einen crackschutz hat, zu belegen :eek::(;)

[brainbug]

Finde auch jeder schutz lässt sich irgendwie überlisten. Vor allem ist ein interpreter immer lahm, was soll dann geschützt werden? spiele? denke enfällt weil interpreter zu lahm. große softwarepakete? ist ja auch unsinn sowas wie z.B. word über n interpreter laufen zu lassen.
Der beste kopierschutz ist immernoch es kostenlos zu verteilen ;-)

die einzige eventuelle möglichkeit sehe ich darin, dass ein programm nur laufen kann wenn eine internetverbindung zu einem server steht, über den ein ständig wechselndes set aus schlüsseln ausgetauscht, die zb auf der mac-adresse und diversen anderen daten basieren. aber hat ja net jeder nen dsl-flat anschluss, also auchnix für die nahe zukunft.. ;)

ps: je aufwendiger und sicherer ein schutz ist, desto mehr ansporn gibt es den hackern ihn zu knacken ;-)

[Jan Krüger]

Das mit der Internetverbindung bringt nichts, solange man den Code mit einem Kerneldebugger tracen und dann von Hand entfernen kann. Nur Schutzmechanismen, die in der Hardware verankert sind, sind sicher (und müssen es auch nicht unbedingt sein - ich habe schon höchstselbst einen Dongle-Schutz von einem Programm innerhalb von ca. 10 Minuten entfernt ;)).

[cYrus]

die einzige sichere methode ist/wäre TCPA bzw. NGSCB :)

und was haltet ihr davon?! :p also vergesst gleich den ganzen crackschutz & co. ;)

[Jan Krüger]

Stimmt, NGSCB wäre eine Lösung. Wir dürfen gespannt sein, wie sich das in der Praxis bewährt. :)