Промислова революція в області реверс-інжинірингу.

Що змінилося в серпні 2026 року

До цієї роботи я багато займався зворотним проектуванням вручну. Я перевіряв функцію, поки не знайшов пояснення, а потім перевірив це пояснення в програмі. Просуваючись далі, я витрачав більше свого часу на наступну функцію. Це також означало, що я тримав у голові все більш об'ємну картину.

Велика частина моєї роботи пов'язана з іграми. Я реконструюю їх, щоб я міг зрозуміти їх поведінку і врешті-решт перенести на програмний порт або мод. Саме цей досвід лежить в основі цієї статті. Цей метод може бути корисним в інших областях, але в кожній області потрібно встановити, що можна перевірити за допомогою надійних посилань.

У серпні 2026 року я почав серйозно вивчати re, керований агентами. Я хотів побачити, як далеко може зайти агент, маючи доступ до програми та звичайних інструментів розробки. Touhou reconstruction дав мені значний проект, де я міг це зрозуміти.

Перші результати були вражаючими. Розслідування могло б тривати без моєї участі у виборі кожного окремого кроку. Невдале порівняння могло б відправити агента до іншого абонента. Можна було б написати невелику діагностику і використати результат, щоб вирішити, що робити далі. Надання цієї свободи змінило ситуацію на краще: я зміг приділяти більше уваги напрямку проекту і тому, чи заслуговують довіри його перевірки.

В першу чергу мою увагу привернув темп. Потім я почав замислюватися над тим, що залишиться після поточного проекту. Чи буде в наступній грі корисно все, що ми тільки що дізналися?

TH08: опора на людську працю

TH08 , "Вічна ніч", починався як продовження реконструкція GensokyoClub. Їх відкрите джерело дало мені значну основу. Це прийшло разом із знанням конструкції та історією внеску, яку я зберіг у продовженні.

Імпортована історія закінчується на загальнодоступній контрольній точці 10 серпня. Моє самостійне продовження почалося 13 серпня. До 19 серпня в журналі були зареєстровані вихідні дані для всіх 1107 ідентифікованих ігрових функцій.

Відтворюваний порт реконструкції Linux був випущений 24 серпня, приблизно через одинадцять днів після початку роботи над продовженням. Потім була випущена веб-версія. 64-розрядна версія Linux для власної версії вийшла 30 Серпня.

Мене вразило те, що в результаті роботи була створена програма, яку могли запускати люди. Щоб досягти цього, потрібно було вирішити проблеми, що виходять за рамки окремої функції. Навіть якщо дві функції виглядали коректно окремо, вони могли випадково використовувати окремі копії state, які повинні були бути спільними.

Це зробило перевірку посилань центральною в роботі. Я називаю їх перевірочними посиланнями (оракулами). Порівняння коду може сказати нам, чи відновлена функція відтворює оригінальні інструкції. Перевірка під час виконання може сказати нам, чи реалізований маршрут досягає очікуваного стану. Агент пропонує пояснення та перевіряє його; невідповідність дає йому можливість дослідити щось конкретне.

Точний збіг з неправильною константою

Посилання для перевірки (oracle)-це програмне забезпечення, яке хтось написав. TH08 дав мені чітке нагадування про те, наскільки це програмне забезпечення може залежати.

У вересні помилка, про яку повідомив порт комутатора, знову призвела до автоматичного збору предметів. У відновленому джерелі потужність програвача була перевірена на рівні 0.0. В оригіналі використовувалося значення 128.0 - поріг максимальної потужності.

Нормальна потужність невід'ємна, тому перевірка відновленої потужності фактично завжди виконувалася. Вище лінії збору гра могла залучати предмети, не вимагаючи максимальної потужності. Інші винятки з умови були вірними. Ця константа змінила поведінку.

Однак функція вже пройшла точне порівняння.

При перестроюванні константа може бути поміщена за іншою адресою. Інструмент порівняння враховував це, коригуючи адреси в складених інструкціях, перш ніж порівнювати їх з оригінальними. Але він ніколи не перевіряв значення з плаваючою комою, збережене за вказаною адресою.

Це залишило прогалину в перевірці. Це може призвести до того, що відновлена команда вказує на початкове значення 128.0, тоді як джерело все ще вказувало 0.0. Байти інструкції збіглися. Джерело мав на увазі щось інше.

Виправлення, випущене 2 вересня, виправило вихідний код і змусило при порівнянні перевіряти фактичні байти константи, на яку посилається посилання. Потім було проведено більше широкий аудит, в ході якого було проаналізовано 1548 посилань на константи з плаваючою комою. Було виявлено ще дванадцять неправильних посилань у п'яти прийнятих функціях.

При порівнянні тепер перевіряється кожна така константа з плаваючою комою. Тести використовують відомі неправильні значення, щоб переконатися, що вони відхилені. Нам також довелося переглянути результати, які пройшли більш слабку перевірку.

Посилання для перевірки (oracle) також потребувало відновлення. Її виправлення було частиною оновлення гри.

Це важливо, коли команда складається в основному з однієї людини, яка працює з агентами. Я не можу особисто перевіряти кожен рядок, який вони створюють, тому багато в чому я довіряю їх перевіркам. "Сліпа пляма" в системі загального контролю (oracle) може вплинути на багато розслідувань, перш ніж я це помічу. Я повинен зрозуміти, що насправді перевіряє засіб перевірки, і протестувати його на предмет випадків, які повинні завершитися невдачею.

У міру продовження роботи ці перевірки ставали частиною репозиторію. Так само і причини змін вихідного коду і примітки, які дозволяли більш пізнього сеансу продовжити роботу з того місця, на якому зупинилася попередня сесія. Репозиторій вихідного коду ставав робочою пам'яттю проекту.

Успішний запуск пакета дозволив нам відновити код та покращити середовище для наступного пакета.

Дві різні ідеї реконструкції

Публічний сайт GensokyoClub явно висловлює свою незгоду з такого роду роботою. У повідомленні повідомляється, що подальша розробка буде вестися в приватному порядку до завершення. В одному уривку сказано:

Зростання кількості шахраїв (декомпіляторів та портаторів штучного інтелекту) у цій галузі на основі нашої роботи створює погану картину для майбутніх зусиль з декомпіляції…

У повідомленні також описується психологічне навантаження на супроводжуючих. Їх політика щодо вкладів виключає запити на перенесення, зроблені в основному за допомогою штучного інтелекту. Вони присвятили свій вільний час складній роботі, і ця робота допомогла мені продовжувати працювати. Я поважаю зусилля, які стоять за цим. Розбіжності, які я хочу обговорити, стосуються того, як повинна проходити реконструкція і як слід оцінювати внесок.

У звичному мені ручному робочому процесі розробка розуміння функції і її реконструкція зазвичай покладалися на одного і того ж людини. Проект значною мірою залежав від досвіду цієї людини. Довіра до розробника мала значення, оскільки більша частина міркувань виникла під час його роботи.

Існуючі проекти вже зберігають знання у своїх оригінальних текстах та інструментах для створення. Для мене змінилося те, що агент може використовувати ці знання для проведення наступного розслідування самостійно.

У своєму продовженні я визначаю мету і стандарт прийняття результату. Агент має широку свободу у проведенні розслідування. Потім запропонована реконструкція повинна пройти відповідні перевірки. Я хочу, щоб інша людина могла проаналізувати, чому ми вибрали певну реалізацію, навіть якщо агент зробив більшу частину роботи.

Це може бути важким переходом. Роки ретельної роботи можуть стати основою для подальшого розвитку, яке буде просуватися набагато швидше. У зв'язку з цим виникають серйозні питання про кредитоспроможність. Це також змінює те, що розробники повинні знати, перш ніж приймати внесок.

Аналогія з промисловістю допомагає мені задуматися над цим. У ремеслі більша частина процесу залежить від майстерності людини, яка його виконує. Обладнання змінюється там, де потрібна ця навичка. Хтось все одно повинен розробляти процес і розпізнавати, коли його результати неправильні. Різні спільноти можуть вибрати, яку частину цих змін вони хочуть взяти на себе.

Мій вибір - продовжувати відкрито, враховуючи успадковану роботу та зберігаючи її історію. Я хочу, щоб нова робота була доступна для рецензування. Це дає нам можливість оцінити, наскільки далеко може пройти цей підхід, і навчитися з того, що на цьому шляху йде не так.

Джерело: Повідомлення GensokyoClub на README, перевірене 10 жовтня 2026 року, і його Політика щодо внесків. Цитата є скороченою витримкою. Титри та Походження TH08 вказують на межу продовження.

TH095: досвід починає накопичуватися

TH095, Shoot the Bullet, значно спростив сприйняття цього досвіду. 29 серпня почалося його оновлення з нульовими підтвердженими ігровими функціями в реєстрі. Ми все ще мали вивчити гру. Але ми вже знали набагато більше про те, як розпочати реконструкцію та як підтримувати її в робочому стані.

До 7 вересня всі 697 ідентифікованих ігрових функцій мали вихідний код. До 8 вересня 696 були прийняті як точні порівняння. 9 вересня вся програма була підключена. Реконструкція Windows i386 була позначена як відтворювана 10 вересня, приблизно через дванадцять днів після ініціалізації.

Я знайшов це більш захоплюючим, ніж швидкість першого проекту. Нова мета могла б отримати вигоду від роботи над іншою грою. Досвід вже був присутній в інструментах і в тому, як був організований проект.

Наприклад, TH08 навчив нас звертати увагу на зібрану програму з самого початку. Якщо кілька відновлених функцій залежать від одного стану, їх ізольоване порівняння залишає відкритим важливе питання. Нам потрібно побачити, як вони працюють разом. Цей урок допоміг нам сформулювати підхід до побудови всієї програми TH095.

Урок, який залишається в моїй голові, корисний, поки я там. Як тільки він стає перевіркою, що можна запустити інший сеанс, він може продовжувати допомагати і після того, як я перейду далі. Наступний агент може використати результат, не повторюючи розслідування, яке призвело до нього.

Помилка, пов'язана з константою з плаваючою комою, також стосується цієї пам'яті. Це пояснює, чому перевірка посилання також вимагає перевірки даних, які стоять за ним. Збереження цього виправлення в коді допомагає подальшим проектам уникнути" сліпої плями " Старої перевірки.

Цей метод стає частиною вихідного матеріалу для наступної гри. У наступному проекті ми можемо витратити більше зусиль, щоб внести щось справді нове у свою мету.

Ті ж переваги доступні для тих, хто приєднається пізніше. Вони можуть переглянути рішення та повторно перевірити його, перш ніж продовжувати роботу. Їм не потрібно відновлювати всю історію проекту, щоб з'ясувати, чому вихідний код виглядає саме так.

TH04: робочий процес функціонує відповідно до іншої архітектури

TH04, Розробник Lotus Land Story, переніс цю роботу в епоху PC-98 для DOS. Тепер метою було 16-розрядне середовище з чотирма взаємодіючими програмами. Для розуміння поведінки апаратного забезпечення були потрібні інші дані, отримані з ігор Windows. Існуючий робота за ReC98 також дала нам цінні знання та вихідні матеріали.

Відновлення DOS зараз працює. Під час мого ручного тестування я відтворив усі звичайні маршрути до їх закінчення та перевірив збереження. В даний час використовується власний 64-розрядний порт. При установці робочої версії DOS спочатку вказується посилання на цей порт.

Архітектура змінила те, що нам потрібно було дослідити. Це також змінило компілятор та час виконання, за допомогою яких ми перевіряли свою роботу. Але агент все-таки міг довести питання до результату і використати цей результат для наступного експерименту.

Розглянемо перехід від ігрового процесу до завершення. Нам потрібно знати, який стан переходить через цю межу і яка програма відповідає за це. Це те, що ми можемо дослідити на прикладі продукту DOS. Як тільки докази та чеки будуть доступні, агент зможе опрацювати питання приблизно так само, як це було з заголовком Windows.

Ось чому TH04 важливий для нашого аргументу. Суттєва зміна платформи не змусила нас почати все спочатку з нового способу роботи. Архітектура визначила проблему; робочий процес все ще давав нам можливість її вирішити.

Що стосується 64-розрядного порту, то тепер ми можемо порівняти нову реалізацію з поведінкою, вже відновленою в DOS. Знання, отримані в результаті реконструкції, дають порту основу для подальшого розвитку.

Стан проекту на 10 жовтня 2026 року: реконструкція DOS та ручне тестування · 64-розрядний порт. Порт знаходиться в розробці.

Від точного коду до читабельного коду

Як тільки реконструкція завершиться, я хочу, щоб хтось інший міг це зрозуміти.

Для мене асемблер і необроблені зміщення здаються старими друзями. Я розумію, що це дещо незвичне визначення слова "читабельний". Більшість людей воліли б слідувати логіці гри, не тримаючи в голові розташування виконуваного файлу в пам'яті.

Саме тут потрібно семантична реконструкція. Відновлене поле все ще може бути відоме в основному з його зміщення. Ми стежимо за тим, як він використовується в грі, поки не зможемо пояснити його роль. Тоді ми можемо дати йому значущу назву та тип, який відповідає доказам. Ми аргументуємо відповідно до джерела, щоб наступна людина могла зрозуміти, звідки походить ця інтерпретація.

Це стає особливо важливим для програмного порту. Абсолютна адреса вказує мені, де щось було у Старому виконуваному файлі. Це мало допомагає 64-розрядної реалізації вирішити, якому об'єкту має належати цей стан. Щоб безпечно змінити поведінку, нам потрібно відновити зв'язок, що стоїть за старим доступом до пам'яті.

Порядок, який я зараз використовую, такий:

1. Відновіть точну базову лінію. Скомпілюйте відновлені фрагменти за допомогою історичного компілятора. Порівняйте відповідний код та дані з оригінальним виконуваним файлом. Запишіть невирішені відмінності, щоб наступний етап мав чітку відправну точку.
2. Створіть і грайте в неї на оригінальній платформі. Об'єднайте ці фрагменти в реальну програму, використовуючи оригінальну архітектуру і компілятор. Використовуйте важливі елементи геймплея. Саме тут ми можемо виявити проблеми із загальним станом або ініціалізацією, які були пропущені при порівнянні ізольованих функцій.
3. Реконструюйте семантику відповідно до обох посилань. Виділіть одну цілісну частину гри за раз і з'ясуйте, що означає Відновлене джерело. Поліпшіть її уявлення, зберігши точні порівняння і відтворювану історичну структуру.
4. Створіть сучасний порт. Перенесіть усталену поведінку в нове середовище, наприклад, у власну 64-розрядну збірку. Реконструйована гра на оригінальній платформі залишається еталоном для порівняння поведінки порту.

Відтворювана збірка, отримана на другому етапі, стає друге посилання для перевірки (oracle) на третьому етапі. Перше посилання для перевірки (oracle) перевіряє, чи все ще наш змінений вихідний код відтворює відповідний вихідний код та дані. Другий перевіряє, що відновлена програма як і раніше будує і поводиться коректно відповідно до обраних нами шляхами.

Вони виявляють різні помилки. Зміна типу може призвести до зміни згенерованих інструкцій. Зміна власника може призвести до того, що дві частини гри використовуватимуть різні копії state. Якщо обидві перевірки будуть доступні, агенту не вдасться провести розслідування, перш ніж проводити подальший рефакторинг.

Назва сама по собі вимагає підтвердження. Точне порівняння не може сказати нам, чи дійсно поле означає "Час невразливості". Ми повинні встановити це по тому, як гра його записує і використовує. Якщо значення залишається невизначеним, нейтральний заголовок буде кориснішим для наступного читача, ніж впевнене припущення.

Ми вивчили цей порядок в ході роботи над проектами. TH08 вже мав доступні для відтворення порти до деяких пізніших перевірок історичних платформ. Це ускладнювало виявлення деяких дефектів. Поточний робочий процес фабрики ставить збірку оригінальної платформи на перше місце, тому semantic work може використовувати її як довідковий матеріал перед початком перенесення.

Точна реконструкція дає нам посилання. Семантична реконструкція дозволяє використовувати відновлені знання. Потім порт може використовувати обидва.

Що робить це промисловим зрушенням

Ці проекти змінили напрямок моєї уваги. Після того, як агенти отримали можливість проводити більшість розслідувань, покращення їх робочого середовища стало однією з найкорисніших речей, які я міг зробити. Більш досконалий інструмент міг би допомогти в будь-якій подальшій роботі, яка його потребувала.

Тут важлива самостійність. Корисний наступний крок часто стає зрозумілим лише після невдалого експерименту. Агенту потрібна достатня свобода, щоб досягти результату в несподіваному місці. Якщо йому доводиться чекати, поки я пропишу кожен крок, більша частина роботи залишається залежною від моєї уваги.

Я очікую, що агент висуне неправильні гіпотези. Важливо те, чи зможемо ми перевірити їх і навчитися з результату. Невдала перевірка повинна допомогти йому зрозуміти помилку досить добре, щоб спробувати ще раз. Мені все ще потрібно вирішити, чи зібрані дані відповідають етапу проекту.

REA надає агенту доступ до інструментів аналізу. Питання про викликає об'єкт функції може привести безпосередньо до перевірки цього викликає об'єкта. Проект реконструкції надає компілятор і свої власні перевірки посилань. Агент може використовувати їх, щоб протестувати запропоноване джерело та перевірити, чи відповідає його пояснення дійсності.

Помилка TH08 показує, чому ці перевірки самі по собі заслуговують на увагу інженерів. Коли одне і те ж порівняння використовується в сотнях функцій, пробіл у ньому може поширитися набагато далі, ніж помилка в одній реалізації. Тестування засобу перевірки покращує зворотний зв'язок, доступний для всієї подальшої роботи.

Промислова аналогія має тут корисний історичний приклад. У 1796 році Боултон і Ватт представили індикатор для парової машини, який допомагав регулювати клапани двигуна. Версія для запису тиску відстежувала хід поршня. Це зробило доступним для контролю внутрішній стан двигуна. Наші інструменти порівняння служать тій же меті: вони дозволяють нам вивчати, що робить обладнання, і одночасно вдосконалювати його.

Ми знаходимося на ранній стадії цього промислового зсуву. Більша частина інфраструктури все ще знаходиться в стадії розробки. Агенти можуть працювати швидше, ніж це передбачено нашими чеками, тому процес повинен розвиватися паралельно з ними. Коли ми виявляємо дефект у загальному інструменті, ми повинні його усунути та переглянути результати, на які він вплинув. Наступний проект може успадкувати більш потужний інструмент.

Також існує практична межа для будь-якого окремого діалогу. Він завершиться до завершення масштабної реконструкції. Сховище вихідного коду повинно забезпечувати можливість продовження наступного сеансу без втрати причини, по якій було прийнято останнє рішення.

Проект Touhou Reconstruction Factory виріс з цієї потреби. Він дає проектам можливість спільно проводити перевірки і витягувати уроки. Робота над однією грою може покращити стартові умови для іншої.

Саме це робить аналогію з промисловістю значущою для мене. Досвід стає частиною інструментів, які можуть використовувати інші. Вдосконалення цих інструментів впливає на те, скільки може зробити наступна людина — або наступний агент.

Проекти, які ми тепер можемо розглянути

Темп важливий, оскільки він змінює рішення про початок роботи. Гра може бути цікавою для реінжинірингу і все одно вимагати від мене більше уваги, ніж я міг би їй приділити. Багато проектів так і залишаться ідеями.

Тепер я бачу спосіб просунути такий проект за допомогою повторних досліджень. Отримання робочої реконструкції робить порт програмного забезпечення більш практичним. Відновлення читабельної семантики полегшує комусь іншому вивчення мода. Зусилля, витрачені на розуміння гри, можуть окупитися після запуску першої версії.

Тепер я дивлюся на незнайому програму і запитую: який доступ, зворотній зв'язок та накопичені знання дозволили б агенту надійно працювати з нею?

Це питання змушує мене замислитися над проектами, які я б раніше залишив у спокої. Кожен з них може покращити наш підхід до наступного. Я хочу продовжувати вивчати, як далеко це може нас завести.

Додаткові статті · Ознайомтеся з дослідженням TH04