partoftheworlD

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

Для примера возьмем 2 игры: CSGO и Left 4 Dead 2, в них используется Source Engine, и как можно подумать подсветка должна реализовываться одинаково, но не тут-то было. Давайте взглянем на процесс инициализации предметов (включая игроков) в CSGO: Как можем здесь увидеть для каждого объекта при инициализации резервируется место в структуре подсветки и возвращается ID в этой структуре, который отличный от ID игрока. Внутри GetGlowIndex: Прелести наследования, т.е. есть класс, который наследуется для любых предметов и инициализирует структуру подсветки, даже для обычных занавесок или телевизора. Вот только в L4D2 ничего такого нет, тут все куда более просто или оптимизировано, структура подсветки наследуется только для боссов (танк, курильщик и т.д.) и игроков, а подсветка ведется постоянно нужно лишь изменить уровень прозрачности. А вот структура определяющая подсветку для мобов (обычных зараженных) является динамической из-за чего заполняется только при определенных условиях, это создает некоторые сложности с подсветкой т.к. придется вручную выделять память под каждого моба и заполнять структуру определяющую подсветку, но просто так записав значение по определенным адресам не выйдет из-за подсчета объектов в структуре. Но мы ведь не пальцем деланные, немного пореверсив находим функцию инициализации, правда перед вызовом необходимо получить указатель на моба, это делается с помощью вызова виртуальной функции, которая принимает id и возвращает указатель на структуру. На выходе получаем это:

Начнем с FLIRT(Fast Library Identification and Recognition Technology). Суть технологии проста - экономия времени, вместо ручного восстановления библиотечных функций, используются сигнатурные файлы сгенерированные из статических библиотек с помощью утилит, которые идут в комплексе с IDA SDK, которые по ходу анализа переименовывают функции найденный с помощью сигнатур. Сигнатурный файлы выглядит так: Например, мы знаем, что игра X использует Lua для выполнения скриптов, но сама длл луа вшита в файл, а не идет в комплексе рядом с ним, из-за чего мы не можем увидеть импортируемые функции, а значит придется потратить кучу времени, чтобы вручную по исходникам восстановить их. И тут на помощь приходит FLIRT, подключаем сигнатурный модуль в процесс анализа и буквально через пару секунд функции начинаются помечаться как библиотечные и подписываться. Пока IDA работает, реверсер отдыхает. У GHIDRA есть подобный функционал, но называется Function ID. И чтобы базы для гидры не генерировать руками, есть готовый скрипт, но для начала совету прочитать статью автора, чтобы не было вопросов по использованию скрипта: https://blog.threatrack.de/2019/09/20/ghidra-fid-generator/

lua51_x64.sig

С недавним обновлением Raft в игре изменили радар, теперь необходимо ввести код из 4-х цифр, который является частотой, чтобы радар показал координаты, найти массив с координатами и кодами слишком просто, и поэтому мы будем генерировать коды без какого-либо воздействия на память игры. Открыв dnSpy необходимо найти участок кода, отвечающий за генерацию частот. Восстановив код и запустив для проверки, обнаружились некоторые проблемы: 1. Cид используется 1 раз при создании нового мира. 2. Частота состоит из 4 цифр, из-за чего очень много сидов будет подходить под значение первой частоты, которая дается в начале игры, поэтому придется брутить и генерировать все возможные частоты для 2-4 локаций. На генерацию сидов ушло порядка 30 минут, 90000+ возможных сидов и лишь 1 правильный набор кодов. Занятие было бессмысленным, но это был отличный способ занять вечер. Seed: 1276855 ------------------------------ 9839 1106 5814 8084 ------------------------------

Составление темы в разделе вопросов без вопроса, вот что круто.

Нужно выйти на структуру игрока и смотреть все вложенные структуры минимум в 2-3 уровнях.

Круто

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

Разработка этого плагина началась с того, что Dark Souls 3 начал выеживаться, а именно не работал сканер указателей, в целом этот "плагин" бесполезная, но точная(в теории) вещь для большинства игр. Может быть кто-то более опытный в Lua захочет его доделать. Осталось сделать 3 пункта: Нормальный парсинг инструкций Парсинг...ну что тут сказать, в Lua паттерны это какой-то regex после авиакатастрофы попавший в аварию на машине скорой.

Нужно смотреть на код, как расставляешь и проверяешь доступность hwbp, а так же как отлавливаешь исключения

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

Размер указывается для определенных типов брейкпоинта, чтобы зацепить изменения в адресе, только на запись и на чтение, если брейкпоинт на выполнение, то размер игнорируется. Получение значений регистров через асм вставки не должно было вызвать проблем, но правильнее было бы открыть поток, получить контекст, из контекста выбрать нужные регистры. auto threadID = GetCurrentThreadId(); auto hThread = OpenThread(THREAD_GET_CONTEXT | THREAD_SET_CONTEXT | THREAD_SUSPEND_RESUME | THREAD_QUERY_INFORMATION, FALSE, threadID); CONTEXT ctx = { 0 }; ctx.ContextFlags = CONTEXT_FULL; GetThreadContext(hThread , &ctx);

Все готовые указатели есть в таблице рекласса, начальный класс это CWorldChrManImp, ну или так указатель на здоровье DarkSoulsIII.exe+0x4768e78] +80] +1F90] +18] +D8] Любой, например здоровье.