Всем доброго времени суток. Есть программа,которая ставит системный хук(на клавиатуру,хоть это не так и важно). Процедура обработки хука находится в динамической библиотеке. Дописал код,запустил,но вышло так,что происходит что-то неладное в данном обработчике хука(в той самой процедуре из dll). Казалось бы,надо взять отладчик(я взял на вооружение ольку) и по шагам изучать этот обработчик,но как это сделать,ведь он находится в dll. Жду помощи от знатоков. P.S Наверное,как всегда окажется,что справиться этим очень просто.!)
Я бы написал ехе, который бы подгружал твою длл и самостоятельно вызывал обработчик хука. Ну и олькой бы заходил вовнутрь
кнопочка м (alt M) выбираем сегмент кода нужной dll и жмем enter ,или поставить бряк на всю секцию кода F2 самоучитель в картинках по Ольге находится здесь http://www.wasm.ru/publist.php?list=23 где то с 9 урока
FLASH300 Я,если честно,день как олькой пользуюсь,так что для меня сложновато как-то пока то,что ты дал. Но данный цикл начал читать.Спасибо.
Код (Text): ...так что для меня сложновато как-то пока... я про 9 урок. Первые уроки-элементарные вещи)
эм... ну ты ж в обработчике ожидаешь какие-то события? ты ж их как-то обрабатываешь? Вот какие обрабатываешь, те и передавай. А если ты параметры просто игнорируешь, то ничего не передавай. Тебе что надо? Проверить, работает ли код при ожидаемых условиях или нет, верно? Вот и содай те условия, которые ожидает твой код. Ну если совсем все страшно, то пусть твоя длл просто ведет запись в лог полученных параметров, а там разберешься, что не так ты обрабатываешь
Как это неважно. Если хук неправильный, то ты будешь ловить клавиши из отладчика Лучше использовать два компьютера и удаленную отладку.
Мде а я уж и забыл как работают эти хуки система в контексте других процессов даже int 3 глотает. По моему в таких случаях проще выделить место под бряки nop ами (чтоб случайно стек не испортить) и для отладки посылать сообщения клавиатуры в окно того процесса который поставил хук, или воспользоваться WH_KEYBOARD_LL (правда не проверено).
Как в Olly изобразить такое?: DEBUG rshx32.dll S 100 8000 74 00 5C 00 4F DEBUG will return a line of the form: 0ADE:0AC0 E 0AC0 74 00 00 00 4F (use the value returned to you above and not 0AC0!!!) W Q я делал Search for binary string и результата никакого!
CroCop я при отладке хуко-длл писал маленькую ехе, которая вызывает с длл ф-ю установки хука. При запуске ехе входил в ф-ю установки хука(F11) и открывался код длл,а там уже ставил бряки на ф-ю обработки хука - чуток напряжно было с хуками на клаву, но все норм - отладка прошла успешно с помощью мыши.) пс. выше сказанное происходило в VisualStudio.
Всё сгребу что спросить хочу... Как можно увидеть api ? Дело в том, что асмом мы только подготавливаем поля фунции, push... push... А потом приходит call и далее уже не ясно что происходит!? Я это давно не понимаю, но не знаю с какого боку подкраться к этому! Иными словами охота увидеть на чистом асме хотяб MsgBox... Или это слишком много коду в действительности и достаточно сложно? Ктонить кодил такое без api ? Ещё по правде сказать я не разбираюсь зачем Step Into, Step Over в отладчике, хотя это можно выяснить... Мне Step Over больше нравиться В чём различие дизассемблера от дебагера? Я боюсь этого страшного IDA, олли хоть и непонятный, но не так пугает всётаки. ))) Но что мне непонравилось, то что в отладчике нельзя сохранить изменения в файл. Или можно? Дампом чтоли... кривой не получится? Или для этих дел hiew лучше подходит?
Semiono 1) MsgBox простой и сложный одновременно. Простой, если надо просто вывести сообщение в окне - это можешь запрограммировать, если конечно не хочешь окна сам рисовать. Без API все равно не обойдешься, даже если будешь все на "десктопе" рисовать линиями и прямоугольниками. Но у MsgBox куча опций и кнопки и модальность и .... 2) Step In тебе позволит узнать, как сложно устроен MsgBox и добраться до ntdll 3) Дизассемблер - выдает исходник и все. Дебаггер позволяет смотреть процесс "изнутри". Дизассемблер есть и в отладчиках, в Олли он интеллектуальный, в IDA еще более интеллектуальный.
