Reverse Engineering: Wofür ist es wirklich gut? [geschlossen]

Ich habe einige unschuldige / Anfänger-Fragen:

• Wofür ist Reverse Engineering gut?
• Soll ich als Programmierer die Kunst des Reverse Engineering erlernen?
• Was sind die Vorteile für einen Programmierer, der damit Erfahrung hat?

Wofür ist Reverse Engineering gut?

Reverse Engineering eignet sich hauptsächlich zum Knacken und Hacken (Entfernen des Seriennummernschutzes oder von Passwortabfragen), aber auch zum Verstehen von Viren oder Wundern, die andere Software ausführen kann. Manchmal ist es eine nützliche Fähigkeit, Fehler in Programmen zu finden, für die Sie nicht die Quelle haben, und sie zu patchen.

Soll ich als Programmierer die Kunst des Reverse Engineering erlernen?

Ja, versuchen Sie Assembler zu lernen und einen anständigen Debugger zu verwenden. Es wird Sie zu einem besseren Entwickler machen, indem Sie Dinge auf niedrigeren Ebenen verstehen, die näher am Metall sind.

Was werden die Vorteile eines Programmierers sein, der Erfahrung mit Reverse Engineering hat?

Du wirst ein guter Hacker / Cracker sein. Sie könnten für andere Antivirenhersteller arbeiten. Als persönliches Beispiel: Ich habe einmal eine Software zurückentwickelt, um einen Fehler aufzuspüren, der beim Herstellen einer Orakelverbindung aufgetreten ist. Niemand sonst konnte das Problem lösen, also wurde ich berühmt.

Darüber hinaus möchte ich auch @ johannes Kommentar zitieren , da er absolut Recht hat:

Ich werde es nicht auf "schlechtes" Knacken beschränken. Das Zerlegen kann hilfreich sein, um herauszufinden, ob der Compiler verrückt geworden ist (normalerweise ist es jedoch Ihr Code). Aus systemadministratorischer Sicht kann es interessant sein, festzustellen, wo eine Anwendung ausfällt

Ich mag die Antwort von Falcon , aber ich möchte hinzufügen, dass Reverse Engineering in einer alten, langweiligen Geschäftsanwendungswelt Sie aus einigen unangenehmen Problemen herausholen kann.

Bei der Arbeit tun wir viel, wenn wir die Datenintegration mit einem System eines Drittanbieters durchführen, das keine neue Wartung hat, sodass wir wissen, wo es kaputt gehen sollte oder nicht.

Wir verwenden auch Reverse Engineering, um die Codequalität (mit bestimmten Einschränkungen natürlich) für von uns gekaufte Komponenten von Drittanbietern zu überprüfen, sofern der Quellcode nicht enthalten ist.

Mein eigentlicher Punkt ist: Reverse Engineering ist nicht an eine einzelne Technologie oder Sprache gebunden, sondern ein Prozess, bei dem Sie die Interna einer "Black Box" lernen . Wenn Sie Code haben, von dem Sie abhängig sind, dem Sie aber nicht vertrauen können oder nicht, sollten Sie auf jeden Fall einen Blick unter die Haube werfen und sehen, was dieser Code tut.

Es gibt auch die absolut langweilige Seite des Reverse Engineerings. Dies ist der Fall, wenn das Unternehmen, in dem Sie tätig sind, über einen Code oder ein Programm verfügt, der bzw. das noch verwendet wird, aber niemand behauptet, etwas darüber zu wissen. Sie gehen es durch, dokumentieren es, schreiben Tests und all die technischen Dinge, die durchgeführt werden sollten, bevor ein Projekt gestartet wird. Sie tun dies für eine Software, die bereits geschrieben wurde, daher "Reverse Engineering".

Es ist viel einfacher, wenn Sie den Code haben, aber es ist technisch immer noch Reverse Engineering. Es ist einer dieser Begriffe, der in Geschäftsmeetings häufig vorkommt, wenn es um Legacy-Projekte geht.

Nur um den Geschäftswert des Reverse Engineerings zu erweitern: Mehr als die Hälfte der Neukunden, denen wir begegnen, haben ein vorhandenes System / eine vorhandene App (nicht immer in der Produktion, wohlgemerkt), aber die Beziehung zu einem früheren Softwareentwicklungsanbieter ist ins Wanken geraten.

In etwa 30% der Fälle hat der Kunde überhaupt keine Quelle für sein System, und in vielen Fällen ist ein Großteil der tatsächlichen Geschäftsprozesse, Regeln und Kenntnisse im Code eingeschlossen.

Und in einigen Fällen, in denen die vorherigen Anbieter eindeutig böswillig geworden sind, die Binärdateien verschleiert, den Code zeitlich blockiert usw., um den Kunden auf unbestimmte Zeit zu fesseln.

Um Ihre Frage zu beantworten, ist Reverse Engineering häufig der Ausgangspunkt für neue Aufgaben mit eher verzweifelten (und ausgebrannten) Kunden, und es kann ein "geschäftskritischer" Erfolgsfaktor sein, vergessenes Wissen aus vorhandenem Code zu extrahieren.

Ich würde argumentieren, dass die Fähigkeiten für das Reverse Engineering und die Fähigkeiten für das Debugging genau gleich sind - wenn Sie ein fantastischer Debugger sind, sind Sie auch ein fantastischer Reverse Engineering und umgekehrt.

Manchmal wird es verwendet, um einige Teile / Software so weit ich weiß zusammenarbeiten zu lassen. Einige seltsame Schnittstellen, Fehler in der Implementierung usw.

Aber soweit ich weiß, ist es ein sehr problematisches Thema, und so werden die bereits komplexen Gesetze der Softwareentwicklung beim Reverse-Engineering auf das Äußerste getrieben.

Nun, mit Reverse Engineering können Sie Code wiederverwenden, um Ihre Arbeit zu minimieren. Beispielsweise können Sie in Symfony2 eine Datenbank aus dem normalen MySQL in das Doctrine-Format konvertieren. Dies ist ein in Symfony möglicher Reverse Engineering-Prozess .... und mit Reverse Engineering können Sie den Code sehen, sagen wir 'in 2D'

Ich gebe nur ein reales Beispiel aus meiner Erfahrung.

Einmal hat unser Unternehmen ein Projekt von einem anderen Unternehmen übernommen. Ungefähr ein halbes Jahr nach Projektbeginn stellten wir fest, dass ein Teilprojekt ohne Code war. Als wir die frühere Firma aufforderten, den Code zu liefern, antworteten sie höflich, dass sie den Code für das Teilprojekt nicht finden könnten. Wir brauchten den Code, weil wir in diesem Teilprojekt etwas ändern wollten.

Ich musste Reverse Engineering das Teilprojekt.

Zuerst habe ich die Assembly dekompiliert (ja, es ist ein .NET-Projekt). Das Ergebnis der dekompilierten Assembly ist langweiliger und verwirrender Code ohne Namen lokaler Variablen und eine komplizierte Kontrollstruktur. Dies liegt daran, dass beim Kompilieren wichtige Informationen verworfen werden, die nicht dekompiliert werden können.

Dann versuchte ich herauszufinden, wo ich diesen Code ändern sollte. Zu diesem Zweck habe ich den Code optimiert, um das gleiche, aber präzisere Verhalten zu erzielen. Ich habe auch die Namen der Variablen anhand ihres Verhaltens erraten. Ich habe den Code ein paarmal durchgesehen, bis ich herausgefunden habe, was er macht.

Ich habe nicht alles rückentwickelt, nur den Teil, den wir ändern mussten. Es war nicht schlecht, etwa 200 Zeilen VB-Code. Es dauerte ungefähr fünf Arbeitstage.