Линуксоиды, берегитесь: новая Ghidra может «уронить» вашу графическую сессию

Ghidra, бесплатный фреймворк для реверс-инжиниринга от исследовательского подразделения АНБ США, получил релиз 12.0 — с ускорениями, исправлениями и набором заметных изменений, которые затронут и обычных пользователей, и тех, кто автоматизирует анализ. Платформа по-прежнему ориентирована на разбор скомпилированного кода под Windows, macOS и Linux и сочетает дизассемблер, декомпилятор, отладчик, эмуляцию, графы и скрипты, а также возможность расширять систему плагинами, загрузчиками, анализаторами и новыми визуализациями.

Разработчики отдельно подчеркивают совместимость: проекты из прежних версий открываются, но всё, что вы создадите или измените в 12.0, уже может не заработать в более старой Ghidra. При этом у релиза есть жёсткое требование по окружению — для запуска нужен как минимум JDK 21, а для использования Debugger или полноценной сборки исходников понадобится установленный Python 3, причём поддерживаются версии от 3.9 до 3.13.

В заметках к выпуску есть и важное предупреждение для Linux-пользователей: сообщалось о падениях XWindows-сервера, которые связывают с регрессией после исправления CVE-2024-31083 в X.org в апреле 2024 года. В качестве ориентиров названы версии, где проблема, по данным разработчиков, уже устранена: xwayland 23.2.6 и xorg-server 21.1.13 — если при запуске Ghidra у вас происходит «выброс» из сессии, стоит проверить обновление X.org до этих уровней.

Одна из самых заметных новинок 12.0 — серьёзно расширенная поддержка link-files внутри проектов и новый формат хранения таких ссылок. Раньше упор делался на ссылки на внешние папки и файлы через Ghidra URL, а теперь появились внутренние ссылки на папки и файлы, причём как абсолютные, так и относительные, и для них введён новый облегчённый формат на основе property-файла без базы данных. Это открывает удобные сценарии, например более точное отражение реальной структуры файловой системы с символьными ссылками, чтобы один и тот же контент не импортировался многократно под разными путями, но разработчики предупреждают о рисках запутанных или циклических ссылок и советуют избегать конфликтующих путей, когда папка и файл имеют одинаковое имя.

Эта логика продолжается и в импорте: в 12.0 добавили режим «зеркалирования» локальной файловой системы при импорте программ и библиотек, включая симлинки, а в headless-режиме для этого появился параметр командной строки -mirror. Параллельно обновился Python-стек: PyGhidra 3.0.0 объявлен совместимым с Ghidra 12.0+ и приносит новые Python-ориентированные методы для типовых задач, а движок скриптов по умолчанию сменился с Jython на PyGhidra — старые Jython-скрипты продолжат работать, но для этого им потребуется заголовок # @runtime Jython.

Для тех, кто активно использует эмуляцию и отладку, релиз добавляет экспериментальный Z3-базированный «concolic»-режим, где символическая часть работает рядом с конкретной эмуляцией и строит выражения и ограничения ветвлений, следуя пути, который задаёт «конкретное» выполнение. Доступ к этому сценарию предлагается через расширение SymbolicSummaryZ3 и соответствующий плагин в Debugger/Emulator, но потребуется Z3 версии 4.13.0, а в отдельных окружениях можно столкнуться с отсутствующими или несовместимыми библиотеками, которые придётся поставить или собрать вручную. Заодно заметно переработали API эмуляции PcodeEmulator в сторону композиции и колбэков, чтобы упростить будущую интеграцию JIT-ускоренного эмулятора в интерфейс, хотя старые расширения на наследовании могут продолжать работать после минимальной адаптации.

Из «пользовательских» новинок в 12.0 появились новый граф данных, который показывает связи между элементами данных в памяти по ссылкам и позволяет разворачивать их дальше, а также переключатель отображения переменных функции прямо под сигнатурой в листинге, как глобально, так и для отдельных функций. В релиз вошла и возможность открывать объекты по GhidraGo URL из браузера, чтобы по клику запускать Ghidra, открывать нужный проект и сразу переходить к указанному адресу или символу. Наконец, расширилась аппаратная поддержка: добавили процессоры NDS32 и вариант RISCV AndeStar v5, а сам RISCV переработали для более аккуратной работы с кастомными расширениями и вынесли определения специальных регистров в отдельное адресное пространство, чтобы с ними можно было работать как с «реальными» объектами памяти.