Vào ngày 20 tháng 8 năm 2026, nhà phát triển Matt Callaghan (blog laserphile) đã công bố phân tích một lỗi kỳ lạ: tai nghe Bluetooth của anh với multipoint không thể chuyển đổi từ máy tính sang điện thoại. Mỗi lần khi mở tab AliExpress. Anh không đoán mò — anh đã sử dụng API trình duyệt và xem điều gì đang xảy ra bên trong trang. Hóa ra, hai script bị mã hóa từ stack chống gian lận của Alibaba đã kích hoạt âm thanh và lấy dấu vân tay thiết bị qua âm thanh mà không ai nghe thấy.
Đây là minh họa hoàn hảo cho điều mà hầu như không ai làm trước khi thiết lập hồ sơ hoặc khởi động trình phân tích: không đọc stack phát hiện của nền tảng, mà đoán nó. Dưới đây là phương pháp thực tiễn để tự tay lấy bản đồ phát hiện của một trang web cụ thể, trong vòng một giờ, mà không cần đảo ngược mã hóa và không cần dịch vụ trả phí.
Tại sao cần lấy bản đồ phát hiện
Chu trình điển hình trông như sau: tài khoản bị cấm — điều chỉnh cài đặt trình duyệt chống phát hiện một cách ngẫu nhiên — thay đổi proxy — lại bị cấm. Giữa "bị cấm" và "cài đặt" không có dữ liệu: không rõ nền tảng đang đọc gì và trên lớp nào bị bắt.
Bản đồ phát hiện lấp đầy khoảng trống này. Đây là danh sách: nhà cung cấp bảo vệ nào đang hoạt động, những script nào thực hiện nó, những API nào họ chạm vào và kết quả đi đâu. Tiếp theo, bạn sẽ thấy nơi thực sự là điểm nghẽn — ở IP, dấu vân tay mạng hay lớp phần cứng của trình duyệt. Điều này đều hữu ích cho ba đối tượng:
- Đa tài khoản — hiểu tín hiệu nào kết nối các hồ sơ. IP của họ khác nhau, nhưng âm thanh, trình render WebGL và hardwareConcurrency thường giống nhau trên toàn bộ trang trại.
- Thu thập dữ liệu — hiểu liệu có cần khởi động trình duyệt hay nhiệm vụ có thể được giải quyết bằng HTTP client với dấu vân tay TLS chính xác.
- Bảo mật riêng tư — thấy chính xác cửa hàng hoặc dịch vụ thu thập thông tin gì về thiết bị của bạn ngoài cookies.
Bước 1. Xác định nhà cung cấp bảo vệ qua mạng
Điều đầu tiên bạn làm là mở DevTools trên tab Network, tải trang và xem tiêu đề và cookies của tài liệu đầu tiên. Các dấu hiệu nhận biết là nổi tiếng và ổn định:
CF-RAYtrong tiêu đề phản hồi và cookiecf_clearance— Cloudflare.- Cookie
_abckvà script với hàmbmak— Akamai Bot Manager. - Các biến và cookies với tiền tố
_px— PerimeterX (HUMAN). - Cookie
datadomevà một JS riêng từ miền của nhà cung cấp — DataDome. - Một
429trống không có nội dung phản hồi — dấu hiệu đặc trưng của Kasada.
Nếu bạn lười làm thủ công, có các bộ phát hiện mở như microlinkhq/is-antibot (30+ nhà cung cấp) và các tiện ích mở rộng trình duyệt phát hiện cho 26+ nhà cung cấp. Chúng cung cấp câu trả lời nhanh chóng đầu tiên, nhưng không trả lời câu hỏi chính — điều gì đang được đo lường trong trình duyệt của bạn. Bạn cần phải đi xa hơn để tìm hiểu điều đó.
Bước 2. Lấy danh sách các script đáng ngờ
Lọc Network theo loại JS và ghi lại tất cả những gì tải không từ miền chính hoặc nằm trong các thư mục dịch vụ. Trong trường hợp AliExpress, đó là hai tệp với đường dẫn rõ ràng là dịch vụ:
assets.aliexpress-media.com/g/AWSC/uab/1.140.0/collina.jsassets.aliexpress-media.com/g/AWSC/fireyejs/1.231.67/fireyejs.js
Dấu hiệu của script chống gian lận: mã hóa bị mã hóa, phiên bản trong đường dẫn, một miền phụ riêng cho tĩnh, không có bất kỳ liên kết nào với phần hình ảnh của trang. Không cần mở và đọc mã hóa — ở bước tiếp theo, script sẽ tự nói về bản thân.
Bước 3. Công cụ hóa fingerprint-API
Đây là cốt lõi của phương pháp và chính xác là những gì Callaghan đã làm: anh đã bọc constructor AudioContext và AudioNode.prototype.connect(), sau đó thấy hai audio context sống trên trang, nơi không có bất kỳ phần tử media nào và không có bất kỳ cuộc gọi play().
Logic rất đơn giản: bạn thay thế phương thức mà bạn quan tâm bằng một lớp bọc của riêng bạn, ghi lại cuộc gọi với stack và chuyển quyền điều khiển cho bản gốc. Stack cuộc gọi cho thấy script nào đã gọi API. Chèn đoạn mã như vậy dễ nhất qua DevTools Sources → Snippets hoặc qua một tiện ích mở rộng thực thi mã trên document-start — quan trọng là phải kịp trước khi tải script chống gian lận.
Bộ công cụ tối thiểu, đóng kín hầu hết các tín hiệu:
HTMLCanvasElement.prototype.toDataURLvàgetImageData— dấu vân tay canvas.WebGLRenderingContext.prototype.getParameter— mô hình card đồ họa và driver, độ chính xác của shader.AudioContext/OfflineAudioContextvàAudioNode.prototype.connect— dấu vân tay âm thanh.- Các getter
navigator.hardwareConcurrency,navigator.deviceMemory,navigator.plugins,navigator.webdriver. RTCPeerConnection— WebRTC và địa chỉ cục bộ.screen.width/height,devicePixelRatio,Intl.DateTimeFormat().resolvedOptions()— màn hình và múi giờ.navigator.mediaDevices.enumerateDevices— danh sách thiết bị âm thanh và video.
Cuối cùng, bạn sẽ có một danh sách: những API nào trong số này đã được gọi, bao nhiêu lần và bởi ai. Trong trường hợp đã phân tích, các script của Alibaba đã chạm vào canvas và toDataURL, trình render WebGL và độ chính xác của shader, âm thanh qua oscillator và analyzer, kích thước màn hình và devicePixelRatio, hardwareConcurrency và deviceMemory, plugins, hỗ trợ codec, WebRTC, thời gian hiệu suất, mẫu chuyển động chuột và chạm, cảm biến chuyển động thiết bị và các thuộc tính chỉ báo tự động hóa.
Âm thanh đã làm gì với đồ thị
Hữu ích để hiểu cách đo lường trông như thế nào, để nhận ra nó ở những nơi khác. Đồ thị trông như sau: oscillator hình răng cưa → AnalyserNode → ScriptProcessorNode, đọc kết quả phân tích → GainNode với độ khuếch đại bằng không → destination. Không có âm thanh, âm lượng không quan trọng — nó đơn giản là không có. Nhưng kết nối với destination, theo cách diễn đạt của tác giả, khiến trình duyệt xử lý đồ thị một cách tích cực, mặc dù âm lượng cuối cùng bằng không. Chính đường âm thanh sống đã giữ kết nối Bluetooth mở, phá vỡ việc chuyển đổi multipoint của tai nghe.
Sự khác biệt trong việc xử lý tín hiệu này phụ thuộc vào bộ xử lý, phần cứng âm thanh, hệ điều hành, trình duyệt và driver — từ đó mà có được định danh ổn định, sống sót qua việc thay đổi IP và xóa cookies. Phân tích chi tiết chính xác lớp này và thiết lập hồ sơ cho nó — trong bài viết về bảo vệ chống lại Audio Context Fingerprinting.
Bước 4. Bắt gửi kết quả
Việc thu thập mà không gửi là vô nghĩa, vì vậy bước tiếp theo là tìm xem dấu vân tay đã thu thập đi đâu. Lọc Network theo XHR/Fetch và xem riêng các yêu cầu kiểu ping — chúng được tạo ra bởi navigator.sendBeacon, mà các script telemetry thích sử dụng, vì nó sống sót qua việc rời khỏi trang.
Thường thì có ích khi bọc thêm fetch, XMLHttpRequest.prototype.send và navigator.sendBeacon — sau đó bạn sẽ thấy nội dung yêu cầu trước khi nó đi. Chuẩn bị cho việc nội dung sẽ được tuần tự hóa và mã hóa: trong trường hợp AliExpress, dữ liệu được mã hóa trước khi gửi đến telemetry của Alibaba. Nhưng ngay cả như vậy, bạn nhận được hai thông tin: địa chỉ nhận và thời điểm gửi liên quan đến hành động của bạn.
Nếu trang web không chỉ hoạt động trong trình duyệt mà còn qua ứng dụng di động hoặc khách hàng riêng, câu hỏi tương tự được giải quyết ở cấp độ lưu lượng, không phải DOM — phương pháp chặn và phân tích được mô tả trong phân tích kiểm toán lưu lượng qua mitmproxy.
Bước 5. Đối chiếu bản đồ với hồ sơ của bạn
Bây giờ bạn có danh sách các tín hiệu mà nền tảng thực sự đọc. Còn lại là kiểm tra xem hồ sơ làm việc của bạn phản hồi như thế nào với những tín hiệu này. Thứ tự như sau: bạn lấy giá trị trong trình duyệt thông thường, sau đó trong mỗi hồ sơ chống phát hiện và so sánh.
Hai điều quan trọng cùng một lúc: các giá trị phải khác nhau giữa các hồ sơ và ổn định trong một hồ sơ giữa các phiên. Hồ sơ mà có dấu vân tay thay đổi mỗi lần khởi động trông không kém phần nghi ngờ so với mười hồ sơ có dấu vân tay giống nhau.
Kiểm tra riêng xem việc thay thế có thực sự tồn tại ở lớp cần thiết. Ở đây, sự phân tán giữa các trình duyệt là đáng chú ý: Firefox từ phiên bản 118 trả về đầu ra WebAudio không thay đổi, và theo dữ liệu phân tích, 99,24% người dùng giảm xuống ba giá trị; Brave thêm dữ liệu ngẫu nhiên và từ ngày 22 tháng 8 năm 2026 đã chặn chính xác những script AliExpress này, nhắc nhở rằng bảo vệ chống lại dấu vân tay âm thanh đã có mặc định hơn sáu năm; Safari thêm lỗi vào bộ đệm âm thanh; Chrome không có bảo vệ mạnh mẽ.
Các cạm bẫy
- Script đã kịp hoạt động. Việc chặn tệp không tiêu diệt được audio context đã tạo ra — tác giả lưu ý rõ ràng rằng các tab mở cần phải đóng. Điều này cũng áp dụng cho việc công cụ hóa của bạn: nếu lớp bọc được thêm sau script, bạn sẽ không thấy gì.
- Chặn làm hỏng chức năng. Stack chống gian lận thường cũng chịu trách nhiệm cho những điều hợp pháp — xác thực, thanh toán, bảo vệ chống bot khỏi lạm dụng thực sự. Lấy bản đồ phát hiện và cắt bỏ script là hai nhiệm vụ khác nhau; nhiệm vụ thứ hai làm hỏng trang web.
- Phiên bản phát hiện không chỉ có một. Stack có thể khác nhau theo địa lý, theo loại thiết bị và theo nhóm A/B. Có ý nghĩa khi lấy bản đồ từ IP và thiết bị mà bạn thực sự làm việc, nếu không bạn đang mô tả cấu hình của người khác.
- Công cụ hóa tự nó cũng bị phát hiện. Các phương thức gốc đã được định nghĩa lại mất
toStringchính xác, và trình gỡ lỗi được kết nối để lại dấu vết. Đối với việc thu thập thông tin, điều này không quan trọng, nhưng đừng nhầm lẫn hồ sơ thu thập thông tin với hồ sơ chiến đấu — các kỹ thuật ngụy trang tự động đã được phân tích trong hướng dẫn về ngụy trang trình duyệt headless.
Proxy nào cần cho kết quả
Kết luận thực tiễn chính từ bản đồ như vậy gần như luôn luôn là một: IP chỉ là lớp đầu tiên, và nó được kiểm tra trước tất cả các lớp khác. Nếu stack chống gian lận đã thấy địa chỉ hosting ở giai đoạn yêu cầu, thì sẽ không có cơ hội đến đồ thị âm thanh và canvas — bạn sẽ nhận được thách thức hoặc kết quả trống rỗng và sẽ sửa chữa sai chỗ.
Vì vậy, logic lựa chọn như sau. Đối với các nền tảng có stack nghiêm trọng (Akamai, DataDome, PerimeterX, các phát triển riêng ở cấp độ Alibaba), cơ sở là proxy dân cư — địa chỉ của các nhà cung cấp thực tế, không bị chặn ở bộ lọc đầu tiên. Đối với các ứng dụng di động và các nền tảng mà phần lớn người dùng sử dụng smartphone, proxy di động gần hơn với hồ sơ tự nhiên: CGNAT của nhà mạng làm cho địa chỉ trở nên chia sẻ giữa nhiều người dùng sống.
Và điều ngược lại cũng đúng: nếu bản đồ cho thấy rằng nền tảng bị giới hạn bởi tiêu đề và cookies, và không có fingerprint JS nặng, — trang trại trình duyệt là dư thừa, nhiệm vụ có thể được giải quyết bằng HTTP client thông thường và địa chỉ từ trung tâm dữ liệu.
Kết luận
Trường hợp với tai nghe có giá trị không phải ở chính việc có dấu vân tay âm thanh — điều này đã được biết đến trong nhiều năm. Giá trị nằm ở phương pháp: con người không tin vào những phỏng đoán, mà đã bọc hai phương pháp API trình duyệt và trong một buổi tối đã có được danh sách đầy đủ những gì đang được lấy từ anh ta, và địa chỉ mà nó đi đến. Cùng một thủ thuật mất một giờ trên bất kỳ nền tảng nào mà bạn làm việc, và thay thế hàng tháng thử nghiệm cài đặt ngẫu nhiên. Hãy lấy bản đồ phát hiện trước khi sửa chữa các lệnh cấm — nếu không có nguy cơ tiêu tốn ngân sách vào proxy ở nơi mà vấn đề nằm ở việc có cùng một trình render WebGL trên tất cả các hồ sơ.
```