LdrpFindOrMapDll

Привет всем

В общем проблема, пытаюсь сделать загрузку длл с помощью нтддл LdrpWalkImportDescriptor. Но в WOW64 ее попрасту нет, что посоветуете ? Проверял на Win7 x64

 

Напиши свою WalkImport, WalkExport, WalkReloc.

 

Если бы мне это надобыло написал бы, но я хочу снизить размер кода, путем вызова кода загрузчика

 

вам бы мог помочь Клерк, но 1) его больше нет на этом форуме, 2) он не шарит в x64...

а зачем вам это? есть же LdrLoadDll...

 

Просто те длл что у меня будут должны жить только в памяти компа и все

 

Не приходилось разбираться с этой темой, но

Код (Text):

1. 0:000> x ntdll32!*Ldr*Import*
2. 00000000`777de80d ntdll32!LdrpHandleOneOldFormatImportDescriptor = <no type information>
3. 00000000`777deff9 ntdll32!LdrpFixupIATForRelocatedImport = <no type information>
4. 00000000`777ddf50 ntdll32!LdrpLoadImportModule = <no type information>
5. [b]00000000`777ddc84 ntdll32!LdrpProcessStaticImports = <no type information>[/b]
6. 00000000`77840382 ntdll32!LdrpCorProcessImports = <no type information>
7. 00000000`777de25e ntdll32!LdrpRecordStaticImport = <no type information>
8. 00000000`777de379 ntdll32!LdrpHandleNewFormatImportDescriptors = <no type information>
9. 00000000`777dd81d ntdll32!LdrpGetImportAddressTableInfo = <no type information>
10. 00000000`777de291 ntdll32!LdrpHandleOneNewFormatImportDescriptor = <no type information>
11. 00000000`777de8cf ntdll32!LdrpHandleOldFormatImportDescriptors = <no type information>
12. 00000000`77840d71 ntdll32!LdrpMungHeapImportsForTagging = <no type information>

говорит о возможной альтернативе

 

настройка таблицы импорта... да и вообще загрузка PE-файла довольно проста, на этот счет есть куча статей для юных малварщиков... я думаю, что написать свой загрузщик проще, чем искать неэкспортируемые функции в ntdll по отладочной информации (как предлагал Клерк)... если в таблице импорта нет - то проще самому написать)

 

Короче я сейчас делаю проще, просто трейшу LoadLibraryA, и перехватываю работу с файлами. Трейшу на основе клерковского лоадера, через TF и VEH. Только то что он описывает есть баг в ВЕХ я что то не нашел все работает как часики.

 

Rel
Ничего нигде не надо искать. Допустим, не только в импорте, но и за рубежом.

СFF
Добавить VEH-хендлер, TF в "1" и вызов LdrLoadDll.

В обработчике смотришь EXCEPTION_SINGLE_STEP, когда доходишь до интересующих
вызовов (ContextRecord->Eip) и заменяешь все что нужно на стеке.

Детали зависят от реализации, вкратце - цель из NtCreateSection возвратить свою, заранее созданную.
Если она без аттрибута SEC_IMAGE, прийдется также контролить NtMapViewOfSection, иначе она будет
смаплена линейно и пи*дец.

Added: код там сырой, проще написать с нуля.

 

Так и делаю

 

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

 

Rel
Прекратите этот фарс! Беритесь уже (и стало быть еще) за отладчик.

 

Трайсинг всетаки закончил, осталось при трейсинге хучить функи. Все таки как показала практика в этом трейсе много подводных камней, наченая от того что писал Clerk

Код (Text):

1. ; Если при трассировке возникнет исключение отличное от #DB, то первое разворачивается, а диспетчер исключений получает управление с взведённым TF.
2. ; После исполнения первой его инструкции генерируется трассировочный останов, снова вход в диспетчер исключений, но уже со сброшенным TF.
3. ; Если не проверять адрес останова, будет выполнена трассировка диспетчера исключений. При этом изза рекурсивного входа в критическую
4. ; секцию(RtlpCalloutEntryLock с не доконца изменёнными полями её при предыдущем вызове) окажется что она уже захвачена(LockCount = 0,
5. ; OwningThread = 0) и поток войдёт в бесконечный цикл ожидания освобождения её.

и заканчивая тем что поток просто замерзает на некоторой инструкции. Но все эти проблумы решил. Сразу сообщу что под virtualbox сразу видно что идет задержка при LoadLibraryA. Без вм - не заметно.

 

[offtop]о неужели Клерк так обиделся что больше сюда не заходит![/offtop]
Кстати, а зачем такие извраты с загрузкой либы? Ведь можно сделать вообще свой собственный загрузчик без зав-тей от нтдлл, надёжней и проще.

 

А чего надежного и проще ? Вы что будете описывать все релоки. Подерживать все 3 импорты. Ресурсы с манифестом. Не я не спорю, что можно, я так и делал раньше. Но зачем писать то что уже написано. И дофига кода занимает.

 

Не уверен, что всё что натрейсите тут неизменно от винды к винде, а пробежаться ручками по релокам, импорту и экспорту проверенное временем решение.

 

Вы не понемаете Трейс это тоже самое что вызвать ЛоадЛибрари. Работает везде на x32/x64. Так что раслабтесь

 

d2k9
Нативный загрузчик будет поддерживать по факту все фичи.

всё что натрейсите тут неизменно от винды к винде
Вместо отображения секции загрузчик Windows 8 начнет использовать пайпы?

 

Народ нужна помощь. Непонятны действия загрузчика.
Вобщем при трейсе, в ZwOpenSection передаю секцию своей длл.
Далее идет 2 раза ZwMapViewOfSection, первый раз все нормально, второй раз STATUS_CONFLICTING_ADDRESSES. Это связано с тем что в параметрах передается BaseAddress на уже смапленый адресс. Ну это я обманул таким кодом

Код (Text):

1.     mov ecx,10
2. _push_next:
3.     push dword ptr [eax + ecx*4]
4.     dec ecx
5.     jnz _push_next
6.        
7.     call [ebx].pNtMapViewOfSection
8.     test eax,eax
9.     jnz _check2
10.    
11.     mov eax,STATUS_IMAGE_NOT_AT_BASE
12.     jmp _nobase
13.    
14. _check2:
15.     cmp eax,STATUS_CONFLICTING_ADDRESSES
16.     jne _continue_trace
17.    
18.     xor eax,eax
19.        
20.  _nobase:
21. ...

Дальше будет вызов ZwProtectVirtualMemory, на мою секцию и тут будет ошибка C000004E. Приэтом при первом мапе функа работает как надо. В чем проблема народ ?

 

Та проще свою настройку импортов релоков сделать чем с трейсом мучаться, если апликуха многопоточная может трейс флаг сбросить или ещё что ..
А если уж и юзать сис загрузчик то может просто найти нужные куски кода и их дергать без всяких трейсов то так понадежнее будет-то