Czy inżynieria odwrotna potrzebuje większego modelu?

Co zmieniły silniejsze modele

Od sierpnia 2026 roku badam, ile inżynierii wstecznej może dokonać agent mając dostęp do programu i możliwość sprawdzenia jego działania. Większość mojego doświadczenia pochodzi z rekonstrukcji gier, szczególnie Touhou. Ponieważ zmieniałem modele, repozytoria prowadziły rejestr tego, co udało się odzyskać w każdej sesji.

Duża część tych prac ma na celu dokładną rekonstrukcję: kompilujemy utrzymywane źródło w ramach historycznego zestawu narzędzi ze stałymi wersjami i sprawdzamy, czy odtwarza ono funkcję docelową. Kiedy późniejszy model odniesie sukces tam, gdzie wcześniejsze prace utknęły w martwym punkcie, zmiany źródłowe pokazują, co umożliwiło ten postęp.

Zmienne tymczasowe wymagały nakładających się okresów istnienia

Duża część logiki funkcji ataku TH09 została już zrekonstruowana, ale kompilator nadal przechowywał tymczasowe wyniki inaczej niż oryginał. Pozostałym problemem było to, jak długo wyniki były potrzebne do zachowania żywotności i kiedy można było ponownie wykorzystać ich pamięć.

GPT-6-Sol rekord sesji zgłosił tę niezgodność po przetestowaniu kilku zwykłych ustaleń kodu źródłowego. Kiedy GPT-6.1-Sol ponownie zbadał problem, zaproponował użyteczną hipotezę dotyczącą czasu życia tych zmiennych tymczasowych.

Funkcja wygenerowała tymczasowe wyniki i skopiowała je do pozycji animacji. W C++ tymczasowy wynik pozostaje aktywny aż do zakończenia wyrażenia, które go używa. Grupowanie rzeczywistych operacji w jedno wyrażenie utrzymywało te wyniki razem, więc kompilator nie mógł już ponownie używać tej samej pamięci dla nich wszystkich.

Jeden wynik nadal współdzielił pamięć o wartości używanej później do sprawdzania kolizji. Nadanie tej wartości własnego czasu życia rozwiązało pozostałe nakładanie się. Po kilku ukierunkowanych eksperymentach czysta rekompilacja ze źródła potwierdziła, że ​​pełna funkcja jest zgodna.

Ciekawi mnie, jak odkrycie i testy wzajemnie się wspierały. Hipoteza dotycząca czasu życia obiektów tymczasowych nadała agentowi AI nowy kierunek. Informacje zwrotne od kompilatora pomogły mu udoskonalić tę hipotezę w celu uzyskania pasującego układu kodu źródłowego.

Inny wykres przepływu sterowania

Druga funkcja TH09 pokazuje, dlaczego ten nowy kierunek może mieć znaczenie. Tutaj przeszkodą był sposób, w jaki kilka oddziałów podzieliło się swoją końcową pracą. We wcześniejszej pracy GPT-6.1-Sol części funkcji pasowały, ale gałęzie nadal łączyły się inaczej niż w oryginale.

GPT-6-Astra zmienił otaczający wykres przepływu sterowania. Główne ścieżki prowadziły teraz do wspólnej ostatecznej aktualizacji i powrotu. W tej strukturze źródłowej kompilator połączył gałęzie w taki sam sposób jak oryginał. Pełna funkcja została zgodna i potwierdziła to osobna kontrola odbudowy.

Zmiana reprezentacji otworzyła bardziej produktywną przestrzeń poszukiwań. Obydwa przypadki dają mi powód, aby poważnie traktować możliwości modelu ogólnego: agent może przez długi czas testować lokalne odmiany, zanim znajdzie lepszy sposób na wyrażenie otaczającej pracy.

Jednocześnie późniejsze sesje rozpoczynały się od wcześniejszych źródeł i odnotowanych awarii. Ta skumulowana praca była częścią ich przewagi. Historia pozwala nam na wgląd w odkrycia i ich sprawdzenie; kontrolowane porównanie pomogłoby oddzielić wpływ modelu od odziedziczonego przez niego doświadczenia.

Właśnie dlatego to pytanie jest dla mnie interesujące. Pewien postęp nastąpił po znalezieniu nowej reprezentacji. Większość pozostałej pracy polegała na testowaniu różnych rozwiązań kodu źródłowego w porównaniu ze znanym kompilatorem. Ile z tego wymaga szerokiej zdolności rozumowania? Ile model może się nauczyć, wielokrotnie pracując z tym kompilatorem i kodem?

Dlaczego wyspecjalizowany model sztucznej inteligencji może się sprawdzić?

Touhou daje nam konkretny powód, aby oczekiwać, że to doświadczenie pomoże. Duża część kodu gry pochodzi od tego samego autora, ZUN, więc powtarzające się nawyki są rozsądnym założeniem wyjściowym. Repozytoria potwierdzają to przydatnymi przykładami: powiązane pętle i układy pomocnicze dostarczyły hipotez w różnych grach.

Te wzorce źródłowe stają się bardziej szczegółowe, gdy dołączymy kompilator. W przypadku określonej wersji i zestawu opcji niewielkie zmiany w źródle mogą powodować powtarzalne różnice w kodzie maszynowym. Niektóre z tych różnic są zaskakująco niejasne.

Na przykład w TH095 nawet nazwa zmiennej lokalnej może mieć wpływ na miejsce przechowywania jej przez VC7.1. Przeniesienie deklaracji nie rozwiązało układu przechowywania. Jednak wcześniejsza funkcja tła ujawniła wzorzec nazewnictwa, który wpłynął na wybór kompilatora. Sugerowało to bardziej obiecującą hipotezę dotyczącą rekonstrukcji Supervisor::LoadDat.

Ponowne użycie tego wzorca dla zmiennej rozmiaru pliku pozwoliło uzyskać wymagany układ bez dodawania pamięci. Pełna funkcja została wówczas dopasowana.

Jest to bardzo specyficzny szczegół, o którym model sztucznej inteligencji ogólnego przeznaczenia może nie wiedzieć, kiedy po raz pierwszy napotka problem. Model wyspecjalizowany dla tego kompilatora mógłby zobaczyć wiele takich przypadków i dowiedzieć się, które odmiany kodu źródłowego warto przetestować w pierwszej kolejności.

Możliwość jest szczególnie wyraźna w przypadku końcowych problemów z dopasowywaniem, w których już rozumiemy zachowanie. Następnie pytamy, jaki zwykły układ kodu źródłowego ten kompilator przekształca w obserwowane instrukcje. Specjalizacja może pomóc modelowi w skuteczniejszym proponowaniu tych form, podczas gdy cel nadal określa, które hipotezy przetrwają.

Przydatne wzorce muszą zachować swój kontekst. TH08 używa wcześniejszej wersji Visual C++ niż TH095 i TH09. TH04 używa innego kompilatora z ery DOS-u. Do jego rekonstrukcji kodu gracza potrzebne były różne hipotezy dotyczące wzorców kodu źródłowego i sposobu łączenia skompilowanego kodu z plikiem wykonywalnym. Posiadanie tego samego autora daje nam wstępne oczekiwania, ale każdy cel mówi nam, czy ma to zastosowanie. Aby rozróżnić te konteksty, potrzebny byłby wyspecjalizowany model.

Gdzie należy przechowywać to doświadczenie?

Zanim zdecydowałbym się uczyć tych wzorców poprzez szkolenie modelowe, sprawdziłbym wiedzę, którą już przechowujemy w repozytorium. W poprzednim eseju pisałem, że stanie się ona pamięcią roboczą projektu. Pamięć ta obejmuje lekcje kompilatora wraz ze źródłem i nieudanymi eksperymentami, które uczyniły je użytecznymi.

Pobierając ten rekord, agent może zacząć od znanego wyniku i sprawdzić, w jaki sposób do niego dotarliśmy. Można również uniknąć alternatyw, które już zawiodły w tym samym kontekście. Punkt początkowy poprawia się bez zmiany przeszkolonych parametrów modelu.

Podczas rekonstrukcji funkcji TH09 służącej do tworzenia wrogów, podczas GPT-6-Luna-max sesji przyjęto hipotezę z powiązanego kodu źródłowego TH08. Ten wcześniejszy kod sugerował, jak zorganizować pętlę i poradzić sobie z błędami w niej występującymi. Zeznania TH09 dostarczyły szczegółów specyficznych dla gry. Przebudowa ze źródła potwierdziła, że ​​cała funkcja jest zgodna.

„Model nie wiedział, że dziwactwo kompilatora” i „model nie mógł go użyć” to różne problemy. Pobranie może rozwiązać pierwszy, ale przekształcenie tego faktu w użyteczną kandydaturę nadal wymaga pracy. A jeśli potencjalny kod źródłowy zawiedzie, model musi zdecydować, co oznacza wynik przy następnej próbie. Znajomość odpowiedniego wzorca to dopiero początek tego procesu.

Z tego powodu do każdego porównania uwzględniłbym mniejszy model sztucznej inteligencji ogólnego przeznaczenia z dobrym wyszukiwaniem. Zapewnienie tej samej biblioteki doświadczeń pomogłoby nam określić, co wnosi szkolenie: lepsze generowanie kandydatów, lepsze decyzje po otrzymaniu informacji zwrotnej lub jedno i drugie.

Nauka kolejnego przydatnego eksperymentu

Najbardziej chciałbym się uczyć tych decyzji po otrzymaniu informacji zwrotnej. W rekonstrukcji agentowej model proponuje wyjaśnienie i testuje je w porównaniu z programem. Nawet jeśli potencjalny kod źródłowy zawiedzie, wynik może zawęzić pozostałe możliwości i zasugerować bardziej przydatny następny eksperyment.

Rozważmy ponownie przykład wyników tymczasowych. Ostateczne źródło pokazuje układ, który zadziałał, ale trasa do tego źródła zawiera więcej informacji. Każdy z poniższych eksperymentów pomógł określić, co należy jeszcze zmienić.

Wybrane eksperymenty z powyższej rekonstrukcji funkcji ataku, pogrupowane według tego, czego nas nauczyły.

Zapis szkoleniowy zachowujący tę sekwencję może nauczyć więcej niż samo ostateczne źródło. Łączy każdą proponowaną zmianę z zaobserwowanym rezultatem i następną decyzją. Utrzymywanie nieefektywnych odmian również ma znaczenie: informują późniejszego agenta, które hipotezy zostały już przetestowane w tym kontekście.

Chciałbym, żeby model nauczył się korzystać ze informacji zwrotnej. Neutralny wynik jest powodem do ponownego rozważenia odmiany; zmieniona niezgodność może wskazywać na inną przyczynę. Kiedy lokalne zmiany przestaną mieć charakter informacyjny, agent powinien mieć możliwość ponownego przejrzenia reprezentacji źródłowej lub ponownego sprawdzenia dowodów.

Nauka dokonywania takich wyborów wymaga autonomii. Czasami przydatnym następnym krokiem jest sprawdzenie innego obiektu wywołującego, zamiast kompilowania kolejnej edycji. Sztywna sekwencja wymaganych przeróbek usunie ten wybór wraz z częścią zachowań, których ma się nauczyć model.

Dlaczego inżynieria odwrotna jest interesująca w uczeniu się przez wzmacnianie

Rekonstrukcja o ustalonym zakresie daje praktyczne środowisko do badania tych decyzji. Po ustaleniu wersji celu i kompilatora wiele eksperymentów z kodem źródłowym zapewnia szybką, powtarzalną informację zwrotną. Agent może skompilować kandydata, sprawdzić różnice i wybrać następny krok.

Uczenie się przez wzmacnianie mogłoby szkolić proces podejmowania decyzji na podstawie otrzymywanych informacji zwrotnych. Kandydat przyjęty przez określony sprawdzian daje nam konkretny wynik, a sekwencja prób pozwala zaobserwować, ile pracy wymagało jego osiągnięcie.

Istnieją już badania potwierdzające ten kierunek. LLM4Decompile bada modele wyspecjalizowane w dekompilacji. AutoDecompiler trenuje udoskonalanie w wielu turach, korzystając z informacji zwrotnych od kompilatora i wykonania. Ich badania skupiają się na odzyskaniu funkcji. W tej pracy użyłbym ich jako punktu wyjścia do powiązanego zadania polegającego na znalezieniu źródła, które pasuje do danych wyjściowych historycznego kompilatora.

Aby jednak osiągnąć tak dobrze zdefiniowane zadanie, być może będziemy musieli najpierw ustalić, jakie zasoby posiada funkcja, lub opracować nowy sposób obserwowania zachowania programu podczas wykonania. Na przykład w TH08 różnica kolizji doprowadziła do tego, jak oryginalny program obsługiwał obliczenia zmiennoprzecinkowe. Zanim agent mógł przetestować użyteczną korektę, musiał ustalić, co należy zmierzyć.

Sugeruje to inną rolę modelu o szerokich możliwościach: przede wszystkim pomoc w sprawdzeniu problemu. Gdy już to sprawdzimy, będziemy mogli sprawdzić, jak daleko może zajść w tym przypadku wyuczona polityka wyszukiwania.

Gdy osoba sprawdzająca myli się

Gdy używamy sprawdzania podczas uczenia, jego zakres staje się częścią środowiska uczenia. Taki wzorzec lub moduł sprawdzający nazywam wyrocznią. Nawet powtarzalną odpowiedź trzeba rozumieć w granicach tego, co rzeczywiście sprawdza.

TH08 pokazał, jak wiele może ukryć się poza tym zasięgiem. Niektóre zrekonstruowane funkcje przeszły dokładne porównania z nieprawidłowymi stałymi zmiennoprzecinkowymi. Komparator korygował przeniesione adresy przed sprawdzeniem instrukcji, ale sprawdzał wartości za tymi adresami tylko wtedy, gdy zostały one wyraźnie zapisane w celu weryfikacji. Inne dosłowne odniesienia można pominąć bez sprawdzania ich wartości.

Aby zaradzić tej luce, szerszy audyt wykrył nieprawidłowe stałe w funkcjach, które przeszły już weryfikację. W jednym obliczeniu do zrekonstruowanego kodu źródłowego dodano 1.0f, podczas gdy w oryginale dodano 32.0f.

Model nagrodzony starym testem weryfikacyjnym mógłby nauczyć się tworzyć niepoprawną rekonstrukcję. Nie trenowaliśmy modelu RL przy użyciu tego modułu sprawdzającego. Niepowodzenie, które zaobserwowaliśmy, dotyczyło samego sprawdzenia. Ale gdybyśmy użyli tego jako nagrody, ten sam martwy punkt stałby się częścią środowiska uczenia się.

Test funkcjonalny może mieć podobny martwy punkt. Badania wykorzystujące różnicowe rozmycie w dekompilatorach LLM wykazały różnice w zachowaniu poza dostarczonymi testami. Dlatego też musimy rozumieć zdanie egzaminu w kategoriach przypadków, w których występuje. Podobnie dopasowanie instrukcji należy rozumieć w kategoriach bajtów i danych, które sprawdza.

Zanim użyję jakiegokolwiek rodzaju kontroli weryfikacyjnej jako nagrody, przetestowałbym ją z celowo błędnymi wynikami. Chciałbym również, aby ostateczna akceptacja była oddzielona od kodu źródłowego, który agent AI może edytować. Model musi przejść weryfikację poprzez poprawną rekonstrukcję programu. W przeciwnym razie zwykłe skopiowanie tablicy bajtów z celu może oszukać naiwny system oceniania bez odzyskiwania przydatnego kodu źródłowego.

Ulepszanie modelu i ulepszanie jego modułu sprawdzającego należą do tego samego problemu badawczego. Im lepiej model optymalizuje otrzymywaną informację zwrotną, tym ważniejsze jest zrozumienie tej informacji.

Porównanie warte przeprowadzenia

Mając te kontrole, rozpocząłbym porównanie od ustalonej rodziny zadań VC7.1. Najpierw ustaliłbym podstawy dla silnego modelu sztucznej inteligencji ogólnego przeznaczenia i mniejszego. Dodanie wiedzy o repozytorium do mniejszego modelu pokazałoby, jakie zmiany w pobieraniu. Następnie nadzorowana specjalizacja i wersja przeszkolona przez RL pozwolą nam sprawdzić, co dodaje szkolenie.

Aby porównania te miały charakter informacyjny, każdy model otrzymałby te same docelowe dowody i narzędzia. W przypadku porównań specyficznych dla szkoleń zachowałbym również stały model podstawowy i dostępną wiedzę. Powtarzane próby pomogłyby odróżnić niezawodną strategię wyszukiwania od potencjalnego rozwiązania, które odniosło sukces przez przypadek.

Następnie oddzieliłbym dwa warunki początkowe: rekonstrukcję funkcji na podstawie jej instrukcji i zamknięcie kilku ostatnich różnic w utrzymywanym źródle. Wyspecjalizowany model sztucznej inteligencji może doskonale sprawdzić się w drugim zadaniu, podczas gdy model sztucznej inteligencji ogólnego przeznaczenia wykonuje większość pracy potrzebnej do jego osiągnięcia. Zmierzenie ich osobno ujawniłoby ten podział pracy.

Obydwa zadania wymagają przykładów testowych wyłączonych ze szkolenia i wyszukiwania. Powiązane gry Touhou udostępniają kod silnika. Wykluczenie jednej gry z treningu może w dalszym ciągu pozostawić prawie identyczne funkcje w zbiorze treningowym. Zamiast tego wykluczyłbym całe grupy powiązanego kodu źródłowego i trzymał ich zweryfikowane odpowiedzi poza danymi szkoleniowymi i biblioteką pobierania.

W przypadku tych przykładów wynikiem będą kompletne, niezależnie zweryfikowane dopasowania. Równe budżety na propozycje kandydatów lub próby kompilacji pomogłyby w porównaniu jakości wyszukiwania. Pomiar całkowitego czasu i kosztów, w tym kompilacji, pokazałby, czy ta jakość zapewnia efektywny przepływ pracy. Koszty szkoleń należy mierzyć osobno.

Obydwa pomiary mają znaczenie. Tania propozycja może prowadzić do kosztownego przepływu pracy, jeśli powoduje więcej kompilacji, które nie dostarczają żadnych przydatnych informacji. I odwrotnie, wolniejszy model może być bardziej ekonomiczny, jeśli wcześniej znajdzie przydatny eksperyment. Porównanie powinno uwzględniać te koszty.

Liczenie zaakceptowanych wyników pozwala również zachować perspektywę postępu pośredniego. Jeden TH09 kandydat do zapisania powtórki wyglądał obiecująco, ponieważ skompilowana funkcja miała oczekiwany rozmiar, ale pełne porównanie nadal wykazało znaczne różnice. Zmiany w sposobie, w jaki kompilator organizuje instrukcje, mogą również sprawić, że kandydat wydaje się bliższy celowi bez rozwiązania podstawowego problemu. Taka diagnostyka może pomóc w kolejnym eksperymencie, ale każdą nagrodę za „zbliżenie się” porównałbym z pełną kontrolą akceptacji.

Byłbym zainteresowany wzorcem tych wyników. Jeśli wyspecjalizowany model sztucznej inteligencji radzi sobie dobrze w znanej rodzinie kompilatorów, czy ta zaleta przetrwa zmianę w zestawie narzędzi? A kiedy oba modele sztucznej inteligencji będą dobrze odzyskiwane, ile jeszcze doda szkolenie? Odpowiedzi pomogłyby nam zdecydować, gdzie każdy rodzaj modelu jest najbardziej przydatny.

Jakiego rodzaju agenta AI to sugeruje?

Jeśli modele pomagają na różnych etapach, przydatny może być agent ogólny z dostępem do modelu specjalistycznego. Gdy zadanie sprowadza się do znanego problemu z kompilatorem, może poprosić specjalistę o kandydatów. Jeśli wyniki przestają mieć sens, agent ogólny może wrócić do danych celu albo zbadać sam pomiar.

W takim układzie specjalizacja staje się narzędziem, które agent może wybrać w miarę rozwoju dochodzenia. Agent zachowuje swobodę zmiany kierunku, co umożliwiło wcześniejsze przełomy.

Wynika to naturalnie z przemian w przemyśle, które opisałem w poprzednim eseju. Możliwość przeprowadzenia znacznie większej liczby eksperymentów zmienia sposób organizacji pracy. Daje nam to również powód, aby zadać sobie pytanie, które decyzje wymagają szerokiego osądu, a które można poprawić dzięki wielokrotnemu doświadczeniu z konkretnym rzemiosłem.

Na razie najsilniejszy model ogólny zasłużył na miejsce w moim przepływie pracy, rozwiązując problemy, których wcześniej nie rozwiązałem. Te sukcesy skłaniają mnie do zbadania procesu: jaka część zależała od szerokości jego możliwości, a jaką mógłby wykonać model uczony specjalnie do takiej rekonstrukcji?

Repozytoria umożliwiają nam przetestowanie pytania. Chciałbym użyć tego rekordu do stworzenia porównania i zobaczenia, czego się dowiemy.