В программе при загрузке подгружаются модули .DLL

Я нашёл в каких местах одного из DLL нужно подменить байты, чтобы в программе стали доступны все лицезированные возможности.

DLL запакована. Quick Unpacker показывает:

PESniffer EP Scan: PEtite v2.1
PEiD scanning... PEtite 2.x [Level 0] -> Ian Luck

В начале файла-DLL находится загрузчик-распаковщик.

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

Всё это до недавнего времени работало, но теперь появилась ещё какая-то доп. проверка целостности файлов, которую мой DLL уже не проходит.

Подскажите, каким образом можно поменять эти очень нужные байты в памяти, не меняя DLL-файл?

Попробовал ABEL loader generator на основную программу, не получается.
Пишет, что это защищённая область памяти DLL

Что можно сделать?

| Сообщение посчитали полезным:

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

| Сообщение посчитали полезным:

krobol2000
Ты либу патченную не хочешь больше трогать? ну тогда напиши ещё одну и запихни весь код с "инЪекцией" туда, назови её lpk.dll бери masm (ну или на чём ты там пишешь) и вперёд, для записи юзай VirtualProtect. (ну это так сказал, на всякий случай)

SVLab пишет:
А почему ты думаешь, что правка в памяти тебе поможет? возможно там и происходит дополнительная проверка.
Не совсем понял, что ты имеешь в виду...Разве нельзя загасить эту проверку в памяти таким же образом как и всё остальное? Да и вообще что мешает просто расковырять эксешник и глянуть что там и как?!

| Сообщение посчитали полезным:

SVLab, доп. проверки целостности в памяти пока нет, т.к. менял эти байты дебаггером и всё работает.

MasterSoft, DLL надо оставить оригинальным (сам файл), а вот в памяти после того, как он распакуется, поменять нужные байты.
Про lpk.dll не понял. Про VirtualProtect читал, например, здесь www.xakep.ru/magazine/xa/118/062/1.asp - то что мне нужно это способ №3.

Это проделывает генератор лоадера - ABEL, но только для ехе-шника. Есть ли похожая программа для изменения подгружаемых DLL?

| Сообщение посчитали полезным:

MasterSoft пишет:
Разве нельзя загасить эту проверку в памяти таким же образом как и всё остальное
Можно, конечно, ну так ведь человек не может найти где и как проверяется.

krobol2000, а сам себя EXE проверяет?

| Сообщение посчитали полезным:

SVLab, да, сам себя exe проверяет, т.е. в него встроить нельзя. К тому же он часто обновляется, поэтому при каждом обновлении придётся заново встраивать патчер.

Насколько я понял, выход такой: на masm32 (сегодня установил его) пишу лоадер, который
- запускает основную программу "main.exe"
- через 5-10 сек (думаю столько хватит, чтобы main.exe загрузила DLL - "protect.dll") ищет в памяти нужный модуль protect.dll
- патчит в protect.dll нужные байты
- лоадер заканчивает работу, а программа продолжает работать в полнофункциональном режиме.

В аттаче loader.asm, то что я нашёл за образец. Теперь в него нужно вставить код, который реализует патчинг нужной dll. Как это сделать?


Либо, второй вариант:
- с помощью ABEL генерю лоадер, который в основную программу main.exe добавит код, который пропатчит нужный модуль после загрузки этого модуля.

на примере изменение API MessageBoxA:
в main.exe вставляем JMP и по адресу JMP:

00401026 PUSHAD; сохраняем регистры в стек
; далее следуют четыре параметра, передаваемые в стек перед вызовом VirtualProtect
00401027 PUSH 00401060; указатель на нулевой байт - параметр "lpflOldProtect"
0040102C MOV EAX,40; Помещаем в EAX параметр "flNewProtect", который разрешает запись в область памяти, где располагается наша DLL
00401031 PUSH EAX; кладем параметр в стек
00401032 PUSH 8; параметр "dwSize", который представляет собой размер области памяти
00401034 PUSH 7E3A05C1; параметр "lpAddress" - начальный адрес области памяти
00401039 CALL VirtualProtect; вызываем VirtualProtect
0040103E MOV EAX,[401100]; помещаем в eax первые 4 байта машинного кода
00401043 MOV EBX,7E3A05C1; в ebx помещаем адрес, по которому будет записано машинное слово
00401048 MOV [EBX],EAX; записываем машинный код в тело API-функции
0040104A MOV EAX,[401104]; помещаем в eax 4 последних байта машинного кода
0040104F MOV EBX,7E3A05C5; в ebx помещаем адрес, по которому будет записано машинное слово
00401054 MOV [EBX],EAX; записываем машинный код в тело API-функции
00401056 POPAD; восстанавливаем регистры перед вызовом MessageBoxA
00401057 CALL MessageBoxA
0040105C JMP 00401013; переходим к дальнейшему выполнению программы

По этому методу есть несколько вопросов: как узнать адрес памяти в которую загружен DLL (ан-но 7E3A05C1).

Какой метод попроще и как реализовать хоть какой-то?

b2c8_13.12.2009_CRACKLAB.rU.tgz - loader.asm

| Сообщение посчитали полезным:

krobol2000 пишет (в loader.asm):
invoke SuspendThread,addr pinfo.hThread ; Тормозим нашу прогу
А к моменту вызова SuspendThread (после Sleep) прога других потоков не наклепает? Или просто с protect.dll работает только этот поток?
Перед WriteProcessMemory возможно еще придется VirtualProtectEx вызывать.

| Сообщение посчитали полезным:

krobol2000 пишет:
protect.dll
это вы ломаете стар?

-----
Лучше быть одиноким, но свободным © $me

| Сообщение посчитали полезным:

нет, не стар. прикладное ПО

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

| Сообщение посчитали полезным:

А dll в импорте или грузится программой?

| Сообщение посчитали полезным:

это не могу сказать. Не знаю как определить.

Но при запуске программы подгружается несколько dll

| Сообщение посчитали полезным:

krobol2000 пишет:
это не могу сказать. Не знаю как определить.
Дойди до оеп и посмотри табличку импорта импреком к примеру.

| Сообщение посчитали полезным:

Загружаю программу в olly debugger - когда стоит на оеп, то нужного dll ещё не загружено.

В процессе выполнения программы вызывается функция, которая загружает необходимые для работы dll-ки. Т.е. dll грузятся программой.
Программа использует MVC и грузит dll функцией QtCore4.load@QLibrary@@QAE_NXZ
которая вызывает в свою очередь функцию kernel32.LoadLibraryW

| Сообщение посчитали полезным:

krobol2000 пишет:
как узнать адрес памяти в которую загружен DLL
Пример

PUSH "KERNEL32.dll"
CALL kernel32.GetModuleHandleA
в EAX адрес по которому загрузилась делка
если 0 то делка незагружена


-----
Чтобы правильно задать вопрос, нужно знать большую часть ответа. Р.Шекли.

| Сообщение посчитали полезным:

LOADER.EXE - загружена по адресу 0401000h

из него, с помощью kernel32.CreateProcessA запускаю основную программу MAIN.EXE
MAIN.EXE - загружена по адресу 0401000h. В ней подгружается TARGET.DLL с помощью kernel32.LoadLibraryW.
TARGET.DLL загружена по адресу 01161000h (но это частный случай).

Как из LOADER.EXE попасть в адресное пространство процесса MAIN.EXE, чтобы изменить TARGET.DLL в памяти по адресу 01161000h?

ClockMan,
PUSH "KERNEL32.dll"
CALL kernel32.GetModuleHandleA показывает адрес местной копии модуля kernel32.dll
Соответственно PUSH "TARGET.DLL"; CALL kernel32.GetModuleHandleA; - результат EAX=0 =(

| Сообщение посчитали полезным:

krobol2000
тут простых путей мало.
1) как тебе все и говорят, твой лоадер должен запустить процесс засуспендженным и выполнить инжект своей длл, которой уже будет проще работать в контексте данного процесса ( можешь погуглить на эту тему ). далее один из вариантов по таймеру сканить не подгрузилась ли длл как тебе тут советовали и тогда ее патчить, или же хучить сплайсингом LoadLibraryEx и анализировать имя длл, а потом патчить.
2) вся логика остается в лоадыре он будет отпускать и суспендить процесс через какое-то время и сканировать всю память процесса ( т.е. читать по 0x1000 память ) и искать сигнатуру из кода твоей длл, чтобы распознать что она уже загружена, далее делаешь подсчет насколько тебе нужно сместится относительно найденного адреса чтобы пропатчить ее.

ну это то что счас в голову пришло

| Сообщение посчитали полезным:

1 как и написал RSI твой лоадер должен запустить процесс засуспендженным
2 пишешь сразу после CALL QtCore4.load@QLibrary@@QAE_NXZ EBh,FEh (т.е зацикливаешь прогу)
3 Через ResumeThread продолжаешь работу
4 ставишь в своем лоадере задержку секунд 5
5 Стопоришь процесс через SuspendThread
6 Через GetThreadContext получаешь значение EAX (поидее там должен быть адрес куда загрузилась dll)
7 Меняешь EBh,FEh на оригинальные, патчишь длл, продолжаешь работу (ResumeThread)
8 Собственно и всё INVOKE ExitProcess,0

| Сообщение посчитали полезным:

RSI, Vovan666
Разве не проще просто пропатчить EXE в памяти перед CALL QtCore4.load@QLibrary@@QAE_NXZ. (Как говорит ТC, память не контролируется.) Имя dll должно ведь ей передаваться, если имя не то, просто возвращаем управление проге, если то, - сами вызываем этот загрузчик и правим dll.

| Сообщение посчитали полезным:

Возможно я не прав, но все эти задержки это не надёжно. Конечно проще мониторить LoadLibraryEx. Ну а код прививки можно вставить и в dll, которая загружается статически, если в ехе нет возможности.

| Сообщение посчитали полезным: