GHIDRA vs. IDA Pro18.12.2019 18:48

Приветствую,

Думаю, пришла пора. Наболело/накипело/есть мнение. С выходом Гидры ситуация с инструментарием для реверс-инженеров достаточно сильно изменилась. Если раньше выбора чем пользоваться особо не было (здесь не будут упоминаться Binary Ninja, Hopper, JEB или Radare2, потому как в известных мне ИБ-компаниях и комьюнити ими пользуется очень малое количество человек, либо же порог вхождения в некоторые (привет, Радар) очень высок, либо же покрытие архитектур ограничено лишь x86/x64/ARM/ARM64/MIPS), то теперь мы имеем очень мощного конкурента Hex-Rays в лице АНБ с их GHIDRA.

Но так ли Гидра хороша? Так ли плоха IDA (или наоборот)? Давайте разбираться. В данной «статье» я постарался свести все плюсы и минусы обоих инструментов. У меня не было цели сказать, что тот или другой инструмент лучше — выводы делайте сами. К тому же, и один и второй инструмент развиваются. И статья будет содержать лишь результаты сравнения на момент написания. Сравнение будет производиться по следующим категориям:

1. Поддерживаемые архитектуры
   

   Если вы — реверс-инженер, работающий только с Intel-платформами (x86/x64), то наличие всех остальных для вас не имеет особого значения. Но, если вам приходится работать с множеством различных файлообменников архитектур, то чем больше их будет в дефолтной поставке, тем лучше.
   

2. Поддерживаемые форматы
   

   То же самое, что и в предыдущем пункте, только касаемо форматов данных.
   

3. Качество декомпиляции
   

   Чуть ли не самый нужный и важный компонент — декомпилятор. От одного только дизассемблера смысла особо нет, поэтому здесь — обзор того, что умеет/выдаёт Ghidra/IDA.
   

4. Расширяемость функционала, SDK/API
   

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

5. Документация
   

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

6. Отладчик (для исследуемых файлов)
   

   Важный и необходимый компонент для среды реверс-инжиниринга. В статике тоже можно, но в динамике всяко проще.
   

7. Скорость анализа файлов
   

   Если дело касается очень больших файлов (от 10 МБ и больше), важно, чтобы среда для реверс-инжиниринга не заставляла уходить пить чай, ложиться спать, пока идёт анализ файла.
   

8. Удобство работы (интерфейс, горячие клавиши, ориентированность на ввод с клавиатуры)
   

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

9. Выход новых версий
   

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

10. Сложность получения дистрибутива
    

    Купить, скачать, собрать дистрибутив — это всё здесь.
    

11. Поддержка
    

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

12. Комьюнити
    

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

13. Совместная работа над проектом
    

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

Сравнение

1. Поддерживаемые архитектуры (IDA)

Из коробки IDA Pro поддерживает очень большое количество процессоров и их модификаций. Список внушает уважение: https://hex-rays.com/products/ida/processors.shtml
Список процессоров отличается для Starter и Professional Edition, 64-bit поддерживается только в Pro-версии. Платформы в последней достаточно редкие, но, тем не менее.

Если работа не ориентирована на IoT, то хватит и Starter, иначе — придётся покупать Pro-версию.
Декомпиляция имеется лишь для x86/x64/arm/arm64/PowerPC, в первой половине следующего года обещают выкатить декомпилятор MIPS.

1. Поддерживаемые архитектуры (GHIDRA)

Онлайн версии списка нет, поэтому привожу его здесь:

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

2. Поддерживаемые форматы (IDA)

Список форматов здесь: https://hex-rays.com/products/ida/file_formats.shtml

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

2. Поддерживаемые форматы (GHIDRA)

Список выше — это лишь список каталогов в https://github.com/NationalSecurityAgency/ghidra/tree/master/Ghidra/Features/FileFormats/src/main/java/ghidra/file/formats
Другой список файлов здесь: https://github.com/NationalSecurityAgency/ghidra/tree/master/Ghidra/Features/Base/src/main/java/ghidra/app/util/bin/format

3. Качество декомпиляции (IDA)

Декомпилятор у Иды замечательно работает с x86/x64/arm/arm64 кодом (про PowerPC сказать не могу, т.к. не доводилось встречаться), который был сгенерирован каким-либо стандартным компилятором, выдаёт в большинстве своём аккуратный C-листинг.

Разработчики изначально ориентировались на MS-DOS код, поэтому учитываются артефакты даже довольно старых компиляторов (отсюда в интерфейсе во многих окнах имеются сегменты, сегментные регистры, es/ds/ss/fs/gs (ds — даже на MIPS!)), вплоть до вполне новых. Правда со включенными оптимизациями компиляторов IDA справляется не так хорошо, и выхлоп превращается в ад.

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

Необходимость задавать нужные регистры вручную в строке ввода прототипа функции через __usercall с её @ и <>, с одной стороны — большой минус, особенно, когда регистров много, а с другой — у Гидры такого нет, и там — только через GUI, что не всегда удобно, если количество используемых регистров мало.

3. Качество декомпиляции (GHIDRA)

Я не знаю людей, которые скажут, что декомпилятор Гидры классный. Тут за радость скорее то, что он вообще есть, и есть для каждого поддерживаемого процессора!

У декомпилятора Гидры много непривычного глазу пользователя Иды мусора в выдаваемом коде, что часто отвлекает от понимания сути происходящего в нём.

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

Также декомпилятору Гидры всё равно, в каких регистрах приходят аргументы — если к ним идёт обращение, они будут использованы.

Тут хотелось бы отметить, почему у Гидры или у Иды имеются свои особенные проблемы с декомпиляцией. Дело в ориентированности каждого из продуктов. IDA, как я уже отмечал выше, создавалась с ориентацией на MS-DOS и, в целом, на x86, затем постепенно покрывая x64 и ARM. Отсюда просто замечательное качество выхлопа для указанных платформ, но абсолютно никакое покрытие других.
У Гидры наоборот — она создавалась с целью реверс-инжиниринга IoT-устройств. Отсюда большое количество поддерживаемых процессоров, внятное описание каждого из них, и простая возможность создавать новые. Но, из-за того, что разработчики старались покрыть множество архитектур, улучшение выхлопа декомпилятора не стало приоритетной задачей.

4. Расширяемость функционала (IDA)

Ида позволяет писать загрузчики, плагины, отладчики и процессорные модули, а также скрипты прямо в интерфейсе. Некоторые можно писать и на питоне, что немного удобнее (через плагин IDAPython, написанный не разработчиками IDA, автор — Elias Bachaalany).

Процесс разработки плагинов во времена версий 6.x был достаточно сложным, т.к. вменяемая документация отстутствовала. Теперь времена изменились, написать своё поделие стало проще. Имеется контест, проводимый каждый год, где разработчики выбирают лучший на их взгляд плагин (а взгляд довольно таки спорный). Например, в последнем контесте победил, никогда не угадаете какой сократитель расширитель функционала… Им оказался плагин, который УБИРАЕТ поддержку Undo в IDA! Просто нет слов. Об этой возможности разработчиков просили так долго, но, пока не вышла GHIDRA, никто и пальцем шевелить не хотел. А теперь — пожалуйста, убрать крутую фичу плагином — Вы выиграли, поздравляем!

Отладка плагинов производится легко, особенно если он был написан на C++. Отлаживать скрипты на питоне или IDC — уже сложнее, и официального способа нет.

Очень сильная боль в заднем проходе началась, когда в версии 7.0 практически полностью переписали API, сделав его несовместимым со старыми версиями. С одной стороны, названия функций сделали понятнее, поубирали лишние аргументы, разработка стала проще. Но, если вы, как и я, разрабатывали плагины ещё для версий 6.x, и потребовался перенос вашего детища на свежий SDK, то, головная боль была вам обеспечена.

А потом в версии 7.1 снова произошли изменения, и всё нужно было чинить по-новой.

4. Расширяемость функционала (GHIDRA)

Ghidra написана на Java (с декомпилятором на C++), с поддержкой скриптинга на Python (через Jython). В стандартной поставке имеется плагин GhidraDev для Eclipse, позволяющий создавать шаблоны проектов (который можно импортировать потом в IntelliJ IDEA). Авто-дополнение в IDE и документация работает прекрасно и, на то, чтобы разобраться с написанием своего первого плагина уйдёт от силы полчаса.

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

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

5. Документация (IDA)

Документация IDA — её слабое место, и так повелось уже давно. Как и у большинства разработчиков, уклон идёт в функционал, нежели в его документирование. Отсюда и скудный HLP-файл, идущий в поставке.

Книга »IDA Pro Book» была написана не разработчиками, и выходила только для 6-й версии. С тех пор новых книг не выпускалось, мануалов по разработке плагинов от разработчиков нет.

Где-то с версии 7.0 документация начала обрастать веб-версией, и скудным описанием API-функций из SDK.

5. Документация (GHIDRA)

Документация у Гидры, в отличие от Иды, писалась одновременно с разработкой. Отсюда, мы имеем комментарии к практически каждой вызываемой функции API, элементам перечислений, и классам. Справочный файл, идущий в поставке, и описывающий интерфейс и настройки Гидры, также выполнен добротно, со скриншотами и примерами для, фактически, каждой кнопки или пункта меню.

6. Отладчик (IDA)

ДА, он есть. И он работает. Windows, Linux, MacOS, плюс возможность приконектиться по gdb. По поводу последнего: для большинства нестандартных платформ приходилось писать собственный модуль-отладчик, теперь же есть возможность отлаживаться через gdb для таких платформ, как: x86/x64, ARM/AArch64, PowerPC, MIPS, Motorola 68k, Infineon TriCore, Renesas RH850. Полный список здесь: https://hex-rays.com/products/ida/debugger/index.shtml#details

6. Отладчик (GHIDRA)

Увы, но отладчика в публичном доступе пока нет. В доках на WikiLeaks были упоминания некоторых отладочных модулей. Тем не менее, известно о том, что в АНБ работают над этим, и отладчик будет!

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

7. Скорость работы (IDA)

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

7. Скорость работы (GHIDRA)

Когда разговор двух реверсеров доходит до обсуждения скорости работы этих Иды и Гидры, каждый приходит ко мнению, что Гидра оооочень долго обрабатывает большие файлы. Хотя и написана с учётом многопоточности. А виной всему Java: плюс к кросс-платформенности, минус к скорости. Тем не менее, если настроить количество памяти, стека и кучи для JVM, а также число потоков, работа слегка ускоряется.

8. Удобство работы (IDA)

Несомненно, многие знают горячие клавиши Иды наизусть. Они простые и понятные, часто интуитивные. Многие пункты меню и фичи Иды умеют вызываться с клавиатуры, что вполне удобно.

Касаемо внешнего вида, до какой-то из версий 6.x использовался самописный графический интерфейс. Далее разработчики полностью перешли на Qt. Интерфейс стал однозначно приятнее. Расположение вкладок, кнопок и элементов интерфейса не менялось уже очень давно.

Отсюда вытекают и плюсы, и минусы. Плюсы — интерфейс привычный, не нужно искать что где находится, и бороться с привычками. Минусы — некоторые элементы остаются рудиментарными (редактор структур выглядит как наследие именно старых версий Иды) или не используются 90% времени…

8. Удобство работы (GHIDRA)

Здесь всё с точностью до наоборот. Новый продукт на рынке, различие горячих клавиш по сравнению с Идой, делают своё дело. Скорость работы, которая за большое время работы с Идой достигла огромной скорости, в Гидре начала проседать. Но, понятное дело, при длительной работе в последней привычки также появляются, и становится не так тяжело.

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

Т.к. Ghidra написана на Java, разработчики использовали базовый функционал JDK, а именно Swing. Из-за этого имеем то, что имеем. Но это нельзя назвать минусом Гидры.

9. Выход новых версий (IDA)

Вы заметили, что с выходом Гидры новые версии Иды стали выходить чаще? А я вот присмотрелся. Знаете почему? Конечно, дело в конкуренции. Наконец-то она появилась!

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

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

9. Выход новых версий (GHIDRA)

Регулярность выпуска новых версий Гидры достаточно большая: с момента публикации исходников вышло около шести версий.

Если ждать выхода нового дистрибутива долго, можно собрать master-ветку с github. Первый раз собираться будет больше часа, но, оно того стоит.

10. Сложность получения дистрибутива (IDA)

Все знают эту историю:»Ильфак Гуильфанов — пиратству бой! ». Из-за этого доступ к Pro — и Starter-версиям дистрибутивов для покупки стал очень сложным и муторным. Для простых смертных, у которых нет доступа к бешеным деньгам почтовым ящикам не на публичных почтовых серверах типа gmail, mail.ru и т.п., приобретение дистрибутивов невозможно. И, даже если у вас есть свой ИП, свой сайт, вам придётся пройти множество проверок, выслать сканы, подтверждения и т.д. И всё ради того, чтобы дистрибутив не выложили в интернет. Это не всегда помогает.

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

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

10. Сложность получения дистрибутива (GHIDRA)

Казалось бы, тут писать вообще нечего, но. На самом деле, к основному сайту Гидры доступ из России, Израиля и Китая запрещён. Нужен VPN, или Tor (скорость скачивания соответствующая). На github релизов нет, только исходники.

11. Поддержка (IDA)

Сколько мне приходилось общаться с поддержкой Hex-Rays, всегда был разный опыт: часть людей, работающих в саппорте, очень вежливые и всегда готовы помочь. Часть: главный разработчик, и общение становилось грубым. Особенно если мнение не совпадало. Но, наверное это характер такой. То же самое и в общении с пользователями в интернете.

Недавно выяснилось, что с саппортом из моих знакомых общаюсь только я. Очень старая бага, связанная с потерей выделения при прокрутке, возникшая ещё в версии 6.6, о которой знают все, никогда не была зарепорчена разработчикам. Спросил, в чём же дело. А ответы в стиле:»не хочется общаться с человеком, который так относится к пользователям». Увы, репутация работает именно так.

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

11. Поддержка (GHIDRA)

У Гидры есть репозиторий на github. Там есть issues, и именно туда необходимо сообщать о багах. Скорость ответа на некоторые может быть как очень долгой, так и достаточно быстрой. Но, баги не закрываются просто так, мол, не хотим это реализовывать. Всё рассматривается, учитывается. Каждый желающий может внести свою лепту.

PR применяются и рассматриваются медленно. Зависит от критичности.

12. Комьюнити (IDA)

Его скорее нет, чем есть. Разрозненные разработчики, реверс-инженеры, каждый со своими скриптами и плагинами. Нет специализированных чатиков, каналов, в которых можно было бы поболтать со знающими людьми, спросить совета.

12. Комьюнити (GHIDRA)

Здесь всё совершенно иначе: сайты типа ghidra.re, телеграм-группы, типа @GHIDRA, тот же github. На всех этих ресурсах можно задать любой вопрос, и получить на него ответ или помочь в решении.

13. Совместная работа над проектом (IDA)

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

13. Совместная работа над проектом (GHIDRA)

Данный функционал присутствует в Гидре из коробки. Можно создать Гидра-сервер, который будет синхронизировать результаты работы.

Выводы

С выходом Гидры многое изменилось. Появилась конкуренция, появилась бесплатная среда для реверс-инжиниринга. Но, это как с Linux в организациях — на внедрение/обучение/переквалификацию нужно время и, если однажды потратить время на всё это, дальше будет легче.

Плюс немаловажную роль играет стоимость покупки/ежегодного обновления IDA. Не все молодые компании могут себе позволить купить дистрибутив, да ещё с декомпилятором. Да и могут ли они её купить.

Также, если для вас важна совместная работа над проектами, стоит обратить внимание на Ghidra. Почему данный функционал так и не был реализован в IDA — не понятно.

Конкуренция — это хорошо. Без неё вообще никак. Я не считаю, что Ghidra лучшая, а IDA — плохая. У каждой из них есть свои плюсы и минусы, но однозначно реверсить малварь легче в Иде, IoT и другие устройства — в Гидре. А выбор всё равно за вами.

Получилось немного сумбурно, но, тем не менее. Спасибо.

P.S. Добавил пункт про совместную работу над одним проектом.
P.P. S Добавил список форматов 2

© Habrahabr.ru