AI Rewrite1 tháng 5, 20262 phút đọc

Dịch Ngược Hộp Đen: Phá Giải Luồng Play Integrity Của Twitter

Cách Twitter giấu quá trình xác thực thiết bị khỏi các công cụ proxy mạng bằng Binder IPC và công thức mật mã đứng sau các chuỗi nonce.

L

Lugon

Vibe Engineer

Chia sẻ bài viết

Các công cụ proxy mạng như Burp Suite hay mitmproxy vốn là tiêu chuẩn trong mảng dịch ngược ứng dụng di động. Tuy nhiên, khi phân tích ứng dụng Twitter trên Android, các nhà nghiên cứu bảo mật phát hiện ra một điều kỳ lạ: các request xác thực thiết bị (attestation) hoàn toàn "bốc hơi". Kể cả khi đã bypass SSL Pinning, bạn vẫn không thể bắt được chúng. Lý do? Không hề có kết nối mạng nào được tạo ra.

Lớp Tàng Hình: Binder IPC

Hầu hết các kỹ thuật bắt gói tin đều giả định mô hình: App → TLS → Network → Proxy → Server. Luồng xác thực của Twitter bỏ qua hoàn toàn con đường này.

Bước trao đổi quan trọng nhất để chứng minh thiết bị là hợp lệ diễn ra giữa hai tiến trình trên cùng một thiết bị, thông qua cơ chế Binder IPC của Android:

  • App Twitter giao tiếp nội bộ qua Binder IPC với Google Play Store (com.android.vending).

  • Google Play Store tạo kết nối TLS nội bộ lên Server của Google.

  • Server trả về một protobuf đã được ký xác nhận cho app thông qua Binder.

  • Cuối cùng, app Twitter gói payload này vào một cấu trúc nội bộ tùy chỉnh và gửi lên API của Twitter.
  • Không có socket TCP nào được tạo ra cho bước xác minh của Google. Do đó, các proxy hoàn toàn bị "mù".

    Chọc Ngoáy Bằng Frida

    Để can thiệp vào luồng này, các nhà nghiên cứu dùng Frida để hook vào chốt chặn cuối cùng của OkHttp. Bằng cách nhắm vào RealCall.execute, họ có thể tóm được payload ngay trước khi nó chui xuống tầng mạng, sau khi tất cả các interceptor tùy chỉnh đã chạy xong.

    Tuy nhiên, phần body của request bị giấu trong một cấu trúc dữ liệu tùy chỉnh. Bằng cách dùng Java reflection ở runtime, payload JSON thực sự đã được moi ra, hé lộ một quy trình gồm ba bước khởi động và xác thực thiết bị.

    Khám Phá Cốt Lõi: Công Thức Băm Nonce

    Phát hiện quan trọng nhất của bài nghiên cứu nằm ở cách tạo ra chuỗi nonce. Thông thường, nonce là một chuỗi UUID ngẫu nhiên. Nhưng với Twitter, chuỗi Play Integrity nonce gửi cho Google bị trói buộc bằng mật mã học với trạng thái của thiết bị.

    Play Integrity nonce = Base64( SHA-256( chuỗi_json_attestation_object ) )

    Điều này có nghĩa là:

    • Nonce mang tính tất định (deterministic), không phải ngẫu nhiên.

    • Bất kỳ thay đổi nào ở các trường dữ liệu (userId, deviceModel, v.v.) đều làm thay đổi mã băm SHA-256, khiến token trở nên vô giá trị.

    • Các cuộc tấn công phát lại (Replay attacks) là bất khả thi vì chuỗi UUID do server tạo ra nằm trong attestation object thay đổi liên tục mỗi lần gọi.


    Thử Nghiệm Trên Máy Huawei

    Để chứng minh sự phụ thuộc hoàn toàn vào Google Play Services, bộ cài APK đã được test trên máy Huawei P40 Lite—thiết bị chạy HMS và không có Google.

    Kết quả? PlayCore SDK thất bại trong việc kết nối tới ExpressIntegrityService. Server buộc phải cấp một fallback token, và hệ thống lập tức từ chối đăng nhập với lỗi LoginError.AttestationDenied. Điều này khẳng định rằng: nếu không có hạ tầng Google và cầu nối IPC nội bộ, app Twitter sẽ ngay lập tức "bế quan tỏa cảng".


    Credit

    securityreverse-engineeringandroidplay-integrity
    Chia sẻ bài viết
    Bắt Đầu Dự Án

    Sẵn sàng để chuyển đổi?

    Tìm hiểu cách TeguFy có thể giúp doanh nghiệp của bạn simplify, amplify và fortify với AI, Blockchain và công nghệ tiên phong.