Binary Ninja VS IDA Pro

Содержание

• 1. Рассматриваемые версии
• 2. Минусы Binary Ninja
• 3. Плюсы Binary Ninja
• 4. Итоги и рекомендации

⚠️	Все нижепредставленные факты основываются только на моём незначительном опыте работы с представленными инструментами, всё субъективно, поэтому — доверяй, но проверяй. Есть возможность того, что я просто-напросто не знаю, как правильно работает тот или иной функционал или как его включить.

1. Рассматриваемые версии

В сравнении участвовали:

• IDA Pro 7.0.171130

• Binary Ninja 1.1.1184-dev Personal, Build ID 44b71efd

ПО на данный момент (09.09.2018) значительно обновилось, особенно это касается Binary Ninja (BN), в котором обновления происходят часто, и они внушительны по объёму нового функционала.

По большей части анализировалась работа BN, поэтому всё описание будет представлено для него в сравнении со всеми используемым ПО IDA Pro.

ℹ️	Здесь не будет описания того, как работать с BN, а также не будет описаний устройства BN, например, различных промежуточных представлений (MLIL, LLIL).

ℹ️	Я не пользуюсь Hex-Rays, поэтому отсутствие декомпилятора для меня не является минусом, для многих же — это будет единственным фактором, из-за которого вообще не стоит открывать BN. Но всё-таки советую обратить внимание на Medium Level Intermediate Language (MLIL).

2. Минусы Binary Ninja

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

1. При открытии уже сохранённого проекта BN проводит анализ каждый раз заново, при этом в файле проекта хранится информация только о пользовательских изменениях, а не о всём анализе, как у IDA Pro. Отсюда вытекает очевидный минус, особенно остро ощущающийся при анализе больших файлов, — долгий старт каждый раз при открытии проекта. Стоит заметить, что данный минус характерен только для персональной лицензии, в других лицензиях проведённый анализ сохраняется в файл проекта.

2. Скорее всего, временный, т. к. исправят в будущих версиях, но минус. При анализе большого проекта весь файл записывается в память, тем самым в оперативной памяти у вас хранится вся база данных (БД). В IDA же, информация о проекте грузится кусками (скорее всего memory map), поэтому какой бы ни был большой проект — всю ОЗУ он резко не «съест». Опять же, отсюда и плюс.

   htop для IDA и BN с открытым одним и тем же проектом

   CPU% MEM% Command
    3.3  3.1 ./ida64
    0.0 29.8 ./binaryninja

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

   

   Рисунок 1. Стековый кадр в BN

4. Нет возможности работать с указателем на стек, т. е. нельзя задать количество байт, занимаемое кадром стека при работе функции (см. рисунок, чтобы понять, что я имею ввиду).

   

   Рисунок 2. Изменение параметров функции в IDA

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

5. Один из самых значительных минусов: нет ссылок на переменные на стеке. Ни в API (здесь до конца не уверен), ни при работе в GUI (в том числе в различных IL) я не смог найти ссылки на переменные, которые появились в результате анализа работы со стеком. Единственный способ, которым я пользовался: включал контрастную цветовую схему, выделял переменную (см. рисунок), уменьшал масштаб и вглядывался в поисках использования переменной в других местах.

   

   Рисунок 3. Подсветка стековой переменной

6. Ещё один минус при работе с регистрами: нет возможности их переименовать. В IDA Pro существует возможность переименовать регистр для какого-то конкретного диапазона (см. рисунок).

   

   Рисунок 4. Окно переименования регистра в IDA Pro

   Но надо отдать должное, переименовать можно переменную в Medium Level IL (см. рисунок), которая может быть в том числе и регистром.

   

   Рисунок 5. Существует возможность переименовать переменную, которая представляет из себя регистр

7. В IDA я привык смотреть передаваемые функции аргументы в виде комментариев (см. рисунок).

   

   Рисунок 6. Аргументы функции в соответствии с соглашением о вызове в IDA

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

   

   Рисунок 7. Аргументы функции в соответствии с соглашением о вызове в BN (MLIL)

8. И снова проблема с регистрами: BN считает, что rax, eax, ax, ah, al — это разные регистры, соответственно, они подсвечиваются не все при выделении одного из них (см. рисунок).

   

   Рисунок 8. Один и тот же регистр, но разного размера (rax и eax) не подсвечивается в BN

9. В BN мало стандартных типов, вообще база различных сигнатур весьма мала по сравнению с IDA, отсюда приходится многое прописывать самому. Конечно, это временная проблема и база будет пополняться разработчиками, наверняка, будут внедряться какие-то системы по экспортированию больших кусков кода из стандартных библиотек и фреймворков, но сейчас из-за этого минуса частенько хочется бросить анализ бинарного файла и открыть его в IDA, чтобы посмотреть, какая там константа может быть использована, ссылка на какой тип структуры передаётся в качестве аргумента этой функции и т. д., вместо того, чтобы искать сигнатуры функций и типы структур в коде различных версий библиотек. Но всё-таки тут опять же есть и свои плюсы.

10. Нет опции настройки деманглинга имён (либо, как всегда, — просто не нашёл её), но сам деманглинг, как таковой, есть — в качестве переименования объекта. При этом, работает лучше, чем в IDA.

11. Нет встроенного отладчика, но есть интеграция в виде плагина с Voltron и интеграция с WinDbg. Динамическим анализом занимался мало, в основном статика, поэтому ничего сказать по поводу качества отладчиков не могу.

12. Очень мало горячих клавиш (и нет возможности изменения существующих), но они есть, тем не менее, многое приходится делать курсором через контекстное меню. Надеюсь, что в ближайшее время исправят, т. к. это достаточно легко сделать.

13. Нет полюбившихся мне миниатюры графа потока управления и proximity browser’а. Хотя IDA могла бы тоже взять пример с r2, вот там с этим всё отлично.

14. Не очень хорошо реализована работа с полями ввода: нет автодополнения, сохранения истории и прочих, упрощающих и без того тяжёлую жизнь реверс-инженера, приятных мелочей.

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

16. Бывали моменты, когда плохо парсит GOT/PLT, в результате не определялась вызываемая функция: указатель — на ноль.

17. Также случались ситуации, когда не распознаёт jump table, хотя возможные значения регистров определяет корректно. Уверен, последние два минусы будут со временем исправляться.

18. В редакторе типов мне часто не хватает интерактивности, как в IDA. Чтобы создать структуру, лучше, чтобы ты знал поля и размер структуры заранее. Создавать тип из исходных текстов также удобно, как в IDA.

19. Нет нормального интерфейса для работы с импортированными/экспортированными функциями — очень неприятный минус.

20. Лично мой минус — нет хорошей поддержки bitmap шрифтов, при увеличении/уменьшении масштаба происходит искажение шрифтов. В IDA такого нет, хотя она тоже на Qt.

3. Плюсы Binary Ninja

1. Вся БД проекта при работе хранится в памяти, соответственно, все действия с ней, какие бы они не были (например, многократное обращение к разным кускам памяти во время работы плагина или глубокого анализа) происходят быстро.

2. В BN применяются весьма качественные алгоритмы для анализа, в том числе для определения границ и других параметров функций. По этой причине нет возможности изменять границы функции, устанавливать количество байт на стеке, которые будет использовать функция и т. п., как в IDA (см. рисунок). Если бы можно было что-то менять, тогда нарушилась бы целостность проводимого анализа, не находились бы участки кода, которые представляют из себя функции. Для того, чтобы анализ проходил максимально полно, достаточно корректно указать ABI для бинарного файла (функции) — можно выбрать из существующих или реализовать собственный с помощью API (как в случае с анализом смарт-контрактов, например). Также можно задавать такой параметр, как возвращение управления из функции (иногда в многопоточном коде это сложно определить), что также увеличивает полноту анализа.

   По моей статистике BN находил на немного меньше функций, чем IDA. Думаю, что это связано исключительно с тем, что он плохо работает с GOT/PLT, экспортируемыми/импортируемыми функциями т. к. я натыкался на такие функции в BN, которые IDA не распознала вовсе.

3. Иногда замечаю, что BN лучше определяет функции стандартных библиотек (соответственно и аргументов), нежели IDA, и тем более лучше, чем это делает r2. Базу бы функций ещё побольше. К сожалению, не знаю, какой алгоритм сравнения функций они используют, но думаю, что там замешан символьный анализ.

4. В MLIL представлении при выставлении типа переменной в качестве указателя на структуру происходит taint анализ (я так думаю) в пределах одной функции, в результате которого автоматически распознаются все поля структуры, к которым происходит обращение через использованные регистры. Я анализировал ещё не очень много бинарных файлов с помощью BN, но данная функция пока ни разу не ошибалась. Для меня данный плюс является одним из важных, т. к. позволяет сэкономить кучу времени и сразу увидеть место, где происходит обращение к нужному полю структуры. Но есть одно НО…​

5. Одна из самых хвалёных разработчиками функций — возможность отката изменений или просто Ctrl+Z. Честно говоря, после IDA не особо пользуюсь данной функцией, привычка, но тем не менее, штука очень полезная.

6. Одна из причин, по которой я вообще начал пользоваться BN: видны значения промежуточного состояния регистров в результате проведения различных операций (см. рисунок)

   

   Рисунок 9. Обратите внимание на регистры r8 и r4, а также манипуляции с ними: показаны все промежуточные состояния данных регистров

   Это особенно актуально для ARM и MIPS архитектур, где есть очень много кода, в котором все вызовы функций, передачу данных производят косвенным способом: через смещения, операцию с регистрами и т. п.

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

   Лично мои пожелания: не хватает возможности задать диапазон значений руками для регистра, чтобы BN продолжил анализ с конкретными значениями, аля concolic execution. Уверен, это можно реализовать с помощью плагинов. В r2 данный функционал имеется, и он очень хорошо помогает в анализе.

   Также данный функционал удобен при работе со строками, точнее с частями строк. Для экономии места частенько бывает, что компилятор указывает на части одной большой строки. В IDA будет показано что-то типа str_YesNoMaybe+18h (придётся либо разбивать строку, что неправильно, либо каждый раз отсчитывать смещение, чтобы понять, какая именно часть строки там используются), а в BN — просто {Maybe}. Также в BN по этой же причине не надо тратить время и переименовывать строки во что-то осмысленное, потому что содержимое строки всегда перед глазами.

7. Очередной плюс, из-за которого я стал пользоваться BN — возможность виртуально разметить огромную область памяти, которая не будет вся записана в БД проекта, как это делается в IDA.

   Я работал с загрузчиками, в коде которых были ссылки на всё подряд, начиная от кода и данных других загрузчиков и кончая регистрами, которые отвечают за работу с периферией устройства. Естественно, все эти ссылки разбросаны по всей памяти устройства, т. е. на 8Гб. Чтобы были видны все эти ссылки (которые могут ссылаться на поля необходимых структур) в IDA, самими разработчиками были предложены такие варианты решения проблемы:

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

   • разрабатывать плагин, который бы отследил все ссылки, указывающие на неразмеченную память, определил бы размер структуры, т. е. сразу же бы определил тип переменной…​ в общем, сделал бы за меня весь анализ.

   Данную проблему можно было бы решить в r2, что я и делал до поры, до времени, пока не достиг критического числа баг при анализе, количество которых мне уже не позволяло производить реверс-инжиниринг плодотворно. Тут то мне на помощь и пришёл BN со своей возможностью виртуально разметить хоть 0xffffffff байт памяти без ущерба производительности и размеру БД проекта.

8. Очередная киллер-фича BN — API. Есть хорошая документация, абстракции логичны и чётко сгруппированы, багов не обнаруживал, но те, что есть — быстро исправляются. Что также важно для меня: API есть для C, а не только для C++/Python, что позволяет нам сразу реализовать FFI практически для любого языка программирования. В общем, здесь много писать не буду — просто попробуйте, сразу захочется реализовать все те идеи, о которых мечтали, но мешал страх перед громоздким, неповоротливым и нелогичным API IDA.

9. BN — мультипоточный, весь анализ проводится в разы быстрее, что, конечно же, является плюсом, особенно вкупе с качественными алгоритмами анализа. К тому же есть API для реализации мультипоточной работы плагинов, есть возможность постановки задач в очередь. К сожалению, есть одно НО — мультипоточная работа предусмотрена только в коммерческой и энтерпрайз лицензии, которых у меня, нет.

10. Из той же оперы: в энтерпрайз лицензии есть возможность коллаборации «из коробки», функциональность которой я не проверял по вышеназванной причине.

11. Как уже было упомянуто раннее, API у BN — хороший, по этой причине люди разрабатывают множество полезных плагинов (вплоть до реализации крупных систем по анализу бинарных файлов редких архитектур — 1, 2, 3, 4, 5, 6, написанных даже на stack-based языках). Кроме этого, есть пакетный менеджер всех плагинов, когда-либо разработанных для BN, также есть контроль версий. Установка плагинов производится из командной строки с помощью вызовов API.

12. В именах переменных, функций и прочего можно использовать практически любой UTF-8 символ (см. рисунок), что бывает полезным при реверс-инжиниринге языков с алгебраическими типами, шаблонов C++, дженериков и прочего.

    

    Рисунок 10. В названии функции используются некорректные для IDA символы, а в названии переменной используются UTF-8 символы

13. Лично мои ощущения: графы потока управления строятся более логичней и интеллектуальней (базовые блоки с операциями очистки памяти, возвратами из функции всегда внизу, главная логика в центре), нежели в IDA. Что я имею ввиду: допустим, у каждого базового блока есть по два выхода — выражение верно вычислено и выражение вычислено неверно, т. е. возвращаемся из функции. В IDA подобного рода граф может отображаться скученно, в BN же все связи, ведущие к возврату из функции будут отделены от связей, которые ведут по главной логике (чтобы понять — см. рисунок).

    

    Рисунок 11. Слева — IDA, все базовые блоки стоят рядом друг с другом, граф смещён вправо; справа — BN, базовые блоки, ведущие к возврату из функции стоят отдельно, также, как и все связи, ведущие к возврату из функции

14. Этот плюс отчасти относится к уже описанному. Хочу только добавить, что подобный функционал работает для всего: ты указываешь тип переменной (регистра, участка памяти и т. д.), а во всём коде, до куда дотянется анализатор, произойдут изменения в соответствии с типом, который ты указал — преобразуется вид в hex-редакторе, сменятся прототипы функций, «переиграется» символьный анализ и т. п. Тоже самое происходит и в IDA, но не настолько глубоко, видимо, из-за ограниченности анализа.

15. Для анализа ещё одного проекта не нужно открывать целую программу, все проекты открываются во вкладках. Думаю, что в будущем это можно будет как-то использовать при разработке плагинов, либо это уже используется, но в коммерческих лицензиях.

16. Изначально заточен для Unix-based систем, что для меня большой плюс. Кроме этого, интерфейс программы не перегружен, нет всяких лишних кнопочек и тулбаров. Надо отдать должное, IDA интерфейс я без труда превращаю в такой же минималистичный.

17. В BN просто приятнее работать в плане интерфейса (уже упоминал выше), кроме того, всё более плавное, скорость отзывчивости UI мне показалась выше, чем у IDA, за время работы багов в интерфейсе не обнаружил. На ноутбуке пользуюсь тачпадом при анализе (были бы хорошие хоткеи и клавиши навигации, не пользовался бы вовсе): в IDA просто невозможно плавно двигать граф. Стоит иметь ввиду, что данное мнение очень субъективное

4. Итоги и рекомендации

Стоит снова обратить внимание на тот факт, что я описывал все плюсы и минусы, относительно своей позиции, возможно, какой-то функционал даже не был рассмотрен, просто потому, что он мне не был нужен в ходе анализа. Также я могу ошибаться, просто не знать, как работает тот или иной функционал, если кто-то знает — сообщите мне, пожалуйста.

Прежде чем делать какие-либо выводы, следует знать, что каким бы ни был крутым инструмент, многое всё равно зависит от самого исследователя, от того, какие методы анализа он применит. И вообще: лучшее решение — решение, написанное под конкретную задачу.

Существует ещё множество минусов BN, которых нет у IDA, это и понятно, т. к. BN относительно молодой проект. Но также есть множество интересных особенностей у BN, которые, я думаю, не так-то просто реализовать с помощью плагинов для IDA.

Кому бы я порекомендовал использовать BN?

• Людям, которые анализируют редкую/неизвестную архитектуру. Разработка плагина у вас займёт гораздо меньше времени, нежели под IDA, а на выходе вы получите относительно качественный анализ.

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

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

• Кто пишет плагины для автоматического анализа машинного кода, и им требуется какая-то стартовая система для проведения дизассемблирования и начального анализа. Но здесь не всё так хорошо, чаще всего GUI для этой задачи вообще не нужен, а чтобы использовать API в режиме headless — нужна коммерческая лицензия.

• Если вы интересуетесь техниками анализа, заинтересованы в заимствовании каких-то функций из BN, интересуетесь IL.

В остальных случаях, если вам не интересно и нет любопытства, то, наверное, не стоит терять время и пробовать BN, сигнатур для определения каких-то шаблонных вещей там пока мало, ваших многочисленных любимых плагинов там тоже нет, особенно каких-то специфичных, но самое критичное для меня — отсутствие полноценной системы нахождения перекрёстных ссылок.