Мастера DELPHI (документация, исходники, скачать)

Основная («Начинающим»)/ Базы / WinAPI / Компоненты / Сети / Media / Игры / Corba и COM / KOL / FreePascal / .Net / Прочее / RSDN.ORG

« предыдущая ветвь | форум | следующая ветвь »

Хендл KERNEL32 [D3, D4, D5, D6, D7, Win95/98, WinME, NT4, Win2k, WinXP]

Страницы: 1 2 3 >
-SeM- © (2004-11-23 12:17:00)
Как узнать хендл (адрес загрузки) kernel32.dll без использования API?
Можно ли со 100% уверенностью ожидать ее загрузки по $BFF60000? Или могут быть иные случаи?

-SeM- (2004-11-25 17:38:00) [1]
Kerk © (25.11.04 17:32) [40]
Во, ото уже что-то. Буду пробовать.

2All
Всем спасибо

Kerk (2004-11-25 17:32:00) [2]
Промотать цепочку SEH до конца. Последний элемент указывает куда-то внутри кернела. Выровнять на границу $1000 и сдвигать вверх с шагом $1000 проверяй наличие PE-заголовка. Платформонезависимый способ.

n0name (2004-11-25 17:29:00) [3]
-SeM- (25.11.04 15:49) [37]
Можешь убрать это(для кернела не надо).
Можешь сам дописать функцию чтобы она находила ntdll.dll(она первая в списке в PEB(смотри исходник)) и xGetProcAddress для 2х причин.

Digitman (2004-11-25 16:31:00) [4]

> -SeM- (25.11.04 15:49) [37]

ладныть, тезка .. уговорил ... более не "переживаю" ... как тебе будет угодно.

жаль вот только, что силушку молодецкую-программистскую почем зря прожигаешь)

-SeM- (2004-11-25 15:49:00) [5]
n0name (25.11.04 14:03) [34]
Да, признаю, не досмотрел...
Как ты думаешь, по каким двум причинам мне не нравится следующее
function LdrLockLoaderLock(Flags: DWORD; result, Magic: PDWORD): NTSTATUS; stdcall; external' ntdll.dll'; function LdrUnlockLoaderLock(Flags, Magic: DWORD): NTSTATUS; stdcall; external' ntdll.dll';

Digitman © (25.11.04 14:17) [36]
Сергей, тезка, да не переживай ты так :)
Я же не говорю, что не буду использовать API, тем более куда я без нее :)
Я говорю "спортивный интерес", пусть даже с твоей точки зрения нездоровый.

Digitman (2004-11-25 14:17:00) [6]

> Нет у меня чужого процесса. Только свой. И только для него
> нужен этот адрес, вне зависимости в какой ОС он работает.

так ведь блажь ! ну блажь же ! самая настоящая !

на кой вообще ляд тогда ОС-платформа с ее АПИ нужна ? если даже в своем процессе ты отказываешься от того, что тебе дает АПИ платформы ? нахаляву ? бери и пользуй, так сказать ? быстро и беспроблемно ? не выпендриваясь и не изобретая велосипедов ?

n0name (2004-11-25 14:03:00) [7]
-SeM- (25.11.04 12:14) [29]
Рядом с xGetProcessAddress лежит мой же xGetModuleHandle.(Отвечаю и на первый и на второй вопросы).

http://delphimaster.ru/cgi-bin/forum.pl?id=1100098886&n=5&p=4

n0name (2004-11-25 13:57:00) [8]
-SeM- (25.11.04 12:14) [29]
Рядом с xGetProcessAddress лежит мой же xGetModuleHandle.(Отвечаю и на первый и на второй вопросы).

http://delphimaster.ru/cgi-bin/forum.pl?id=1100098886&n=5&p=4

-SeM- (2004-11-25 13:47:00) [9]
Digitman © (25.11.04 13:22) [32]

> одним и тем же и в своем и в чужом процессе

Нет, не уводи меня в сторону. Это я даже не могу поставить под сомнение.
Нет у меня чужого процесса. Только свой. И только для него нужен этот адрес, вне зависимости в какой ОС он работает.

Чтобы зря не толочь воду, давай я для начала попробую [4]. А будут вопросы (думаю будут :)) - вот тогда и спрошу.

Digitman (2004-11-25 13:22:00) [10]

> по-поводу приведенной схемы смущает только это
>
> > [1] адрес этот зависит и от конкретной ОС-платформы и
> от версии kernel32

не понимаю почему тебя это смущает..

каким бы ни был этот адрес, он будет одним и тем же и в своем и в чужом процессе

> речь идет об одном и том же модуле?

ну да, о kernel32.dll, о каком же еще ?

-SeM- (2004-11-25 13:13:00) [11]
Digitman © (25.11.04 12:39) [30]
Мне кажется ты связываешь мой вопрос с "самодостаточным кодом" :)
Об этом я пока не задумывался. А по-поводу приведенной схемы смущает только это

> [1] адрес этот зависит и от конкретной ОС-платформы и от версии kernel32

> [30] полагаясь на факт неизменности адреса загрузки этого модуля

Ведь речь идет об одном и том же модуле?

ЗЫ Вариант [4], честно говоря, еще не пробовал - нет времени.

Digitman (2004-11-25 12:39:00) [12]

> -SeM- (25.11.04 12:14) [29]

ну согласен .. может я и неверно истолковал твой комментарий по поводу КМД ..

но в общем и целом ответ на вопрос свой ты уже получил : полагаясь на факт неизменности адреса загрузки этого модуля, в "своем" процессе получить адрес т.входа в kernel32.GetProcAddress (hKernel32) и просто передать этот адрес параметром в стартуемый тобой удаленный трэд - он и там, в "чужом" АП, будет столь же актуален и корректен, как и в "своем" АП .. а далее логика удаленного трэда проста : получаешь адрес т.входа в hKernel32.LoadLibrary() и далее ты волен грузить любой нужный тебе модуль (если он уже загружен, ты, инкрементировав ссылку на него, просто получишь его хэндл) и, получив этот хэндл, далее получать т.входа экспортируемые этим модулем ф-ции, чтобы их беспроблемно вызывать по необх-ти

вот такая схема какие-то сомнения вызывает у тебя ?

-SeM- (2004-11-25 12:14:00) [13]
n0name (25.11.04 11:37) [27]
Да есть у меня GetProcAddress (не xGetProcAddress). Или же в хGetProcAddress реализован поиск адреса загрузки кернел?

> kernel32.dll всегда 2ая в списке модулей

Модулей чего?

Digitman © (25.11.04 11:48) [28]
Повторюсь еще раз. Не надо мне драйверов режима ядра. Нет ни желания, ни обходимости. Была когда-то ветка, в которой обсуждалось и создание драйвера в Delphi, и то что ее линкер в любом случае добавляет импорт. Вот и стал разбираться, пробовать а можно ли без этого. Можно. Но для того чтобы закрыть приложение без "выкрутасов с RET" (Digitman © (24.11.04 10:37) [82] в соседней ветке) нужно использовать "как минимум одну ф-цию - ExitProcess(), поскольку в соответствии с док-цией Майкрософт вызов этой ф-ции есть предпочтительный способ нормального завершения процесса", для чего как минимум нужно знать хендл kernel32 и аналог GetProcAddress. Со вторым проблем нет.
Надеюсь что я объяснил свой интерес к "определению адреса kernel32как модуля искл-но польз.режима"

Digitman (2004-11-25 11:48:00) [14]

> Уже не раз подымался вопрос - можно ли написать драйвер
> в Delphi. Обычно говорят - не получится

да, от начала и до конца не получится

хотя бы потому что делфевый линкер не имеет опций сборки, соответствующих требованиям системы для драйверов.

но вовсе не потому делфевый линкер включает в модуль драйвера IAT : ничто не мешает драйверу иметь стат.импорт (загляни любой утилиткой просмотра зависимостей в любой полноценный NT KMD и увидишь там ссылку хотя бы на ntoskrnl)

другой вопрос, что КMD не вправе импортировать и использовать сист.модули режима пользователя, хотя бы тот же kernel32.dll, ссылку на который линкер по дифолту включает в IAT из-за того что ссылки на него имеются в SysInit.

поэтому опять же непонятна связь твоего "спортивного" интереса к KMD и вопроса про определение адреса kernel32 как модуля искл-но польз.режима

n0name (2004-11-25 11:37:00) [15]
-SeM- (25.11.04 10:51) [26]
xe xe. Я сделал чистую имп. таблицу. Исходники показывал ищи xGetProcAddress. Но можно и проще kernel32.dll всегда 2ая в списке модулей.

-SeM- (2004-11-25 10:51:00) [16]
Leonid Troyanovsky (25.11.04 10:13) [24]
Да нет, спасибо. Мне так не нравится.

Digitman © (25.11.04 10:29) [25]
Ну почему же сразу бурную "черную деятельность", можно просто деятельность.
А зачем? Не знаю... Наверное спортивный интерес. Уже не раз подымался вопрос - можно ли написать драйвер в Delphi. Обычно говорят - не получится, т.к. модуль в любом случае будет иметь импорт из-за линковщика, что не допустимо для драйверов. Мне вообще-то драйвера не надо, а вот стало интересно - а смогу ли я отказаться от стат. импорта. А зачем? Не знаю, сделаю - потом буду думать зачем оно мне :)

С уважением

Digitman (2004-11-25 10:29:00) [17]

> приложение имеет девственно чистую таблицу импорта

ты хоть пояснил бы, зачем ты так извращаешься, пытаясь создать "девственно чистое" приложение ..

я могу еще понять, если твоя цель - внедрение кода в чужой процесс и старт этого кода в виде удаленного трэда, при том что этот тред разворачивает свою бурную "черную деятельность" т.с. с нуля, безо всяких IAT, т.е. имея адрес kernel32 получает точку входа в GetProcAddress() и с этого момента получает независимый от IAT доступ ко всем нужным ему модулям, как уже загруженным, так и требуемым к загрузке по ходу дела ..

Leonid Troyanovsky (2004-11-25 10:13:00) [18]

> -SeM- (25.11.04 09:57) [23]

> А что тут смешного? Действительно приложение имеет девственно
> чистую таблицу импорта. Все адреса необходимых внешних функций
> определяются динамически аналогом GetProcAddress (и ExitProcess
> тоже). Одно только пока не реализовано - определение адреса
> загрузки kernel32.dll - зашито жестко. На возможное замечание
> о линковщике скажу сразу - используется замена модулей system
> и sysinit и компилируется в среде Delphi обычным образом.

Ну, я ж не предполагал, что дело зашло так далеко :)
Могу лишь предложить устанавливать оный адрес, скажем
при установке приложения. Т.е., установщик определит
нужный адрес и пропатчит екзешник (достаточно 4 байт).

--
С уважением, LVT.

-SeM- (2004-11-25 09:57:00) [19]
Leonid Troyanovsky (24.11.04 21:50) [22]

А что тут смешного? Действительно приложение имеет девственно чистую таблицу импорта. Все адреса необходимых внешних функций определяются динамически аналогом GetProcAddress (и ExitProcess тоже). Одно только пока не реализовано - определение адреса загрузки kernel32.dll - зашито жестко. На возможное замечание о линковщике скажу сразу - используется замена модулей system и sysinit и компилируется в среде Delphi обычным образом.

Leonid Troyanovsky (2004-11-24 21:50:00) [20]

> -SeM- (24.11.04 16:52) [21]
> > Так что, можешь смело пользовать GetModuleHandle
>
> Да не могу. Он же сидит в кернел, адрес которого и хочу
> определить. Нет у меня ни одного импорта (и ExitProcess
> тоже).

Чего-чего нет?
А чего мы тут распинались? :)

--
С уважением, LVT.

PS Т.е., пробывать слабо.

Страницы: 1 2 3 >

Наверх

	« предыдущая ветвь \| форум \| следующая ветвь »