Protection gegenüber cracking
Alles kann, am allerwenigsten von einem theoretischen Gesichtspunkt, gecrackt werden. Glauben Sie nicht jenen Leuten die versuchen Sie vom Entgegengesetzten zu überzeugen. Wir haben das Kracken lang genug studiert um besser es zu wissen. Jedoch existieren Wege um es wegen der zeitbezogenen Angelegenheiten extrem schwierig zu machen. In der Tat macht es lARP64Pro so hart und zeitraubend, dass bis jetzt kein einziges lARP64Pro geschütztes Programm schon gecrackt worden ist! Obgleich selbstverständlich: sag niemals nie!
lARP64Pro nimmt es an, und regt Sie sogar an, Ihr eigenes Lizenzsystem zu verwenden. Es wäre eher dumm nur einen lARP64Pro Lizenzentwurf anzubieten. Selbst wenn dieser Entwurf mit Veränderungen auf dem Thema eingeführt werden könnte. Wir haben herausgefunden dass dieses in der Tat nur Mühelosigkeit für die Cracker meinen würde. Sobald sie einen bestimmten Entwurf aufgehoben haben, wird es weit einfacher den gleichen Lizenzentwurf vom gleichen Protector immer wieder zu cracken als ein neuer Entwurf in jedem neuen Programm. Und in solchem Fall können Sie sicher sein dass, egal wie schwierig der Entwurf ist, der Entwurf früher oder später gekrackt wird. Nein! Nicht früher oder später aber eher früher als später! Folglich zielten wir die lARP64 Technologie auf das Schützen Ihres eigenes Lizenzentwurfs ab!
lARP64Pro verteidigt Ihren Lizenzsystem durch die lARP64 Technologie die eine Summe von stark obfuskierten Code und aller Arten vorgerückten Techniken wie zum Beispiel Antidumping, Antidebugging und Antidisassembling ist. Diese sind das Resultat unserer innerbetrieblichen Forschung.
Die meiste Kodierung erfolgt in den höheren Programmiersprachen (HLL) aber das Cracken wird in Debuggern und in Disassemblern in Assemblersprache getan. Assembler bietet so viele Möglichkeiten an die in HLL nicht oder nur kaum möglich sind. Folglich wurde der schützende Code in lARP64Pro auch vollständig in Assembler kodiert. Um komplett zu sein, erwähnen wir noch dass das GUI in .NET kodiert wurde.
Copyright (c) 2006-2010 lARP64Tech Software All rights reserved
SITE
NAVIGATION
HOME
PRODUKTE
TECHNOLOGIE
DOWNLOAD
ANKAUF
BILDER
HILFE (in English)
Software Reverse Engineering oder Reverse Code Engineering (RCE), ist die Zergliederung und das Studieren der binären Anwendungen ohne ihren Quellencode zu haben. Gründe für Reverse Engineering sind mehrere. Eine der wichtigsten Funktionen von RCE besteht aus studieren von Malware als Computerviren, Würmern, Trojans, Addware und Spyware. Reverse Engineering wird auch geübt weil die Unterlagen einer bestimmten Vorrichtung verloren gegangen sind oder nie geschrieben wurden, und die Person die sie errichtete, ist nicht mehr vorhanden. Die einzige Weise um die Studienfunktionalität in neue Technologie zu verbinden kann Reverse Engineering sein. Es gibt auch die Produktanalyse zum überprüfen wie ein Produkt nach innen arbeitet, aus welchen Bestandteilen es besteht, usw. Es gibt die revidierende Sicherheit und vergisst nicht, dass in der Antivirus-Software-Industrie, es kaum was anderes als Reverse Engineering gibt. Auf der anderen Seite jedoch, gibt es auch den Abbau des Kopierschutzes, die Umgehung der Zugangsbeschränkungen und die Kreation von Lizenz Duplikate. Anders als gratis Software die theoretisch keine Sicherheit braucht, stellt geschlossene Quellen-Software den Benutzer mit einem „schwarzen“ Kasten dar. Historisch ist RCE an den Windows-Plattformen durchgeführt worden aber es gibt jetzt eine wachsende Notwendigkeit an allen RCE Experten. In der Tat hat "Reverse Engineering" eine Doppelbedeutung weil das Reverse Engineering auch eine gute und legitime Sache sein kann! Anderseits hat das Wort „cracken“ fast immer die Bedeutung von etwas ungültiges, von einer betrügerischen Tätigkeit.
Als harte Nuss: wer hat gesagt, dass ein Virusschöpfer auch keine Rechte auf seiner Arbeit haben sollte? Und wo zeichnet man die Linie ob es wohl oder nicht zugelassen ist um der Code von einem Virus zu reversen?
Jede Weise, RCE erlaubt Ihnen innerhalb des schwartzen Kastens zu sehen. Indem Sie eine binäre Anwendung reversen, können Sie den Ablauf des Programms auf seinen niedrigsten Niveaus beobachten. Sobald die Anwendung zu Maschinensprache aufgegliedert wird, kann ein erfahrener Praktiker den Betrieb jeder binären Anwendung folgen, gleichgültig wie gut der Software-Verfasser auch versucht hat ihn zu schützen.
Warum würde ein Sicherheitsexperte RCE lernen müssen? Wie schon gesagt ist der allgemeine Grund, Malware wie Viren oder trojan Pferde, aufzuheben. Z.B. hängt die Antivirusindustrie von der Fähigkeit ab, Binären zu zergliedern um sie zu bestimmen, zu desinfizieren und zu verhindern. Zusätzlich gibt es die starke Verbreitung des unmoralischen Handelsspyware und der Software Antipiracy Schutze, der „nach Hause“ anrufen. Und im Allgemeinen, Ihren eigenen Code auszuprüfen ist sogar eine Form von Reverse Engineering.
Reversing, oder meinten Sie Cracking?
Gesetze
Die Legalität von RCE ist in vielen Bereichen noch fraglich. Die meiste Freeware und Shareware kommen mit einer EndbenutzerLizenzvereinbarung oder einem EULA, so auch Z.B. lARP64Free und lARP64Pro. Entsprechend lARP64Tech und jenen anderen Software-Herstellern akzeptiert man das EULA durch klicken „Ich stimme ein“. Die meiste EULAs schließen eine Klausel ein, die den Endbenutzer allen Reverse Engineering verbietet um das Eigentum des Herstellers zu schützen. Es gibt keinen Zweifel das in diesen Fällen in denen der Autor Reverse Engineering ausdrücklich verbietet, Leute dann beim Reverse Engineering das Gesetz brechen. Tatsächlich stellt das Digital Millennium Copyright Act (DMCA) grosse kriminelle Strafen für Fälle von Reverse Engineering zur Verfügung. Man konnte die Frage aufwerfen, warum so viele Leute diese Strafen riskieren und nicht imstande zu sein scheinen zu stoppen. Lassen Sie uns zuerst ein wenig von der Geschichte sehen um in der Lage zu sein diese betätigende Frage zu beantworten.
Ein wenig Geschichte
Reverse Engineering ist ein Entdeckungprozeß, schon seit längere Zeit bekannt. Wenn man einen neuen Blick am Code nehmt, ob entwickelt durch sich selbst oder durch anderen, überprüft, lernt und sieht man Sachen die man möglicherweise nicht erwartet hätte. Es ist nicht nur interessant zu sehen wie der Meister es getan hat, es liefert auch eine schnelle Weise des Lernens.
„Modernes“ RCE begann in den frühen 80er-Jahren mit Programmierern die Kopierschutz auf klassischen Computerspielen zerbrachen. Obgleich diese Tendenz schnell eine Weise wurde um gekaperte Computer-Software zu verteilen, blieb ein Kern an Experten das RCE lediglich aus akademischen Gründen entwickeln. In der Tat kann man nicht sagen dass jene Leute falsche Ziele mit ihrer Arbeit hatten.
Einige der legendären Buchstaben jenes Anfangs waren geniale Software Reverse Engineers und Autoren und Lehrer in der Angelegenheit. Ihre klassischen Texte gelten heute noch immer als vorgeschriebenen lesen für RCE Kursteilnehmer. Ein neues Erzeugung des Reverse Engineering hat die alten Texte wiederentdeckt und angefangen die Wissenschaft noch einmal voranzubringen. Noch wurde Reverse Engineering von Software um die frühen Neunzigerjahre nur besser. Seit damals hat es einen ausgedehnten und wachsenden Körper der Forschung auf der Umkehrung von Techniken, von Software-Analyse, von Programmverständnis, von Software-Sichtbarmachung, von Datenrücktechnik und von allen seinen in Verbindung stehenden Werkzeugen und von Ansätze, gegeben.
Heutzutage gibt es ein zunehmendes Interesse an Reverse Engineering zur Stützplattformmigration, zur Interoperabilität, zur Malware Abfragung und zur Problemermittlung. Heute ist der Software-Reverse Engineer nur so gut wie seine Werkzeuge. Und RCE hat ziemich viel von denen. Früher waren Hex Editor allgemeine Werkzeuge. Derzeit benötigt man keinen Hex Editor mehr weil heutzutage patching auch innerhalb vom Debugger möglich ist. Ein Debugger ist tatsächlich ein Disassembler der auch die Möglichkeiten der Durchführung und der Kontrolle des Codes am Wunsch anbietet. Ein Disassembler versucht ein Binär zu zergliedern und die in für den Menschen lesbare Assemblersprache wiedergeben. Die Disassembler-Software liest den rohen Bytestromausgang vom Prozessor und analysiert ihn in Gruppen von Anweisungen. Diese Anweisungen werden dann in Assemblersprachenanweisungen übersetzt. Der Disassembler bildet eine beste Vermutung am Assemblersprachencode, häufig mit variablen Resultaten. Dennoch ist es das grundlegende Werkzeug für einen Software-Cracker. Jedoch wie schon gesagt, haben moderne Debugger die eingebauten disassember Möglichkeiten und können die meisten Sachen bereits mit diesem einem Werkzeug getan werden. Man könnte auch decompilers erwähnen, aber Decompilers sind noch selten das Hauptwerkzeug eines Crackers.
Viele Programme werden mit Shareware-kompressoren oder „Packers“ zusammengedrückt um Speicherkapazität zu sparen oder um die Arbeit des Disassemblers schwieriger zu machen. Ein gutes Beispiel eines Freeware Packers ist lARP64Free. Das höchste Niveau um das Cracken zu hindern ist der Protector. Einige schützen und kompressieren außerdem wobei sie alle Arten Tricks und Ruses hinzufügen um den Reverse Engineer oder den Cracker zu besiegen. Die verwendeten Ruses durch einen Protector können viele sein und unter vielen verschiedenen Formen bestehen. Ein gutes Beispiel solch eines kombinierten Kompressorschutzes ist lARP64Pro.
Die Wissenschaft des Auspackens der kompressierten und geschützten Binären -und wir benennen das als Wissenschaft, jawohl- ist in der Tat sehr komplex und enthält einen gesamten Subspezialtät von RCE.
Da es illegal ist Schutze auf urheberrechtlich geschützten Arbeiten zu besiegen, programmieren Reverse Engineers jetzt ihre eigenen Schutzentwürfe zu unterrichtenden Zwecken. So sind Crackmes kleine Programme, die das Herz des Schutzentwurfs enthalten, und wenig sonst.
Hinsichtlich des ungültigen Crackens ist die Frage schließlich: und wer gewinnt die Diskussion, oder ist es sogar ein Kampf?
Pro und contra
Experten sagen dass Cracker und Entwickler der Schutzmechanismen nicht gerade Konkurrenten sind, dass sie auch Kollegen sind. Wenn man annimmt dass Cracker parasitsch sind und die Unfähigkeit von Programmierer um hochwertige Schutzmechanismen zu errichten, ausnutzen, dann muss man feststellen dass Programmierer auch parasitsch sind und die Unfähigkeit von Benutzer ausnutzen um Programme zu schreiben!
Das Cracken mit dem Hauptgewicht auf der ungültigen Tätigkeit und die Programmierung mit dem Hauptgewicht auf dem legalen Rechtsverfahren, haben viel gemeinsam. Die Schaffung der hochwertigen und zuverlässigen Schutzmechanismen erfordern hochwertige Programmierfähigkeiten und dazu die Fähigkeit mit dem Betriebssystem-, Fahrer, Ausrüstung und Wissen der Architektur der Prozessoren zu arbeiten, die spezifischen Eigenschaften des Codeerzeugungs typisch für spezifische Compiler und das wirken der Bibliotheken, die verwendet werden. Auf dieser Ebene von der Programmierung, wird die Unterscheidung zwischen der Programmierung und dem Cracken so dünn, dass es kaum möglich ist eine Linie zwischen die beide zu zeichnen. Man konnte einen Cracker unter Verwendung seiner Werkzeuge mit einem Einbrecher vergleichen, der ein Stethoskop verwendet. Ein Stethoskop konnte vom Einbrecher benutzt werden um zum Verschlussmechanismus eines Safes zu hören, um die Trommeln an der richtigen Stelle fallen zu hören. Aber das gleiche Stethoskop konnte von einem Doktor benutzt werden um Herz oder Gesundheitsprobleme zu ermitteln. Das Werkzeug ist nicht in sich selbst gut oder schlecht noch er oder sie die das Werkzeug benutzt. Die Ausgabe entsteht mit dem Gebrauch für den das Werkzeug gewählt wird. Und es liegt recht auf der Hand dass das Stethoskop nicht verboten werden noch zerstört werden sollte, weil man es für weniger bewundernswerte Gründe auch benutzen könnte.
Jeder Schutz erfordert vorsichtige und vollständige Prüfung um seine Brauchbarkeit genau so wie jeder möglicher andere Softwarebaustein aus zu werten. In diesem Zusammenhang wird seine Brauchbarkeit gedeutet sowie wie fähig der Protector ist um qualifizierte Cracker mit oder ohne Crack-Werkzeuge bewaffnet, zu wiederstehen. Schutzqualität wird ausgewertet nicht durch seine Stärke aber durch das Verhältnis zwischen den Beschäftigtenstunden erfordert um es zu machen und die Beschäftigtenstunden erfordert um es zu cracken. Langfristig wird jedes Schutzsystem gebrochen weil das Cracken nur ein Frage von Zeit, Geld, Crackerfähigkeiten, Werkzeuge und Bemühung ist. Jedoch darf sachverständig-entworfener Schutz keine einfache Gelegenheiten für das Cracken zur Verfügung stellen. Und dieses ist genau wo lARP64Pro in das Spiel kommt: wir haben lARP64Pro so stark und Zeitraubend zum cracken gemacht dass es kaum „crackbar“ ist. Aber sehen wir später noch mehr Argumente vom Gesichtspunkt des Crackers aus.
Um Schutzmechanismen zu entwickeln, muss der Programmierer mindestens eine allgemeine Idee über die Arbeitsmethoden und die technischen Werkzeuge die von seinen Konkurrenten benutzt werden, haben. Es ist sogar angewesen dieses technisches Arsenal auf einem Niveau erarbeiten zu können das dieses des Konkurrenten nicht niedriger ist. Praktische Erfahrung in Cracker Programmen ist in hohem Grade wünschenswert weil sie erlaubt die Taktiken und die Strategie der anderen Partei sorgfältig zu studieren und sie erlaubt die Organisation einer optimalen Verteidigung. Sie erlaubt dem Programmierer die wahrscheinlichsten Ziele gegen die Crackerangriffe zu ermitteln und zu verstärken und konzentriert auf die maximalen vorhandenen intellektuellen Betriebsmittel. Dies heißt, dass der Entwickler der Schutzmechanismen durch Crackerpsychologie angespornt werden muss zu denken wie ein Cracker.
So die Informationschutz Technologie erarbeitend nimmt die Beherrschung der Cracker Technologie an. Wenn Sie nicht wissen wie Schutzmechanismen gebrochen werden, wenn Sie ahnungslos sind was ihre Verwundbarkeit ist, und wenn Sie keine Informationen haben über das Cracker Arsenal, dann können Sie auch keinen starken Schutzmechanismus machen der billig und einfach einzuführen ist. Die Bücher über Sicherheit die dieses Thema ausschließlich vom Schutzgesichtspunkt betrachten, haben die gleiche Beeinträchtigung wie Speichergeräte weil die Informationen die sie schreiben keine praktische Anwendung haben. Das Studieren des Schlechten holt das gute hoch. Und das Kennen des Feindes bildet Ihre Verteidigung besser. So haben wir bei lARP64Tech in der Tat das Cracken, seine Werkzeuge und seine Techniken, für Jahre studiert. Wir sind beim Denken wie ein Cracker ziemlich erfahren geworden, so um immer ein Schritt vor dem Konkurrenten zu bleiben. Nur die ausgedehnte Studie mit dem einzigen Grund zu denken wie ein Cracker und das Lernen vor ihnen zu bleiben, hat uns fähig gemacht die Technologie lARP64 zu entwickeln!
Wenn Cracker gebeten werden, warum sie Software cracken, ist eine der allgemeinsten Antworten, dass sie es für die Herausforderung und die Erregung des Erfolgs tun. Auch das cracken wird getan um zu erlernen und intelligenter mit Software zu werden. Meistens sind Cracker sehr intelligente Leute, die an Software-Schutz entfernen für Tage auf einmal arbeiten, und in den Extremfällen sogar für Wochen. Der Erfolg des Crackers hängt fast immer von seinem Beweggrund ab. Es kann Sie überraschen zu erfahren dass die meisten des Beweggrundes des Crackers nicht finanziell ist. Schließlich geben Cracker ihre Cracks und Informationen gratis. Sie verdienen kein Geld von Ihrer Software, obwohl die Leute die ihre Cracks benutzen, Geld sparen. Eher als Cracks für finanziellen Gewinn, nehmen Cracker an einer Art von formlosen Konkurrenz teil. Ein Cracker der ein neuer und sehr schwieriger Schutzentwurf entfernen kann wird eine betrachtete und in hohem Grade respektierte Person innerhalb der Crackergemeinschaft.
Es gibt eine allgemeine Meinung dass Publikationen über Löcher in den Sicherheitssystemen mehr Schaden als Gut tun und dass sie verboten werden müssen. Das heißt, sagen die Verfechter dieser Meinung, dass sie keinen starken Schutzmechanismus machen können obwohl das genau ist was getan werden soll.
Können Gesetze helfen?
Es ist sehr schwierig hier Linien zu zeichnen, aber Linien müssen irgendwo gezeichnet werden. Wie schon aufgemerkt worden ist, hat das Reverse Engineering auch einen eindeutigen und zugelassenen Grund für Bestehen. Gesetze existieren, entsteht so die Frage ob jene Gesetze fähig sind das Übel zurück zu drücken. Die Antwart ist nicht so klar. Sehen wir uns zuerst an was die Verteidiger des Crackens sagen.
Fürsprecher des Urheberrechtsgesetzes müssen verstehen dass desto intensiver die gebrochenen Schutzmechanismen, desto mehr der Fortschritt im Feld ihrer Entwicklung! Unter solchen Bedingungen haben Entwickler einen starken Beweggrund um hochwertigen und konkurrierenden Schutzpakete zu machen. Es gibt auch keine Notwendigkeit die Sachen zu verstecken die jeder Cracker unter Verwendung eines Debuggers und eines Disassemblers bekanntmachen kann. Skrupulöse Untersuchung des Schutzmechanismus muss begrüßt werden. Schließlich gibt es das Konzept der Vollständigkeit der Informationen. Versuche, offensichtliche Defekte und Beeinträchtigungen zu verstecken sind dumm. Gute Sachen Leiden darunter nicht, aber schlechte Sachen fürchten Offenheit wie die Pest.
Die Digital Millennium Copyright Act verbietet die Ausbreitung von Technologien, von Vorrichtungen und von Dienstleistungen die gemacht werden um vorhandene Schutzmechanismen zu überbrücken, was logisch scheint. Rechtsanwälte versuchen die Welt gegen offensichtliche Verbrecher und Vandalen zu schützen. Jedoch ist es notwendig Cracken und Forschungstätigkeiten im Feld der informierenden Technologie zu unterscheiden. Jemand der mit böswilliger Absicht crackt, ist mindestens tadelnswert und verdient höchstens zur Gefangenschaft verurteilt zu werden. Aber die Strafe muss mit dem Schaden vergleichbar sein, der durch das Cracken verursacht wurde. Es gibt keinen Not daran dass man Cracker mit Terroristen gleichstellt!
lARP64Tech
Nach der ganzen Diskussion pro und contra oben beschrieben, was ist die Entscheidung? Für lARP64Tech ist die Antwort klar: Reverse Engineering hat in der Tat ein Recht zu bestehen. Aber dieses Recht zu bestehen geht nur bis zu „aber sie müssen meine Software allein lassen!“ In der Tat, und wir sind da diesbezüglich sehr deutlich: niemand hat das Recht irgendjemandes Software zu cracken um sie dann gratis zu verteilen! Jene Cracker können außerdem ihre eigenen Programme („Crackmes“) schreiben und die cracken. Es gibt absolut keine Notwendigkeit Ihr Einkommen zu stehlen und jene Leute haben zweifellos keine Notwendigkeit über Ihr Einkommen von Ihrer harten Arbeit, zu beschlechten. Punkt! Fragen Sie jeden möglichen Entwickler der gelitten hat wie er an dieses denkt! Er beantwortet sofort, dass er/sie Geld verloren hat, eine kleine Menge vielleicht aber häufig ist sehr viel Geld verloren!
Aber wenn Gesetze Ihnen nicht im vollen Umfang helfen können, was dann?
Die Antwort ist Doppel: einerseits sollten Entwickler einen starken kombinierten Kompressor und Protector gebrauchen, um ihre Software vor Crackern zu schützen. Als Software Protector ist lARP64Pro Ihre erste Wahl für 64 Bit Anwendungen. Anderseits sollten Entwickler auch einige grundlegende Richtlinien anwenden. Siehe Protectionsmassnahmen für Entwickler.
