Reverse Enginieering kann völlig legitim sein, es kann aber auch zur Vorbereitung eines Angriffs dienen. Aber ganz egal, welchen Zweck es verfolgt: Würden Sie als Hersteller nicht wissen wollen, wenn jemand Ihre Software dekompiliert?

Wie kann ich herausfinden, dass jemand mein Programm mit Reverse Engineering analysiert? Der Schlüssel sind raffiniert gestaltete Köder im Programm. Damit können Sie einen Hacker dazu bringen, sich bei Ihnen zu melden – wenn auch nicht ganz freiwillig. Collin Mulliner erklärt, wie das funktioniert. Angenommen, jemand stößt in dekompiliertem Code auf eine obskure Internetadresse wie zum Beispiel. Die Versuchung wäre sicher groß, diese Adresse aufzurufen.

Auf dem Server ist jedoch ein Skript hinterlegt, das jeden Zugriff sofort mit der IP-Adresse des Gegenübers an den zuständigen Admin meldet. Schon ist der Angreifer enttarnt (wenn er unvorsichtig genug war, ohne TOR oder VPN zuzugreifen). Der Server muss aber gar nicht selbst im Code als Köder vorkommen. Sie können auch Köder hinterlegen, die wie eine geheimnisvolle Programmbibliothek aussehen, vielleicht lib_highsec_access87v987hzt. Zusätzlich stellen Sie eine Seite ins Netz, die über genau dieses vermeintliche Modul informiert, und sorgen dafür, dass die Seite bei Google indiziert ist. Vielleicht behaupten Sie im Titel sogar, Sie hätten Ihre Software bereits decompiliert – Ihr Angreifer könnte sich also jede Menge Arbeit sparen, wenn er Ihre Informationen aufruft!

Das Szenario ist ausbaufähig. Die Köder müssen eindeutige Namen tragen, die es bisher noch nicht gibt. Sie dürfen im normalen Code nicht auffallen. Es können auch mehrere Köder an verschiedenen Stellen im Code stecken. Sie können als Frühwarnsystem dienen, wenn das Reverse Engineering auf einen geplanten Angriff hindeutet; sie können helfen, Urheberrechtsverletzungen oder Vertragsverstöße aufzudecken. Oder Sie hinterlegen eine Stellenanzeige: Da ist ja jemand offensichtlich sehr an Ihrem Produkt interessiert, das könnte auch ein wertvoller Mitarbeiter werden.