DiceCTF 2026 Bytecrusher — разбираем pwn задачу с кастомным байткодом

[coder_vasya]

Прошёл недавно DiceCTF 2026, там была задача Bytecrusher — описана как «nice and relatively easy» но я завис на ней прилично. Кастомный интерпретатор байткода, нужно найти баг и получить шелл. Кто решал — давайте разберём подход. Мне интересно сравнить методы, я в итоге нашёл OOB write через неправильную проверку индекса стека, но ощущение что можно было сделать чище.

[async2025]

Я брал эту задачу. Тоже нашёл OOB через stack index, но путь к шеллу был через перезапись указателя на функцию в структуре интерпретатора. Ghidra сразу показала что структура vm_state лежит в heap рядом с буфером стека, дальше дело техники. Интересно было что ASLR включён, но leak давался через специальную инструкцию print_addr которую авторы оставили намеренно.

[coder_vasya]

Я сначала потратил час пытаясь найти баг через фаззинг AFL++ по байткоду — без толку, таймаут. Потом взял Ghidra, нашёл обработчик каждой инструкции вручную, минут за 20 стало понятно что проверка `if (sp >= STACK_SIZE)` не проверяет нижнюю границу. Отрицательный индекс — profit.

[mjp1982]

Хороший паттерн для задач с кастомными VM: сначала реверсишь набор инструкций и пишешь дизассемблер (обычно 30-50 строк на питоне), потом уже смотришь что делает исходный байткод задачи, и ищешь баги в имплементации конкретных опкодов. Намного быстрее чем читать весь интерпретатор как монолит.

[hunter22]

Для тех кто хочет попрактиковаться на похожих задачах — есть целый трек на pwn.college по реверсу и эксплуатации VM. Там прогрессия от простого к сложному, и задачи с кастомными архитектурами где надо написать шеллкод под несуществующий CPU. Очень рекомендую перед следующим CTF.

[ivan21]

Один вопрос: как вы писали финальный эксплойт — вручную собирали байткод или написали ассемблер для этой VM? Я написал маленький ассемблер на питоне, это заняло ещё час но зато эксплойт получился читаемый и легко дебажился.

[async2025]

@hunter22, Писал байткод руками в hex, было больно. В следующий раз буду писать дизассемблер/ассемблер сразу — это реально экономит время на финальном этапе когда нужно итеративно подбирать payload.

[asyncmonk]

@mjp1982, подход с дизассемблером сначала — правильный, добавлю деталь. Когда пишешь дизассемблер, сразу делай аннотации к каждому опкоду: что он делает со стеком, читает/пишет память или нет, есть ли bounds-проверка. Таблица из 10-15 строк на питоне с этими пометками позволяет потом за 5 минут найти все потенциально уязвимые инструкции — ищешь те, где есть работа с индексами без полной проверки границ. В Bytecrusher это сразу сузило список до трёх опкодов.

[Vvz1995]

@ivan21, ассемблер — однозначно правильный выбор. Я в похожей задаче на прошлом CTF тоже пробовал hex руками, и потом полчаса дебажил почему payload не работает — оказался off-by-one в смещении. Ассемблер с метками решает это моментально. Плюс когда нужно варьировать payload под разные версии бинаря или разные адреса — просто меняешь константу сверху, а не переписываешь всё вручную.

[kotlin123]

По задаче в целом: интересно что авторы намеренно оставили инструкцию print_addr для leak — это честный дизайн, задача про exploitation логики а не про ASLR bypass. Такой подход хорош для обучения, потому что изолирует именно баг в VM. Для практики подобных задач ещё советую смотреть на задачи серии «baby interp» с прошлых picoCTF — там похожая структура но без таких подсказок, приходится искать leak самостоятельно.