Kỹ thuật đảo ngược có cần một mô hình lớn hơn không?

Mô hình mạnh hơn đã thay đổi điều gì?

Kể từ tháng 8 năm 2026, tôi đã khám phá mức độ kỹ thuật đảo ngược mà một tác nhân có thể thực hiện khi có quyền truy cập vào một chương trình và cách kiểm tra công việc của nó. Phần lớn kinh nghiệm của tôi đến từ việc xây dựng lại trò chơi, đặc biệt là Touhou. Khi tôi thay đổi mô hình, các kho lưu trữ đã lưu giữ một bản ghi về những gì mỗi phiên đã khôi phục được.

Phần lớn công việc hướng tới tái dựng chính xác: biên dịch mã nguồn đang được duy trì bằng chuỗi công cụ lịch sử có phiên bản cố định, rồi kiểm tra xem nó có tái tạo hàm đích hay không. Khi mô hình sau giải quyết được điểm mà công việc trước bị mắc kẹt, thay đổi trong mã nguồn cho thấy điều gì đã giúp tiến triển.

Các biến tạm thời cần có thời gian tồn tại chồng chéo

Phần lớn logic của hàm tấn công TH09 đã được xây dựng lại, nhưng trình biên dịch vẫn lưu trữ các kết quả tạm thời khác với kết quả ban đầu. Vấn đề còn lại là những kết quả đó cần tồn tại trong bao lâu và khi nào bộ nhớ của chúng có thể được sử dụng lại.

Bản ghi phiên GPT-6-Sol đã báo cáo sự không khớp này sau khi kiểm tra một số cách sắp xếp mã nguồn thông thường. Khi GPT-6.1-Sol kiểm tra lại vấn đề, nó đã đề xuất một giả thuyết hữu ích về thời gian tồn tại của các biến tạm thời này.

Hàm này tạo ra các kết quả tạm thời và sao chép chúng vào các vị trí hoạt ảnh. Trong C++, kết quả tạm thời vẫn tồn tại cho đến khi biểu thức sử dụng nó kết thúc. Việc nhóm các hoạt động thực tế thành một biểu thức giúp giữ cho các kết quả đó tồn tại cùng nhau, do đó trình biên dịch không thể sử dụng lại cùng một bộ lưu trữ cho tất cả chúng nữa.

Một kết quả vẫn được chia sẻ bộ nhớ với giá trị được sử dụng sau này để kiểm tra xung đột. Việc đưa ra giá trị đó trong thời gian tồn tại của chính nó đã giải quyết được sự chồng chéo còn lại. Sau một số thử nghiệm có mục tiêu, việc biên dịch lại rõ ràng từ nguồn đã xác nhận rằng hàm đầy đủ khớp với.

Tôi quan tâm đến việc khám phá và thử nghiệm hỗ trợ lẫn nhau như thế nào. Giả thuyết về thời gian tồn tại của đối tượng tạm thời đã mang lại cho tác nhân AI một hướng đi mới. Phản hồi của trình biên dịch đã giúp nó tinh chỉnh giả thuyết đó thành một cách sắp xếp mã nguồn phù hợp.

Biểu đồ luồng điều khiển khác

Hàm TH09 thứ hai cho biết tại sao hướng đi mới đó lại quan trọng. Ở đây, trở ngại là làm thế nào một số chi nhánh chia sẻ công việc cuối cùng của họ. Công việc trước đó của GPT-6.1-Sol có các phần của hàm khớp với nhau, nhưng các nhánh vẫn được nối với nhau khác với ban đầu.

GPT-6-Astra đã thay đổi biểu đồ luồng điều khiển xung quanh. Các đường dẫn chính hiện đã dẫn đến bản cập nhật cuối cùng được chia sẻ và quay trở lại. Trong cấu trúc nguồn đó, trình biên dịch kết hợp các nhánh giống như bản gốc. Chức năng hoàn chỉnh đã khớp và một cuộc kiểm tra xây dựng lại riêng biệt đã xác nhận điều đó.

Việc thay đổi cách biểu diễn đã mở ra một không gian tìm kiếm hiệu quả hơn. Cả hai trường hợp đều cho tôi lý do để xem xét nghiêm túc khả năng của mô hình chung: một tác nhân có thể tiếp tục thử các biến thể cục bộ trong một thời gian dài trước khi tìm ra cách tốt hơn để thể hiện công việc xung quanh.

Đồng thời, các phiên sau bắt đầu với nguồn trước đó và ghi lại lỗi. Công việc tích lũy đó là một phần lợi thế của họ. Lịch sử cho phép chúng ta kiểm tra những khám phá và kiểm tra chúng; một so sánh có kiểm soát sẽ giúp tách biệt tác động của mô hình khỏi trải nghiệm mà nó kế thừa.

Đây là điều làm cho câu hỏi trở nên thú vị đối với tôi. Một số tiến bộ đến từ việc tìm kiếm một đại diện mới. Phần lớn công việc còn lại liên quan đến việc kiểm tra các cách sắp xếp mã nguồn khác nhau dựa trên một trình biên dịch quen thuộc. Bao nhiêu trong số này đòi hỏi khả năng suy luận rộng? Một mô hình có thể học được bao nhiêu khi làm việc liên tục với trình biên dịch và mã đó?

Tại sao một mô hình AI chuyên biệt có thể hoạt động tốt?

Touhou cho chúng ta lý do cụ thể để mong đợi trải nghiệm đó sẽ hữu ích. Phần lớn mã trò chơi đều đến từ cùng một tác giả, ZUN, vì vậy những thói quen lặp đi lặp lại là một giả định khởi đầu hợp lý. Các kho lưu trữ hỗ trợ điều đó bằng các ví dụ hữu ích: các vòng lặp liên quan và cách sắp xếp trợ giúp đã cung cấp các giả thuyết cho các trò chơi.

Các mẫu nguồn đó trở nên cụ thể hơn khi chúng tôi đưa trình biên dịch vào. Trong một phiên bản và tập hợp các tùy chọn cụ thể, những thay đổi nhỏ về nguồn có thể tạo ra những khác biệt lặp lại trong mã máy. Một số trong những khác biệt đó mơ hồ một cách đáng ngạc nhiên.

Ví dụ: trong TH095, ngay cả tên biến cục bộ cũng có thể ảnh hưởng đến vị trí VC7.1 lưu trữ nó. Việc di chuyển khai báo của nó không giải quyết được bố cục lưu trữ. Tuy nhiên, hàm nền trước đó đã tiết lộ kiểu đặt tên ảnh hưởng đến sự lựa chọn của trình biên dịch. Điều đó gợi ý một giả thuyết hứa hẹn hơn cho việc tái tạo Supervisor::LoadDat.

Việc sử dụng lại mẫu đó cho biến kích thước tệp sẽ tạo ra bố cục cần thiết mà không cần thêm bộ nhớ. Các chức năng đầy đủ sau đó phù hợp.

Đây là một chi tiết rất cụ thể mà một mô hình AI đa năng có thể không biết khi lần đầu gặp sự cố. Một mô hình chuyên dụng cho trình biên dịch này có thể xem nhiều trường hợp như vậy và tìm hiểu xem biến thể mã nguồn nào đáng để thử nghiệm trước tiên.

Cơ hội đặc biệt rõ ràng trong các bài toán so khớp cuối cùng khi chúng ta đã hiểu rõ hành vi. Sau đó, chúng tôi sẽ hỏi trình biên dịch này sẽ chuyển sự sắp xếp mã nguồn thông thường nào thành các lệnh máy được quan sát. Sự chuyên môn hóa có thể giúp mô hình đề xuất các hình thức đó hiệu quả hơn, trong khi mục tiêu vẫn xác định giả thuyết nào tồn tại.

Các mẫu hữu ích phải đi kèm bối cảnh áp dụng. TH08 dùng phiên bản Visual C++ cũ hơn TH095 và TH09. TH04 dùng một trình biên dịch khác thuộc thời DOS. Việc tái dựng mã điều khiển người chơi cần những giả thuyết khác về cách viết mã và cách liên kết thành tệp thực thi. Cùng tác giả là một giả định ban đầu; từng mục tiêu cho biết giả định đó có phù hợp không. Mô hình chuyên biệt cần học cách phân biệt các bối cảnh này.

Kinh nghiệm này nên được lưu trữ ở đâu?

Trước khi quyết định dạy những mẫu đó thông qua đào tạo mô hình, tôi sẽ xem xét kiến thức mà chúng tôi đã lưu giữ trong kho. Trong bài luận trước, tôi đã viết về việc nó trở thành bộ nhớ làm việc của dự án. Bộ nhớ đó bao gồm các bài học về trình biên dịch, cùng với nguồn và các thử nghiệm thất bại khiến chúng trở nên hữu ích.

Bằng cách truy xuất bản ghi đó, nhân viên hỗ trợ có thể bắt đầu với kết quả đã biết và kiểm tra cách chúng tôi đạt được kết quả đó. Nó cũng có thể tránh được những lựa chọn thay thế đã thất bại trong cùng bối cảnh. Điểm bắt đầu được cải thiện mà không thay đổi các tham số đã huấn luyện của mô hình.

Trong khi xây dựng lại chức năng tạo kẻ thù của TH09, phiên GPT-6-Luna-max đã lấy một giả thuyết từ mã nguồn TH08 có liên quan. Mã trước đó đã đề xuất cách tổ chức vòng lặp và xử lý các lỗi bên trong nó. Bằng chứng riêng của TH09 đã cung cấp chi tiết cụ thể về trò chơi. Việc xây dựng lại từ nguồn đã xác nhận rằng toàn bộ hàm khớp với bản gốc.

"Mô hình không biết lỗi của trình biên dịch" và "mô hình không thể sử dụng nó" là các vấn đề khác nhau. Việc truy xuất có thể giải quyết được vấn đề đầu tiên, nhưng việc biến thực tế đó thành một mã ứng viên hữu ích vẫn cần nhiều công sức. Và nếu mã nguồn mã ứng viên không thành công, mô hình phải quyết định kết quả có ý nghĩa gì cho lần thử tiếp theo. Biết mẫu có liên quan chỉ là bước khởi đầu của quá trình đó.

Vì lý do đó, tôi sẽ đưa vào một mô hình AI có mục đích chung nhỏ hơn với khả năng truy xuất tốt trong mọi so sánh. Cung cấp cho nó cùng một thư viện kinh nghiệm sẽ giúp chúng tôi xác định nội dung đào tạo bổ sung: tạo ứng viên tốt hơn, đưa ra quyết định tốt hơn sau khi phản hồi hoặc cả hai.

Học thí nghiệm hữu ích tiếp theo

Những quyết định sau khi được phản hồi là điều tôi muốn nghiên cứu nhất. Trong tái cấu trúc tác nhân, mô hình đề xuất một lời giải thích và kiểm tra nó dựa trên chương trình. Ngay cả khi mã nguồn ứng viên không thành công, kết quả có thể thu hẹp các khả năng còn lại và đề xuất thử nghiệm tiếp theo hữu ích hơn.

Hãy xem xét lại ví dụ về kết quả tạm thời. Nguồn cuối cùng của nó cho thấy sự sắp xếp đã có hiệu quả nhưng đường dẫn đến nguồn đó chứa nhiều thông tin hơn. Mỗi thử nghiệm sau đây đã giúp xác định những gì vẫn cần thay đổi.

Các thử nghiệm được chọn từ quá trình tái cấu trúc chức năng tấn công ở trên, được nhóm theo những gì chúng đã dạy chúng ta.

Một bản ghi huấn luyện lưu giữ trình tự này có thể dạy nhiều hơn chỉ riêng nguồn cuối cùng. Nó kết nối từng thay đổi được đề xuất với kết quả được quan sát và quyết định tiếp theo. Việc giữ lại các biến thể không hiệu quả cũng rất quan trọng: chúng cho tác nhân sau này biết những giả thuyết nào đã được kiểm tra trong bối cảnh đó.

Tôi muốn mô hình học cách sử dụng phản hồi. Kết quả trung lập là lý do để xem xét lại biến thể; sự không phù hợp đã thay đổi có thể chỉ ra một nguyên nhân khác. Khi các chỉnh sửa cục bộ không còn mang tính thông tin, nhân viên sẽ có thể xem lại phần trình bày nguồn hoặc kiểm tra lại bằng chứng.

Học cách đưa ra những lựa chọn đó đòi hỏi sự tự chủ. Đôi khi, bước tiếp theo hữu ích là kiểm tra người gọi khác thay vì biên dịch một bản chỉnh sửa khác. Một chuỗi các lần viết lại bắt buộc một cách cứng nhắc sẽ loại bỏ lựa chọn đó, cùng với một phần hành vi mà chúng ta muốn mô hình học.

Tại sao kỹ thuật đảo ngược lại thú vị cho việc học tăng cường

Tái dựng trong phạm vi xác định là môi trường thực tế để nghiên cứu các lựa chọn này. Khi phiên bản của mục tiêu và trình biên dịch được cố định, nhiều thử nghiệm mã nguồn cho phản hồi nhanh và có thể lặp lại. Tác nhân có thể biên dịch mã ứng viên, xem khác biệt rồi chọn bước tiếp theo.

Học tăng cường có thể rèn luyện quá trình ra quyết định đó thông qua phản hồi mà nó nhận được. Một mã ứng viên được chấp nhận bởi một cuộc kiểm tra xác định sẽ cho chúng ta một kết quả cụ thể, trong khi trình tự các lần thử cho phép chúng ta quan sát xem cần bao nhiêu công sức để đạt được kết quả đó.

Đã có nghiên cứu hỗ trợ hướng này. LLM4Decompile nghiên cứu các mô hình chuyên dùng cho việc dịch ngược. AutoDecompiler đào tạo sàng lọc nhiều lượt bằng cách sử dụng phản hồi của trình biên dịch và thực thi. Nghiên cứu của họ tập trung vào phục hồi chức năng. Đối với công việc này, tôi sẽ sử dụng chúng làm điểm khởi đầu cho nhiệm vụ liên quan là tìm nguồn phù hợp với đầu ra của trình biên dịch lịch sử.

Tuy nhiên, để đạt được nhiệm vụ được xác định rõ ràng như vậy, trước tiên chúng ta có thể cần thiết lập tài nguyên nào mà hàm sở hữu hoặc nghĩ ra cách mới để quan sát hành vi của chương trình khi chạy. Ví dụ: trong TH08, sự khác biệt về va chạm dẫn đến cách chương trình ban đầu xử lý các phép tính dấu phẩy động. Trước khi tác nhân có thể kiểm tra một sự điều chỉnh hữu ích, nó phải tìm ra những gì cần đo lường.

Điều này gợi ý một vai trò khác của một mô hình có khả năng rộng rãi: giúp làm cho vấn đề có thể được kiểm tra ngay từ đầu. Khi kiểm tra đó tồn tại, chúng tôi có thể điều tra xem chính sách tìm kiếm đã học có thể đi được bao xa.

Khi công cụ xác minh sai

Khi dùng một phép kiểm tra để huấn luyện, phạm vi kiểm tra cũng trở thành một phần của môi trường học. Tôi gọi chuẩn tham chiếu hoặc công cụ kiểm tra đó là oracle. Ngay cả câu trả lời lặp lại được cũng cần được hiểu theo những gì nó thực sự xác minh.

TH08 cho thấy vấn đề có thể ẩn ngoài phạm vi kiểm tra. Một số hàm tái dựng dùng hằng số dấu phẩy động sai nhưng vẫn vượt qua so sánh chính xác. Bộ so sánh điều chỉnh địa chỉ tái định vị trước khi kiểm tra lệnh máy, nhưng chỉ kiểm tra giá trị tại các địa chỉ đó nếu chúng đã được ghi nhận rõ ràng để xác minh. Những tham chiếu hằng số khác có thể vượt qua mà không được kiểm tra giá trị.

Để giải quyết khoảng trống này, kiểm tra rộng hơn đã tìm thấy các hằng số không chính xác trong các hàm đã vượt qua quá trình xác minh. Trong một phép tính, mã nguồn được xây dựng lại đã thêm 1.0f, trong khi mã nguồn ban đầu được thêm 32.0f.

Mô hình được khen thưởng bằng kiểm tra xác minh cũ có thể học cách tạo ra bản dựng lại không chính xác. Chúng tôi không đào tạo mô hình RL bằng trình kiểm tra đó. Sự thất bại mà chúng tôi quan sát thấy nằm ở chính việc kiểm tra. Nhưng nếu chúng ta sử dụng nó như một phần thưởng thì điểm mù đó sẽ trở thành một phần của môi trường học tập.

Một bài kiểm tra chức năng có thể có điểm mù tương tự. Nghiên cứu sử dụng tính năng làm mờ vi phân trên bộ giải mã LLM đã tìm thấy những khác biệt về hành vi bên ngoài các thử nghiệm được cung cấp. Do đó, chúng ta cần hiểu một bài kiểm tra đạt theo các trường hợp mà nó thực hiện. Tương tự, một lệnh khớp phải được hiểu theo byte và dữ liệu mà nó xác minh.

Trước khi sử dụng một trong hai loại kiểm tra xác minh làm phần thưởng, tôi sẽ kiểm tra nó với kết quả cố tình sai. Tôi cũng sẽ tách biệt sự chấp nhận cuối cùng với mã nguồn mà tác nhân AI có thể chỉnh sửa. Mô hình phải vượt qua quá trình xác minh bằng cách xây dựng lại chương trình một cách chính xác. Mặt khác, chỉ cần sao chép một mảng byte từ mục tiêu có thể đánh lừa một hệ thống tính điểm ngây thơ mà không khôi phục được mã nguồn hữu ích.

Cải thiện mô hình học và cải thiện công cụ xác minh là hai phần của cùng một vấn đề nghiên cứu. Mô hình càng giỏi tối ưu phản hồi được cung cấp, chúng ta càng cần hiểu chính phản hồi đó.

Một so sánh đáng chạy

Với những bước kiểm tra đó, tôi sẽ bắt đầu so sánh trên nhóm nhiệm vụ VC7.1 cố định. Đầu tiên, tôi sẽ thiết lập các đường cơ sở cho một mô hình AI có mục đích chung mạnh mẽ và một mô hình nhỏ hơn. Việc bổ sung kiến ​​thức về kho lưu trữ vào mô hình nhỏ hơn sẽ cho thấy những thay đổi trong quá trình truy xuất. Từ đó, chuyên môn hóa được giám sát và phiên bản được đào tạo RL sẽ cho phép chúng tôi kiểm tra nội dung đào tạo bổ sung.

Để làm cho những so sánh đó trở nên hữu ích, mỗi mô hình sẽ nhận được các bằng chứng và công cụ mục tiêu giống nhau. Đối với các so sánh dành riêng cho đào tạo, tôi cũng sẽ giữ nguyên mô hình cơ sở và kiến ​​thức có sẵn. Các thử nghiệm lặp đi lặp lại sẽ giúp phân biệt một chiến lược tìm kiếm đáng tin cậy với một giải pháp ứng viên tình cờ thành công.

Sau đó, tôi sẽ tách hai điều kiện bắt đầu: xây dựng lại một hàm từ các lệnh máy của nó và đóng một số khác biệt cuối cùng trong nguồn được duy trì. Một mô hình AI chuyên dụng có thể thực hiện xuất sắc nhiệm vụ thứ hai trong khi một mô hình AI có mục đích chung thực hiện phần lớn công việc cần thiết để đạt được nhiệm vụ đó. Việc đo lường chúng một cách riêng biệt sẽ tiết lộ sự phân chia công việc đó.

Cả hai nhiệm vụ đều cần loại trừ các mẫu thử nghiệm khỏi quá trình đào tạo và truy xuất. Trò chơi Touhou liên quan chia sẻ mã công cụ. Việc loại trừ một trò chơi khỏi quá trình huấn luyện vẫn có thể để lại các chức năng gần như giống hệt nhau trong tập huấn luyện. Thay vào đó, tôi sẽ loại trừ toàn bộ các nhóm mã nguồn có liên quan và loại bỏ các câu trả lời đã được xác minh của chúng khỏi cả dữ liệu huấn luyện và thư viện truy xuất.

Kết quả cần đo là các lần khớp hoàn chỉnh, được xác minh độc lập. Giới hạn số mã ứng viên hoặc số lần biên dịch bằng nhau giúp so sánh chất lượng tìm kiếm. Đo tổng thời gian và chi phí, kể cả biên dịch, cho biết chất lượng đó có tạo ra quy trình hiệu quả không. Chi phí huấn luyện cần tính riêng.

Cả hai phép đo đều quan trọng. Một đề xuất rẻ tiền có thể dẫn đến một quy trình làm việc tốn kém nếu nó tạo ra nhiều lần biên dịch không cung cấp thông tin hữu ích. Ngược lại, một mô hình chậm hơn có thể tiết kiệm hơn nếu nó tìm thấy một thử nghiệm hữu ích sớm hơn. Việc so sánh nên bao gồm những chi phí này.

Việc đếm các kết quả được chấp nhận cũng giúp duy trì tiến độ trung gian. Một TH09 mã ứng viên lưu lại phát lại có vẻ đầy hứa hẹn vì hàm được biên dịch có kích thước như mong đợi nhưng so sánh đầy đủ vẫn tìm thấy những khác biệt đáng kể. Những thay đổi trong cách trình biên dịch sắp xếp các lệnh máy cũng có thể khiến mã ứng viên có vẻ gần hơn mà không giải quyết được vấn đề cơ bản. Chẩn đoán như vậy có thể hướng dẫn thử nghiệm tiếp theo, nhưng tôi sẽ xác thực bất kỳ phần thưởng nào cho việc "tiến gần hơn" so với kiểm tra chấp nhận hoàn toàn.

Tôi sẽ quan tâm đến mô hình trên các kết quả này. Nếu một mô hình AI chuyên dụng hoạt động tốt trong dòng trình biên dịch quen thuộc, liệu lợi thế đó có tồn tại được khi thay đổi chuỗi công cụ không? Và một khi cả hai mô hình AI đều có khả năng truy xuất tốt thì việc đào tạo vẫn bổ sung thêm bao nhiêu? Câu trả lời sẽ giúp chúng ta quyết định xem mỗi loại mô hình sẽ hữu ích nhất ở đâu.

Điều này gợi ý loại tác nhân AI nào?

Nếu các mô hình tỏ ra hữu ích ở các giai đoạn khác nhau, thì sự sắp xếp hữu ích có thể là một tác nhân rộng rãi có quyền truy cập vào một mô hình AI chuyên dụng. Khi một nhiệm vụ trở thành một công cụ tìm kiếm trình biên dịch quen thuộc, nó có thể yêu cầu mô hình AI chuyên biệt dành cho ứng viên. Nếu kết quả không còn có ý nghĩa nữa, tác nhân rộng hơn có thể quay lại bằng chứng mục tiêu hoặc tự điều tra phép đo.

Trong sự sắp xếp đó, sự chuyên môn hóa trở thành một công cụ mà đặc vụ có thể lựa chọn khi cuộc điều tra phát triển. Người đại diện có quyền tự do thay đổi hướng đi để có thể đạt được những đột phá trước đó.

Điều này diễn ra một cách tự nhiên từ sự chuyển dịch công nghiệp mà tôi đã mô tả trong bài viết trước. Việc có thể chạy nhiều thử nghiệm hơn sẽ thay đổi cách chúng ta tổ chức công việc. Nó cũng cho chúng ta lý do để hỏi những quyết định nào cần được đánh giá rộng rãi và quyết định nào được cải thiện thông qua kinh nghiệm lặp đi lặp lại với một nghề cụ thể.

Hiện tại, mô hình tổng quát mạnh nhất đã có chỗ đứng trong quy trình của tôi vì giải quyết được những vấn đề trước đó còn bỏ ngỏ. Những thành công này khiến tôi muốn xem kỹ quá trình: bao nhiêu phần phụ thuộc vào năng lực rộng của mô hình, và bao nhiêu phần có thể giao cho một mô hình được huấn luyện riêng cho kiểu tái dựng này?

Các kho lưu trữ cung cấp cho chúng tôi một cách để kiểm tra câu hỏi. Tôi muốn sử dụng hồ sơ đó để xây dựng sự so sánh và xem những gì chúng tôi học được.