В общем ставлю хук на ф-ции из этой dll. Также перехватываю ф-ции (через IAT) ntdll.LdrLoadDll, kernel32.GetProcAddress (попробовал хукать ntdll.LdrGetProcedureAddress - вылетает все нафик ), приостанавливаю потоки и т.д. Для пробы хукаю user32.MessageBoxA/W - все нормально. Пробую хукнуть ф-ции wininet.dll - облом. Нашел через поиск только одну тему, подобную моей, но там так ничего и не решилось ...
Исправил глюк с перехватом ntdll.LdrGetProcedureAddress, потому убрал kernel32.GetProcAddress. Результат остался прежним - ф-ции wininet.dll не перехватываются. Потому вопрос: как правильно организовать перехват ф-ций wininet.dll из драйвера? Интересует теоретическая часть, с практической и сам разберусь, но если вдруг кто будет столь любезен, то канеш не откажусь ... Просто накидайте примерный алгоритм действий и т.д.
Мне кажется, из драйвера перехватывать 3 кольцевые апи бессмыслено. А для юзермода самый надежный способ перехвата - сплайсинг. Я проверил, с помошью dll injection и сплайсинга все прекрасно перехватывается.
10x Ms Rem за совет. Оч странно, но если хукать ф-ции ntdll.LdrGetProcedureAddress и ntdll.LdrLoadDll, то IE идет в обход их местами... Я заменил их перехват на набор ф-ций из kernel32.dll и все заработало!!!
Это почему ??? вставил в начало кода функции какой нить 0xcd70(сам же и говорил) и лови прерывание, в драйвере его и обрабатывай, только для этого надо будет дескриптор описать подобно Int2e чтоб не заклинило при переключении режимов. еще надо будет решить проблему с реентерабельностью, поскольку контексты свопиться один хрен будут, и пока наш драйвер будет обрабатывать инт, кто нить другой вызовет прерывание, но это всё просто решается. Мне кажется вообще намного проще будет осуществить перехват именно из драйвера Единственная замутка будет только со стеком, но и она решается довольно просто.
В некоторых случаях проще, а иногда вообще неприменимо (из за тормозов при переключении в кернелмод), к тому же апишки часто хукаются для изменения их результатов работы, причем в обработчике может быть один или несколько вызовов оригинальной функции. Можно конечно и в таком случае замутить обработку в драйвере, но зачем наживать геморрой, если можно просто повесить юзермодную длл в которой такие обработчики делаются куда проще. Имхо драйвера проще и удобнее применять при перехвате в кернелмоде, а в юзермоде они годятся только для очень простых случаев, когда обработчику не нужны юзермодные апи.
Хм, что то я тебя не совсем понимаю, я пользовал данн6ый метод и всегда он отрабатывал превосходно, тормоза припереключении режимов ???? какие ??? Данные функции будут так часто вызываться, что суммарное время к примеру вызова int2e будет меньше к примеру чем вызов нашего обработчика?? Это глупости. А тебе это важно ???? тееб надо отследить то, что на входе функции и на выходе, а что там в оригинале тебе зачем, ведь требуется то всего навсего повлиять на поведение последней. Так с этого и надо было начинать, а если там никаких API не юзается, а к примеру требуется всего лишь отмониторить или повлиять на параметры, но почему бы и нет ???? мы получим глобальный обработчик, недосягаемый для остального UM кода и практически нерушимый, это нечто как с обработчиком #UD для NTVDM к примеру.
Вызов прерывания с изменением СPL, переключением стека и.т.д. всегда будет занимать гораздо больше времени чем простой call на юзермодный обработчик. Это справедливо только в простейших случаях, сложные обработчики могут содержать множество вызовов других API. Разве? Во-первых мы ставим обработчик изменяя память юзермодного кода, а значит он сможет ее перезаписать и убрать вызов прерывания. Также программа может обнаружить обработчик и работать в обход перехватываемой апи.
в исходном задании о сложности упоминания не велось Прям настолько уж много ???? Когда стэк дров KAV тормозит при каждом прогоне irp это нормально и все терпят, а тут какой то вызов шлюза и в результате куча потерянного времени ) это вряд ли если только об этом не стоит задача у перехватываемого кода, а если так, то ты можешь отследить это и исправить в случае чего. Ты что то слишком сложно уж смотришь на вещи )
а ты не дай ей переписать память, во первых мы будем иметь дело с кодовой секцией, а это значит, что изменять код по умолчанию не дозволено, можно поменять аттрибуты страницы для осуществления задуманного, а делается это дело вызовом VirtualProtect, ну и перехвати соответствующий аналог в NTDLL.DLL и проконтролируй, ничего твой юзермод код в этом случае сделать не сможет, только если для этого не установит свой драйвер и не попросит тот сделать для него эту работу, ну а это уже сам понимаешь, больше напоминает научную фантастику в данном контексте ) никаких траблов я тут не вижу, сам же статьи написал, а теперь за голову хватаешься ))
Во-первыз ntdll - юзерможная длл, нужно перехватывать ZwProtectVirtualMemory в ядре, иначе приложение сможет обойти эту функцию мимо. И вторая ВЕСОМАЯ причина не использовать драйвер для перехвата юзермодных апи в том, что для запуска драйвера понадобятся права администратора. Говорю я это все потому, что мне приходилось делать программу перехватывающую функции работы с реестром и заставляющую программу думать что она обращается к HKEY_LOCAL_MACHINE, хотя она на самом деле обращалась к подветке HKEY_CURRENT_USER. Цель этой программы - запускать без прав администратора игрушки требующие такие права и при этом избежать засорения реестра. Так вот, программа должна устанавливатся и работать без прав администратора в системе и при этом обработчики функций были весьма не простейшими. Драйвер для такого случая не подходит совершенно. Я не пытаюсь сказать, что драйвер нельзя для юзермодного перехвата использовать, просто в некоторых случаях это нецелесообразно и весьма геморройно.
Ничего не понимаю, ты преследуешь цели в каких то идеализированных условиях. Наверняка то , что ты пишешь, будет являться существенным продуктом. Ну и что, попроси инсталяции в админмод, засунешь туда драйвер, а затем пусть народ дальше юзает тачку с юзерправами. И всё будет так как надо. Единственный гемор в данном вопросе, это использование кучи апи в обработчике перехватчика, больше проблем я не вижу.
