Blog von eddy14

Reverse Engineering

Auf dieser Seite erkläre ich, was Reverse Engineering ist und weiter unten zeige ich, welche Systeme ich bereits “reversed” habe.

Seit längerem bin ich stark interessiert an Reverse Engineering von Computersoftware. Hierbei geht es mir hauptsächlich darum, zu verstehen wie ein System (Software/Hardware) arbeitet. Die Programme die ich analysiere, liegen nur in kompilierter Form vor. Das heißt, es liegt mir kein source code (von Menschen lesbare Instruktionen für den Computer) vor und ich muss das Programm deswegen ausseinander nehmen und analysieren, um zu verstehen, wie es funktioniert. Meistens sind es Programme, die gewisse Algorithmen geheim halten. Das gibt mir den ansporn, mich tief in das System hineinzubohren und den Programmablauf Schritt für Schritt zu verfolgen. So kann ich den Programmablauf rekonstruieren.

Meistens nehme ich mir proprietäre (unfreie), verschlüsselte Dateiformate vor. Diese Dateien basieren meistens auf Security-by-Obscurity. Es gibt absolut kein Problem mit verschlüsselten Dateien, sofern das Kerckhoffs´sche Prinzip nicht ausser Acht gelassen wird. Es besagt, dass die Sicherheit eines Verschlüsselungsverfahrens nicht auf die Geheimhaltung des Algorithmus beruhen sollte, sondern auf die Geheimhaltung des Schlüssels. Und häufig ist genau dort bei Systemen die auf Security-by-Obscurity setzen der Fehler. Meistens ist es so, dass der Schlüssel entweder fest in die Datei “eingebrannt” wird, irgendwo abgeholt wird, oder selbst generiert wird. Manchmal beruht es aber auch wirklich auf Geheimhaltung des Schlüssels; allerdings ist dann häufig der Verschlüsselungsalgorithmus selbst fehlerhaft, und erlaubt mir so das “brechen” der Verschlüsselung.

Ich finde heraus wie das Programm arbeitet, wo der Schlüssel ist (wie er generiert wird, falls überhaupt) und wie der Algorithmus zum Verschlüsseln funktioniert und baue das Verfahren nach. In den meisten fällen, reicht es herauszufinden, was das Verfahren und der Schlüssel ist (da diese auf Verschleierung statt tatsächlicher Verschlüsselung setzen), sodass ich irgendwann einen eigenen Decrypter habe, ohne irgendwelche Restriktionen des eigentlichen Programmes.

Diesen ganzen Vorgang nenne ich “öffnen”, “dokumentieren”, “brechen” oder “knacken” (letzteres hört sich eigentlich voll doof an, aber das habe ich in meinen anfänglichen Posts immer verwendet). Das sage ich hier nur, damit keine Verwirrung bei dem Wortgebrauch entsteht.

Eigentlich habe ich es mir zum Ziel gemacht, der ganzen Welt (naja, wohl eher der deutschsprachigen Bevölkerung) zu zeigen, wieviel Spaß Reverse Engineering macht. Deswegen versuche ich in meinen Blogposts, so viele Details wie möglich preiszugeben, damit jeder (mit genügend freier Zeit) nachvollziehen, was ich genau getan habe, um zum Ziel zu kommen.

Es geht also primär nicht darum, ein fertiges Produkt (häufig einen Decrypter) anzubieten, sondern darum, Informationen darüber bereitzustellen, wie man selbst eine Analyse durchführen kann.

Hier ist eine Liste von Softwaresystemen die ich (nicht unbedingt als erster) Reverse Engineered und auf dem Blog dokumentiert habe:

- RSDF: Das Dateiformat von “RS Downloader”. Ich habe es damals nicht ganz hinbekommen. Es war mein erster Versuch in dieser Richtung. Das Dateiformat schützt Downloadlinks von One-Click-Hostern in einer verschlüsselten Datei. Der Algorithmus ist AES, und der Schlüssel war ein konstanter Wert (fest in der Datei verankert).

- DLC: Das Dateiformat von “jDownloader”. Das erste Programm auf meiner Reise, welches ich “öffnen” konnte. Wie RSDF schützt es Downloadlinks von OCHs in einer verschlüsselten Datei. Es wird auch AES verwendet, allerdings ist der Schlüssel hier dynamisch. Ein zentraler Server übermittelt einem den Key, speziell für jede DLC Datei.

- SFT06: Das Dateiformat von “SFT Loader” und “SFT Encrypter”. Es schützt FTP Daten in einer verschlüsselten Datei. Es wurde der RC4 sowie ein abgewandelter RC5 Algorithmus verwendet. Der Key wird (jenachdem ob der Ersteller der Datei ein Passwort gesetzt hat oder nicht) generiert (mit einem festen Salt-Wert).

-FLP: Das FLP-Format wurde extra für flp.to entwickelt. Das dazugehörige Programm nennt sich “FLP Loader”. Es ist dem SFT-Format sehr ähnlich (und auch vom gleichen Entwickler).

-Anti-Leech: Dies ist mehr ein Protokoll. Anti-Leech wird verwendet um die Herkunft von Downloads zu verbergen. Dafür muss jeder Benutzer das System vorerst installieren (wie üblich geht es nur auf Windows). Es ist ein Plugin für den Browser. Bei speziellen Webseiten wird es aktiviert, und erlaubt das verschlüsselte senden der Downloadlinks. Hier wurde sehr wahrscheinlich der DES Algorithmus verwendet. Der Schlüssel wird dynamisch aus einem Hash generiert (mit Uhrzeit, Downloadlink etc.). Leider kein Decrypter, da ich irgendwann die Lust an dem Format verlor.

-SWL: Ein Dateiformat welches nur für eine (kleine?) Downloadseite verwendet wird (nennt sich SWSite). Es wurde der Twofish Algorithmus im CBC Modus verwendet. Der Schlüssel ist fest (statisch) eingebrannt in die exe.

-OTRKEY: Dateien mit der Endung “.otrkey” sind verschlüsselte Video-Dateien (genau genommen: TV-Aufnahmen) von dem Webdienst onlinetvrecorder.com. Es wird der Blowfish Algorithmus verwendet. Im ECB sowie im CBC Modus. Es wird ein konstanter Schlüssel verwendet um den Header zu entschlüsseln, und ein anderer Schlüssel wird mit der Email-Adresse, dem Passwort und dem Datum generiert. Dieser wird für die Webkommunikation benutzt, um auf eine verschlüsselte Art einen anderen Key vom Server abzuholen. Dieser Key wird in einer Datenbank auf den Servern von onlinetvrecorder.com gespeichert und ist für jede OTRKEY-Datei verschieden. Dieser letzte Key wird benutzt, um die Videodatei zu entschlüsseln.

-Disguise: Meine erste Kryptoanalyse. Disguise ist ein Programm welches alle möglichen Dateien verschlüsseln kann. Allerdings hatte der Algorithmus triviale Bugs, die mir per Known-Plaintext Angriff erlaubten, die Datei vollkommen zu entschlüsseln, ohne vorher den Key oder irgendwelche anderen zusätzlichen Informationen zu kennen.

Seit kurzem befasse ich mich auch mit Hardwaresystemen (alle möglichen Geräte):

-ferngesteuerte Lampe: Eine Wohnzimmerlampe, die durch eine kabellose Fernbedienung an- und ausgeschaltet werden konnte, habe ich einer Analyse unterworfen, um herauszufinden wie es genau funktioniert. Meine erster Versuch in der Richtung Hardware Reverse Engineering.