Скрипты для восстановления определений строк в двойных двоичных файлах с анализом P-кода. Протестировано с x86, x86-64, ARM и ARM64.
Их можно найти в категории Голанга в менеджере сценариев.
GoDynamicStrings.javaGoFuncCallStrings.javaGoStaticStrings.javaGoKnownStrings.javadata/known_strings.json .GoStringFiller.javago.string.* После первоначального анализа, на основе порядка возрастающей длины строковых данных.Существует также несколько особых вариантов сценария динамического анализа строк:
GoDynamicStringsSingle.javaGoDynamicStrings.java , но использует один процесс декомпилятора. Используйте это, если анализ двоичного файла приводит к процессам параллельного декомпилятора в память о выхлопной системе.GoDynamicStringsHigh.javaЭто можно найти в категории PCODE в диспетчере скриптов.
PrintHighPCode.javaВот общий поток для использования этих сценариев для восстановления строковых определений в бинарном виде:
.rodata , .rdata или __rodata . Затем щелкните правой кнопкой мыши в списке кода и выберите «Очистить байты кода».GoKnownStrings.java , чтобы обнаружить некоторые стандартные строки.GoStaticStrings.java .GoFuncCallStrings.java (если бинарная версия Golang поддерживается встроенными функциями Golang's Golang) .GoDynamicStrings.java .GoStringFiller.java .go.string.* На первой строке.go.string.* И определите любые строки с очевидными начальными и конечными точками.GoStringFiller.java , определите, где длины строки меняются в неопределенных строковых данных, и определите строки, наиболее близкие к этой границе. Затем повторно запустите GoStringFiller.java , чтобы автоматически заполнять пятна, где он может правильно определить длину оставшихся неопределенных строк.В Ghidra:
Для затмения с плагином Ghidradev:
Строить с затмением:
Строить прямо с Gradle:
$ cd Ghostrings
$ gradle -PGHIDRA_INSTALL_DIR= < ghidra_install_dir > Хорошо известная проблема с программами обратной инженерии GO заключается в том, что отсутствие нулевых терминаторов в строках GO затрудняет восстановление строк из составленных двоичных файлов. Многие из постоянных строковых значений программы GO хранятся вместе в одном гигантском Blob в скомпилированной сборке, без каких -либо символов терминатора, встроенных в строковые данные, чтобы отметить, где заканчивается одна строка, а другая начинается. Даже простая программа, которая просто печатает "Привет, мир!" имеет более 1500 строк в ИТ, связанных с системой времени выполнения GO и другими стандартными библиотеками. Это может привести к типичным реализациям обнаружения строки ASCII, например, предоставленной Ghidra, для создания ложных определений положительных строк, которые составляют десятки тысяч символов.
Вместо нулевого завершенного строк GO использует строковую структуру, которая состоит из указателя и значения длины. Многие из этих строковых структур создаются в стеке программы во время выполнения, поэтому для восстановления отдельных мест запуска строки и значений длины требуется анализ скомпилированного машинного кода. Существует несколько существующих сценариев, которые выполняют этот анализ, проверяя определенные шаблоны инструкций X86-64, но они пропускают структуры, созданные с невозможными вариациями инструкций, которые в конечном итоге оказывают одинаковое влияние на стек, и они также ограничены определенным ISA.
Ghostrings избегает обеих этих проблем, работая с упрощенными, независимыми от архитектуры операций P-кода, создаваемыми анализом декомпилятора Ghidra.
Copyright 2022 NCC Group. Выпущено по лицензии GPLV3 (см. Лицензию).
Основной автор проекта: Джеймс Чамберс Джеймс[email protected]