Situs ini ditutup oleh Cloudflare, Turnstile muncul pada setiap permintaan kedua, dan tata letak berubah setiap dua minggu. Sementara itu, layanan yang sama memiliki aplikasi seluler yang terhubung langsung ke backend dan menerima JSON yang sudah siap — tanpa tantangan, tanpa penandaan, dengan skema bidang yang stabil. Inilah yang disebut "API tersembunyi": antarmuka yang tidak terdokumentasi, tetapi sepenuhnya berfungsi, yang digunakan oleh klien resmi.
Kita akan membahas langkah demi langkah bagaimana menemukannya menggunakan mitmproxy, apa yang harus dilakukan dengan certificate pinning dan mengapa pada tahap skala pengumpulan tanpa proxy semuanya hancur.
Kenapa harus mengakses lalu lintas aplikasi
Scraping versi web dan memanggil API privat adalah tugas yang berbeda dalam hal biaya. Bandingkan:
- Web. Diperlukan browser headless, melewati anti-bot, parsing HTML, dan perbaikan pemilih secara berkala. Satu permintaan = megabyte lalu lintas dan detik waktu prosesor.
- API Privat. Permintaan HTTP biasa dengan beberapa header, respons — JSON ringkas dengan bidang yang terstruktur. Sering kali memberikan lebih banyak data daripada yang ditampilkan oleh antarmuka: pengenal internal, bendera, bidang layanan.
Backend seluler secara historis lebih lemah dilindungi dibandingkan web. Alasannya sederhana: platform anti-bot dirancang untuk lalu lintas browser (tantangan JS, canvas, sinyal perilaku), dan klien seluler tidak akan melewati mereka. Sebagai gantinya, pengembang mengandalkan kunci aplikasi statis dan TLS-pinning — dan keduanya diambil di perangkat lokal.
Apa yang dibutuhkan
- mitmproxy — HTTPS proxy interceptor dengan kode sumber terbuka (lebih dari 44.000 bintang di GitHub, cabang terbaru 12.2.2 dirilis pada April 2026, memerlukan Python 3.12+). Diinstal dengan satu perintah: pip install mitmproxy. Memahami HTTP/1, HTTP/2, HTTP/3, WebSocket, dan TCP mentah, bekerja dengan TLS 1.2 dan 1.3.
- Perangkat Android atau emulator dengan root. Praktik menunjukkan bahwa Android 7–11 adalah yang paling nyaman: versi baru sangat memperketat kerja dengan sertifikat.
- ADB untuk berkomunikasi dengan perangkat dan Frida (pip install frida-tools) — diperlukan jika aplikasi melakukan pinning sertifikat.
Mitmproxy memiliki tiga antarmuka di atas satu mesin: mitmproxy (TUI terminal), mitmweb (antarmuka web, lebih nyaman untuk pemula) dan mitmdump (headless, untuk skrip dan otomatisasi).
Langkah 1. Menjalankan interceptor
Kita menjalankan antarmuka web sehingga mendengarkan koneksi eksternal, bukan hanya localhost:
mitmweb --web-host 0.0.0.0
Secara default, proxy dijalankan di port 8080. Pada saat pertama kali dijalankan, mitmproxy membuat pusat sertifikasi sendiri dan menyimpan kunci di direktori ~/.mitmproxy. Di sana akan muncul empat file: mitmproxy-ca.pem (sertifikat bersama dengan kunci privat), mitmproxy-ca-cert.pem (hanya sertifikat), mitmproxy-ca-cert.p12 untuk Windows dan mitmproxy-ca-cert.cer — format untuk Android.
Langkah 2. Mengarahkan perangkat melalui proxy
Di pengaturan Wi-Fi di ponsel, pilih proxy manual: IP komputer Anda di jaringan lokal dan port 8080. Selanjutnya, buka di browser perangkat domain khusus mitm.it — ini adalah halaman yang terintegrasi dalam mitmproxy yang secara otomatis menentukan platform dan memberikan format sertifikat yang diperlukan dengan instruksi.
Di iOS, prosedur terdiri dari tiga bagian, dan setengah kedua sering dilupakan: unduh profil melalui Safari, instal di "Pengaturan → Umum → VPN dan manajemen perangkat", dan kemudian aktifkan kepercayaan penuh secara terpisah di "Pengaturan → Umum → Tentang perangkat ini → Kepercayaan sertifikat". Tanpa langkah terakhir, sertifikat diinstal tetapi tidak berfungsi.
Jika tidak ingin repot dengan pengaturan Wi-Fi, mitmproxy memiliki mode server VPN: mitmweb --mode wireguard. Perangkat terhubung menggunakan klien WireGuard standar, dan lalu lintas ditangkap secara transparan, tanpa pengaturan proxy manual di sistem.
Langkah 3. Dinding utama — kepercayaan pada sertifikat
Di sini kebanyakan upaya gagal. Ada dua masalah, dan itu adalah masalah yang berbeda.
CA kustom tidak dihargai sejak 2016
Mulai dari Android 7 Nougat (API 24), aplikasi secara default hanya mempercayai penyimpanan sertifikat sistem. CA kustom diabaikan jika pengembang tidak secara eksplisit mengizinkannya dalam Konfigurasi Keamanan Jaringan — melalui blok <certificates src="user" /> di trust anchors. Ini adalah keputusan sadar dari Google untuk mengurangi permukaan serangan, dan tidak dapat diatasi dengan pengaturan ponsel. Chrome, kebetulan, juga tidak mempercayai sertifikat kustom. Di Android 11, pembatasan semakin diperketat.
Kesimpulan praktis: di perangkat dengan root, sertifikat mitmproxy harus diletakkan di penyimpanan sistem, bukan di penyimpanan pengguna. Itulah sebabnya root ada dalam daftar persyaratan, bukan "diinginkan".
Certificate pinning
Dinding kedua — pinning: aplikasi menyimpan jejak sertifikat server yang diharapkan dan menolak untuk berbicara dengan siapa pun yang lain. Bahkan CA sistem tidak menyelamatkan di sini. Penelitian ACM 2022 menunjukkan bahwa pinning umum di "vertikal berisiko tinggi" (bank, taksi, kripto), tetapi sering kali diimplementasikan secara tidak lengkap dan karenanya dapat diatasi.
Ada beberapa alat untuk tugas ini, dan mereka menyelesaikannya dengan cara yang berbeda:
- Frida — mengedit perilaku di runtime: kita meng-hack fungsi pemeriksaan sertifikat dan memaksa mereka untuk mengembalikan keberhasilan. Aplikasi tidak dimodifikasi — ini adalah opsi paling fleksibel. Peluncuran tipikal: frida -U -f com.target.app -l ssl_bypass.js --no-pause.
- apk-mitm — secara otomatis memotong pinning dari file APK secara statis.
- android-unpinner — membangun ulang APK, menyisipkan Frida dan skrip untuk menghapus pinning.
- objection — toolkit di atas Frida, dapat digunakan untuk iOS dan Android.
- ssl-kill-switch2 — menonaktifkan pinning di aplikasi iOS dan macOS.
Jika domain tertentu dipinning secara ketat dan mengganggu pekerjaan, Anda dapat cukup mengecualikannya dari penangkapan dengan opsi ignore_hosts (menerima ekspresi reguler) — lalu lintas akan melewati mitmproxy tanpa dekripsi.
Langkah 4. Menemukan permintaan yang diperlukan
Selanjutnya — rutinitas. Buka aplikasi, lakukan satu tindakan yang bermakna (membuka kartu produk, menggulir umpan, menerapkan filter) dan lihat permintaan apa yang muncul. Di antarmuka terminal, ini dilakukan dengan cepat: Z membersihkan daftar aliran, Enter membuka permintaan yang dipilih, E mengekspornya — termasuk dengan perintah curl yang sudah siap.
Apa yang dicari dalam permintaan yang ditangkap:
- Endpoint dan parameter. Sering kali ada lebih banyak daripada yang digunakan oleh antarmuka aplikasi.
- Kunci klien. Klasik genre — pengenal statis yang tertanam dalam aplikasi. Dalam analisis terkenal dari API publik MyAnimeList, kunci ini adalah header x-mal-client-id dengan nilai 6591a087c62b3e94d769cd8e35ffe909, yang membuka akses ke endpoint api.myanimelist.net/v3/anime/season dan /v3/anime dengan dua puluh parameter.
- User-Agent. Di klien seluler, ini spesifik dan berfungsi sebagai bagian dari "izin" — dalam contoh yang sama ini adalah MAL (ios, 139).
- Token dan masa berlakunya. Segera periksa, apakah kunci statis atau diperbarui: ini akan mempengaruhi seluruh arsitektur pengumpul.
curl yang diekspor nyaman diubah menjadi kode melalui curlconverter — Anda akan mendapatkan permintaan siap pakai di requests, dan selanjutnya Anda bekerja dengan klien HTTP biasa, tanpa browser.
Langkah 5. Skala — dan di mana semuanya hancur
Di sini kekecewaan datang, yang dikenal oleh semua orang yang mencobanya: dari satu IP rumah, API privat merespons dengan baik selama setengah jam pertama, dan kemudian mulai memberikan 429 dan 403. Backend seluler lebih lemah dilindungi dari pemalsuan klien, tetapi batasan berdasarkan IP di sana lebih ketat — server menganggap bahwa di alamat tersebut ada satu ponsel, bukan parser dengan dua puluh aliran.
Dari sini, kesimpulan praktis.
- Jaga profil permintaan tetap realistis. Aplikasi nyata tidak melakukan 50 permintaan per detik dan tidak berjalan sesuai jadwal yang ketat. Urutan panggilan juga penting: klien yang sebenarnya pertama-tama meminta konfigurasi sesi, kemudian konten.
- Sebarkan beban ke alamat yang berbeda. Satu IP = satu "ponsel". Tentang strategi rotasi, penundaan dengan jitter dan exponential backoff telah dibahas secara rinci dalam materi cara menghindari pembatasan laju API saat melakukan parsing melalui proxy.
- Perhatikan geo. Banyak API seluler memberikan konten dan harga yang berbeda tergantung pada negara alamat — ini adalah batasan sekaligus peluang.
Debugging nyaman dilakukan tanpa keluar dari mitmproxy: ia dapat terhubung ke proxy yang lebih tinggi. Perintah mitmdump --mode upstream:http://example.com:8081 mengalihkan semua lalu lintas ke upstream, dan otorisasi untuk itu ditentukan dengan opsi --upstream-auth dalam format username:password. Dengan cara ini, Anda melihat permintaan yang sama seperti sebelumnya, tetapi mereka sudah pergi dari alamat eksternal — Anda dapat segera memeriksa bagaimana API bereaksi terhadap negara tertentu atau jenis IP.
Jenis proxy apa yang harus digunakan untuk API seluler
Pemilihan di sini tidak abstrak, itu tergantung pada siapa Anda berpura-pura.
- Proxy seluler — opsi prioritas. Anda meniru lalu lintas aplikasi, dan alamat operator seluler terlihat sangat organik bagi backend: di satu alamat, berkat CGNAT, sebenarnya ada ratusan pelanggan, sehingga batasan untuk IP semacam itu lebih lunak. Cocok untuk proxy seluler 4G/LTE.
- Proxy residensial — tengah yang bekerja, jika volumenya besar dan keterikatan pada operator tidak kritis: IP rumah dari penyedia memberikan cakupan geo yang luas dengan harga yang wajar. Ini adalah proxy residensial.
- Data center — hanya untuk endpoint tanpa pemeriksaan reputasi alamat yang serius. ASN mereka dikenali dengan cepat, dan di backend seluler ini terlihat aneh: tidak ada ponsel di pusat data.
Perangkap yang diketahui terlambat
- HTTP/3. Dukungan QUIC di mitmproxy ada dan diaktifkan secara default, tetapi pada lalu lintas seluler yang nyata, itu terbatas: sering kali koneksi harus dipaksa kembali ke HTTP/2 melalui manipulasi ALPN. QUIC bekerja paling baik dalam mode reverse dan WireGuard.
- API privat berubah tanpa peringatan. Ia tidak memiliki kewajiban untuk kompatibilitas mundur — ini adalah antarmuka internal. Versi aplikasi dalam User-Agent suatu saat akan berhenti dilayani, dan pengumpul akan diam-diam mulai menerima respons kosong. Pantau tidak hanya kode respons, tetapi juga struktur JSON.
- Jangan bingungkan "menemukan kunci" dan "mendapatkan izin". Kunci klien statis — bukan izin untuk pengumpulan tanpa batas.
Tentang sisi hukum
Menangkap lalu lintas di perangkat sendiri adalah praktik debugging yang sah dan sehari-hari, digunakan oleh pengembang seluler dan spesialis keamanan. Batasan mulai lebih jauh: patuhi syarat penggunaan layanan, jangan kumpulkan data pribadi tanpa dasar hukum (di UE ini diatur langsung oleh GDPR), jangan sentuh endpoint yang memerlukan otorisasi orang lain, dan jaga beban pada tingkat yang tidak mengganggu kerja layanan. Patokan praktis: jika data terlihat di aplikasi oleh pengguna mana pun tanpa masuk ke akun — Anda berada di zona yang relatif aman; jika akses memerlukan akun orang lain — Anda sudah di luar batas tersebut.
Singkatnya
Skema ini bekerja dan menghemat minggu-minggu repot dengan anti-bot: kita mengangkat mitmproxy, menempatkan sertifikat di penyimpanan sistem perangkat dengan root, jika perlu menghapus pinning melalui Frida, menangkap satu permintaan yang bermakna, mengekspornya ke curl dan menulis ulang ke Python. Selanjutnya, tugas dari kategori "menghindari perlindungan" berubah menjadi tugas "mendistribusikan beban dengan hati-hati" — dan diselesaikan dengan rotasi alamat, jeda yang masuk akal dan jenis proxy yang tepat. Cara termudah untuk memulai adalah dengan proxy seluler: mereka paling mendekati lalu lintas yang diharapkan backend.