keng

Я - не оратор, да и гх-навыков у меня не так много, просто всегда нравилось ковыряться в коде, особенно в чужом. Спасибо за отзыв, так сказать. В любом случае, критику и дополнения я со всей яростью приветствую - от них урокам будет только лучше.

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

Ну и не мегабайт, опять же! :D Как вариант - запихать какие-нибудь из функций во внешнии DLL, которые написать не на решётках, а на плюсах, к примеру - они уже на ура пожмутся. Ещё довольно много места занимают картинки, например.

ЕХЕ-файлы под .NET - это не совсем обычные PE-формата бинарники, так что стандартными пакерами они жмутся вроде как фиговенько. Насколько я помню, можно поиграться с настройками компилятора - тогда размер будет меньше.

Круто! Объясняю я довольно сумбурненько, но если по шагам каждый урок смотреть - вроде как более-менее понятно всё будет. Тут главное самому практиковаться, т.к. я не могу просто взять и положить знания в голову - я скорее показываю направление куда копать нужно. PS: Сначала тоже на решёточках хотел показывать, но меня после нескольких лет разработки уже от них подташнивает.

Тема-сборник, куда я буду скидывать все видео про создание трейнеров на ассемблере, например. Процесс этот не быстрый, так что ногами прошу не бить. (: А вот и [сайт] ассемблера, который я буду в этой теме использовать. Поехали: [первая запись] - простейшая программа на ассемблере. [вторая запись] - построчный разбор программы из первого урока и план дальнейших действий. [третья запись] - создаём диалоговое окно для нашего трейнера. [четвёртая запись] - пишем функцию записи в процесс игры. [пятая запись] - улучшаем внешний вид. [шестая запись] - работа с горячими клавишами. [седьмая запись] - работаем с указателями.

Идёшь [сюда], выбираешь на свой вкус.

Весь процесс запросто автоматизируется, после чего код пихается в dll'ку, которая цепляется к целевому процессу и делает всё самостоятельно. Наворотить можно что угодно - было бы время и желание. (:

Во, пасиба, я так и думал. У меня в планах выложить урок с демонстрацией универсального решения (как под opengl так и под direct3d) для любой игры. Но это попозже. (:

Вольный перевод-пересказ статьи от меня: [ссылка]. Оригинальная статья на английском (я перевёл и описал ключевые моменты, не опираясь на конкретно взятую игру): [ссылка]. Чуть позже будет видео, сейчас, увы, слишком загружен на работе. PS: Критика и комментарии приветствуются.

Да, в первых уроках был небольшой косяк с синхронизацией аудио- и видеопотоков, потом я это исправил. Первые уроки придётся смотреть так, увы.

Я честно не помню, что там конкретно было в моём видео, но давай судить по твоему скриншоту:

Спасибо, теорию я немного знаю. Я кинул ссылки на урок по указателям и по инъекции кода - это два разных решения твоей проблемы.

Так как ты не описал свои действия точно и не привёл ни названия игры ни исходников трейнера, буду тыкать пальцем в небо: Итак, первое: Игра хранит все нужные ей для работы значения (патроны, жизни, уровень здоровья и вообще всё) в переменных. Эти переменные хранятся в оперативной памяти. Представь себе вот такую картинку: 0x1: 10 0x2: 200 0x3: 150 0x4: lalala 0x5: tratata Левая колонка - это адреса, приставка "0х" означает, что они записываются в шестнадцатеричной системе счисления. Правая колонка - значения переменных - жизни, патроны или что угодно ещё. Например, по адресу 0x2 игра хранит 200 жизней игрока. В программе поиска (Artmoney, Cheat Engine, TSearch, MHS - не важно) ты находишь нужный тебе адрес, что ты уже успешно и сделал, как я понимаю. Создаёшь трейнер, который будет писать, скажем, в адрес 0х2 1000 жизней. Дальше ты игру перезагружаешь. И смотри, что происходит: Было так: 0x1: 10 0x2: 200 <- адрес жизней 0x3: 150 0x4: lalala 0x5: tratata Стало так: 0x7: 10 0x8: 200 <- [b]новый[/b] адрес жизней 0x9: 150 0x10: lalala 0x11: tratata Адрес жизней изменился после перезапуска игры и, соответственно, по старому адресу, куда трейнер пытается писать, теперь может находиться любое другое значение. Почему это происходит? А происходит это из-за гадкой и противной штуковины под именем Dynamic Memory Allocation, она же DMA, она же - Динамическое Распределение Памяти, если у тебя туговато с техническим английским. Её краткий смысл в том, что операционная система (в нашем случае - MS Windows) при запуске каждого нового приложения выдаёт ему кусок памяти, начинающийся со случайного адреса. Проще говоря, каждый запуск игры адреса всего и вся в ней будут меняться. И какой же тут выход? А выход есть - искать указатель на нужный нам адрес, или же отлаживать и изменять код игры, т.к. местоположение кода (в отличие от памяти) никогда не меняется. Вот тебе пара полезных ссылок: Раз и Два.

Грац-грац! PS: Люблю nfo и трейнеры на 2-3Кб. ^^

Санкт-Петербург.

Судя по всему, местный парсер сходит с ума, так как в слове гугл.ком у меня вставлена ссылка, но она вставлена без http:// ("google.com") , так что почему-то не отображается нормально.

Чуток дополню пост №9 - ещё (часто - в стратегиях) бывает так, что в памяти игры висят структуры вида "свои игроки + игрок-человек" и "чужие игроки", в которых и хранятся айдишники всех юнитов\построек, привязка к ресурсам, открытость карты и прочие штуки. Ищется такое или методом тыка или по количеству игроков в той или иной группе на одной и той же карте. Я такое встретил один раз в одном старом клоне старкрафта, так что не утверждаю, что такое встречается и сейчас. Ещё, кстати, бывает так, что отличается код каких-нибудь алгоритмов объекта. Как пример - стрельба или нанесение урона. Отличие игрока от бота состоит в том, что в случае игрока игре необходимо в буквальном смысле показать происходящее - вывести результат на экран. Обычно в отладчике это выглядит парой call'ов, а вот боту на экран по-барабану - он ориентируется чисто механически - только читает данные, смотреть ему ни на что не надо, так что код в случае бота может выглядеть иначе. Такое, опять же, очень распостранено в стратегиях - бот ползёт по своему: -Посмотреть, сколько у меня ресурсов -Если достаточно для заказа юнита N, то -Заказать юнит N -Проверить, не закончен ли заказ юнита N -Если да - послать юнит N в атаку А вот в случае с человеком будет слегка иначе: -Выводить на экран количество ресурсов и кнопку для заказа -Если игрок нажал на кнопку заказа юнита N -Проверить, достаточно ли ресурсов -Если нет - вывести на экран много неприличных слов -Если да - нарисовать прогресс-бар и вывести сообщение о заказе юнита -Обновить экранное значение ресурсов -Обновлять прогресс-бар в соответствии с прогрессом заказ и так далее.

Просто написание статьи подразумевает изучение предметной области этой статьи, а следовательно - надо быть готовым отвечать на вопросы по охватываемому материалу. А тут вопросы задаёт сам автор статьи. Если хочешь - могу вечером попробовать переписать методы из предыдущего поста, как их вижу я. Заодно прокомментирую и на вопросы отвечу, как смогу.

Класс реализует поддержку WINApi-функций для чтения и записи байт в память, а так же - реализует работу с указателями, в том числе и многоуровневыми. Методы Write()\Read() и PointerWrite()\PointerRead() я бы объединил, т.к. они отличаются между собой всего парой строчек, т.е. вместо двух пар практически одинаковых методов оставил бы MemoryReadWrite(bool rw) и PointerReadWrite(bool rw), а в дальнейшем вообще объединил всё в один метод, которому бы пихались в виде аргументов адрес памяти, оффсеты (если есть - то это указатель), булевый флаг - читать или писать и набор байт, который нужно прочитать или записать в память. Будет удобно, красиво и универсально. PS: Я не считаю себя программистом, но я им работаю. (:

Во-первых, как-то странно выкладывать статью, код которой ты не до конца понял. Во-вторых, покажи места, которые тебе не понятны - попробуем объяснить\оптимизировать.

О, таки получилось у тебя? Отлично!

Фу таким быть! Пойду гуглить, как видеоконтент можно защищать, помимо водяных марок и доната.

Один из профилей товарища плагиатора в соц. сетях. Мобильный: +380994024361 Mail: dj-zion@mail.ru Skype: dj-crown1

Предлагаю вниманию читателей очередной сканер памяти, обладающий (по словам автора) самым быстрым в мире алгоритмом поиска\перебора адресов. Ссылка на сайт. Написан на Delphi 6 + Assembler. На данный момент может быть не очень актуально, т.к. проект заглох, но почитать исходники, думаю, будет многим интересно. У меня отлично работала (и компилилась) на WinXP, на Win7 не проверял.