keng

О чем вы спорите? Сколько байт указано в SYSTEM_INFO.dwAllocationGranularity, до такого значения и округлится размер при вызове VirtualAlloc. Еще там может быть NULL, ага. Вопрос скорее в том, зачем лезть в Native-код.

Привет! При помощи одной из стандартных функций библиотеки - [memcpy].

То есть вылет происходит именно при вызове ProtectHacker, так?

По поводу "собрать всех монстров с локации" - если получится подвигать одного монстра, найдя и изменив его координаты (тут надо учесть, что координаты бывают экранные, игровые и еще какие-нибудь "внутриигровые", которые из игровых туда-сюда конвертируются), можно найти список монстров и им всем по нажатию кнопки координаты поменять. Как обычно этот список ищется - чаще всего монстры хранятся массивом указателей, так что надо найти одного монстра (скажем, здоровье), затем найти в его структуре смещение до координат, а затем сделать поиск указателя 1-го уровня на базовый адрес структуры или на адрес здоровья. Обычно вываливается 2-3 адреса, так что их руками перебрать будет легко - добавляем каждый найденный в новую структуру в СЕ, раскрываем по очереди указатели (они там стрелочками будут) и смотрим нужное смещение. Выглядеть это будет примерно так: 0x1234567:-->0x100-0x20 - health-0x30 - X coord...-->0x300-0x20 - health-0x30 - X coord... Частенько такой массив указателей лежит рядышком с игроком, а то и игрок вместе с монстрами в одном лежит. После этого нужно будет найти инструкцию, которая почаще читает все координаты, и сделать в ней инъекцию, в которой пойти по адресу с указателями, залезть в каждый, взять [адрес_монстра+смещение_до_координат] и заменить его на некоторое новое значение. Цикл, в общем, перебор в цикле. Главное четко определить, что это нужная структура, а не что-нибудь другое - иначе игра не оценит шутку и, скорее всего, вылетит. Последний момент, который хотелось бы заметить в этом способе - лучше все перемещаемые объекты немного подовигать вверх, т.е. по оси OY, чтобы они ножками в землю не застряли при приземлении и не случилось из-за этого чего-нибудь нехорошего.

Гм. Файл я получил, но ничего такого в нем не нашел. Если закомментировать вызов функции ProtectHacker - то работает?

Не могу просто так сказать - нужно смотреть\отлаживать код. Можешь мне нужный cpp-файл письмом прислать? 00 keng (doge) gmail com

Так это, при первом вызове VIrtualProtect в oldProtect как раз и запихивается старая защита. Ну, PAGE_EXECUTE_READ, к примеру. Мы ее сохраняем, затем пишем нужные байты через memcpy, а потом ставим сохраненную на место. Второму вызову все равно нужно скормить oldProtect еще раз, потому что без этой шляпы функция нормально отработать не сможет. На это, в принципе, внимание можно и не обращать. Ну и как написано в MSDN про virtualprotect: "If the function succeeds, the return value is nonzero." (если функция выполнилась успешно, то возвращаемое значение - ненулевое) Поэтому ты такой Int lala = virtualprotect(...), а затем смотришь, что приехало в lala и что в oldprotect, если там не нули, то все хорошо.

Хорошая привычка - "нашел решение проблемы - опиши его". Форум для этого и существует.

Байт одинаковое количество и защита снимается\ставится верно, так? Все функции возвращают какое-то значение в зависимости от успешности их выполнения. memset, насколько я помню, здесь - исключение, но вот VirtualProtect точно что-то возвращает. Проверь, что она нормально срабатывает и пишутся ли (или нет) нужные байты после вызова memset.

Так я ж говорю, что там нечего толком объяснять - там одна функция, которую я учу перехватывать в предыдущих уроках. Эта фунция банально рисует некий графический примитив, описание которого (количество вершин и т.д.) передается в аргументах вызова функции. Так как мы функцию перехватили - можем делать с этими данными что захотим. Вот мы и кладем их в список, а при помощи горячих клавиш выбираем тот или иной примитив из этого списка. Если программа пытается нарисовать выбранный горячими клавишами примитив, то он красится зеленой текстурой, чтобы можно было понять, глядя на экран, нужный примитив мы нашли или нет. PS: Я тоже никогда не занимался 3D-графикой, так что перед всеми своими уроками на эту тему сидел и изучал, как оно работает. Да, потратил пару месяцев времени, но результат-то есть.

Так это очевидно - тебе нужен SDK для версии DirectX, под которую ты собираешься делать приложение. Логгер под 9 - нужен SDK под 9. Просто раньше DirectX SDK выпускался отдельным пакетом, а начиная с DX10 его объединили вместе с Windows SDK, так что туда должны входить и DX10 и DX11. Написал простенькое приложение, понял, как оно работает, а затем адаптировал под это существующий DX9 логгер. Там функция-то одна, кода на полторы страницы.

Можно ведь адаптировать дх9 под любую другую версию - нужен будет лишь sdk, который сейчас входит в windows sdk.

Насколько я помню, для работы ультимапа нужен работающий DBVM. У меня он даже на чистенькой Windows 7 работает через раз, так что приходится трейсить код в основном руками.

Так исходники-то есть - скачай да посмотри. (:

Оно отслеживает ветки кода, которые выполнились или не выполнились за определенный промежуток времени. Как сканер адресов, только для call-ов.

Так, э, почему тогда нельзя в самом начале инициализации эту функцию вызвать?

Что у тебя делает функция new_My_Thread() и почему нельзя было ProtectHacker декларировать как "void ProtectHacker()"?

Раз должна возвращать - значит где-то есть return. И списывать из видео код без понимания того, как он работает и что делает - незачем, толку от этого не будет. Пиши лучше сам.

Первый - это адрес начала страницы памяти, защиту которой поменять надо. Так что да, это адрес для записи байт. Второй - размер региона в байтах, защита которого будет изменена. Третий - какую защиту ставить. Нас тут интересует PAGE_EXECUTE_READWRITE. Четвертый - указатель на 4 байта (DWORD) переменную, куда запишется старая защита. Про memcpy вот [отсюда] что не ясно?

Так ведь я тебя прекрасно понял. Алгоритм я тебе описал, все необходимое у тебя есть, описания функций, если не очень понятны, можно легко посмотреть в интернете. Берешь и пробуешь написать, а если что-то не получается - спрашиваешь.

Так я ж уже все написал. DLL ты сделал? Сделал. В память игры ее подгрузить можешь? Можешь. Дальше тебе нужно знать куда писать (а нужные адреса памяти ты уже нашел), удостовериться, что можешь писать - через VirtualProtect, указав что по адресу, куда ты будешь писать, N байт, которые ты будешь писать, надо сделать не read-only (только для чтения, как обычно и есть), а read-write (чтобы можно было и читать и писать). После этого ты вызываешь memcpy, скормив ей адрес *куда* копировать (адрес кода в игре), *откуда* копировать (место в твоей DLL, куда записаны байты новой инструкции, скажем, nop, и сколько байт - это N, то есть длина инъекции. Потом только остается через еще один вызов VirtualProtect установить на место оригинальные настройки защиты памяти - при первом вызове эта функция попросит переменную, куда сохранять. Вот и все, в общем-то.

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

Привет! Как уже правильно подметил Xipho, тебе нужны права к нужной странице памяти. Это делается через VirtualProtect. А для записи можно использовать хоть [memcpy], хоть побайтное копирование ручками. Суть в том, что dll и игра имеют общее адресное пространство, так что не нужен хэндл и доступ к самому процессу - ты уже в нем находишься. Нужны права на запись\чтение и все.

Увы, так не бывает. Да и "тру-хацкеры" тоже когда-то были никем и ничего не умели.

На что?