Mitprogrammierer verwendeten schlechteste Programmierpraktiken


37

Ich weiß, es scheint seltsam zu sagen, aber ein Arbeitskollege hat absichtlich ein paar schlechte Programmierpraktiken angewendet! Ich erkläre es. Lassen Sie mich zunächst sagen, dass er ein intelligenter Typ ist und größtenteils verständlichen Code schreibt.

Er wurde gebeten, Lizenzen für ein in Java geschriebenes Webanwendungsprojekt zu implementieren. Da es sich um Java handelt, könnte man, wenn man es wirklich wollte, wahrscheinlich die Gläser öffnen und die Namen der darin geschriebenen Klassen und Methoden lesen. Seine Lösung für dieses Problem bestand darin, Variablen und Methoden buchstäblich als weniger offensichtliche Namen zu bezeichnen und sie in bereits überlastete Klassen einzufügen, anstatt neue Klassen zu generieren.

Er begründete dies damit, dass ein Hacker, der bestimmte Klassen ausschalten wollte, um Lizenzprüfungen zu umgehen (und daher eine kostenlose Kopie des Produkts zu erhalten), eine weitaus schwierigere Zeit damit haben würde, wenn nicht klar wäre, welche Methoden zur Anwendung kamen diese besonderen Aufgaben ausführen. Erst nachdem er es getan hatte, konfrontierte ich ihn damit und schlug vor, dass wir vielleicht eine Art Verschleierungsbibliothek kaufen könnten, um es für uns zu tun, während wir gute Programmierpraktiken beibehielten. Er behauptet, weder Zeit noch Ressourcen gehabt zu haben, um nach einer solchen Lösung zu suchen.

..Das lässt mich in einem Dilemma. Suche ich nach einer Obfuscator-Bibliothek in Java und repariere seinen alten Code (der beim Umbau seines Codes etwas heikel sein könnte), oder lasse ich ihn so, wie es mich bis zum Äußersten irritiert?


4
Wenn es bei Ihrer Frage darum geht, wie Sie mit der Politik dieser Situation umgehen sollen, dann weisen viele der hier gegebenen Antworten in die richtige Richtung. Wenn Sie jedoch, wie ein Kommentar von Ihnen sagt, eine bessere Alternative vorschlagen möchten, sollten Sie dies überprüfen Antworten auf diese Frage: stackoverflow.com/questions/6018215/…
Mark Booth

8
Wenn ein Hacker mit Zugriff auf Ihren sauberen Quellcode Ihre Authentifizierung hacken kann, ist dies hackbar. Keine Menge an Verschleierung wird helfen. Wenn Sie nach einer Lösung suchen, die einige Hacker aufhält, sollten Sie zusätzlich zur Verschleierung auch einige seiner Fehlleitungspraktiken anwenden (Dinge in unwahrscheinlichen Klassen verstecken, die nicht einfach ersetzt werden können). Häufige Updates, die Ihre Authentifizierungspraxis vollständig ändern, helfen ebenfalls. Viele Benutzer haben es satt, sich auf Hacker zu verlassen und kaufen sie einfach.
Bill K

2
Benannte er Einheimische um? Wenn ja, verschwendet er seine Zeit - sie existieren sowieso nicht als benannte Variablen im kompilierten Code.
Nick Johnson

1
Es heißt "Verschleierung" und obwohl es heutzutage häufiger verwendet wird, ist es nicht voll beweisbar! .. obwohl es jemanden vom Knacken des Codes abhält, kann es geknackt werden! .. was ich gerne sehen würde, ist ein Compiler das kann den Objektcode verschlüsseln und nur mit dem richtigen Schlüssel ausgeführt werden, so dass selbst jemand mit einem Disk-Editor, Disassembler oder einem anderen Cracking-Tool niemals in der Lage sein wird, daraus Kopf oder Zahl zu machen!
Frank R.

6
"Seine Lösung für dieses Problem bestand darin, Variablen und Methoden buchstäblich als unangenehme Namen zu bezeichnen und sie in bereits überlastete Klassen einzufügen, anstatt neue Klassen zu generieren." und "Lassen Sie mich zuerst sagen, dass er ein intelligenter Kerl ist" passen nicht in den gleichen Absatz!
verschlang Elysium

Antworten:


94

Sicherheit durch Verschleierung ist niemals gute Sicherheit. Es muss bessere Möglichkeiten geben, Ihr geistiges Eigentum zu schützen. Und das sollten Sie und Ihr Kollege gemeinsam mit Ihrem Vorgesetzten zur Sprache bringen. Wenn das Management dann entscheidet, dass es nicht die Zeit oder das Geld für mehr Sicherheit ausgeben möchte, müssen Sie beide mit dieser Entscheidung leben (es ist nicht Ihr Produkt, es ist das Produkt des Unternehmens) und besser nicht ausgeben (Abfall?). mehr Zeit zum Thema.


31
+1 Verschleierung ist KEINE Sicherheit, nur eine Komfortdecke.
uɐɪ

7
Wenn Sie eine bessere Lösung als die Verschleierung finden können, werde ich Ihre Antwort als die richtige markieren. Wie können Sie sicherstellen, dass jemand mit Zugriff auf die War-Datei die Funktionalität nicht ändern kann, zumindest was Lizenzen betrifft?
Neil

5
Sie können es überhaupt nicht garantieren, wenn jemand Zugriff auf die Dateien hat. Die Wahrheit ist jedoch: Der einfachste Mechanismus verhindert, dass 99,99% der Benutzer Ihrer Software Schaden zufügen. Ein engagierter und erfahrener Hacker wird IMMER einen Weg finden, die Anwendungssicherheit zu umgehen. Sie können jedoch zur Remote-Überprüfung wechseln, sodass Ihr Programm nur ausgeführt wird, wenn es für einen Ihrer Dienste authentifiziert wurde. Damit dies sicher ist, müssen Sie Ihr gesamtes Programm verschlüsseln und eine Art Bootloader haben. ABER: Wenn jemand einen gültigen Schlüssel hat, kann er die Software trotzdem erneut zurückentwickeln.
Falcon

7
@Neil: Implementieren Sie die Kerngeschäftslogik in einem als USB-Dongle angeschlossenen Mikrocontroller. Du hast nicht gesagt, dass es billig oder einfach zu implementieren sein muss;)
SF.

8
@SF .: Touche. Ich denke, es sollte drei Satelliten erfordern, um sich gleichzeitig zu verbinden, nur zum Teufel. ;)
Neil

84

Original: Was sagt dein Chef? Finde es heraus - mach das.


Ich wurde gebeten, das oben Genannte auszuarbeiten:

Zuallererst denke ich, dass Sie mehr als ein Dilemma haben:

  • Sollten Sie einen anderen Personencode "reparieren"?
  • Ist die Implementierung (hiervon A) der anderen Personen schlecht genug, dass sie durch etwas anderes ersetzt werden sollte?
  • Wird ein Verschleierer (hiervon B) besser für diese "Lizenzierung in unsere Anwendung einbetten"?

Vor allem aus betriebswirtschaftlichem Fall gesehen das Problem IST gelöst. A ist vorhanden und höchstwahrscheinlich eine "ausreichend gute" Lösung für das Problem. Ihr Unternehmen ist vielleicht gerade so gut geschützt, dass es gezielte Anstrengungen braucht, um das Problem zu lösen.

Dies bedeutet, dass selbst wenn Sie es nicht mögen (und glauben Sie mir, Sie werden im Laufe Ihrer Karriere viel schlechter dastehen ), es das tut, was nötig ist. Wenn das Problem gelöst ist, sollten Sie es also nicht einfach tun, sondern die Person, die für die langfristige Zuordnung Ihrer Arbeit verantwortlich ist, davon überzeugenDer Preis für diese Implementierung ist hoch genug, um ein Rollback zu rechtfertigen und einen Stock Obfuscator zu wählen. Dies erfordert einiges an Vorbereitung von Ihnen, und beachten Sie auch, dass Obfuscators auch Nachteile haben, die Sie kennen müssen (andere Antworten decken dies gut ab). ZB sind Stapelspuren nicht sofort verwendbar usw. Es kommt darauf an, wie wichtig es ist, Raubkopien zu vermeiden. Beachten Sie, dass es am schwierigsten ist, Hardware-Dongles zu brechen, und dass dies höchstwahrscheinlich teurer ist, als es Ihre Kunden möchten.

Daher liegt diese Entscheidung nicht bei Ihnen, da Ihr Unternehmen zusätzliche Ressourcen für die Kontaktaufnahme mit B benötigt. Daher müssen Sie Ihre Bedenken der verantwortlichen Person mitteilen, diese und alle anderen langfristigen Bedenken gut genug erläutern, damit diese verstehen kann, warum Sie halten es für schlechter als Ihren Vorschlag. Lassen Sie ihn dann die Entscheidung treffen und respektieren und verhalten Sie sich unabhängig davon, wie es sich herausstellt, professionell. Beachten Sie, dass der ursprüngliche Autor es höchstwahrscheinlich ohnehin so pflegen muss, wie er es geschrieben hat, und wenn er abreist oder es nicht mehr möchte, können Sie die Angelegenheit erneut zur Sprache bringen.

Mit anderen Worten: Was sagt Ihr Chef? Finde es heraus - mach das.

Beachten Sie auch, dass dies anders gewesen wäre, wenn Sie das Problem früher angesprochen hätten, sodass die Geldverschwendung für die Zeit, die für die Implementierung von A aufgewendet wurde, geringer war. Mit anderen Worten, wenn die Wahl zwischen A und B getroffen werden sollte.

Abschließend möchte ich Ihre Frage zu "nur das Reparieren des Codes anderer Leute" kommentieren. Dies ist keine kleine Korrektur für den vorhandenen Code (was ich gut finde und empfehle, insbesondere wenn Tests vorhanden sind). Es ist ein störendes Rollback und eine Neuimplementierung, und selbst in Teams mit gemeinsamem Code-Besitz wäre dies - zumindest für mich - ohne vorherige Genehmigung nicht akzeptabel.

Hoffentlich klärt dies meinen Standpunkt.


8
Mein Chef ist kein Programmierer, und es fällt mir wahrscheinlich schwer zu erklären, warum wir Zeit und Geld in etwas investieren sollten, das das Verhalten des Programms letztendlich in keiner Weise verändert.
Neil

15
@Neil: ... vielleicht ist es an der Zeit, Ihrem Chef das Konzept der "Wartungskosten" vorzustellen?
SF.

21
Wird dies die Standardantwort auf jede einzelne Frage zu Mitarbeitern oder zum Arbeitsumfeld? Ich weiß, dass ein Noppen gehen und Sie bitten musste, dies als Antwort zu posten, aber komm schon, es ist keine Antwort. Dies ist eigentlich eine halbwegs anständige (wenn auch unbeholfen formulierte) Frage zu den Problemen mit Sicherheit durch Dunkelheit. Diese "Antwort" ist beleidigend.
Aaronaught

8
@Aaronaught. Diese Antwort geht auf den Punkt, wenn es sich um "Implementierung A ist schlecht, ich schlage vor, wir machen Implementierung B" handelt, weil zusätzliche Arbeit (gleich Geld) erledigt werden muss. Wäre es eine Wahl zwischen der Implementierung von A oder B gewesen, wäre die Antwort anders ausgefallen. Ich schlage vor, Sie öffnen eine Frage zu Meta, wenn Sie eine detailliertere Antwort wünschen.

22
"Wird dies die Standardantwort auf jede einzelne Frage zu Mitarbeitern oder zum Arbeitsumfeld?" Warum nicht? Wenn dies als technische Frage formuliert wurde, z. B. "Welche ist besser? Automatisierte Verschleierung vs handcodierte (= schlechte Praxis) Verschleierung", dann ist das eine ganz andere Frage und rechtfertigt eine technische Diskussion. Alle "Soll ich das hinter meinen Mitarbeitern wieder in Ordnung bringen?" Die Fragen beschränken sich letztendlich auf "Nein,
mach das

13

Suche ich nach einer Obfuscator-Bibliothek in Java und repariere seinen alten Code (der beim Umbau seines Codes etwas heikel sein könnte), oder lasse ich ihn so, wie es mich bis zum Äußersten irritiert?

Nein , es wäre schlimmer, hinter jemanden zurückzukehren und den Code zu ändern, für den er verantwortlich ist, als den fragwürdigen Code zu schreiben.

Sie haben es mit dem Programmierer besprochen. Ihr nächster Schritt ist, Ihre Nase herauszuhalten oder es mit dem Management zu besprechen und dann Ihre Nase herauszuhalten.


Wenn ich dann in Zukunft durch diese Klassen fische, halte ich wohl nur meine Nase.
Neil

3
Wenn Sie eine direkte Verantwortung für diesen Code haben, ist es in Ordnung, ihn nach Ihren Wünschen zu ändern, aber wenn es eine gemeinsame Verantwortung gibt, brauchen Sie jemanden, der entscheidet. Es ist einfach, die Arbeitsbeziehungen zu schädigen und Zeit in solchen Situationen zu verschwenden, besser, wenn möglich, kein Problem daraus zu machen. Wenn ein Problem auftreten muss, sollten Sie es so schnell wie möglich aus dem Weg räumen.
DKnight

6

Gab es eine offizielle Codeüberprüfung jeglicher Art - oder gab es bei der Konfrontation eine inoffizielle "Codeüberprüfung"? Ich würde sagen, da dies ein heikles und wichtiges Thema wie Sicherheit und Lizenzierung ist, müssen Sie dies in der Kette erhöhen. Sie haben den ersten Teil erledigt - die Konfrontation mit dem Programmierer. Jetzt, da er nicht zuhört, können / sollten Sie es aufnehmen. Wenn Sie dies nicht tun, sind Sie möglicherweise Teil des Problems.

Ich würde ihm sagen, dass Sie es tun werden - dies KANN seine Meinung ändern. Wenn dies nicht der Fall ist, schreiben Sie Ihrem Chef und dem Programmierer CC eine sehr politisch korrekte, aber genaue und prägnante E-Mail über die Situation. Bitten Sie in der E-Mail um ein Treffen zwischen Ihnen und / oder einer anderen teilnehmenden Partei.

Treffen Sie diese Dinge immer direkt - und dies auf politische und freundschaftliche Weise.


Mit Sicherheit ein lobenswerter Ansatz. Ich habe die Codeänderung selbst bemerkt und meinen Code über SVN aktualisiert. Wenn er nicht einverstanden ist, führt die Überzeugung meines Chefs, diese Sicherheitsvorkehrungen zu treffen, wahrscheinlich nicht zu einer Änderung, da der Programmierer argumentieren könnte, dass dies bereits funktioniert.
Neil

2

Wenn Sie einen Verschleierer finden, der die Signatur von Klassen (Methodennamen usw.) verschleiern kann, schlagen Sie vor, ihn zu kaufen und zu verwenden.

Bis dahin musst du vielleicht damit leben. Ich gebe zu, dass ich in einem kürzlich durchgeführten Grails-Projekt etwas Ähnliches getan habe - die Lizenzprüfungen sind bewusst in die bereits umfangreiche Anmeldemethode eingebettet, sodass es ziemlich schwierig wäre, die Methode zur Umgehung der Prüfung zu ersetzen.


1
Ich kann dir nicht sagen, wie sehr mich das stört, obwohl du wahrscheinlich recht hast, dass ich damit leben muss.
Neil

2

Kann er zeigen, dass ein solcher Hack machbar ist, oder ist es nur ein hypothetisches Szenario, über das er sich Sorgen macht? Kann er eine Live-Demo dieser Arbeit geben? Er sollte es versuchen. Ernst. Wenn es funktioniert, sollte es dem Management vorgelegt werden und dann vorgeschlagen werden, einen Verschleierer zu besorgen.

Wenn ein Obfuscator nicht sicher genug ist, haben Sie nach anderen Möglichkeiten gesucht, um die JAR zu sichern, z. B. die Verschlüsselung oder das Kompilieren zu systemeigenem Code?

RE: Überarbeitung seines Codes: Ist es nur eine Frage des Umbenennens? Viele IDEs verfügen über Refactoring-Tools, die dies recht einfach durchführen können.


Er kommt mir ein bisschen paranoid vor, obwohl ich verstehen kann, warum. Wenn das Produkt gehackt würde, würde es wahrscheinlich seinen Job bedeuten. Ich werde nicht sagen, dass es möglich ist, aber ich weiß genug, um zu wissen, wie Sie nach Methodennamen suchen können, und wenn es eine offensichtliche Methode namens "isLicenseValid" gäbe, müsste man eine Klasse schreiben, die diese Methode hat und immer true zurückgibt "Hack" es. Ich denke, dieses Programm ist kompliziert genug, ohne es weiter zu komplizieren, obwohl er sich dessen sicher zu sein scheint. Ich denke, ich könnte seinen Code leicht reparieren, indem ich ihn umbenenne, ja.
Neil

Nur weil Sie eine Methode mit dem Namen "isLicenseValid" haben, heißt das nicht, dass sie gehackt werden kann, indem Sie einfach eine Klasse mit derselben Methode schreiben. Wenn Sie Ihre Klasse als "versiegelt" markieren (das ist die C # -Syntax), können Dritte Ihre Sicherheitsüberprüfungen nicht einfach umgehen, indem sie Unterklassen schreiben und Ihre Methode überschreiben. Auf jeden Fall, wenn dieser Typ nicht der Sicherheitsbeauftragte des Unternehmens ist, warum würde es seinen Job bedeuten, wenn das Produkt gehackt wird?
Tundey

2
@Tundey, es geht nicht um Unterklassen (wie würden sie geladen?): Es geht darum, dieselbe Klasse zu schreiben und die gehackte Version früher in die Klassenpfadsuchliste aufzunehmen.
Peter Taylor

1
ha.Ich erinnere mich an die Freuden des Klassenladens in Java. Dennoch muss es einen besseren Weg geben, dem entgegenzuwirken. Wie kann jemand eine Klasse schreiben, die mit Ihrer Klasse identisch ist, wenn Ihr Klassenladeprogramm nicht gefährdet ist? Vor allem, wenn Ihre JAR signiert ist? Würden Sie Ihre JARs nicht unterschreiben und Ihre Klassen versiegeln, um das Problem zu lösen, dass jemand eine Klasse mit demselben Namen wie Ihre schreibt?
Tundey

1
@Tundey the Sun JVM ist (meistens) Open Source, Sie können es ändern.
Spudd86

2

Unabhängig davon, wie wertvoll Ihre IP-Adresse ist, besteht das Intelligente nicht darin, Ihren Code in der Hoffnung, Hacker zu verwirren, zu entstellen. Abgesehen von der Tatsache, dass es ein Albtraum sein wird, dies auch weiterhin zu tun, löst es kein wirkliches Problem. Es macht es nur schwieriger, aber nicht unmöglich. Es ist also keine wirkliche Lösung und die Nebenwirkungen sind schlimm. Es ist, als würde man ein Medikament einnehmen, das nicht wirkt und schlimme Nebenwirkungen hat.

Ihr Problem ist, wie Sie Ihre IP sichern können. Finden Sie eine Lösung dafür: Verschleierer, Lizenzserver usw.


Ich stimme Ihnen zu 110% zu. Was die Sicherung der IP angeht, ist dies ein Schutz für unseren Kunden, da auf dessen Rechner die Webanwendung ausgeführt wird, nicht unsere eigene, obwohl Sie einen gültigen Standpunkt vertreten. Ich habe mich mehr um den Kunden gekümmert, der direkten Zugriff auf unser Produkt auf seiner Maschine hat und es auseinander nehmen kann. Ein Lizenzserver ist nur so gut wie die clientseitige Sicherheit. Wenn Sie den Zugriff auf den Lizenzserver umgehen können, hindern Sie keine Tricks im Buch daran, das Programm ohne Lizenzen zu verwenden.
Neil

1

Ich bin auf ein ähnliches Problem gestoßen, als ein anderer Entwickler unsere Verschlüsselungs- / Entschlüsselungsroutinen str__copyund nannte str__delete(beachten Sie den zweiten Unterstrich). Es war lahm und hätte besser gemacht werden können, also haben wir gewartet, bis es eine Geschichte gab, in der eine Aktualisierung der Lizenzierung erforderlich war. Das Management hatte kein Problem mit der zusätzlichen Handvoll Stunden, da wir es als "Aufräumen" beschrieben haben. Problem gelöst, keine verletzten Gefühle.


Natürlich können wir es später immer noch ändern, obwohl ich denke, dass die Änderung mehr im Kopf als im Code sein muss.
Neil

1
@ Neil Dann würde ich vorschlagen, dass du derjenige bist, der die Veränderung im Kopf braucht. Wenn der Code funktioniert, adäquate Tests hat und gut kommentiert ist, ist es nicht die beste Wahl, diesen Weg zu gehen, anstatt obfuscator zu verwenden, aber es ist auch nicht das Ende der Welt. Beheben Sie es später, wenn es ein Problem ist, und fahren Sie ansonsten einfach fort.
Christopher Bibbs

@Christopher_Bibbs: Beruhige dich. Ich kann Ihnen mit ziemlicher Sicherheit versichern, dass dies tatsächlich irgendwann ein Problem darstellen wird.
Neil

1

Mein erster Gedanke war die Pflege dieses Codes. Wenn der Code bereits verschleiert ist und er weitermacht, viel Glück beim Versuch, diesen Code in den Griff zu bekommen. Sie werden dann der Hacker sein, der versucht, den Code zu entschlüsseln.

Stattdessen würde ich empfehlen, den Code zu bereinigen und die harte Arbeit mit einem Obfuscator zu erledigen. Langfristig haben Sie viel verwaltbaren Code und Sie überlassen die ganze verrückte Komplexität jedem, der Ihre Lizenz hacken möchte.

Denken Sie daran, dass kein Obfuscater perfekt ist und ein sehr entschlossener Hacker alles rückentwickeln kann, aber zumindest wird es nur er sein. Außerdem erhöhen Obfuscater die Komplexität erheblich, als dies ein Typ wahrscheinlich kann.


0

Ich stimme mit den Antworten überein, dass Sie Ihren Chef über das Problem befragen und tun sollten, was er sagt.

Ein sehr wichtiger Zusatz zu diesen Antworten ist jedoch, dass Sie Ihre Bedenken in Bezug auf Sicherheit und Wartbarkeit dokumentieren. Unabhängig davon, ob Sie den Code ändern oder nicht, ist es wichtig, dass die Leute wissen, worüber Sie sich Sorgen machen und warum. Dies ist sowohl proaktiv (Ihr Chef kann keine Entscheidung treffen, von der er nicht einmal weiß, dass sie getroffen werden muss) als auch defensiv (wenn / wenn ein Hacker Löcher in das schlecht abgesicherte Lizenzsystem steckt, kann er Ihnen keine Schuld dafür geben Fehler.)


0

"Seien Sie nicht der überlegenste Fachmann, der ein Problem kennt".

Mit anderen Worten, sagen Sie es Ihrem Chef und gehen Sie von dort aus. Wenn Sie ruhig bleiben und in diesem Geheimnis ganz oben auf der Liste stehen, sind Sie verantwortlich, wenn es darauf ankommt. Sagen Sie es Ihrem Chef beiläufig und lassen Sie ihn entscheiden, wie er es angehen soll. Auf diese Weise werden Sie von der Last der Wahl befreit.

Sagen Sie es nicht nur Ihrem Chef, denn viele Manager sind vielleicht nicht so technisch, sondern tun, was wir immer tun: Geben Sie das Problem und mögliche Lösungen mit den Vor- und Nachteilen für jede dieser Lösungen an. Dann lassen Sie sie entscheiden und haben das vergangen. Das ist der Grund, warum Manager / Führungskräfte das große Geld bekommen!


0

Die klare Wahrheit ist, dass mit genügend Zeit und Ressourcen alles geknackt werden kann. Es ist eine einfache Funktion, wie beliebt Ihre App ist. Je populärer es ist, desto geschickter zieht es Hacker an und desto mehr Zeit wird darauf verwendet, es zu brechen. Die Codeverschleierung bietet genau das - eine Möglichkeit, die zum Auflösen erforderliche Zeit zu verlängern, ähnlich wie bei der Kryptografie. Wenn Ihr Code also verschleiert ist, muss der Angreifer geschickt sein und Zeit darauf verwenden, sonst verzweifelt er und gibt auf. Sie müssen sich fragen, ob Ihre App die Mühe auf beiden Seiten wert ist.

Es ist erstaunlich, wie schwer es werden kann, verschleierten Code zu knacken. Sie können ein einfaches 10-zeiliges C-Programm einfach durch Verschleierung in ein 100-zeiliges Assembler-Programm verwandeln. Wenn Sie versuchen, es zu debuggen, springen Sie sinnlos im Code herum und können sehr frustrierend sein, ihn zu durchlaufen. Irgendwann wird es kaputt gehen, aber es wird sehr schwer und da nichts wirklich unmöglich ist, ist das der Punkt. Durch die Verschleierung von Code wird die Anzahl der Personen verringert, die in der Lage sind, den Code zu zerstören.

Sicher gibt es bessere Möglichkeiten, wie den Debugger nicht den Cracker zu verwirren, sondern einen billigen und effizienten. Es ist jedoch nicht ganz einfach, Dinge unbeholfen zu benennen. Sie müssen Steuerflussaufruffunktionen ändern, die für den gesamten Code nichts bewirken, aber dessen Größe und Komplexität erhöhen: Rufen Sie Dummy-Funktionen auf, deren Rückgabewert nirgendwo verwendet wird, und zwar aus Funktionen heraus, die wirklich etwas bewirken. Sie können bereits sehen, wie verwirrend dies werden kann.

Sie haben etwas, was der Angreifer nicht tut. Der ursprüngliche Quellcode. Finden Sie einen Weg, um es besser für sich selbst zu organisieren.

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.