Ручная прогрузка kernel32 и ntdll

Точку входа вызвал и она вернула ошибку.

Вообщем решил проблему немного подругому. Просто срелоцировал копию на оригинальную dll в которой всё уже проинициализировано. И теперь нет необходимости вызывать DllEntry, таким образом копии kernel32 и ntdll стали работать

 

хех... оригинальное решение... молодец!

 

Не понял, а какой тогда смысл всего этого действа? В чём изначально задача была?
Использовать "чистую" копию системной библиотеки, загруженную с диска, или что?

 

x64

Задача снять хуки с экспортных функций (kernel32 и ntdll), и усложнить анализ файла(при такой прогрузке копии при отладке ни олли ни ida не видят имён экспортных функций).

 

Aids
перехват sysenter все равно перехватит Ваши вызовы.
и почему бы просто не заюзать эти же системный вызовы?

 

K10

ну перехватывать sysenter нужно из ядра. а если напрямую юзать то нужно помнить номера сервисов для всех windows. Хотя имея простенький дизасм, и зная адрес ntdll можно найти номера системных вызовов нужных функций

 

Aids
Можно из юзермода перехватить KiFastSystemCall, номера сервисов тоже определяются несложно.

 

есть ли примеры реализации?

 

Rel
Может и есть, я думаю так, в ntdll.dll экспортируемые функции имеют вид стабов на KiFastSystemCall, типа:

Код (Text):

1. MOV EAX, ServiceNumber
2. MOV EDX, 7FFE0300 ; SharedUserData!SystemCallStub
3. CALL DWORD PTR DS:[EDX]
4. RETN

Соответсвенно в 7FFE0300 находится адрес KiFastSystemCall. По указателю на функцию можно узнать номер вызова и заменить адрес в 7FFE0300 на адрес обработчика, старый сохранить.

А так же патчи никто не отменял.

 

да это понятно... мне интересно посмотреть, как это делают грамотно... то есть например, чтобы потокобезопасно подставить свой адрес (установить/убрать подобный хук) надо видимо остановливать все другие потоки... как лучше писать свои обработчики и тд... эти вопросы тянут минимум на статью по тематике, ну или исходники... поэтому и спрашиваю про примеры)

 

Rel
Для модификации "MOV EDX, 7FFE0300 " нет смысла стопорить потоки,

 

не, ну в принципе да, но а в случае наличия нескольких процессоров, не может возникнуть каких-либо проблем?

 

Rel
Вроде уже обсуждалось и пришли к выводу, что запись DWORDа атомарна даже при нескольких процессорах.

 

вообще, надо канеш мануалы почитать. тк это сложная тема... но я чет не уверен, что запись дворда невыравненного на 4 байтовую границу пройдет атомарно... это канеш потенциально довольно редкий баг, но всякое бывает, я думаю, что лучше уж для верности остановить другие потоки процесса)))

 

нет лучше уж запись дворда сделать чем такой ахтунг )