Bloga geri dön

Mobil Uygulamanın Gizli API'sini Bulmanın Yolları: mitmproxy, Frida ve Proxy 2026

Web sitesi Cloudflare kullanıyor ve aynı hizmetin mobil uygulaması tek bir zorluk olmadan hazır JSON alıyor. Bu gizli API'yi nasıl bulacağımızı inceliyoruz: mitmproxy ayarları, Android'deki sistem sertifika deposu, Frida ile sertifika pinning'in kaldırılması, isteğin curl ile dışa aktarılması — ve neden ölçeklendirmede her şeyin IP rotasyonuna dayandığı.

📅1 Ağustos 2026
Mobil Uygulamanın Gizli API'sini Bulmanın Yolları: mitmproxy, Frida ve Proxy 2026

Site, Cloudflare tarafından kapatıldı, Turnstile her ikinci istekte ortaya çıkıyor ve tasarım her iki haftada bir değişiyor. Aynı hizmetin, doğrudan arka uç ile iletişim kuran ve hazır JSON alan bir mobil uygulaması var - zorluklar olmadan, işaretleme olmadan, stabil alan şeması ile. İşte bu "gizli API": belgelenmemiş, ancak tamamen çalışan bir arayüz, resmi istemcinin kullandığı.

Adım adım, mitmproxy ile nasıl bulunacağını, sertifika pinning ile ne yapacağınızı ve neden proxy olmadan ölçeklendirme aşamasında her şeyin çöktüğünü inceleyelim.

Uygulama trafiğine neden girmeliyiz?

Web versiyonunu kazıma ve özel API'yi çağırma, maliyet açısından farklı görevlerdir. Karşılaştırın:

  • Web. Headless tarayıcı, anti-bot aşma, HTML ayrıştırma, seçicilerin düzenli onarımı gereklidir. Bir istek = megabaytlarca trafik ve saniyelerce işlemci süresi.
  • Özel API. Birkaç başlıkla normal bir HTTP isteği, yanıt - tiplenmiş alanlarla kompakt bir JSON. Genellikle arayüzün gösterdiğinden daha fazla veri verir: iç kimlikler, bayraklar, hizmet alanları.

Mobil arka uçlar tarihsel olarak web'den daha zayıf korunmaktadır. Sebep basit: anti-bot platformları tarayıcı trafiğine yönelik tasarlanmıştır (JS zorlukları, canvas, davranışsal sinyaller), mobil istemci bunlardan geçemezdi. Bunun yerine geliştiriciler, uygulamanın statik anahtarına ve TLS pinning'e güveniyor - her ikisi de yerel cihazda kaldırılabilir.

Ne gerekecek?

  1. mitmproxy - açık kaynaklı bir HTTPS proxy yakalayıcı (GitHub'da 44.000'den fazla yıldız, güncel sürüm 12.2.2 Nisan 2026'da çıktı, Python 3.12+ gerektirir). Tek bir komutla kurulur: pip install mitmproxy. HTTP/1, HTTP/2, HTTP/3, WebSocket ve ham TCP'yi anlar, TLS 1.2 ve 1.3 ile çalışır.
  2. Rootlu bir Android cihaz veya emülatör. Uygulama sertifikalarıyla çalışmak için en uygun versiyon Android 7-11'dir: yeni sürümler sertifikalarla çalışma konusunda çok daha katı hale geldi.
  3. ADB cihazla iletişim için ve Frida (pip install frida-tools) - uygulama sertifikayı pinliyorsa gerekecek.

mitmproxy'nin bir motor üzerinde üç arayüzü vardır: mitmproxy (terminal TUI), mitmweb (yeni başlayanlar için daha kullanışlı web arayüzü) ve mitmdump (headless, betikler ve otomasyon için).

Adım 1. Yakalayıcıyı başlatmak

Web arayüzünü dış bağlantıları dinleyecek şekilde başlatıyoruz, sadece localhost değil:

mitmweb --web-host 0.0.0.0

Varsayılan olarak proxy 8080 portunda başlatılır. İlk başlatıldığında mitmproxy kendi sertifika otoritesini oluşturur ve anahtarları ~/.mitmproxy dizinine koyar. Orada dört dosya oluşacaktır: mitmproxy-ca.pem (sertifika ve özel anahtar), mitmproxy-ca-cert.pem (sadece sertifika), mitmproxy-ca-cert.p12 Windows için ve mitmproxy-ca-cert.cer - Android için format.

Adım 2. Cihazı proxy üzerinden yönlendirmek

Telefonun Wi-Fi ayarlarında manuel proxy seçiyoruz: yerel ağınızdaki bilgisayarın IP'si ve 8080 portu. Daha sonra cihazın tarayıcısında özel bir alan adı mitm.it açıyoruz - bu, mitmproxy'de yerleşik bir sayfa olup, platformu otomatik olarak tanır ve gerekli sertifika formatını talimatlarla birlikte sunar.

iOS'ta prosedür üç bölümden oluşur ve herkes ikinci kısmı unutur: Safari üzerinden profili indirmek, "Ayarlar → Genel → VPN ve cihaz yönetimi" kısmında kurmak ve ardından ayrı olarak tam güveni etkinleştirmek "Ayarlar → Genel → Bu cihaz hakkında → Sertifikalara güven". Son adım olmadan sertifika kurulu ama çalışmaz.

Wi-Fi ayarlarıyla uğraşmak istemiyorsanız, mitmproxy'nin bir VPN sunucu modu vardır: mitmweb --mode wireguard. Cihaz, WireGuard'ın standart istemcisi ile bağlanır ve trafik şeffaf bir şekilde, sistemde proxy ayarı yapmadan yakalanır.

Adım 3. Ana engel - sertifikaya güven

Burada çoğu deneme başarısız olur. İki sorun var ve bunlar farklı sorunlardır.

Kullanıcı CA'ları 2016'dan beri dikkate alınmıyor

Android 7 Nougat (API 24) ile birlikte uygulamalar varsayılan olarak yalnızca sistem sertifika deposuna güvenir. Kullanıcı CA'sı, geliştirici açıkça Network Security Config'de izin vermediği sürece göz ardı edilir - güvenilir köklerde <certificates src="user" /> bloğu ile. Bu, Google'ın saldırı yüzeyini azaltma kararıdır ve telefon ayarlarıyla aşılması mümkün değildir. Bu arada, Chrome da kullanıcı sertifikalarına güvenmiyor. Android 11'de kısıtlamalar daha da sıkılaştırıldı.

Pratik sonuç: rootlu bir cihazda mitmproxy sertifikası sistem sertifika deposuna yerleştirilmelidir, kullanıcı deposuna değil. Bu nedenle root, gereksinimler listesinde "gerekli" olarak yer alıyor.

Sertifika pinning

İkinci engel - pinning: uygulama, beklenen sunucu sertifikasının parmak izini taşır ve başka biriyle iletişim kurmayı reddeder. Hatta sistem CA'sı burada kurtarmaz. 2022 ACM araştırması, pinning'in "yüksek riskli" sektörlerde (bankalar, taksi, kripto) yaygın olduğunu gösterdi, ancak genellikle eksik uygulandığı için aşılabiliyor.

Bu görev için birkaç araç var ve bunlar farklı şekillerde çözüyor:

  • Frida - çalışma zamanında davranışı değiştirme: sertifika kontrol fonksiyonlarını yakalıyoruz ve başarılı sonuç döndürmelerini sağlıyoruz. Uygulama bu arada değiştirilmez - en esnek seçenek. Tipik bir başlatma: frida -U -f com.target.app -l ssl_bypass.js --no-pause.
  • apk-mitm - APK dosyasından pinning'i otomatik olarak keser.
  • android-unpinner - Frida ve pinning kaldırma betikleri ekleyerek APK'yı yeniden derler.
  • objection - Frida üzerinde bir araç seti, hem iOS hem de Android'i destekler.
  • ssl-kill-switch2 - iOS ve macOS uygulamalarında pinning'i devre dışı bırakır.

Belirli bir alan adı sıkı bir şekilde pinlenmişse ve çalışmayı engelliyorsa, onu ignore_hosts seçeneği ile yakalamadan hariç tutabilirsiniz (düzenli ifade alır) - trafik mitmproxy'den şifrelenmeden geçecektir.

Adım 4. Gerekli isteği bulmak

Sonra rutin başlar. Uygulamayı açıyoruz, tam olarak bir anlamlı eylem gerçekleştiriyoruz (ürün kartını açmak, akışı kaydırmak, filtre uygulamak) ve hangi isteklerin ortaya çıktığına bakıyoruz. Terminal arayüzünde bu hızlı bir şekilde yapılır: Z akış listesini temizler, Enter seçilen isteği açar, E onu dışa aktarır - bu, hazır bir curl komutuyla da olabilir.

Yakalanan istekte ne aramalısınız:

  • Uç nokta ve parametreler. Genellikle uygulama arayüzünün kullandığından çok daha fazlası vardır.
  • Müşteri anahtarı. Türünün klasiği - uygulamaya gömülü statik bir kimlik. Tanınmış bir MyAnimeList kamu API incelemesinde bu anahtar, x-mal-client-id başlığı olarak ortaya çıktı ve değeri 6591a087c62b3e94d769cd8e35ffe909 idi, api.myanimelist.net/v3/anime/season ve /v3/anime uç noktalarına erişim sağlıyordu.
  • User-Agent. Mobil istemcilerde özel olup, "geçiş" parçası olarak hizmet eder - aynı örnekte bu MAL (ios, 139) idi.
  • Tokenler ve yaşam süreleri. Anahtarın statik mi yoksa güncellenebilir mi olduğunu hemen kontrol edin: bu, toplayıcının tüm sonraki mimarisini etkiler.

Dışa aktarılan curl'ü kod haline dönüştürmek için curlconverter kullanmak uygundur - hazır bir istek alırsınız ve ardından normal bir HTTP istemcisi ile çalışmaya devam edersiniz, herhangi bir tarayıcı olmadan.

Adım 5. Ölçeklendirme - ve her şeyin nerede çöktüğü

Bu noktada, denemiş olan herkesin tanıdığı bir hayal kırıklığı başlar: bir ev IP'sinden özel API ilk yarım saat boyunca mükemmel yanıt verir, sonra 429 ve 403 vermeye başlar. Mobil arka uçlar, istemci taklitlerine karşı daha zayıf korunmaktadır, ancak IP başına limitler daha katıdır - sunucu, adresin arkasında bir telefon olduğunu varsayar, yirmi akışlı bir toplayıcı değil.

Bundan pratik sonuçlar çıkarılabilir.

  1. İstek profilinizi inandırıcı tutun. Gerçek bir uygulama saniyede 50 istek yapmaz ve kesin bir takvimle hareket etmez. Çağrı sırası da önemlidir: gerçek bir istemci önce oturum konfigürasyonunu talep eder, sonra içeriği.
  2. Yükü adresler arasında dağıtın. Bir IP = bir "telefon". Adres değiştirme stratejileri, jitter ile gecikmeler ve üstel geri çekilme ile ilgili ayrıntılı bilgi, proxy üzerinden API oran sınırlamasını nasıl aşacağınız konulu makalede ele alınmıştır.
  3. Coğrafyayı dikkate alın. Birçok mobil API, adresin ülkesine bağlı olarak farklı içerikler ve farklı fiyatlar sunar - bu hem bir kısıtlama hem de bir fırsattır.

Hata ayıklamayı mitmproxy'den çıkmadan yapmak uygundur: üstteki proxy'e bağlanabilir. mitmdump --mode upstream:http://example.com:8081 komutu tüm trafiği yukarı akışa yönlendirir ve ona yetkilendirme --upstream-auth seçeneği ile username:password formatında atanır. Böylece daha önce gördüğünüz aynı istekleri görebilirsiniz, ancak artık dış bir adresten çıkıyorlar - API'nin belirli bir ülkeye veya IP türüne nasıl tepki verdiğini hemen kontrol edebilirsiniz.

Mobil API için hangi tür proxy alınmalı?

Buradaki seçim soyut değil, kimin gibi davrandığınıza bağlıdır.

  • Mobil proxyler - öncelikli seçenek. Uygulama trafiğini taklit ediyorsunuz ve cep telefonu operatörünün adresi arka uç için tamamen doğal görünüyor: bir adresin arkasında CGNAT sayesinde gerçekten yüzlerce abone oturuyor, bu nedenle bu tür IP'lere yönelik limitler daha yumuşaktır. Mobil 4G/LTE proxyler uygundur.
  • İkamet eden proxyler - büyük hacimler varsa ve operatöre bağlılık kritik değilse, çalışır bir ortadır: ev IP'leri, makul bir fiyatla geniş coğrafi kapsama sağlar. Bu ikamet eden proxyler.
  • Veri merkezi proxyleri - yalnızca ciddi adres itibar kontrolü olmayan uç noktalar için. ASN'leri anında tanınır ve mobil arka uçta bu garip görünür: veri merkezlerinde telefonlar olmaz.

Geç öğrenilen tuzaklar

  • HTTP/3. mitmproxy'de QUIC desteği vardır ve varsayılan olarak açıktır, ancak gerçek mobil trafikte sınırlıdır: çoğu zaman bağlantıyı ALPN ile manipüle ederek HTTP/2'ye zorlamak gerekir. QUIC, ters ve WireGuard modlarında en iyi çalışır.
  • Özel API, önceden haber vermeden değişir. Geriye dönük uyumluluk yükümlülüğü yoktur - bu bir iç arayüzdür. User-Agent'taki uygulama sürümü bir gün desteklenmeyi bırakacak ve toplayıcı sessizce boş yanıtlar almaya başlayacaktır. Yanıt kodlarını değil, JSON yapısını da izleyin.
  • "Anahtarı buldum" ile "yetki aldım"ı karıştırmayın. Statik müşteri anahtarı, sınırsız toplama izni değildir.

Hukuki tarafı

Kendi cihazınızda trafiği yakalamak, mobil geliştiriciler ve güvenlik uzmanları tarafından kullanılan yasal ve günlük bir hata ayıklama pratiğidir. Sınırlar daha sonra başlar: hizmetin kullanım koşullarına uyun, yasal bir dayanak olmadan kişisel verileri toplamayın (AB'de bu doğrudan GDPR ile düzenlenir), başkalarının yetkilendirmesini gerektiren uç noktalara dokunmayın ve yükü hizmetin çalışmasını engellemeyecek bir seviyede tutun. Pratik bir kılavuz: veriler, herhangi bir kullanıcı tarafından hesaba giriş olmadan uygulamada görünüyorsa - nispeten sakin bir alandasınız; erişim için başkasının hesabı gerekiyorsa - artık onun dışındasınız.

Kısaca

Şema çalışır ve anti-bot ile uğraşmak için haftalar kazandırır: mitmproxy'yi başlatıyoruz, sertifikayı rootlu cihazın sistem sertifika deposuna koyuyoruz, gerekirse pinning'i Frida ile kaldırıyoruz, bir anlamlı isteği yakalıyoruz, onu curl ile dışa aktarıyoruz ve Python'a yazıyoruz. Sonra "korumayı aşma" görevimiz "yükü dikkatlice dağıtma" görevine dönüşüyor - ve adres döngüsü, makul gecikmeler ve doğru proxy türü ile çözülüyor. En kolay başlangıç noktası mobil proxyler: arka uçun görmek istediği trafiğe en yakın olanlar.