KRYPTOPUNK

Так в программе разные типы памяти. RAW DATA( или глобальные данные), стек и куча. вот твой указатель и есть глобальные данные, которые хранятся непосредственно в exe-шнике.

Чаще всего "направление" это "поворот", так что это почти всегда вектор или кватернионы. Потому что камера почти всегда логический объект, который так же имеет позицию и поворот. Если они заданы как два угла, допустим, как в движке Source, то вообще все намного легче искать, но эти углы нужно будет рассчитывать, если захочешь напрямую манипулировать камерой. К сожалению, у меня нет времени, так как основная работа есть, да и C# я не люблю и не пишу на нём.

Так это же в Cheat Engine можно найти, а отличия искать уже в каком нибудь ReClass или в инспекторе структур Cheat Engine. Отличие по Z -- наша камера.

Тогда можно предположить, что вращение камеры равно вращению персонажа? Если камера стоит за спиной персонажа, то они могут смотреть в одном направлении.

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

У тебя не может быть погрешность примерно +- 1 пиксель, потому что каст к инту может отбросить только с одной стороны .9, так что глупо так считать. Если ты пишешь на C#, я так понимаю, у тебя игра на Юнити. В этом случае есть штука, которая называется Camera.worldToCameraMatrix, которая отдаст тебе матрицу трансформирования мировых координат в координаты камеры. Однако, там есть сноска о которой нужно помнить.

Ты бы хоть сказал, left-handed или right-handed координатная система, и что ты кодом делаешь. Что за 250.0f? Ты спрашиваешь, как найти координаты цели, но говоришь, что они известны. В общем, подробнее объясни, что происходит и что ты делаешь

Берешь GHIDRA, дизассемблируешь, ищешь необходимые строки, смотришь их адрес, и ищешь в памяти указатели на эти строки. Потом отладчиком смотришь, кто читает эти строки.

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

Нет, это над-движковая система для проектирования UI в 3д мире. Нет, и вряд ли будет, ибо NDA

У меня есть система UI, которая считает свои размеры относительно родительского "окна" в процентах на каждом "эвенте" OnResize Правда там система скорее как в вебе, где отношения размеров "родитель"->"потомок" указывается в процентном соотношении. Так вот, на каждый ресайз вызывается OnResize для каждого элемента системы и он пересчитывает свои размеры на основе размеров родителя и своих отступов от границ родительского окна. Удобно, достаточно, и не сильно сложно по big-O. И да, там уже можно не строить дерево руками, а у каждого элемента просто хранить вектор с детьми проходясь range-based циклом

IntelliSence не всегда показывает то, что получится в итоге. Он очень легко ломается, допустим, шаблонами. Или такой вот конструкцией. Зачем тебе в конструкторе класса может понадобиться получить значение из поля объекта? Не нужно так делать. Можешь глянуть тот же гугловский гаедлайн на тему кодстайла. И вообще, без разницы, как ты параметры назовёшь, ты их можешь вообще никак не называть) А для избегания путаницы, можно делать так Учитывая твой пример с огромным количеством аргументов, проще структуру сделать, и передавать её через move-семантику. и никаких проблем с неймингом.

Компиляторы достаточно умные сейчас. Даже если я напишу так: никаких проблем не будет.

Экранная клавиатура) Сам так делаю ?

Да, конечно, DLL инжектить надо. Не думал, что это нужно проговаривать, извини.

Собери dll в дебаг сборке, подключись к процессу отладчиком Visual Studio. Профит.

Код оберни в "код". Кнопка специальная есть, выглядит как <>

Скинь полный код под спойлером и где конкретно ты ловишь инструкции

Предисловие: Я хотел сделать эту статью сообщением под статьей пользователя roma912, но потом решил вынести её отдельно, так как здесь мы будем описывать новую версию движка и более конкретно описывать те или иные действия. Использовать мы будем тот-же SDK GEN, что и в его статье, но здесь мы рассмотрим ситуацию, когда игр, нам нужных для разбора нет в пресетах (как чаще всего и бывает), и будем искать всеми нужные GNames и GObjects, ручками. Для этого нам понадобятся инструменты. Из обязательных: GHIDRA/IDA, Cheat Engine, ReClass. Опционально: исходный код Unreal Engine конкретной версии, как его получить, смотрите здесь -- https://github.com/EpicGames/Signup, также сам движок подходящий по версии с вашей игрой. Что есть звери эти? Для того, чтобы понять, как искать эти самые GNames и GObjects, нужно понять, что они из себя представляют. Важно понимать, что в Unreal Engine 4 используется в основном язык C++, так что этот движок образный «ООП на стероидах». В нем используется сложная система наследования, практически каждый тип данных заменен на свой, с добавлением приставки “U”, такие как «UField», «UObject», «UArray», именно поэтому в нем будет разобраться не просто, даже имея исходный код на руках. Начнем с GObjects. Что это такое? Судя по названию, можно предположить, что это глобальная переменная, в которой хранятся все объекты. Это отчасти верно, однако даже поиск по исходному коду движка этого названия нам ничего не даст. Нужно подумать, объектом какого класса может быть эта переменная. Достаточно длительный разбор исходного кода движка приводит нас к следующей картине: в файле UObjectArray.h есть класс с названием «class COREUOBJECT_API FUObjectArray». Звучит интересно. Смотрим в его приватные поля и видим Интересующий нас объект называется ObjObjects. Теперь посмотрим его класс. Объявление его класса находится в том же файле выше. Не забываем про typedef и ищем класс «FFixedUObjectArray». В его приватных полях находим Это то, что нужно! В итоге логика выглядит так: FUObjectArray.ObjObjects->Objects В файле UObjectHash.cpp находим использование этого класса в играх Как видно, это статическая переменная, содержащая в себе класс «массив», который в свою очередь хранит в себе указатель на массив всех объектов в игре. Такие дела. Примечание: на многих источниках этот объект указывают как TArray<Object*>, что не совсем корректно для более поздних движков. GNames. Не буду долго распинаться, поэтому скажу в общих чертах: GNames так же статичная переменная, используемая для хранения имен всех объектов в игре. Имеет тип TNameEntryArray, что является typedef’ом от TStaticIndirectArrayThreadSafeRead<FNameEntry, 4 * 1024 * 1024, 16384> Больший интерес представляет сам класс FNameEntry, который и является классом хранения имени. Выглядит он так: Именно m_ansi нас и интересует. Розыскные мероприятия. Мы знаем, что переменные GUObjectArray и Names, статические, значит, для целей их розыска и поимки, мы можем использовать GHIRA/IDA. Дизассемблируем программу, ждем конца автоанализа. Сейчас я расскажу, как действовать, если вы решили пойти по хитрому пути и скачать движок Unreal Engine версии, совпадающей с исследуемой игрой. Заходим в EGS-> Unreal Engine -> Библиотека. Потому нажимаем на + возле Версии Unreal Engine Выбираете версию движка, нажимаете установить. ВАЖНЫЙ МОМЕНТ! Заходите в настройки установки и отмечаете галочкой эту строку Для того, чтобы потом можно было генерировать .pdb. Когда скачали, запускайте и создавайте новый проект. Желательно выбирать жанр, который совпадает с вашей исследуемой игрой. Ждем загрузки… Далее кликаем File -> Package Project -> Build Configuration -> Shipping Далее File -> Package Project -> Packaging Settings И отмечаем галочку «Include Debug Files» И, время компилировать! File -> Package Project -> Windows -> и выбираем разрядность игры, которую исследуем. Зачем это нужно? Открываем GHIDRA/IDA, пихаем туда нашу скомпилированную игру и грузим .pdb ВНИМАНИЕ: В ГИДРЕ ОТКАЗЫВАЕМСЯ ОТ АВТОАНАЛИЗА И ЗАГРУЖАЕМ .PDB ДО НЕГО! Теперь у нас есть листинг, где мы можем найти все подписанные функции движка. Выглядит это так: Вот, собственно, и всё. Теперь можно просто по паттерну искать функции в нашей исследуемой игре. Для поиска GNames нам понадобиться метод FName::GetNames() Для GObjects GUObjectArray() Подсказка: при поиске по паттерну, может быть очень много похожих функций. Ориентируйтесь на количество аргументов и тип возвращаемого значения. Также можно использовать(«абьюзить») строки, но об этом в другой раз. Зачем ReClass? К сожалению, мы с вами будем работать через SDK генератор, который обновлялся последний раз пять лет назад. А вот Epic Games обновляют движок игры примерно раз в полгода. Поэтому, нам нужно будет ручками реверсить классы в движке, и заносить результаты в отдельный файл. Так же никто не отменял, что некоторые компании изменяют движок под свои нужны и могут использовать кастомные типы данных. Поэтому, всё же, нужно будет знать объявление классов для того, чтобы SDK генератор работал правильно. Брать эти объявления можно из исходников движка, а через ReClass подтверждать, что они указаны верно для конкретно вашей игры. Послесловие. Все сказанное выше актуально только для Unreal Engine версии ниже 4.22, так как в версиях выше для GNames используется класс FNameEntryPool, который работает совершенно по-другому. Спасибо за чтение и удачи в исследованиях!

Ты как там свой инжектор писать собрался? А главное написал, судя опять же по тобою сказанному. Мне кажется, ты голову морочишь.

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

https://github.com/KRYPTOPUNK/RiskOfRain2_hack Вот. Смотри. Это исходный код моего трейнера для Risk Of Rain 2.

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

Самый простой способ, как назвали выше, это CreateRemoteThread с LoadLibrary и путем к твоей длл. Я не понимаю смысла в ресурсах экзешника держать DLL. Зачем? Информация про DLL и хуки есть здесь. Если того, что здесь не хватает, гугли сайты. Правда один из хороших закрыли paywall'ом не понятно зачем, но не суть. Информация в основном на английском, но интуитивно понятно. Если конкретно по книгам то Джеффри Рихтер "Windows для профессионалов", начиная с главы 19. Если хочешь античиты обходить, то меньше чем мануал маппинг делать не выйдет. А это самому загружать, производить релокацию, импорты фиксить, вызывать TLS'ы и прочее. Ибо более менее нормальные античиты в основном ставят хуки на довольно глубокие штуки, такие как LdrLoadDll, LdrpLoadDll, даже на RtlInitUnicodeString некоторые ставят. При том, что мы имеем дело не с ring0 античитом.

Посмотри мои работы, которые я здесь выкладывал. Не бог весть что, не идеал, но как концепт понять можно.