Форум: "WinAPI";
Текущий архив: 2004.04.11;
Скачать: [xml.tar.bz2];
Вниз"Вклиниться" в адр. пространство библиотеки до выполнения Dllmain Найти похожие ветки
← →
Игорь Шевченко © (2004-03-15 10:45) [40]Kerk © (12.03.04 16:41)
К вопросу, почему статья для пакостников: я не поленился, сходил на основной сайт (там ссылочка дана на инструмент, в котором "данные решения успешно используются"), даже что-то оттуда попытался скачать, но неудачно - антивирус не дал, сказал, что файлы в архивах заражены Backdoor.HackDefender virus.
Интересно, правда ?
← →
Игорь Шевченко © (2004-03-15 10:45) [40]Kerk © (12.03.04 16:41)
К вопросу, почему статья для пакостников: я не поленился, сходил на основной сайт (там ссылочка дана на инструмент, в котором "данные решения успешно используются"), даже что-то оттуда попытался скачать, но неудачно - антивирус не дал, сказал, что файлы в архивах заражены Backdoor.HackDefender virus.
Интересно, правда ?
← →
Kerk © (2004-03-15 14:12) [41]
> Игорь Шевченко © (15.03.04 10:45) [40]
А ты запусти и еще раз касперским попробуй проверить... :)
Ничего страшного не случится... гарантирую.
Прога не является трояном сама по себе... она инструмент для скрытия всего что указано конфигурационных файлах...
← →
Kerk © (2004-03-15 14:12) [41]
> Игорь Шевченко © (15.03.04 10:45) [40]
А ты запусти и еще раз касперским попробуй проверить... :)
Ничего страшного не случится... гарантирую.
Прога не является трояном сама по себе... она инструмент для скрытия всего что указано конфигурационных файлах...
← →
Игорь Шевченко © (2004-03-15 14:43) [42]
> Ничего страшного не случится... гарантирую
Я извиняюсь, я антивирусу доверяю больше - он железный :)
И если антивирус ругается на некую программу, то место ей в Recycle Bin, как и прочим поделкам пакостников.
> Прога не является трояном сама по себе...
А эти сказки можно прокурору рассказать - он сжалится :))
← →
Игорь Шевченко © (2004-03-15 14:43) [42]
> Ничего страшного не случится... гарантирую
Я извиняюсь, я антивирусу доверяю больше - он железный :)
И если антивирус ругается на некую программу, то место ей в Recycle Bin, как и прочим поделкам пакостников.
> Прога не является трояном сама по себе...
А эти сказки можно прокурору рассказать - он сжалится :))
← →
Kerk © (2004-03-15 14:53) [43]
> Я извиняюсь, я антивирусу доверяю больше - он железный :)
Печально.. :( Не стоит слепо верить антивиру...
Кстати, прога с исходниками идет, если мне не доверяешь, можешь сам посмотреть.
> > Прога не является трояном сама по себе...
> А эти сказки можно прокурору рассказать - он сжалится :))
hxdef в принципе не способен нанести какой-либо ущерб!
Сама прога может и "для пакостников", но сами технологии потенциально полезны.
← →
Kerk © (2004-03-15 14:53) [43]
> Я извиняюсь, я антивирусу доверяю больше - он железный :)
Печально.. :( Не стоит слепо верить антивиру...
Кстати, прога с исходниками идет, если мне не доверяешь, можешь сам посмотреть.
> > Прога не является трояном сама по себе...
> А эти сказки можно прокурору рассказать - он сжалится :))
hxdef в принципе не способен нанести какой-либо ущерб!
Сама прога может и "для пакостников", но сами технологии потенциально полезны.
← →
Игорь Шевченко © (2004-03-15 17:29) [44]
> hxdef в принципе не способен нанести какой-либо ущерб!
"Program installs hidden
backdoors, register as hidden system service and installs hidden system driver.
The technology of backdoor allowed to do the implantation of redirector."
" Because rootkit hooks all process in the system all TCP ports on all
servers will be backdoors. For example, if the target has port 80/TCP open for
HTTP, then this port will also be available as a backdoor."
Еще комментарии нужны или как ?
← →
Игорь Шевченко © (2004-03-15 17:29) [44]
> hxdef в принципе не способен нанести какой-либо ущерб!
"Program installs hidden
backdoors, register as hidden system service and installs hidden system driver.
The technology of backdoor allowed to do the implantation of redirector."
" Because rootkit hooks all process in the system all TCP ports on all
servers will be backdoors. For example, if the target has port 80/TCP open for
HTTP, then this port will also be available as a backdoor."
Еще комментарии нужны или как ?
← →
VMcL © (2004-03-16 00:53) [45]>>Игорь Шевченко © (15.03.04 14:43) [42]
>И если антивирус ругается на некую программу, то место ей в Recycle Bin
ИМХО, слишком категорично. Я когда-то лабы в вузе сдавал: брал задание, делал дома, приносил на занятия в WinRAR"ском SFX-архиве. Так один раз в лаборатории то ли Dr.Web, то ли AVP ругнулся на SFX-модуль - типа там вирус, хотя его там, естественно, не было. Лабу пришлось сдавать в следующий раз.
P.S. Так и не удалось мне убедить препода, что можно установленным у них WinRar"ом распаковать мой архив и проверить его содержимое, и если уже оно (содержимое) не в порядке, тогда вопросов нет.
P.P.S. В архиве были только исходники то ли PAS, то ли CPP.
← →
VMcL © (2004-03-16 00:53) [45]>>Игорь Шевченко © (15.03.04 14:43) [42]
>И если антивирус ругается на некую программу, то место ей в Recycle Bin
ИМХО, слишком категорично. Я когда-то лабы в вузе сдавал: брал задание, делал дома, приносил на занятия в WinRAR"ском SFX-архиве. Так один раз в лаборатории то ли Dr.Web, то ли AVP ругнулся на SFX-модуль - типа там вирус, хотя его там, естественно, не было. Лабу пришлось сдавать в следующий раз.
P.S. Так и не удалось мне убедить препода, что можно установленным у них WinRar"ом распаковать мой архив и проверить его содержимое, и если уже оно (содержимое) не в порядке, тогда вопросов нет.
P.P.S. В архиве были только исходники то ли PAS, то ли CPP.
← →
SPeller © (2004-03-16 00:55) [46]
> Этот метод на начальной стадии разработки был отвергнут
> как слишком грубый. К тому же пришлось бы править код во
> всех подгружаемых библиотеках
Зато будет работать на ВСЕХ версиях ОС. Я ведь не говорю править исходный файл, а всего-лишь отображение его в памяти. Неужели независимость от версии ОС (хоть на вынь95 запускайте) не перевешивает "грубости" решения? Лично я не вижу ничего грубого в этом.
ЗЫ: Кстати, дайте мне скачать ваше творение, а то ссылка битая.
← →
SPeller © (2004-03-16 00:55) [46]
> Этот метод на начальной стадии разработки был отвергнут
> как слишком грубый. К тому же пришлось бы править код во
> всех подгружаемых библиотеках
Зато будет работать на ВСЕХ версиях ОС. Я ведь не говорю править исходный файл, а всего-лишь отображение его в памяти. Неужели независимость от версии ОС (хоть на вынь95 запускайте) не перевешивает "грубости" решения? Лично я не вижу ничего грубого в этом.
ЗЫ: Кстати, дайте мне скачать ваше творение, а то ссылка битая.
← →
BiN © (2004-03-16 09:45) [47]SPeller © (16.03.04 00:55) [46]
Я ведь не говорю править исходный файл, а всего-лишь отображение его в памяти
В том-то и дело, что он отображается в памяти, когда уже полностью загружен и как правило _после_ вызова Dllmain (перечитай subj). Как уже упоминалось, можно написать свой загрузчик - но есть более простые и эффективные методы.
Лично я определяю адрес неэкспортируемой функции, кот. вызывает DllMain и правлю ее (функции) вызов. Синтаксис дан. функции (по крайней мере в W2k) такой (я назвал ее LdrpDllEntryPointCaller, не найдя, к сожалению, ее аналог в замечательной статье Russ Osterlund на http://msdn.microsoft.com/msdnmag/issues/02/03/Loader/default.aspx):
function LdrpDllEntryPointCaller(DllEntryPoint:TDllEntryPoint; hinstDLL:HMODULE; fdwReason:DWORD; lpvReserved:Pointer):BOOL; stdcall;
Кстати, дайте мне скачать ваше творение,
в этой теме я вроде никаких ссылок на свои творения не давал :)
← →
BiN © (2004-03-16 09:45) [47]SPeller © (16.03.04 00:55) [46]
Я ведь не говорю править исходный файл, а всего-лишь отображение его в памяти
В том-то и дело, что он отображается в памяти, когда уже полностью загружен и как правило _после_ вызова Dllmain (перечитай subj). Как уже упоминалось, можно написать свой загрузчик - но есть более простые и эффективные методы.
Лично я определяю адрес неэкспортируемой функции, кот. вызывает DllMain и правлю ее (функции) вызов. Синтаксис дан. функции (по крайней мере в W2k) такой (я назвал ее LdrpDllEntryPointCaller, не найдя, к сожалению, ее аналог в замечательной статье Russ Osterlund на http://msdn.microsoft.com/msdnmag/issues/02/03/Loader/default.aspx):
function LdrpDllEntryPointCaller(DllEntryPoint:TDllEntryPoint; hinstDLL:HMODULE; fdwReason:DWORD; lpvReserved:Pointer):BOOL; stdcall;
Кстати, дайте мне скачать ваше творение,
в этой теме я вроде никаких ссылок на свои творения не давал :)
← →
Kerk © (2004-03-16 16:57) [48]
> Еще комментарии нужны или как ?
Ты архив распаковывал?
Чувствую к консенсусу не придем. Тебе прога не нравится - ладно, но текст то здесь при чем?!
И не надо меня прокурорами пугать! Я почти-что законопослушный гражданин! :)
← →
Kerk © (2004-03-16 16:57) [48]
> Еще комментарии нужны или как ?
Ты архив распаковывал?
Чувствую к консенсусу не придем. Тебе прога не нравится - ладно, но текст то здесь при чем?!
И не надо меня прокурорами пугать! Я почти-что законопослушный гражданин! :)
← →
Игорь Шевченко © (2004-03-16 17:38) [49]Kerk © (16.03.04 16:57)
Распаковывал. Мне программа не нравится по двум причинам - по ее целям и по стилю написания. Антивирус мне exeшники вытер, разбираться в таком коде (про него вообще разговор отдельный) у меня нету ни времени, ни желания. Про цели я вроде цитаты привел...
> Чувствую к консенсусу не придем.
А что там в консенсусе должно образоваться ? :)
← →
Игорь Шевченко © (2004-03-16 17:38) [49]Kerk © (16.03.04 16:57)
Распаковывал. Мне программа не нравится по двум причинам - по ее целям и по стилю написания. Антивирус мне exeшники вытер, разбираться в таком коде (про него вообще разговор отдельный) у меня нету ни времени, ни желания. Про цели я вроде цитаты привел...
> Чувствую к консенсусу не придем.
А что там в консенсусе должно образоваться ? :)
← →
Kerk © (2004-03-17 10:21) [50]
> А что там в консенсусе должно образоваться ? :)
Какое-то единое мнение. :)
> Мне программа не нравится по двум причинам ...
см. Kerk © (16.03.04 16:57) [48]:
Тебе прога не нравится - ладно, но текст (на который была ссылка) здесь при чем?!
> Антивирус мне exeшники вытер ...
Опять же - ты слишком доверяешь антивирусу. Написать вирь, неопределяющийся касперским можно за полчаса. А в базы антивиров часто добавляют совершенно безвредные проги (key-gen"ы всякие)...
← →
Kerk © (2004-03-17 10:21) [50]
> А что там в консенсусе должно образоваться ? :)
Какое-то единое мнение. :)
> Мне программа не нравится по двум причинам ...
см. Kerk © (16.03.04 16:57) [48]:
Тебе прога не нравится - ладно, но текст (на который была ссылка) здесь при чем?!
> Антивирус мне exeшники вытер ...
Опять же - ты слишком доверяешь антивирусу. Написать вирь, неопределяющийся касперским можно за полчаса. А в базы антивиров часто добавляют совершенно безвредные проги (key-gen"ы всякие)...
← →
Игорь Шевченко © (2004-03-17 11:51) [51]Kerk © (17.03.04 10:21)
> Какое-то единое мнение. :)
Мое мнение - вредная програма :) Консенсус ?
> Опять же - ты слишком доверяешь антивирусу.
Experience :)
Кстати, если есть желание продолжить флейм на эту тему, давай по почте, а то уже злостный offtopic.
← →
Игорь Шевченко © (2004-03-17 11:51) [51]Kerk © (17.03.04 10:21)
> Какое-то единое мнение. :)
Мое мнение - вредная програма :) Консенсус ?
> Опять же - ты слишком доверяешь антивирусу.
Experience :)
Кстати, если есть желание продолжить флейм на эту тему, давай по почте, а то уже злостный offtopic.
← →
SPeller © (2004-03-18 14:51) [52]
> В том-то и дело, что он отображается в памяти, когда уже
> полностью загружен и как правило _после_ вызова Dllmain
Да ну?
← →
SPeller © (2004-03-18 14:51) [52]
> В том-то и дело, что он отображается в памяти, когда уже
> полностью загружен и как правило _после_ вызова Dllmain
Да ну?
← →
Игорь Шевченко © (2004-03-18 15:13) [53]SPeller © (18.03.04 14:51)
> Да ну?
Ну да. MSDN RE второй сигнальный номер: внутри загрузчика Windows NT
← →
Игорь Шевченко © (2004-03-18 15:13) [53]SPeller © (18.03.04 14:51)
> Да ну?
Ну да. MSDN RE второй сигнальный номер: внутри загрузчика Windows NT
← →
BiN © (2004-03-18 15:31) [54]>> SPeller ©
конечно же, сам образ библиотеки отображается в памяти до вызова DllMain - это очевидно хотя бы потому, что в качестве одного из параметров передается адрес (или хэндл) загруженного модуля.
Метод, предложеный тобой в [46] работать не будет по той причине, что ты собираешься править код в уже загруженной библиотеке и после вызова точки входа.
← →
BiN © (2004-03-18 15:31) [54]>> SPeller ©
конечно же, сам образ библиотеки отображается в памяти до вызова DllMain - это очевидно хотя бы потому, что в качестве одного из параметров передается адрес (или хэндл) загруженного модуля.
Метод, предложеный тобой в [46] работать не будет по той причине, что ты собираешься править код в уже загруженной библиотеке и после вызова точки входа.
← →
BiN © (2004-03-18 15:32) [55]Удалено модератором
Примечание: Дубль
← →
BiN © (2004-03-18 15:32) [55]Удалено модератором
Примечание: Дубль
← →
Aleksey Pavlov © (2004-03-18 15:59) [56]>> BiN:
можно полученный в результате код посмотреть?
164142@_NO_SPAM_PLZ_mail.ru
← →
Aleksey Pavlov © (2004-03-18 15:59) [56]>> BiN:
можно полученный в результате код посмотреть?
164142@_NO_SPAM_PLZ_mail.ru
← →
BiN © (2004-03-18 17:21) [57]Готовый проект я позже выложу где-нибудь в инете, а принцип объяснить могу и сейчас - к тому же он оказался прост до безобразия :). Как уже упоминалось, все сводится к изменению адреса в инструкции вызова в одной из вложеных в LdrLoadDll функций.
Сама LdrLoadDll выглядит примерноо так в переводе на дельфи :)
function LdrLoadDll(PathToFile:Pchar;
Flags:ULONG;
ModuleFileName:PNICODE_STRING;
var ModuleHandle:DWORD); stdcall;
begin
MapDataAndCreateIAT; <<Более подробно можно посмотреть по
ссылке, указанной в [47]
...
call offset // где offset - это смещение на функцию
LdrpDllEntryPointCaller см [47]
end;
Этот последний вызов и требуется найти и изменить. Здесь и возникают проблемы с несовместимостью OS и как следствие, со сдвигами адресов и т.д. Свен Шнайбер борется с этим с помощью отладочных файлов, кто-то еще находу анализирует код LdrLoadDll и патчит его начало.
Но ведь можно сократить наш поиск, элементарно осуществив его с конца, из недр своей подгружаемой библиотеки. Другими словами, функция определяющая адрес находится не в теле программы, а в библиотеке, что может создавать некоторые неудобства, но не тем кто, кто хочет осуществлять перехват в адресном пространстве другого процесса. На данный момент требуемый адрес находится по ссылкам оставляемым в стеке "шапками" процедур вида
push ebp
mov ebp, esp
Так как нужно определить всего лишь вторую ссылку, то и вероятность ошибки довольно мала. Точнее, этот метод будет работать железно при условии(!), что вызывающая Dllmain функция начинается с вышеуказанной шапки. Вуаля.
← →
BiN © (2004-03-18 17:21) [57]Готовый проект я позже выложу где-нибудь в инете, а принцип объяснить могу и сейчас - к тому же он оказался прост до безобразия :). Как уже упоминалось, все сводится к изменению адреса в инструкции вызова в одной из вложеных в LdrLoadDll функций.
Сама LdrLoadDll выглядит примерноо так в переводе на дельфи :)
function LdrLoadDll(PathToFile:Pchar;
Flags:ULONG;
ModuleFileName:PNICODE_STRING;
var ModuleHandle:DWORD); stdcall;
begin
MapDataAndCreateIAT; <<Более подробно можно посмотреть по
ссылке, указанной в [47]
...
call offset // где offset - это смещение на функцию
LdrpDllEntryPointCaller см [47]
end;
Этот последний вызов и требуется найти и изменить. Здесь и возникают проблемы с несовместимостью OS и как следствие, со сдвигами адресов и т.д. Свен Шнайбер борется с этим с помощью отладочных файлов, кто-то еще находу анализирует код LdrLoadDll и патчит его начало.
Но ведь можно сократить наш поиск, элементарно осуществив его с конца, из недр своей подгружаемой библиотеки. Другими словами, функция определяющая адрес находится не в теле программы, а в библиотеке, что может создавать некоторые неудобства, но не тем кто, кто хочет осуществлять перехват в адресном пространстве другого процесса. На данный момент требуемый адрес находится по ссылкам оставляемым в стеке "шапками" процедур вида
push ebp
mov ebp, esp
Так как нужно определить всего лишь вторую ссылку, то и вероятность ошибки довольно мала. Точнее, этот метод будет работать железно при условии(!), что вызывающая Dllmain функция начинается с вышеуказанной шапки. Вуаля.
← →
Игорь Шевченко © (2004-03-18 17:43) [58]
> Так как нужно определить всего лишь вторую ссылку, то и
> вероятность ошибки довольно мала. Точнее, этот метод будет
> работать железно при условии(!), что вызывающая Dllmain
> функция начинается с вышеуказанной шапки.
Это все будет работать до Windows XP (и, соответственно, всех более поздних версий). Свен Шрайбер не зря ведь рекомендует пользоваться символьной информацией.
> элементарно осуществив его с конца, из недр своей подгружаемой
> библиотеки. Другими словами, функция определяющая адрес
> находится не в теле программы, а в библиотеке, что может
> создавать некоторые неудобства, но не тем кто, кто хочет
> осуществлять перехват в адресном пространстве другого процесса
Идея интересная. Но LdrpLoadDll не начинается с той шапки в указанных мной версиях Windows.
← →
Игорь Шевченко © (2004-03-18 17:43) [58]
> Так как нужно определить всего лишь вторую ссылку, то и
> вероятность ошибки довольно мала. Точнее, этот метод будет
> работать железно при условии(!), что вызывающая Dllmain
> функция начинается с вышеуказанной шапки.
Это все будет работать до Windows XP (и, соответственно, всех более поздних версий). Свен Шрайбер не зря ведь рекомендует пользоваться символьной информацией.
> элементарно осуществив его с конца, из недр своей подгружаемой
> библиотеки. Другими словами, функция определяющая адрес
> находится не в теле программы, а в библиотеке, что может
> создавать некоторые неудобства, но не тем кто, кто хочет
> осуществлять перехват в адресном пространстве другого процесса
Идея интересная. Но LdrpLoadDll не начинается с той шапки в указанных мной версиях Windows.
← →
BiN © (2004-03-18 17:53) [59]... LdrpLoadDll не начинается с той шапки
в том-то и дело, что в моем методе нет зависимости от LdrpLoadDll, т.к. она вызывается где-то "посередине" иерархии вложенных функций . Что ж, из принципа придется сегодня ставить XP :)
← →
BiN © (2004-03-18 17:53) [59]... LdrpLoadDll не начинается с той шапки
в том-то и дело, что в моем методе нет зависимости от LdrpLoadDll, т.к. она вызывается где-то "посередине" иерархии вложенных функций . Что ж, из принципа придется сегодня ставить XP :)
← →
BiN © (2004-03-18 20:20) [60]Проведенное тестирование на MS Windows XP Professional SP1, позволяет с уверенностью утверждать, что предложенный мной метод увпешно работает и на этой ОС.
← →
BiN © (2004-03-18 20:20) [60]Проведенное тестирование на MS Windows XP Professional SP1, позволяет с уверенностью утверждать, что предложенный мной метод увпешно работает и на этой ОС.
← →
Игорь Шевченко © (2004-03-19 10:18) [61]Код на whitefranz@hotmail.com не затруднит отправить ?
← →
Игорь Шевченко © (2004-03-19 10:18) [61]Код на whitefranz@hotmail.com не затруднит отправить ?
← →
SPeller © (2004-03-21 17:01) [62]Товарищи, если я что-то не догоняю, то извините пожалуйста. Если можно, то расскажите мне, бестолковому, что мешает загрузить библиотеку через CreateFileMapping, сделать все нужные поправки, о которых я говорил ранее, и после этого вызвать DllMain ?
← →
SPeller © (2004-03-21 17:01) [62]Товарищи, если я что-то не догоняю, то извините пожалуйста. Если можно, то расскажите мне, бестолковому, что мешает загрузить библиотеку через CreateFileMapping, сделать все нужные поправки, о которых я говорил ранее, и после этого вызвать DllMain ?
← →
Игорь Шевченко © (2004-03-21 22:39) [63]SPeller © (21.03.04 17:01)
Это называется - написать свой загрузчик. Я там ссылочку на MSDN RE давал, почитай, чем занимается загрузчик.
← →
Игорь Шевченко © (2004-03-21 22:39) [63]SPeller © (21.03.04 17:01)
Это называется - написать свой загрузчик. Я там ссылочку на MSDN RE давал, почитай, чем занимается загрузчик.
← →
Alexander666 © (2004-03-21 22:50) [64]А на адрес alexj_8@hotmail.com тоже можно отправить?
← →
Alexander666 © (2004-03-21 22:50) [64]А на адрес alexj_8@hotmail.com тоже можно отправить?
← →
BiN © (2004-03-22 09:39) [65]SPeller © (21.03.04 17:01) [62]
Здесь можно посоветовать почитать статью, где описываются минимальные действия по созданию загрузчика на дельфи, но даже там в результате получается несколько ущербный вариант.
http://rsdn.ru/article/baseserv/peloader.xml
← →
BiN © (2004-03-22 09:39) [65]SPeller © (21.03.04 17:01) [62]
Здесь можно посоветовать почитать статью, где описываются минимальные действия по созданию загрузчика на дельфи, но даже там в результате получается несколько ущербный вариант.
http://rsdn.ru/article/baseserv/peloader.xml
← →
Игорь Шевченко © (2004-03-22 10:28) [66]BiN © (22.03.04 09:39)
Проверил я, как и обещал в письме, все работает, но мне до сих пор непонятно одно - как можно убедиться в перехваченной точке, что DLL загружена и ее разделы импорта настроены нужным образом.
Насколько я понял, ты перехватываешь вызов той программы, которая вызывает внутри себя DllMain. Идея интересная, но вопрос остается...
← →
Игорь Шевченко © (2004-03-22 10:28) [66]BiN © (22.03.04 09:39)
Проверил я, как и обещал в письме, все работает, но мне до сих пор непонятно одно - как можно убедиться в перехваченной точке, что DLL загружена и ее разделы импорта настроены нужным образом.
Насколько я понял, ты перехватываешь вызов той программы, которая вызывает внутри себя DllMain. Идея интересная, но вопрос остается...
← →
BiN © (2004-03-22 11:13) [67]Игорь Шевченко © (22.03.04 10:28) [66]
... как можно убедиться в перехваченной точке, что DLL загружена и ее разделы импорта настроены нужным образом
Обязательно настроены, ведь без этого работа самой Dllmain была бы некорректна.
Насколько я понял, ты перехватываешь вызов той программы, которая вызывает внутри себя DllMain.
Немного путано, но попробую разобраться... Дело в том, что этот метод можно использовать не только при внедрении своего кода в другие процессы, а, например, для защиты от всё того же внедрения.
В данном же случае требуется перехватить любые попытки вызова функции A, как в a) теле программы так и в b) теле DllMain при динамической загрузке. Это решается просто, если исследуемый процесс создавать самим, т.е. использовать отработанную схему:
CREATE_SUSPENDED
внедрение нашей длл, в кот. происходит:
правка IAT
правка адреса в ntdll, кот-ю, кстати, возможно придется делать в новом потоке, а не изнутри процедуры точки входа нашей внедренной длл - я, к сожалению, пока не тестировал все варианты.
ResumeThread
Или, может, я не до конца понял вопрос?
← →
BiN © (2004-03-22 11:13) [67]Игорь Шевченко © (22.03.04 10:28) [66]
... как можно убедиться в перехваченной точке, что DLL загружена и ее разделы импорта настроены нужным образом
Обязательно настроены, ведь без этого работа самой Dllmain была бы некорректна.
Насколько я понял, ты перехватываешь вызов той программы, которая вызывает внутри себя DllMain.
Немного путано, но попробую разобраться... Дело в том, что этот метод можно использовать не только при внедрении своего кода в другие процессы, а, например, для защиты от всё того же внедрения.
В данном же случае требуется перехватить любые попытки вызова функции A, как в a) теле программы так и в b) теле DllMain при динамической загрузке. Это решается просто, если исследуемый процесс создавать самим, т.е. использовать отработанную схему:
CREATE_SUSPENDED
внедрение нашей длл, в кот. происходит:
правка IAT
правка адреса в ntdll, кот-ю, кстати, возможно придется делать в новом потоке, а не изнутри процедуры точки входа нашей внедренной длл - я, к сожалению, пока не тестировал все варианты.
ResumeThread
Или, может, я не до конца понял вопрос?
← →
Игорь Шевченко © (2004-03-22 11:52) [68]BiN © (22.03.04 11:13)
> Обязательно настроены, ведь без этого работа самой Dllmain
> была бы некорректна.
Э....ты же перехватываешь не то место, где вызывается DLLMain, а перехватываешь вызов той процедуры, которая вызывает DllMain внутри себя, если я правильно в коде разобрался. Или прокомментируй каждую команду в процедуре, начинающуюся с
{$O-} {<-- на всякий случай}
Я хочу сказать, а не вызывается ли настройка импорта (или еще чего-нибудь важного) в промежутке между адресом, который ты перехватил, и точкой вызова DllMain ?
← →
Игорь Шевченко © (2004-03-22 11:52) [68]BiN © (22.03.04 11:13)
> Обязательно настроены, ведь без этого работа самой Dllmain
> была бы некорректна.
Э....ты же перехватываешь не то место, где вызывается DLLMain, а перехватываешь вызов той процедуры, которая вызывает DllMain внутри себя, если я правильно в коде разобрался. Или прокомментируй каждую команду в процедуре, начинающуюся с
{$O-} {<-- на всякий случай}
Я хочу сказать, а не вызывается ли настройка импорта (или еще чего-нибудь важного) в промежутке между адресом, который ты перехватил, и точкой вызова DllMain ?
← →
BiN © (2004-03-22 12:16) [69]
...ты же перехватываешь не то место, где вызывается DLLMain, а перехватываешь вызов той процедуры, которая вызывает DllMain внутри себя
Совершенно верно
... а не вызывается ли настройка импорта (или еще чего-нибудь важного) в промежутке между адресом, который ты перехватил, и точкой вызова DllMain ?
эта процедура в ntdll w2ksp4 в переводе на паскаль выглядит примерно так (ассемблерный код можно посмотреть самому):
function LdrpDllEntryPointCaller(DllEntryPoint:TDllEntryPoint; hinstDLL:HMODULE; fdwReason:DWORD; lpvReserved:Pointer):BOOL; stdcall;
begin
Result:=DllEntryPoint(hinstDll, fdwReason, lpvReserved);
end;
Причем, никаких иных действий эта функция не производит. Она же получает управление и для вызова Dllmain при выгрузке библиотеки. Следовательно, логично предположить, что в ней не будет происходить какие-либо изменения IAT - зачем при выгрузке библиотеки настраивать таблицу импорта.
Следует отметить, что описанный в предыдущих постах пример не затрагивает перехват Dllmain при вызове FreeLibrary и т.п., в этом просто нет необходимости.
← →
BiN © (2004-03-22 12:16) [69]
...ты же перехватываешь не то место, где вызывается DLLMain, а перехватываешь вызов той процедуры, которая вызывает DllMain внутри себя
Совершенно верно
... а не вызывается ли настройка импорта (или еще чего-нибудь важного) в промежутке между адресом, который ты перехватил, и точкой вызова DllMain ?
эта процедура в ntdll w2ksp4 в переводе на паскаль выглядит примерно так (ассемблерный код можно посмотреть самому):
function LdrpDllEntryPointCaller(DllEntryPoint:TDllEntryPoint; hinstDLL:HMODULE; fdwReason:DWORD; lpvReserved:Pointer):BOOL; stdcall;
begin
Result:=DllEntryPoint(hinstDll, fdwReason, lpvReserved);
end;
Причем, никаких иных действий эта функция не производит. Она же получает управление и для вызова Dllmain при выгрузке библиотеки. Следовательно, логично предположить, что в ней не будет происходить какие-либо изменения IAT - зачем при выгрузке библиотеки настраивать таблицу импорта.
Следует отметить, что описанный в предыдущих постах пример не затрагивает перехват Dllmain при вызове FreeLibrary и т.п., в этом просто нет необходимости.
← →
Игорь Шевченко © (2004-03-22 13:26) [70]Да, нашел. Называется LdrpCallInitRoutine. В этом случае действительно DLL готова к выполнению функции инициализации.
← →
Игорь Шевченко © (2004-03-22 13:26) [70]Да, нашел. Называется LdrpCallInitRoutine. В этом случае действительно DLL готова к выполнению функции инициализации.
← →
pasha_golub © (2004-03-22 13:46) [71]Напишите, пожалуйста, статью по этому поводу и код исходный на pavel.golub@farata.kr.ua киньте, пожалуйста.
← →
pasha_golub © (2004-03-22 13:46) [71]Напишите, пожалуйста, статью по этому поводу и код исходный на pavel.golub@farata.kr.ua киньте, пожалуйста.
Страницы: 1 2 вся ветка
Форум: "WinAPI";
Текущий архив: 2004.04.11;
Скачать: [xml.tar.bz2];
Память: 0.79 MB
Время: 0.04 c