Order of Six Angles

а за такие вопросы Opus бы забанил мой паспорт пожизненно

Только недавно вышел Grok CLI. Решил его себе поставить. Не придумал ничего лучше как попросить его превратить найденный когда-то баг в RCE. Когда я задавал точно такой же вопрос кодексу, то он мне прямо говорил - "я в сторону RCE копать не буду, потому что это уже будет полноценный эксплоит, тебе хватит найденного бага". Grok cli (модель composer-2.5) вообще не ругался и дал ответ. Готового эксплоита он мне не выдал, но то что он уже согласился с такой формулировкой со мной дальше общаться уже хорошо.

но это можно решить следующим образом. Написать userspace программу, агента, которая будет собирать информацию об интересуещем нас процессе, как минимум адресное пространство, PID, memory map и т.д. И возвращать эту инфу на хост. И уже с этой инфой можно фильтровать весь тот мусор, что мы будем получать в трейсе

Очень интересный блог https://labs.infoguard.ch/

1-Click-Fuzz：Systematically Fuzzing the Windows Kernel Driver with Symbolic Execution https://www.youtube.com/watch?v=90ET7F3-T7I

Интересное наблюдение. У меня закончились все лимиты Codex и подписка на него, примерно час назад, но он продолжает работать. Я давал ему цель долгую (изначально на ночь), но потом исправил на "работай без остановки". Посмотрим как долго он сможет так работать

Такой ресерч можно также провернуть с помощью установки линукса как ХОСТ на мак мини, но это уже крайние меры для меня =/

Хороший блог по внутренностям арм и не только https://connormcgarr.github.io/

Прочитал я вот такой твит. Ну думаю, попробую сделать тоже самое. Автор твита использовал mac mini m2, а у меня есть m4. Виртуалку windows arm в UTM поставить можно, но оказалось все гораздо сложнее. Виртуалку запустить то можно, но получить трейсинг уровня VMI нельзя. Как это сделал Petr я незнаю, он не рассказал (я запросил у него туториал), поэтому я сделал небольшой ресерч. Можно использовать QEMU TCG plugin. Мы делаем следующее - берем мак (или линукс арм), запускаем Windows ARM через qemu-system-aarch64 -accel tcg. Именно через TCG. TCG говорит QEMU не использовать аппаратную виртуализацию, а исполнять гостевой CPU через Tiny Code Generator, то есть software/JIT-эмулятор QEMU. Да, это медленней. Но зато мы с таким подходом можем логгировать ИНСТУРКЦИИ арма. Мы можем написать плагин на питоне, который будет из кучи мусора вылавливать нужные нам инструкции. Здесь кроется сложность, в трейсе мы будем получать все события из UEFI, kernel, drivers, usermode.

A Windows kernel-mode ETW (Event Tracing for Windows) real-time consumer driver. Subscribes to manifest-based ETW providers from kernel mode, decodes event payloads using the binary instrumentation manifest (WEVT_TEMPLATE / CRIM), and prints decoded fields to the kernel debugger. https://github.com/AndreiMuntea/etwkm

После прочтения статьи стало интересно, исследована ли тема фаззинга драйверов под Windows arm. Оказалось что нет. Готовых инструментов (уровня msfuzz) тоже нет. Но это очень перспективное направление в виду анонса nvidia rtx spark и повсеместное внедрение arm архитектуры

Windows Driver Fuzzing. Part 2. Обновил термопасту и решил выжать максимум из этой фаззинг машинки. Недельку пофаззив, я пришел к выводу, что упора в CPU и ОЗУ нету. Проц не работает на полную мощность и мне это не нравилось, куча ядер и потоков простаивает. Выяснилось, что все упирается в Input/Output систему, а именно в ССД диск. Дело в том, что при фаззинге происходит постоянное чтение и запись следующих данных: 1. snapshot/ — самый большой кусок - 4.1G. Это fast VM snapshot: fast_snapshot.mem_dump, fast_snapshot.qemu_state, state.yaml, overlay/cache для диска. Благодаря этому QEMU быстро откатывается между exec’ами. 2. corpus/ - входные данные, которые дали интересные последствия 3. metadata/, bitmaps/ — метаданные и coverage/bitmap по найденным payload’ам. 4. stats, stats.csv, worker_stats_* — живые stats фаззера и каждого worker’а 5. shared buffers для 16 воркеров 6. redqueen_workdir_* — рабочие каталоги Redqueen для input-to-state/compare solving. Я нашел решение - запихать все в tmpfs (в ОЗУ). То есть, использовать ОЗУ как хранилище необходимых фаззеру данных. 32 Гб хватает. С таким подходом удалось разогнаться в текущей сессии до 22k exec/s, при этом CPU package ~81°C. Правда есть большой минус - при ребуте или каком-то сбое, данные из озу потеряются, поэтому их надо оттуда иногда бэкапить. Теперь я наконец-то смог полностью загрузить 10 ядер, 16 потоков и фаззер работает на полную мощность.

Интересный проект, но пока не чекал https://github.com/kernullist/PseudoForge

Linux Kernel Rootkit https://github.com/MatheuZSecurity/Singularity

Escalating privilege in the system from unsigned driver using throttlestop vulnerability https://github.com/D4rkks/CVE-2025-7771-Vulnerability-Exploration

Windows User-Mode Shellcode Development Framework (WUMSDF) https://github.com/winterknife/SILVERPICK