TAS_Reverse_Engineering_stillgoing

%%TOC%%

''"Искусство ТАС стало чем-то большим, нежели просто играть в игру. ТАСинг сделался игрой сам, и даже это порой затмевается уже созданием того, что еще и играет в игру за вас. Это, своего рода, метаигра. Ее лучшие игроки знают, как нарушить все правила, что ведет к необходимости глубокого понимания как архитектуры, особенностей игры, так и инструментов для взаимодействия с ней."'' ? [=forum/p/389519#389519|ТРУЪ].

!! Предисловие

[https://ru.wikipedia.org/wiki/%D0%9E%D0%B1%D1%80%D0%B0%D1%82%D0%BD%D0%B0%D1%8F_%D1%80%D0%B0%D0%B7%D1%80%D0%B0%D0%B1%D0%BE%D1%82%D0%BA%D0%B0|Обратной разработкой] называется процесс исследования технического устройства прибора, объекта или системы посредством анализа его/ее строения, функций и поведения. Часто это включает в себя разбор чего-то (механического или электронного устройства, компьютерной программы, биологических, химических или органических материй) на части с дальнейшим анализом их работы в отдельности с целью ремонта, или создания нового устройства или программы с аналогичными функциями без использования или прямого копирования (без понимания) оригинала.

В старые ламповые времена, создание ТАС сводилось к экспериментам над игрой в попытках пройти ее неизвестным доселе способом. Это было довольно ново, и потому работало. Но приходили все новые люди, делались ТАС по все новым играм, старые прохождения постоянно сменялись новыми, а сообщество в итоге развило новый стандарт ТАСинга, на порядок более эффективный. Этот естественный процесс был обусловлен двумя основными причинами:
* Уровень оптимизации постоянно возрастал, обнаруживались и применялись новые трюки, улучшались старые.
* Развлечь зрителей становилось все сложнее, коль скоро за годы они повидали уже столько всего, что ТАСеры были вынуждены искать новые необычные идеи.

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

Данное руководство ставит себе целью научить читателя методам простым и эффективным, которые можно применять к подавляющему большинству игр. Единственной проблемой может оказаться отсутствие нужных инструментов в некоторых эмуляторах.

''Примечание: настоящее руководство изложено в контексте наиболее мощного в части обратной разработки эмулятора - FCEUX. Однако, опыт, полученный с его помощью, может быть эффективно применен в отношении любых других платформ/эмуляторов, для которых существуют аналогичные приспособления.''

!! Области памяти (RAM)

''Примечание: Используйте встроенный во FCEUX шестнадцатеричный редактор, чтобы обозревать память RAM в ходе игры. Команда меню "Debug -> Hex Editor". Также будет полезно сразу отрегулировать размер окна, чтобы единовременно отображалось 16 строк (1 страница памяти).''

В диапазоне адресов от $0000 до $00FF располагается нулевая страница, или Zero Page. Игры размещают там временные переменные, которые очень часто меняются, или те, к которым необходим самый быстрый доступ; очень часто одни и те же адреса в пределах Zero Page отражают значения массы несвязанных между собой переменных из основной памяти. В связи с чем эти самые адреса, пусть даже если в них можно стабильно находить реальные данные, все равно не надежны. Необходимо искать реальные адреса, где на самом деле хранятся данные о состоянии RAM игры, и которые не перетираются посторонней информацией.

В диапазоне $0100 - $01FF располагается Стек, который также используется для данных временного характера.

Третья страница часто отводится под данные о спрайтах, что можно заметить, наблюдая, как там меняются значения.

А вот дальше уже идут настоящие данные об игровом процессе, из которых можно многое узнать. Существует ряд довольно типичных способов размещения этих данных. Не считая всяких особо хитрых счетчиков и прочего, практически каждая игра хранит состояние объектов в массивах или чем-то подобном.

!! Объекты

Термин говорит сам за себя. Реализованные в игре сущности, взаимодействующие друг с другом или окружением, принято называть объектами. Как правило, все они обладают неким общим набором атрибутов. Для их хранения можно организовать виртуальную таблицу, где сами объекты будут представлены рядами, а их атрибуты - столбцами. Если вы разберетесь в адресах, соответствующих атрибутам тех или иных объектов, то матрица откроет вам свои тайны.

Вышеназванная гипотетическая таблица не так уж далека от того, как объекты на самом деле размещаются в памяти. Начинаться сия структура может с массива идентификаторов объектов, располагающихся в некотором наборе свободных слотов. Потом - массив из идентификаторов спрайтов для них. А может - какой нибудь номер состояния объекта, от которого зависит его поведение. И в дополнение ко всему - пространственные координаты, обычно из 2-3 переменных каждая. Типичный набор таков:
* X - младший байт
* X - старший байт
* X - субпиксельная позиция
* Y - младший байт
* Y - старший байт
* Y - субпиксельная позиция
Порой имеется и координата по оси Z. Также ситуация может различаться в зависимости от того, является ваш персонаж элементом общей карты размещения объектов, или обладает уникальными аттрибутами, адресуемыми отдельно.

Какие-то игры отслеживают положение объектов по абсолютным координатам в рамках уровня. А какие-то - чисто в зависимости от положения игровой камеры. Координаты X и Y для камеры тоже могут занимать по паре байт и обычно хранятся отдельно от основного массива объектов. Это иногда позволяет получить истинное положение объекта на экране путем вычитания абсолютных координат из координат камеры. А некоторые игры просто хранят данные о положении на экране отдельно, но такие данные ненадежны.

Часто можно найти и другие атрибуты, такие, как скорость, направление, и так далее. Какие-то вам не понадобятся, какие-то может оказаться трудно интерпретировать.

Вам потребуется определить, что - ряды, а что - колонки. Некоторые игры представляют слоты в виде колонок, а атрибуты располагают рядами. А некоторые хранят атрибуты сразу за идентификатором, тем самым делая ряды слотами, а атрибуты строя в колонки. Бывает еще так, что игра специально форматирует таблицу на манер того, как показывает данные HEX-редактор, к примеру, резервируя 8 или 16 слотов под объекты, или давая каждому из них до 16 атрибутов. Такую таблицу объектов можно наблюдать невооруженным глазом.

Разобравшись с назначением отдельных частей таблицы,вам уже нет нужды искать атрибуты вручную, достаточно наблюдать изменения в ячейках памяти и делать выводы об их реальном назначении, например:
* Младший байт для X координаты растет от 0 до 255 и снова сбрасывается в 0, увеличивая старший байт.
* Координата X для позиции на экране замирает, когда персонаж достигает точки, где экран начинает прокручиваться вслед за ним.
* Очки здоровья уменьшаются при получении объектом урона (хотя иногда наоборот - полученный урон аккумулируется на счетчике).
* Скорость часто также представляет направление (принимая положительные или отрицательные значения) и меняется при ускорении.
* Субпиксельные позиции интенсивно меняются, когда скорость растет или уменьшается, замирают или колеблются между парой значений, когда скорость постоянна.
* Идентификатор объекта появляется в слоте вместе вводом объекта в игру и не обнуляется, пока последний не исчезнет.
* Значения таймеров уменьшаются или увеличиваются на один до наступления определенного момента, и иногда можно увидеть, наступление каких событий отслеживается.

Какие-то игры реализуют боссов, как обычные объекты, а какие-то хранят их атрибуты отдельно от прочих. Вам потребуется найти их: очки здоровья, таймер неуязвимости, позиция, состояние/направление движения. Это позволит понять их действия и найти способ их контролировать, или, по меньшей мере, отслеживать.

!! Генераторы случайных чисел.

Разобраться в причинах возникновения какого-то конкретного события не так уж сложно. Однако, для этого нужно будет пользоваться отладчиком, ставить точки останова, равно, как и выводить исполненный код в файл или окно (иными словами, делать дамп).

Для начала, следует определить для себя некий видимый параметр, который изменяется, а вы хотите это контролировать. К примеру, конкретный кадр, на котором противник предпримет атаку. Или тип этой атаки. И место появления какого-то объекта. В общем, любой фактор, который выглядит случайным и меняется в зависимости от вашего поведения в игре.

После этого надо найти адрес, по которому хранится значение этого параметра. В этом нам помогут инструменты поиска в RAM (RAM Search tool), которые позволят найти адреса переменных, которые меняются в точности, когда и искомый видимый параметр.

Затем ставится точка останова на событие Записи по найденному адресу. Запускается мувик, в котором меняется искомый параметр. Важно знать, как часто происходит его запись. В большинстве случаев точка останова будет срабатывать лишь раз в некоторый промежуток времени (скажем, раз в несколько секунд). А записанное значение равняется тому, что вы впоследствии видите в RAM. Номер кадра, на котором происходит запись следует как-то записать, например, в текстовом файле, или сохранить состояние игры непосредственно перед ним.

После этого надо вывести в файл код, выполняющийся непосредственно перед срабатыванием точки останова. Во многих случаях логов за лишь один кадр, где это произошло, достаточно. Однако, если точка останова срабатывала много раз за кадр, обязательно убедитесь, что в лог попали они все. Хорошо может сказаться и привычка пройти несколько "шагов вглубь" вслед за последним срабатыванием, чтобы захватить весь вовлеченный в событие код. Читать его во время выполнения не так уж полезно. А вот чтение дампа покажет вам, откуда взялось значение, записанное по наблюдаемому адресу. Обычно оно бывает:
* Скопировано как есть из ROM.
* Скопировано как есть с другого адреса в RAM.
* Результат какого-то взаимодействия с другой или несколькими другими переменными.

В первом случае, вам потребуется найти условие, при котором игра выполняет переход на данную позицию в коде и пишет это значение. Если переход будет сделан в другое место, записанное значение тоже будет другим.

В двух других случаях, вам нужно будет найти, откуда берется результирующее значение. Если оно копируется напрямую с другого адреса, установите точку останова на запись туда, и ищите, откуда берется то значение (точка останова может активироваться не единожды, прежде чем там окажется конечное значение, в таком случае надо обращать внимание на последний раз, в который было установлено значение, попавшее по наблюдаемому вами адресу). Если имел место какой-то алгоритм с участием значений по сторонним адресам, вам потребуется отладить его все разы, получая разный результат для каждого различного набора исходных значений.

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

Иными словами, для поиска причин вы будете раз за разом отматывать время назад. И наконец, наотлаживав и натрассировав достаточно, придете к четкому пониманию, как себя ведет искомый псевдослучайный параметр. Можно будет даже написать аналогичный алгоритм на LUA, и с его помощью предсказывать будущие значения в зависимости от игровой ситуации. И, самое главное, у вас появится возможность влиять на псевдослучайные исходные факторы, определяющие искомый параметр, тем самым эффективно контролируя его. А может наоборот, узнаете, что он нисколько не случаен, и им нельзя манипулировать без существенного проигрыша по скорости. В конечном счете, в этом заключается самая интересная головоломка!

''Замечание: Некоторые эмуляторы поддерживают использование при отладке и трассировке информации об отладочных символах. Это - ужасно полезная вещь, позволяющая заменить нужные вам адреса на на понятные вам слова. В результате, в коде будут фигурировать не безликие цифры, а осмысленные названия, отражающие назначение упоминаемых адресов.''

!! Ссылки

* http://www.6502.org/tutorials/6502opcodes.html
* http://wiki.nesdev.com/w/index.php/Nesdev_Wiki
* http://en.wikibooks.org/wiki/Super_NES_Programming
* http://forums.nesdev.com/viewtopic.php?t=5528
* http://www.romhacking.net/utilities/749/
* http://gendev.spritesmind.net/page-home.html
* http://problemkaputt.de/gbatek.htm
* http://gbadev.org/docs.php

* http://www.fceux.com/web/help/HexEditor.html
* http://www.fceux.com/web/help/fceux.html?Debugger.html
* http://www.fceux.com/web/help/fceux.html?TraceLogger.html
* http://www.fceux.com/web/help/NESRAMMappingFindingValues.html

!! Эмуляторы

|| Эмулятор || Платформа || Инструменты ||
| [http://www.fceux.com/|FCEUX] | NES/FDS | - Отладчик%%% - Трассировщик кода%%% - HEX-редактор%%% - Функции отладки LUA |
| [BizHawk] | Несколько | - Трассировщик кода%%% - HEX-редактор |
| [http://code.google.com/p/vba-rerecording/|VisualBoyAdvance] | GBx/GBA | - Дизассемблер%%% - Трассировщик кода%%% - HEX-редактор |
| [http://desmume.org/|DeSmuME] | NDS | - GDB Stub%%% - Дизассемблер%%% - HEX-редактор |
| [lsnes] | SNES | - Disassembler%%% - Трассировщик кода%%% - HEX-редактор%%% - Функции отладки LUA |
| [http://psxemulator.gazaxian.com/|pSX] | PSX | - Отладчик%%% - HEX-редактор |
| [http://problemkaputt.de/index.htm|nocash emulators] | Несколько | - Отладчик%%% - Трассировщик кода%%% - HEX-редактор%%% |
| [http://aamirm.hacking-cult.org/www/regen.html|Regen D] | Genesis/GG/SMS | - Отладчик%%% - HEX-редактор%%% |
| [http://code.google.com/p/gens-rerecording/downloads/list|Gens-rr] | Genesis/SegaCD/32X | - Трассировщик кода%%% |
| [http://elektropage.ru/publ/programmy_dlja_romkhakinga/ehmuljatory/gens_11_r57shell_mod/38-1-0-122|Gens-rr r57shell mod] | Genesis/SegaCD/32X | - Отладчики%%% - Трассировщик кода%%% - HEX-редактор%%% |

----

''[TODO]'': Add cases that contradict this guide..%%%
''[TODO]'': Expand this guide with details..%%%