Дизассемблирование на лету

Доброго всем времени суток уважаемые!

Еще раз подниму этот вопрос - извините за назойливость, но очень надо
Как можно получить адрес переменной/процедуры по ее имени? Какие есть принципиальные приемы? Какие уже готовые решения на асм/С уже реализованы?

Например есть в НТ ядре переменная MmPagingFile
ИДА и ВинДбг ее спокойно показывают как _MmPagingFile и nt!MmPagingFile соответственно. Допустим ВинДбг сообщает, что ее адрес 0х8055f720

Вот как бы мне сделать (или достать исходник) функции типа PVOID xxGetAddressByName( char* name ) которая бы мне возвращала адрес !_неэкспортируемой_! глобальной переменной/функции ?

Спасибо!

 

Удали символы и попробуй найти эту переменную.

 

Угу, без символов нет и переменных. Если есть символы - юзай pdbdump, можно по имени вытащить RVA http://www.wasm.ru/baixado.php?mode=tool&id=205

 

Поставь IDA, найди xref'ы к ней, после этого юзай сигнатурный поиск по опкодам.

 

Кстати за вас майкрософт это сделала, тока немного криво, но для юзермода достаточно обычно http://msdn.microsoft.com/en-us/library/dexter.functioncatnat.sym.aspx

 

Clerk
Rodin

Спасибо! Все работает, пока будут пользовать этот метод...

n0name
Не понимаю о чем речь, можешь объяснить подробнее?

 

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

 

*мегабайты

 

Clerk
то что идет речь о поиске без символов я понял а вот все остальное непонял...

1. "найди xref'ы к ней" ?
2. как из 1 получить сигнатуру опкодов?

хорошо бы получить небольшой примерчик...

 

Найди в IDA места, где используется эта переменная, вычлени уникальную сигнатуру опкодов которая позволяет найти инструкцию, обращающуюся к переменной. Напиши код, который используя дизассемблер, анализирует опкоды, сравнивая с "сигнатурой".

 

n0name
ёканый бабай! довольно замороченная штука...
наверное все же проще из ПДБ получить РВА и уже от нее плясать... ведь для конкретного билда и версии ОС РВА на символ будет всегда одинаковый. Поправьте если я не прав...

 

не прав, рва будут постояными только для одинаковых версий библиотеки, а они часто отличаются даже внутри одного билда ОСи.

 

опять возвращаюжсь к этому вопросу... допустим я через pdbdump вытащил RVA, например:

// pubsym <rva 0x83de0> _MmSystemPtesEnd

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

1. как и где мне найти эти "таблицы" RVA внутри загруженного образа если я знаю его базу?
2. насколько надежен такой метод поиска функции:

2.1 искать RVA в таблице RVA загруженного образа - если не найден, значит такой функции нет - выход
2.2 если RVA найден с искомым, идем по кинечному адресу и сравниваем пролог функции - скажем первые 30 байт функции в памяти - если нет полного совпадения - выход
2.3 если 2.2 и 2.1 успешно пройдены, проверяем длину функции - достаточно просто

таким образом, если все три пункта выполнились, то с какой-то вероятностью мы нашли нашу функцию. в принципе, если не использовать RVA, достаточно ли иметь бинарник функции и искать его в памяти начиная с базы загруженного образа? или это уже полный маразм?

 

Само понятие "неэкспортируемой" функции говорит о том, что в таблицах ты ее не найдешь. Именно по этой причине тебе начали говорить о сигнатурном поиске кода, который обращается к интересующей переменной/функции.

Твой алгоритм поиска говорит что идеи этой ты не понял ))
(2.1) - если не найден, значит функция _не экспортируется_.
(2.2) - если RVA найден в таблице экспорта, то ф-ция есть и экспортируется - смысл дальнейших проверок?

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

Если слишком сложно с дизасмом - найди pdb для всех на данный момент нужных тебе систем, извлеки pdbdump'ом RVA и сделай таблицу версия системы / RVA. В софте соответственно проверяешь версию системы и ищешь в таблице нужный RVA.

 

NeuronViking
тогда надо строить дерево вызовов функций (искать по вызовам и RETам) и сверять "экспортируемые из RVA" с корневыми из построенного дерева.

 

t00x
не пойму смысла таких операций.
поясни плз что к чему.

 

deLight

вероятнее всего неэкспортируемые функции вызываются "корневыми" экспортируемыми и возможно ТС ищет именно "корневую неэкспортируемую"?

 

t00x
я вот что придумал - до безобразия тупо и через жопу. Используя нормальную экспорт функцию (заранее зная, что она использует искомую мною локальную функцию или данные и зная КАК она ее использует) нахожу в ней последовательность E8 [addr] - т.е. адрес искомой мне функции/данных, приблизительно зная размер кода... Тогда получается, что метод не привязан к конкретному билду, сервис паку, етц.

 

Это n0name сказал в посте номер 10, а не ты придумал

 

жесть )
обычный сигнатурный поиск которому уже 100 лет в обед
и правда шикарная идея