partoftheworlD

Обновление: BSWin32KeyboardDevice->gap80[wScanCode + 0xE8] = BSWin32KeyboardDevice->gap1A3[wScanCode + 0xC5]; BSWin32KeyboardDevice->gap1A3[wScanCode + 0xC5] = v12 & 0x80; В коде были 2 строки, они отвечают за структуры, одна из которых обрабатывает состояние клавиш, а в другую пишется это состояние и после копируется в первую структуру для дальнейшей обработки. Для примера возьмем клавишу W её скан код это 11. Дальше пишем во вторую структуру состояние клавиши W (base + 11 + 268) = 0x80 и гг начинает двигаться.

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

игру(Assembly-CSharp.dll) открываешь через dnSpy. ищешь упоминания лески/натяжений/катушки, в классе FishingLine(леска) будет метод UpdateTension(обновление натяжения), теперь необходимо получить адрес значения натяжения, быстро пробежавшись по дизассемблеру и коду в dnSpy можно найти инструкцию, которая работает с натяжением. Дальше ищешь рабочую инструкцию с этим же смещением, если эта не срабатывает. Получаешь адрес значения натяжения Теперь устанавливаешь на этот адрес брейкпоинт на запись, и ждешь пока рыба клюнет: После подсечки появятся еще 4 инструкции, скрипты нужно будет написать на первые 2 с обнулением xmm5. И скрипт

Это? Если да, тогда табличку кину.

Если справка выводится локальная - удалить её, если вызывает URL с инфой, то сломать ShellExecute внутри CE Эти функции патчишь ret и больше никакой справки cheatengine-i386 : 55 89 E5 8D 64 24 C8 53 56 57 66 89 D6 cheatengine-x86_64: 55 48 89 E5 48 8D 64 24 ? 48 89 5D C8 48 89 7D D0 48 89 75 D8 66 89 D3 Можно и от F1 отвязку сделать, но мне лень, патч по идее должен сработать.

HexRaysCodeXplorer.7z

Основными методами нахождения обработчика нажатий являются поиск(и заморозка потоков для проверки, просто потому, что всегда у обработчика свой поток) и поиск изменяющегося значения при нажатии на клавишу. Так или иначе, оба этих способа приведут нас к тому, что игра использует DirectInput или XInput, выбор метода зависит от специфики игры и личного опыта. Из инструментов для этого лучше всего подойдет x64dbg. Приступим к поиску с вкладки Threads и что мы видим, один из потоков был создан из dinput8. И раз мы нашли поток, то можем обратиться к базовому адресу потока, таким образом попадаем в тело метода CEm_LL_ThreadProc. Теперь поставим на этот метод брейкпоинт и перезапустим игру. Посмотрим, откуда происходит создание потока. После перезапуска игры и срабатывания бряка, в стеке вызовов получаем все, что необходимо для продолжения поиска: Пробежав быстро по стеку вызовов, находим интересную апишку MapVirtualKeyA выйдя из метода, которая переводит скан-код в код виртуальной клавиши. Ну что ж, теперь мы знаем где работает обработчик нажатий Directinput, где он переводится, остался последний шаг - узнать, где нажатая нами клавиша используется, это как раз и будет сам обработчик нажатий. На этом этапе уже будет удобней исследовать код в IDA/GHIDRA, поэтому перейдем к ним, оставив отладчик подключенным к процессу. Немного восстановлю код для наглядности:

CreateRemoteThread/CreateRemoteThreadEx?

Ищи редакторы на форумах мододелов, либо пиши свой редактор на основе функций игры, иначе никак.

Всем чем угодно, от перехвата трафика твоего 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 ------------------------------