Tiêu chuẩn xác thực ảnh C2PA trên Android bị vô hiệu hóa bởi lỗ hổng root

Bởi David Buchanan (hay còn gọi là retr0id), ngày 25 tháng 8 năm 2026

Có lẽ bạn đã nghe nói rằng C2PA là một công nghệ sẽ cứu chúng ta một cách thần kỳ khỏi vấn nạn giả mạo bằng AI, bằng cách yêu cầu các máy ảnh ký mã hóa vào những hình ảnh mà chúng ghi lại. Hoan hô mật mã học!

Rất tiếc. Điều đó sẽ không hiệu quả đâu. Có rất nhiều vấn đề ở đây, vì vậy tôi sẽ cố gắng đi thẳng vào vấn đề nhanh nhất có thể:

Các ứng dụng máy ảnh hỗ trợ C2PA trên nền tảng Android dựa vào Key Attestation (Chứng thực khóa) và/hoặc Google Play Integrity để ngăn người dùng can thiệp vào ứng dụng nhằm ký vào các tệp tùy ý (thay vì dữ liệu từ cảm biến hình ảnh của thiết bị).

Việc có thể ký vào các tệp tùy ý sẽ phá vỡ mô hình tin cậy của C2PA.

Các lỗ hổng leo thang đặc quyền root (Root privilege escalation) sẽ phá vỡ mô hình bảo mật Key Attestation của Android, và cả Play Integrity cũng vậy.

Các thiết bị Android có thể bị root thông qua các cuộc tấn công tiêm lỗi phần cứng (hardware fault injection) chi phí thấp.

Các lỗ hổng phần cứng trên các thiết bị hiện có không thể được vá (vấn đề này có những sắc thái riêng, sẽ được thảo luận sau).

Do đó, C2PA trên nền tảng Android đã bị phá vỡ theo cách không thể vá lỗi một cách thực tế.

Không có điều nào ở trên là "0day" (lỗ hổng chưa được công bố), và tất cả đã được báo cáo cho các bên liên quan ít nhất 90 ngày trước (nhưng bất kỳ ai tỉnh táo đều có thể đoán trước được điều này, như nhiều người đã làm).

Nhưng khoan đã, vẫn còn nữa! Nhờ một phần vào các mô hình ngôn ngữ lớn (LLM), các lỗ hổng leo thang đặc quyền root (root LPE) đang xuất hiện nhanh hơn tốc độ Google tung ra các bản vá. Tại thời điểm viết bài, các công cụ root "một cú nhấp chuột" đang tồn tại ngoài thực tế cho các thiết bị Google Pixel đã được vá đầy đủ (thông qua CVE-2026-43499). Với những công cụ này, bất kỳ ai cũng có thể tạo ra các bản giả mạo C2PA mà không cần đến các cuộc tấn công phần cứng. Sau đây trong bài viết này, tôi sẽ cung cấp hướng dẫn để thực hiện điều đó.

Như bạn có thể thấy, tôi đang tập trung vào Android ở đây. Tôi sẽ để Google giải thích lý do tại sao:

Ứng dụng Pixel Camera đã đạt được Assurance Level 2 (Mức độ đảm bảo 2), xếp hạng bảo mật cao nhất hiện được xác định bởi Chương trình tuân thủ C2PA. Assurance Level 2 cho một ứng dụng di động hiện chỉ khả thi trên nền tảng Android.

Nghĩa là, tôi đang tấn công vào bản triển khai "mạnh nhất" chỉ để chứng minh quan điểm của mình. Đây là một hình ảnh rác do AI tạo ra, mà C2PA khẳng định là một bức ảnh thật chưa qua chỉnh sửa trực tiếp từ ứng dụng Pixel Camera: (Di chuột để làm rõ nét, nhấp để "xác minh" nó)

Và đây là một video Youtube mà hộp thông tin cho biết đã được "ghi lại bằng máy ảnh" (cảnh báo spoiler: không phải vậy).

Chỉnh sửa, 2026-08-25T19:12:16Z: Google dường như đã xóa phần "Được ghi lại bằng máy ảnh" khỏi mô tả video, có lẽ là xóa thủ công. Điều đó không giải quyết được nhiều vấn đề—hãy đọc tiếp để tìm hiểu cách tự ký vào phương tiện của riêng bạn. Ngoài ra, tôi đã đổi URL sang một URL khác. Các bản giả mạo sẽ tiếp tục xuất hiện cho đến khi tinh thần được cải thiện.

Nhân tiện, có tin đồn rằng Apple đang phát triển giải pháp xác thực nguồn gốc phương tiện của riêng họ, nhưng nó vẫn chưa tồn tại. Tôi sẽ cho bạn biết suy nghĩ của mình về nó khi nó ra mắt. Tôi nghi ngờ rằng sự tích hợp theo chiều dọc của họ sẽ mang lại cho họ một lợi thế đáng kể, điều này có thể chuyển các cuộc tấn công dễ dàng nhất sang lĩnh vực quang học (chụp ảnh màn hình, v.v.).

Dù sao thì, hãy đi vào chi tiết.

Làm thế nào mà root LPE phá vỡ cơ chế chứng thực khóa "dựa trên phần cứng"?

Chứng thực chỉ xác nhận một số điều nhất định, bao gồm:

Cách "thông thường" để root một thiết bị Android là mở khóa bộ nạp khởi động (bootloader) và cài đặt một bản firmware đã sửa đổi, quá trình này buộc thiết bị phải khôi phục cài đặt gốc. Cơ chế chứng thực sẽ gắn cờ rằng bootloader đã được mở khóa, và Google sẽ từ chối cung cấp khóa C2PA cho thiết bị của bạn (và Netflix sẽ không cung cấp nội dung độ phân giải cao cho bạn, ứng dụng ngân hàng của bạn sẽ không hoạt động, v.v.).

Cho đến nay, mọi thứ vẫn ổn (nếu bạn thích kiểu đó).

Tuy nhiên, nếu bạn root thiết bị thông qua một lỗ hổng, cơ chế chứng thực không có cách nào đáng tin cậy để "nhận ra". Bootloader vẫn bị khóa, các khóa AVB không bị sửa đổi và thiết bị vẫn đang chạy bản cập nhật bảo mật mà nó đã khởi động ban đầu. Bây giờ, các máy chủ của Google sẽ vui vẻ cung cấp khóa cho một thiết bị đã bị xâm nhập.

Các khóa C2PA vẫn được bảo vệ bởi bảo mật phần cứng, bên trong StrongBox (trong Titan M2, trên các thiết bị Pixel mới hơn). Điều này ngăn kẻ tấn công lấy khóa ra, ngay cả khi có quyền root. Tuy nhiên, kẻ tấn công không cần dữ liệu khóa thô! Với quyền root, chúng có thể yêu cầu StrongBox sử dụng các khóa này để ký vào bất kỳ dữ liệu nào chúng muốn và tạo ra các bản giả mạo C2PA (hoặc giải mã hộp thư đến Signal của bạn, cùng nhiều điều tồi tệ khác).

Lý thuyết đằng sau thiết kế của cơ chế chứng thực là các lỗ hổng phần mềm LPE đã biết cần được vá, sau đó Bên dựa vào (Relying Party - thực thể xác minh báo cáo chứng thực) có thể yêu cầu người dùng cài đặt các bản cập nhật, và khi đó thiết bị đã cập nhật sẽ không còn bị LPE nữa.

CVE-2026-43499 là bằng chứng cho thấy các bản vá kịp thời không phải lúc nào cũng có sẵn, nhưng hãy cứ cho mọi người hưởng lợi từ sự nghi ngờ và giả định rằng các lỗ hổng công khai cho các lỗi chưa được vá không bao giờ tồn tại. Vẫn còn hai vấn đề còn lại:

Bất kỳ thực thể nào có nguồn lực tài chính vừa phải, từ chính phủ đến các công ty pháp y di động, đều có thể xây dựng một kho lưu trữ các lỗ hổng riêng (và họ thực sự làm vậy). Đây chính xác là những nhóm mà bạn không muốn họ giả mạo chữ ký C2PA.

Các lỗ hổng phần cứng chi phí thấp luôn tồn tại, bất kể cấp độ bản vá.

Làm thế nào tôi ký vào hình ảnh và video demo?

Ban đầu, tôi đã sử dụng một cuộc tấn công phần cứng. Đó là sự tiếp nối nghiên cứu trước đây của tôi: Bạn có thể lấy quyền root chỉ với một chiếc bật lửa không?

Tôi đã định viết chi tiết về nó ở đây, nhưng thẳng thắn mà nói, các con đường khai thác chỉ bằng phần mềm đã chiếm mất sự chú ý của tôi. Các lỗ hổng phần mềm thuận tiện hơn nhiều khi chúng tồn tại, vì vậy tôi sẽ để dành các chi tiết phần cứng đầy đủ cho một dịp khác. Không cần vội vàng, vì các lỗ hổng phần cứng phần lớn không thể vá được.

Nếu bạn muốn tái tạo các phát hiện của tôi ngay hôm nay, tôi khuyên bạn nên dùng công cụ Root My Pixel. (Lưu ý: mặc dù nó hỗ trợ các bản cập nhật bảo mật tháng 8 mới nhất của hầu hết các thiết bị Pixel hiện nay, bạn sẽ cần build từ nhánh main để kích hoạt hỗ trợ đó. Tôi đã tự mình thử nghiệm trên Pixel 8a và 9a.)

Sau khi có quyền root, phần còn lại của cuộc tấn công chỉ là kỹ thuật. Tôi đã tạo một công cụ để hỗ trợ việc này: keystork. Keystork có kiến trúc máy khách/máy chủ, cho phép mã máy khách thực hiện các thao tác tùy ý đối với API KeyStore, trong khi mạo danh bất kỳ ứng dụng nào đã cài đặt. "Máy chủ" (keystorkd) chạy trên thiết bị đã root, và máy khách là bất cứ thứ gì có thể giao tiếp với giao thức mạng mà tôi đã tạo ra (mặc định được truyền qua unix domain socket chuyển tiếp qua ADB). Máy khách tham chiếu là một thư viện python với giao diện CLI tương ứng, nhưng về lý thuyết, các ứng dụng Android có thể giao tiếp với nó theo kiểu Shizuku (mặc dù trước tiên bạn sẽ muốn xây dựng một lớp xác thực/quyền hạn).

Đây là tập lệnh PoC "ký vào bất kỳ hình ảnh nào", chống lại ứng dụng Pixel Camera: https://gist.github.com/DavidBuchanan314/fa0ffdaaaa31594e6a511118c1cea1e0

Trong khi các lỗ hổng phần mềm có thể và sẽ được vá (cuối cùng), các lỗ hổng phần cứng là mãi mãi. Hay là không?

Các cuộc tấn công phần cứng có thể được giảm thiểu không?

Về lý thuyết là có, nhưng trên thực tế thì không hẳn.

Chiến lược ban đầu của tôi (đảo bit trong PTE) vẫn hoạt động trên các thiết bị Pixel ngày nay. Tuy nhiên, nó không hoạt động trên các thiết bị Samsung!

Tôi đã thực hiện một số thử nghiệm ban đầu trên thiết bị Samsung A07 (vì chúng rẻ). Lỗ hổng đã hoạt động vào thời điểm đó, nhưng sau một bản cập nhật bảo mật, nó đã ngừng hoạt động (tôi nghĩ thời điểm đó chỉ là sự trùng hợp). Bản cập nhật đã kích hoạt tính năng giảm thiểu "RKP" của Samsung (Real-time Kernel Protection - Bảo vệ nhân thời gian thực, không nên nhầm lẫn với Remote Key Provisioning...).