Получить список процедур.

Здрасти.

Необходимо определить начала всех процедур, тоесть всего кода, после компиляции. Каким образом это можно сделать, откуда извлечь инфу(.map, obj etc). Причём константы в секции кода это не код. mapfile сомнительно. Такое вообще возможно ?

obj.IMAGE_SYM_DTYPE_FUNCTION видимо нужное, но формат не прост.

 

Фантазию включать разрешается?

- можно прочесать весь дамп в поисках начал процедур, характерных для ЯП (ЯВУ)
- можно прочесать дамп, собирая все CALL'ы, и потом смотреть куда они "смотрят" - это либо п.1, либо место после POP'ов + RET, и возможно это начало новой процедуры

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

 

_edge

Мне нужно это сделать через компилятор.

 

Отпишусь здесь. Нашел такую вещь http://www.jakstab.org/

вот презентация http://seminaire-dga.gforge.inria.fr/2012/20130419_JohannesKinder.pdf

Как говорится, для тех, для кого это может представлять интерес.

 

TermoSINteZ

Студия например. В общем для обработки апликухи(чтобы запротектить, но не суть важно) нужно выделить её код, тоесть начала всех процедур. Для этого нужно использовать инфу компилера. Вот оказывается в map содержится не только код на сколько помню, а экспорт в целом. Поэтому если туда попадёт переменная, а она не есть код, то всё сломается. Лучший способ это скомпилить с CFG картой, хотя туда тоже не всё включается. Хотелось бы найти метод общий, который можно применить к бинарю, но видимо это невозможно.

 

TermoSINteZ,

Мне не нужны графы. А простой и надёжный способ. И сурец исходный может не именно на сишке быть.

 

Как вариант распарсить OBJ файл, добраться до таблицы символов, извлечь элементы с типом IMAGE_SYM_DTYPE_FUNCTION. Правда не знаю всегда ли оно корректно заполняется.

 

Какое то противоречие. Я не думаю, что у вас в модуле имеются константы и переменные в секции кода. Для этих целей студия создает доп. секции.
Большиству протекторов (vmprot и иные) вполне достаточно map файла.
Да я и сам написал протектор с ВМ. И мне тоже вполне хватает информации из map файла.

 

Согласен map файла вполне должно быть достаточно, функции помечаются обычно символом f, так что можно со стопроцентной уверенностью покрыть каждую ф-ю (см. пример)

Код (Text):

1.  0000:00000000       ___ImageBase               00400000     <linker-defined>
2. 0001:00000000       __enc$textbss$begin        00401000     <linker-defined>
3. 0001:00010000       __enc$textbss$end          00411000     <linker-defined>
4. 0002:000013a0       ??0List@@QAE@XZ            004123a0 f   List.obj
5. 0002:00001410       ??0ListEntry@@QAE@XZ       00412410 f   List.obj
6. 0002:00001490       ??1List@@QAE@XZ            00412490 f   List.obj
7. 0002:00001570       ??1ListEntry@@QAE@XZ       00412570 f   List.obj
8. 0002:00001610       ??_GListEntry@@QAEPAXI@Z   00412610 f i List.obj
9. 0002:00001680       ?AppendTail@List@@QAEXPAVListEntry@@@Z 00412680 f   List.obj
10. 0002:00001700       ?Attach@ListEntry@@QAEXKPAE@Z 00412700 f   List.obj
11. 0002:00001760       ?CopyTo@ListEntry@@QAEXPAEKPAK@Z 00412760 f   List.obj
12. 0002:00001820       ?DataLeft@ListEntry@@QBEKXZ 00412820 f   List.obj

 

JKornev,

Без вас бы не справились. Сказал ведь - не годится.

 

Интереса ради спрошу и чем же map не подходит?

 

JKornev,

Да сколько же раз повторять то можно. Там не код!

 

Cмотрите, вы писали

Далее в топике вы упоминали map и cfg карту, следовательно под компиляцией вы имеете ввиду именно компиляцию + линковку. Отсюда логический вывод что вы хотите обрабатываеть бинарь, а не obj файлы. Далее вы пишите

Но это не так, все функции бинаря(приват, экспорт), данные и прочие регионы бинарного файла описываются map файлом, мало того каждая функция помечается флагом f, следовательно если вам данные не нужны, то пропускайте при парсинге все строки без флага f, смотрите пример выше. Правда линкер может вставлять код который не описывается в map, например таблица jump'ов incremental linking table <c>, но обычно это юзается только в дебаг сборке и все эти jmp лежат в начале кодовой секции, это не проблема вычеслить. Далее

map даёт больше инфы чем CFG карта, разве нет?

 

Посмотрел несколько OBJ файлов сгенерированных C++, VB6, несколько файлов из WDK. Все функции имеют тип IMAGE_SYM_DTYPE_FUNCTION, константы и переменные не имеют этого атрибута.

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

 

Для более-менее сносного покрытия нужно комбинировать. Список адресов функций дает опорные точки, от которых уже строится CFG.

 

JKornev,

> map даёт больше инфы чем CFG карта, разве нет?

Нет, могу вам привести реал пример, когда весь код нэйтива выделяется через CFG и ребилдится в буфер.

 

Вот нашёл вам немного инфы:

Видос и семпл, как выполняется ребилд всего кода в модуле через CFG:

https://yadi.sk/i/5kaYg6STw9drt

На счёт семпла не уверен(на ядиске их сотни по этой теме) https://yadi.sk/d/plsdUoIHw6ery

Тут моя тема тоже с семплами https://exelab.ru/f/index.php?action=vthread&forum=6&topic=24488&page=0#17

Но вы что то из подобного провернуть не сможите - у вас нет конструктора

 

Indy, расскажите лучше как при построении графа решаются проблемы с вычислением адреса в рантайме.