Поток без длл или самодостаточный код

← →
Digitman © (2004-11-24 08:18) [80]

> Piter © (23.11.04 23:26) [78]

имелся ввиду не какой-то конкретный адрес, а то что в рамках одной и той же сессии ОС образ модуля kernel32 в АП всех использующих его приложениях будет находиться по одному и тому же адресу, поскольку как правило статически загружается одним из первых системных модулей, импортируемых win32-приложениями.

← →
n0name (2004-11-24 09:36) [81]

>Игорь Шевченко © (24.11.04 00:13) [79]
Спасибо за информацию, обязательно напишу.

>Digitman © (24.11.04 08:18) [80]
Вот именно, как правило :)
Win32-приложение может и не импортировать никаких функций из kernel32.dll, но он будет грузиться вторым(после ntdll.dll).

← →
Digitman © (2004-11-24 10:37) [82]

> n0name (24.11.04 09:36) [81]

> Win32-приложение может и не импортировать никаких функций
> из kernel32.dll

Нормальное (без выкрутасов с RET) win32-приложение импортирует из kernel32.dll как минимум одну ф-цию - ExitProcess(), поскольку в соответствии с док-цией Майкрософт вызов этой ф-ции есть предпочтительный способ нормального завершения процесса.

> будет грузиться вторым(после ntdll.dll)

ну и что ? предпочтительный адрес загрузки kernel32 выбран разработчиком ОС таким образом, что вынужденное изменение его системой в подавляющем большинстве не требуется. Особенно это касается НТ-платформы, где kernel32 грузится в верхние (системные) 2Гб АП процесса, куда при всем желании пользовательские модули загрузить (дабы вынудить систему "подвинуть" kernel32) не удастся. К тому же докум.загрузка пользов. PE-модулей осуществляется с пом. LoadLibrary(), которая опять же требует уже загруженной kernel32.
Так что вероятность изменения факт.адреска загрузки kernel32 по отношения к предпочтительному в НТ практически равна нулю. Она (такая вероятность), конечно же, больше нуля в Маздае, но с учетом того, что нормальные приложения грузят kernel32 первым модулем в цепочке требуемых к импорту, этой вероятностью опять же можно пренебречь.

В конечном итоге, ДАЖЕ если сомнения существуют, можно просканировать АП целевого процесса на предмет обнаружения какой-либо сигнатуры, идентифицирующей kernel32, и найдя таковую с учетом ее смещения отн-но начала образа получить фактический базовый адрес.

← →
Игорь Шевченко © (2004-11-24 10:59) [83]

Digitman © (24.11.04 10:37) [82]

> Особенно это касается НТ-платформы, где kernel32 грузится
> в верхние (системные) 2Гб АП процесса, куда при всем желании
> пользовательские модули загрузить (дабы вынудить систему
> "подвинуть" kernel32) не удастся

Это ты с Win9x перепутал, извини.

> Так что вероятность изменения факт.адреска загрузки kernel32
> по отношения к предпочтительному в НТ практически равна
> нулю

Теоретически она тоже равна нулю, так как на фиксированные адреса в kernel32 ссылаются другие системные библиотеки. Про попытке запустить программу, которая в адресном пространстве занимает область kernel32.dll такая программа просто не запускается.

← →
Digitman © (2004-11-24 11:04) [84]

> Игорь Шевченко © (24.11.04 10:59) [83]

да, точно, перепутал.
строго наоборот.

> Про попытке запустить программу, которая в адресном пространстве
> занимает область kernel32.dll такая программа просто не
> запускается

и анализ исх.текста это также подтверждает ?

← →
Игорь Шевченко © (2004-11-24 11:30) [85]

Digitman © (24.11.04 11:04) [84]

Нет, исходный текст тут не причем, такая связь при импорте символов устанавливается, насколько мне известно. Опытным путем было установлено, что при попытке залезть в область адресов kernel32.dll программа не запускается из-за того, что kernel32.dll не может быть перемещена.

← →
n0name (2004-11-24 12:06) [86]

>Digitman © (24.11.04 10:37) [82]
На это (ExitProcess) я отвечу : ха!
Никаких извращений - NtTerminateProcess(DWORD(-1), 0).

Что насчёт загрузки кернела, то измени ImageBase в PE-заголовке при компиляции на предпологаемый адрес кернела.

Загрузчик PE ВСЕГДА для Win32-приложений грузит kernel32.dll. Причём обязательно вторым по счету.

← →
Digitman © (2004-11-24 13:16) [87]

> n0name (24.11.04 12:06) [86]

> Никаких извращений - NtTerminateProcess

это ты - про НТ... а про маздайную линейку ?

> Причём обязательно вторым по счету

опять же - а для маздая кто будет первым ?

← →
-SeM- (2004-11-24 16:43) [88]

Digitman © (24.11.04 13:16) [87]

И на маздай то же - ха! Но для этого надо как-то узнать адрес загрузки кернел. Что и пытаюсь определить http://predskazanie-wunschpunsch.ru/view/4-1101201473/&web=1

← →
Xaker © (2004-11-24 17:40) [89]

n0name (24.11.04 12:06) [86]

> Что насчёт загрузки кернела, то измени ImageBase в
> PE-заголовке при компиляции на предпологаемый адрес
> кернела.

Ошибка: Недопустимое перемещение системной DLL

- не хочет запускаться ..

самое интересное, что можно больше сделать и меньше - будет работать ...

← →
Digitman © (2004-11-24 17:41) [90]

> -SeM- (24.11.04 16:43) [88]

ХАкать я бы не посоветовал.

← →
n0name (2004-11-25 11:35) [91]

Digitman мне кажется что Win9X это анахроизм.
У меня его нет, и я не могу программировать под него.

← →
Digitman © (2004-11-25 12:03) [92]

> -SeM- (24.11.04 16:43) [88]
> для этого надо как-то узнать
> адрес загрузки кернел. Что и пытаюсь определить http://predskazanie-wunschpunsch.ru/view/4-1101201473/&web=1

в той ветке ты поехал в совершенно иной огород - создание KMD ..

никак не вяжется что-то поднятая тобой проблема определения адреса загрузки модуля kernel32 как модуля режима пользователя с программированием KMD, использующего модули и ф-ции именно режима ядра, но никак не режима пользователя ..

← →
Digitman © (2004-11-25 12:09) [93]

> мне кажется что Win9X это анахроизм

ну наверно она, эта линейка ОС, потому маздайной и зовется, что изначально рождалась под флагом "Должна умереть") ... что ж, для тебя она уже умерла ... аминь)

← →
-SeM- (2004-11-25 12:21) [94]

Digitman © (25.11.04 12:03) [92]
Да нет, ты не правильно понял. Ответ там же.

n0name (25.11.04 11:35) [91]
А ты, как программист, разве не должен учитывать то, что твоя прога может быть запущена на другой линейке ОС. Или ты предпочитаешь писать в реадми, что прога работает только на NT линейке?

← →
n0name (2004-11-25 14:03) [95]

Digitman © (25.11.04 12:09) [93]
-SeM- (25.11.04 12:21) [94]
Как программист я должен учитывать эту возможность(есть же слабые компы). А как юзер давно простился с линейкой Win9X.
Но еа каждый хитрый болт есть своя хитрая гайка.
Что можно сделать в WinNT+ можно сделать и в Win9X. Вопрос в другом сколько займёт реализация...
Например в Win9X нет NativeAPI. Если хочешь реализуй нужную функцию сам.

← →
n0name (2004-11-25 14:03) [96]

Удалено модератором
Примечание: Дубль

← →
Xaker © (2004-11-28 23:25) [97]

Остался вопрос, а как можно подправить стёа потока, чтобы он был "нормальным" ?

← →
n0name (2004-11-30 10:33) [98]

Для чего тебе "подправлять" стек?

← →
Xaker © (2004-11-30 13:24) [99]

n0name (30.11.04 10:33) [98]
чтобы не выделялся ;))

← →
Digitman © (2004-11-30 13:29) [100]

> Xaker © (30.11.04 13:24) [99]

размер стека трэда задается 2-м параметром при вызове ф-ций CreateThread/CreateRemoteThread

← →
Xaker © (2004-11-30 14:24) [101]

Digitman © (30.11.04 13:29) [100]
ок, спасибо, постараюсь сделать его более "нормальным" :))
- а что там лучше указывать ? - какое значение ?
- чтобя вообще не выделялся ?

← →
TankMan © (2004-11-30 15:01) [102]

Прочитал я эту ветку...и у меня вопрос возник, вы всетаки хотите довести этот код до ~100% вероятности работоспособности или просто так спорите?

← →
n0name (2004-11-30 15:08) [103]

>>n0name
:)) Самый самый верхний :)

TankMan © (30.11.04 15:01) [102]
код работает .. улучшаем . :)

Piter © (30.11.04 21:01) [105]
я сам пока точно не выяснил...

← →
n0name (2004-12-01 10:52) [107]

Если ты про xGetModuleHandle и xGetProcAddress. Я сделал новую версию. В прошлых было несколько багов, теперь их нет.

n0name (01.12.04 10:52) [107]
выкладывай :))
потестим :)

← →
n0name (2004-12-01 13:47) [109]

unit xFuncs; interface uses CommonTypes, StrFuncs, PETypes, xTypes; function xGetModuleHandle(ModuleName: PChar): HMODULE; function xGetProcAddress(hMod: HMODULE; ProcName: PChar): Pointer; implementation var LdrLockLoaderLock: function (Flags: DWORD; result, Magic: PDWORD): NTSTATUS; stdcall; LdrUnlockLoaderLock: function (Flags, Magic: DWORD): NTSTATUS; stdcall; function GetCurrentPEB: PPEB; asm mov eax, fs:[30h] mov result, eax end; function xGetProcAddress(hMod: HMODULE; ProcName: PChar): Pointer; var ExportDir: PImageExportDirectory; i, IndInAddr: DWORD; begin result:=nil; ExportDir:=PImageExportDirectory(PImageNtHeaders(hMod+DWORD(PImageDosHeader(hMod).e_lfanew)).OptionalHeader. DataDirectory[IMAGE_DIRECTORY_ENTRY_EXPORT].VirtualAddress+hMod); for i:=0 to ExportDir.NumberOfNames-1 do begin if ComparePCharStrings(PChar(PDWORD(DWORD(ExportDir.AddressOfNames)+hMod+i*4)^+hMod), ProcName) then begin IndInAddr:=PWORD(DWORD(ExportDir.AddressOfNameOrdinals)+hMod+i*2)^; result:=Pointer(PDWORD(DWORD(ExportDir.AddressOfFunctions)+hMod+IndInAddr*4)^+hMod); end; end; end; function GetNtDLLHandle: HModule; begin result:=DWORD(PLdrDataTableEntry(PLdrDataTableEntry(GetCurrentPEB.Ldr.InLoadOrderModuleList.FLink)^. InLoadOrderLinks.Flink)^.DllBase); end; procedure InitAPI; var NtDLLHandle: THandle; begin NtDLLHandle:=GetNtDLLHandle; @LdrLockLoaderLock:=xGetProcAddress(NtDLLHandle, "LdrLockLoaderLock"); @LdrUnlockLoaderLock:=xGetProcAddress(NtDLLHandle, "LdrUnlockLoaderLock"); end; function xGetModuleHandle(ModuleName: PChar): HMODULE; var FirstMod: Pointer; CurrentMod: TLdrDataTableEntry; LdrLockMagic: DWORD; begin InitAPI; result:=0; LdrLockLoaderLock(0, nil, @LdrLockMagic); FirstMod:=GetCurrentPEB.Ldr.InLoadOrderModuleList.FLink; CurrentMod:=PLdrDataTableEntry(FirstMod)^; repeat if FirstMod=CurrentMod.InLoadOrderLinks.FLink then exit; if CompareMultibyteWithAnsi(CurrentMod.BaseDllName.Buffer, ModuleName) then begin result:=DWORD(CurrentMod.DllBase); exit; end; CurrentMod:=PLdrDataTableEntry(CurrentMod.InLoadOrderLinks.Flink)^; until (not true); LdrUnlockLoaderLock(0, LdrLockMagic); end; end.

n0name (01.12.04 13:47) [109]

Я бы тебе посоветовал переделать функции LdrLockLoaderLock и LdrUnlockLoaderLock

на

type TLdrLockLoaderLock: function (Flags: DWORD; Aresult, Magic: PDWORD): NTSTATUS; stdcall; TLdrUnlockLoaderLock: function (Flags, Magic: DWORD): NTSTATUS; stdcall; var _LdrLockLoaderLock: TLdrLockLoaderLock; _LdrUnlockLoaderLock: TLdrUnlockLoaderLock; procedure InitAPI; var NtDLLHandle: THandle; begin NtDLLHandle:=GetNtDLLHandle; @_LdrLockLoaderLock:=xGetProcAddress(NtDLLHandle, "LdrLockLoaderLock"); @_LdrUnlockLoaderLock:=xGetProcAddress(NtDLLHandle, "LdrUnlockLoaderLock"); end; function LdrLockLoaderLock (Flags: DWORD; Aresult, Magic: PDWORD): NTSTATUS; stdcall; begin if Assigned(_LdrLockLoaderLock) then Result := _LdrLockLoaderLock (Flags, Aresult, Magic) else begin Result := NT_SUCCESS; EnterCriticalSection(CurrentPEB.LoaderLock); end; end; function LdrUnlockLoaderLock (Flags, Magic: DWORD): NTSTATUS; stdcall; begin if Assigned(_LdrUnlockLoaderLock) then Result := _LdrUnlockLoaderLock (Flags, Magic) else begin Result := NT_SUCCESS; LeaveCriticalSection(CurrentPEB.LoaderLock); end; end;

Причина в том, что функции блокировки загрузчика экспортируются из NTDLL только в WinXP, Win2003 и в LongHorn.

Удалено модератором
Примечание: Создание пустых сообщений. Предупреждение тебе

Поток без длл или самодостаточный код Найти похожие ветки