Создать граф потока управления из файла сборки

Что нужно ОП, так это дисциплинированный подход к выполнению этой задачи.

Ему нужен хороший синтаксический анализатор исходного кода на ассемблере, чтобы он знал, что у него есть точное его представление. Помимо чистой части синтаксического анализа, ему придется полностью эмулировать ассемблер, включая все сложности, такие как макросы, условные блоки, счетчики нескольких местоположений, абсолютные/относительные/внешние символы и т. д. (Создайте хороший синтаксический анализатор, полагаясь исключительно на на регулярных выражениях не будет работать.)

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

(Вот трюк, который я использую в большом x86-приложении. Я хочу добавить проверку работоспособности в свой код во многих местах. Тесты работоспособности выглядят так:

  <test for some sane condition>
  jf  location+3       ; this branchs to a breakpoint in the middle of the next instruction
  cmp  al, 0xCC        ; the immediate value is a BREAKPOINT opcode

Они компактны, и точка останова возникает, когда происходит что-то плохое. Но при анализе этой программы на предмет потока управления "jmp false" иногда переходит в то, что кажется серединой инструкции. Как ОП это смоделирует?)

Следующей сложностью являются указатели на код. Код на ассемблере часто генерирует много указателей на другие инструкции, а затем прячет эти указатели в разных местах (инструкция вызова помещает их в стек данных для x86), извлекает их, а затем выполняет «непрямой jmp». Если вы хотите знать, куда может пойти этот jmp, вам нужно отслеживать возможные значения, которые могут содержаться в ячейке памяти, что означает, что вам нужно выполнить анализ потока данных (как значения попадают туда и откуда) и объединить с графом вызовов построение (не можете добраться до этой функции? Хорошо, тогда то, куда она идет, не повлияет на этот код), чтобы вычислить разумный ответ.

Выполнение всего этого специальными методами приведет к неточным (бесполезным) ответам. ОП должен найти основу для создания своего синтаксического анализатора и реализовать качественные алгоритмы анализа точек, если он надеется получить хороший результат.

C не предназначен специально для поддержки этой задачи. Он может сделать это с достаточным количеством дополнительного пота, но это верно для любого языка программирования.

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

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

Используя разборку, выполните два прохода. Первый этап заключается в создании структур данных для представления каждой инструкции и для сбора всех целей перехода.

Второй этап заключается в создании структур, представляющих базовые блоки (блок кода с одной точкой входа). и выход). Свяжите каждый базовый блок с его преемником(ами). Базовый блок может иметь ноль, одного или двух последователей (или N последователей в случае таблицы переходов). Базовый блок, оканчивающийся на RET, не имеет последователей. Базовый блок, заканчивающийся безусловным переходом, имеет одного преемника. А у базового блока с условным переходом есть два преемника — либо провал, либо цель перехода. Базовые блоки без предшественников являются либо точками входа в подпрограмму, либо мертвым (или недействительным) кодом.

Цели перехода — это начало базового блока, как и инструкция, следующая за безусловным переходом (который должен быть целью перехода или точкой входа подпрограммы).

За исключением запуска программы (через реальное оборудование или эмулятор), точное знание целей непрямых переходов невозможно. Я предлагаю поддержать пару простых случаев: 1) таблица переходов, где таблица находится внутри программы 2) переход через ячейку глобальной памяти, которая использовалась для ссылки на другой исполняемый файл (и дизассемблер перечисляет, что является целью). В первом случае базовый блок может иметь произвольное количество последователей. Во втором случае базовый блок имеет одного преемника.

Обратите внимание, что я намеренно опускаю CALL как часть CFG. Когда я реализовал CFG grapher, я сделал именно это. Мой граф показывал только одну функцию за раз. Если дважды щелкнуть CALL, отобразится CFG подпрограммы.

Однако, если вы хотите включить все дерево подпрограмм в одну CFG, то CALL будут концом базового блока, а инструкция, следующая за CALL, будет началом базового блока. Обратите внимание, что для чего угодно, кроме самых простых программ, будет сложно просмотреть всю CFG для программы.

Я опускаю INT и IRET, потому что предполагаю, что вы имеете дело с приложениями пользовательского режима. Если нет, то относитесь к INT как к вызовам, а к IRET — как к RET. Аппаратная процедура обслуживания прерываний (ISR) может быть вызвана из любого места, где разрешены прерывания, поэтому (обычно) не будет каких-либо прямых вызовов ISR - она ​​просто будет сидеть в стороне. В более общих чертах, если вы имеете дело с программным обеспечением режима ядра, у вас будет множество других соображений.

Я столкнулся с той же проблемой, что и вы, и не нашел готовых решений, поэтому я написал простое самостоятельно с помощью Python: https://github.com/Kazhuu/asm2cfg.

Обратите внимание, что я тестировал его только с дампами дизассемблирования функций из GDB. Думаю, это можно расширить для использования с objdump.