Antworten mit Chrome über das DevTools-Protokoll abfangen und ändern

F5

Bei Shape stoßen wir auf viele dubiose JavaScript-Codefragmente. Wir finden Skripte, die in böswilliger Absicht in Seiten eingeschleust wurden, die uns möglicherweise von einem Kunden mit der Bitte um Rat zugesandt wurden oder die unsere Sicherheitsteams im Internet entdeckt haben, weil sie offenbar gezielt auf bestimmte Aspekte unseres Dienstes Bezug nehmen. Im Rahmen unserer täglichen Arbeit nehmen wir die Skripte sofort genau unter die Lupe, um zu verstehen, was sie tun und wie sie funktionieren. Sie sind in der Regel minimiert, häufig verschleiert und müssen stets in mehreren Schritten bearbeitet werden, bevor sie für eine eingehende Analyse bereit sind.

Bis vor Kurzem ließ sich diese Analyse am einfachsten entweder mit lokal zwischengespeicherten Setups durchführen, die eine manuelle Bearbeitung ermöglichen, oder mithilfe von Proxys, die Inhalte dynamisch umschreiben. Die lokale Lösung ist am bequemsten, doch Websites lassen sich nicht immer problemlos in andere Umgebungen übertragen. Dadurch verliert man sich häufig in endlosen Fehlerbehebungen, bevor man überhaupt produktiv arbeiten kann. Proxys sind äußerst flexibel, aber meist umständlich und nicht besonders portabel – jeder hat ein eigenes, an seine Umgebung angepasstes Setup, und manche kennen sich mit einem bestimmten Proxy besser aus als mit einem anderen. Ich habe begonnen, Chrome und dessen DevTools-Protokoll zu verwenden, um Anfragen und Antworten direkt während ihrer Übertragung abzufangen und dynamisch zu verändern. Diese Lösung ist auf jede Plattform mit Chrome übertragbar, umgeht eine ganze Reihe von Problemen und lässt sich gut in gängige JavaScript-Tools integrieren. In diesem Beitrag zeige ich, wie sich JavaScript mithilfe des Chrome-DevTools-Protokolls dynamisch abfangen und verändern lässt.

Wir verwenden Node, aber ein Großteil der Inhalte lässt sich auf die Programmiersprache Ihrer Wahl übertragen, sofern Sie problemlos auf die DevTools-Hooks zugreifen können.

Falls Sie sich noch nie mit der Skriptsteuerung von Chrome beschäftigt haben: Eric Bidelman hat einen hervorragenden Leitfaden für den Einstieg in Headless Chrome verfasst. Die dortigen Tipps gelten sowohl für Headless Chrome als auch für Chrome mit grafischer Benutzeroberfläche (mit einer Besonderheit, auf die ich im nächsten Abschnitt eingehen werde).

Chrome starten

Wir verwenden die Bibliothek chrome-launcher von npm, um dies zu vereinfachen.

chrome-launcher macht genau das, was Sie erwarten würden, und Sie können dieselben Befehlszeilenoptionen, die Sie vom Terminal gewohnt sind, unverändert übergeben (eine hervorragende Liste wird hier gepflegt). Wir übergeben die folgenden Optionen:

–window-size=1200,800

• Die Fenstergröße automatisch auf einen sinnvollen Wert festlegen.

–auto-open-devtools-for-tabs

• Die Entwicklertools automatisch öffnen, da wir sie häufig verwenden.

–user-data-dir=/tmp/chrome-testing

• Legen Sie ein festes Verzeichnis für Benutzerdaten fest. (Idealerweise wäre das nicht nötig, aber im Nicht-Headless-Modus unter Mac OSX lassen sich Anfragen ohne dieses Flag offenbar nicht abfangen. Wenn Sie eine bessere Möglichkeit kennen, lassen Sie es mich bitte über Twitter wissen!)

Führe dein Skript testweise aus, um sicherzustellen, dass du Chrome öffnen kannst. Du solltest ungefähr Folgendes sehen:

Verwendung des Chrome DevTools-Protokolls

Dies wird auch als „Chrome-Debugger-Protokoll“ bezeichnet, und in der Dokumentation von Google scheinen beide Begriffe synonym verwendet zu werden. Installieren Sie zunächst das Paket chrome-remote-interface über npm. Es stellt praktische Methoden für die Interaktion mit dem DevTools-Protokoll bereit. Halten Sie unbedingt die Protokolldokumentation griffbereit , wenn Sie tiefer in das Thema einsteigen möchten.

Um das CDP zu verwenden, müssen Sie eine Verbindung zum Debugger-Port herstellen. Da wir die Bibliothek chrome-launcher verwenden, ist dieser bequem über chrome.port zugänglich.

Viele der Domänen im Protokoll müssen zunächst aktiviert werden. Wir beginnen mit der Runtime-Domäne, damit wir uns in die Konsolen-API einklinken und alle Konsolenaufrufe im Browser an die Befehlszeile weiterleiten können.

Wenn Sie Ihr Skript jetzt ausführen, erhalten Sie ein voll funktionsfähiges Chrome-Fenster, das außerdem alle Konsolenmeldungen in Ihrem Terminal ausgibt. Das allein ist schon großartig, insbesondere für Testzwecke!

Anfragen abfangen

Zunächst müssen wir registrieren, was wir abfangen möchten, indem wir eine Liste von RequestPatterns an setRequestInterception übergeben. Das Abfangen ist entweder in der Phase „Request“ oder in der Phase „HeadersReceived“ möglich. Um eine Antwort tatsächlich zu ändern, müssen wir bis „HeadersReceived“ warten. Der Ressourcentyp entspricht den Typen im Netzwerkbereich der Entwicklertools.

Vergiss nicht, die Network-Domäne wie oben bei Runtime zu aktivieren, indem du Network.enable() demselben Array hinzufügst.

Die Registrierung des Event-Handlers ist relativ unkompliziert, und jede abgefangene Anfrage enthält eine ​interceptionId , mit der Informationen über die Anfrage abgerufen oder schließlich ihre Fortsetzung veranlasst werden kann. Hier greifen wir lediglich ein und protokollieren jede abgefangene Anfrage im Terminal.

Anfragen ändern

Um Anfragen zu ändern, müssen wir einige Hilfsbibliotheken installieren, die Base64-Zeichenfolgen kodieren und dekodieren. Es stehen zahlreiche Bibliotheken zur Verfügung; Sie können gerne eine beliebige auswählen. Wir verwenden atob und btoa.

Die API für den Umgang mit Antworten ist etwas umständlich. Um Antworten zu verarbeiten, müssen Sie Ihre gesamte Antwortlogik in die Anfrageabfangung integrieren (anstatt beispielsweise einfach eine Antwort abzufangen). Anschließend müssen Sie den Body anhand der Abfang-ID abrufen. Das liegt daran, dass der Body zum Zeitpunkt des Aufrufs Ihres Handlers möglicherweise noch nicht verfügbar ist. Auf diese Weise können Sie gezielt auf genau das warten, was Sie benötigen. Der Body kann außerdem Base64-codiert sein. Daher sollten Sie dies überprüfen und ihn gegebenenfalls decodieren, bevor Sie ihn einfach weiterleiten.

An diesem Punkt kannst du dich mit dem JavaScript nach Herzenslust austoben. Dein Code wird mitten in der Verarbeitung einer Antwort ausgeführt, sodass du sowohl auf das gesamte angeforderte JavaScript zugreifen als auch deine geänderte Antwort zurücksenden kannst. Großartig! Wir passen das JS einfach an, indem wir am Ende ein console.log anhängen, damit unser Terminal eine Meldung erhält, wenn unser geänderter Code im Browser ausgeführt wird.

Wir können nicht einfach nur einen geänderten Body weitergeben, da dessen Inhalt möglicherweise mit den Headern in Konflikt steht, die zusammen mit der ursprünglichen Ressource gesendet wurden. Da Sie aktiv testen und Anpassungen vornehmen, sollten Sie wahrscheinlich zunächst mit den Grundlagen beginnen, bevor Sie sich zu viele Gedanken über weitere Header-Informationen machen, die Sie übermitteln müssen. Bei Bedarf können Sie über ​responseHeaders auf die Response-Header zugreifen, die an den Event-Handler übergeben werden. Vorerst erstellen wir jedoch einfach einen eigenen minimalen Satz in einem Array, damit er sich später leicht bearbeiten und anpassen lässt.

Um die neue Antwort zu senden, muss eine vollständige, Base64-codierte HTTP-Antwort (einschließlich der HTTP-Statuszeile) erstellt und über die Eigenschaft rawResponse in dem an continueInterceptedRequest übergebenen Objekt gesendet werden.

Wenn Sie nun Ihr Skript ausführen und im Internet surfen, sehen Sie in Ihrem Terminal in etwa Folgendes, während Ihr Skript JavaScript abfängt, Ihr modifiziertes JavaScript im Browser ausgeführt wird und die ​console.log()-Aufrufe über den Hook weitergeleitet werden, den wir zu Beginn des Tutorials erstellt haben.

Den vollständigen funktionsfähigen Code für das grundlegende Beispiel finden Sie hier:

Wie es von hier aus weitergeht

Du kannst zunächst den Quellcode übersichtlich formatieren, denn das ist immer ein sinnvoller erster Schritt beim Reverse Engineering. Natürlich ist das in den meisten modernen Browsern möglich, aber du solltest jeden Änderungsschritt selbst kontrollieren, damit alles über verschiedene Browser und Browserversionen hinweg konsistent bleibt und du bei der Analyse des Quellcodes die Zusammenhänge nachvollziehen kannst. Wenn ich fremden, verschleierten Code untersuche, benenne ich Variablen und Funktionen gern um, sobald ich ihren Zweck zu verstehen beginne. JavaScript sicher zu verändern ist alles andere als trivial und wäre einen eigenen Blogbeitrag wert. Vorerst könntest du jedoch ein Tool wie ​unminify verwenden, um gängige Techniken zur Minimierung und Verschleierung rückgängig zu machen.

Sie können unminify über npm installieren und den neuen JavaScript-Body mit einem Aufruf von ​unminify umschließen, um es in Aktion zu sehen:

Im nächsten Beitrag werden wir uns eingehender mit den Transformationen befassen. Wenn Sie Fragen, Anmerkungen oder weitere nützliche Tricks haben, kontaktieren Sie mich gerne über Twitter!

Über den Autor

F5

Weitere Blogbeiträge von F5