Опять о старом, перехват API функций!

LightMoon
Это о вашей трассировки .
Вообще я привел конкретный случай когда от патчи отработают а ваш "редЫрект" нет.

 

shchetinin
Жаль что ты сопливый студентик, хотелось бы обсудить серьёзно, но к сожалению это не возможно.

 

LightMoon
Вот в том то и бролема ваша, вам не обсуждать а похоливарить как все у всех не работает, а у вас работает.

 

shchetinin
Правда ведь!

 

LightMoon
Ну ок, как будем перехватывать ole32.dll!CoCreateInstance ?
ole32.dll - 0x000FFFXXXX2000 - 0x000FFFXXXX2000 + SizeOfImage
Отсуда hModuleOle32 = 0x000FFFXXXX2000
ULONG_PTR pFn = (ULONG_PTR) GetProcAddress(hModuleOle32, "CoCreateInstance");
Становится равным
pFn = 0x000FEFXXXX3640 (IEShims сделал патчь для GetProcAddress).
Как будет маршрутизировать ?

Поэтому вам и приходится постоянно регатся.

 

shchetinin

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

 

LightMoon
В том то и дело что адресса ядерные не могут быть известны. Так как импл может сильно менятся ...
Так как в таком случае желать маршрутизацию?

 

shchetinin
Как это не известно ?

Вы что не знаете что за модуль и где он ?

Это не возможно, ваша задача в сферическом вакууме.

 

LightMoon
Что за модуль известно еще раз повторяюсь ole32, нужен CoCreateInstance. Только вызов в нее не произойдет так что реализация будет другая(Хотя может и будет вызов на неё). Мы не можем пологатся на какой то системный вызов. Конечно можно использовать связку вызовов , но это напоминает сигнатуру далее думаю ясно что это бред.

Теперь еще раз и на пальцах
Есть общие описание функции ole32!CoCreateInstance. Реализация не известна , конечный имедж в образе произвольный(Если не понятно как это делает ссылки на раскопки я привел выше). Как будем действовать?

 

shchetinin

Что это значит ?

Да как угодно. К примеру будем каким либо образом отслеживать аллокацию или обращение к хипу. При этом находим в SFC адрес, принадлежащий графу для CoCreateInstance(). Если принадлежит - откатываем функцию, возвратив ошибку из апи хипа. Очевидно что CoCreateInstance() будет хип юзать, ибо эта апи толстая. А что до адресов - это значения не имеет, действительно какая разница в Ip, это не влияет на поведение камня.

 

LightMoon

По GetProcAddress вернет CoCreateInstance не из оригинального именджа ole32.dll, а из shadow ole32.dll

1) Откуда будем строить граф для CoCreateInstance()?
2) Не факт что увидим алокацию памяти, так как реализация может сильно менятся, в особености выделение памяти ( Кэш алокаций ).
3)Нет факта что граф станет возможет , если были вызовы через колбеки, потребуется разворачить стек, что иногда не возможно, если не было кадра стека(сгенерин код, были траплайны).

 

Как для следующих переходов будем строить граф?

Код (Text):

1. .text:1000623D 8B 74 24 10                          mov     esi, [esp+38h+lpFactory]
2. .text:10006241 85 C0                                test    eax, eax
3. .text:10006243 78 07                                js      short loc_1000624C
4. .text:10006245 8B 06                                mov     eax, [esi]
5. .text:10006247 57                                   push    edi
6. .text:10006248 53                                   push    ebx
7. .text:10006249 56                                   push    esi
8. .text:1000624A FF 10                                call    dword ptr [eax]

 

shchetinin

Мне без разницы что оно у вас возвращает, я не юзаю эту апи. Я нахожу модуль через LdrGetDllHandle() и разбираю экспорт всегда своим кодом, в крайнем случае для хорошей совместимости могу дёрнуть LdrGetProcedureAddress(), но это очень редко и для некоторых специальных целей, обычно это совершенно не нужно.
1. Из CoCreateInstance().
2. Факт.
3. Факт.

Никак и не нужно. Нужен код на !NL.
Учить матчасть!

 

Таким спосбом функция не будет найдена ... Смотреть пункты выше, это делает IEShims(Фиксап для GetProcAddress). Так вы найдете другую функцию.

Если былии колбек ссылки, то граф не построить (Только граф jump который в данном случае безполезен)

Обращения на выделения памяти может не происходить , например при участии CRT

Опять таки, вы не понимаете вызов колбеков,

Ссылку, если она есть, если нет , вывод напрашивается ...

 

shchetinin

A. Искать адрес не моя задача. Тут нужно код похачить, а корректный адрес должен передавать тот, кто будет использовать данный механизм. Тоесть вы например знаете что у вас там что то не корректно - передайте корректный адрес.

B. Есть в памяти модуль, пусть ваш ole32. Он описан в лдр. Модуль содержит некоторый код в себе. Код этот находится анализом экспорта в данном случае. Что не так ?

C. Вы ушли к обсуждению задачи в своём сферическом вакууме. Она не в поиске заключается процедур в невесть где.

Да нет, это вы не понимаете. Накой граф нужен и что с ним делать ?

CRT это стабы для NTRTL. Хип всюду.

 

Окей, приминяется , просто я описал что приедтся использовать GetProcAddress, а не что то другое.

А насамом деле GetProcAddress(который IEShims ) пропатчил , вернет функцию не из имиджа ole32.dll , так что в экспорте не найти.

CRT бывают разные, например C++, который умеет это дело оптимизировать для меньшего обращения к ядру.

Так как на счет линка ?

Давайте с кодесом , так как болтавня без кодеся пустая трата времени за частую. С кодесом все понятно. Или семпел с матчастью(без кодеса можно будет понять).

 

shchetinin

Что вернёт LdrGetDllHandle("ole32.dll") или LdrLoadDll("ole32.dll) ?

Я тут уже форум до дыр протёр одним и темже, кодесом тоже.

 

Базовый адресс ole32.dll.
А Вот GetProcAddress( LdrGetDllHandle("ole32.dll"), "CoCreateInstance");
Вернет адресс функции не из имеджа (Image) ole32.dll ( LdrGetDllHandle("ole32.dll") или LdrLoadDll("ole32.dll) ), это будет другой имедж (Image, образ).

Ясно... Я думал что то интерестное будет.((

 

shchetinin

Ну вот мы его распарсим и найдём CoCreateInstance().

Какой другой ?

 

LightMoon
Да что с вами? сконцентрируйтесь наконец таки!
И так поехали
1) Есть процесс IExplore
2) Делаем инжект в IExplore
3) Требуется перехватить объект который создается по средствам CoCreateInstance.

Поехали.
делаем

GetProcAddress был похукан IEShims, происохдит подмена адресса (например это был фикс sxs)
Адресс функции теперь не из "ole32.dll". Так что функция которая в ole32.dll нас теперь перестает интересовать.
С другой стороны это фикса могло и не быть. Так что ичитываем и это.

Но реализация(NewCoCreateInstance) может не содержать как токого кода, а только заплонять указатели, то и есть системных вызовов может и не быть. Как будем действовать ?