Vorwort

Da die meisten Anwendungen nun über einen Anti-Capture-Schutz verfügen, werden wir heute die Art und Weise, wie Pakete erfasst werden, umkehren, um zu sehen, welche Anti-Capture-Strategien es gibt.
Beachten Sie, dass ich in diesem Artikel nicht den spezifischen Vorgang vorstellen werde, sondern nur auf die Methode und Idee der Paketerfassung eingehen werde. Beispielsweise kann die Verwendung des Agenten-Paketerfassungstools Charles in einem großen Bereich online durchsucht werden, daher werde ich hier nicht darauf eingehen. Um das Folgende zu lesen, müssen Sie die folgenden Wissenspunkte verstehen:

Verwendung von Charles-Werkzeugen
Der Vorgang des Herstellens einer verschlüsselten Verbindung mit HTTPS
Prinzip des SSL-Pinnings
Es ist am besten, über einige Android-Reverse-Engineering-Kenntnisse zu verfügen (z. B. die Verwendung von Xposed).

1. Einleitung

In Android gibt es im Allgemeinen drei Arten von Netzwerkanforderungen: HTTP, HTTPS und Socket.
Http und Https sind beide Frameworks der oberen Schicht, die auf der Socket-Kapselung basieren. Sie werden im Allgemeinen verwendet, es ist jedoch nicht ausgeschlossen, dass einige Anwendungen mit hohen Sicherheitsanforderungen Socket verwenden, um Netzwerkanforderungen selbst zu kapseln. Dies ist problematischer. Der Schlüssel liegt darin, dass die Datenanalyse nicht einfach ist.

Zweitens: HTTP-Paketerfassung

Die HTTP-Erfassung ist relativ einfach. Sie können Charles oder Fiddler zur Erfassung verwenden.

3. HTTP-Paketerfassung

Die Erfassung von HTTP-Paketen ohne Schutz ist ebenfalls sehr einfach. Lassen Sie mich das Prinzip kurz erläutern: Wir verstehen das Proxy-Tool als Mittelsmann. Wenn der Client Daten an den Server sendet, gibt der Mittelsmann vor, der Server zu sein. Senden Sie den öffentlichen Schlüssel Ihres eigenen Zertifikats an den Client, rufen Sie dann die vom Client gesendeten Daten ab, geben Sie sich als Client aus und senden Sie den öffentlichen Schlüssel Ihres eigenen Zertifikats an den Server. Kann man sich wohl als Doppelagenten vorstellen. Der Client gibt vor, der Server zu sein, und der Server gibt vor, der Client zu sein.
Und aufgrund der Eigenschaften von https ist es notwendig, ein Zwischenhändlerzertifikat auf dem Mobiltelefon zu installieren, damit die Anwendung dem Zwischenhändler vertrauen und die übertragenen Daten entschlüsseln kann, und Sie können das Paket dann problemlos abfangen. Sie werden jedoch feststellen, dass die meisten Anwendungen danach immer noch keine Pakete erfassen können. Hier gibt es zwei Fälle. Erstens geht die Netzwerkanforderung überhaupt nicht über den Proxyserver. Zu diesem Zeitpunkt verfügt das Proxy-Tool zwar über keine Daten, obwohl die Anwendung normal verwendet werden kann. Ein anderer besteht darin, dass das Proxy-Tool die Netzwerkanforderung abfangen kann, die Anforderung jedoch direkt fehlschlägt. Lassen Sie uns zunächst die möglichen Gründe für das Scheitern des Sendens analysieren :

1. Einschränkungen des Android-Systems

Das Android-System ist in Zertifikate, vom System vorinstallierte Zertifikate und vom Benutzer installierte Zertifikate unterteilt.

Darunter sind Android 6.0 (API-Level 23) und niedrigere Versionen, das standardmäßige Vertrauenssystem der Anwendung, ein vorinstalliertes Zertifikat und ein vom Benutzer installiertes Zertifikat

<base-config cleartextTrafficPermitted="true">
    <trust-anchors>
        <certificates src="system" />
        <certificates src="user" />
    </trust-anchors>
</base-config>

Android 7.0 (API-Level 24) und höher vertraut standardmäßig nur dem vom System vorinstallierten Zertifikat.

<base-config cleartextTrafficPermitted="true">
    <trust-anchors>
        <certificates src="system" />
    </trust-anchors>
</base-config>

Wenn die Anwendung nicht mit einem Vertrauenszertifikattyp konfiguriert ist, können Sie einen Computer unter Android 6.0 zum Erfassen von Paketen verwenden. Wenn die Anwendung so konfiguriert ist, dass sie nur dem vorinstallierten Zertifikat des Systems oder nur Geräten über Android 7.0 vertraut, gibt es zwei Lösungen.

Eine besteht darin, die Anwendung zu ändern und neu zu verpacken. Der spezifische Vorgang besteht darin, mit apktools das Installationspaket zu dekompilieren, die Konfiguration von android:networkSecurityConfig zu ändern und dann neu zu verpacken. Dies kann auf viele Fallstricke stoßen. Beispielsweise führen viele Anwendungen eine Überprüfung der Anwendungssignatur durch.

Die zweite besteht darin, das Charles-Zertifikat nach dem Rooten des Mobiltelefons in das Systemzertifikat zu importieren, sodass es unabhängig von der Konfiguration keinen Einfluss auf die Paketerfassung hat. Hier werde ich kurz auf den Prozess eingehen:

1. Berechnen Sie den Zertifikatsnamen:

openssl x509 -subject_hash_old -in charles-ssl-proxying-certificate_saved.pem
Berechnen Sie den Wert, z. B. 3a1074b3

2. Benennen Sie die Zertifikatsdatei um

Ändern Sie dann das ursprüngliche Charles-Zertifikat charles-ssl-proxying-certificate_saved.pem in 3a1074b3.0

3. Legen Sie es in die Systempartition

Legen Sie es in /system/etc/security/cacerts/ ab.

Wenn das Paket nach der obigen Konfiguration nicht erfasst wurde, verwendet die Anwendung möglicherweise die gängigste Anti-Erfassungsmethode: Überprüfung des Server- oder Client-Zertifikats.

2. Zertifikatsüberprüfung (SSL-Pinning)

Obwohl wir das Zertifikat des Zwischenhändlers im Systemverzeichnis abgelegt haben, um die Überprüfung des HTTP-Zertifikats zu umgehen, ist der Zwischenhändler kalt, wenn die Anwendung über eine eigene Logik zur Überprüfung des Serverzertifikats verfügt, d. Dies ist eine Zertifikatsüberprüfung. Wie kann man es brechen?

Client-Verifizierungsserver

Die Implementierung der Client-Überprüfung besteht zunächst darin, ein Serverzertifikat oder einen Zertifikat-Hash zur Überprüfung lokal zu speichern, und das Zertifikat kann auch vom Server über das Netzwerk an den Client gesendet werden. Da es sich um eine clientseitige Überprüfung handelt, muss sich die Überprüfungslogik auf der Clientseite befinden. Wir können Hook-Tools verwenden, um die Überprüfung zu überspringen. Beispielsweise hat okhttp, ein häufig verwendetes Netzwerkanforderungsframework in Android, APIs zur Zertifikatsüberprüfung bereitgestellt. Wir können diese API direkt einbinden, um die Überprüfung zu überspringen, sodass alle Anwendungen, die okhttp verwenden, Pakete erfassen können. Ich werde hier nicht auf Details eingehen. Ich empfehle zwei allgemeine Tools.

xposed-Lösung: JustTrustMe
Frida-Lösung: DroidSSLUnpinning

Zusätzlich zu einigen gängigen Netzwerk-Frameworks passen einige Hersteller aus Sicherheitsgründen ihre eigenen Frameworks an. Beispielsweise ist das Netzwerk-Framework von Toutiao das auf magische Weise modifizierte okhttp3, und die darin enthaltene SSL-Überprüfung wurde ebenfalls durch Boringssl (openssl-Zweig von Googles Open Source) ersetzt. In diesem Fall können wir nur den Code überprüfen, um den zu ändernden Hook-Punkt zu finden, was schwieriger ist .

serverseitiger Verifizierungsclient

Die Art und Weise, wie der Server den Client überprüft, ist umgekehrt. Wir können die Überprüfungslogik des Servers nicht ändern, aber das Überprüfungszertifikat befindet sich auf dem Client. Wir nehmen das Zertifikat des Clients heraus und geben es an den Vermittler. Der Vermittler kann dieses Zertifikat verwenden, um sich als Client auszugeben und mit dem Server zu kommunizieren. Daher liegt die Schwierigkeit bei der Serverüberprüfung darin, das vom Client gespeicherte Zertifikat oder den Hash des Zertifikats zu finden. Die allgemeine Methode besteht darin, das Zertifikat im Installationspaket oder das Zertifikat im Dump-Speicher zu überprüfen. .

3. Der Fall, dass kein Agent eingesetzt wird

Wir haben bereits erwähnt , dass es eine Situation gibt, in der die Netzwerkanforderung nicht über den Proxy geht, der im Allgemeinen im Code festgelegt ist. Eine Methode besteht darin, den Ort der Codeeinstellung einzubinden und ihn in den System-Proxy zu ändern; ), sodass Drony den Netzwerkverkehr auf allen Mobiltelefonen verwalten und sogar den Verkehr verschiedener APPs auf dem Mobiltelefon separat konfigurieren kann . Spezifische Verwendungsmethoden finden Sie in diesem Artikel https://www.codeprj.com/blog/ada83a1.html.

Viertens: Socket-Erfassung

Sprechen Sie einfach über das Socket-Paket. Erstens basieren sowohl Charles als auch Fiddler auf dem HTTP-Protokoll, sodass sie das Socket-Paket nicht abfangen können. Sie können nur Software wie Wireshark verwenden, um den Datenverkehr der Netzwerkkarte direkt abzufangen. Zweitens sind die Verliererdaten verschlüsselt, und die abgefangenen Pakete sind auch eine Menge verstümmelter Pakete. Ich rate Ihnen daher, diese Anwendung aufzugeben. Ich möchte wirklich versuchen, seinen Quellcode zu kompilieren, um ihn abzufangen, bevor die Verschlüsselung verschlüsselt wird.

Zusammenfassen

Ich bin hier damit fertig, über einige Methoden der Paketerfassung zu sprechen, und sage nur, was ich weiß. Es muss Unvollkommenheiten geben, und viele Stellen wurden nicht eingehend analysiert. Ich habe auch vorhin gesagt, dass es in meinem Artikel eher darum geht, eine Idee zu liefern, die den Effekt hat, Steine zu werfen und Jade anzuziehen. Ich möchte die Paketerfassung wirklich vollständig analysieren. Wie kann ich sie in ein paar Artikeln abschließen?

Zusammenfassung der Ideen zur Android-Paketerfassung

Artikelverzeichnis