keng

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

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

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

Изменяет, т.к. это зависит только от размера. Near - это +-127 байт от EIP. Верхняя же планка, по-моему, стоит в 4 Гб.

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

ТС, пожалуйста, не надо использовать готовый код, ничего в нем не понимая и пытаясь что-то поменять. Найди на форуме пару видеоуроков (от меня или от Coder-а) по созданию такого сканера - там хотя бы объясняется, как он работает. Более того, код, который ты привел - это не C++, но тут я уже скорее придираюсь.

Еще можно прыгать на + или - сколько-нибудь байт вперед. Типа "jmp 5" - вперед (ниже по коду) на 5 байт. CE, по-моему, даже умеет автоматически определять разницу между short jmp и far jmp. А "почему так сложно" - наоборот, просто, все переходы - статические. Код лежит всегда по одним и тем же относительным смещениям, так компилятор делает и так процессору проще в этой каше разбираться. Как результат - программы работают быстрее.

Не, давай еще раз. Ты нашел инструкцию, которая *записывает* текущее положение зомби. Меняется это положение не этой инструкцией, а где-то раньше. Следовательно, саму инструкцию можно вообще не трогать. По сути, она является эквивалентом чего-то такого: zombie.Position = pos Как вариант, можно в скрипте читать текущее значение, отнимать из него какое-то число, а потом уже записывать. PS: Исходный код и скрипты принято заворачивать в тег "spoiler" (кнопка с глазом на панели редактирования поста).

Привет! Не стоит надеяться на то, что NOP может решить все проблемы. Почитай внимательно, что делает инструкция. Если коротко, то процессор сам по себе умеет работать только с целыми числами, а когда понадобились дробные - к нему сбоку "прикрутили" дополнительные регистры и сделали специальные инструкции для работы с ними. FST\FLD - это сокращения от "Float Store" и "Float Load", то есть они считывают и записывают дробные числа между "обычными" регистрами и специальными. У тебя получается такая ситуация, что ESI+2C хранит положение зомби (или скорость, что-нибудь такое), и игра меняет эту цифру, а затем переводит из дробного числа в целое и сохраняет себе. Следовательно, где-то выше по коду игра что-то с числом делает - например, прибавляет или отнимает. Или умножает, тут особой разницы нет. Эту инструкцию тебе и нужно искать.

Автор, в теме выложили уже два по сути готовых решения, чем они тебе не подходят?

VMT не смещается, а пересоздается. Спасибо DMA и COM - каждый раз в новом месте. Так что искать нужно заново, но штука в том, что перед тем как умереть интерфейс дернет у себя функцию Reset. Если ее перехватить - ты поймаешь момент, когда нужно будет заново искать VMT, но там много вариантов - например, можно перехватить сразу CreateDevice. Второй вопрос - по-моему, да, так. Третий - значит что-то делаешь неправильно.

Привет! Вполне может быть, что игра пересоздает объект d3d, когда переключается на проигрывание ролика и обратно. В этом случае у объекта создается новая VMT, так что хук, установленный до этого, будет работать неправильно. Тут нужно перехватить, если я правильно помню, Reset, а в нем уже переустанавливать хук в новое место.

Да я понял, я говорил о том, что обычно выше по коду параметры пихаются через стек, а не регистры. Частенько VMT вообще компилирует в длинную простыню jmp-ов.

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

Привет! Смотри выше по коду, что происходит с EBX. Значение адреса функции не берется из воздуха.

Короче, все просто! В одной переменной - ссылка на массив указателей на ENUM_SERVICE_STATUS_PROCESS, в каждой лежит SERVICE_STATUS_PROCESS, а в ней - PID. В другой переменной - массив PID-ов всех процессов. Что делать дальше - думаю, все понятно. Разобраться в коде - запросто, там куча комментов, а все функции взяты тупо из MSDN. PS: В зависимости от состояния левой пятки винды, функция EnumProcesses может находиться как в psapi.dll, так и в kernel32.dll - я предупредил! Я сделяль!

Для примера возьму Dropbox - у него нет окна в нормальном понимании этого слова, зато есть иконка. Как я уже писал выше, это - просто один из вариантов, что навскидку пришел в голову. Мне уже больше интересно, что за задача такая у автора темы.

Когда кажется - нужно пробовать. Получаешь список всех процессов, у каждого получаешь его pID, по нему - HANDLE главного окна, если его нет - то это сервис. Если есть, получаешь ID иконки, если ее нет - то это сервис. Все, что осталось - складываешь в массив\вектор\лист или что угодно еще.

Мой вариант с GetClassLong не сработал?

По-моему, там нужно было найти свойство у объекта, который можно обнаружить этим самым чутьем, 0 - не подсвечен, 1 - подсвечен, затем найти расстояние от персонажа и объекта и после этого в структуре персонажа искать дальность. Можно проще, через dissect code или ultimap, так что вариантов много.

Так ведь чтобы посчитать количество сервисов, для начала нужно научиться сервисы от обычных процессов отличать.

Первое, что пришло в голову - это вызвать для каждого найденного функцию [GetClassLong] и выяснить или иконку или адрес оконной процедуры. У сервиса ни первого, ни второго не окажется.

Привет! Между процессом и сервисом разница только в том, что у сервиса иначально нет окна и пользователь сам никак с ним не взаимодействует. Есть еще пара особенностей, конечно, но они не сильно меняют суть дела.

@helldrg, вообще, у меня в блоге лежит два варианта и оба ищут через кучу. Штука только в том, что в одном случае для перехвата функции используется библиотека MS Detours, а в другом я написал сам нужную для этого функцию, чтобы не таскать с собой лишнего и упростить код. Эта функция и есть в коде @Dino. Тебе хочется разобраться вообще в алгоритме работы всей этой штуки, или только в конкретной функции?

@helldrg, в нижнем-правом углу сообщения стрелочки - плюс и минус. А метод перехвата у @Dino, по-моему, тот же что и у меня - в начало функции записывается ассемблерная инструкция вида "jmp addr", где addr - адрес перехваченной функции в нашей dll.