Reverse Engineering - Herausforderung Blackbox

(elkement. Erstellt: 2018-02-02. Tags: Ingenieur, IT, Reverse Engineering, Technologie, Troubleshooting. Englische Version.)

Ich sage ja oft: Eigentlich / wirklich / im Grund ist alles was ich mache ... Reverse Engineering von Blackboxen! Das betrifft Software, Drähte, Hydraulik - und alles dazwischen, wie die Steuerung.

Irgendwann war ich offiziell technischer Spezialist für bestimmte (Software-)Produkte. Da nimmt der Kunde an, man hätte langjährige Erfahrungen und zig Schulungen hinter sich. De facto hab ich manchmal das betreffende Produkt am Wochenende vor dem Auftritt als Experte auseinander genommen und untersucht.

Was verbinde ich mit Reverse Engineering?

Pragmatischer Ansatz - 80/20. Jahrelang hatte ich an akademischen Publikationen gefeilt: Jede Formulierung x-mal umgedreht - oft nach zermürbenden Besprechungen, um die These wasserdicht zu machen, jedes Messergebnis hinterfragt. Und dann flog ich durch ein Wurmloch in die Welt des kleinen Computer-Fuzzis: Du stehst beim Kunden vor der störrischen Maschine und musst ein Problem lösen. Besser schnell als perfekt.

Jahre später könnte man dazu vielleicht sogar ein wissenschaftliches Paper schreiben. Das ist aber uninteressant, weil es nicht darum geht, andere Experten in demselben Fach zu beeindrucken. Ein dringendes Problem muss behoben werden, hier und jetzt ... aber nicht mehr.

Tiefe und Breite. Ja, man muss beim Reverse Engineering und Troubleshooting 'out-of-the-box' denken, wie man heute sagt. Das bedeutet aber nicht, dass es unwichtig wäre, Grundlagen und 'Theorie' zu betroffenen Problem zu lernen. Für optimal halte ich die Kombination von tiefem Wissen in einem Spezialgebiet - jenes, das man sich auch offiziell auf die Fahnen heftet - und breitem Halbwissen über die Gebiete darum herum. Also so, dass man mittels gezieltem Schnüffeln / Debuggen / Forschen auch in diese Gebiete tiefer eindringen kann und eventuell ein langsam ein neues Spezialgebiet erorbert.

Ursprünglich war mein Thema: Public Key Infrastructure, nun sind es seit einiger Zeit Wärmepumpen und Thermodynamik. Und plötzlich ergibt sich die Notwendigkeit, sich mit CAN-Bus-Netzwerkprotokollen zu beschäftigen, oder mit Wärmepumpen ohne elektrisch angetriebenem Kompressor.

Kein falscher Stolz. Es ist interessant und lohnend - und vor allem praktisch - an Problemen zu tüftlen, die man alleiner lösen kann. Ohne große Support-Organisation und Entwicklungsabteilung im Hintergrund. Besser einmal kurz sniffen und tracen als zu versuchen, einer Kontakt zu dem menschlichen Schöpfer der Blackbox herzustellen - einer unbekannten menschlichen Lebensform die vielleicht oder vielleicht auch nicht in einer Firma mit 1000en Mitarbeitern arbeitet.

Aber Aufwand/Nutzen für Sniffen versus Kontak sollte pragmatisch abgewogen werden - es ist manchmal nicht leicht, den Geek-Ethos zu dämpfen und sich durchzutelefonieren oder -e-mailen. Ich habe Social Engineering betrieben (mit guter Absicht!) ohne es wissen, um an Manuals, Passwörter etc. zu gelanden.

Letzendlich kann es Win-Win-Situation werden für alle Beteiligten - es gibt keine Art des Lernens, die so effizient ist wie das Fachsimpeln mit Kollegen. Und es gibt keine Art des 'Netzwerkens' die so sinnvoll und selbstverständlich ist wie Fachkollegen 'im Notfall' - also wenn man beim  Kunden nicht mehr weiter weiß - kontaktieren zu können. Umgekehrt ist man selbst auch Anlaufstelle bei Notfällen im eigenen Spezialgebiet. Glücklicherweise waren die Fälle selten, in denen das Verständnis von Win-Win sehr unterschiedlich war.

Wieder verwenden statt Green Field. Ich verbinde Reverse Engineering automatisch mit: Reparieren und Sanieren - anstelle von Wegwerfen / Löschen und Neukauf / Neuinstallation. Es kann meine persönliche Präferenz sein, da die 'Einschränkung' durch Vorhandenes einen ganz besonderen Reiz hat und die Kreativität anspornt.

Ein übernommenes Altsystem ist immer eine Blackbox, die es zu entschlüsseln gilt. Aber auch Dinge, die man selbst gebau hat vor Jahren, können einem selbst irgendwann Rätsel aufgeben, die man schneller mit Debugging löst als mit dem Nachlesen der eigenen Dokumentation (.... das sage ich als legendär-exzessiver Dokumentator).

Was die Experten sagen ... muss nicht immer richtig sein. Zu wissen, was diese Dinge machen und wie sie funktionieren ist die Basis für die Kontrolle darüber - und kein externer Profi / Lieferant / Dienstleister kann einem dann ein Gschichtl erzählen.

Wenn der Fachexperte (der oft auch gleichzeitig der Verkäufer von neuem Zeug ist) behauptet Das geht nicht, dann kann man das nur widerlegen, indem man zeigt, dass es geht.Vielleicht ist das der wichtigste Aspekt überhaupt - in Zeiten von immer mehr Schnittstellen zu externen Diensten, Clouds und immer schöner verpackten und versiegelten Blackboxen, die man unter Androhung legaler Konsequenzen keinesfalls reverse engineeren darf.

Wärmepumpe hacken

Persönliche Website von Elke Stangl, Zagersdorf, Österreich, c/o punktwissen.
elkement [ät] subversiv [dot] at.