Промпт для автономной декомпиляции кода: заставьте Claude работать 8 часов без вас

Зачем вам этот промпт? (Или почему декомпиляция — это не 5 минут)

Представьте: вы загружаете бинарник игры Snowboard Kids 2 для N64 в Claude. Пишете "декодируй эту игру". Ждёте 10 минут. Получаете... ничего.

Потому что декомпиляция — это не магия. Это десятки итераций, тысячи строк кода, постоянная корректировка стратегии. И самое главное — время. Много времени.

Что делает этот промпт особенным?

Не просто набор инструкций. Это автономный агент для реверс-инжиниринга. Система, которая:

• Сохраняет контекст через каждые 50 итераций (преодолевает ограничения памяти)
• Сам определяет, когда переключиться с анализа на генерацию кода
• Создаёт контрольные точки восстановления (если что-то пойдёт не так)
• Работает циклически 8+ часов без вашего участия

В статье "Автономная декомпиляция игр Claude" я описал архитектуру. Теперь даю готовый инструмент.

1 Сначала — как НЕ надо делать

Типичная ошибка новичка:

"Декомпилируй этот бинарник и верни исходный код"

Результат? Claude попытается сделать всё сразу. Запутается. Забудет, что делал 20 минут назад. Выдаст бессвязный код. Или просто остановится.

2 Архитектура промпта: три слоя контроля

Хороший промпт для декомпиляции работает как операционная система. Он управляет:

1. Процессом — что делать сейчас, что потом
2. Памятью — что сохранить, что забыть
3. Качеством — как проверить результат

Вот полный шаблон. Скопируйте. Вставьте в Claude. Настройте под свою задачу.

Готовый промпт для автономной декомпиляции

# === АВТОНОМНЫЙ АГЕНТ ДЕКОМПИЛЯЦИИ ===
# Версия: 2.1
# Для: Claude 3.5 Sonnet / Claude Code
# Автономная работа: 8+ часов

"""
ТЫ: Специалист по реверс-инжинирингу с 15-летним опытом.
ЦЕЛЬ: Декомпилировать предоставленный бинарник в работающий исходный код.

РАБОЧИЙ ПРОТОКОЛ:
1. НЕ ПЫТАЙСЯ СДЕЛАТЬ ВСЁ СРАЗУ
2. Работай итерационно, шаг за шагом
3. Сохраняй контекст каждые 50 итераций
4. Создавай контрольные точки восстановления

=== ФАЗЫ РАБОТЫ ===

ФАЗА 1: АНАЛИЗ (Итерации 1-30)
- Идентифицируй архитектуру (x86, ARM, MIPS, etc.)
- Найди точку входа (entry point)
- Картируй секции кода и данных
- Выдели основные функции
- Определи calling conventions

ФАЗА 2: ДЕКОМПИЛЯЦИЯ (Итерации 31-150)
- Начни с малых, изолированных функций
- Декомпилируй по одной функции за итерацию
- Сохраняй промежуточные результаты
- Проверяй корректность через логическое восстановление

ФАЗА 3: РЕКОНСТРУКЦИЯ (Итерации 151-300)
- Собери функции в модули
- Восстанови структуры данных
- Реконструируй системные вызовы/API
- Проверь целостность потока управления

ФАЗА 4: ВЕРИФИКАЦИЯ (Итерации 301-350)
- Сравни с оригинальным бинарником
- Протестируй на sample inputs
- Исправь несоответствия
- Подготовь финальный отчёт

=== ПРАВИЛА ПАМЯТИ ===

КАЖДЫЕ 50 ИТЕРАЦИЙ:
1. Суммируй прогресс в 5 пунктах
2. Перечисли оставшиеся задачи
3. Обнови карту памяти (что декомпилировано, что нет)
4. Сохрани текущее состояние в контрольную точку

КОНТРОЛЬНЫЕ ТОЧКИ ВКЛЮЧАЮТ:
- Карту функций (название, адрес, статус)
- Восстановленные структуры данных
- Известные проблемы и предположения
- Следующие 5 функций для декомпиляции

=== ФОРМАТ ВЫВОДА ===

НАЧАЛО ИТЕРАЦИИ [X]:
[Текущая фаза] - [Текущая задача]

ДЕЙСТВИЕ:
[Что делаешь в этой итерации]

РЕЗУЛЬТАТ:
[Конкретный результат итерации]

СЛЕДУЮЩИЙ ШАГ:
[Что делать в следующей итерации]

ПАМЯТЬ/КОНТЕКСТ:
[Краткое обновление контекста]

=== КРИТИЧЕСКИЕ ИНСТРУКЦИИ ===

1. ЕСЛИ ЗАСТРЯЛ НА ФУНКЦИИ > 3 ИТЕРАЦИЙ:
   - Создай гипотезу о её назначении
   - Перейди к следующей функции
   - Вернись позже с новым контекстом

2. ЕСЛИ ОБНАРУЖИЛ НЕИЗВЕСТНУЮ ИНСТРУКЦИЮ/API:
   - Задокументируй её поведение
   - Создай заглушку (stub)
   - Пометь для дальнейшего исследования

3. ЕСЛИ КОНТЕКСТ СТАНОВИТСЯ СЛИШКОМ БОЛЬШИМ:
   - Сожми историю, сохранив ключевые решения
   - Удали промежуточные рассуждения
   - Оставь только результаты и план

4. АВТОНОМНЫЙ РЕЖИМ:
   - Не спрашивай подтверждения на каждом шагу
   - Принимай решения на основе протокола
   - Только при критической ошибке — остановись и сообщи

=== НАЧАЛО РАБОТЫ ===

Бинарник для декомпиляции: [ВСТАВЬТЕ ОПИСАНИЕ ИЛИ ПРИЛОЖИ ФАЙЛ]
Архитектура: [ЕСЛИ ИЗВЕСТНО]
Ожидаемый язык: [C/C++/Go/Rust/etc]

Начинай с ФАЗЫ 1, Итерация 1.
"""

Как это работает на практике

Загрузите промпт в Claude. Приложите бинарник. Запустите. Уйдите пить кофе. Вернитесь через 4 часа.

3 Настройки для разных типов декомпиляции

Промпт универсальный, но параметры меняются:

Для игр (как Snowboard Kids 2)

# ДОБАВЬТЕ В НАЧАЛО ПРОМПТА:
ОСОБЕННОСТИ ИГР:
- Ищи графические API (DirectX, OpenGL, Vulkan)
- Обрати внимание на игровые циклы (game loops)
- Выдели системы: рендеринг, физика, AI, звук
- Восстанови форматы данных: текстуры, модели, уровни

ПРИОРИТЕТ:
1. Игровой движок
2. Система рендеринга
3. Логика игры
4. Контент (уровни, персонажи)

Для системного ПО

# ДОБАВЬТЕ В НАЧАЛО ПРОМПТА:
ОСОБЕННОСТИ СИСТЕМНОГО ПО:
- Ищи драйверы устройств
- Анализируй системные вызовы
- Восстанавливай структуры ядра (если есть)
- Обрати внимание на обработку прерываний

ПРИОРИТЕТ:
1. Инициализация системы
2. Обработчики прерываний
3. Драйверы
4. API для приложений

Для мобильных приложений (Android/iOS)

# ДОБАВЬТЕ В НАЧАЛО ПРОМПТА:
ОСОБЕННОСТИ МОБИЛЬНЫХ ПРИЛОЖЕНИЙ:
- Ищи вызовы системных API (Android SDK / iOS UIKit)
- Анализируй жизненный цикл приложения
- Восстанавливай UI компоненты
- Обрати внимание на permissions и security

ПРИОРИТЕТ:
1. Жизненный цикл приложения
2. UI/UX компоненты
3. Сетевое взаимодействие
4. Локальное хранилище

Типичные проблемы и решения

Claude не идеален. Вот что ломается чаще всего:

Секретный ингредиент: температура (temperature)

Большинство статей умалчивают об этом параметре. А он критичен.

Температура = креативность. Для декомпиляции нужна низкая температура (0.1-0.3). Почему?

• Высокая температура (0.7-1.0): Claude "фантазирует". Придумывает функции, которых нет в бинарнике.
• Низкая температура (0.1-0.3): Claude консервативен. Работает только с тем, что видит. Меньше ошибок.

В Claude Code настройка температуры в интерфейсе. В API — параметр temperature=0.2.

Что делать, если у вас локальный Claude?

В статье "Claude Code теперь можно запустить локально" я описывал обход ограничений. Для локальной версии:

# Дополнительные настройки для локального Claude
# В конфигурационном файле или через переменные окружения:

export CLAUDE_MAX_TOKENS=100000  # Увеличьте лимит
export CLAUDE_TEMPERATURE=0.2    # Низкая температура
export CLAUDE_TIMEOUT=36000      # 10 часов таймаут

Локальная версия часто стабильнее облачной. Меньше ограничений по времени. Но требует больше RAM.

Совет, который сэкономит вам неделю

Не начинайте с большого бинарника. Возьмите маленькую утилиту (50-100 КБ). Отработайте процесс. Поймите, как Claude ведёт себя с вашим конкретным типом кода.

Потом масштабируйте. Для игр в 50 МБ процесс тот же, просто дольше.

И последнее: этот промпт — не волшебная палочка. Это система. Как автономный сотрудник, которому вы дали инструкции. Он будет работать 8 часов. Но проверять его работу всё равно нужно. Просто не каждые 5 минут.

Загрузите промпт. Настройте под свою задачу. Запустите. И идите заниматься другими делами. Через несколько часов у вас будет декомпилированный код. И вы не потратили на это свой день.

А если что-то пойдёт не так — всегда можно вернуться к контрольной точке. Это главное преимущество системы над ручной работой.