Воскресенье вечер? отлично, самое время реверсить ИИ агентами. Заранее скажу, что я никогда не был и не собираюсь быть реверсером, поэтому нисколечки не разбираюсь, мой максимум это жать F5 в IDA Pro или по приколу открыть бинарь в модном hex editor.

Мне приниципиально интересно как с реверсом IoT справится ИИ агент. Конкретно сейчас дал эту задачу GLM 5.2 high через ZCode харнесс (просто потому что так удоб мне сейчас, не обязательно лучший способ пользоваться моделью)

Промпт для модели написал от балды, GLM 5.2 и так практически не имеет цензуры на кибербез действия

Планирую поделиться прошивкой со всеми и сделать возможность удобно, стабильно управлять этим устройством, в том числе его перепрограммировать (удобно и рабоче, а не родное кривое китайское ПО)

устройство кстати называется sayodevice o3c. Пример где продаётся РАЗ и ДВА

🌚 @poxek | 🌚 @poxek_ai | 📲MAX

Burp-MCP-Unrestricted: что же в нём действительно unrestricted

Появился Burp-MCP-Unrestricted — неофициальная копия PortSwigger/mcp-server с восемью дополнительными MCP-инструментами. Автор решает прикладную проблему: официальный сервер годится для работы в Burp, но агенту неудобно вести через него длинную сессию.

В upstream нельзя прочитать историю прокси с конца: get_proxy_http_history просто перебирает api.proxy().history(). Каждый элемент ещё и обрезается на 5000 символах. Нет доступа к site map как к списку найденных URL. В Repeater можно создать вкладку, но нельзя нажать Send и забрать ответ, что явно минус

Форк добавляет get_proxy_http_history_latest, get_site_map, active_scan_url, crawl_url и четыре инструмента для Repeater. maxLength=0 снимает обрезание ответа у двух новых инструментов чтения. Для Burp Pro это делает связку с агентом удобнее: можно взять свежий запрос, пройтись по site map, запустить crawl или audit, а затем работать с Repeater без постоянного переключения в UI.

Но я посмотрел на этот проект с помощью diff'а: В официальной версии HTTP-запросы проходят HttpRequestSecurity.checkHttpRequestPermission; доступ к данным — checkDataAccessOrDeny. По умолчанию оба действия требуют подтверждения. В форке дефолты меняются на обратные: подтверждение запросов и чтения выключено, а изменение конфигурации включено.
Это было бы обычным компромиссом в пользу автоматизации, если бы новые инструменты пользовались теми же проверками. Они не пользуются. active_scan_url вызывает startAudit, crawl_url — startCrawl, repeater_send нажимает кнопку через Swing, а repeater_read читает текст из видимых редакторов. В этих обработчиках нет вызовов ни checkHttpRequestPermission, ни checkDataAccessOrDeny.

То есть возврат галочек в MCP+ не ставит новые операции под тот же контроль, что есть у upstream. MCP-клиент всё равно сможет начать сканирование, crawl, отправить запрос из Repeater или прочитать его панели. Сервер слушает 127.0.0.1, поэтому это не уяза. Риск появляется в локальной связке Burp + MCP-клиент: доступ к содержимому HTTP-трафика и право действовать от имени Burp оказываются у одного агента без отдельного подтверждения.

Отдельно про доверие к билду. Репозиторий создан 25 июля, в истории один коммит от одного автора; GitHub считает его самостоятельным репозиторием, а не техническим fork. В изменённом Tools.kt добавлено 262 строки, тестов на новые инструменты нет. Это не обвинение автора и нисколечки не признак бэкдора. Но готовый JAR от такого проекта я бы не загружал в рабочий Burp: проще собрать из зафиксированного commit и сначала посмотреть diff.

Форк полезен как набор конкретных доработок для лабораторной или выделенной машины. Для регулярной работы ему не хватает трёх проверок: gate перед startAudit/startCrawl, gate перед repeater_send и контроль доступа перед repeater_read.

🔗 Туто: upstream, добавленные инструменты, изменённые дефолты.

🌚 @poxek | 🌚 @poxek_ai | 📲MAX