ПОГРУЖЕНИЕ В ДЕБРИ: REVERSE ENGINEERING

Как войти в IT? - Наверное с книг, видео, курсов с примерами, начинающихся с "Hello World".

Мой вход был через OllyDbg, где я разбирался, как процессор исполняет инструкции.
Скрин выше — фото доски с моими записями 2017 года из цикла видео Как взламывают игры?.
А я тогда даже не слышал что такое ООП и не мог нормально написать ни одну программу.

Я горел этим и по факту начал изучение программирования с ASM!

И на полном серьезе выбирал, буду я Unity Developer или Reverse Engineer.
Но после анализа вакансий на hh, Леша Reverse умер и родился Алексей Unity 🤣
Выжило только неизмеримое желание лезть в самые сложные темы и разбираться в них!

🔻История, где мне это сильно помогло:
На первом моем коммерческом проекте мы делали клон игры Archero.
Для нас было загадкой, как именно там сделана последовательность уровней.

Кто не играл, коротко:

Одна локация включала в себя линейку из 50 уровней.
Каждый 10ый уровень — босс.
Задача — пройти все уровни и открыть следующую локацию. Видео с геймплеем.

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

Тогда я, почувствовав что смогу найти точный ответ, скачал apk игры и через AssetStudio посмотрел какие именно ресурсы лежат внутри.
Мне удалось узнать что:
🔸Каждая вариация уровня - xml файл
🔸На каждый уровень было по 1-50 вариаций.
🔸Каждый элемент карты был записан в матрицу и имел свой номер. Вода, окружение, препятствия, противники и т.п.
🔸Для каждой карты был прописан % усиления противников от базовых параметров.
🔸На старте генерировался seed карты, который определял вариацию уровня.

Дальше я захотел посмотреть код.
Тогда я взял CPP2IL, скормил ему global-metadata.dat внутри apk и получил сигнатуры всех объектов.
Оттуда удалось узнать:
🔹 Какие данные отправляются в аналитику и примерно когда.
🔹 Как структурированы предметы, персонажи, уровни.
🔹 На сколько их архитектура приспособлена к созданию огромного объема контента.

❤️‍🔥 В итоге множество решений мы взяли себе за основу, что значительно сократило время на поиск правильного решения.

Время прошло, а навыки и знания все равно остаются полезными, т.к. иногда нужно:
🔸 Посмотреть или пропатчить внешнюю dll'ку через DnSpy
Так я исправил баг, который не давал EDM4U создать папку в которой есть точка. Подробности тут.
🔸 Убедиться что ошибка точно не на твоей стороне.
Так можно собрать .exe локально, подключиться debugger'ом через Visual Studio к процессу, скачать symbols нужной UnityPlayer.dll отсюда и получить полный stacktrace ошибки на стороне unity.
Дальше можно через Ghidra или IDA Pro можно поставить breakpoint и посмотреть что где именно что-то ломается.
🔸 Написать свой мониторинг утечек памяти через Mono.Cecil
На текущем проекте, из-за того что повсеместно используется EventManager.Instance.(Add/Remove/Raise)Event, начали появляться плавающие баги.
До перерасхода памяти не дошло, но пару дней на отладку у middle разработчика было потрачено.

🔻К чему это я? Часто слышу вопрос:

Где та грань, когда разработчик начинает разбираться в unsafe и низкоуровневых деталях?

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

А эта статья пример, набор инструментов и ресурсов, которые вы можете использовать в реальной работе чтобы упростить себе жизнь!
Если вы хотите погрузится в мир reverse engeneering'а, рекомендую блог создателя IL2CppInspector, а так же Unity Game Hacking Guide

Сохраняй себе, чтобы не потерять и делись с коллегами 📞
Ставь 👍 если тебе заходит такого рода контент!

@UniArchitect #проект_в_разработке