Cách các hệ thống chống gian lận phát hiện việc giả lập di động

Sự tiến hóa của mô phỏng di động

Cách đơn giản nhất để chuyển từ máy tính để bàn sang di động là tính năng trong công cụ dành cho nhà phát triển cho phép bạn xem một trang web trông như thế nào ở bố cục di động. Tuy nhiên, điều quan trọng là phải hiểu rằng chế độ di động trong DevTools là một công cụ gỡ lỗi giao diện người dùng, không phải là một giải pháp giả mạo. DevTools sẽ không làm bạn vô hình trước Cloudflare hay DataDome.

Kỹ sư và affiliate sử dụng trình duyệt chống phát hiện để giả mạo và đa tài khoản. Các nhà phát triển giải pháp chống phát hiện đầu tư nguồn lực khổng lồ vào việc giả mạo vân tay sâu, từ WebGL và Canvas đến giả mạo ở cấp ngăn xếp mạng Chromium hoặc thông qua các lớp proxify.

Các trình duyệt chống phát hiện có hỗ trợ hồ sơ di động thường có thể được chia thành hai nhóm chính:

• các trình duyệt chống phát hiện mô phỏng một trình duyệt di động (nhưng không phải thiết bị thực);

• các trình duyệt chống phát hiện mô phỏng một thiết bị di động thực.

Hồ sơ di động (giả lập máy tính để bàn)

Danh mục này bao gồm hầu hết các trình duyệt chống phát hiện cổ điển và nâng cao mô phỏng một trình duyệt di động ở cấp phần mềm. Về mặt vật lý, những trình duyệt chống phát hiện như vậy vẫn chạy trên CPU máy tính để bàn của bạn, nhưng chúng giả mạo các tham số để trông như của thiết bị di động. Điều này bao gồm việc chặn và giả mạo vân tay WebGL, kiểm soát các tham số kết xuất Canvas và WebGL, mô phỏng sự kiện chạm, và đồng bộ hóa các chữ ký TLS ở ngăn xếp mạng của trình duyệt hoặc ở lớp proxy để chúng khớp với một hệ điều hành di động.

Đối với các hệ thống chống gian lận phân tích lưu lượng di động, một hồ sơ như vậy có thể trông như một khách hàng di động đáng tin cậy. Xét về hiệu quả chi phí, đây là một cách tiếp cận hiệu quả, nhanh chóng và dễ mở rộng, bao phủ hoàn hảo 90% các tác vụ không đòi hỏi thiết bị di động thực.

Thiết bị di động thực (điện thoại đám mây và cụm máy)

Những giải pháp này hoàn toàn từ bỏ việc giả mạo ở cấp phần mềm trên máy tính để bàn và thay vào đó cung cấp cho người dùng quyền truy cập vào điện thoại thông minh vật lý hoặc các máy ảo được triển khai trên bộ xử lý máy chủ ARM thực. Ở đây không cần phải bắt chước hành vi của cảm biến hay GPU di động, vì mọi thứ diễn ra một cách vật lý ở cấp phần cứng. Điểm khác biệt then chốt của cách tiếp cận này là khả năng chạy các ứng dụng di động gốc.

Việc có một hồ sơ trên thiết bị thực là điều không thể thiếu đối với các nền tảng có hệ thống bảo vệ cực kỳ tiên tiến, nơi việc đăng ký hoặc chuẩn bị tài khoản chỉ có thể thực hiện thông qua ứng dụng chính thức (TikTok, Instagram, các ứng dụng ngân hàng). Tuy nhiên, để đạt độ chân thực 100% phải trả giá, cả theo nghĩa đen lẫn nghĩa bóng: những hạ tầng như vậy chậm hơn, khó cấu hình hơn và đắt hơn nhiều lần.

Cách các hệ thống chống gian lận phơi bày việc giả mạo máy tính để bàn

Vì triển khai một hạ tầng gồm toàn điện thoại thông minh thực trong đa số trường hợp là quá đắt và chậm một cách không đáng, nên phần lớn chuyên gia làm việc với các hồ sơ di động chạy trên phần cứng máy tính để bàn.

Các hệ thống chống gian lận tính đến kinh tế của tiếp thị liên kết và thu thập dữ liệu. Chúng hoạt động dựa trên giả định rằng xác suất tìm thấy một máy chủ Ubuntu hoặc một PC Windows 11 tại nhà đang ẩn sau lớp mặt nạ thiết bị di động là cực kỳ cao.

Đó là lý do mục tiêu chính của chúng là gỡ bỏ lớp mặt nạ đó. Nhưng chính xác thì chúng làm điều đó như thế nào? Bí mật không nằm ở việc kiểm tra chiều rộng màn hình hay User-Agent, mà ở những khác biệt kiến trúc cơ bản giữa phần cứng máy tính để bàn và chip ARM di động.

Xung đột mật mã ở cấp TLS

Việc kiểm tra kỹ một hồ sơ di động giả bắt đầu từ rất lâu trước khi byte HTML đầu tiên được tải hay một dòng JavaScript duy nhất được thực thi. Bạn có thể bị gắn cờ ngay trong quá trình thiết lập kết nối HTTPS an toàn, tức cái gọi là bắt tay TLS.

Nó hoạt động thế nào? Khi bạn kết nối tới một trang web, trình duyệt sẽ gửi cho máy chủ một thông điệp ClientHello mở, một lời chào mật mã liệt kê các thuật toán mã hóa và tiện ích mở rộng được hỗ trợ. Đây là lúc những khác biệt kiến trúc cơ bản phát huy tác dụng.

Một thiết bị di động thực xây dựng gói ClientHello theo đặc điểm của hệ điều hành di động của nó. Đúng là Android dùng một ngăn xếp giống Chromium (giống như Chrome trên máy tính để bàn), nhưng môi trường di động áp đặt các quy tắc riêng: một bộ bộ mã hóa cụ thể, các tham số truyền tải khác nhau và thứ tự tiện ích mở rộng độc đáo. Một trình mô phỏng trên máy tính để bàn sẽ ghép gói này hơi khác đi. Kết quả là quá trình bắt tay với máy chủ diễn ra theo cách khác về mặt vật lý.

Ở bên trái bạn có thể thấy vân tay mật mã của một máy tính giả làm thiết bị di động, và ở bên phải là một gói TLS di động đúng chuẩn trên cùng một máy tính

Mô phỏng iPhone còn phức tạp hơn nữa. Hệ sinh thái của Apple hoàn toàn không sử dụng thư viện BoringSSL mà Chromium dựa vào. Safari sử dụng ngăn xếp TLS riêng của Apple, khiến vân tay của nó khác căn bản so với các trình duyệt dựa trên Chromium; nó xây dựng các gói theo một “ngôn ngữ mật mã” hoàn toàn khác. Nếu Chrome trên máy tính để bàn cố gắng bắt chước Safari di động ở mức socket, nó sẽ tạo ra sự lệch pha vân tay rất lớn và trông hết sức lố bịch đối với các hệ thống chống gian lận.

Các hệ thống bảo vệ hiện đại như Cloudflare và Akamai sử dụng các phương pháp lấy vân tay TLS như JA3 và JA4. Nếu bạn dùng mô phỏng di động chất lượng thấp, một hệ thống chống gian lận vững chắc thu thập các vân tay này sẽ ngay lập tức nhận ra sự không nhất quán:

• Ở cấp ứng dụng, User-Agent tuyên bố là Chrome di động trên Android.

• Ở cấp truyền tải, cấu trúc gói tiết lộ rằng thực ra đó là một trình duyệt máy tính để bàn đang chạy trên Windows.

Các thao tác chèn JS hoặc giả mạo tiêu đề HTTP thông thường sẽ không giúp ích ở đây, vì chúng hoạt động ở tầng ứng dụng và không thể thay đổi cách tệp nhị phân của trình duyệt mở socket.

Các trình duyệt chống phát hiện chất lượng cao, như Octo Browser, sửa đổi ngăn xếp mạng của Chromium ở mức mã nguồn. Chúng buộc engine trên máy tính để bàn phải tạo các gói mật mã cấp thấp đúng y như một thiết bị di động thực.

Rò rỉ phần cứng và toán học shader: GPU của bạn tố cáo bạn như thế nào

Hãy chuyển từ tầng mạng sang kết xuất đồ họa. Cách đơn giản và thô sơ nhất để ngụy trang phần cứng máy tính để bàn là chặn các lời gọi JavaScript tới API WebGL, nói cách khác, làm cho trình duyệt trả về tên của một GPU di động thay vì card đồ họa máy tính để bàn của bạn.

Vấn đề ở đây là các hệ thống chống gian lận hiện đại đã từ lâu không còn tin vào văn bản thuần túy. Các hệ thống tiên tiến kiểm tra phép toán và các giới hạn kiến trúc của đường ống đồ họa để xác minh xem thiết bị có thực sự là di động hay không. Chúng kiểm tra điều đó như thế nào?

Các dấu chấm than màu đỏ cho biết trình kiểm tra đã phát hiện sự can thiệp

• Giới hạn texture và đường ống: GPU di động như Qualcomm Adreno hoặc ARM Mali có các giới hạn phần cứng nghiêm ngặt. Ví dụ, tham số MAX_TEXTURE_SIZE truyền thống thấp hơn so với GPU máy tính để bàn, mặc dù các thiết bị flagship ngày nay có thể phần nào chồng lấp. Nếu một trình duyệt chống phát hiện chỉ giả mạo tên GPU mà bỏ qua các vi tham số này, trình duyệt sẽ báo hỗ trợ cho các texture máy tính để bàn khổng lồ có kích thước 16384 hoặc thậm chí 32768 pixel.

• Độ chính xác số thực: các thuật toán bảo vệ truy vấn phương thức getShaderPrecisionFormat để đo độ chính xác của phép tính dấu phẩy động. Chi tiết then chốt là các kiến trúc x86/x64 (máy tính để bàn) và ARM (di động) xử lý hình học và làm tròn khác nhau. Những khác biệt này đến từ GPU, trình điều khiển và API đồ họa. Việc kết xuất một cảnh 3D ẩn trên Canvas và băm kết quả (lấy vân tay điểm ảnh) có thể phơi bày các thuật toán raster hóa của máy tính để bàn.

• Giới hạn bộ nhớ: hệ điều hành di động thường áp đặt giới hạn nghiêm ngặt hơn đối với lượng RAM được cấp cho một tab trình duyệt. Một trình mô phỏng trên máy tính để bàn chạy trên máy có 32 GB RAM có thể dễ dàng hiển thị một cảnh nặng, và bản thân điều đó trở thành bằng chứng hành vi rằng hệ thống chống gian lận đang đối phó với một máy tính để bàn, không phải một điện thoại thông minh.

Bẫy dành cho script

Các giải pháp và tiện ích mở rộng đơn giản cố gắng che giấu những sự không nhất quán toán học này như thế nào? Chúng dựa vào việc chèn JS bằng cách ghi đè các hàm gốc của trình duyệt.

Nhưng điều này lại tạo ra một vấn đề khác: phân tích call stack. Một hệ thống chống gian lận có thể cố tình kích hoạt lỗi DOM. Một tiện ích mở rộng giả mạo ẩn sẽ chặn sự kiện, gặp lỗi nhân tạo đó, và để lại dấu vết của chính nó trong call stack của đối tượng Error, làm lộ các hàm bao bọc ẩn danh nội bộ hoặc các mục như VM5:44 trong bảng điều khiển.

Chỉ riêng sự tồn tại của giải pháp vòng qua đã trở thành bằng chứng. Đó là lý do tại sao việc giả mạo phần cứng đáng tin cậy chỉ có thể thực hiện sâu bên trong mã nguồn của trình duyệt, mà không phụ thuộc vào các script JS có thể tự tố cáo mình.

Ví dụ về các giải pháp chất lượng thấp

• Tiện ích mở rộng giả (User-Agent Switcher): ví dụ kinh điển với hàng triệu lượt cài đặt. Các công cụ này chỉ thay đổi một dòng trong tiêu đề HTTP. Bất kỳ bộ kiểm tra chống gian lận cơ bản nào cũng ngay lập tức thấy UA khai báo Android / Pixel 7 trong khi navigator.platform vẫn trả về Win32. Tất nhiên, những tiện ích mở rộng như vậy cũng hoàn toàn bỏ qua các vân tay TLS và việc giả mạo WebGL đúng cách.

UA khai là Android, trong khi các tham số còn lại cho thấy rõ ràng đây là một máy tính để bàn bình thường: đó là cách User-Agent Switcher hoạt động

• Trình giả lập game (BlueStacks, NoxPlayer, LDPlayer): một trong những sai lầm phổ biến nhất là cố gắng vượt qua các hệ thống chống gian lận bằng trình giả lập game. Những trình giả lập này được xây dựng cho hiệu năng, không phải cho ẩn danh. Chúng xử lý đồ họa một cách trực tiếp bằng GPU máy tính để bàn của bạn. Một truy vấn WebGL từ trình duyệt chạy bên trong BlueStacks hoặc NoxPlayer sẽ lộ ra phần cứng NVIDIA hoặc AMD thay vì GPU Adreno di động.

Các dấu chấm than cho thấy trình kiểm tra đã phát hiện một lần chèn JS. Trong ảnh chụp màn hình, một trình duyệt di động đang chạy thông qua trình giả lập NOX

• Tự động hóa trần trụi (Selenium/Puppeteer): trong nỗ lực tiết kiệm tiền, người ta thường viết các script Python tùy chỉnh kết hợp với proxy trung tâm dữ liệu. Nhưng việc giả mạo đúng chuẩn chỉ có thể được triển khai ở cấp nhân trình duyệt, điều mà các công cụ như Selenium không thể cung cấp.

Nghịch lý geo-engine

Mọi thứ đều rõ ràng với các giải pháp vòng qua rẻ tiền, nhưng ngay cả các giải pháp chuyên nghiệp cũng có thể gặp vấn đề không nhất quán vân tay. Các hệ thống chống gian lận có thể bắt bạn bằng logic đơn giản và địa chính trị. Hãy xem các thuật toán bảo vệ hiện đại suy nghĩ sâu đến mức nào qua ví dụ về iPhone.

Về mặt lịch sử, Apple từng yêu cầu nghiêm ngặt tất cả trình duyệt bên thứ ba trên iOS phải dùng engine WebKit. Việc cố gắng mô phỏng iOS bằng Chrome trên máy tính để bàn (Blink/V8) sẽ bị lộ ngay lập tức bằng cách kiểm tra các quy tắc CSS và API cụ thể.

Năm 2024, Liên minh châu Âu ban hành luật chống độc quyền buộc Apple phải cho phép các engine trình duyệt bên thứ ba trên iOS. Kết quả là, việc mô phỏng iPhone bằng Blink trở nên hợp pháp. Tuy nhiên, luật này chỉ áp dụng trong các quốc gia EU.

Các hệ thống chống gian lận bắt đầu phát hiện sự không nhất quán bằng cách tương quan chéo:

• UA: Chrome trên iOS.

• Công cụ JS: Blink (V8).

• Địa chỉ IP kết nối: Hoa Kỳ, Mỹ Latinh hoặc châu Á.

Kết quả là một hồ sơ rất có thể sẽ bị phân loại là giả. Một chiếc iPhone thật chạy Blink bên ngoài EU trên các kịch bản người dùng thông thường gần như không tồn tại. Đó là lý do Android thường là lựa chọn an toàn hơn, hợp lý hơn và dễ kiểm soát hơn nhiều.

Telemetry: vật lý đối đầu toán học

Bây giờ hãy chuyển từ địa chính trị sang vật lý. Một chiếc điện thoại thông minh thực sự vẫn là một vật thể vật lý tương tác với con người.

Các cảm biến phần cứng của nó—con quay hồi chuyển và gia tốc kế—liên tục ghi lại những chuyển động nhỏ từ cả thiết bị lẫn bàn tay người dùng. Các trình giả lập cơ bản mô phỏng sự rung này bằng các script với Math.random(). Nhưng các hệ thống chống gian lận tiên tiến có thể xử lý luồng dữ liệu này bằng các phương pháp phân tích tín hiệu. AI có thể dễ dàng phân biệt tiếng ồn trắng tổng hợp phẳng với vật lý hài hòa phức tạp của các cảm biến MEMS thật và các mẫu nhịp tim con người.

Tất nhiên, không phải hệ thống chống gian lận nào cũng có đủ năng lực tính toán để thực hiện phân tích như vậy, nhưng bạn nên kỳ vọng điều đó từ các nền tảng nghiêm túc như dịch vụ fintech hoặc mạng xã hội lớn.

Bên cạnh đó, sự khác biệt kiến trúc giữa bộ xử lý x86/x64 (máy tính để bàn) và bộ xử lý ARM (di động) tất yếu còn xuất hiện không chỉ trong kết xuất đồ họa, mà cả trong lập hồ sơ tính toán. Các hệ thống bảo vệ đo tốc độ thực thi và thời gian của các chỉ thị mật mã nặng, điều này thường cho phép xác định xem “bộ não” của thiết bị là CPU Intel hay AMD, hay là chip Snapdragon di động.

Khía cạnh thực tế: vì sao hồ sơ di động trong trình duyệt chống phát hiện vẫn lý tưởng cho 90% tác vụ

Sau khi đọc về phân tích phổ con quay hồi chuyển và toán học WebGL, bạn có thể nghĩ rằng kỷ nguyên mô phỏng máy tính để bàn đã kết thúc và mọi người nên khẩn trương chuyển sang các giải pháp đắt hơn với hồ sơ di động dựa trên thiết bị ARM thực. Nhưng hãy thực tế: chỉ một tỷ lệ nhỏ dịch vụ có hệ thống chống gian lận đủ tinh vi để kiểm tra hồ sơ của bạn sâu đến mức đó.

Các hồ sơ di động được tạo trong các trình duyệt chống phát hiện máy tính để bàn chất lượng cao với việc giả mạo ở cấp nhân vẫn đang là—and sẽ còn là trong thời gian dài—giải pháp hiệu quả và hợp lý về mặt kinh tế nhất cho phần lớn các tác vụ. Lý do là:

1. Web di động không chỉ là các ứng dụng gốc. Đúng, việc tạo tài khoản bằng ứng dụng di động gốc Instagram hoặc TikTok thông qua mô phỏng trên máy tính để bàn hiện nay rất khó khăn. Những nền tảng đó dùng các kiểm tra nghiêm ngặt về cảm biến và kiến trúc. Nhưng các phiên bản website di động bị giới hạn bởi hộp cát trình duyệt. Chúng không có quyền truy cập trực tiếp vào telemetry hệ điều hành cấp thấp. Nếu trình duyệt chống phát hiện của bạn giả mạo chính xác vân tay TLS, Client Hints, giới hạn bộ nhớ và các tham số WebGL sâu bên trong mã nguồn Chromium, bạn sẽ trông giống như lưu lượng tự nhiên đối với web di động.

2. Thương mại điện tử, thu thập dữ liệu và marketplace. Các nền tảng như Amazon, Wildberries, Ozon, các bộ tổng hợp vé và các trang cá cược chủ yếu quan tâm đến địa chỉ IP sạch, sự nhất quán về múi giờ và font, cùng việc không có các giải pháp vòng qua JS quá rõ ràng. Lưu lượng di động thường nhận được điểm tin cậy cao hơn từ những nền tảng như vậy. Đó là lý do sử dụng hồ sơ di động để thu thập dữ liệu các bố cục di động hoặc săn bonus giúp giảm nguy cơ CAPTCHA hoặc bị khóa tài khoản. Các hồ sơ di động dựa trên ARM thực cho những tác vụ này về cơ bản là quá mức cần thiết và tốn kém không cần thiết.

3. Khả năng mở rộng và hiệu quả chi phí. Lợi thế lớn nhất của mô phỏng trên máy tính để bàn là khả năng mở rộng với chi phí hiệu quả. Một máy chủ tầm trung duy nhất có thể chạy hàng trăm hồ sơ web di động. Ngược lại, thuê các node ARM thực hoặc điện thoại thông minh vật lý tốn một khoản tiền khổng lồ. Nếu điều bạn cần là tiếp thị liên kết qua giao diện web, quản lý tài khoản quảng cáo trên Facebook hoặc Google, hoặc thu thập dữ liệu, thì các trình duyệt chống phát hiện trên máy tính để bàn mang lại ROI cao hơn đáng kể.

Kết luận

Bạn cần hiểu rõ mục tiêu của mình. Nếu bạn tự động hóa các hành động bên trong các ứng dụng APK gốc tinh vi, bạn không thể tránh việc sử dụng thiết bị thực hoặc hồ sơ chạy trên thiết bị thực. Nhưng đối với làm việc với web di động, quảng cáo, thu thập dữ liệu và thương mại điện tử, các hồ sơ di động chất lượng cao được tạo trong một trình duyệt chống phát hiện đáng tin cậy vẫn là sự cân bằng lý tưởng giữa mức độ tin cậy và chi phí mở rộng.

Tin tức sản phẩm

Octo Browser hiện đã có trên iOS