Нативный анализ с REA: что вызывает «File too large»?

01. Используйте ошибку как точку входа

Приложение отказывается принимать файл. Интерфейс сообщает «File too large», но имеются ли в виду байты, декодированные пиксели, сжатый размер или ограничение сервиса? Восстановите логику решения перед изменением своей реализации.

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

npx -y rea-agents@6.4.0 search "/absolute/path/program" --pattern="File too large" --kind strings --provider ghidra --format json

02. Найдите функцию, использующую строку

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

Заглушки ниже нужно заменить адресами, возвращёнными для вашего бинарного файла. Адреса другой сборки невзаимозаменяемы.

npx -y rea-agents@6.4.0 xrefs "/absolute/path/program" --address="RETURNED_STRING_ADDRESS" --provider ghidra --format json
npx -y rea-agents@6.4.0 decompile "/absolute/path/program" --procedure="RETURNED_FUNCTION_ADDRESS" --provider ghidra --format json

03. Восстановите сравнение вместе с единицами

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

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

Используй возвращённые данные функции, чтобы объяснить ветвь, выдающую эту ошибку. Проследи сравниваемое значение до входа. Определи порог, единицы, знаковость и точное сравнение. Если декомпиляция неполна, изучи инструкции и соответствующую вспомогательную функцию. Укажи адреса и пометь неустановленные типы вместо догадок.

04. Проверьте границу, а не только успешный сценарий

Если восстановленное правило использует порог L, проверьте L−1, L и L+1 в фактических единицах входа. Также проверьте ноль и некорректный ввод там, где приложение его принимает. Выполняйте это только в контролируемой копии программы.

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

• L−1: принят или отклонён?
• L: проходит ли равенство?
• L+1: какая ошибка возвращается?
• Отклоняется ли некорректный ввод раньше, в другой ветви?

05. Соразмеряйте вывод с данными

Ваш результат — одно восстановленное правило и выполненные для него тесты. В этой статье процесс не выполнялся для конкретной цели; текст ошибки — пример сценария, который следует заменить своим.

Как реальный пример такого подхода проект REA документирует функцию звуковой панорамы DX-Ball: отчёт отделяет 3 205 дифференциальных проверок входов от отдельного совпадения 63 байтов компилятора. Ни одно утверждение не означает воссоздание всей игры. См. официальное руководство по нативному коду и его разбор по ссылке.