Protectionsmassnahmen für Entwickler
Entwickler sollten einen starken kombinierten Kompressor und Protector gebrauchen, um ihre Software vor Crackern zu schützen. Als Software-Protector für 64 Bit ist lARP64Pro Ihre erste Wahl. Aber nicht nur ein Protector kann hilfen gegen Cracking. Einerseits sollten Entwickler auch erlernen, einige grundlegende Richtlinien zu üben. Dieses allein bereits verhindert dass Ihre Software durch den Anfängercracker gecrackt wird. Lassen Sie uns einige Möglichkeiten erwähnen, die der Entwickler hat. Freilich ist es nicht einfach, und es erfordert etwas Arbeit aber es ist gar nicht unmöglich guten Schutz in Ihren eigenen Programmen zu programmieren. Noch müssen Sie sich erinnern wenn Sie ein neues Programm schreiben, dass typische Programmierungsmethoden den Job des Crackers einfacher bilden. Die meisten Cracker wenden einige gut-geprüfte Methoden an um bestimmte Weisen des Schutzes als solches zu cracken und sind so in der Lage einen großen Prozentsatz des Schutzentwurfs zu entfernen. Der Schlüssel ist weniger allgemeine Methoden anzuwenden, aber neue zu suchen die den Cracker verlangsamen oder den Anfänger sogar komplett stoppen.
Einige Richtlinien des Schreibens guten Schutzens in Ihrem Ausrichtungsentwurf.
* Zuerst: wenn Ihr Programm gercackt worden ist, geben Sie eine neue Version frei. Häufige Updates zu Ihrem Programm können Cracker müde machen, besonders als der Schutz durch das Ändern des Codes entfernt wurde. Dieses ist auch weil der Patch vermutlich nicht mehr in der neuen Version arbeitet. Falls Ihr Programm keygenned wurde, dann schreiben Sie Ihren Ausrichtungsentwurf neu in einer vollständig unterschiedlichen Art!
* Verwenden Sie starke Verschlüsselung für den Ausrichtungsentwurf und andere heikle Gebiete in Ihrem Code. Wenn dieses den Cracker nicht stoppt, verlangsamt es ihn/sie mindestens beträchtlich.
* Verwenden Sie nie selbst-umschreibende Namen. Z.B. wenn Sie die Funktionsnamen IsNotRegistered und IsRegistered in Ihrer Quelle verwenden, dann weiß der Cracker sofort wo man seine Bemühung im Code fokussiern soll. Zugestimmt, es ist ein wenig schwieriger Ihre Programme so zu schreiben, aber das Cracken wird auch viel härter! Es ist sogar eine gute Gewohnheit einige gefälschter Namen zu verwenden die zu einem Lockvogelausrichtungsentwurf anspielen!
* Benutzen Sie nie Fehlermeldungen (sie sind vermutlich doch nicht notwendig). Wenn das Programm eine Fehlermeldung gibt, nachdem eine falsche Serial eingegeben worden ist, kann der Cracker den Programmcode nach der Fehlermeldung ganz einfach absuchen um das Verfahren das sie benannte, ausfindig zu werden. Dieses kann für ihn/sie sogar so einfach sein wie ein breakpoint auf MessageBoxA um sofort im rechten Punkt zu landen. Wenn Fehlermeldungen wirklich unvermeidbar sind, verstecken Sie sie so viel wie möglich und verursachen Sie sie (dynamisch) in Realzeit, eher als Betriebsmittel für sie zu benutzen. Es ist auch eine gute Idee die Daten und das Verfahren das eine Fehlermeldung verursacht, zu verschlüsseln, was es viel schwieriger bildet für den Cracker ihn im auseinandergebauten Code zurück zu finden.
* Führen Sie die Ausrichtungsprüfung nicht sofort nach Eingeben der Serial durch. Dieses bildet es viel schwieriger als der Cracker die Anwendung in einem Debugger verfolgt. Besser noch, erfordern Sie dass das Programm neu gestartet wird bevor Prüfung anfängt.
* Fügen Sie gelegentliche Tests für die Ausrichtung hinzu die sich vom ursprünglichen Test unterscheiden. Cracker hassen das wirklich weil es normalerweise viel Zeit nimmt um diese Tests zu entfernen. Als Veränderung auf diesem Thema, können Sie am besten verschiedene Entwürfe des Registrierens selbst und der Ausrichtungsüberprüfung an jedem Start prüfen lassen. So bedeutet dieses, dass Sie die gleiche Überprüfung nicht durchlaufen aber in der Tat in unterschiedliche Funktionen prüfen.
* Verwenden Sie teilweises Checksumming in Ihrer Anwendung. Wenn Sie Ihre EXE und DLL-Akten für Änderungen prüfen, besonders in den heiklen Gebieten, werden Cracker gehindert um jene Bereiche mit dem einfachen Patchen zu ändern. Natürlich sind sie noch in der Lage den Code direkt im Gedächtnis zu ändern, also ist es außerdem eine gute Idee auf Änderungen am Anwendungscode im Gedächtnis zu prüfen. Beachten Sie, dass ein Cracker die Prüfsumme zum korrekten Wert ändern kann nachdem er das Programm so gepatcht hat. Aber wenn Sie Prüfsummen auf kleineren Abschnitten des Programms durchführen, bilden Sie den Job des Crackers schwieriger.
* Verwenden Sie genistete Tests um Programme auf heiklen Gebieten zu überprüfen, und es so härter zu bilden den Schutz zu entfernen. Jedes Teil des Tests sollte nur ein Teil der Korrektheit der Ausrichtung überprüfen, um die Ausrichtung zu verhindern zu leicht verstanden zu werden wenn ein Cracker sie entdeckt. Indem ihr mehr als ein Überprüfenprogramm verwendet, ist das Cracken des Programms häufig falsch, weil der Cracker eine oder mehrere der Überprüfenprogramme verfehlen kann.
* Kodieren Sie ein Lockvogelausrichtungsteil in Ihrem Programm. Diese Technik mit falschen Prüfungsteilen verwirrt den Cracker, da es endlose Veränderungen auf dem Thema gibt und es ziemlich schwierig ist, zu ermitteln, welches Teil des Programms schließlich das wichtige ist.
* Verwenden Sie nicht einfach den erst möglichen Ausrichtungsentwurf woran Sie für Ihr Programm denken. Der Ausrichtungsentwurf ist zweifellos das wichtigste Stück des Codes (abgesehen von der Hauptfunktion?) in Ihrem Programm. Denken Sie lang an die Möglichkeiten und finden Sie Rat auf dem Thema wenn notwendig.
* Verschlüsseln Sie Ihre Ausrichtung unter Verwendung einer Technik, die von der bestimmten Computerhardware abhängig ist. Das bildet es härter die gleiche Akte zu benutzen um das Programm auf einen anderen Computer zu registrieren.
* Setzen Sie Ihre Ausrichtungsinformationen in einen nicht offensichtlichen Platz ein. Wenn Sie die Ausrichtungsinformationen im Windows-Register einführen, kann es leicht entdeckt werden. Eine Möglichkeit ist, es in einer Akte zu halten von der niemand vermuten würde dass es die Ausrichtung enthalten könnte. Z.B. wie innen ein DLL. Indem Sie solch ein DLL in das Windows-Systemsverzeichnis setzen, bilden Sie die Ausrichtungssituation sehr verwirrend für den Cracker. Selbst wenn ein Cracker ein Aktenüberwachungwerkzeug benutzt um Zugang zu den Akten zu folgen, kann es eine Weile dauern bevor er versteht dass die Ausrichtung in solch einer Akte ist. Besser noch, errichten Sie Teile der Ausrichtung in unterschiedlichen Plätzen um sie so zu bilden dass der Schutz falsch entfernt wird.
* Haben Sie nicht vor langen Ausrichtungen Angst. Desto länger die Ausrichtungsakte ist, desto länger dauert es um sie zu verstehen. Wenn die Ausrichtungsakte lang genug ist, kann sie wichtige Informationen enthalten die das Programm benötigt. Wenn solch ein Programm gepatcht wird, läuft es nicht richtig.
* Bilden Sie den Überprüfungsprozeß für Ihr Serialroutine unvollständig und prüfen Sie gelegentlich die restlichen Teile der Serial, also nicht sofort aber gelegentlich. Dies ist eine sehr starke Maßnahme weil es für den Cracker viel härter ist wenn das sogenannt korrekt registrierte Programm plötzlich bemirkt dass es tatsächlich noch nicht richtig registriert war.
* Für Zeit-begrenzten Trial-Shareware sollten Sie einige zeitbezogene Daten wie Aktendatum usw. prüfen. Auch können Sie das Datum und die Zeit festlegen um dann das Tagesdatum während jeder neuer Produktstart zu prüfen. Wenn das Tagesdatum oder die Zeit gleich oder kleiner ist als das Programm vorher laufen gelassen wurde, ist es klar dass die Zeit justiert wurde.
* Ein allgemeiner Fehler ist das Serial Test stück zu lange zu bilden. Was nur eine Sekunde nimmt als ein Programm läuft, dauert bereits lang genug um es unter Debugger zu studieren. Alles das länger dauert, holt zusätzliche Punkte des Angriffs zum Cracker. Es ist häufig zutreffend dass die einfachsten Methoden auch die besten sind, zweifellos ist das nicht immer das richtige Argument für Ihr Serienüberprüfungsprogramm. So ist irgendein Lockvogelcode in Ihrem Ausrichtungsentwurf auch häufig eine gute Idee. Dennoch sollten Sie überprüfen ob es für den Cracker nicht möglich ist gleich zu erklären ob irgend ein Stück des Codes wichtig ist oder nicht.
* Erwägen Sie Abschnitte des erst nach Ausrichtung entschlüsselt zu werden Codes die nicht in einer nicht registrierten Version arbeiten sollen, zu verschlüsseln. Der entschlüsselnde Schlüssel muss die Ausrichtung dann enthalten damit das Stück nicht ohne Ausrichtung decodiert werden kann.
* Wenn Ihre Anwendung eine Serial verwendet, dann sollte diese Zahl im Gedächtnis nie sichtbar sein. Die korrekte Serial sollte im Gedächtnis überhaupt nie vollständig gebildet werden. Überprüfen Sie Teile der Serial, zerstören Sie sein Gedächtnis und überprüfen Sie dann das folgende Teil der Serial. Dies heißt, dass es unmöglich sein sollte, die Zulassungsnummer Ihres Programms unter Debugger zu finden. Dies heißt auch, dass die Serialüberprüfung mehr tun soll als nur zwei Variabeln zu vergleichen. Ein möglicher aber noch zu einfacher Weg ist, die eingegebene Serial und die korrekte Ausrichtung ebenso zu verschlüsseln. Auf diese Art können die zwei Zahlen ohne ein zu großes Risiko des Crackens verglichen werden. Verwenden Sie Ihre Fantasie! Sie konnten eine Prüfsumme der eingegebenen Serial mit der Prüfsumme der korrekten Serial vergleichen.
* Ein einfaches zusätzliches vergleichen durch teilweise Überprüfung in einem unterschiedlichen Thread benutzt nicht viele Betriebsmittel wenn es nur gelegentlich durchgeführt wird. Doch ist dieses einen realen Schmerz um zu finden.
* Erwägen Sie on-line-Ausrichtung obwohl dieses auch einige Nachteile haben kann, und es ist auch nicht ratsam für bestimmte Software. Das Internet hat die Möglichkeiten der on-line-Ausrichtung und seiner Überprüfung bestimmt erhöht. Wenn ein Programm online registriert wird, werden seine Ausrichtungsdaten zu einem bestimmten Server geschickt. In seiner grundlegendsten Form schickt dieser Server dann Informationen zum Programm zurück das erklärt ob die Ausrichtung wohl oder nicht erfolgreich war. Wichtige Nebenwirkung ist, dass der Server auch benutzt werden kann um Daten zu senden die die Programmnotwendigkeiten zwecks die registrierte Anwendung starten. Diese Daten können von den wichtigen Teilen des Codes zu einem Schlüssel reichen, der benötigt wird, um Teile des Programms zu decodieren. Oder das Programm kann Zeit-gelegentlich Überprüfen auf den Server ob alles noch fein ist. Noch ist ein Wort der Warnung hier an seinem Platz: wenn der Cracker den Code für den Server findet (der häufig wirklich einfach zu finden ist), dann ist alles unbrauchbar. Offensichtlich, wenn Sie die on-line-Ausrichtung anstreben, müssen Sie dieses Stück des Codes mit allen möglichen Mitteln verstecken, verschlüsseln und verteidigen!
* Handeln Sie nie sofort wenn ein Ausrichtungsproblem ermittelt wird. Senden Sie den Cracker eine Weile weiter weg. Keine Warnung was falsch ist, nur die Registrierung total aufheben und unregistriert weiter arbeiten.
* Wenn Sie die Funktionalität Ihres Programms begrenzen, dann bilden Sie am besten eine reale Demo wobei Sie sicherstellen dass das Programm den Code für die begrenzte Funktion nicht enthält. Viele Entwickler machen den Fehler vom Einschließen des Codes für eine Funktion die nur nach Ausrichtung im registrierten Programm vorhanden sein soll. In solch einem Fall kann der Cracker den Code ändern, damit die Funktion arbeitet.
* Informieren Sie sich. Wir wissen dass es kaum möglich ist alles Material über Cracken zu lesen und zu studieren. Jedoch verletzt etwas lese-Arbeit über neue Techniken, über Schutz und über das Cracken im Allgemeinen, nie. Im Gegenteil: es hilft bereits viel in der Vermeidung der grundlegenden Fehler!
Erwähnen Sie, dass die oben genannten Technieken Ihre Software nicht gegen dem Cracken verteidigen kann, selbst nicht wenn Sie alle oben genannten Massnahmen zusammen in Ihrem Programm verwenden. Ist Ihre Software nie vorher gecrackt worden? Beachten Sie dann, dass Sie entweder sehr viel Glück haben, oder Ihre Software noch nicht aufgefallen war, oder Ihre Software nicht interessant genug ist. Noch ist es besser, Ihre Software zu schützen, weil man nie weiß, was morgen bringen konnte … . So ist die letzte Massnahme zweifellos nicht die wenigst wichtige Maßnahme die alle Softwareentwickler nehmen sollten: schütze Ihre Software mit einem starken Protector, der von ernsten Leuten mit starkem Wissen über dem Cracken gebildet wurde.
Erinnern Sie sich daran dass Cracker häufig besser informiert sind als Sie. Die Besten von ihnen sind auch ausgezeichnete Programmierer, und sie können nicht leicht überrascht werden. Folglich sollten Sie einen professionell gebildeten Schutz benutzen: jene Leute haben das Cracken studiert und wissen besser als der übliche Entwickler wie Ihre Software zum Besten zu verteidigen! Eine Anmerkung: konstruieren Sie und verwenden Sie Ihren eigenen Ausrichtungsentwurf, selbst wenn Sie wirklich keine Idee haben wie man dies auf eine starke Art tut. Sobald der Protector-Ausrichtungsentwurf gecrackt ist, ist es zu einfach für Cracker in der Lage zu sein den gleichen Entwurf vom Protector immer wieder zu cracken. Es ist weit schwieriger, wenn Sie Ihren eigenen Entwurf haben, den Sie zusammen mit dem zusätzlichen Schutz von dem Protector verwenden!
Viel Glück!