Ceasta v0.12.0

Ceasta 0.12.0 — руководство по инструменту и MCP

Документ составлен по ответу tools/list, полученному от локального MCP-сервера Ceasta 0.12.0, и описанию проекта ngwg/ceasta.

MCP-инструменты ниже — это не обязательно команды интерфейса Ceasta. Это имена инструментов, которые MCP-клиент или AI вызывает через JSON-RPC tools/call.

1. Что такое Ceasta

Ceasta — инструмент обратной разработки (reverse engineering), объединяющий:

Дизассемблер — показывает машинные инструкции процессора.
Декомпилятор — восстанавливает приближённый C-подобный псевдокод.
Граф функций — показывает базовые блоки и переходы между ними.
Отладчик — позволяет запускать программу, ставить точки останова, выполнять инструкции пошагово и исследовать память.
Анализ бинарных файлов — находит функции, строки, импорты, экспорты, ссылки и секции.
Сравнение бинарников — помогает определить, какие функции изменились между двумя версиями.
Lua-плагины — расширяют интерфейс собственными командами.
MCP-сервер — предоставляет AI-клиенту доступ к анализируемому файлу и инструментам Ceasta.

Ceasta предназначена для анализа исполняемых файлов и библиотек, например EXE, DLL и SYS, а также ELF и Mach-O. Поддерживаемые архитектуры зависят от формата и сборки; проект заявляет x86, x64 и ARM64.

Ceasta не является магическим восстановителем исходного кода. Декомпиляция — приближённая реконструкция, а результаты статического анализа могут быть неполными, особенно для упакованных и обфусцированных программ.

Репозиторий: https://github.com/ngwg/ceasta
Каталог плагинов: https://github.com/ngwg/ceasta/tree/main/plugins
Версия локального MCP-сервера в полученном ответе: 0.12.0

2. Как работает MCP

MCP (Model Context Protocol) — протокол, через который клиент, например AI-ассистент, получает список доступных инструментов и вызывает их.

Локальный адрес в текущей конфигурации:

http://127.0.0.1:8744/mcp

Получить список инструментов

Запрос tools/list возвращает имена инструментов, описания и JSON-схемы их аргументов.

{
  "jsonrpc": "2.0",
  "id": 2,
  "method": "tools/list",
  "params": {}
}

Вызвать инструмент

Пример вызова get_binary_info:

{
  "jsonrpc": "2.0",
  "id": 3,
  "method": "tools/call",
  "params": {
    "name": "get_binary_info",
    "arguments": {}
  }
}

Пример для Windows CMD

curl -i -X POST http://127.0.0.1:8744/mcp -H "Content-Type: application/json" -H "Accept: application/json, text/event-stream" -d "{\"jsonrpc\":\"2.0\",\"id\":2,\"method\":\"tools/list\",\"params\":{}}"

Для вызова конкретного инструмента замените method на tools/call, а params задайте как в примере выше. Если сервер в будущем начнёт требовать сессию, используйте Mcp-Session-Id, возвращённый при инициализации.

3. Рекомендованный порядок анализа

get_binary_info — узнать формат, архитектуру, entry point, секции, импорты, ресурсы, хеши и признаки упаковки.
list_strings и list_imports — найти интересные строки и API.
list_functions — получить список функций; использовать фильтр для известных имён.
get_xrefs_to — узнать, кто обращается к интересующему адресу, функции или строке.
get_xrefs_from — посмотреть, какие функции и данные использует выбранная функция.
decompile_function — прочитать псевдокод.
disassemble_function — сверить псевдокод с реальными инструкциями.
get_basic_blocks — исследовать ветвления и структуру потока управления.
Если статического анализа недостаточно — безопасно подготовить отладку, поставить breakpoint и исследовать выполнение.
save_project — сохранить имена, комментарии, прототипы и другие поддерживаемые данные проекта.

4. Полный справочник MCP-инструментов

В списке, который пользователь получил от Ceasta 0.12.0, присутствуют следующие инструменты.

4.1. Информация и статический анализ

`get_binary_info`

Аргументы: нет.

Возвращает обзор загруженного файла: формат, архитектуру, точку входа, базовый адрес, сегменты и их энтропию, импортированные библиотеки, флаги безопасности, MD5/SHA-256/imphash, версию, ресурсы, предупреждения (например, признаки упаковки или overlay), количество найденных функций, импортов, экспортов и строк.

Когда использовать: первым запросом при начале анализа.

`list_functions`

Аргументы:

filter — необязательная строка; оставить имена, содержащие подстроку без учёта регистра.
offset — сколько результатов пропустить.
limit — максимум результатов; по умолчанию 200.

Возвращает найденные функции: адрес, размер и имя, отсортированные по адресу. Безымянные функции могут называться вроде sub_401000.

Когда использовать: навигация по функциям, поиск уже известных имён, просмотр результатов порциями.

`decompile_function`

Обязательный аргумент: function — имя, адрес или адрес внутри функции.

Возвращает C-подобный псевдокод функции. Имена локальных переменных и аргументов могут быть условными; регистры и соглашение о вызовах зависят от архитектуры. Для API, которые известны декомпилятору, могут показываться распознанные аргументы.

Когда использовать: быстро понять логику функции. Если псевдокод выглядит странно, проверить дизассемблер.

`decompile_with_kuna`

Обязательный аргумент: function — имя или адрес функции.

Декомпилирует ту же функцию альтернативным декомпилятором Kuna. Может быть полезен как второе мнение для оптимизированного кода и поддерживает ARM64. Имена и типы, назначенные в Ceasta, могут не отображаться в выводе Kuna.

Когда использовать: сравнить два варианта декомпиляции. Для работы требуется корректно установленный Kuna и его SPEC-файлы.

`disassemble`

Обязательный аргумент: address — адрес или имя.

count — число строк, по умолчанию 60, максимум 800.

Показывает инструкции, метки, имена вместо адресов, данные и комментарии начиная с указанного места.

Когда использовать: изучить участок кода без вывода всей функции.

`disassemble_function`

Обязательный аргумент: function — имя или адрес.

Показывает полный дизассемблер функции.

Когда использовать: проверить псевдокод, условия переходов, вызовы и инструкции, которые декомпилятор восстановил неверно.

`get_xrefs_to`

Обязательный аргумент: address — адрес или имя.

limit — максимальное количество ссылок, по умолчанию 300.

Показывает, откуда обращаются к адресу: вызовы, переходы, чтение/запись данных и указатели. Для каждого обращения указывается функция-источник.

Когда использовать: найти вызывающие функции или код, который использует строку/глобальную переменную.

`get_xrefs_from`

Обязательный аргумент: address — адрес или имя.

whole_function — если true, собрать ссылки для всей функции, а не только указанной инструкции.

Показывает, на какие функции, строки и глобальные данные ссылается инструкция или функция.

Когда использовать: построить карту зависимостей функции.

`list_strings`

Аргументы:

filter — необязательная подстрока, поиск без учёта регистра.
offset — смещение в списке результатов.
limit — максимум результатов, по умолчанию 200.

Показывает найденные ASCII- и UTF-16-строки с адресами.

Когда использовать: искать URL, сообщения об ошибках, имена файлов, пути, названия функций и другие текстовые признаки. Для найденной строки используйте get_xrefs_to, чтобы увидеть места использования.

`list_imports`

Аргумент: filter — необязательная подстрока имени.

Показывает импортированные функции, библиотеки и адреса импортных слотов.

Когда использовать: искать обращения к файловой системе, сети, криптографическим библиотекам, загрузке DLL и другим API.

`list_exports`

Аргумент: filter — необязательная подстрока.

Показывает экспортируемые символы и адреса.

Когда использовать: анализировать публичные точки входа DLL или экспортируемые функции.

`read_bytes`

Обязательный аргумент: address — адрес или имя.

length — длина чтения в байтах, по умолчанию 128, максимум 4096.

Читает байты загруженного файла и показывает hex/ASCII-представление.

Когда использовать: проверить заголовки, константы, структуры или данные рядом с адресом.

`search_bytes`

Обязательный аргумент: pattern — байты в шестнадцатеричном виде, разделённые пробелами; ?? означает любой байт.

Пример шаблона: 48 8b ?? 05.

Ищет совпадения байтов в бинарнике.

Когда использовать: искать известные сигнатуры инструкций, магические значения и таблицы. Учитывайте, что совпадение само по себе не доказывает назначение данных.

`lookup`

Обязательный аргумент: what — адрес или имя.

Показывает, что находится по адресу или какому адресу соответствует имя: адрес, имя, содержащая функция, сегмент, а также признак импорта, экспорта или строки.

Когда использовать: быстро разобраться, что представляет собой адрес.

`diff_binary`

Обязательный аргумент: path — путь к другому бинарному файлу.

limit — максимум записей в каждой секции отчёта, по умолчанию 60.

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

Когда использовать: сравнивать версии программы после обновления или патча.

`get_basic_blocks`

Обязательный аргумент: function — имя или адрес.

Возвращает базовые блоки функции и рёбра графа потока управления.

Когда использовать: разбирать условия, циклы, switch-подобные конструкции и сложный поток управления. Это не гарантированное распознавание VM-диспетчера.

4.2. Изменение заметок и имён в проекте

`rename`

Аргументы:

address — адрес или текущее имя.
name — новое имя; пустая строка снимает пользовательское имя.

Назначает имя функции или глобальному объекту. Имя отображается в листинге, псевдокоде и xref и сохраняется в проекте.

Рекомендация: использовать осмысленные имена вроде parse_config, decrypt_string, validate_certificate только при наличии доказательств.

`set_comment`

Аргументы:

address — адрес или имя.
comment — текст комментария; пустая строка удаляет комментарий.

Добавляет комментарий к адресу. Комментарий отображается в листинге и сохраняется в проекте.

`rename_variable`

Аргументы:

function — функция, имя или адрес.
variable — имя переменной так, как оно показано в псевдокоде.
name — новое имя; пустая строка возвращает автоматическое имя.

Переименовывает параметр, локальную переменную или переменную-регистр в псевдокоде функции.

`set_variable_type`

Аргументы:

function — функция.
variable — имя переменной из псевдокода.
type — тип C, например int, char*, DWORD, struct header*, char[16].

Задаёт тип переменной, чтобы сделать псевдокод понятнее. Пустой тип сбрасывает пользовательское назначение.

`set_function_prototype`

Аргументы:

function — имя или адрес функции.
prototype — прототип в стиле C, например int check_key(const char* key, int len).

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

`suggest_name`

Аргументы:

address — адрес или имя.
name — предлагаемое имя.
reason — краткое обоснование.

Не переименовывает объект немедленно, а добавляет предложение для проверки в интерфейсе Ceasta: AI → Review suggested names.

Когда использовать: массовое именование при неполной уверенности.

`suggest_variable_name`

Аргументы:

function — функция.
variable — имя переменной из псевдокода.
name — предлагаемое имя.
reason — краткое обоснование.

Предлагает новое имя переменной для проверки пользователем, не применяя его сразу.

`save_project`

Аргументы: нет.

Сохраняет имена, комментарии и поддерживаемые данные проекта. В зависимости от способа открытия это может быть база проекта или файл <имя-бинарника>.ceasta рядом с бинарником.

Рекомендация: сохранять результаты после значимого этапа анализа.

4.3. Выполнение Lua

`run_lua`

Обязательный аргумент: code — исходный текст Lua.

Выполняет Lua-скрипт с API Ceasta. В описании инструмента указаны, например, ceasta.functions(), ceasta.decompile(addr), ceasta.xrefs_to(addr), ceasta.read(addr, n), ceasta.rename(addr, name) и ceasta.log(...). Также доступны стандартные Lua-библиотеки io и os, поэтому скрипт может читать и записывать файлы в пределах разрешений текущего пользователя.

Внимание: запускайте только понятные скрипты из доверенных источников. Lua-скрипт может иметь побочные эффекты, особенно при использовании io и os.

Пример простого скрипта:

ceasta.log("Functions: " .. #ceasta.functions())

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

4.4. Отладчик

Отладочные инструменты запускают программу или изменяют состояние её процесса. Не запускайте неизвестный бинарник на основной системе без изоляции.

`debug_start`

Аргумент: args — необязательная строка аргументов командной строки.

Запускает загруженный файл под отладчиком и останавливает выполнение у точки входа. Одновременно отлаживается один процесс.

`debug_status`

Аргументы: нет.

Показывает, выполняется ли отладка и где/почему процесс остановился.

`debug_continue`

Аргумент: timeout_ms — время ожидания в миллисекундах, по умолчанию 15000, максимум 120000.

Продолжает выполнение до breakpoint, ошибки, завершения программы или тайм-аута.

`debug_step_into`

Аргумент: count — число инструкций, по умолчанию 1, максимум 200.

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

`debug_step_over`

Аргумент: count — число инструкций, по умолчанию 1, максимум 200.

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

`debug_step_out`

Аргумент: timeout_ms — время ожидания, по умолчанию 15000.

Выполняет код до возврата из текущей функции и останавливается в вызывающей функции.

`debug_step_back`

Аргумент: count — число шагов назад.

Откатывает изменения регистров и памяти, зарегистрированные поддерживаемыми пошаговыми операциями. Это не полноценная перемотка произвольного выполнения: продолжение процесса и некоторые вызовы начинают новую историю шагов.

`debug_run_to`

Обязательный аргумент: address — адрес или имя.

timeout_ms — время ожидания, по умолчанию 15000.

Выполняет программу до указанного адреса, точки останова или тайм-аута.

`debug_pause`

Аргументы: нет.

Приостанавливает выполняющийся процесс.

`debug_kill`

Аргументы: нет.

Завершает процесс, запущенный под отладчиком.

`debug_set_breakpoint`

Обязательный аргумент: address — адрес или имя.

condition — необязательное условие на Lua, которое должно быть истинным для остановки.

Ставит точку останова. Условие может использовать регистры, счётчик попаданий hits и функции чтения памяти u8, u16, u32, u64, str, wstr.

Пример условия, если регистр и адрес соответствуют нужному контексту: hits == 100.

`debug_remove_breakpoint`

Обязательный аргумент: address — адрес или имя.

Удаляет точку останова по указанному адресу.

`debug_list_breakpoints`

Аргументы: нет.

Показывает точки останова по статическим адресам и watchpoints по адресам выполнения.

`debug_watch`

Обязательный аргумент: address — имя регистра, имя/адрес файла или runtime-адрес.

size — размер в байтах: 1, 2, 4 или 8; по умолчанию 4.
access — если true, остановка также при чтении; по умолчанию отслеживаются записи.
remove — если true, удалить watchpoint по этому адресу.

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

Когда использовать: выяснить, кто изменяет флаг, буфер, указатель или результат декодирования.

`debug_backtrace`

Аргумент: limit — максимальное число кадров стека, по умолчанию 32.

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

`debug_memory_map`

Аргумент: filter — необязательная подстрока для фильтрации регионов памяти.

Показывает области памяти процесса, права доступа (r/w/x), модули, heap и stack.

`debug_get_registers`

Аргументы: нет.

Показывает регистры остановленного потока и, где возможно, интерпретацию адресов, на которые они указывают.

`debug_set_register`

Аргументы:

name — имя регистра.
value — новое значение в шестнадцатеричном виде.

Изменяет регистр остановленного потока. Может изменить ход выполнения программы.

`debug_read_memory`

Обязательный аргумент: address — регистр, имя/адрес файла или runtime-адрес.

length — количество байтов, по умолчанию 128, максимум 4096.

Читает память работающего процесса и выводит hex/ASCII-представление.

`debug_write_memory`

Аргументы:

address — регистр, имя/адрес файла или runtime-адрес.
bytes — байты в hex, например 90 90 c3.

Записывает байты в память процесса. Это изменяет состояние программы и может привести к её падению или изменению поведения.

`debug_call`

Аргументы:

function — имя или адрес функции.
args — массив аргументов; элементы могут быть числами или строками согласно правилам инструмента.

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

Внимание: вызывать неизвестные функции рискованно. Перед вызовом изучите прототип, соглашение о вызовах и побочные эффекты.

`debug_trace`

Аргумент: count — количество инструкций для пошагового выполнения, по умолчанию 2000, максимум 200000.

Выполняет инструкции пошагово и записывает цели косвенных вызовов/переходов (например, вызовы через указатели, vtable или jump table). Эти цели добавляются как xref и сохраняются с проектом. Трассировка медленная; ставьте breakpoint в интересном месте и начинайте с небольшого числа инструкций.

`debug_decompile_here`

Аргументы: нет.

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

Когда использовать: понять, что функция делает с данными именно в текущем запуске.

5. Быстрые сценарии использования

Сценарий A: первичная разведка бинарника

get_binary_info
list_imports
list_strings
list_functions
save_project после разметки

Сценарий B: исследование строки

list_strings с фильтром, например certificate, https, error.
get_xrefs_to для адреса найденной строки.
decompile_function для функции, которая использует строку.
get_xrefs_from для анализа зависимостей.
set_comment и suggest_name для документирования выводов.

Сценарий C: исследование функции

lookup для проверки адреса.
decompile_function.
disassemble_function.
get_xrefs_to и get_xrefs_from.
get_basic_blocks.
rename, set_comment, set_function_prototype, затем save_project.

Сценарий D: сравнение двух версий

Открыть базовый файл в Ceasta.
Вызвать diff_binary с путём к новой версии.
Проверить изменившиеся функции через decompile_function и disassemble_function.
Сохранить выводы в комментариях.

Сценарий E: динамический анализ

Убедиться, что бинарник доверенный или запущен в изолированной среде.
debug_start.
Поставить debug_set_breakpoint.
debug_continue до остановки.
Изучить debug_get_registers, debug_read_memory, debug_backtrace.
При необходимости debug_step_into, debug_step_over, debug_step_out или debug_trace.
Не применять debug_write_memory, debug_set_register и debug_call, пока не понятно, к чему приведут изменения.

6. Lua-плагины Ceasta

Lua-плагины — скрипты .lua, которые добавляют команды в меню плагинов. В README указаны два возможных каталога для пользовательских плагинов:

рядом с программой: plugins/
каталог пользователя Windows: %APPDATA%\ceasta\plugins
Linux: ~/.config/ceasta/plugins
macOS: ~/Library/Application Support/ceasta/plugins

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

Пример из документации проекта:

ceasta.register_command("Count calls", function()
    local n = 0
    for _, fn in ipairs(ceasta.functions()) do
        n = n + #ceasta.xrefs_to(fn.addr)
    end
    ceasta.log(n .. " references to functions")
end)

API Lua нужно сверять с документацией именно установленной версии. Не следует считать, что любой метод, встречающийся в примере из интернета, существует в текущей сборке.

7. Важные ограничения и безопасность

Декомпилятор показывает реконструкцию, а не исходный код. Сверяйте вывод с дизассемблером.
Для упакованных/обфусцированных программ статический анализ может быть неполным.
search_bytes ищет совпадение байтов, но не объясняет его назначение.
Большое количество переходов не доказывает наличие виртуальной машины или обфускации.
Наличие строки сертификата не означает, что она используется для TLS или проверки подписи.
Изменение файла, сертификата или подписанных данных может нарушить цифровую подпись и работу приложения. Перед модификациями делайте копию и проверяйте право на изменение файла.
debug_start запускает анализируемую программу на машине пользователя. Не запускайте недоверенные файлы без изоляции.
debug_write_memory, debug_set_register, debug_call и debug_kill — инструменты с побочными эффектами.
run_lua может выполнять файловые операции через io/os; запускайте только проверенный код.
Не публикуйте локальный MCP endpoint в интернет без аутентификации и сетевых ограничений: он может давать доступ к анализу и изменению состояния процесса.

8. Ссылки

Проект Ceasta: https://github.com/ngwg/ceasta
README и обзор возможностей: https://github.com/ngwg/ceasta
Lua-плагины: https://github.com/ngwg/ceasta/tree/main/plugins
Версия Ceasta в текущем сеансе MCP: 0.12.0

Описание

Ceasta 0.12.0 — руководство по инструменту и MCP

1. Что такое Ceasta

2. Как работает MCP

Получить список инструментов

Вызвать инструмент

Пример для Windows CMD

3. Рекомендованный порядок анализа

4. Полный справочник MCP-инструментов

4.1. Информация и статический анализ

get_binary_info

list_functions

decompile_function

decompile_with_kuna

disassemble

disassemble_function

get_xrefs_to

get_xrefs_from

list_strings

list_imports

list_exports

read_bytes

search_bytes

lookup

diff_binary

get_basic_blocks

4.2. Изменение заметок и имён в проекте

rename

set_comment

rename_variable

set_variable_type

set_function_prototype

suggest_name

suggest_variable_name

save_project

4.3. Выполнение Lua

run_lua

4.4. Отладчик

debug_start

debug_status

debug_continue

debug_step_into

debug_step_over

debug_step_out

debug_step_back

debug_run_to

debug_pause

debug_kill

debug_set_breakpoint

debug_remove_breakpoint

debug_list_breakpoints

debug_watch

debug_backtrace

debug_memory_map

debug_get_registers

debug_set_register

debug_read_memory

debug_write_memory

debug_call

debug_trace

debug_decompile_here

5. Быстрые сценарии использования

Сценарий A: первичная разведка бинарника

Сценарий B: исследование строки

Сценарий C: исследование функции

Сценарий D: сравнение двух версий

Сценарий E: динамический анализ

6. Lua-плагины Ceasta

7. Важные ограничения и безопасность

8. Ссылки

Похожие материалы

`get_binary_info`

`list_functions`

`decompile_function`

`decompile_with_kuna`

`disassemble`

`disassemble_function`

`get_xrefs_to`

`get_xrefs_from`

`list_strings`

`list_imports`

`list_exports`

`read_bytes`

`search_bytes`

`lookup`

`diff_binary`

`get_basic_blocks`

`rename`

`set_comment`

`rename_variable`

`set_variable_type`

`set_function_prototype`

`suggest_name`

`suggest_variable_name`

`save_project`

`run_lua`

`debug_start`

`debug_status`

`debug_continue`

`debug_step_into`

`debug_step_over`

`debug_step_out`

`debug_step_back`

`debug_run_to`

`debug_pause`

`debug_kill`

`debug_set_breakpoint`

`debug_remove_breakpoint`

`debug_list_breakpoints`

`debug_watch`

`debug_backtrace`

`debug_memory_map`

`debug_get_registers`

`debug_set_register`

`debug_read_memory`

`debug_write_memory`

`debug_call`

`debug_trace`

`debug_decompile_here`