Зачем использовать NotHoly для реверс-инжиниринга

Реверс-инжиниринг это чтение. У вас уже открыт Ghidra, radare2 или IDA, а медленная часть это разобрать дамп декомпилятора, назвать локальные переменные и написать скрипт, который переименует следующие двести. Модель помогает тут, но только если берёт вопрос без нотации и читает то, что вы вставляете. NotHoly делает и то, и другое. Вы оставляете свои инструменты, а модель объясняет вывод и пишет скрипты. Сценарий реверс-инжиниринга содержит более длинный поток; здесь о том, почему это подходит.

#Вставьте вывод, получите объяснение и скрипт

Вывод декомпилятора и дизассемблера это ввод. Вставьте функцию из Ghidra, блок из radare2 или листинг из IDA, и модель объяснит, что она делает, назовёт структуру, которую видит, и отметит части, похожие на проверку границ, процедуру decode или парсер. Попросите скрипт, и она напишет его для вашего инструмента: проход на Ghidra Python, который переименовывает по шаблону, последовательность команд radare2, фрагмент IDAPython, hook Frida для логирования вызова. Скрипт идёт на вашей машине, против вашего образца, никогда не нашего. Раз модель не отказывает в задаче, процедура unpacking, запутанный цикл, трюк anti-debug или проверка лицензии читаются как любой другой код, пока работа в вашем scope.

r2 -q -c "pdf @ sym.main" ./bin | notholy "explain this function and write a radare2 script to rename the locals"

#Первый взгляд до тяжёлого инструмента

Прикрепите бинарник в чате или запустите notholy analyze, и статические инструменты дадут первый проход без открытия декомпилятора. Для ELF или PE вы получите SHA-256, размер, энтропию, формат, entry point, секции и imports. Для образца вы получите ещё strings и предпросмотр дизассемблера с начала файла. APK даёт manifest и текст каждой записи, а архив даёт своё дерево. Каждый файл разбирается в одноразовом sandbox без сети и с корнем только для чтения, ничто в нём не исполняется, а pickle Python разбирается через pickletools, никогда не загружается. Высокая энтропия и короткая таблица imports уже достаточны, чтобы решить, стоит ли образец часа в Ghidra. Справочник по файлам перечисляет типы и пределы.

#Что ещё в пределах досягаемости

База знаний это часть модели, так что вопрос о packer, формате файла или соглашении вызова подтягивает курируемую технику с источником и лицензией на каждом фрагменте. Строка версии, которую вы восстановили, идёт прямо в lookup CVE, который возвращает CVSS, EPSS и статус KEV с датами. И база знаний, и данные CVE читаются через CLI и через API тоже, так что пакет образцов можно отсортировать из скрипта, и та же модель, что объяснила функцию, набрасывает отчёт к ней. Та же модель, что набросала отчёт, превращает восстановленный формат в парсер, так что вы идёте от байтов к рабочему скрипту, не меняя инструмент.

#Где не подходит

Платформа не декомпилирует. У нас нет декомпилятора и нет графа потока управления, а встроенный предпросмотр дизассемблера останавливается на начале файла и коротком числе инструкций, так что настоящий листинг идёт из вашего Ghidra или IDA. Ничто не исполняется, и нет динамического анализа, нет отладчика и нет эмуляции, так что поведение упакованного образца во время выполнения вам наблюдать в своей лаборатории. Картинки дают только размеры, без OCR пока. И модель может неверно прочитать offset, выдумать API или объяснить функцию неправильно, так что относитесь к объяснению как к зацепке и сверяйте с байтами.

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