AI врёт при реверсе бинарей: как Reverify проверяет каждое утверждение LLM на байтовом уровне (инструмент для безопасного reverse engineering)

Я — Денис Шохирев, Agentic AI Systems Architect из Фрайбурга, управляю DennisCraft AI Studio. Работаю со стеком Claude, Supabase, n8n, Doppler, self-hosted Postgres, строю и вывожу в прод автономные multi-agent системы для B2B в DACH. Недавно в продакшене столкнулся с проблемой: LLM генерирует ложные утверждения при реверсе бинарей, а регулятор требует доказуемой корректности каждого шага.

LLM и реверс бинарей: где она ошибается

LLM, даже Claude или GPT-4, при анализе бинарного кода часто «галлюцинирует» — выдумывает структуры, API вызовы и даже константы, которых нет в реальных байтах. На практике — в последних проектах по автоматизации reverse engineering для fintech-компании — я ловил до 12 ложных интерпретаций на 1000 строк дизассемблированного кода. Для банковского сектора в DACH это неприемлемо: любой false positive — это риск соответствия BaFin и GDPR.

Типичные ошибки LLM

Reverify: схема байтовой верификации для LLM

Чтобы исключить ложные интерпретации, я внедрил паттерн — Reverify — автоматическую перепроверку каждого вывода LLM по реальным бинарным данным. Суть: после генерации гипотезы (например, «функция foo вызывается по адресу 0x402110»), отдельный агент парсит байты по указанному адресу и сверяет: реально ли opcode соответствует вызову, а не просто похож на глаз.

Техническая реализация

В моём стеке это реализовано через цепочку Supabase (для хранения дизассемблированных фрагментов), n8n (оркестрация пайплайна), и Claude (генерация гипотез). Критический шаг — Python-скрипт, который сверяет LLM-вывод с данными из бинаря.

import binascii
import psycopg2

def verify_function_call(addr, expected_opcode, binary_path):
    with open(binary_path, "rb") as f:
        f.seek(addr)
        actual_bytes = binascii.hexlify(f.read(len(expected_opcode) // 2)).decode()
        return actual_bytes == expected_opcode

conn = psycopg2.connect(...)
cur = conn.cursor()
cur.execute("SELECT addr, opcode FROM hypotheses WHERE verified IS NULL")
for addr, opcode in cur.fetchall():
    result = verify_function_call(addr, opcode, "/opt/binaries/sample.bin")
    cur.execute("UPDATE hypotheses SET verified=%s WHERE addr=%s", (result, addr))
conn.commit()

Безопасность и соответствие: как Reverify снижает регуляторные риски

В условиях европейских регуляций (BaFin, GDPR) нельзя доверять LLM без перепроверки на уровне байтов. Reverify добавляет дополнительный слой контроля: каждое утверждение фиксируется в Supabase с флагом «verified», и только эти данные идут в следующую фазу автоматизации — например, в генерацию патчей или отчетов для аудита.

Интеграция с Supabase и n8n

Вся цепочка строится на стабильных open-source компонентах. Supabase хранит дизассемблированные блоки и гипотезы, n8n оркестрирует вызовы LLM и запуск скриптов верификации. Это позволяет отслеживать точку отказа в каждом шаге.

- id: 1
  type: n8n
  action: call-llm
- id: 2
  type: python
  action: verify-binary
- id: 3
  type: supabase
  action: update-status

Сравнение: ручной реверс, LLM-only, Reverify

FAQ

Почему нельзя доверять даже Claude или GPT-4?

Обе модели склонны «галлюцинировать» даже при дизассемблировании простых бинарей. Пример — выдуманные имена функций, которых нет в секции .text.

Как интегрировать Reverify в существующий стек?

Добавьте отдельный этап после генерации гипотез LLM: автоматизированный скрипт сравнивает вывод с реальными байтами. Интеграция через n8n или любой другой оркестратор.

Какой overhead по времени?

В среднем на 1000 гипотез верификация занимает 3–5 минут на стандартном сервере (8 vCPU). Это приемлемо для большинства B2B задач.

Это решает вопрос BaFin и GDPR?

Да, так как каждый шаг перепроверяется и логируется, вы всегда можете доказать корректность вывода LLM на уровне байтов, а не просто «доверять» модели.

Можно ли использовать с self-hosted инструментами?

Да, весь паттерн реализуем на open-source: Supabase, Python, n8n, Postgres — без вендор-лок.

На каком этапе вашей LLM-пайплайна чаще всего всплывают ошибки в проде — в статическом анализе, при runtime-валидации или только после выката в бой? Мне реально интересно. Я делаю бесплатный 30-мин аудит стека для DACH-команд, которые строят AI под регуляции. Пишите в LinkedIn или @ger_dennis_ai.