Kỹ thuật dịch ngược bằng AI: Trình dịch ngược có thể đưa ra thông tin sai lệch

Tác giả: Alexander Panasenko · Ngày 6/11/2026 · 20 phút đọc Kỹ thuật dịch ngược bằng AI: Nguy cơ sai lệch thông tin từ trình dịch ngược Một tên trường, 2.000 hàm tương đồng và một nhánh mã giả C sai lệch: Quy trình phân tích bằng XRef với mọi kết luận đều được kiểm chứng đối chiếu với tập lệnh máy. Trí tuệ mã nguồn và tác tử lập trình Mục lục bài viết · 14 phầnBản chất thực tế của ví dụ công khai Chuỗi khóa là điểm khởi đầu, không phải là một trường Địa chỉ của trường và giá trị lưu trữ tại đó là hai khái niệm khác nhau Phạm vi truy cập không phải là một khai báo cấu trúc Hai nghìn hàm có biểu hiện tương tự đáp án Ý nghĩa thực tế và giới hạn của việc xếp hạng Xác định nguồn gốc của con trỏ cơ sở Một hàm, nhiều vị trí gọi khác nhau, nhiều câu hỏi khác nhau Đánh giá ứng viên từ góc độ khác Một kết quả rỗng cần phải đi kèm lý do giải thích Tái lập thao tác nhanh: dữ liệu có thể lưu bộ nhớ đệm và dữ liệu không thể Quy trình công việc có thể chuyển giao cho tác tử Các bài học rút ra từ thực tế Nguồn tài liệu và phương pháp tái hiện Tóm tắt: Các tên trường được tuần tự hóa có thể dẫn tới vị trí chênh lệch (offset) của các trường đó. Vấn đề phức tạp hơn nằm ở việc xác định đoạn mã nào thực hiện thay đổi các trường này: trong một ví dụ công khai, 2.000 hàm giả lập ghi vào cùng các vị trí offset như hàm thực tế. Cả hàm thực tế và các hàm giả lập được hiển thị đều đạt mức điểm 40 tương đương nhau đối với các thao tác ghi vào những trường này. Hàm thực tế nhận thêm 10 điểm do có chung hàm gọi là main với bộ tuần tự hóa; trong khi các hàm giả lập hoàn toàn không có hàm gọi. Ứng viên này sau đó được đối chiếu kiểm tra với các lệnh máy và vị trí gọi hàm. Quy trình hướng dẫn sử dụng công cụ XRef 0.4.0 cùng một chương trình hợp ngữ và mã C tổng hợp; nội dung nhằm minh họa phương pháp luận và không phải là bài đánh giá hiệu năng (benchmark). Trước phiên bản 0.4.0, một truy vấn trường xref trả về kết quả not_found_under_limits: không có bố cục phù hợp. Phản hồi này cảnh báo quá trình phát hiện chưa hoàn tất trong phạm vi giới hạn phân tích, nhưng không cung cấp thông tin cho biết công cụ đã ghi nhận những khóa nào hoặc bị mất liên kết với các trường ở vị trí nào. Trường hợp này được ghi nhận tại sự cố (issue) số 76. Một danh sách rỗng dễ dẫn tới những bước xử lý sai lầm tiếp theo: mở rộng phạm vi tìm kiếm một cách ngẫu nhiên, kết luận cấu trúc không tồn tại, hoặc tiến hành phân tích toàn bộ tệp nhị phân bằng phương pháp thủ công. Yêu cầu đặt ra là phải giải quyết một bài toán khu biệt hơn: những quan sát nào có thể dẫn dắt từ một tên trường đến đoạn mã thực hiện sửa đổi trường đó? Diễn đạt theo cách thông dụng: khi một chương trình báo cáo "status": "failed"—hàm nào đã thay đổi trường dữ liệu đó? Đây là cách đặt vấn đề mang tính trực quan. Ví dụ được ghi lại dưới đây sử dụng các khóa c, m và e, được giữ nguyên trạng để mã nguồn, tập lệnh và kết quả đầu ra có thể được đối chiếu đồng thời. Khi một tác tử AI thực hiện công việc này, hệ thống đòi hỏi chuỗi kiểm chứng tương tự như quy trình của con người. Trong mô hình này, XRef đóng vai trò là bộ phân tích gốc: tác tử đặt câu hỏi thông qua giao diện dòng lệnh (CLI) hoặc giao thức MCP và xử lý dữ liệu trả về. Tìm kiếm một hàm khả thi, hiểu rõ vai trò của hàm đó và đọc hiểu chính xác mã giả C là ba bước tách biệt; trong đó bước thứ ba chính là nguồn gốc của tiêu đề bài viết: phần sau của tài liệu sẽ dẫn chứng trường hợp tái hiện từ phiên bản XRef cũ, cho thấy đoạn mã giả C trả về giá trị 99 nếu đọc theo nghĩa đen, trong khi mã máy thực tế tính toán ra kết quả là 4. Bản ghi dưới đây bao gồm các lệnh CLI và kết quả thu được tương ứng; phần kết sẽ chuyển hóa quy trình này thành danh mục kiểm tra để tác tử có thể áp dụng. Đối với một tệp thực thi không có biểu tượng (symbol), đây là một vấn đề khó xử lý một cách đáng ngạc nhiên. Người phân tích có thể biết tên của một trường dữ liệu do tên này xuất hiện trong đầu ra được tuần tự hóa (serialized), nhưng hầu như không biết gì về cách bố trí của trường đó trong bộ nhớ. Tên kiểu dữ liệu gốc không còn. Tên hàm cũng biến mất. Một độ dịch chuyển (displacement) nhỏ đơn lẻ có thể xuất hiện trong hàng nghìn chỉ lệnh hoàn toàn không liên quan. Một bản dịch ngược (decompilation) có vẻ hợp lý có thể khiến phỏng đoán ban đầu trở nên thuyết phục rất lâu trước khi các dữ kiện thực tế chứng minh điều đó. Trong quá trình phát triển XRef, vấn đề này dần được xác định rõ ràng hơn: trước hết là tìm mã nguồn từ tên của một trường đã được tuần tự hóa, sau đó khớp một nhóm khóa liền kề và tìm các hàm ghi vào những trường đó. Các khóa ngắn đã bộc lộ khoảng trống tiếp theo: ngay cả một kết quả âm tính cũng cần giải thích những nội dung mà công cụ thực sự đã kiểm tra. Tiến trình này được phản ánh qua các báo cáo sự cố (issue) số 58, 74 và 76. Lệnh xref field liên kết việc sử dụng khóa với các độ lệch (offset) tương đối so với con trỏ đầu vào, sau đó tìm kiếm và xếp hạng các hàm ghi tiềm năng. Tham chiếu chuỗi, độ lệch và hàm phù hợp là những manh mối độc lập. Để chuyển đổi các manh mối này thành câu trả lời, cần theo dõi toàn bộ chuỗi liên kết và lưu giữ các chỉ lệnh làm căn cứ cho từng kết luận. Bài viết này lần lượt giải quyết một câu hỏi cụ thể: đoạn mã nào làm thay đổi các giá trị gắn với những khóa này? Đồng thời, bài viết chỉ ra những manh mối sai lệch khiến vấn đề không thể giải quyết đơn thuần bằng việc tìm kiếm các thao tác ghi vào bộ nhớ. Bản chất của ví dụ công khai Nhằm theo dõi chuỗi phân tích này đến cùng, bài viết sử dụng một chương trình thử nghiệm nhỏ đã được công bố với kết quả định trước, giúp mọi kết luận đều có thể đối chiếu với mã nguồn và các chỉ lệnh máy. Các tác vụ thực tế đã định hình chức năng của công cụ; trong khi phần hướng dẫn thực hành được tiến hành trên ví dụ mở này. Bản ghi hiện có sử dụng tệp thực thi XRef 0.4.0 dành cho Linux đã được phát hành, lập ngày 5/11/2026; bài viết tái sử dụng các lệnh và kết quả đầu ra này thay vì thực hiện một lượt chạy mới. Bản sửa đổi (revision) chính xác của bản dựng và mã băm tệp được lưu trong hồ sơ môi trường của bản ghi (được đính kèm liên kết ở cuối bài). Chương trình mục tiêu được tạo bằng ngôn ngữ C và hợp ngữ (assembly). Phần mã nguồn C quan trọng được trình bày ngắn gọn như sau: struct record { uint64_t c, m, e; }; void serializer(struct record *p) { emit("c", 1, &p->c); emit("m", 1, &p->m); emit("e", 1, &p->e); } void writer(struct record *p, uint64_t value) { p->m += value; p->e ^= value; } Đây là đoạn trích từ mã nguồn hoàn chỉnh được sinh ra. Các thuộc tính của hàm và cờ biên dịch bảo đảm giữ nguyên mô hình gọi hàm phục vụ quá trình phân tích. Hàm main gọi hàm writer trước, sau đó gọi serializer. Hàm emit chỉ thực hiện thao tác đưa khóa, độ dài và giá trị tại địa chỉ đã cho vào một biến volatile. Thao tác này tái lập mô hình cấp máy “khóa + địa chỉ giá trị → hàm dùng chung” mà không cần bộ mã hóa JSON thực tế hay thư viện Serde. Đây là ví dụ tổng hợp bằng ngôn ngữ C và assembly phục vụ việc nghiên cứu cơ chế. Việc đánh giá độ chính xác trên các ứng dụng Rust thực tế đòi hỏi một quy trình kiểm nghiệm riêng biệt. Phần hợp ngữ bổ sung 2.000 hàm nghi binh. Mỗi hàm này ghi