Версия для печати темы
Нажмите сюда для просмотра этой темы в оригинальном формате |
Форум программистов > C/C++: Системное программирование и WinAPI > Анализ PE-заголовков |
Автор: Leksey 13.4.2006, 21:12 |
Нужны примеры исходников на С/С++ для работы с Pe-заголовками. |
Автор: _hunter 14.4.2006, 11:06 |
что понимается по "работой"? в любом случае идем http://msdn.microsoft.com/library/en-us/dndebug/html/msdn_peeringpe.asp. потом и вторую часть почитать можно будет... |
Автор: Leksey 14.4.2006, 13:54 |
Под работой я понимаю извлечение всякой полезной информации по типу таблиц экспорта,импорта. За линк спасибо , информации по Pe заголовкам у меня хватает. Мне бы так чтобы самому как можно меньше писать... |
Автор: 4udo 21.4.2006, 18:18 |
Leksey , очень спецовые исходники есть на http://vx.netlux.org в журналах 29-A. Там же адреса сайтов авторов исходников. А так вот держи один исходничок от просветленного y0da. |
Автор: 4udo 29.4.2006, 09:28 |
Leksey,вот нашел ещё один исходник (авторство не знаю) ; это исходник полиморфного упаковщика exe-модулей.... Очень навороченный ......... Прицепить не реально - размер великоват. Вот отсюда можно скачать: http://www.wasm.ru/baixado.php?mode=tool&id=188 |
Автор: 4udo 30.4.2006, 16:53 |
А этот вообще на С!!!!!!!!!!!!!!!!!!! Coded by Cronos!!!! Зацени............... ![]() |
Автор: criz 27.3.2009, 19:26 |
А как можно узнать параметры, переданные фукнции? Допустим, прочитал я таблицу импорта, узнал какие функции используются. Можно ли узнать переданные параметры? |
Автор: GoldFinch 27.3.2009, 19:51 |
criz, для этого есть отладчик и дизассемблер |
Автор: Acer 27.3.2009, 20:11 |
http://www.firststeps.ru/mfc/winapi/winapi1.html хорошее описание PE заголовков |
Автор: GremlinProg 27.3.2009, 21:39 |
именно в PE и COFF, для этого служит формат формирования декорированных имен функций, т.е. в самом названии эти данные могут присутствовать, в зависимости от способа линковки символов функции, экспортированные и слинкованные как extern "C", в общем случае, такой информации в PE не предоставляют, только общие соглашения: размер пула параметров, порядок параметров в стеке(прямой, обратный) и условие эпилога(выталкивать стек или нет на выходе) в общем случае, это не надежный источник информации, поскольку переопределить любое объявление можно вручную без всяких условий декорирования (как, например, сделано в большинстве API), обычно используется информация из символьных БД как правило, такие базы весят в десятки раз больше, приложений,которые они описывают, поэтому ими редко пользуются повторно не экспортируемые функции, в PE, именуются вообще крайне редко, так что они актуальны только для COFF-образов по декорированию подробнее тут: http://members.ozemail.com.au/[email protected]/samples/programming/msvc/language/decoration/index.html http://msdn.microsoft.com/en-us/library/deaxefa7(VS.71).aspx а по базам - ключ для поиска: PDB-файлы |
Автор: GoldFinch 27.3.2009, 22:31 |
если имя декорировано, отладчик или дизассемблер или просто просмотровщик его расшифрует |
Автор: 0xDX 28.3.2009, 03:33 |
IDA pro |
Автор: criz 30.3.2009, 17:32 |
Вариант с отладчиками и дизасемблерами, типа IdaPro и др., не подходит. Думал, что можно все реализвать своими силами, имея в распоряжении только exe-шник. |
Автор: GoldFinch 30.3.2009, 17:52 |
criz, те в рантайме или статически? |
Автор: EvilsInterrupt 31.3.2009, 08:50 | ||
criz, Зная соглашение можно понять скоко параметров автоматизировано! вызов на си, с stdcall: hDll = LoadLibrary("my1.dll"); на асме:
вот вывод: 1. нашел итем в ИАТ нужной ф-ции 2. нашел места ее вызова 3. Распознал соглашение вызова , stcall, cdecl - как правило , реже register- тут уже реверсить, ну и др 4. если stdcall, cdecl - работем и смотрим скоко пушей перед этим ! 5. если cdecl еще лучше, скоко байтов у стека убивается и ищем стоко пушей, если они есть значит именно эти параметры и есть ) ЗЫ: Почитай теорию декомпиляции |
Автор: GoldFinch 31.3.2009, 09:05 |
тогда уж сразу лучше искать в коде функции "ret xx" и делить xx на 4 |
Автор: GoldFinch 31.3.2009, 14:27 |
GremlinProg, там где можно анализировать - надо анализировать иначе можно везде подобрать частные случаи и сказать что это повод не решать задачу кроме того ТС вообще не сказал проги каких компиляторов он собрался анализировать, может там вообще не будет cdecl а будет fastcall |
Автор: GremlinProg 31.3.2009, 15:06 | ||||
для всех случаев, решение я уже предложил, а моя критика по поводу твоего, по моему, очевидна: дизассемблирование - это эвристический метод, требующий интеллектуальных ресурсов, или проще говоря, условие его работы - непосредственное присутствие человека при решении, а изначальная суть вопроса, судя по ответам вопрошающих - автоматический разбор описаний функций из PE, т.е. дизассемблеры тут в принципе ни каким боком не стоят (***) я лишь показал, почему не стоят кстати, GoldFinch, тоже ответь на вопрос из моего предыдущего поста, это не частный случай, эту задачу тоже можно решить программно (только стоит ли оно того?)
на самом деле это странный формулировка, поскольку по наводящим ответам, уже давно понятно (***) ты сам, как раз и уходишь от решения, а зачем - непонятно |