Kembali ke blog

Cara Mengambil Peta Deteksi Situs: Temukan Skrip Fingerprint Sendiri

Kasus AliExpress: jejak audio tersembunyi mengungkapkan dirinya melalui headphone Bluetooth. Kami membahas metode praktis — bagaimana dalam satu jam menentukan vendor anti-fraud, menemukan skripnya, menginstrumentasikan fingerprint-API di DevTools dan melihat sinyal apa yang benar-benar diambil oleh platform dan ke mana mereka mengirimkannya.

📅25 Agustus 2026
Cara Mengambil Peta Deteksi Situs: Temukan Skrip Fingerprint Sendiri
```html

Pada 20 Agustus 2026, pengembang Matt Callaghan (blog laserphile) menerbitkan analisis tentang bug aneh: headphone Bluetooth-nya dengan multipoint berhenti beralih dari komputer ke telepon. Setiap kali tab AliExpress dibuka. Dia tidak menebak — dia menginstrumentasikan API browser dan melihat apa yang terjadi di dalam halaman. Ternyata, dua skrip yang diobfuski dari tumpukan anti-fraud Alibaba mengangkat konteks audio dan mengambil sidik jari perangkat melalui suara yang tidak didengar oleh siapa pun.

Ini adalah ilustrasi sempurna tentang apa yang hampir tidak dilakukan orang sebelum mengatur profil atau menjalankan parser: tidak membaca tumpukan deteksi situs, tetapi menebaknya. Di bawah ini adalah metode praktis tentang cara mengambil peta deteksi situs tertentu dengan tangan Anda sendiri, dalam satu jam, tanpa membalik obfuscation dan tanpa layanan berbayar.

Mengapa mengambil peta deteksi

Siklus tipikal terlihat seperti ini: akun diblokir — kita mengubah pengaturan browser anti-detect secara acak — mengganti proxy — diblokir lagi. Antara "diblokir" dan "pengaturan" tidak ada data: tidak jelas apa yang sebenarnya dibaca oleh situs dan di lapisan mana ia menangkap.

Peta deteksi menutup celah ini. Ini adalah daftar: vendor perlindungan mana yang terpasang, skrip mana yang mengimplementasikannya, API mana yang mereka sentuh dan ke mana hasilnya pergi. Selanjutnya, menjadi jelas di mana sebenarnya titik sempit — di IP, di sidik jari jaringan atau di lapisan perangkat keras browser. Ini sama-sama berguna untuk tiga audiens:

  • Multi-akuntansi — memahami sinyal mana yang menghubungkan profil. IP mereka berbeda, tetapi tumpukan audio, renderer WebGL, dan hardwareConcurrency sering kali sama untuk seluruh farm.
  • Scraping — memahami apakah perlu mengangkat browser atau apakah tugas dapat diselesaikan dengan klien HTTP dengan sidik jari TLS yang benar.
  • Privasi — melihat apa yang sebenarnya toko atau layanan kumpulkan tentang perangkat Anda selain cookies.

Langkah 1. Menentukan vendor perlindungan melalui jaringan

Hal pertama yang Anda lakukan adalah membuka DevTools di tab Jaringan, memuat halaman, dan melihat header dan cookies dari dokumen pertama. Tanda pengenal sudah dikenal dan stabil:

  • CF-RAY di header respons dan cookie cf_clearance — Cloudflare.
  • Cookie _abck dan skrip dengan fungsi bmak — Akamai Bot Manager.
  • Variabel dan cookies dengan awalan _px — PerimeterX (HUMAN).
  • Cookie datadome dan JS terpisah dari domain vendor — DataDome.
  • Empty 429 tanpa body respons — tanda tangan khas Kasada.

Jika malas secara manual, ada detektor terbuka seperti microlinkhq/is-antibot (30+ penyedia) dan ekstensi browser-detektor untuk 26+ vendor. Mereka memberikan jawaban cepat pertama, tetapi tidak menjawab pertanyaan utama — apa yang sebenarnya diukur di browser Anda. Untuk itu, Anda perlu melangkah lebih jauh.

Langkah 2. Mengambil daftar skrip mencurigakan

Filter Jaringan berdasarkan jenis JS dan catat semua yang dimuat tidak dari domain utama atau terletak di direktori layanan. Dalam kasus AliExpress, ada dua file dengan jalur layanan yang jelas:

  • assets.aliexpress-media.com/g/AWSC/uab/1.140.0/collina.js
  • assets.aliexpress-media.com/g/AWSC/fireyejs/1.231.67/fireyejs.js

Tanda-tanda skrip anti-fraud: kode yang diobfuski, versi dalam jalur, subdomain terpisah untuk statis, tidak ada hubungan dengan bagian visual halaman. Tidak perlu membuka dan membaca obfuscation — di langkah berikutnya, skrip itu sendiri akan memberi tahu tentang dirinya.

Langkah 3. Menginstrumentasikan fingerprint-API

Ini adalah inti dari metode dan tepatnya apa yang dilakukan Callaghan: dia membungkus konstruktor AudioContext dan AudioNode.prototype.connect(), setelah itu dia melihat dua konteks audio aktif di halaman, di mana tidak ada elemen media dan tidak ada panggilan play().

Logika sederhana: Anda mengganti metode yang Anda minati dengan pembungkus Anda, yang mencatat panggilan dengan tumpukan dan meneruskan kontrol ke yang asli. Tumpukan panggilan menunjukkan skrip mana yang memanggil API. Memasukkan snippet seperti itu paling nyaman melalui DevTools Sumber → Snippet atau melalui ekstensi yang menjalankan kode pada document-start — penting untuk melakukannya sebelum skrip anti-fraud dimuat.

Set minimum jebakan yang menutup sebagian besar sinyal:

  1. HTMLCanvasElement.prototype.toDataURL dan getImageData — sidik jari kanvas.
  2. WebGLRenderingContext.prototype.getParameter — model kartu grafis dan driver, akurasi shader.
  3. AudioContext / OfflineAudioContext dan AudioNode.prototype.connect — sidik jari audio.
  4. Getter navigator.hardwareConcurrency, navigator.deviceMemory, navigator.plugins, navigator.webdriver.
  5. RTCPeerConnection — WebRTC dan alamat lokal.
  6. screen.width/height, devicePixelRatio, Intl.DateTimeFormat().resolvedOptions() — layar dan zona waktu.
  7. navigator.mediaDevices.enumerateDevices — daftar perangkat audio dan video.

Setelah menjalankan, Anda akan memiliki daftar: API mana yang dipanggil, berapa kali, dan oleh siapa. Dalam kasus yang dianalisis, skrip Alibaba menyentuh kanvas dan toDataURL, renderer WebGL dan akurasi shader, audio melalui osilator dan analisator, ukuran layar dan devicePixelRatio, hardwareConcurrency dan deviceMemory, plugin, dukungan codec, WebRTC, waktu kinerja, pola gerakan mouse dan sentuhan, sensor gerakan perangkat dan indikator otomatisasi.

Apa yang dilakukan audio graph

Penting untuk memahami bagaimana pengukuran terlihat, agar dapat mengenalinya di tempat lain. Grafisnya adalah: osilator bergerigi → AnalyserNodeScriptProcessorNode, membaca hasil analisis → GainNode dengan penguatan nol → destination. Tidak ada suara, volume tidak relevan — itu tidak ada. Namun, koneksi ke destination, menurut penjelasan penulis, memaksa browser untuk memproses grafik secara aktif, meskipun volume akhirnya sama dengan nol. Justru jalur audio yang hidup yang menjaga jalur Bluetooth terbuka, merusak pergantian multipoint headphone.

Perbedaan dalam pemrosesan sinyal ini tergantung pada prosesor, perangkat keras audio, OS, browser, dan driver — dari sini muncul pengidentifikasi stabil yang bertahan meskipun ada perubahan IP dan pembersihan cookies. Analisis mendetail tentang lapisan ini dan pengaturan profil untuknya — dalam artikel tentang perlindungan dari Audio Context Fingerprinting.

Langkah 4. Menangkap pengiriman hasil

Pengumpulan tanpa pengiriman tidak ada artinya, jadi langkah berikutnya adalah menemukan ke mana sidik jari yang dikumpulkan pergi. Filter Jaringan berdasarkan XHR/Fetch dan lihat permintaan tipe ping secara terpisah — ini dihasilkan oleh navigator.sendBeacon, yang sering digunakan oleh skrip telemetri karena ia bertahan saat meninggalkan halaman.

Hampir selalu berguna untuk membungkus fetch, XMLHttpRequest.prototype.send, dan navigator.sendBeacon — maka Anda akan melihat body permintaan sebelum ia pergi. Bersiaplah untuk konten yang akan diserialisasi dan dienkripsi: dalam kasus AliExpress, data dienkripsi sebelum dikirim ke telemetri Alibaba. Namun, bahkan begitu, Anda mendapatkan dua fakta: alamat penerima dan waktu pengiriman relatif terhadap tindakan Anda.

Jika situs berfungsi tidak hanya di browser, tetapi juga melalui aplikasi seluler atau klien terpisah, pertanyaan yang sama diselesaikan di tingkat lalu lintas, bukan DOM — metode intercept dan analisis dijelaskan dalam analisis audit lalu lintas melalui mitmproxy.

Langkah 5. Membandingkan peta dengan profil Anda

Sekarang Anda memiliki daftar sinyal yang benar-benar dibaca oleh situs. Tinggal memeriksa apa yang diberikan oleh profil kerja Anda berdasarkan sinyal ini. Urutannya adalah: ambil nilai di browser biasa, kemudian di setiap profil anti-detect dan bandingkan.

Dua hal penting secara bersamaan: nilai harus berbeda antara profil dan stabil di dalam satu profil antara sesi. Profil yang memiliki sidik jari yang bergetar setiap kali diluncurkan terlihat tidak kurang mencurigakan bagi anti-fraud dibandingkan dengan sepuluh profil dengan sidik jari identik.

Periksa secara terpisah bahwa penggantian benar-benar ada di lapisan yang diperlukan. Di sini, variasi antar browser sangat mencolok: Firefox sejak versi 118 memberikan output WebAudio konstan, dan menurut data analisis, 99,24% pengguna terdistribusi ke tiga nilai; Brave mencampur data acak dan sejak 22 Agustus 2026 memblokir skrip AliExpress ini secara khusus, mengingatkan bahwa perlindungan dari sidik jari audio sudah ada secara default selama lebih dari enam tahun; Safari mencampur kesalahan dalam buffer audio; Chrome tidak memiliki perlindungan agresif.

Perangkap

  • Skrip sudah sempat berfungsi. Pemblokiran file tidak membunuh konteks audio yang sudah dibuat — penulis secara langsung mencatat bahwa tab yang terbuka harus ditutup. Hal yang sama berlaku untuk instrumentasi Anda: jika pembungkus dipasang setelah skrip, Anda tidak akan melihat apa pun.
  • Pemblokiran merusak fungsionalitas. Tumpukan anti-fraud sering kali juga bertanggung jawab untuk hal-hal yang sah — otorisasi, pembayaran, perlindungan anti-bot dari penyalahgunaan nyata. Mengambil peta deteksi dan memotong skrip adalah tugas yang berbeda; yang kedua merusak situs.
  • Versi deteksi tidak hanya satu. Tumpukan dapat berbeda berdasarkan geo, jenis perangkat, dan grup A/B. Peta masuk akal untuk diambil dari IP dan perangkat yang benar-benar Anda gunakan, jika tidak, Anda mendeskripsikan konfigurasi orang lain.
  • Instrumentasi itu sendiri terdeteksi. Metode native yang diubah kehilangan toString yang benar, dan debugger yang terhubung meninggalkan jejak. Untuk eksplorasi ini tidak kritis, tetapi jangan bingungkan profil eksplorasi dengan profil tempur — teknik penyamaran otomatisasi dibahas dalam panduan tentang penyamaran headless-browser.

Proxy apa yang dibutuhkan untuk hasil

Kesimpulan praktis utama dari peta semacam itu hampir selalu satu: IP adalah hanya lapisan pertama, dan ia diperiksa lebih awal daripada yang lain. Jika anti-fraud sudah melihat alamat hosting pada tahap permintaan, maka tidak akan sampai ke audio graph dan kanvas — Anda akan mendapatkan tantangan atau hasil kosong dan akan memperbaiki hal yang salah.

Oleh karena itu, logika pemilihan adalah sebagai berikut. Untuk situs dengan tumpukan serius (Akamai, DataDome, PerimeterX, pengembangan internal tingkat Alibaba), basisnya adalah proxy residensial — alamat penyedia nyata yang tidak terputus pada filter pertama. Untuk aplikasi seluler dan situs di mana audiens utama menggunakan smartphone, proxy mobile lebih mendekati profil alami: CGNAT operator membuat alamat secara inheren dibagikan di antara banyak pengguna nyata.

Dan sebaliknya juga benar: jika peta menunjukkan bahwa situs dibatasi oleh header dan cookies, dan tidak ada sidik jari JS berat, — farm browser berlebihan, tugas ini dapat diselesaikan dengan klien HTTP biasa dan alamat data center.

Kesimpulan

Kasus dengan headphone berharga tidak hanya karena fakta sidik jari audio — tentang itu sudah diketahui selama bertahun-tahun. Berharga adalah metode: orang tersebut tidak percaya pada dugaan, tetapi membungkus dua metode API browser dan dalam satu malam mendapatkan daftar lengkap tentang apa yang diambil darinya, dan alamat ke mana itu pergi. Teknik yang sama memakan waktu satu jam di situs mana pun yang Anda kerjakan, dan menggantikan bulan-bulan percobaan pengaturan secara acak. Ambil peta deteksi sebelum memperbaiki pemblokiran — jika tidak, ada risiko menghabiskan anggaran untuk proxy di tempat masalahnya adalah pada renderer WebGL yang sama di semua profil.

```