So finden Sie die versteckte API einer mobilen Anwendung: mitmproxy, Frida und Proxys im Jahr 2026

```html

Die Website wird von Cloudflare geschützt, Turnstile erscheint bei jeder zweiten Anfrage, und das Layout ändert sich alle zwei Wochen. Gleichzeitig hat derselbe Dienst eine mobile Anwendung, die direkt auf das Backend zugreift und fertiges JSON erhält – ohne Herausforderungen, ohne Markup, mit stabilen Feldschemata. Das ist die „versteckte API“: ein nicht dokumentiertes, aber voll funktionsfähiges Interface, das vom offiziellen Client verwendet wird.

Wir gehen Schritt für Schritt durch, wie man es mit mitmproxy findet, was mit Certificate Pinning zu tun ist und warum beim Skalieren der Sammlung ohne Proxy alles zusammenbricht.

Warum überhaupt in den Traffic der Anwendung eingreifen?

Web-Scraping und der Aufruf einer privaten API sind unterschiedlich teure Aufgaben. Vergleichen Sie:

• Web. Ein Headless-Browser ist erforderlich, um Anti-Bot-Maßnahmen zu umgehen, HTML zu parsen und Selektoren regelmäßig zu reparieren. Eine Anfrage = Megabytes an Traffic und Sekunden an CPU-Zeit.
• Private API. Eine normale HTTP-Anfrage mit ein paar Headern, die Antwort – kompaktes JSON mit typisierten Feldern. Oft gibt es mehr Daten zurück, als die Benutzeroberfläche anzeigt: interne Identifikatoren, Flags, Dienstfelder.

Mobile Backends sind historisch weniger gut geschützt als das Web. Der Grund ist banal: Anti-Bot-Plattformen sind auf Browser-Traffic ausgelegt (JS-Herausforderungen, Canvas, Verhaltenssignale), und der mobile Client würde einfach nicht durchkommen. Stattdessen verlassen sich die Entwickler auf einen statischen Anwendungsschlüssel und TLS-Pinning – beides wird auf dem lokalen Gerät entfernt.

Was benötigt wird

1. mitmproxy – ein Open-Source-HTTPS-Proxy-Interceptor (über 44.000 Sterne auf GitHub, die aktuelle Version 12.2.2 wurde im April 2026 veröffentlicht, benötigt Python 3.12+). Installation mit einem Befehl: pip install mitmproxy. Unterstützt HTTP/1, HTTP/2, HTTP/3, WebSocket und rohes TCP, arbeitet mit TLS 1.2 und 1.3.
2. Android-Gerät oder Emulator mit Root-Rechten. Die Praxis zeigt, dass Android 7–11 am bequemsten ist: Neuere Versionen haben die Arbeit mit Zertifikaten stark erschwert.
3. ADB zur Verbindung mit dem Gerät und Frida (pip install frida-tools) – wird benötigt, wenn die Anwendung das Zertifikat pinnt.

Mit mitmproxy gibt es drei Schnittstellen über einem Motor: mitmproxy (Terminal-TUI), mitmweb (Weboberfläche, bequemer für Anfänger) und mitmdump (headless, für Skripte und Automatisierung).

Schritt 1. Den Interceptor starten

Wir starten die Weboberfläche so, dass sie externe Verbindungen hört und nicht nur localhost:

mitmweb --web-host 0.0.0.0

Standardmäßig wird der Proxy auf Port 8080 gestartet. Beim ersten Start erstellt mitmproxy eine eigene Zertifizierungsstelle und legt die Schlüssel im Verzeichnis ~/.mitmproxy ab. Dort erscheinen vier Dateien: mitmproxy-ca.pem (Zertifikat zusammen mit dem privaten Schlüssel), mitmproxy-ca-cert.pem (nur das Zertifikat), mitmproxy-ca-cert.p12 für Windows und mitmproxy-ca-cert.cer – das Format für Android.

Schritt 2. Gerät über Proxy leiten

In den WLAN-Einstellungen des Telefons wählen wir den manuellen Proxy: IP Ihres Computers im lokalen Netzwerk und Port 8080. Dann öffnen wir im Browser des Geräts die spezielle Domain mitm.it – dies ist eine in mitmproxy integrierte Seite, die die Plattform automatisch erkennt und das benötigte Zertifikatsformat mit Anweisungen bereitstellt.

Auf iOS besteht das Verfahren aus drei Teilen, und die zweite Hälfte wird oft vergessen: Profil über Safari herunterladen, in „Einstellungen → Allgemein → VPN und Geräteverwaltung“ installieren und dann separat vollständiges Vertrauen aktivieren in „Einstellungen → Allgemein → Über dieses Gerät → Vertrauen von Zertifikaten“. Ohne den letzten Schritt ist das Zertifikat installiert, funktioniert aber nicht.

Wenn Sie keine Lust haben, mit den WLAN-Einstellungen herumzuspielen, hat mitmproxy einen VPN-Servermodus: mitmweb --mode wireguard. Das Gerät verbindet sich mit dem Standard-WireGuard-Client, und der Traffic wird transparent abgefangen, ohne manuelle Proxy-Einstellungen im System.

Schritt 3. Die Hauptmauer – Vertrauen in das Zertifikat

Hier scheitern die meisten Versuche. Es gibt genau zwei Probleme, und das sind unterschiedliche Probleme.

Benutzerdefinierte CAs sind seit 2016 nicht mehr angesehen

Seit Android 7 Nougat (API 24) vertrauen Anwendungen standardmäßig nur dem systemeigenen Zertifikatsspeicher. Benutzerdefinierte CAs werden ignoriert, es sei denn, der Entwickler hat dies ausdrücklich in der Network Security Config erlaubt – über den Block <certificates src="user" /> in den Vertrauensanker. Dies war eine bewusste Entscheidung von Google zur Reduzierung der Angriffsfläche, und man kann es nicht durch die Einstellungen des Telefons umgehen. Chrome vertraut übrigens auch nicht auf benutzerdefinierte Zertifikate. In Android 11 wurden die Einschränkungen noch weiter verschärft.

Praktische Schlussfolgerung: Auf einem Gerät mit Root-Rechten muss das Zertifikat von mitmproxy im systemeigenen Zertifikatsspeicher abgelegt werden, nicht im benutzerdefinierten. Deshalb ist Root in der Liste der Anforderungen und nicht „wünschenswert“.

Certificate Pinning

Die zweite Mauer ist das Pinning: Die Anwendung trägt den Fingerabdruck des erwarteten Serverzertifikats in sich und weigert sich, mit jemand anderem zu kommunizieren. Selbst der systemeigene CA hilft hier nicht. Eine Untersuchung von ACM aus dem Jahr 2022 zeigte, dass Pinning in „hochriskanten“ Vertikalen (Banken, Taxis, Krypto) verbreitet ist, aber oft unvollständig implementiert wird und daher umgangen werden kann.

Es gibt mehrere Werkzeuge für diese Aufgabe, und sie lösen sie auf unterschiedliche Weise:

• Frida – Verhaltensänderung zur Laufzeit: Wir hooken die Funktionen zur Zertifikatsprüfung und zwingen sie, Erfolg zurückzugeben. Die Anwendung wird dabei nicht modifiziert – die flexibelste Option. Typischer Start: frida -U -f com.target.app -l ssl_bypass.js --no-pause.
• apk-mitm – schneidet das Pinning automatisch statisch aus der APK-Datei heraus.
• android-unpinner – rekonstruiert die APK, indem es Frida und Skripte zum Entfernen des Pinnens einfügt.
• objection – Toolkit über Frida, funktioniert sowohl mit iOS als auch mit Android.
• ssl-kill-switch2 – deaktiviert das Pinning in iOS- und macOS-Anwendungen.

Wenn eine bestimmte Domain hartnäckig gepinnt ist und die Arbeit stört, kann sie einfach mit der Option ignore_hosts (akzeptiert reguläre Ausdrücke) vom Abfangen ausgeschlossen werden – der Traffic geht ohne Entschlüsselung an mitmproxy vorbei.

Schritt 4. Den benötigten Request finden

Danach folgt die Routine. Wir öffnen die Anwendung, führen genau eine sinnvolle Aktion aus (ein Produktblatt öffnen, den Feed scrollen, einen Filter anwenden) und sehen, welche Anfragen aufgetaucht sind. Im Terminal-Interface geht das schnell: Z löscht die Liste der Streams, Enter öffnet die ausgewählte Anfrage, E exportiert sie – einschließlich der fertigen curl-Anweisung.

Was man in der abgefangenen Anfrage suchen sollte:

• Endpoint und Parameter. Oft sind sie deutlich mehr als die Benutzeroberfläche der Anwendung verwendet.
• Client-Key. Ein Klassiker – eine statische ID, die in der Anwendung eingebettet ist. In einer bekannten Analyse der öffentlichen API von MyAnimeList stellte sich dieser Schlüssel als Header x-mal-client-id mit dem Wert 6591a087c62b3e94d769cd8e35ffe909 heraus, der den Zugang zu den Endpunkten api.myanimelist.net/v3/anime/season und /v3/anime mit zwei Dutzend Parametern eröffnete.
• User-Agent. Bei mobilen Clients ist er spezifisch und dient als Teil des „Zugangs“ – in demselben Beispiel ist das MAL (ios, 139).
• Tokens und deren Lebensdauer. Überprüfen Sie sofort, ob der Schlüssel statisch ist oder aktualisiert wird: Das hängt von der gesamten Architektur des Sammlers ab.

Der exportierte curl lässt sich bequem in Code umwandeln über curlconverter – Sie erhalten eine fertige Anfrage für requests, und dann arbeiten Sie mit einem normalen HTTP-Client, ohne einen Browser.

Schritt 5. Skalierung – und wo alles zusammenbricht

An diesem Punkt tritt die Enttäuschung ein, die allen bekannt ist, die es versucht haben: Von einer heimischen IP-Adresse antwortet die private API in den ersten 30 Minuten hervorragend, und dann beginnt sie, 429 und 403 zurückzugeben. Mobile Backends sind weniger gut gegen Client-Spoofing geschützt, aber die Limits pro IP sind strenger – der Server geht davon aus, dass sich ein Telefon hinter der Adresse befindet und nicht ein Parser mit zwanzig Threads.

Von hier aus folgen praktische Schlussfolgerungen.

1. Halten Sie das Anfrageprofil glaubwürdig. Eine echte Anwendung macht nicht 50 Anfragen pro Sekunde und folgt nicht strikt einem Zeitplan. Die Reihenfolge der Aufrufe ist ebenfalls wichtig: Ein echter Client fragt zuerst die Sitzungs-Konfiguration an und dann den Inhalt.
2. Verteilen Sie die Last auf Adressen. Eine IP = ein „Telefon“. Über Strategien zur Rotation, Verzögerungen mit Jitter und exponentielles Backoff wurde ausführlich im Artikel wie man API-Rate-Limiting beim Parsen über Proxys umgeht diskutiert.
3. Berücksichtigen Sie Geo. Viele mobile APIs liefern je nach Land der Adresse unterschiedliche Inhalte und Preise – das ist gleichzeitig eine Einschränkung und eine Möglichkeit.

Die Fehlersuche lässt sich bequem durchführen, ohne mitmproxy zu verlassen: Es kann sich an einen übergeordneten Proxy anschließen. Der Befehl mitmdump --mode upstream:http://example.com:8081 leitet den gesamten Traffic upstream, und die Authentifizierung erfolgt mit der Option --upstream-auth im Format username:password. So sehen Sie die gleichen Anfragen wie zuvor, aber sie gehen bereits von einer externen Adresse aus – Sie können sofort überprüfen, wie die API auf ein bestimmtes Land oder einen bestimmten IP-Typ reagiert.

Welchen Proxy-Typ für mobile API wählen?

Die Auswahl ist hier nicht abstrakt, sie ergibt sich daraus, als wen Sie sich ausgeben.

• Mobile Proxys – die bevorzugte Option. Sie imitieren den Traffic der Anwendung, und die Adresse des Mobilfunkanbieters sieht für das Backend absolut organisch aus: Hinter einer Adresse sitzen dank CGNAT tatsächlich Hunderte von Abonnenten, weshalb die Limits für solche IPs milder sind. Geeignet sind mobile Proxys 4G/LTE.
• Residential Proxys – eine praktikable Mitte, wenn die Volumina groß sind und die Bindung an den Anbieter nicht kritisch ist: Heimische IPs von Anbietern bieten eine breite Abdeckung nach Geo zu einem angemessenen Preis. Das sind residential Proxys.
• Datacenter-Proxys – nur für Endpunkte ohne ernsthafte Überprüfung der Adressreputation. Ihr ASN wird sofort erkannt, und auf einem mobilen Backend sieht das seltsam aus: Telefone gibt es in Rechenzentren nicht.

Unterwassersteine, von denen man spät erfährt

• HTTP/3. Unterstützung für QUIC ist in mitmproxy vorhanden und standardmäßig aktiviert, aber bei echtem mobilem Traffic ist sie eingeschränkt: Oft muss die Verbindung zwangsweise auf HTTP/2 zurückgesetzt werden, indem man mit ALPN manipuliert. Am besten funktioniert QUIC im Reverse- und WireGuard-Modus.
• Private API ändert sich ohne Vorwarnung. Sie hat keine Verpflichtungen zur Rückwärtskompatibilität – es handelt sich um ein internes Interface. Die Version der Anwendung im User-Agent wird eines Tages nicht mehr unterstützt, und der Sammler beginnt stillschweigend, leere Antworten zu erhalten. Überwachen Sie nicht nur die Antwortcodes, sondern auch die Struktur des JSON.
• Verwechseln Sie „habe den Schlüssel gefunden“ nicht mit „habe das Recht erhalten“. Ein statischer Client-Schlüssel ist keine Erlaubnis für unbegrenztes Sammeln.

Zur rechtlichen Seite

Das Abfangen von Traffic auf dem eigenen Gerät ist eine legale und alltägliche Debugging-Praxis, die von mobilen Entwicklern und Sicherheitsspezialisten genutzt wird. Die Grenzen beginnen weiter: Halten Sie sich an die Nutzungsbedingungen des Dienstes, sammeln Sie keine personenbezogenen Daten ohne rechtliche Grundlage (in der EU wird dies direkt durch die DSGVO geregelt), berühren Sie keine Endpunkte, die eine fremde Authentifizierung erfordern, und halten Sie die Last auf einem Niveau, das den Betrieb des Dienstes nicht stört. Praktischer Anhaltspunkt: Wenn Daten für jeden Benutzer in der Anwendung ohne Anmeldung sichtbar sind – befinden Sie sich in einer relativ sicheren Zone; wenn für den Zugriff ein fremdes Konto erforderlich ist – sind Sie bereits außerhalb dieser Zone.

Kurz gesagt

Das Schema funktioniert und spart Wochen mit Anti-Bot-Maßnahmen: Wir starten mitmproxy, legen das Zertifikat im systemeigenen Zertifikatsspeicher des Geräts mit Root-Rechten ab, entfernen gegebenenfalls das Pinning über Frida, fangen eine sinnvolle Anfrage ab, exportieren sie in curl und schreiben sie in Python um. Danach verwandelt sich die Aufgabe „Schutz umgehen“ in die Aufgabe „Lasten sorgfältig verteilen“ – und wird durch Adressrotation, angemessene Pausen und den richtigen Proxy-Typ gelöst. Am einfachsten beginnt man mit mobilen Proxys: sie sind dem Traffic, den das Backend erwartet, am nächsten.