О, r2pipe это боль. И сам радар боль. И жизнь это боль. Я перед гидрой делал еще заход на радар и это было целое приключение с грустной развязкой. На самом деле хотел отложить это пока в официальных сборках cutter'а не введут питон-байндинги (уже может быть и ввели даже, в исходниках уже было, но релизы без них), но тут гидру выкатили. Если вкратце r2pipe это выполнение радарокоманд и получение их результатов в виде... html. Сравнивал выхлоп tricore-модуля радара, иды и trace32 - в иде 2 бага в самом дизасме, в trace32 2 бага в дизасме, радар тупо не поддерживает актуальный набор инструкций. Также знаю, что renesas sh та же петрушка - нет набора инструкций sh2a. То есть наверное только числом поддерживаемых архитектур радар гидру превосходит (а как их поддерживает только что сказал), в остальном не знаю даже зачем он теперь нужен. Гидру с радаром по-моему вообще нельзя сравнивать, гидра это другой уровень качества даже в сравнении с идой.
Куттер явно не конкурент гидре, даже когда допилят, это очевидно. Просто если речь про джаву, то почему гидра оказалась удобнее r2pipe (для java) ? Разве не удобнее трассировки, брэкпоинты и прочее, характерное для динамического анализа в радаре? Если цель снимать упаковщики и протекторы, гидру с какого конца следует изучать?
Блин как объяснить-то) r2pipe это текстовый интерфейс для команд радара, чем гидра, в скриптах которой доступна вся ее нутрянка в виде классов/интерфейсов, удобней этого?) Дебаггера в гидре нету. Они там конечно же появятся, если еще не появились, но сейчас даже намеков не наблюдается. Отладка конечно же всегда предпочтительней, если она вообще возможна. Для контроллеров это не такая тривиальная вещь, как для x86. Мы даже при наличии аппаратных интерфейсов-отладчиков без крайней-крайней нужды их не расчехляем. А даже когда это случается, ида ничем помочь не может, в ход идет UDE или что-то в этом роде. Ну вот в качестве отладчика, который кое-что может в плане анализа, радар может еще и годится (бесплатная оля и бесплатный дебаггер от мистера ексодии правда могут с этим не согласиться).
UDE - это что? графика не нужна, скорее подходят gdb и windbg со скриптами для них. Получается со скрипта запускаем процесс, стопим, дампим (дамп в гидру), думаем, переписываем скрипт, стопим где-то позже, опять дампим, опять в гидру, так что-ли предлагается работать создателями гидры?
Спойлер: что это https://www.pls-mc.com/universal-de...s32v234-s32/universal_debug_engine-a-802.html По всей видимости, анб не использовало гидру как отладчик, либо выложили не все. Раз это теперь опенсурс, наверное кто-нибудь задумается об этом упущении, по крайней мере все возможности для этого есть. Ида тоже не абы какой отладчик, и ничего, ей это не мешает.
годные фичи из гидры тихо-мирно утекут в идушку + насколько помню, шла речь об искусственном урезание функций иды, дабы не помогать блэкхэтам. к примеру, развитый декомпиль не так уж нужен для работы с малварью, зато для взлома софтины и угона алгосов без него трудно
Думаю, произойдет ровно наоборот. Потому и выкатили в открытый доступ, что бы зачистить рынок полностью от тех, с кем пришлось бы договариваться.
Тебе ничего не мешает сделать простенький скриптик, который разберет быстрей, либо поиграться со списком плагинов-анализаторов.
Ну не знаю, я делал раньше неплохие скрипты-анализаторы (приходилось, потому что ида только интел более-менее сносно разбирает), потом пришел к ручному и полуручному разбору - оказался самым эффективным способом. По крайней мере на иде. Насчет общей скорострельности гидры - ожидал, что совсем все плохо будет, даже удивился, насколько там прилично простенькие скрипты работают. Вся эта автоматика - попытка решить задачу общим способом и имхо предназначена для нубиков-кнопкодавов. Если работаешь над однотипными вещами, должен знать, как задача решается лучше частным способом в твоем случае. Без написания своих скриптов, что в иде, что в гидре не используешь все возможности на полную катушку.
А мне показалось об одном, о первичном анализе, обнаружении в образе кода по разным признакам, выделении в нем функций, анализе прототипа и натягивании сигнатур, чтобы обнаружить библиотечные. То, к чему больше всего претензий к гидре в плане быстродействия. Первый-второй шаг можно и самому реализовать, дизасм дальше сам подхватит. С чем еще помогут скрипты? С динамической адресацией например. Если через 15 вложенных функций тащится указатель или просто базовый адрес какой-то структуры, ида с ним возиться не станет. И гидра скорей всего не станет, их этому надо учить. У иды проблемы даже с тем, чтобы в пределах одной функции догадаться, что где-то там выше регистр, по которому здесь что-то адресуется, был инициализирован константой и неплохо бы это показать кросс референсом. При разглядывании функции в целом пофиг, неудобно просто, а если двигаешься от адресуемого места, это проблема.
Фигасе сопутствующие потери. При статическом анализе это критические потери, когда отладка недоступна. Ну если устраивает то, что прямо из коробки работает, либо уже кем-то написано, то ида предпочтительней. Так речь именно о том, что ида во многом и есть этот предыдущий шаг, где надо много делать самому, если за тебя энтузиасты на гитхабе не сделали
не так давно ее заоупенсорсили, как бы понятно, что много ума не надо джаву декомпилить, но все же теперь проект оупенсорц: https://github.com/NationalSecurityAgency/ghidra
че там эти сраные ковбои бормочат на импортном языке.. непонятно же.. требую перевода на православный русский язык!
На ютубе можно включить субтитры (сгенерированные распознаванием речи) и даже настроить их перевод на русский (видимо гуглтранслейтом). Гидра будет называться то "Кирра", то "Китра". Если вкратце, в куттере за последний год сделан ряд изменений (самое ценное - питоноплагины) и добавлена агрегация с гидродекомпилером (в иде это тоже случилось).