Reverse Engineering
Seit längerem bin ich stark interessiert an Reverse Engineering von Computersoftware. Hierbei geht es mir hauptsächlich darum, zu verstehen wie ein Programm 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, 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 genau dort ist bei Systemen die auf Security-by-Obscurity setzen der Fehler. Der Schlüssel wird entweder fest in die Datei “eingebrannt”, sie wird irgendwo abgeholt, oder selbst generiert. Irgendwann ist der Schlüssel auf dem Computer des Benutzers; der Schlüssel, der eigentlich vom Benutzer geheim gehalten werden soll. Und hier setze ich an.
Ich finde heraus wie das Programm arbeitet, wo der Schlüssel ist (wie er generiert wird etc.) und baue das Verfahren nach, sodass ich einen eigenen Decrypter habe, ohne irgendwelche Restriktionen des Original Programmes.
Diesen ganzen Vorgang nenne ich “öffnen”, “dokumentieren”, “brechen” oder “knacken”. Das sage ich hier nur, damit keine Verwirrung entsteht.
Hier ein paar Dateiformate die ich (nicht unbedingt als erster) Reverse Engineered 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.
- SFT: 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.