.NET-Code vor Reverse Engineering schützen?


491

Die Verschleierung ist eine Möglichkeit, kann jedoch nicht vor einer Beeinträchtigung der Piraterieschutzsicherheit der Anwendung schützen. Wie stelle ich sicher, dass die Anwendung nicht manipuliert wird, und wie stelle ich sicher, dass der Registrierungsmechanismus nicht rückentwickelt werden kann?

Es ist auch möglich, eine C # -Anwendung in nativen Code zu konvertieren, und Xenocode ist zu kostspielig.

C # bietet viele Funktionen und ist die ideale Sprache für meinen Code. Daher kommt es nicht in Frage, die gesamte Codebasis erneut in C ++ zu schreiben.

Sichere Zertifikate können einfach aus den signierten Assemblys in .NET entfernt werden.



@Andreas: Das ist großartig !! Ich werde es versuchen. Wer benutzt es?
Jack

1
@ Jack ist nur für Windows Store-Apps. Es gibt keine Zeitleiste für Desktop-Apps (soweit ich das beurteilen kann).
Tyler Long

Wenn Sie native ohne archaisches C ++ möchten, verwenden Sie Delphi. Die Leichtigkeit von .Net kam sowieso von Delphi.
William Egge

Antworten:


671

Das kannst du nicht.

Es gibt Schritte, die Sie unternehmen können, um es etwas schwieriger zu machen , aber letztendlich ist jede ausführbare Datei auf dem lokalen Computer knackbar. Schließlich muss dieser Code in nativen Maschinencode konvertiert werden, und jede ausführbare Anwendung ist anfällig.

Was Sie tun möchten, ist, es nur so schwierig zu machen, es zu knacken, dass es die Mühe der Menschen nicht wert ist.

Einige Vorschläge, die ich für Sie habe, um Ihre Anwendung zu schützen:

  • Verschleiern Sie Ihren Code. Dotfuscator hat eine kostenlose Edition und wird mit Visual Studio geliefert .
  • Verwenden Sie einen öffentlichen / privaten Schlüssel oder eine asymmetrische Verschlüsselung , um Ihre Produktlizenzen zu generieren. Dies stellt sicher, dass nur Sie Ihre Lizenzcodes generieren können. Selbst wenn Ihre Anwendung ist geknackt, können Sie sicher sein , dass sie nicht einen Schlüsselgenerator für Ihre Anwendung veröffentlichen, weil es unmöglich ist , den Schlüsselerzeugungsalgorithmus zu umkehren.
  • Verwenden Sie einen Packer eines Drittanbieters, um Ihre ausführbare .NET-Datei in eine verschlüsselte Win32-Wrapper-Anwendung zu packen. Themida ist eine der besseren. Dies verhindert, dass Benutzer Ihre Anwendung in .NET Reflector wiedergeben, und macht das Auspacken zum Umkehren zum Problem.
  • Schreiben Sie Ihren eigenen Packer . Wenn die Packer von Drittanbietern zu teuer sind, sollten Sie Ihre eigenen schreiben. Manchmal können benutzerdefinierte Packer sehr effektiv sein, da es keine gut veröffentlichten Methoden zum Entpacken gibt. Das Tutorial Wie Sie Ihren eigenen Packer schreiben, bietet eine Menge guter Informationen zum Schreiben Ihres eigenen Win32-Packers.

Letztendlich aber, wenn Leute wollen, dass Ihre Anwendung geknackt wird, werden sie es tun. Schauen Sie sich die gesamte kommerzielle Software an, die über eine Vielzahl von Ressourcen verfügt, um ihre Anwendungen zu schützen, und die dennoch geknackt sind, bevor die Anwendungen überhaupt für die Öffentlichkeit freigegeben werden.

Ein erfahrener Reverse Engineer kann IDA-Pro starten und Ihre Anwendung wie Butter durchschneiden, egal was Sie tun. Eine gepackte Anwendung kann ausgepackt werden, und die Verschleierung verhindert nur, dass sie im Park spazieren geht. All Ihre harte Arbeit mit Ihrem komplexen Lizenzcode kann mit einem einzigen Byte-Patch rückgängig gemacht werden.

Sie müssen nur akzeptieren, dass es eine sehr reale Chance gibt, dass Leute Ihre Software raubkopieren. Es gibt einige Leute, die niemals für Ihre Bewerbung bezahlen werden, egal was passiert, und dies sind die Leute, um die Sie sich keine Sorgen machen müssen.

Es gibt jedoch viele Unternehmen, die niemals eine Klage riskieren und gerne Softwarelizenzen kaufen würden, und viele Computerbenutzer, die es entweder nicht riskieren wollen, es falsch finden oder nicht technisch versiert genug sind, um zu raubkopieren. Dies sind Ihre wahren Kunden, und Sie sollten sich darauf konzentrieren, ihnen eine gute Benutzererfahrung zu bieten und die Leute zu ignorieren, die Ihre Software knacken.

Ich habe meine Bewerbung schon einmal raubkopieren lassen und sie als persönliche Beleidigung angesehen. Hier war ich, ein kleiner Entwickler, der mein Herz und meine Seele in eine Anwendung gesteckt hat und diese Leute hatten die Galle, von mir zu raubkopieren?! Sie nahmen Geld direkt aus meiner Tasche!

Ich fügte sofort einen Haufen drakonischen DRM-Codes hinzu und versuchte, jede Person mit einer illegitimen oder geknackten Kopie zu sabotieren. Ich hätte natürlich daran arbeiten sollen, meine Anwendung zu verbessern, anstatt zu versuchen, das Unvermeidliche zu stoppen. Nicht nur das, sondern ich habe meine wahren Kunden verletzt , all diese zusätzlichen Schutzmaßnahmen, die ich ergriffen habe.

Nach einem langen Kampf wurde mir klar, dass ich gegen die Gezeiten kämpfte und die ganze Zeit, die ich verschwendete, umsonst war. Ich habe den gesamten Telefon-Home-Code mit Ausnahme der Barebone-Lizenzfunktionen herausgenommen und nie zurückgeschaut.


67
Also +1, dass es fast +2 ist. Ich wünschte, mehr Leute würden endlich erfahren, dass Sie Ihre Software einfach nicht vor einem entschlossenen Angreifer schützen können.
Bombe

102
Sie haben das Nirvana des Softwareschutzes erreicht: Es geht nicht darum, mehr Schutz hinzuzufügen, sondern sich auf das Produkt zu konzentrieren und es so gut zu machen, dass die Leute dafür bezahlen möchten. Und für diejenigen, die es raubkopieren, hätten sie sowieso nie bezahlt, so als ob sie nie existiert hätten.
Arthur Chaparyan

6
@ Arthur Chaparyan, ich stimme zu. Es hat lange gedauert, bis ich hier war, aber ich habe endlich das Licht gesehen. Ich ging den Weg des restriktiveren Schutzes und des Kampfes gegen die Cracker. Ich habe alles über Reverse Engineering gelernt, um mein eigenes zu verhindern. Ich habe endlich die richtige Ideologie herausgefunden
mmcdole

50
Zur Hölle, ich hätte mich geehrt
Erik Forbes

10
Wenn Sie sich für einen Großteil Ihres Einkommens auf den Verkauf Ihrer Software verlassen, ändert sich etwas. Es fühlt sich an, als würde jemand von dir stehlen. Ich verstehe, was du sagst. Ich war schockiert, als ich auf Torrent-Sites zum ersten Mal Risse für meine Software fand.
mmcdole

265

Sie können keine Anwendung (verwaltet oder nicht) vollständig sichern. Welche Hoffnung hat Ihre App, wenn Systeme wie die Playstation und das iPad geknackt werden können - wo der Anbieter sogar die Hardware steuert? Zum Glück willst du nicht wirklich. Meiner Meinung nach müssen Sie Ihre Anwendung gerade so sichern, dass jemand Ihr Produkt nicht versehentlich raubkopieren kann, und nicht mehr.

Wenn Sie beispielsweise eine Lizenz pro Computer verwenden, sollte diese nicht nur funktionieren, wenn Sie sie auf einem neuen zweiten Computer installieren. Sie möchten eine gute Fehlermeldung, um zusätzliche Supportanrufe zu vermeiden, aber verbringen Sie keine zusätzliche Zeit damit, das Umgehen zu erschweren und Benutzer nicht über den Kopf zu schlagen.

Ein weiteres Beispiel ist ein zeitlich begrenzter Versuch. Machen Sie sich nicht einmal Gedanken über einfache Dinge, z. B. wenn Benutzer die Systemuhr einfach zurücksetzen können. Jemand, der das tut, weiß, dass er Ihre Lizenz bricht, und solange ein Benutzer weiß, wenn er gegen die Bestimmungen verstößt, haben Sie genug getan.

Sie müssen so viel tun, da sich Benutzer nicht um Ihre Lizenz kümmern. Lizenzen sind erfundene Dinge, die niemanden interessieren, bis sie es brauchen. Niemand liest sie und sie sollten es wirklich nicht müssen. Daher können Sie dem Benutzer am besten mitteilen, wo sich die Grenzen befinden, wenn das sofort einsatzbereite Verhalten Ihrer Anwendung mit der Lizenz übereinstimmt. In diesem ersten Fall bedeutet dies, dass entweder die Installation fehlschlägt oder das zweite Mal im Testversionsmodus installiert wird. Für letztere bedeutet dies möglicherweise nur die Überprüfung eines Nur-Text-Datums in einer Konfigurationsdatei. Stellen Sie in jedem Fall sicher, dass Sie elegant, hilfsbereit und respektvoll damit umgehen.

Das erklärt also, was es bedeutet, genau so viel zu tun. Aber warum nicht noch weiter gehen? Warum nicht jedes kleine Loch verstopfen, das Sie finden können? Die Antwort besteht aus zwei Teilen. Erstens, wenn jemand die ethische Schwelle überschreitet , Ihre Lizenzbedingungen bewusst zu brechen - auch auf einfache Weise -, ist er auch bereit, etwas Schwierigeres oder Gefährlicheres zu tun, z. B. Ihre Anwendung aus einem Torrent zu ziehenSite - und es besteht eine gewisse Gefahr, Anwendungen auszuführen, die von nicht vertrauenswürdigen Quellen heruntergeladen wurden. Es schwieriger zu machen, ist für diese Benutzer nur ein kleiner Ärger und birgt das Risiko, Probleme mit Ihren zahlenden Kunden zu verursachen. Wenn Sie es einfach halten, kann dies verhindern, dass sich jemand in Ihre Anwendung vertieft und einen umfassenderen Riss freigibt. Zweitens haben Sie nur wenige Augen, um nach Fehlern zu suchen. Die Hacker haben viele und sie haben mehr Übung darin, sie zu finden. Sie müssen nur einen kleinen Fehler übersehen, und Ihre App wird auf Piratenseiten dieselbe Verteilung haben, als hätten Sie nichts getan. Du musst jedes Mal Recht haben; Sie müssen nur einmal Glück haben. Der Aufwand ist also sehr hoch und die Wahrscheinlichkeit eines Erfolgsmaßes sehr gering.

Letztendlich, wenn jemand will Piraten Ihre Anwendung (im Gegensatz zu nur es verwendet wird ), und das ist ihr Hauptziel, das werden sie. Sie können nichts tun, um sie aufzuhalten. Dies ist die Natur der Software; Sobald sich die Dateien, aus denen Ihr Produkt besteht, auf dem Computer eines Benutzers befinden, können diese nach Belieben damit arbeiten. Dies ist besonders in verwalteten Umgebungen wie Java oder .NET relevant , gilt aber definitiv auch für nativen Code. Die Zeit ist auf ihrer Seite, und wenn genügend Zeit zur Verfügung steht, kann jede digitale Sicherheit zerstört werden.

Da Sie Benutzer nicht davon abhalten können, Ihr Produkt zu raubkopieren, besteht Ihre beste Vorgehensweise darin, diese Benutzerklasse so einzubeziehen, dass sie zu Ihrem Vorteil verwendet wird. Es ist oft möglich, dass sie für Sie arbeiten und nicht gegen Sie. In diesem Sinne lohnt es sich wahrscheinlich, unabhängig von Ihrer Anwendung eine kostenlose Version beizubehalten, die fast vollständig funktionsfähig ist und nicht abläuft. Der Unterschied zwischen einem Preis von 1 US-Dollar und einem kostenlosen Preis ist enorm, wenn der Kunde Ihnen aus keinem anderen Grund seine Kreditkarte anvertrauen muss. Eine kostenlose Version Ihres Produkts wird nicht nur die Raubkopien-Distribution effektiv töten (warum sollten Sie eine Raubkopien-Version riskieren, wenn Sie für denselben Preis legitim sein können?), Sondern auch das Potenzial haben, Ihr Publikum dramatisch zu erweitern.

Das Ergebnis ist, dass Sie möglicherweise den Preis für die kostenpflichtige Edition erhöhen müssen, sodass Sie am Ende anstelle von 2.000 Benutzern zu je 20 US-Dollar 100.000 kostenlose Benutzer haben, von denen 500 bereit sind, 99 US-Dollar für die "professionelle" Edition zu zahlen . Dies bringt Ihnen mehr Geld ein, als wenn Sie eine Menge Zeit damit verbracht hätten, Ihr Produkt einzusperren. Darüber hinaus können Sie diese kostenlosen Benutzer einbeziehen und die Beziehung auf verschiedene wichtige Arten nutzen.

Eines ist die Unterstützung. Ein Pessimist würde diese Gelegenheit nutzen, um sich über die gestiegenen Kosten für die Unterstützung von 100.000 kostenlosen Benutzern zu beschweren, aber stattdessen passiert etwas Erstaunliches: Ihr Produkt wird weitgehend selbsttragend. Sie sehen dies ständig bei großen Open-Source-Projekten, bei denen kein Geld für Supportkosten anfällt. Benutzer werden sich steigern und es möglich machen.

Kostenlose Benutzer haben im Allgemeinen aus gutem Grund zunächst geringere Support-Erwartungen. Alles, was Sie tun müssen, ist, die kostenlose Edition als nur für den Community-Support qualifiziert zu markieren und zu diesem Zweck ein benutzermoderiertes Online-Forum einzurichten. Ihre Support-Wissensdatenbank generiert sich selbst, und fortgeschrittene Benutzer werden diejenigen unterstützen, die in Ihrem Namen zusätzliche Handhaltung benötigen. Noch wichtiger ist, dass Sie so Fehler schneller identifizieren und beheben können, was letztendlich die Qualität Ihres Produkts verbessert und die gesamten Supportkosten senkt. Dies war vorher nicht möglich, da Ihre Benutzerbasis nicht groß genug war, aber wenn Sie die kostenlosen Benutzer als Kunden behandeln, kann dies sehr gut funktionieren.

Ein weiterer Grund ist das Feedback. Wenn Sie sich Ihr Forum ansehen, lernen Sie wichtige Verbesserungsvorschläge kennen, die Sie möglicherweise nie anders in Betracht gezogen haben. Auf diese Weise können Sie letztendlich mehr Ihrer kostenlosen Benutzer in bezahlte Benutzer verwandeln und ein überzeugenderes Produkt erstellen, das ein noch größeres Publikum anzieht.

Schließlich müssen Sie Marketing in Betracht ziehen. Alle diese kostenlosen Benutzer sind jetzt eher Fans als Gegner und werden entsprechend handeln. Nicht nur das, aber wenn es Zeit ist, Ihre nächste Version zu veröffentlichen, haben diese Benutzer alle Ihren genehmigten Vertriebskanal durchlaufen und nicht irgendeinen anderen unbekannten Mechanismus. Das bedeutet, dass Sie für Ihre nächste Version zunächst mit einem größeren, hochinteressierten und unterstützenden Publikum in Verbindung stehen.

Die besten Funktionen, die für die Professional Edition reserviert werden können, sind Tools, die die Bereitstellung und Verwaltung von Unternehmen vereinfachen sollen. Ein Cracker wird dies nicht als zwingenden Grund ansehen, es für seinen eigenen Gebrauch zu hacken, aber für ein Unternehmen, das 300 Lizenzen kaufen und unternehmensweit veröffentlichen möchte, ist dies ein Muss. Natürlich wird die Professional Edition sowieso raubkopiert, aber noch einmal: Schwitzen Sie nicht, denn Sie könnten das Produkt wahrscheinlich nicht an diese Piraten verkaufen, egal was Sie getan haben, also kostet es Sie keinen Umsatz.

Obwohl es psychologisch schwierig sein kann, Ihr Produkt so oft zu verschenken, können Sie hoffentlich verstehen, wie es wirklich der beste Weg ist. Nicht nur das, es ist der einzige Weg, um langfristig zu gehen. Ich weiß, dass jemand da draußen denkt, dass er es nicht so machen will. Immerhin haben sie es geschafft, ihr gesperrtes 20-Dollar-Produkt jahrelang gut zu verkaufen. Aber das ist einfach zu schade, denn wenn Sie es nicht so machen, wird es irgendwann jemand anderes tun . Und ihr Produkt wird genauso gut sein wie deins oder nah genug dran sein, dass sie das behaupten können. Dann sieht Ihre Preisgestaltung plötzlich unverschämt aus, der Umsatz sinkt dramatisch und Sie können nichts mehr tun. Sie können sich für eine zusätzliche mittlere Stufe entscheiden, wenn Sie müssen, aber es ist unwahrscheinlich, dass es Ihnen hilft.


1
@Learning: Es ist mit der Zeit gewachsen und hat die automatische Konvertierung in den CW-Schwellenwert überschritten.
Joel Coehoorn

1
+1 Besser als die Antwort, die ich auf die vorherige Version dieser Frage gegeben habe. @ Joel Wusste nicht, dass es ein Limit gibt.
pipTheGeek

1
Ich bin hier nicht mit allem einverstanden, und es ist sowieso eine einfache +1 für die äußerst gut durchdachte Präsentation und Argumentation.
Beska

2
Gutes Argument, aber es fehlt ein Punkt zum Schutz des geistigen Eigentums. Wenn Ihre App über Code verfügt, der etwas Komplexes bewirkt, kann die Verschleierung den Unterschied zwischen dem vollständigen Kopieren und Einfügen von Code und dem Versuch, Code so zu interpretieren und neu zu konstruieren, dass er funktioniert, ausmachen. Dies ist besonders wichtig bei Updates: Wenn jemand Ihren verschleierten Code kopiert hat und ein Update veröffentlicht, muss er dies erneut tun - und dies verursacht zumindest mehr Schmerzen / Kosten / Zeit. Wenn Sie es nicht auf irgendeine Weise geschützt haben, kopieren / fügen Sie es einfach erneut ein und es funktioniert.
Gregmac

4
Toller Beitrag - es geht wirklich um die richtigen Details zu den Gründen, warum es sich nicht lohnt, einen komplexen Kopierschutz zu schreiben. Obwohl es sich bei der Frage um ein Duplikat handelt, lohnt es sich, sie nur für diese Antwort erneut zu öffnen. Vielleicht kann ein Mod es zusammenführen?
EMP

45

Nach meiner Erfahrung schadet es Ihren ehrlichen Kunden, Ihre Anwendung oder Bibliothek schwieriger zu knacken, während die unehrlichen nur geringfügig verzögert werden. Konzentrieren Sie sich darauf, ein großartiges Produkt mit geringer Reibung herzustellen, anstatt große Anstrengungen zu unternehmen, um das Unvermeidliche zu verzögern.


38

Ein Geheimnis, das Sie mit vielen Menschen teilen, ist kein Geheimnis. Wenn Ihr Code geheime Inhalte enthält, ist die Verschleierung kein Schutz. es muss nur einmal deobfusciert werden . Wenn Sie ein Geheimnis haben, das Sie nicht mit Ihren Kunden teilen möchten, teilen Sie es nicht mit Ihren Kunden . Schreiben Sie Ihren Code als Webdienst und bewahren Sie Ihren Super-Geheimcode auf Ihrem eigenen Server auf, wo nur Sie ihn sehen können.


1
Übrigens mache ich ein Projekt, in dem ich ein Produkt auch "offline" aktivieren möchte (ich habe einen WCF-Dienst erstellt, um es online zu aktivieren). In diesem Fall, wie werden Sie Code manipulieren? Kannst du mir ein paar Treffer geben?
Piyush

1
Interessante Idee, aber welche Vorgehensweise würden Sie jemandem empfehlen, der eine Anwendung entwickelt, die ohne Datenverbindung ausgeführt werden muss, z. B. ein WP7-Spiel?
Charlie Skilbeck

23

Im Großen und Ganzen gibt es drei Gruppen von Menschen da draußen.

  • Diejenigen, die Ihre Software nicht kaufen und auf Risse zurückgreifen oder keine finden, verwenden Ihre Software überhaupt nicht. Erwarten Sie nicht, mit dieser Gruppe Geld zu verdienen. Sie verlassen sich entweder auf ihre eigenen Fähigkeiten oder auf Cracker (die ihre Zeit in der Regel nach Ihrem Nutzen und der Größe Ihres Publikums priorisieren. Je nützlicher, desto eher wird ein Crack verfügbar sein).

  • Die Gruppe legitimer Benutzer, die Ihre Software kaufen (bezahlen), unabhängig davon, welchen Schutzmechanismus Sie verwenden. Machen Sie Ihren legitimen Benutzern das Leben nicht schwer, indem Sie einen ausgeklügelten Schutzmechanismus verwenden, da sie auf jeden Fall dafür bezahlen werden. Ein komplexer Schutzmechanismus kann die Benutzererfahrung leicht beeinträchtigen, und Sie möchten nicht, dass dies dieser Gruppe passiert. Persönlich würde ich gegen jede Hardwarelösung stimmen, was die Kosten Ihrer Software erhöht.

  • Eine Minderheit, die auf "unethisches" Cracken zurückgreift und nur für Ihre Software bezahlt, weil ihre Funktionen durch einen Lizenzierungsmechanismus geschützt sind. Sie möchten es dieser Gruppe wahrscheinlich nicht besonders leicht machen, Ihren Schutz zu umgehen. Der Aufwand für den Schutz Ihrer Software zahlt sich jedoch aus, je nachdem, wie groß diese Personengruppe ist. Dies hängt ganz von der Art der Software ab, die Sie erstellen.

Wenn Sie der Meinung sind, dass es eine ausreichend große Minderheit gibt, die zum Kauf Ihrer Software gezwungen werden kann, sollten Sie eine Form des Schutzes implementieren. Überlegen Sie, wie viel Geld Sie mit dieser Minderheit verdienen können, verglichen mit der Zeit, die Sie für die Arbeit am Schutz aufwenden, oder dem Betrag, den Sie für eine Schutz-API / ein Tool eines Drittanbieters ausgeben.

Wenn Sie eine eigene Lösung implementieren möchten, ist die Verwendung der Kryptografie mit öffentlichem Schlüssel eine gute Möglichkeit (im Gegensatz zu symmetrischen Algorithmen), um einfache Hacks zu verhindern. Sie können beispielsweise Ihre Lizenz digital signieren (Seriennummer oder Lizenzdatei). Die einzige Möglichkeit, dies zu umgehen, besteht darin, den Code zu dekompilieren, zu ändern und neu zu kompilieren (was Sie mit Techniken wie den in Simucals Antwort vorgeschlagenen erschweren könnten).


Die Verwendung einer starken Kryptografie zum Schutz / zur Überprüfung Ihrer Lizenzen ist völlig nutzlos, wenn jemand den Code herausreißt, der die Anwendung abbricht, wenn die Lizenz nicht ausgecheckt wird. :)
Bombe

Einverstanden, aber wie gesagt, der Schutz gilt nicht für Benutzergruppen, die auf die Verwendung von Rissen zurückgreifen (eine von mir getroffene Annahme wird existieren).
Mystic

Kryptographie mit öffentlichem Schlüssel = asymmetrische Kryptographie. Ich denke du meintest symmetrisch.
mmcdole

1
Um fair zu sein, ist der dritte Punkt voreingenommen, da davon ausgegangen wird, dass ein Teil der Menschen immer eine Minderheit ist. Ich bin mir ziemlich sicher, dass es unter bestimmten Rahmenbedingungen eine klare Mehrheit ist. Ich habe Online-Spiele mit massiven Multiplayer-Funktionen im Auge, weil a) die meisten Benutzer Kinder mit sehr niedrigen ethischen Standards sind, b) die Kosten für diese Benutzer erheblich sein können, wenn es sich um eine monatliche Gebühr handelt, die sich über Monate
hinzieht

19

Sie können nicht verhindern, dass Leute Ihre Software knacken.

Sie können sie jedoch dazu bringen, Risse zu erzeugen, die Ihren Umsatz weniger beeinträchtigen. Schlüsselgeneratoren, die einen gültigen Registrierungscode für Ihre Software ausgeben können, sind viel schlechter als einfache Patches, mit denen Registrierungsanreize aus Ihrer Software entfernt werden. Dies liegt daran, dass ein Crack nur für eine Softwareversion funktioniert und mit dem nächsten von Ihnen veröffentlichten Software-Update nicht mehr funktioniert. Der Schlüsselgenerator funktioniert so lange, bis Sie Ihren Registrierungsschlüsselalgorithmus ändern. Dies möchten Sie nicht oft tun, da dies Ihre ehrlichen Kunden abschreckt.

Wenn Sie also nach einer Methode suchen, um illegale Schlüsselgeneratoren für Ihre Software zu bekämpfen, und aufgrund der langen Registrierungscodes, die dadurch generiert werden, keine assymetrische Verschlüsselung verwenden möchten, sollten Sie sich die Teilschlüsselüberprüfung ansehen.

Durch die teilweise Schlüsselüberprüfung wird sichergestellt, dass jeder illegale Schlüsselgenerator nur für eine bestimmte Version Ihrer Software funktioniert. Grundsätzlich müssen Sie sicherstellen, dass jede Version Ihrer Software nur mit dem Code verknüpft ist, um einige Ziffern des Registrierungscodes zu überprüfen. Welche Ziffern genau zufällig sind, müssen Cracker viele verschiedene Versionen Ihrer Software zurückentwickeln und all dies in einem Schlüsselgenerator kombinieren, um einen Schlüsselgenerator freizugeben, der für alle Versionen Ihrer Software funktioniert.

Wenn Sie regelmäßig neue Softwareversionen veröffentlichen, führt dies zu zahlreichen Schlüsselgeneratoren, die auf alle Arten von Softwarepiraterie-Archiven verteilt sind, die nicht mehr funktionieren. Potenzielle Softwarepiraten suchen normalerweise nach einem Crack oder Keygen für die neueste Version, daher werden sie wahrscheinlich einige davon ausprobieren und schließlich aufgeben.

Ich habe die Teilschlüsselüberprüfung in meinen (C ++) neueren Shareware-Spielen verwendet und sie war sehr effektiv. Vorher hatten wir viele Probleme mit Schlüsselgeneratoren, die wir nicht bekämpfen konnten. Danach gab es viele Risse und einige wenige Schlüsselgeneratoren, die nur für diese bestimmte Version des Spiels funktionierten, aber keinen Schlüsselgenerator, der mit allen Versionen funktionieren würde. Wir haben regelmäßig sehr kleine Updates des Spiels veröffentlicht, um alle zuvor vorhandenen Risse unbrauchbar zu machen.

Es scheint ein Open-Source- .NET-Framework für die teilweise Schlüsselüberprüfung zu geben , obwohl ich es nicht ausprobiert habe.


1
Wie die Idee können Sie auch verschiedene Passwörter für die assymetrische Verschlüsselung in verschiedenen Releases verwenden.
Priyank Bolia

Interessante Idee, aber was genau ist das Problem mit einem langen Registrierungscode überhaupt? Heutzutage würde es sowieso niemand mehr von Hand eingeben - jeder würde es kopieren und einfügen. Ob es nun 10 Zeichen oder 100 Zeichen sind, sollte keinen Unterschied machen.
EMP

4
@Evgeny: Das stimmt nur, wenn Ihre Benutzer Power-User sind. Wir entwickeln seit vielen Jahren Shareware / Casual Games und ich kann Ihnen sagen, dass die meisten unserer Benutzer nicht kopieren und einfügen können. Das Registrierungsfenster enthält sogar ein Handbuch zum Kopieren und Einfügen, und einige tun es sogar nicht, nachdem sie es gelesen haben.
Adrian Grigore

Beeindruckend! OK, nun, Sie haben offensichtlich mehr Erfahrung als ich, also kann ich nicht streiten, ich kann nur sagen, dass ich überrascht bin. Aber ich würde sagen, wenn sie nicht wissen, wie man kopiert und einfügt, sollten Sie den Code 200 Zeichen lang machen, damit sie eine äußerst nützliche allgemeine Computerkenntnis erlernen. :)
EMP

1
@Evgeny: Selbst mit den kurzen Registrierungscodes haben wir immer noch viele E-Mails von Leuten erhalten, die ihre Codes falsch eingegeben haben und daher dachten, dass der Code nicht gültig sein kann, weil sie niemals einen solchen Fehler mehrmals in a machen würden Reihe. Ich überlasse den IT-Unterricht lieber anderen Unternehmen ... :-)
Adrian Grigore

16
  • Verwenden Sie das Online-Update, um diese nicht lizenzierten Kopien zu blockieren.

  • Überprüfen Sie die Seriennummer von verschiedenen Modulen Ihrer Anwendung und verwenden Sie keinen einzigen Funktionsaufruf, um die Überprüfung durchzuführen (damit Cracker die Überprüfung nicht einfach umgehen können).

  • Überprüfen Sie nicht nur die Seriennummer beim Start, überprüfen Sie sie beim Speichern der Daten, sondern jeden Freitagabend, wenn der Benutzer inaktiv ist ...

  • Überprüfen Sie die Prüfsumme der Anwendungsdatei und speichern Sie Ihre Sicherheitsprüfungssumme an verschiedenen Orten.

  • Gehen Sie bei solchen Tricks nicht zu weit. Stellen Sie sicher, dass Ihre Anwendung niemals abstürzt oder in eine Fehlfunktion gerät, während Sie den Registrierungscode überprüfen.

  • Das Erstellen einer nützlichen App für Benutzer ist viel wichtiger als das Erstellen einer
    unzerbrechlichen Binärdatei für Cracker.


14

Du kannst..

Microsoft SLP-Dienste Das Software-Potenzial von InishTech bietet die Möglichkeit, Code zu schützen, ohne die Funktionalität Ihrer Anwendungen zu beeinträchtigen.

UPDATE: (Offenlegung: Ich arbeite an Eazfuscator.NET) Was das Potenzial der Microsoft SLP Services- Software unterscheidet, ist die Möglichkeit, den Code zu virtualisieren, sodass Sie dies definitiv können . Mehrere Jahre sind vergangen, seit die Frage ursprünglich gestellt wurde; Heute gibt es mehr Produkte, die ebenfalls auf einer ähnlichen Basis funktionieren, wie zum Beispiel:


2
Preis mein Freund, Kauf einer
Lizenzsoftware

Ich habe es versucht, es funktioniert sehr gut, aber es verschlüsselt nur den Code innerhalb einer Methode, nicht der gesamten Assembly oder des gesamten Projekts, so dass ein Cracker den Programmfluss mit IL-Injektion leicht ändern kann
Mohsen Afshin

@ogggre Wenn Sie Lieferantenlinks hinzufügen, müssen Sie Ihre Verbindungen wirklich in der Post offenlegen. Auch die derzeit verfügbare Version von SLPS (an der ich arbeite: D) unterstützt Generika. Natürlich haben alle Lösungen ihre individuellen Vor- und Nachteile, die nur eine Bewertung für Menschen richtig kontextualisieren kann
Ruben Bartelink

@MohsenAfshin Ich verstehe nicht, was Sie sagen - der Punkt ist, dass Sie alle Methoden schützen müssen, bei denen das Hinzufügen / Entfernen / Ändern von IL eine Lizenzverletzung darstellen würde. Da die Virtualisierung von Dingen nicht kostenlos sein kann, ist es einfach nicht sinnvoll, "alles auf magische Weise zu schützen", wie Sie vorschlagen. Zurück zum entscheidenden Punkt: Das Ziel des SP-Schutzes besteht darin, IL-Änderungen bei Methoden zu verhindern, die Sie aufgrund ihrer Empfindlichkeit auswählen (und im Allgemeinen einige andere als Rauschen, um das Pflanzen zu vermeiden. Sie müssen dieses Bit hier knacken -> Zeichen )
Ruben Bartelink

1
@ RubenBartelink Ich stimme dir zu. Leider ist dieser Thread mit mehreren Inhaltsseiten viel zu groß. Zuerst wollte ich eine neue Antwort hinzufügen, aber StackOverflow schlug vor, dass es besser ist, die vorhandene zu erweitern. So tat ich. Hoffe, meine kleine Information ist nützlich. Vielen Dank für ein Update zur allgemeinen Unterstützung in SLPS und Ihre Korrekturen.
Ogggre

10

.NET Reflector kann nur "verwalteten Code" öffnen, was im Grunde ".NET-Code" bedeutet. Sie können es also nicht zum Zerlegen von COM-DLL-Dateien, nativem C ++, klassischem Visual Basic 6.0- Code usw. verwenden. Die Struktur des kompilierten .NET-Codes macht es sehr bequem, portabel, erkennbar, überprüfbar usw. .NET Reflector nutzt dies aus Auf diese Weise können Sie in kompilierte Assemblys blicken, aber Dekompilierer und Disassembler sind keineswegs spezifisch für .NET und gibt es schon so lange wie Compiler.

Sie können Verschleierer verwenden, um das Lesen des Codes zu erschweren, aber Sie können nicht genau verhindern, dass er dekompiliert wird, ohne ihn auch für .NET unlesbar zu machen. Es gibt eine Handvoll Produkte (normalerweise teuer), die behaupten, Ihre verwaltete Codeanwendung mit einer nativen Codeanwendung zu "verknüpfen", aber selbst wenn diese tatsächlich funktionieren, wird eine entschlossene Person immer einen Weg finden.

Wenn es jedoch um Verschleierung geht, bekommen Sie, wofür Sie bezahlen. Wenn Ihr Code also so proprietär ist, dass Sie so große Anstrengungen unternehmen müssen, um ihn zu schützen, sollten Sie bereit sein, Geld in einen guten Verschleierer zu investieren.

In meinen rund 15 Jahren Erfahrung beim Schreiben von Code habe ich jedoch festgestellt, dass ein übermäßiger Schutz Ihres Quellcodes Zeitverschwendung ist und wenig Nutzen bringt. Der Versuch, den Originalquellcode ohne unterstützende Dokumentation, Kommentare usw. zu lesen, kann sehr schwer zu verstehen sein. Hinzu kommen die sinnlosen Variablennamen, die Dekompilierer entwickeln, und der Spaghetti-Code, den moderne Verschleierer erstellen - Sie müssen sich wahrscheinlich nicht allzu viele Sorgen machen, wenn Menschen Ihr geistiges Eigentum stehlen.


9

Lohnt es sich wirklich? Jeder Schutzmechanismus kann mit ausreichender Entschlossenheit gebrochen werden. Berücksichtigen Sie Ihren Markt, den Preis des Produkts, die Anzahl der Kunden usw.

Wenn Sie etwas Zuverlässigeres wollen, gehen Sie den Weg der Hardwareschlüssel, aber das ist (für den Benutzer) ziemlich mühsam und teurer. Softwarelösungen wären wahrscheinlich eine Verschwendung von Zeit und Ressourcen, und das einzige, was sie Ihnen geben würden, ist das falsche Gefühl von "Sicherheit".

Nur noch wenige Ideen (keine ist perfekt, da es keine perfekte gibt).

  • AntiDuplizieren
  • Ändern Sie die Sprache und verwenden Sie die netten Tricks, die die Autoren von Skype verwendet haben
  • Lizenzserver

Und verschwenden Sie nicht zu viel Zeit damit, denn die Cracker haben viel Erfahrung mit den typischen Techniken und sind Ihnen nur wenige Schritte voraus. Wenn Sie nicht viele Ressourcen verwenden möchten, ändern Sie wahrscheinlich die Programmiersprache (auf Skype-Weise).


Vergessen Sie nicht, dass es durchaus möglich ist, den Software-Teil der Hardware-Sperre anzugreifen.
Magnus Hoff

Ja, das stimmt, die einzige echte Option wäre, die Anwendung teilweise in Hardware implementiert zu haben (zum Beispiel eine seltsame Mischung aus Software-VHDL-Anwendungen). Dies wäre aber auch knackbar ...
Anonym

Was ist mit Dongles, die eine Public / Private Key-Strategie implementieren? Nur der private Schlüssel des Dongles kann die Anwendung entschlüsseln und ausführen.
mmcdole

Das macht normalerweise der Hardware-Schlüssel. Sie können jedoch entweder den Dongle angreifen - ihn klonen oder die Software, die für das Gespräch mit dem Dongle verantwortlich ist (umgehen, deaktivieren usw.).
Anonym

1
In meinem Fall hat es sich wirklich gelohnt. Nachdem ich die Teilschlüsselüberprüfung implementiert und das Registrierungsschlüsselschema für ein vorhandenes Produkt geändert hatte, stieg der Umsatz erheblich. Alle Software kann geknackt werden, die Frage ist nur, wie hoch Sie die Messlatte für den gelegentlichen Softwarepiraten höher legen.
Adrian Grigore

9

Wenn Sie möchten, dass Benutzer Ihren Code ausführen können (und wenn nicht, warum haben Sie ihn dann überhaupt geschrieben?), Muss ihre CPU in der Lage sein, Ihren Code auszuführen. Um den Code ausführen zu können , muss die CPU ihn verstehen können.

Da CPUs dumm sind und Menschen nicht, bedeutet dies, dass auch Menschen den Code verstehen können.

Es gibt nur einen Weg, um sicherzustellen, dass Ihre Benutzer Ihren Code nicht erhalten: Geben Sie ihnen nicht Ihren Code.

Dies kann auf zwei Arten erreicht werden: Software as a Service (SaaS), dh Sie führen Ihre Software auf Ihrem Server aus und lassen Ihre Benutzer nur remote darauf zugreifen. Dies ist beispielsweise das Modell, das Stack Overflow verwendet. Ich bin mir ziemlich sicher, dass Stack Overflow ihren Code nicht verschleiert, aber Sie können ihn nicht dekompilieren.

Der andere Weg ist das Appliance-Modell: Anstatt Ihren Benutzern Ihren Code zu geben, geben Sie ihnen einen Computer, der den Code enthält. Dies ist das Modell, das Spielekonsolen, die meisten Mobiltelefone und TiVo verwenden. Beachten Sie, dass dies nur funktioniert, wenn Sie den gesamten Ausführungspfad "besitzen": Sie müssen Ihre eigene CPU, Ihren eigenen Computer, Ihr eigenes Betriebssystem und Ihre eigene CLI- Implementierung erstellen . Dann und nur dann können Sie Ihren Code schützen. (Beachten Sie jedoch, dass selbst der kleinste Fehler alle Ihre Schutzmaßnahmen unbrauchbar macht. Microsoft, Apple, Sony, die Musikindustrie und die Filmindustrie können dies bestätigen.)

Oder Sie können einfach nichts tun, was bedeutet, dass Ihr Code automatisch urheberrechtlich geschützt wird.


8

Leider werden Sie nicht davonlaufen. Am besten schreiben Sie Ihren Code in C und P / Rufen Sie ihn auf.

Es gibt einen kleinen Catch-22, jemand könnte Ihre Anwendung einfach in CIL dekompilieren und jeden Bestätigungs- / Aktivierungscode (zum Beispiel den Aufruf Ihrer C-Bibliothek) beenden. Denken Sie daran, dass Anwendungen, die in C geschrieben sind, auch von den hartnäckigeren Hackern rückentwickelt werden (sehen Sie sich nur an, wie schnell Spiele heutzutage geknackt werden). Nichts schützt Ihre Anwendung.

Am Ende funktioniert es sehr ähnlich wie bei Ihnen zu Hause. Schützen Sie es gut genug, damit es zu aufwändig ist (Spaghetti-Code würde hier helfen) und der Angreifer nur zu Ihrem Nachbarn wechselt (Konkurrenz :)). Schauen Sie sich Windows Vista an, es muss 10 verschiedene Möglichkeiten geben, es zu knacken.

Es gibt Pakete, die Ihre EXE-Datei verschlüsseln und entschlüsseln, wenn der Benutzer sie verwenden darf, aber auch hier wird eine generische Lösung verwendet, die zweifellos geknackt wurde.

Aktivierungs- und Registrierungsmechanismen richten sich an den "durchschnittlichen Joe": Leute, die nicht genug technisches Know-how haben, um es zu umgehen (oder wissen, dass sie es umgehen können). Kümmere dich nicht um Cracker, sie haben viel zu viel Zeit.


1
Wenn Sie sich wirklich die Mühe machen, Ihren Registrierungscode in eine DLL auszulagern, sollten Sie sicherstellen, dass die DLL bei jeder neuen Version Ihrer Software anders sein muss. Andernfalls machen Sie es den Leuten noch einfacher, Ihre Software zu knacken. Sie müssen lediglich Ihre DLL einmal knacken und diese für alle späteren Versionen verwenden. Selbst Endbenutzer können dies tun, sobald sie eine alte geknackte DLL gefunden haben. Dies ist sogar noch schlimmer, als den Registrierungsmechanismus in Ihren verwalteten Code einzufügen.
Adrian Grigore

8

Neben dem Kaufschutz können Sie (oder Ihre Entwickler) den Kopierschutz erlernen.

Das sind Ideen:

Versuchen Sie zunächst, ein Programm zu schreiben, das sich selbst in die Konsole schreibt. Das ist ein berühmtes Problem. Der Hauptzweck dieser Aufgabe besteht darin, das Schreiben von selbstreferenzierendem Code zu üben.

Zweitens müssen Sie eine Technologie entwickeln, die Code so umschreibt, dass er von der CIL anderer Methoden abhängt .

Sie können eine virtuelle Maschine schreiben (noch in .NET ). Und geben Sie dort einen Code ein. Letztendlich führt die virtuelle Maschine eine andere virtuelle Maschine aus, auf der der Code ausgeführt wird. Dies gilt für einen Teil der selten genannten Funktionen, um die Leistung nicht zu stark zu verlangsamen.

Schreiben Sie eine Logik in C ++ / CLI um und mischen Sie verwalteten Code mit nicht verwaltetem. Dies wird die Demontage härten. Vergessen Sie in diesem Fall nicht, auch x64- Binärdateien bereitzustellen .


nicht bekommen können Sie im Detail erklären.
Priyank Bolia

7

Ja. Es ist wahr. .NET-Code lässt sich sehr einfach zurückentwickeln, wenn der Code nicht verschleiert ist.

Durch die Verschleierung werden Personen, die versuchen, Ihre Software zurückzuentwickeln, ärgerlich. Je nachdem, welche Version Sie erhalten, erhalten Sie unterschiedliche Schutzstufen.

Visual Studio enthält eine Version von Dotfuscator . Da es sich um eine gebündelte Version handelt, erhalten Sie definitiv nicht die bestmögliche Verschleierung. Wenn Sie sich die Funktionslisten ansehen, sehen Sie genau, was Ihnen fehlt (und was die Anwendung genau tut, um Ihren Code sicherer zu machen).

Es gibt einige andere kostenlose oder Open-Source-.NET-Verschleierer (aber ich kann die Qualität oder die verschiedenen Methoden, die sie verwenden, nicht kommentieren):

Am Ende ist nichts perfekt. Wenn jemand wirklich sehen möchte, wie Ihre Software funktioniert, wird er es tun.


11
Es ist nicht nur "wenn sie wirklich sehen wollen, wie Ihre Software funktioniert, werden sie". Wenn sie sich interessieren, können sie wahrscheinlich raten, ohne zu schauen. 99,9% + der Software haben keine Magic Pixie Dust-Algorithmen. Der schwierige Teil der Programmierung ist keine spezielle geheime Technik. Es geht nur darum, alle Teile auszurichten und zu arbeiten.
Ken

9
@ Ken - Shhhh! Sie können den Rest der Welt nicht wissen lassen, dass wir die meiste Zeit keine Magic Pixie Dust-Algorithmen verwenden.
Justin Niessner

9
Justin: Zählt Liebe als magischer Algorithmus? Liebe ist das Besondere an meinen Programmen. Ich glaube nicht, dass du die Liebe zerlegen kannst.
Ken

Babel.NET ist nicht mehr kostenlos. Eine Liste der häufigsten (kostenlosen und kommerziellen) Verschleierer finden Sie hier .
InputOutput

6

Nun, Sie können Ihr Produkt nicht VOLLSTÄNDIG vor Rissen schützen, aber Sie können die Sicherheitsstufe maximieren / verbessern und es ein bisschen zu schwierig machen, von Neulingen und Zwischencrackern geknackt zu werden.

Bedenken Sie jedoch, dass nichts unknackbar ist, nur die Software auf der Serverseite ist gut geschützt und kann nicht geknackt werden. Um die Sicherheitsstufe in Ihrer Anwendung zu verbessern, können Sie einige einfache Schritte ausführen, um zu verhindern, dass einige Cracker "nicht alle" Ihre Anwendungen knacken. Diese Schritte werden diese Cracker verrückt und vielleicht verzweifelt machen:

  • Verschleiern Sie Ihren Quellcode. Dadurch sieht Ihr Quellcode offensichtlich chaotisch und unlesbar aus.
  • Lösen Sie mehrere zufällige Überprüfungsroutinen in Ihrer Anwendung aus, z. B. alle zwei Stunden, 24 Stunden, einen Tag, eine Woche usw. oder möglicherweise nach jeder Aktion, die der Benutzer ausführt.
  • Speichern Sie die MD5- Prüfsumme Ihrer freigegebenen Anwendung auf Ihrem Server und implementieren Sie eine Routine, mit der die aktuelle MD5-Prüfsumme der Datei mit der tatsächlichen auf Ihrer Serverseite überprüft und zufällig ausgelöst werden kann. Wenn die MD5-Prüfsumme geändert wurde, bedeutet dies, dass diese Kopie raubkopiert wurde. Jetzt können Sie es einfach blockieren oder ein Update veröffentlichen, um es zu blockieren usw.
  • Versuchen Sie, eine Routine zu erstellen, mit der überprüft werden kann, ob einige Ihrer Codes (Funktionen, Klassen oder bestimmte Routinen) tatsächlich geändert oder sogar entfernt wurden. Ich nenne es (Code-Integritätsprüfung).
  • Verwenden Sie kostenlose unbekannte Packer, um Ihre Anwendung zu packen. Wenn Sie das Geld haben, entscheiden Sie sich für kommerzielle Lösungen wie Thamida oder .NET Reactor . Diese Anwendungen werden regelmäßig aktualisiert. Sobald ein Cracker Ihre Anwendung entpackt, können Sie einfach ein neues Update von diesen Unternehmen erhalten. Sobald Sie das neue Update erhalten, packen Sie einfach Ihr Programm und veröffentlichen ein neues Update.
  • Geben Sie regelmäßig Updates frei und zwingen Sie Ihren Kunden, das neueste Update herunterzuladen.
  • Schließlich machen Sie Ihre Bewerbung sehr billig. Mach es nicht zu teuer. Glauben Sie mir, Sie werden zufriedenere Kunden haben und Cracker werden Ihre Anwendung einfach verlassen, weil es ihre Zeit nicht wert ist, eine sehr billige Anwendung zu knacken.

Dies sind nur einfache Methoden, um zu verhindern, dass Neulinge und Zwischencracker Ihre Anwendung knacken. Wenn Sie weitere Ideen zum Schutz Ihrer Anwendung haben, scheuen Sie sich nicht, diese zu implementieren. Es wird Crackern nur das Leben schwer machen und sie werden frustriert sein und schließlich werden sie Ihre Anwendung verlassen, weil es ihre Zeit einfach nicht wert ist.

Schließlich müssen Sie auch in Betracht ziehen, Ihre Zeit mit dem Codieren einer guten und qualitativ hochwertigen Anwendung zu verbringen. Verschwenden Sie Ihre Zeit nicht mit dem Codieren komplizierter Sicherheitsebenen. Wenn ein guter Cracker Ihre Anwendung knacken möchte, wird er / sie tun, egal was Sie tun ...

Jetzt geh und implementiere ein paar Spielsachen für die Cracker ...


5

Es gibt Salamander , einen nativen .NET-Compiler und -Linker von Remotesoft, der Anwendungen ohne das .NET-Framework bereitstellen kann. Ich weiß nicht, wie gut es seinen Ansprüchen gerecht wird.


Die Antwort ist ganz einfach: Es ist schade, dass die meisten Antworten über Verschleierung sprechen. Die Verschleierung ist gut, um den ersten (Reflektor-ähnlichen) Versuch zu stoppen, in Ihrem Code nachzuschauen, das ist alles. Das ist nicht schlecht. Und natürlich hindert nichts echte Hacker, die Assembler-Code verstehen, außer dem Schreiben einer SAAS-Anwendung (selbst dann können sie versuchen, Ihren Server zu hacken). Aber es gibt noch mehr, es gibt Tools wie Salamander, .NET Reactor und andere, die (vielleicht) fast das gleiche Sicherheitsformular bieten, das nicht kompiliert werden kann wie eine C ++ - kompilierte Win32 .exe. Welches dieser Tools das beste ist, kann ich noch nicht beurteilen.
Philm

5

Wenn Microsoft eine Lösung finden könnte, hätten wir keine Raubkopien von Windows-Versionen, daher ist nichts sehr sicher. Hier sind einige ähnliche Fragen von Stack Overflow, und Sie können Ihre eigene Art des Schutzes implementieren. Wenn Sie verschiedene Versionen veröffentlichen, können Sie verschiedene Techniken für verschiedene Versionen anwenden, sodass die zweite Version übernommen werden kann, wenn die erste geknackt wird.


5

.NET Reaktor

Aktualisieren

Jared wies darauf hin, dass de4dot behauptet, es dekompilieren zu können.

.NET Reactor bietet vollständigen Schutz für Ihr sensibles geistiges Eigentum, indem Ihre .NET-Assemblys in nicht verwaltete Prozesse konvertiert werden, die nicht als CIL verstanden werden können und die kein vorhandenes Tool dekompilieren kann. Hacker haben keinen Zugriff auf eine verständliche Form Ihrer Quelle.

Mit den leistungsstarken und flexiblen .NET Reactor-Lizenzierungsfunktionen können Sie Ihre Lizenzbedingungen durchsetzen und Ihre Einnahmequellen durch Hardware- und Software-Sperren schützen. Der Lizenzmanager kann innerhalb von Sekunden Test- oder permanente Lizenzen erstellen. Mit einem vollständig dokumentierten Software Development Kit (SDK) mit Beispielen können Sie das Lizenzierungssystem direkt aus Ihrem Code heraus aufrufen und benutzerdefinierte Erweiterungen für das Lizenzierungssystem erstellen.


3
Ich habe versucht, diese Leute mit einer Frage zu kontaktieren, die ich zu ihrem Produkt hatte, aber sie haben nie geantwortet. Haben Sie ihr Produkt ausprobiert? Ich habe mich für eine intelligente Montage entschieden und sowohl das Produkt als auch der Support sind sehr gut. Aber wie ich bereits in der Frage sagte, ist die Verschleierung eine Möglichkeit, aber kein vollständiger Beweis.
Priyank Bolia

1
Ich hatte früher einige Probleme mit ihrem Produkt und stellte dann einige Fragen zu hochauflösenden Symbolen in groups.google.se/group/net-reactor-users. Ich erhielt eine Antwort und eine Lösung, aber jetzt scheint es schwierig zu sein ergattern.
Schade

2
Wenn "kein vorhandenes Tool dekompiliert werden kann", warum wird es auf der Seite mit den de4dot-Funktionen als unterstützter Verschleierer / Packer aufgeführt?: Bitbucket.org/0xd4d/de4dot
Jared Thirsk

Wahrscheinlich, weil es eine alte Aussage ist und sie ihre Webseite nicht aktualisiert haben. Ich bin kein Benutzer eines Verschleierungswerkzeugs mehr.
Loraderon

de4dot ist ein sehr mächtiges Werkzeug. Ich habe es gegen mehrere Verschleierer versucht und es macht einen tollen Job. Es war jedoch nicht in der Lage, mit .NET Reactor (v6.0) geschützte Dateien zu verarbeiten. Vielleicht ist de4dot nicht auf dem neuesten Stand.
InputOutput

4

Hier ist eine Idee: Sie könnten einen von Ihrem Unternehmen gehosteten Server haben, zu dem alle Instanzen Ihrer Software eine Verbindung herstellen müssen. Es reicht nicht aus, sie nur zu verbinden und einen Registrierungsschlüssel zu überprüfen - sie entfernen nur den Scheck. Zusätzlich zur Schlüsselprüfung muss der Server eine wichtige Aufgabe ausführen, die der Client nicht selbst ausführen kann, sodass eine Entfernung nicht möglich ist. Dies würde natürlich wahrscheinlich eine Menge intensiver Verarbeitung seitens Ihres Servers bedeuten, aber es würde es schwierig machen, Ihre Software zu stehlen, und vorausgesetzt, Sie haben ein gutes Schlüsselschema (Besitz prüfen usw.), werden die Schlüssel auch schwierig zu stehlen sein stehlen. Dies ist wahrscheinlich invasiver als Sie möchten, da Ihre Benutzer mit dem Internet verbunden sein müssen, um Ihre Software verwenden zu können.


5
Was passiert, wenn der Server ausfällt oder Benutzer nicht immer über einen Internetzugang verfügen? Ihre Methode frustriert die Kunden einfach, da sie so häufig zu den Internet-Servern fährt, nur um eine App zu verwenden.
Priyank Bolia

Ich stimme vollkommen zu. Deshalb habe ich in meiner letzten Zeile gesagt, "das ist wahrscheinlich invasiver als Sie wollen ...". Ich habe dem OP nur die beste Lösung angeboten, die ich für technisch machbar hielt, nicht den besten Ansatz, um die Kunden zufrieden zu stellen :)
rmeador

Im ersten Quartal 2010 (einige Monate nachdem diese Antwort geschrieben wurde) versuchte die Spieleentwicklungsfirma Ubisoft dies, und anscheinend war die Belastung der serverseitigen Komponenten so groß, dass die Spiele nicht spielbar waren. Gesamteindruck der SW: "Aufwand bei der Installation, kann nicht offline verwendet werden, invasiv und unzuverlässig ". Sollten Sie also entscheiden, dass die serverseitige Verarbeitung der richtige Weg ist, stellen Sie sicher, dass Sie tatsächlich nach Bedarf skalieren können.
Piskvor verließ das Gebäude am

3

Alles, was auf dem Client ausgeführt wird, kann dekompiliert und geknackt werden. Die Verschleierung macht es nur schwieriger. Ich kenne Ihre Bewerbung nicht, aber in 99% der Fälle denke ich einfach nicht, dass sich die Mühe lohnt.


3

Es ist leider unmöglich, eine Anwendung vollständig zu sichern.



2

Denken Sie daran, dass 99% + Ihrer Benutzer nicht daran interessiert sein werden, Ihre ausführbare Datei zu untersuchen, um zu sehen, wie sie funktioniert.

Lohnt es sich angesichts der Tatsache, dass sich so wenige Menschen überhaupt die Mühe machen, es zu versuchen, und dass die meisten Verschleierer umgangen werden können, Ihre Zeit und Mühe?

Sie sollten die Zeit besser in die Verbesserung Ihres Produkts investieren, damit mehr Menschen es verwenden möchten.


2

Nur um eine Warnung hinzuzufügen: Wenn Sie die Verschleierung verwenden möchten, überprüfen Sie, ob alles noch funktioniert! Durch die Verschleierung können sich beispielsweise Klassen- und Methodennamen ändern. Wenn Sie also Reflection verwenden, um bestimmte Methoden und / oder Klassen aufzurufen (wie in einer Plugin-Architektur), kann Ihre Anwendung nach der Verschleierung fehlschlagen. Auch Stacktraces können nutzlos sein, um Fehler aufzuspüren.


2

Wenn es in .NET geschrieben und in CIL kompiliert ist , kann es wiedergegeben werden. Wenn die Sicherheit ein Problem darstellt und eine Verschleierung vermieden werden soll, empfehle ich, Ihre Anwendung in einer nicht verwalteten Sprache zu schreiben, die von Natur aus schwieriger zurückzuentwickeln ist.


2

So stellen Sie sicher, dass die Anwendung nicht manipuliert wird, und wie Sie sicherstellen, dass der Registrierungsmechanismus nicht rückentwickelt werden kann.

Beide haben die gleiche sehr einfache Antwort: Verteilen Sie den Objektcode nicht an nicht vertrauenswürdige Parteien, wie (anscheinend) Ihre Kunden. Ob es möglich ist, die Anwendung auf Ihren Computern zu hosten, hängt nur davon ab, was sie tut.

Wenn es sich nicht um eine Webanwendung handelt , können Sie möglicherweise die SSH- Anmeldung mit X-Weiterleitung an einen Anwendungsserver (oder eine Remotedesktopverbindung) zulassen , glaube ich, für Windows) .

Wenn Sie nerdigen Personen Objektcode geben und diese glauben, dass es Spaß machen könnte, Ihr Programm zu knacken, wird dies der Fall sein es geknackt. Daran führt kein Weg vorbei.

Wenn Sie mir nicht glauben, weisen Sie auf eine hochkarätige Anwendung hin, die nicht geknackt und raubkopiert wurde.

Wenn Sie sich für die Hardwareschlüssel entscheiden, wird die Produktion teurer und Ihre Benutzer werden Sie dafür hassen. Es ist eine echte Schlampe, auf dem Boden herumzukriechen und Ihre 27 verschiedenen USB-Geräte ein- und auszustecken, weil Softwarehersteller Ihnen nicht vertrauen (wie ich mir vorstellen kann).

Es gibt Pakete, die Ihre EXE-Datei verschlüsseln und entschlüsseln, wenn der Benutzer sie verwenden darf

Natürlich besteht der Weg dahin darin, den "can-I-use-it" -Test zu knacken, damit er immer true zurückgibt.

Ein böser Trick könnte darin bestehen, die Bytewerte der Opcodes, die den Test an einer anderen Stelle im Programm ausführen, auf schmutzige Weise zu verwenden, wodurch das Programm mit hoher Wahrscheinlichkeit abstürzt, es sei denn, der Wert stimmt genau. Sie sind jedoch mit einer bestimmten Architektur verbunden :-(


Kein Absturzpunkt ist einfach zu debuggen und überschreiben Sie den Code in .NET, um diese Prüfung zu umgehen. Wie werden Sie auch die Opcodes in .NET ändern? Können Sie dies näher erläutern?
Priyank Bolia

Oh. Ich hatte C-Tricks im Sinn; Nehmen Sie beispielsweise die Adresse der Validierungsfunktion und addieren Sie die 10 ersten Bytes in diesem char-Array (setzen Sie den Funktionszeiger um). wähle eine beliebige Funktion f und speichere [die Adresse von f minus der vorherigen Summe] in fptr. Nennen Sie f immer als * (fptr + diese Summe). Berechnen Sie "diese Summe" vor
Jonas Kölker

2

Machen Sie einfach eine gute Anwendung und codieren Sie ein einfaches Schutzsystem. Es spielt keine Rolle, für welchen Schutz Sie sich entscheiden, er wird umgekehrt ... Verschwenden Sie also nicht zu viel Zeit / Geld.


2

Wenn es um .NET geht, wenn Sie Windows Forms veröffentlichen Anwendung (oder eine Anwendung, in der der Client über die Portable Executable-Datei verfügt) , kann diese geknackt werden.

Wenn Sie bei .NET bleiben und die Wahrscheinlichkeit minimieren möchten, dass Ihr Quellcode verwendet wird, sollten Sie ihn möglicherweise als ASP.NET- Anwendung auf einem Webserver bereitstellen, anstatt ihn zu einer Windows Forms-Anwendung zu machen.


2

Ehrlich gesagt müssen wir manchmal den Code verschleiern (z. B. Lizenzklassen registrieren und so weiter). In diesem Fall ist Ihr Projekt nicht kostenlos. IMO, du solltest für einen guten Obfucator bezahlen.

Dotfuscator verbirgt Ihren Code und .NET Reflector zeigt einen Fehler an, wenn Sie versuchen, ihn zu dekompilieren.


Durch die Nutzung unserer Website bestätigen Sie, dass Sie unsere Cookie-Richtlinie und Datenschutzrichtlinie gelesen und verstanden haben.
Licensed under cc by-sa 3.0 with attribution required.