keng

И какой в этом смысл? Сначала увеличиваем значение регистра, потом затираем другим.

Я подумал, что этот пост будет полезно увидеть ещё кому-нибудь:

Ну как, лично у меня программа свою основную функцию (поиск адресов) вообще по факту не выполняет, зато мне интерфейс очень понравился. Что до функционала - вряд ли сейчас есть что-то, превосходящее по возможностям CE + Olly + IDA, так что допиливать можно очень долго.

Ну вот. Штука в том, что как раз эта самая защита и мешает артмане и другим сканерам находить нужные адреса, т.к. "портит" память игры с их точки зрения. Как с этим бороться? Снимать защиту.

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

Как вариант, попробовать можно, но я думаю что защиты просто закатывают истерику в том случае, если память процесса, который они охраняют, начинает кто-то модифицировать. А кто и зачем - это их мало волнует. Тот же Outpost (фаервол который) начинает считать программу трояном, если она записывает в чужой процесс N-ое количество байт. Для ольки, например, да и для софтайса, была кучка приблуд, прячущих всячески отладчик и вообще его присутствие в системе. Самая клёвая тема - это повесить хуки на некоторые функции винды, в результате чего можно вообще напрочь спрятать процесс и сам факт его пребывания в системе от этой самой системы. Но это - долго и сложно.

№25, и в эту тоже, т.к. обе игры явно наделены какой-то защитой. №24, это скорее программный уровень, т.е. права пользователя\администратора тут слегка ни при чём, т.к. мы, проще говоря, мешаем винде и её программам работать так, как они были изначально спроектированы. Трейнеры по своей природе в чём-то напоминают компьютерные вирусы, а сканеры памяти вроде артмани и прочие инструменты не слишком далеко от них ушли. Плюс ко всему, сами разработчики стараются всячески бороться с такого рода явлениями, усложняя нам жизнь. Снятие защиты подчас бывает достаточно сложным и трудоёмким делом, так что да - разговор для отдельной темы.

Мне бы хотелось написать очередную простыню, но я не знаю даже как лучше подступиться. Но попробую: Артманя (как и любой другой сканер памяти) работает таким образом, что ей необходимо подключиться к чужому процессу (процессу игры), получить доступ к адресному пространству этого процесса (по сути, куску оперативной памяти, который ему выделила Windows и в котором он хранит все свои данные) и суметь прочитать его, опираясь на некоторые условия поиска. Выглядит это похоже на дикую кучу карманов, где пользователь при поиске задаёт вещь, карман с которой ему нужно найти. Артманя пробегается по всем "карманам" памяти игры и находит карман с нужной вещью. Или не находит, если таковой ни в одном нету. Проблема заключается в том, что в Windows вся эта штука с карманами и памятью спроектирована так, чтобы отдельные программы друг другу не мешали, в чужие данные не лезли и (по возможности) вообще о существовании соседей не подозревали. Этот момент можно легко решить, вежливо Windows попросив выдать нужные права. Но вот сама программа тоже можно не любить (и очень сильно), если кто-то извне лезет в её память и заставляет её работать не так, как ей самой изначально надо. В самом простом варианте она будет периодически проверять, все ли её данные на месте и они правильные и не подключился ли к ней какой-то чужой процесс. Если вдруг что не так - она может принять какие-то меры, вплоть до объявления войны блокировки каких-то пользовательских данных (сохранений, текущего прогресса прохождения и т.д.). Вот, как-то так. Не буду в дебри лезть, но это сильно похоже на вирусы и антивирусы - вирусы лезут в систему и её портят, а антивирусы следят за тем чтобы у них ничего не получилось. Снимаются эти вот защиты довольно индивидуальным способом и одной артманей тут не обойтись, так что в рамки конкретно этой простыни это не входит.

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

Short-прыжки не катят, т.к. они вроде бы работают в пределах +\-127 байт от текущего адреса, а уменя это может быть и миллион байт - бинарники нынче жирные. В этом случае можно сэкономить при помощи финта ушами: push 0х123 ret В итоге это будет эквивалентно команде: jmp 0x123 Но jmp занимает 5 байт, а вот jmp+ret - 2 байта!

Чуток обновил шапку темы, да. Ещё немного материала.

Во, спасибо. Классический code cave выглядит примерно вот так: В игровом коде: jmp CaveAddress nop (балансировка опкодов в случае разной длины инструкций) CaveAddress: *какой-то наш код* jmp ToGameCode Плюс такого способа в том, что команда jmp не использует стек для хранения адреса возврата - она, скажем так, просто прыгает и всё. Минусов я лично вижу аж пару - во-первых, оба адреса нужно считать (т.к. адрес возврата должен учитывать количество сбалансированных опкодов), во-вторых - команда jmp занимает 4 байта (если не ошибаюсь). Из неё можно возвращаться и через ret, но для ret нужно засунуть в стек адрес возврата, который будет на 4 байта позже адреса входа. Типа такого: В игровом коде: jmp CaveAddress nop ;(балансировка опкодов) CaveAddress: *какой-то наш код* push CaveAddress+5 ;(кладём в стек адрес возврата = адрес jmp to + по 1 байту на каждый сбалансированный опкод) ret ;(ret возвращается на адрес из стека) Тут фишечка в том, что ret занимает то ли 1 то ли 2 байта, но об этом чуть ниже. Соответственно, можно использовать и обратный вариант (jmp вместо ret): pop eax ;Вытаскиваем из стека адрес возврата jmp eax ;Прыгаем на него, как будто это ret Но самое крутое в том, что так как после записи инъекции мы уже в игровой памяти, то мы можем использовать связку call-ret: Игровой код: call CodeCave nop CodeCave: *наш код* ret Ничего со стеком в этом случае делать не нужно - команда call автоматически кладёт в него адрес возврата. Плюсы в том, что посчитать нужно только один адрес (куда переходить), и места этот код займёт меньше.

Апдейт! Вторую проблему я решил. Почитав документацию, вспомнилось, что можно прыгать не только на метку, но и на адрес. Вот пример: beep: ;Метка invoke Beep,500,200 ;Играем звук высотой в 500 Гц и длительностью в 200 мсек jmp beep ;Прыгаем обратно на метку После компиляции метка заменится адресом вида 0x12345, с которого будет начинаться команда воспроизведения звука и в итоге мы будем рекурсивно прыгать и выполнять одну и ту же команду. Проблема может возникнуть в том случае, если компилятора у нас нет, а нужно записать такую конструкцию в память. Зная, что команда invoke Beep,500,200 занимает 10 байт (можно посмотреть в дизассемблере), мы можем переписать этот участок следующим образом: invoke Beep,500,200 ;Играем звук jmp $-15 ;Прыгаем на 15 байт назад относительно текущего адреса Значок $ нужен затем, чтобы прыгать именно на адрес раньше 15-ти байт команды jmp, т.к. сама команда так же занимает 5 байт. Получается, что прыгаем мы на начало команды invoke. Само собой, этот способ работает и с командами условного перехода. Первый вопрос остаётся открытым.

Кто-нибудь мне может внятно разъяснить разницу между: call 0x123 0x123: ... ret и jmp 0x123 0x123: ... ret (jmp?) Помимо того, что jmp не трогает стек и если использовать jmp-ret, то надо адрес возврата ручками подгонять. Пока что я заметил разницу только в том, что ret жрёт на 4 байта меньше, чем jmp. call-ret у меня отлично работают, но должна же разница быть. Роюсь в документации, но вдруг кто знает. И второе. Есть, скажем, такой кусок кода: pushad xor esi, esi xor edi, edi [b]loop:[/b] mov dword ptr [esi+0x499434], 0 lea esi, dword ptr [esi+0x98] inc edi cmp edi, 0x12c [b]jne loop[/b] popad Каким образом можно избавиться от метки? Да, есть команда loop, есть movsb, но они так и так требуют для работы наличие метки. Или её можно заменить относительным адресом? Можно ли без использования меток организовать переходы по коду? Типа: push 0x1212 ret Вот, как-то так.

Конечно, но в этом случае форма просто появится с такой-то прозрачностью, а в примере показано как её менять динамически с течением времени.

Плюсую, занимательно, но вот зашёл на сайт и увидел в разделе "О нас" строчку: Как-то это не круто.

Комментировал код изо всех сил, для работы приложение потребует .NET Framework 3.5. Вопросы и замечания - в студию. WindowsFormsApplication2.zip

Так это, я вроде так и написал - не "Вопросы по созданию трейнеров", а "Информация по созданию трейнеров". Misunderstanding получилось.

Круто! Можешь, кстати, чуть подробнее написать, почему мы берём не всю цепочку байт для инъекции - вдруг кому непонятно. PS: Очень рекомендую скачать и поставить чудо-прогу под названием Resharper (если ещё нету) - сильно поможет писать код лучше\быстрее.

Этот плагин висит на официальном сайте Оли, да и в комплекте вместе с 1.10 идёт.

Спасибо, вроде бы - то, что надо. Попробую как можно в более легкоусваиваемой форме представить. Да, я внезапно осознал, что этой теме было бы комфортнее вот в [этом] разделе. Модераторы, спасайте!

Окей, учту. Писал довольно-таки второпях, так что код пока не приложен. В видео всегда сначала запускаю готовое приложение, а потом уже построчно комментирую, разбавляя объяснениями попроще. Не знаю пока, стоит ли лезть в си - всё ещё есть возможность запутаться. Исполняемые файлы можно взять из папки с ассемблером, а всё, что напишем сами - буду прикладывать к статьям, само собой. Хорошо ещё, что я не полез в дебри защищённого режима, Win16\Win32, моделей памяти, сегментов PE и так далее. Всё будет, но потихоньку. PS: Спасибо за оценку. Надеюсь, что объяснения принесут пользу - я сам довольно долго втыкал в сухую англоязычную документацию. PPS: Если есть что-нибудь толковое о winapi в целом (мне что-то на ум не приходит) - можно в лс ссылку? Т.е. я в самом начале объяснил (очень кратно), что все процессы в системе общаются и взаимодействуют при помощи этих самых функций. Если это можно объяснить ещё проще - я только рад буду, честно. Иногда трудно объяснить то, что тебе кажется элементарным и с чем каждый день работаешь. PS: Обновил статью, приложил исходник + скомпилированный проект, ну и дописал объяснения про недостающие места.

Прикладываю [ссылку на статью], где самым подробным образом разбирается "hello, world!" на Ассемблере, немного рассказывается про функции и их аргументы, а так же (совсем немного) описывается алгоритм работы большинства трейнеров. Надеюсь, кому-нибудь пригодится. [Вторая часть]. [Третья часть], на этот раз - видеоурок. Пробежался по используемым WinAPI-функциям, ещё немного разобрал код в целом. Исходник и готовый пример приложены в архиве. Дальше - больше. Спасибо, вроде бы - то, что надо. Попробую как можно в более легкоусваиваемой форме представить. Так, простенький каркас трейнера мы написали, теперь будем его периодически улучшать. Вот небольшая заметка о том, как избавить окно от заголовка и научить его перетаскиваться за любую его часть: [тык]. Да, я внезапно осознал, что этой теме было бы комфортнее вот в [этом] разделе. Модераторы, спасайте!

У меня есть подозрение, что ещё что-то интересное происходит в процедуре по адресу 0x00881B16, т.к. перед вызовом этой процедуры мы запихиваем в стек два аргумента, ("fp32" и "jump_speed"). [esp+C] сильно походит на [base address + offset], т.е. это какая-то структура, так что вполне вероятно, что процедура по указанному выше адресу кушает какой-то идентификатор ("fp32") и то, что ей надо сделать. А сделать ей надо "jump_speed", т.е. посчитать высоту прыжка. А то фигня же какая-то получается - может я только в самом начале любимого уровня, хочется головой о потолок побиться, а приходится ждать загрузки следующего. Но за труды - всё равно плюс.

Для флагов надо pushfd\popfd юзать. PS: Разве EIP можно поменять программно? О_о