Я хочу переделать Kernel32.dll
Мне надо создать Dll в точности копирующий kernel32 , но чтоб вместо CreateFile была моя функция(пишу на Дельфи). Ну так что?
А зачем?
В точности не получиться... да и не за чем.
Наверное, хочешь хукать CreateFile? Но это можно сделать др. более реальными и простыми методами.
Ну так что?
Так и делаешь, пишешь вызовы из своей kernel32 в настоящую т.е. перенаправляешь, а при вызове нужной функции вызываешь свою dll, но это не просто (версии, обновления и т.д.), лучше внедрять свою dll в адресное пространство программы и перехватывать нужную функцию.
:)
Так и делаешь, пишешь вызовы из своей kernel32 в настоящую т.е. перенаправляешь, а при вызове нужной функции вызываешь свою dll, но это не просто (версии, обновления и т.д.), лучше внедрять свою dll в адресное пространство программы и перехватывать нужную функцию.
:)
Это не только непросто, но и практически невозможно, т.к. kernel32 имеет кучу недокументированных функций, которые активно юзаются продуктами MS. Также некоторые продукты юзают процедуры этой DLL напрямую, т.к. она лежит постоянно в одном и том же адресном пространстве и нет необходимости трясти таблицу экспорта.
В точности не получиться... да и не за чем.
Наверное, хочешь хукать CreateFile? Но это можно сделать др. более реальными и простыми методами.
Ну и как же ещё можно её хукнуть. С помощью Debug API у меня не получилось! Ну так как?
Так и делаешь, пишешь вызовы из своей kernel32 в настоящую т.е. перенаправляешь, а при вызове нужной функции вызываешь свою dll, но это не просто (версии, обновления и т.д.), лучше внедрять свою dll в адресное пространство программы и перехватывать нужную функцию.
:)
Тогда такой вопрос :D как получить PID процесса или EXE процесса, который обратился к DLL.
Это не только непросто, но и практически невозможно, т.к. kernel32 имеет кучу недокументированных функций, которые активно юзаются продуктами MS. Также некоторые продукты юзают процедуры этой DLL напрямую, т.к. она лежит постоянно в одном и том же адресном пространстве и нет необходимости трясти таблицу экспорта.
Понятно что некоторые функции не документированы, но ведь функции SYM показывают все symbols библиотеки. Версии и др найти можно,но всё это действительно не легко, а можно просто добавить к этой библиотеке ещё несколько функций, ну или заменить?
А зачем?
В точности не получиться... да и не за чем.
Наверное, хочешь хукать CreateFile? Но это можно сделать др. более реальными и простыми методами.
Ну и как же ещё можно её хукнуть. С помощью Debug API у меня не получилось! Ну так как?
Я бы сделал всё основательно, т.е. через драйвер, см. Filemon на http://www.sysinternals.com
Я бы сделал всё основательно, т.е. через драйвер
Из пушки по воробьям ? :D
И вообще я что-то не понимаю сути проблемы, причем здесь какие-то недокументированные функции ?
Список экспортируемых функций известен. Нужно сделать DLL c точно таким же списком функций, в теле функций заглушку типа
jmp <там где настоящая функция>
и все дела.
"Васька проснется - а его голова в тумбочке лежит. Вот смеху-то будет" (из старого анегдота)
Green
Из пушки по воробьям ? :D
И вообще я что-то не понимаю сути проблемы, причем здесь какие-то недокументированные функции ?
Список экспортируемых функций известен. Нужно сделать DLL c точно таким же списком функций, в теле функций заглушку типа
jmp <там где настоящая функция>
и все дела.
Ок...
А как обойти такую ситуацию:
p = GetProcAddress(hModule, "CreateFile");
p(......);
Ответ, кажется, прост: написать и свою ф-цию GetProcAddress.
НО! Как будете возвращать указатель на др. ф-ции, не на CreateFile? Следует учесть, что первые 100 функций kernel32 недокументированны, адрес получается не по их названию, а по номеру, и стандартный GetProcAddress намеренно не отрабатывает вызовы, ведущие к попыткам использовать эти 100 ф-ций из сторонних приложений.
Green
Из пушки по воробьям ? :D
Понятие "пушка" и "воробей" весьма относительные.
Я считаю, что значительно проще написать драйвер, чем перелопачивать DLL. Кроме того, таким образом пресекаются все варианты обращения к CreateFile ядра.
IGORYOK
Есть такая книга - "Ядро Windows" издательство Microsoft Press на русском,
она тебе поможет, там есть раздел внедрение своей dll в адресное пространство другой программы.
:)
Следует учесть, что первые 100 функций kernel32 недокументированны, адрес получается не по их названию, а по номеру, и стандартный GetProcAddress намеренно не отрабатывает вызовы, ведущие к попыткам использовать эти 100 ф-ций из сторонних приложений.
Только под отстойной Win98 и ее родственниками. Под WinNT все функции именованные и почти все документированны.
А как обойти такую ситуацию:
p = GetProcAddress(hModule, "CreateFile");
p(......);
Ответ, кажется, прост: написать и свою ф-цию GetProcAddress.
Честно говоря, я не понял хода мыслей. :roll: Поэтому более подробно опишу свой метод.
1. Получается список экспортируемых фукнций Kernel32.dll (не обязанельно имен, сойдут и номера) с соответствующими адресами этих функций.
2. Создается копия Kernel32.dll под другим именем, скажем K32.dll.
3. Наша DLL статически связывается с K32.dll (т.е. с настоящей Kernel32.dll) и использует все нужные ей системные функции.
4. Для каждой неинтересной нам функции пишется что-то вроде редиректора (сначала я обозвал его заглушкой, но это наверно неправильно) следующего вида:
void __stdcall CloseHandle()
{
__asm {
mov edx, <адрес CloseHandle в K32.dll>
jmp edx
}
}
Только нужно проследить за целостностью стека. Если компилятор что-нибудь там сохранит, все это надо вытащить до прыжка.
5. Реализация интересных ограничивается лишь фантазией разработчика.
6. Замена dll в системном каталоге и попытка загрузки :).
При практической реализации конечно придется "обработать напильником", но в целом идея, думаю, работоспособна.
IGORYOK
Ну а если сделать по другому с помощью IDA pro декомпилировать kernel32.dll, а потом внутри вставить свою функцию и тд и закомпилировать назад. Только я на ассемблере никогда ничего не делал кто знает где чё найти и как сделать
Гораздо быстрей будет сложить ханойскую башню из 64 золотых дисков и отправиться к праотцам :D.
non_prog
Есть такая книга - "Ядро Windows" издательство Microsoft Press на русском,
Что за книга ? Рихтер что ли :-?.
Green
Только под отстойной Win98 и ее родственниками. Под WinNT все функции именованные и почти все документированны.
Честно говоря, я не понял хода мыслей. :roll: Поэтому более подробно опишу свой метод.
1. Получается список экспортируемых фукнций Kernel32.dll (не обязанельно имен, сойдут и номера) с соответствующими адресами этих функций.
2. Создается копия Kernel32.dll под другим именем, скажем K32.dll.
3. Наша DLL статически связывается с K32.dll (т.е. с настоящей Kernel32.dll) и использует все нужные ей системные функции.
4. Для каждой неинтересной нам функции пишется что-то вроде редиректора (сначала я обозвал его заглушкой, но это наверно неправильно) следующего вида:
void __stdcall CloseHandle()
{
__asm {
mov edx, <адрес CloseHandle в K32.dll>
jmp edx
}
}
Только нужно проследить за целостностью стека. Если компилятор что-нибудь там сохранит, все это надо вытащить до прыжка.
5. Реализация интересных ограничивается лишь фантазией разработчика.
6. Замена dll в системном каталоге и попытка загрузки :).
При практической реализации конечно придется "обработать напильником", но в целом идея, думаю, работоспособна.
Гораздо быстрей будет сложить ханойскую башню из 64 золотых дисков и отправиться к праотцам :D.
Спасибо за сравнение с башней, но ты думаешь я не попытался сделать твоим методом(в смысле моим). Но какие возникли проблемы, во первых когда я пытался это сделать на С++ или Delphi появлялась такая особенность внутри созданной DLL появлялись ссылки на функции типа работы с потоками и тд из настоящей kernel32.dll без нового имени просто потому что первично kernel32.dll используется system.pas так же как и user32.dll и др, а отключить это я незнаю как, так как убрать прокол
Но какие возникли проблемы, во первых когда я пытался это сделать на С++ или Delphi появлялась такая особенность внутри созданной DLL появлялись ссылки на функции типа работы с потоками и тд из настоящей kernel32.dll без нового имени просто потому что первично kernel32.dll используется system.pas так же как и user32.dll и др, а отключить это я незнаю как, так как убрать прокол
Самый простой способ - в шестнадцатеричном редакторе открываешь свою DLL, ищешь строку "KERNEL32.DLL" и заменяшь на что-угодно.
[QUOTE]Originally posted by segev
Green
void __stdcall CloseHandle()
{
__asm {
mov edx, <адрес CloseHandle в K32.dll>
jmp edx
}
}
Ага, если быэто было так просто.
А какое кольцо защиты использует ЭТО, вы знаете?
Как шлюзы вызова использовать тоже?
Как распределена таблица селекторов шлюзов?
НУ и так далее.
Тем более билдов виндов огромное количество, где гарантии, что что ДЛЛ подойдет к винде на которой запущена прога?
Лично я бы попробовал вариант с изменением существующей.
Ага, если быэто было так просто.
А какое кольцо защиты использует ЭТО, вы знаете?
Как шлюзы вызова использовать тоже?
Как распределена таблица селекторов шлюзов?
НУ и так далее.
Тем более билдов виндов огромное количество, где гарантии, что что ДЛЛ подойдет к винде на которой запущена прога?
Лично я бы попробовал вариант с изменением существующей.
Так сам же сказал что билдов огромное кол-во, так как же ты собираешся переделывать существующую ? она ведь тоже подойдёт для какогото определённого....
Имхо вариант с джампами на настоящий адрес самый лучший... а причём тут кольцо защиты я вообще не понял, тут всё в 3'ем выполняется..
Имхо вариант с джампами на настоящий адрес самый лучший... а причём тут кольцо защиты я вообще не понял, тут всё в 3'ем выполняется..
Да все просто. Дело в том, что в этой библиотеке содержатся некоторые привелегированные функции выполнение которых происходит в других кольцах, т.к. эти функции юзаются системой.