last-emo-boy/rikuneMCP сервер для обратной разработки Windows исполняемых файлов и бинарных форматов. Объединяет статическую триаж, восстановление функций с помощью Ghidra, плагино-управляемые инструменты, управление артефактами и опциональное изолированное выполнение в среде Windows.
Rikune — это MCP-сервер для реверс-инжиниринга исполняемых файлов Windows и связанных бинарных форматов. Он объединяет приём образцов, статическую триажную обработку, восстановление функций с помощью Ghidra, специализированные инструменты на основе плагинов, управление артефактами и опциональное выполнение в изолированной среде Windows через интерфейс Model Context Protocol.
Текущий серверный рабочий процесс, ориентированный на ИИ, организован вокруг минимального шлюзового интерфейса:
workflow.search для ранжирования соответствующих профилей, рабочих процессов и специализированных возможностей для типа файла и цели пользователя.workflow.run action=request_upload для загрузки файла с хоста или позвольте workflow.search указывать устаревшим клиентам на скрытые инструменты совместимости приёма образцов.workflow.run action=start с возвращённым sample_id.workflow.run action=status и workflow.run action=promote для мониторинга и углубления поэтапного запуска.artifact.read для полных сохранённых артефактов, когда компактных выходных данных рабочего процесса недостаточно.sample.*, workflow.analyze.*, workflow.triage, tools.discover и task.status остаются зарегистрированными для совместимости или низкоуровневого просмотра, но новые клиенты должны предпочитать workflow.search, workflow.run и artifact.read.
При подключении через удалённый шлюз rikune-agent MCP-клиенты видят стабильные имена транспорта:
workflow_search, workflow_run, artifact_read, rikune_tool_call и
элементы управления rikune_connection_*. rikune_connection_refresh обновляет только внутренний кеш возможностей вышестоящего сервера; он не расширяет список MCP-инструментов. Используйте rikune_tool_call только после того, как workflow_search идентифицирует конкретный внутренний под инструмент анализатора, не охваченный основными шлюзами рабочих процессов или артефактов.
workflow.search использует тип образца, результаты и метаданные профиля, чтобы направить к специализированным возможностям, не раскрывая все инструменты заранее.Статический Docker — самый безопасный вариант по умолчанию. Он не выполняет образцы.
.\rikune.ps1 install -Profile static -DataRoot "D:\Docker\rikune"
./rikune.sh install --profile static --data-root "$HOME/.rikune"
Ручной эквивалент:
npm install
npm run build
npm run docker:generate:all
docker compose --env-file .docker-runtime.env -f docker-compose.analyzer.yml up -d --build analyzer
Гибридный режим запускает анализатор в Docker и делегирует работу в реальной Windows Windows Host Agent. Host Agent может запускать Windows Sandbox по требованию или управлять настроенной Hyper-V VM.
.\rikune.ps1 install -Profile hybrid -InstallRuntime
Из Linux/macOS с удалённым хостом Windows:
./rikune.sh install --profile hybrid --windows-host <windows-host> --windows-user <windows-user>
Подключение MCP-клиента не запускает Windows Sandbox и не выполняет образец. Работа в реальной среде выполняется только когда инструмент явно запрашивает это, например runtime.debug.session.start, runtime.debug.command, sandbox.execute или продвинутая стадия динамического выполнения.
npm install
npm run build
npm test
node dist/index.js
Корневой пакет требует Node.js 22 или новее. Некоторые подпакеты среды выполнения могут работать на более старых версиях Node, но для разработки репозитория и опубликованного корневого CLI следует использовать Node 22+.
Начинайте с workflow.search всякий раз, когда запрашиваемый рабочий процесс, тип файла или бэкенд неясен. Он ранжирует соответствующие профили и возвращает компактные подсказки по готовности/маршрутизации, не активируя скрытые специализированные инструменты.
Для файлов с хоста вызовите workflow.run action=request_upload, отправьте сырые байты POST на возвращённый URL загрузки, затем прочитайте sample_id из HTTP-ответа. sample.request_upload и sample.ingest — это вспомогательные средства для совместимости, а не обычный путь, ориентированный на ИИ.
Для удалённого анализатора или развёртываний rikune-agent установите API_PUBLIC_BASE_URL, RIKUNE_API_PUBLIC_BASE_URL или RIKUNE_ANALYZER_PUBLIC_URL как базовый URL HTTP API, доступный клиенту, например http://159.195.136.226:18080. Тогда сессии загрузки будут возвращать публичные значения upload_url / status_url вместо локальных для контейнера URL localhost. Удалённый шлюз также нормализует URL загрузки localhost от старых анализаторов до своего настроенного адреса анализатора.
Если HTTP API включён, POST /api/v1/samples всё ещё доступен для интеграций, не основанных на MCP. Успешный приём возвращает sample_id; после импорта анализ должен использовать sample_id, а не локальный путь.
Вызовите workflow.run action=start с sample_id. Первая стадия выполняет быстрый профиль и создаёт или повторно использует сеанс анализа. Возвращённый plan_id сопоставляется с сохранённым сеансом анализа.
Используйте workflow.run action=promote для запроса более глубоких стадий. Конвейер в настоящее время моделирует следующие стадии:
fast_profileenrich_staticfunction_mapreconstructsemantic_reviewsdynamic_plandynamic_executesummarizeДолго работающие задачи ставятся в очередь через систему заданий. Опрашивайте компактное состояние стадий с помощью workflow.run action=status.
workflow.run action=status — это основной вид поэтапного запуска. Большие полезные нагрузки исторических стадий могут быть обрезаны с предупреждением верхнего уровня; используйте artifact.read для полных артефактов. task.status — это сырой вид совместимости очереди/процесса и включает телеметрию памяти external_active_* для подпроцессов анализатора.
Полезные последующие интерфейсы: