ProGuard không còn đủ: AI đang tự động hoá dịch ngược APK

Bạn ship một bản APK fintech, bật ProGuard, đổi hết tên class thành a, b, c rồi coi như xong phần chống dịch ngược. Vài tuần sau có người gọi đúng endpoint nội bộ mà chỉ app mới biết đường ký. Dưới đây là những gì lớp công cụ reverse engineering có AI hỗ trợ thực sự thay đổi, và lớp phòng thủ nào còn làm attacker tốn thời gian.

REA tự động hoá đúng phần đắt nhất: đọc hiểu code

Theo một bài phân tích trên Dev.to, REA (Reverse Engineer Anything) là một AI-driven reverse-engineering agent framework đại diện cho xu hướng kết hợp large language models với công cụ reverse engineering truyền thống, bằng cách đưa JADX, Ghidra và IDA vào một workflow có AI tham gia.

Điểm thay đổi nằm ở chi phí thời gian. Bài viết mô tả: trước đây phân tích một APK "thường đòi hỏi một reverse engineer có kinh nghiệm bỏ ra nhiều ngày, thậm chí nhiều tuần"; với AI hỗ trợ, "một số tác vụ trong đó có thể hoàn thành nhanh hơn nhiều". Cùng xu hướng, Kritt-ai/open-kritt — công cụ "self-hosted AI vulnerability research" điều phối agent tìm và xác nhận lỗi bảo mật trong code — đang có 2.284 sao GitHub.

Vì sao đổi tên class không còn là phòng thủ

Ví dụ trong bài: một hàm checkPermission sau obfuscation cơ bản chỉ còn là

boolean a(b c) { return c.d >= 10; }

Tác giả lập luận rằng mô hình AI "vẫn có thể suy ra method này thực hiện kiểm tra permission-level dựa trên tham số, call site, giá trị trả về và ngữ cảnh xung quanh". Lợi thế của AI không phải đọc code, mà là suy ra ý nghĩa sau code — nên việc chỉ đổi tên class và method "đang kém hiệu quả dần khi đứng một mình".

Với packing hay mã hoá DEX, bài chỉ ra lỗ hổng quen thuộc: nếu attacker dump được DEX gốc từ memory thì code khôi phục "có thể một lần nữa đọc được bằng công cụ phân tích tiêu chuẩn". Câu đáng nhớ: REA không cần tự phá mọi cơ chế bảo vệ thì mới hữu ích — chỉ cần có code đọc được, AI lo phần còn lại.

Tầng nào còn làm chậm được automation

Phần sau của bài mô tả kiến trúc XopProtector. Lưu ý: đây là dự án của chính tác giả, nên các năng lực dưới đây là tuyên bố của tác giả, không phải kết quả kiểm chứng độc lập.

Lớp	Attacker phải làm thêm	Giới hạn bài viết tự thừa nhận
Đổi tên (ProGuard/R8)	Gần như không	AI suy luận được ngữ nghĩa
DEX packing	Dump DEX từ memory	Sau đó quay về luồng JADX bình thường
Code virtualization (PVM/VMP)	Hiểu interpreter, giải nghĩa tập lệnh ảo, dựng lại control flow	Không làm reverse engineering "bất khả thi về mặt toán học"
RASP	Vượt anti-debug, hook detection, integrity check	Không cơ chế đơn lẻ nào đảm bảo phát hiện mọi lần debug hay instrumentation

Lập luận đáng giữ lại, kể cả khi bỏ qua phần sản phẩm: virtualization "thay đổi bài toán reverse engineering chứ không chỉ làm code khó đọc hơn" — attacker phải phân tích máy ảo trước, rồi mới tới business logic.

Static cũng không còn là mặt trận duy nhất: bài mô tả vòng lặp AI phân tích hàm mục tiêu → sinh hook script Frida → chạy app → thu runtime data → sinh tiếp script.

Làm gì tuần này

• Dump DEX từ process app trên một máy đã root, đẩy qua JADX và tự đọc: logic nào hiện ra nguyên vẹn thì coi như đã công khai.
• Liệt kê 3–5 method thực sự đáng bảo vệ (ký request, license check, công thức tính giá) thay vì virtualize cả app — virtualization có giá về hiệu năng và khả năng debug.
• Thêm integrity và signature verification nếu chưa có; đây là phần rẻ nhất trong nhóm RASP.
• Giả định attacker bypass được hook detection: đưa quyết định nhạy cảm về server, nơi AI trên máy họ không đọc tới.