Собственная GetModuleHandle без ассемблерных вставок (cpp)

поспорили с товарищем о том, что возможно написать DLL с пустой таблицей импорта... то есть, что вызовы функций будут происходить динамически, и просмотрев таблицу импорта или поискав строки среди pe-формата нельзя было судить о функционале DLL... как бы в этом нет ничего сложного, нужно лишь написать свою функцию определения базы необходимой DLL в процессе и функцию определения адреса функции из этой DLL... со второй функцией проблем нет, но как определить базу загруженной процессом DLL? я думал делать так: через TEB найти PEB, и в PEB'е пройтись по списку загруженных библиотек... как бы вариант нормальный, но как определить адрес TEB без ассемблерных вставок (такого условие спора, только си и сипп)? или может есть какой-нить альтернативный вариант?

 

Узнай адрес куда PEB грузится в проге. потом ручками в коде вбей адрес...
без асм вставок...

 

NtQueryInformationProcess()

 

...поспорили с товарищем о том, что возможно написать DLL с пустой таблицей импорта...
ммм...

 

хех... это к сожаление не вариант... так как DLL будет грузиться в разные процессы на xp, vista (x32 и x64)...

 

Ну вообщето это вариант, для того чтобы выиграть спор......
а иначе, при ваших условиях, никак этого не сделать.

 

на вскидку
- установить сех
- пройти стэк к младшим адресам (адрес в стеке - любой адрес локальной переменной) и найти адрес обработчика (его мы знаем)
- раскрутить цепочку до конечного обработчика -> адрес kernel32.dll
- по адресу найти базу, по экспорту найти LoadLibrary/GetProcAddress

но это через одно место

 

да и по поводу NtQueryInformationProcess()
вызывайте напрямую через шлюз. Этот метод лучше, чем через seh.

 

в msvc есть интринсик

Код (Text):

1. __readfsdword(
2.    unsigned long Offset
3. );

http://msdn.microsoft.com/en-us/library/3887zk1s%28VS.80%29.aspx

 

в msvc есть вообще много полезных вещей, если не полениться и справку к нему почитать %)

 

алсо DllEntryPoint вроде бы вызывает ntdll - вот вам и адрес внутри ntdll

 

Rel
Задача бредовая. Согласен с izlesa, юзайте шлюзы напрямую. Хотя чтобы сискол/инт вызвать тоже вставки нужны наверно хз. Как решение - трассировка диспетчера исключений, чтобы начать трейс нужно вызвать исключение, взведя TF, это нужно флажки изменить.. Можно изменить сегментный регистр и обратится к памяти, но чтоб загрузить нужный селектор нужно тоже на асме. Лучше наверно найти ntdll(xthtp через сепшены) и оттуда заюзать NtCurrentTeb и пр.
Скрипты удалить, такие извращения вызванные проблемой переносимости для виндоз недопустимы

 

да... согласен...

я думаю, я все же добавлю в DLL файлик на асме (под x64 асм-вставки не работают), так как без него тут видимо не обойтись... спасибо всем вам за помощь!

 

дык тебе же кинули ссылку на __readfsdword

 

PTEB WINAPI NtCurrentTeb(); -но тоже что и со вставками 3 строчки

 

для тех кто в танке

берем асм код

Код (Text):

1.  mov ebx, fs:[ 0x30 ]       // get a pointer to the PEB
2.  mov ebx, [ ebx + 0x0C ]    // get PEB->Ldr
3.  mov ebx, [ ebx + 0x14 ]    // get PEB->Ldr.InMemoryOrderModuleList.Flink (1st entry)
4.  mov ebx, [ ebx ]           // get the next entry (2nd entry)
5.  mov ebx, [ ebx ]           // get the next entry (3rd entry)
6.  mov ebx, [ ebx + 0x10 ]    // get the 3rd entries base address (kernel32.dll)

и пишем его на С

Код (Text):

1. #include <intrin.h> // для __readfsdword
2.  
3. int main()
4. {
5.    char* p = (char*)__readfsdword(0x30);
6.    p = *(int*)(p + 0x0C)
7.    p = *(int*)(p + 0x14)
8.    p = *(int*)p
9.    p = *(int*)p
10.    p = *(int*)(p + 0x10)
11.    return (int)p;
12. }

 

GoldFinch
Исчо не факт что либы будут располагаться в таком порядке
Надо имя либы узнавать и сранивать с необходимым.

 

Вообщето всегда
program_name.exe
ntdll.dll
kernel32.dll

 

d2k9
после __readfsdword(0x30);
можно делать чтоугодно

 

RET
Да невсегда. В той же семёрке