Rewolucja przemysłowa w inżynierii odwrotnej.

Co się zmieniło w sierpniu 2026 roku

Przed tą pracą wykonałem wiele ręcznej inżynierii odwrotnej. Sprawdzałem funkcję, dopóki nie miałem wyjaśnienia, a następnie testowałem to Wyjaśnienie przeciwko programowi. Pójście dalej oznaczało spędzenie większej ilości czasu na następnej funkcji. Oznaczało to również utrzymanie coraz większego obrazu w mojej głowie.

Większość moich prac re jest na grach. Rekonstruuję je, aby ich zachowanie można było zrozumieć i ostatecznie przenieść do portu oprogramowania lub modu. To jest doświadczenie stojące za tym artykułem. Metoda może być przydatna gdzie indziej, ale każde pole musi ustalić, co może sprawdzić z wiarygodnym odniesieniem.

W sierpniu 2026 roku zacząłem poważnie eksplorować re napędzane agentami. Chciałem zobaczyć, jak daleko agent może się dostać z dostępem do programu i zwykłych narzędzi programistycznych. Rekonstrukcja Touhou dała mi znaczący projekt, w którym mogę się dowiedzieć.

Wczesny postęp był zaskakujący. Śledztwo może trwać bez mojego wyboru każdego indywidualnego kroku. Nieudane porównanie może wysłać Agenta do innego dzwoniącego. Może napisać małą diagnostykę i wykorzystać wynik, aby zdecydować, co spróbować dalej. Przyznanie tej wolności miało znaczenie: mogłem poświęcić więcej uwagi kierunkowi projektu i temu, czy jego kontrole są godne zaufania.

Tempo najpierw zwróciło moją uwagę. Potem zacząłem się zastanawiać, co przetrwa poza obecnym projektem. Czy następna gra skorzysta na wszystkim, czego się właśnie nauczyliśmy?

TH08: budowanie na ludzkiej pracy

TH08 , Niezniszczalna noc, rozpoczęła się jako kontynuacja Rekonstrukcja GensokyoClub. Ich publiczne źródło dało mi solidne podstawy. Przyszedł ze znajomością budowy i historią wkładów, które zachowałem w kontynuacji.

Importowana historia kończy się w publicznym punkcie kontrolnym 10 sierpnia. Moja niezależna kontynuacja rozpoczęła się 13 sierpnia. Do 19 sierpnia Księga rejestrowała źródło wszystkich 1107 zidentyfikowanych funkcji gry.

Grywalny Port rekonstrukcji Linux został popełniony 24 sierpnia, mniej więcej jedenaście dni po rozpoczęciu kontynuacji. Nastąpiło wydanie internetowe. Natywna 64-bitowa wersja Linux pojawiła się 30 sierpnia.

Uderzyło mnie to, że praca dotarła do programu, który ludzie mogli uruchomić. Dotarcie tam wymagało następujących problemów wykraczających poza indywidualną funkcję. Nawet jeśli dwie funkcje wyglądały poprawnie w izolacji, mogły przypadkowo użyć oddzielnych kopii stanu, które powinny były zostać udostępnione.

To sprawiło, że kontrole referencyjne były kluczowe dla pracy. Nazywam je referencje weryfikacyjne (wyrocznie). Porównanie kodu może nam powiedzieć, czy zrekonstruowana funkcja odtwarza oryginalne instrukcje. Kontrola czasu wykonywania może nam powiedzieć, czy ćwiczona trasa osiąga oczekiwany stan. Agent proponuje wyjaśnienie i testuje je; niedopasowanie daje mu coś konkretnego do zbadania.

Dokładne dopasowanie z niewłaściwą stałą

Referencja weryfikacyjna (oracle) to oprogramowanie, które ktoś napisał. TH08 dał mi wyraźne przypomnienie, ile może zależeć od tego oprogramowania.

We wrześniu błąd zgłoszony przez port przełącznika w dół doprowadził do automatycznego zbierania przedmiotów. Zrekonstruowane źródło sprawdziło moc gracza przeciwko 0.0. Oryginalny używany 128.0, maksymalny próg mocy.

Normalna moc jest nieujemna, więc zrekonstruowana kontrola mocy była skutecznie zawsze spełniona. Powyżej linii kolekcji gra może przyciągać przedmioty bez konieczności maksymalnej mocy. Pozostałe wyjątki w tym stanie były poprawne. Ta jedna stała zmieniła zachowanie.

Jednak funkcja przeszła już dokładne porównanie.

Odbudowa może umieścić stałą pod innym adresem. Narzędzie porównujące uwzględniło to, dostosowując adresy w skompilowanych instrukcjach przed porównaniem ich z oryginałem. Ale nigdy nie sprawdzał wartości zmiennoprzecinkowej przechowywanej pod adresem, do którego się odwołuje.

To zostawiło dziurę w czeku. Może wskazywać zrekonstruowaną instrukcję na oryginał 128.0 podczas gdy źródło wciąż mówi 0.0. Bajty instrukcji dopasowane. Źródło oznaczało coś innego.

The 2 września poprawka Poprawiono źródło i porównano rzeczywiste bajty przywoływanej stałej. A szerszy audyt następnie zbadano 1548 stałych zmiennoprzecinkowych odniesień. Znalazł kolejne dwanaście błędnych odniesień w pięciu akceptowanych funkcjach.

Porównanie sprawdza teraz każdą taką stałą zmiennoprzecinkową. Jego testy zawierają celowo błędne wartości, aby upewnić się, że zostały odrzucone. Musieliśmy również ponownie sprawdzić wyniki, które przeszły słabszą kontrolę.

Referencja weryfikacyjna (oracle) również wymagała rekonstrukcji. Naprawa była częścią naprawy gry.

Ma to znaczenie, gdy zespół składa się głównie z jednej osoby pracującej z agentami. Nie mogę osobiście sprawdzić każdej linii, którą produkują, więc duża część mojego zaufania spoczywa na ich czekach. Blind spot shared verification reference (oracle) może wpłynąć na wiele dochodzeń, zanim to zauważę. Muszę zrozumieć, co faktycznie weryfikuje kontroler i przetestować go pod kątem przypadków, które powinny się nie udać.

W miarę kontynuowania prac kontrole te stały się częścią repozytorium. Podobnie jak przyczyny zmian źródłowych i notatek, które pozwalają na późniejszą sesję w miejscu, w którym zatrzymała się wcześniejsza. Repozytorium kodu źródłowego stawało się pamięcią roboczą projektu.

Udana partia dała nam zarówno odzyskany Kod, jak i lepsze środowisko dla następnej partii.

Dwie różne koncepcje rekonstrukcji

GensokyoClub publiczny README wyraźnie wyraża sprzeciw wobec tego rodzaju pracy. W zawiadomieniu zapowiada się, że dalszy rozwój nastąpi prywatnie do czasu zakończenia. Jeden fragment brzmi:

Powstanie grifterów (dekompilacje AI i porty) w tej przestrzeni biorąc z naszej pracy maluje zły obraz dla przyszłych wysiłków dekompilacyjnych…

Zawiadomienie opisuje również psychologiczne żniwo dla opiekunów. Ich polityka wkładu wyklucza pull requesty wytwarzane głównie za pomocą sztucznej inteligencji. Poświęcili swój wolny czas na trudną pracę,a ta praca pomogła mi kontynuować. Szanuję wysiłek, który za tym stoi. Spór, który chcę omówić, dotyczy tego, jak powinna przebiegać odbudowa i jak należy oceniać wkład.

W ręcznym przepływie pracy, który znałem, rozwijanie zrozumienia funkcji i jej rekonstrukcja Zwykle przypadało tej samej osobie. Projekt w dużej mierze opierał się na wiedzy tej osoby. Zaufanie do współpracownika miało znaczenie, ponieważ tak wiele rozumowania wydarzyło się, gdy pracowali.

Istniejące projekty już zachowują wiedzę w swoim źródle i budują narzędzia. Zmieniło się dla mnie to, że agent mógł wykorzystać tę wiedzę do samodzielnego prowadzenia następnego śledztwa.

W mojej kontynuacji decyduję o celu i standardzie akceptacji wyniku. Agent ma szeroką swobodę prowadzenia dochodzeń. Proponowana rekonstrukcja musi następnie przetrwać odpowiednie kontrole. Chcę, aby inna osoba mogła zbadać, dlaczego wybraliśmy implementację, nawet jeśli agent wykonał większość pracy.

To może być trudne przejście. Lata starannej pracy mogą stać się podstawą kontynuacji, która porusza się znacznie szybciej. To rodzi prawdziwe pytania dotyczące kredytu. Zmienia również to, co opiekunowie muszą wiedzieć przed przyjęciem wkładu.

Analogia przemysłowa pomaga mi o tym myśleć. W rzemiośle znaczna część procesu zależy od umiejętności osoby, która go wykonuje. Maszyny zmieniają się tam, gdzie ta umiejętność jest potrzebna. Ktoś nadal musi zaprojektować proces i rozpoznać, kiedy jego wynik jest nieprawidłowy. Różne społeczności mogą wybrać, ile z tej zmiany chcą podjąć.

Moim wyborem jest otwarcie kontynuować, z przypisaną odziedziczoną pracą i zachowaną jej historią. Chcę, aby nowa praca była możliwa do przejrzenia. To daje nam sposób, aby zapytać, jak daleko może zajść to podejście i wyciągnąć wnioski z tego, co dzieje się nie tak po drodze.

Źródło: GensokyoClub README zawiadomienie, sprawdzone 10 października 2026 r. i jego Polityka składek. Cytat jest skróconym fragmentem. TH08 kredyty i pochodzenie Zapisz granicę kontynuacji.

TH095: doświadczenie zaczyna się mieszać

TH095 , Shoot the Bullet, sprawił, że wartość tego doświadczenia była znacznie łatwiejsza do zobaczenia. Jego repozytorium rozpoczęło się 29 sierpnia z zerowymi potwierdzonymi funkcjami gry w Księdze. Nadal musieliśmy nauczyć się gry. Ale wiedzieliśmy już znacznie więcej o tym, jak rozpocząć rekonstrukcję i jak ją utrzymać.

Do 7 września wszystkie 697 zidentyfikowanych funkcji gry miało źródło. Do 8 września 696 zostało zaakceptowanych jako dokładne porównania. Cały program połączył się 9 września. Rekonstrukcja Windows i386 została oznaczona jako grywalna 10 września, około dwanaście dni po inicjalizacji.

Uważam to za bardziej ekscytujące niż szybkość pierwszego projektu. Nowy cel mógłby skorzystać z pracy wykonanej nad inną grą. Doświadczenie było już obecne w narzędziach i sposobie organizacji projektu.

Na przykład TH08 nauczył nas wcześnie zwracać uwagę na zmontowany program. Jeśli kilka odzyskanych funkcji zależy od tego samego stanu, ich pojedyncze porównania pozostawiają ważne pytanie otwarte. Musimy zobaczyć, jak pracują razem. Ta lekcja pomogła ukształtować sposób, w jaki zbliżyliśmy się do kompilacji całego programu TH095.

Lekcja, która pozostaje w mojej głowie, jest przydatna, gdy tam jestem. Gdy stanie się to sprawdzeniem, czy może uruchomić się kolejna sesja, może pomóc po przejściu dalej. Następny agent może wykorzystać wynik bez powtarzania dochodzenia, które do niego doprowadziło.

Zmiennoprzecinkowy błąd stałej również należy do tej pamięci. Wyjaśnia, dlaczego sprawdzenie odwołania wymaga również sprawdzenia danych za nim stojących. Utrzymanie tej korekty za pomocą kodu pomaga późniejszym projektom uniknąć dziedziczenia martwego pola starego czeku.

Metoda staje się częścią materiału wyjściowego do następnej gry. Możemy poświęcić więcej wysiłku następnego projektu na to, co jest naprawdę nowe w jego celu.

Ta sama korzyść jest dostępna dla osób dołączających później. Mogą sprawdzić decyzję i ponownie uruchomić kontrolę przed kontynuowaniem pracy. Nie muszą rekonstruować całej historii projektu, aby dowiedzieć się, dlaczego źródło wygląda tak, jak wygląda.

TH04: przepływ pracy przetrwa inną architekturę

TH04 , Lotus Land Story, wziął tę pracę do ery PC-98 DOS. Celem było teraz środowisko 16-bitowe z czterema współpracującymi programami. Zrozumienie jego zachowania sprzętowego wymagało różnych dowodów od gier Windows. Istniejące ReC98 praca dał nam również cenną wiedzę i materiały źródłowe.

Rekonstrukcja DOS już działa. W moich testach ręcznych grałem w pełne normalne trasy przez ich zakończenia i sprawdzałem zapisy. Obecna praca to natywny port 64-bitowy. Ustanowienie działającej wersji DOS najpierw daje temu portowi odniesienie.

Architektura zmieniła to, co musieliśmy zbadać. Zmienił również kompilator i Środowisko wykonawcze, w którym sprawdzaliśmy naszą pracę. Ale agent może nadal podążać za pytaniem aż do wyniku i pozwolić temu wynikowi kierować następnym eksperymentem.

Rozważ przejście od rozgrywki do zakończenia. Musimy wiedzieć, jaki stan przenosi tę granicę i który program jest za to odpowiedzialny. To jest coś, co możemy zbadać przeciwko produktowi DOS. Gdy dowody i kontrole są dostępne, agent może przepracować pytanie tak samo, jak w przypadku tytułu Windows.

Dlatego TH04 ma znaczenie dla argumentu. Istotna zmiana platformy nie zmusiła nas do rozpoczęcia od nowa z nowym sposobem pracy. Architektura zdefiniowała problem; przepływ pracy nadal dał nam sposób na jego rozwiązanie.

W przypadku portu 64-bitowego możemy teraz zbadać nową implementację pod kątem zachowania już odzyskanego w DOS. Wiedza z rekonstrukcji daje portowi coś do zbudowania.

Stan projektu na 10 października 2026 r: Rekonstrukcja DOS i testy ręczne · Port 64-bitowy. Port pozostaje w fazie rozwoju.

Od dokładnego kodu do czytelnego kodu

Gdy rekonstrukcja zadziała, chcę, aby ktoś inny mógł to zrozumieć.

Dla mnie montaż i surowe przesunięcia mogą czuć się jak starzy przyjaciele. Zdaję sobie sprawę, że jest to nieco nietypowa definicja "czytelnego"."Większość ludzi wolałaby podążać za logiką gry bez trzymania w głowie układu pamięci pliku wykonywalnego.

Właśnie tam rekonstrukcja semantyczna wchodzi. Odzyskane pole może być nadal znane głównie z jego przesunięcia. Śledzimy, jak gra go używa, dopóki nie wyjaśnimy jej roli. Następnie możemy nadać mu znaczącą nazwę i typ, który pasuje do dowodów. Trzymamy rozumowanie ze źródłem, aby następna osoba mogła zobaczyć, skąd pochodzi ta interpretacja.

Staje się to szczególnie ważne w przypadku portu oprogramowania. Adres bezwzględny mówi mi, gdzie coś żyło w starym pliku wykonywalnym. Daje 64-bitową implementację niewielką pomoc w podjęciu decyzji, który obiekt powinien posiadać ten stan. Aby bezpiecznie przenieść zachowanie, musimy odzyskać związek stojący za starym dostępem do pamięci.

Kolejność, której teraz używam, to:

1. Odzyskaj dokładną linię bazową. Skompiluj zrekonstruowane elementy za pomocą kompilatora historycznego. Porównaj odpowiedni kod i dane z oryginalnym plikiem wykonywalnym. Zapisz nierozwiązane różnice, aby następna faza miała wyraźny punkt wyjścia.
2. Zbuduj i zagraj na oryginalnej platformie. Połącz te elementy z prawdziwym programem za pomocą oryginalnej architektury i kompilatora. Ćwicz ważne ścieżki rozgrywki. W tym miejscu możemy znaleźć problemy ze stanem współdzielonym lub inicjalizacją, które przeoczyło izolowane Porównanie funkcji.
3. Zrekonstruuj semantykę na podstawie obu odniesień. Weź jedną spójną część gry na raz i ustal, co oznacza jej odzyskane źródło. Popraw jego reprezentację, zachowując dokładne porównania i grywalną historyczną kompilację.
4. Stwórz nowoczesny port. Przenieś ustalone zachowanie do nowego środowiska, takiego jak natywna kompilacja 64-bitowa. Zrekonstruowana oryginalna gra platformowa pozostaje punktem odniesienia do porównania zachowania portu.

Grywalna kompilacja z drugiego etapu staje się drugie odniesienie do weryfikacji (oracle) podczas trzeciego. Pierwsze odniesienie weryfikacyjne (oracle) sprawdza, czy zmienione źródło nadal odtwarza odpowiedni oryginalny kod i dane. Drugi sprawdza, czy zrekonstruowany program nadal buduje i zachowuje się poprawnie wzdłuż ścieżek, które ćwiczymy.

Łapią różne błędy. Zmiana typu może zmienić wygenerowane instrukcje. Zmiana własności może pozostawić dwie części gry przy użyciu różnych kopii stanu. Utrzymywanie obu dostępnych kontroli daje agentowi konkretny brak zbadania przed dalszym przenoszeniem refaktora.

Imię potrzebuje własnego dowodu. Dokładne porównanie nie może nam powiedzieć, czy pole naprawdę oznacza "czas niewrażliwości"."Musimy to ustalić na podstawie tego, jak gra ją pisze i używa. Jeśli znaczenie pozostaje niepewne, neutralna nazwa jest bardziej pomocna dla następnego czytelnika niż pewne przypuszczenie.

Nauczyliśmy się tego zamówienia poprzez projekty. TH08 miał już grywalne porty przed niektórymi późniejszymi audytami platform historycznych. To sprawiło, że niektóre wady były trudniejsze do zauważenia. The Obecny przepływ pracy fabryki stawia na pierwszym miejscu kompilację oryginalnej platformy, aby praca semantyczna mogła używać jej jako odniesienia przed rozpoczęciem przenoszenia.

Dokładna rekonstrukcja daje nam odniesienie. Rekonstrukcja semantyczna sprawia, że odzyskana wiedza jest użyteczna. Port może następnie budować na obu.

Co sprawia, że jest to zmiana przemysłowa

Te projekty zmieniły się tam, gdzie spędziłem moją uwagę. Kiedy agenci mogli przeprowadzić wiele śledztwa, poprawa ich środowiska pracy stała się jedną z najbardziej przydatnych rzeczy, jakie mogłem zrobić. Lepsze narzędzie może pomóc w każdej późniejszej funkcji, która tego potrzebowała.

Autonomia ma tu znaczenie. Przydatny następny krok często staje się jasny dopiero po nieudanym eksperymencie. Agent potrzebuje wystarczającej swobody, aby śledzić ten wynik w nieoczekiwanym miejscu. Jeśli musi czekać, aż przepiszę każdy krok, znaczna część pracy pozostaje związana z moją uwagą.

Oczekuję, że agent postawi błędne hipotezy. Liczy się to, czy możemy je przetestować i wyciągnąć wnioski z wyniku. Nieudana kontrola powinna pomóc zrozumieć błąd na tyle dobrze, aby spróbować ponownie. Nadal muszę zdecydować, czy zgromadzone dowody potwierdzają kamień milowy projektu.

REA daje agentowi dostęp do narzędzi analitycznych. Pytanie dotyczące dzwoniącego funkcji może prowadzić bezpośrednio do sprawdzenia tego dzwoniącego. Projekt rekonstrukcji dostarcza kompilator i własne kontrole referencyjne. Agent może ich użyć do przetestowania proponowanego źródła i sprawdzenia, gdzie znajduje się jego wyjaśnienie.

Błąd TH08 pokazuje, dlaczego te kontrole zasługują na własną uwagę inżynierską. Gdy to samo porównanie jest używane w setkach funkcji, luka w nim może rozprzestrzenić się znacznie dalej niż błąd w jednej implementacji. Testowanie sprawdzania poprawia informacje zwrotne dostępne dla wszystkich późniejszych prac.

Analogia przemysłowa ma tutaj przydatny przykład historyczny. Boulton i Watt przedstawili wskaźnik parowozu w 1796 roku aby pomóc w regulacji zaworów silnika. Wersja rejestrująca prześledziła ciśnienie przez skok tłoka. Dzięki temu wewnętrzne zachowanie silnika było dostępne do kontroli. Nasze narzędzia porównawcze służą podobnemu celowi: pozwalają nam zbadać, co robi maszyna, podczas gdy my ją ulepszamy.

Jesteśmy na wczesnym etapie tej zmiany przemysłowej. Znaczna część infrastruktury jest nadal niedojrzała. Agenci mogą poruszać się szybciej niż nasze czeki zostały zaprojektowane do obsługi, więc proces musi się rozwijać wraz z nimi. Kiedy znajdziemy usterkę we wspólnym narzędziu, musimy ją naprawić i Ponownie sprawdzić wyniki, na które wpłynęło. Następny projekt może następnie odziedziczyć silniejsze narzędzie.

Istnieje również praktyczny limit każdej jednej rozmowy. Zakończy się przed zakończeniem dużej rekonstrukcji. Repozytorium kodu źródłowego musi umożliwić kontynuowanie kolejnej sesji bez utraty przyczyny ostatniej decyzji.

The Fabryka Odbudowy Touhou wyrosła z tej potrzeby. Daje projektom wspólny sposób na kontynuowanie kontroli i lekcji. Praca nad jedną grą może poprawić warunki początkowe dla innej.

To właśnie sprawia, że analogia przemysłowa ma dla mnie znaczenie. Doświadczenie staje się częścią narzędzi, z których mogą korzystać inni. Ulepszenie tych narzędzi zmienia, ile może zrobić następna osoba—lub następny agent.

Projekty, które możemy teraz rozważyć

Tempo ma znaczenie, ponieważ zmienia decyzję o rozpoczęciu. Gra może być fascynująca w inżynierii wstecznej i nadal wymagać więcej mojej uwagi, niż realistycznie mógłbym jej poświęcić. Wiele projektów pozostanie pomysłami.

Teraz widzę sposób na utrzymanie takiego projektu poprzez powtarzające się dochodzenia. Uzyskanie działającej rekonstrukcji sprawia, że port oprogramowania jest bardziej praktyczny. Odzyskiwanie czytelnej semantyki ułatwia komuś innemu eksplorację Moda. Wysiłek włożony w zrozumienie gry może się opłacić po uruchomieniu pierwszej wersji.

Patrzę teraz na Nieznany program i pytam: jaki dostęp, informacje zwrotne i zgromadzona wiedza pozwoliłyby agentowi pracować nad tym niezawodnie?

To pytanie skłania mnie do rozważenia projektów, które wcześniej zostawiłbym sam. Każdy z nich może poprawić sposób, w jaki podchodzimy do następnego. Chcę dalej badać, jak daleko to może nas zaprowadzić.

Więcej artykułów · Poznaj badanie TH04