Вывести трассу вызовов DLL?

кароч есть нативное приложение, которое использует функции, реализованные во внешних DLL... всего шесть мажорных версий приложения... мне надо определить несколько функций, которые я мог бы похукать для своих грязных и коварных целей)... есть ли какой то проект, который позволит мне построить трассу вызовов функций из внешних DLL, чтобы упростить поиск этих функций во всех шести мажорных версиях проекта... чтобы упростить поиск, а не сидеть с отладчиком во всех шести версиях... есть Rohitab API Monitor, но пока не уверен, что он поможет, тк там нужно иметь описания для логируемых функций...

--- Сообщение объединено, 19 янв 2019 ---

посбрасываю варианты сюда пока:
http://www.rohitab.com/apimonitor
http://jacquelin.potier.free.fr/winapioverride32/
https://www.apimonitor.com/

 

Пиши свой хукер по экспорту с трамплином на базе дизасма первых 2 инструкций. Если результат, возвращаемый функцией не интересует - 1.5-2 кила кода (в нативе). Логгер с этим чудом все распишет.

 

делал нечто похожее в иде через скрипт idc: трассировал код, если есть вызов внешней функи, то логировал его
вот вырезал необходимое (нужно еще трейсер в иде настроить чтобы вызывал TaintSlicer() после каждой инструкции):

Код (C):

1. //________________________________________________________________________________________________________________
2. #include <idc.idc>
3. #define true 1
4. #define false 0
5. #define TaintColorErr 0x0000ff
6. extern $Bitness;
7. extern $Segment;
8. extern $CalleeFunc;
9. extern $TracingStop;
10. //________________________________________________________________________________________________________________
11. static TaintSlicer()
12. {
13.   auto $e, $ea, $cmd, $taint;
14.   $TracingStop = false;
15.   try
16.   {
17.     $ea = GetTevEa(TEV_NONE);
18.     if ($Segment != SegName($ea))
19.     {
20.       $CalleeFunc = $ea;
21.     }
22.   }
23.   catch($e)
24.   {
25.     SetColor($ea, CIC_ITEM, TaintColorErr);
26.   }
27.   if ($TracingStop)
28.   {
29.     MakeComm($ea, CommentEx($ea, 0) + sprintf("%08x", $CalleeFunc) + " " + Name($CalleeFunc) + "; ");
30.     Message("External code: " + sprintf("%08x", $CalleeFunc) + " " + Name($CalleeFunc) + "\n");
31.   }
32.   return $TracingStop;
33. }
34. //________________________________________________________________________________________________________________
35. static main()
36. {
37.   auto $i, $e;
38.   $TaintMemArray = object();
39.   $TaintRegArray = object();
40.   try
41.   {
42.     $Bitness = GetSegmentAttr(GetRegValue("rip"), SEGATTR_BITNESS) + 1;
43.     $Segment = SegName(GetRegValue("rip"));
44.   }
45.   catch($e)
46.   {
47.     try
48.     {
49.       $Bitness = GetSegmentAttr(GetRegValue("eip"), SEGATTR_BITNESS);
50.       $Segment = SegName(GetRegValue("eip"));
51.     }
52.     catch($e)
53.     {
54.       return;
55.     }
56.   }
57.   Message("Current segment: " + $Segment + "\n");
58.   Message("Bitness: ");
59.   ($Bitness == 1) ? Message("32\n") : Message("64\n");
60. }
61. //________________________________________________________________________________________________________________

 

Rel,

Ну и как ты это решил, вручную отладкой ?

Задача элементарная, а ведь от тебя столько понта" было

 

да руками, там вызывается нужный функционал через COM, пропатчил таблицу виртуальных методов и все, что нужно было, перехватил...

 

Rel,

Жаль что быстро сдался, тема ведь интересная. Я думал может что то автоматикой решал, но увы.

 

я пробовал все программы, что я перечислил в первом посте, для всех из них нужно описывать прототипы перехватываемых функций... в итоге написал скрипт на IDAPython, тупо сделал хот-патч для всех экспортных функций и залогировал... к сожалению, уже когда стал разбирать логи и дебажить, выяснил, что все решается через COM объект с интерфейсом IDispatch (что странно, я ожидал увидеть какой-то кастомный интерфейс), пропатчил vtable, чтобы Invoke ссылался на мой инжектированный шелл... нашел нужные DISPID, а дальше все просто, тк параметры передаются комовскими вариантами...

а так для этого есть готовые DBI фреймворки, типа Intel PIN, Dyninst, Dynamorio и тд... они на себя возьмут инжект и любые хуки... но мне было проще и быстрее руками запилить...

 

Тема действительно интересная. Я даже зарегистрировался сразу, чтобы Indy_ поддержать в том, что тема хорошая . А то уже беспонтовые посты от Minzdrav-а порядком надоели . Там выше vx1d про интересную технику упомянул. Как можно нечто похожее в IDA через скрипт idc реализовать. Хорошо бы это поподробней раскрыть. В общем, было бы интересно более подробно почитать мнения знающих людей о подобных техниках - причем в различных ситуациях, а не только той которая возникла у Rel-а.

 

Я, например, с помощью трейса и скрипта на idc сделал TaintSlicer, типа отслеживать распространение помеченных данных память/регистры по коду (свой велосипед), а код выше это часть того idc скрипта

 

vx1d, не знаю кому как, но мне ваш велосипед очень интересен. Может более подробно это все же раскрыть? Если там хитрости какие-нибудь применяются и не хочется их распространять, то может тогда в личку? Обещаю строго хранить тайну . Я почему к вам так, что называется "прицепился"? Изучал как-то скрипты Иды и поймал себя на мысли, что команд связаных с трассировщиком(отладчиком) там вроде как и нет. Видимо по диагонали читал .

 

https://qpdownload.com/blade-api-monitor/
https://www.nektra.com/products/spystudio-api-monitor/

--- Сообщение объединено, 3 фев 2019 ---

Ы тут http://autodebug.com/

--- Сообщение объединено, 3 фев 2019 ---

http://intellectualheaven.com/default.asp?BH=StraceNT
еть тожь нЭ забуваем

 

UbIvItS, спасибо, как говорится, на добрых ссылках . Может еще команды какие-нибудь подскажете из скриптов для IDA и IDAPython? Чтобы было понятно, хочу пояснить на базе WinDbg. У WinDbg есть хорошие команды t, p и производные от них (p, pa, pc, pt и т.п). Вот опираясь на эти команды, да плюс еще и логирование, можно получить скрипт неплохого трассировщика. У IDA такое тоже наверняка должно быть на базе скриптов. Может даже у кого-нибудь и образец простенький имеется, чтобы было от чего оттолкнутся и понять принцип.

 

Я тоже хочу! Просим!

 

вообще, кто-нить работал с DBI фреймворками? интересно сравнение Dyninst, Dynamorio и Intel PIN в плане фичурсов и удобства...

 

Rel, а что делал ваш скрипт, если не секрет и какие команды в него входили? Там явно было что-то, что интересует широкую общественность . Может чуть приоткроете завесу секретности, а там глядишь вашему хорошему примеру последует и vx1d. Ну и если погода и звезды на небе не подведут, может и Indy_ нам пару секретов подбросит. Конечно, на счет Indy_ я скоее всего обольщаюсь, но вот тот же f13nd, если появится в этой ветке, вполне себе, что-либо интересное может поведать .

 

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

Инде скажет, что все, что ты когда либо делал в твоей жизни, ты делал неправильно и надо было делать через <вставить_сюда_странную_аббревиатуру_значение_которой_не_понимает_никто_кроме_Инде>...

 

Rel,

> Инде скажет, что все, что ты когда либо делал в твоей жизни, ты делал неправильно

Да, верно.

> интересно сравнение Dyninst, Dynamorio и Intel PIN

Работали, вот только если хочешь сделать правильно - сделай это сам".

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

Вы взяли для примера инструменты не рабочие и левые", почему например вы не посмотрели мой визор ?

В отличие от этих нерабочих поделок, dye это найтивный динамический эмулятор бранчей. Спор на пивас на кл привёл к быстрой доработки мотора, до такой степени что любое апп выполнялось без каких то косяков, например гуглохром или фотошоп, затем за пару недель это было допилено для работы с протекторами. Оно получилось на столько стабильным, что можно на лету запускать любой пакер/протектор/криптор/что_угодно. Из за универсальности и простоты обработки я поднял несколько задач, одна из них была - поиск EP автоматикой. Вы много чего пропустили, обсуждение было не долгим.

https://yadi.sk/d/bLWoylqfLmsBsg

А ваша задача при использовании монитора тривиальна. Необходимо создать карту, которая в 8-мь раз меньше размера образа. Каждый бит в этой карте показывает что адрес не является началом процедуры. По ходу трассировки каждая следующая выбираемая инструкция в этой карте должна помечаться. Тогда возврат в процедуру после ветвления даст понять что это не начало, а продолжение процедуры. Тогда передача управления на адрес, для которого маркер сброшен - это вход в процедуру.

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

 

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

 

q2e74,

Каждая часть процедуры связана в CFG. Если ветвление в тело процедуры(не на начало), это нужно как то обнаружить. Имея поток инструкций отсюда и решение. Такой ход мыслей.

Кстате вопрос хороший и уместный. Есть лишь два эффективных пути решения задачи отображения адресов - использование битовых карт или деревьев(AVL). Битмапа всегда более эффективна, хоть и требует много памяти.

 

Indy_, в порядке бреда, или фантастического рассказа...
Допустим есть мир, в котором объединенные между собой серваки связаны между собой одним общим рантаймом. Например, интерпретатор кода один на всех. Допустим, по этому объему виртуальной памяти бегают программы-агенты. Ну что-то типа игры-жизнь-конвея. Допустим, один из агентов с вашим визором на борту. Этакий агент-полицейский. Вы как создатель визора, идейный ярый викс-боец, как отнесетесь к тому, что ваше детище будет охотиться за викс-прогами-агентами? Ну, как если бы мы смотрели киберпанк-кино, как поступили бы вы, и как поступил бы киношный создатель такого копа-визора, из логики зрелещности?