rikshaspal

Ну а дальше задача уже выглядит совсем привычно: берём HEAP, ищем в нём нужное значение, запоминаем индексы, значение в игре меняется - ищем новое только среди найденных ранее. Обычный Cheat Engine, только вместо памяти процесса у нас массив Javascript. Я написал для этого три маленьких сниппета в консоль. Первый проходил по HEAP и сохранял найденные индексы в localStorage, второй проверял только сохранённые позиции и отбрасывал лишнее, третий показывал, что в итоге осталось. На этом, собственно, всё и должно было закончиться.

Но не закончилось :)

Куда пропал HEAP

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

После некоторого ковыряния выяснилась интересная особенность. Если остановить выполнение игры в отладчике, нужный HEAP обнаруживался в локальных переменных одного из call frames. Пока игра стоит на паузе - вот он, можно спокойно читать. Продолжаем выполнение - привычной ссылки на него уже нет. И вот тут мои три прекрасных сниппета превратились в довольно унылое занятие. Остановить игру в debugger, найти нужный frame, выполнить первый код, снять с паузы, что-нибудь изменить в игре, снова остановить, опять найти HEAP, выполнить следующий код...

Причём в некоторых играх всё это хозяйство ещё и живёт не в основной странице, а во фреймах или вообще в воркерах. Работало, но уже начинало напоминать ручной труд там, где его быть совершенно не должно. Поскольку Chrome умеет всё это делать через Debugger Protocol, следующим логичным шагом было переложить работу на расширение, дабы оно само подключалось к выбранной вкладке, ставило выполнение на паузу, перебирало доступные targets и call frames и искало там HEAPы. Так появилась кнопка Pause & Hunt HEAP и вместе с ней первая более-менее удобная версия того, что я назвал WASM Memory Scanner.

Как этим пользоваться

Если вы когда-нибудь пользовались Cheat Engine или ArtMoney, объяснять особо нечего. Выбираем вкладку с игрой, жмём Pause & Hunt HEAP, после чего расширение пытается найти доступную память WASM.

Дальше вводим значение и делаем First Scan, отпускаем игру через Resume, меняем искомое значение и после следующего Pause & Hunt делаем Next Scan. Повторяем, пока из тысяч результатов не останется что-нибудь вменяемое.

Причём довольно быстро выяснилось, что одного поиска точного значения мало. Поэтому появились Changed/Unchanged, Increased/Decreased, поиск диапазона, изменение на заданную величину и Unknown initial value. Последний полезен, например, когда есть полоска здоровья, но самого числа мы не знаем: запоминаем начальное состояние, получаем урон и оставляем уменьшившиеся значения. Лечимся - оставляем увеличившиеся.

Тут тоже ничего нового, ровно так memory scanners работали последние лет двадцать. Найденные адреса можно складывать в отдельный список, смотреть их текущее значение, записывать новое и при необходимости включать Freeze. Заодно пришлось сделать индикатор прогресса, потому что первый проход по большому HEAP может занять заметное время, а смотреть несколько минут на неподвижное окно и гадать, работает оно или уже всё, оказалось не очень увлекательно.

На чём это работает

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

С такими играми экспериментировать интереснее всего. В серверных всё сильно зависит от архитектуры. Можно найти локальное количество денег, заменить 100 на 999999 и даже увидеть новый результат на WASM Memory Scanner , а при попытке что-нибудь купить сервер вполне резонно сообщит, что денег у нас как было 100, так и осталось.

Мы поменяли представление на клиенте, а настоящее состояние хранится совсем в другом месте. По той же причине я не вижу особого смысла лезть с этим в нормальные сетевые игры. Помимо возможного нарушения правил конкретной игры, там просто значительно меньше интересного: сервер всё равно главный.

А вот старые и новые однопользовательские браузерные игры, всякие Unity WebGL/WASM проекты, эмуляторы, небольшие игры на Emscripten и вообще WASM, в который хочется посмотреть из любопытства - совсем другое дело. Хотя последнее всё-таки с оговоркой: техническая возможность залезть программе в память не означает автоматически разрешение делать это где угодно. Для экспериментов лучше выбирать свои проекты, локальные игры или то, где подобные вещи не запрещены.

В итоге

Самое забавное во всей этой истории, что писать расширение я вообще не собирался. Мне нужны были три маленьких Javascript-сниппета, чтобы один раз проверить одну идею. Потом понадобилось автоматически находить HEAP. Потом выяснилось, что его надо выковыривать из остановленных call frames. Потом нашлись workers. Потом захотелось нормального поиска, прогресса, изменения значений, Freeze и интерфейса, которым можно пользоваться не держа рядом инструкцию.

Ну и в какой-то момент стало очевидно, что сниппеты несколько вышли из-под контроля :) Сейчас это уже вполне самостоятельное расширение для Chrome/Chromium. Всё работает локально, никакого сервера нет, исходники открыты, интерфейс на русском и английском.

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

Ссылка на репу: https://github.com/rikovmike/chrome-wasm-memory-scanner

Если кто-нибудь попробует его на какой-нибудь необычной WASM-игре или движке - интересно будет посмотреть на результаты. Особенно если HEAP там не найдётся вообще...

По сути, инструмент может быть полезен в дебаггинге своих игровых разработок, проверке безопасности и своих античитерских наработок, если ваш мегапроект настолько крут, что его нужно от этого защищать:)

UDP: В 99% случаев достаточно сканировать HEAP32, а на остальные забить. В 64, U32, U64 , да и порой в 16 значения просто отзеркалены из HEAP32. Можно не тратить на них время. Но... 1% все же существует :)

В предыдущей статье мы реализовали довольно неплохой эффект старого рендера из ранних 90х. Однако, ощущения от него будут неполными, если мы не введем другие характерные для того времени ограничения. Нет-нет, 10 фпс и имитацию слабых компьютеров вводить не будем, но постараемся ввести один значимый для ретро-рендера эффект. Возможно он не является частью общей парадигмы, особенно в области рендеринга на РС, но добавит особую атмосферу. Речь идет, конечно же, об эффекте дрожания вершин, характерный для Playstation 1.

Эффект «дрожания вершин» в PlayStation 1, был следствием ограниченной точности расчетов, использовавшихся на этом железе. Поскольку PlayStation 1 использовала фиксированную точку для вычисления координат вершин, это приводило к визуальным артефактам, когда позиции вершин «дрожали» при перемещении камеры или объектов. Мы, как и в прошлый раз, попробуем воссоздать данный эффект только с помощью шейдера в Unity, без использования дополнительных скриптов на C#.

Основная идея простая — нужно будет обойти все доступные шейдеру вершины и округлить их позиции относительно проекционных координат .

Основы шейдера

Напишем заготовку для шейдера, в которой укажем будущие параметры для материалы и объявим структуры и переменные.

Здесь мы задаём два параметра для будущего материала: _MainTex — текстура и _JitterAmount — слайдер для точной настройки силы эффекта дрожания.

Еще нам, конечно же, понадобятся две структуры:

• appdata — данные вершин, передаваемые в вершинный шейдер из Unity

• v2f — данные, передаваемые из вершинного шейдера в пиксельный шейдер и, в конечном итоге, в графический конвейер

Добавим функцию округления позиций вершин. Мы применяем округление только к clipPos.xy, то есть к координатам, которые уже находятся в проекционных координатах (после всех трансформаций объекта). Это даст эффект «дрожания», как на PlayStation 1, когда камера или объект движется. Параметр clipPos будет передаваться в функцию, как и параметр jitterAmount, который позволяет контролировать, насколько сильным будет эффект дрожания.

Округление в clip space означает, что каждая вершина будет «привязана» к определенным фиксированным позициям на экране. При движении камеры или объекта из-за этого квантования вершины будут перескакивать с одного положения на другое, создавая желаемый эффект «дрожания».

Начинаем колдовать

Пишем «вершинный» блок шейдера.

Здесь мы сначала получаем clipPos функцией UnityObjectToClipPos для нашей вершины. Затем получаем новую позицию вершины через вызов написанной ранее функции JitterVertex, которой передаем полученный clipPos и наш параметр _JitterAmount из инспектора.
Возвращаем новые данные вершины. UV-координаты оставляем без изменений.

Параметр _JitterAmount нужно держать в пределах от 0.01 до 0.1, этого достаточно для заметного эффекта. Однако, никто не запрещает эксперименты — все ваших руках.

Осталось только добавить фрагментную (пиксельную) часть, в которой мы просто отдаем текстуру, как есть.

Полный код шейдера лучше посмотреть в репозитории. Выкладывать картинку сюда было бы издевательством )

Настройка текстуры

Шейдер использует стандартную текстуру, которую можно задать в Unity через инспектор. Текстура рендерится через стандартную функцию tex2D, которая отображает текстуру по UV-координатам, переданным из вершинного шейдера. С помощью бегунка _JitterAmount плавно регулируем эффект дрожания. В зависимости от проекта, свойства самой текстуры настраиваются индивидуально, но стилистически, конечно же, желательно выключить фильтрацию и использовать текстуры с небольшим разрешением, вроде 64х64 или 128х128.

На будущее

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

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

Ссылка на github: https://github.com/rikovmike/YetAnotherVertexJitter