MadnessBrains0

Если честно — меня об этом никто не просил. Ни один заказчик, ни один работодатель, ни строчка в чьих-то задачах. Я создал это просто потому, что устал каждый раз с нуля пересобирать один и тот же путь: открыть OWASP, вспомнить, что рядом есть ещё ASVS и WSTG, найти, где это пересекается с NIST SSDF, вспомнить нужный CVE, найти подходящий инструмент — и так по новой для каждого класса уязвимости. В какой-то момент оказалось проще один раз сесть и связать всё это между собой, чем ещё раз объяснять самому себе, зачем я опять открыл двадцать вкладок.

Из этого раздражения и родился ROOT — локальная система, которая связывает методологии ИБ, практику и CVE в одном месте, и которую я в первую очередь собирал как рабочее место для самого себя.

Внутри я свёл в один интерфейс теорию, браузерные CTF, мини-лаборатории по API, каталог CVE, инструменты, payload'ы, цепочки проверок, конструкторы команд, методологии, чек-листы и шаблоны отчётов. Получился не ещё один список ссылок, а попытка склеить обучение, практику и разбор патчей в один сквозной процесс.

ИЗОБРАЖЕНИЕ: Главный экран ROOT

https://habrastorage.org/webt/b9/2b/52/b92b52bee026c76115cf4...

ЗАЧЕМ ЕЩЁ ОДИН ПОЛИГОН, ИХ ЖЕ И ТАК ПОЛНО

Соревноваться в количестве и глубине лабораторий я даже не пытался — это гонка, которую я бы проиграл. Мне не хватало другого: места, где после лаборатории не нужно открывать ещё пять вкладок, чтобы найти методику проверки, подходящий инструмент, связанный CVE и нормальный шаблон отчёта.

ROOT решает чуть другую задачу — быть единым автономным рабочим столом, где после лаборатории можно сразу, не выходя из окна:

— понять класс уязвимости;

— посмотреть связь с CWE и реальными CVE;

— пройти симуляцию эксплуатации;

— сравнить уязвимый и исправленный код;

— решить CTF-задание;

— проверить себя вопросами;

— подобрать инструменты и команды;

— оформить результат в виде отчёта.

Единица обучения тут — не отдельный payload и не абстрактное определение из учебника, а полный цикл:

«понять → проверить → доказать → исправить → перепроверить → описать»

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

ЧТО ВНУТРИ

На момент подготовки статьи рабочая версия включает:

Web CTF — 30 браузерных заданий

API Security — 10 мини-лабораторий

Вопросы — 500 вопросов с разбором

Методологии — около 50 материалов в 11 доменах

Справочник инструментов — около 420 карточек

CISA KEV — локальная подборка, зависящая от версии снимка

CVE — локальный SQLite-каталог и расширенный импортируемый архив

Библиотека полезных нагрузок — более 1 200 примеров

Цепочки атак — более 100 сценариев

Конструкторы команд — десятки модулей

Честно предупреждаю: проект растёт быстрее, чем я успеваю обновлять README, так что счётчики в интерфейсе иногда обгоняют документацию. Ниже отдельно расскажу, почему метрики правильнее генерировать автоматически при сборке, а не вписывать руками.

Центр всего этого — единое рабочее пространство OWASP. Вместо кучи отдельных вкладок с Top 10, API Security, ASVS, WSTG и SAMM пользователь получает одну связанную карту: от общего риска и требований — до проверки, практики и патча.

ИЗОБРАЖЕНИЕ: Рабочее пространство OWASP: Web Top 10, API Security Top 10, ASVS, WSTG, SAMM, MASVS и направления безопасности LLM.

https://habrastorage.org/webt/e7/7d/a5/e77da5ca516297a043f95...

ПРАКТИКА ПО OWASP TOP 10 — БЕЗ ФОРМАТА «ПРОЧИТАЛ И НАЖАЛ ДАЛЕЕ»

Основной веб-трек построен вокруг категорий OWASP Top 10. Для каждой я специально уходил от формата «прочитай определение → нажми "Далее"» — от него в голове ничего не остаётся.

Вместо этого одна и та же проблема разбирается сразу с нескольких сторон:

— что именно нарушено;

— где проходит граница доверия;

— какие данные контролирует пользователь;

— как выглядит уязвимый фрагмент кода;

— каким должен быть реальный патч;

— как проверить, что патч не обходится соседним запросом.

CTF-часть — это 30 браузерных заданий с трёхуровневыми подсказками, флагами и общей системой очков. Прогресс, найденные флаги, результаты тестов и заметки сохраняются в браузере; после прохождения веб-заданий выдаётся сертификат завершения.

Например, в лаборатории по SSRF мало прочитать определение — этого никогда не бывает достаточно. Пользователь выбирает сценарий, работает с локальным эмулятором, пытается достать флаг и по необходимости открывает подсказки поэтапно, а не всей простынёй сразу. Рядом всегда под рукой теория, разбор патча и проверочные задания.

ИЗОБРАЖЕНИЕ: Практическая лаборатория по SSRF: локальный эмулятор, несколько сценариев проверки, система подсказок и флаг.

https://habrastorage.org/webt/8b/bf/be/8bbfbef623938df6d903e...

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

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

МИНИ-ЛАБОРАТОРИИ ПО API — ПОТОМУ ЧТО BOLA ЭТО НЕ «ПОМЕНЯЛ ID И УВИДЕЛ ЧУЖИЕ ДАННЫЕ»

Отдельный трек посвящён OWASP API Security Top 10:2023: https://owasp.org/API-Security/editions/2023/en/0x11-t10/:

1) Broken Object Level Authorization;

2) Broken Authentication;

3) Broken Object Property Level Authorization;

4) Unrestricted Resource Consumption;

5) Broken Function Level Authorization;

6) Unrestricted Access to Sensitive Business Flows;

7) Server-Side Request Forgery;

8) Security Misconfiguration;

9) Improper Inventory Management;

10) Unsafe Consumption of APIs.

Каждая категория — это автономная симуляция запросов и ответов.

Возьмём BOLA. Важно не просто заменить user_id=1001 на user_id=1002 и обрадоваться, а понять, почему проверка «пользователь залогинен» — это вообще не то же самое, что проверка «этот пользователь имеет право именно на этот объект».

Нормальный разбор такой уязвимости должен отвечать хотя бы на четыре вопроса:

1) Кто субъект запроса?

2) Какой объект он пытается получить или изменить?

3) Где именно сервер проверяет связь между субъектом и объектом — и проверяет ли вообще?

4) Можно ли обойти проверку через другой HTTP-метод, пакетный endpoint или вложенное поле?

И да, Top 10 для веба и Top 10 для API — это не взаимозаменяемые списки. Если веб- или мобильное приложение дёргает backend API, смотреть нужно оба слоя, иначе половина картины остаётся за кадром.

500 ВОПРОСОВ — НЕ РАДИ ТОГО, ЧТОБЫ ЗАЗУБРИТЬ РАСШИФРОВКУ АББРЕВИАТУРЫ

500 вопросов с пояснениями внутри нужны не для того, чтобы вы могли с закрытыми глазами расшифровать SSRF на собеседовании. Они проверяют причинно-следственные связи — то, ради чего вообще стоит учиться, а не набор карточек для запоминания.

Плохой вопрос звучит так:

«Как расшифровывается SSRF?»

Полезный вопрос звучит иначе:

«Почему запрет запросов к 127.0.0.1 не защищает от SSRF, если приложение автоматически следует за редиректами или допускает альтернативные представления IP-адреса?»

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

ИЗОБРАЖЕНИЕ: Один из наборов проверочных вопросов с сохранением прогресса и разбором ответов.

https://habrastorage.org/webt/60/20/8d/60208de0a5fb18f49c7a5...

НЕ СПИСОК СТАНДАРТОВ, А КАРТА: ЧТО И КОГДА ЧИТАТЬ

Ещё одна вечная боль учебных материалов — стандарты и методологии существуют как отдельные, никак не связанные друг с другом документы.

Человек прекрасно знает названия NIST SSDF, OWASP ASVS, SAMM или WSTG — и при этом понятия не имеет, в какой момент рабочего процесса каждый из них реально отвечает на нужный вопрос. Знать аббревиатуру и знать, когда её открывать, — разные навыки.

В ROOT методологии собраны примерно в 11 доменах и привязаны к конкретным этапам жизненного цикла:

ВСЕ 11 ДОМЕНОВ

— безопасная разработка;

— моделирование угроз;

— оценка и тестирование;

— устранение уязвимостей;

— управление доступом;

— безопасность цепочки поставок;

— укрепление инфраструктуры;

— обнаружение и реагирование;

— управление риском;

— безопасность API;

— безопасность AI- и агентных систем.

Задача этой карты не в том, чтобы объявить один стандарт «главным», а в том, чтобы показать, как несколько моделей дополняют друг друга вместо того, чтобы соревноваться.

ИЗОБРАЖЕНИЕ: Карта методологий: от безопасной разработки и моделирования угроз до укрепления систем и реагирования.

https://habrastorage.org/webt/5c/18/3d/5c183d399c2a97b3154d7...

КАТАЛОГ ИНСТРУМЕНТОВ: НЕ ОДНА ПАПКА НА ОДИН ПРОДУКТ

Кроме учебных материалов, в ROOT есть:

— методические материалы;

— чек-листы;

— шаблоны отчётов;

— библиотека полезных нагрузок;

— цепочки атак;

— конструкторы команд;

— локальный SQL-терминал;

— справочник инструментов по AppSec, DevSecOps, Mobile и Offensive Security.

Каталог — это не список из сотен названий ради самого списка, а карта: какой инструмент нужен на конкретном этапе и что он должен произвести на выходе.

Сейчас инструменты распределены по четырём верхнеуровневым направлениям:

— AppSec;

— DevSecOps;

— Mobile;

— Offensive Security.

Внутри — дополнительные категории, фазы и теги, поэтому один и тот же инструмент вполне может всплывать в нескольких релевантных местах одновременно.

ИЗОБРАЖЕНИЕ: Каталог инструментов ROOT: AppSec, DevSecOps, Mobile и Offensive Security с поиском и дополнительной классификацией.

https://habrastorage.org/webt/3c/84/73/3c8473d3503004292ee48...

Offensive security, например, раскладывается по фазам:

Разведка

→ Картирование поверхности атаки

→ Поиск уязвимостей

→ Эксплуатация и проверка

→ Постэксплуатация

→ Подготовка отчёта

→ Повторная проверка

В подборках соседствуют инструменты для bug bounty и внешней разведки — Subfinder, Amass, Nuclei, ffuf, httpx, Katana, Arjun, Dalfox — и средства для внутреннего тестирования и red team: BloodHound, Impacket, Mimikatz, Sliver, Mythic, PEASS-ng.

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

Burp Suite одновременно живёт в проксировании, ручном тестировании, DAST и проверке API. Trivy пригождается и для контейнеров, и для SCA, и для IaC, и для SBOM. Nuclei болтается где-то на границе между DAST, шаблонным сканированием и управлением поверхностью атаки.

Поэтому внутри платформы инструмент описывается не одним разделом, а набором возможностей:

{

"name": "Burp Suite",

"domain": "AppSec",

"phases": [

"attack-surface-mapping",

"vulnerability-discovery",

"exploitation-validation"

],

"capabilities": [

"intercepting-proxy",

"dast",

"api-testing",

"manual-testing"

],

"engagements": ["bug-bounty", "pentest", "red-team"]

}

Такой подход отвечает не на скучный вопрос «к какой категории относится Burp», а на куда более практичный:

«Что я вообще могу сделать этим инструментом на текущем этапе проверки?»

ОТ НАЗВАНИЯ ИНСТРУМЕНТА — К КОНКРЕТНОМУ ДЕЙСТВИЮ

Одного перечня инструментов маловато. В рабочей ситуации обычно нужен ответ не на вопрос «что вообще существует», а на вопрос «что конкретно выполнить прямо сейчас».

Поэтому рядом с каталогом лежат:

— полезные нагрузки;

— конструкторы команд;

— цепочки атак;

— шаблоны bug bounty-отчётов;

— Kubernetes-сценарии;

— вспомогательные справочники.

Материалы сгруппированы по классам OWASP и типам проверки: обход контроля доступа, IDOR, SSRF, path traversal, CORS, захват учётной записи и другие сценарии.

Сразу оговорюсь: это не кнопка «атаковать автоматически». ROOT показывает заготовки и контекст их применения, а решение о запуске и проверка разрешённого скоупа всегда остаются за специалистом, и это не формальность, а необходимое условие использования.

ИЗОБРАЖЕНИЕ: Справочник команд и полезных нагрузок: категории OWASP, конструкторы, цепочки проверок и Kubernetes-сценарии.

https://habrastorage.org/webt/36/27/18/3627181338bb7812d9cdb...

КАК ЭТО УСТРОЕНО ТЕХНИЧЕСКИ

ROOT сделан без тяжёлого frontend-фреймворка — и это осознанный выбор, а не лень.

Основной интерфейс написан на обычном JavaScript, разметка и стили работают локально, а браузерная база знаний использует sql.js и WebAssembly. Прогресс пользователя хранится в localStorage.

Архитектура выглядит примерно так:

Browser UI

├── Web / API / LLM learning tracks

├── CTF simulations and quizzes

├── Tools, payloads and attack chains

├── Command builders and report templates

├── sql.js / WASM knowledge database

└── localStorage progress

Python HTTP server

└── Read-only CVE API

└── SQLite archive

Серверная часть — стандартная библиотека Python и SQLite, без магии. API строит параметризованные запросы к базе и публикует только операции чтения — писать в базу через интерфейс нельзя, и это тоже сознательное решение.

Доступные endpoint'ы:

GET /api/cves/status

GET /api/cves?severity=CRITICAL&q=apache&limit=50&offset=0

GET /api/cves/counts

GET /api/cves/{CVE-ID}

Для запуска достаточно Python 3.10 или новее:

git clone https://github.com/madnessbrainsbl/ROOT.git

cd ROOT

python serve.py

После этого интерфейс открывается локально:

http://127.0.0.1:8080

Есть и вариант через Docker Compose:

docker compose up --build

Базовый локальный снимок уже лежит в репозитории, так что для встроенного каталога не нужны ни внешний API-ключ, ни SaaS-аккаунт, ни доступ к учебной облачной лаборатории. Клонировал — и работаешь.

Именно тут раскрывается главное преимущество offline-first подхода. Полигон можно спокойно использовать:

— в закрытой сети;

— в учебном классе с дохлым интернетом;

— на личном ноутбуке без единой регистрации;

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

— как переносную справочную базу при подготовке к собеседованию или сертификации.

Онлайн-версия на GitHub Pages — это витрина интерфейса, не более того. Для полноценной работы с Python API и SQLite репозиторий нужно клонировать себе.

ЧЕМ ROOT ОТЛИЧАЕТСЯ ОТ ДРУГИХ УЧЕБНЫХ ПЛАТФОРМ

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

Проект — Основной формат — Сильная сторона

PortSwigger Web Security Academy — Облачные интерактивные лаборатории — Глубокая и регулярно обновляемая web-практика

Hack The Box / TryHackMe — Удалённые машины, треки и сценарии — Реалистичная инфраструктура и широкий выбор направлений

PentesterLab — Практические упражнения по web security — Последовательные технические треки

ROOT — Offline-first рабочая среда и симуляторы — Связь теории, проверки, исправления, CVE, инструментов и отчётности

PortSwigger даёт заметно более глубокие отдельные лаборатории и обновляется вместе с живым research по web security — тут ROOT никогда не будет конкурентом.

ROOT логичнее воспринимать как связующий слой между всем этим:

Изучил класс уязвимости в ROOT

→ прошёл локальную симуляцию

→ решил полноценную лабораторию в Academy

→ нашёл связанный CVE

→ изучил исправление

→ написал отчёт

→ добавил результат в личную базу знаний

Проект не соревнуется с существующими платформами за звание «самого большого CTF». Его дело — помочь выстроить систему вокруг практики, которая иначе рассыпается на разрозненные вкладки.

CVE, KEV И «ПОЛМИЛЛИОНА БЫВШИХ ZERO-DAY»

Zero-day — это уязвимость, которая ещё не была известна ответственным сторонам, либо для которой на момент эксплуатации не существовало доступного исправления. Обычная запись CVE сама по себе автоматически не является zero-day — это два разных понятия, которые легко перепутать в заголовке, но нельзя путать в статье.

И уж тем более нельзя говорить, что для каждой CVE «защиты нет»: для огромной части уязвимостей давно есть обновления, обходные меры, детекты и компенсирующие контроли.

В ROOT на самом деле несколько разных наборов данных, и смешивать их не стоит:

— расширенный CVE-архив (около 500 тысяч записей), на объём которого рассчитаны API и SQLite;

— облегчённый локальный снимок для автономной работы (около 250 тысяч записей);

— выборка критических CVE;

— записи CISA Known Exploited Vulnerabilities: https://www.cisa.gov/known-exploited-vulnerabilities-catalog;

— учебные материалы и CTF-записи.

Разница в 500 и 250 тысяч — не прихоть, а чистая физика GitHub. Полный архив целиком в репозиторий просто не влезает: ограничения на вес файлов и общий размер репы этого не выдерживают. Поэтому в самом репозитории лежит облегчённый снимок примерно на половину объёма, а полная версия архива используется отдельно, тем же движком — SQLite и read-only API, — но уже вне гитхаба.

CISA KEV — это каталог CVE, для которых есть подтверждённые свидетельства эксплуатации в реальных атаках. CISA рекомендует опираться на KEV как на один из главных источников приоритизации патчей. Это не каталог всех CVE подряд и уж точно не синоним zero-day.

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

Полная локальная версия использует SQLite и read-only API. Онлайн-демонстрация показывает интерфейс, но для работы с серверным API и локальным снимком базы репозиторий нужно развернуть у себя.

ИЗОБРАЖЕНИЕ: Локальный каталог CVE и CISA KEV с поиском, фильтрацией по критичности и карточками уязвимостей.

https://habrastorage.org/webt/72/e2/39/72e2392e414178949ece7...

Корректная формулировка выглядит так:

«В ROOT встроен локальный архив CVE, поисковый SQLite-интерфейс и подборка данных об уязвимостях, представляющих практический интерес, включая записи CISA KEV.»

От фразы «полмиллиона zero-day без защиты» я сознательно отказался: техническая аудитория такую ошибку заметит моментально, и весь разговор уйдёт в разбор терминологии вместо самого проекта.

ЧТО УЖЕ РАБОТАЕТ, А ЧТО ЕЩЁ ПРЕДСТОИТ ДОДЕЛАТЬ

ROOT уже можно запустить из исходников или посмотреть прямо в браузере.

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

ПЯТЬ ПУНКТОВ ТЕХДОЛГА: МЕТРИКИ, ВЕРСИИ, ЛИЦЕНЗИЯ, РЕЛИЗЫ, ГРАНИЦА СИМУЛЯЦИИ

СИНХРОНИЗАЦИЯ МЕТРИК

Сейчас README и интерфейс иногда показывают разные числа инструментов и записей. Документация может отставать на один счётчик, пока рабочий интерфейс уже показывает около 420 карточек.

Правильное решение — генерировать счётчики при сборке, а не редактировать вручную в трёх местах сразу:

stats = {

"ctf": len(ctf_challenges),

"api_labs": len(api_labs),

"quiz_questions": len(quiz_questions),

"tools": len({tool["slug"] for tool in tools}),

"payloads": len(payloads),

"attack_chains": len(attack_chains),

}

Тогда один файл stats.json сможет питать README, интерфейс и страницу проекта одновременно — и они перестанут расходиться.

ГРАНИЦА МЕЖДУ СИМУЛЯЦИЕЙ И НАСТОЯЩЕЙ ЛАБОРАТОРИЕЙ

ROOT должен честно показывать, где пользователь работает с симуляцией, а где — с по-настоящему уязвимым сервисом. Смешивать эти два режима в голове опасно.

Браузерный симулятор хорошо показывает:

— структуру HTTP-запроса;

— изменение параметров;

— нарушение авторизации;

— уязвимый и безопасный код;

— ожидаемый результат атаки.

Но полноценное приложение вдобавок показывает то, что симулятор физически не может воспроизвести:

— состояние сессии;

— гонки запросов;

— кэширование;

— работу reverse proxy;

— ошибки сериализации;

— особенности конкретной базы данных;

— сетевые тайм-ауты;

— реальные логи;

— поведение защитных средств.

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

ДЛЯ КОГО Я ВСЁ ЭТО ДЕЛАЛ

В первую очередь — для людей, которым не хватает маршрута.

Начинающий специалист может пройти OWASP по порядку, решить CTF, закрепить материал и понять, какие инструменты реально относятся к каждой фазе, а не просто красиво звучат.

Разработчик может сравнить уязвимую реализацию с патчем и наконец перестать воспринимать security как список абстрактных запретов «так нельзя».

AppSec- или DevSecOps-инженер получает под рукой локальный справочник по CVE, payload'ам, инструментам, чек-листам и шаблонам отчётов — без необходимости гуглить одно и то же в пятый раз.

Bug bounty researcher может использовать проект для систематизации разведки, тестирования, доказательства влияния и оформления находок.

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

Самая важная идея проекта простая, и весь остальной текст — просто её разворачивание:

«Инструмент сам по себе ничему не учит. Учиться нужно принятию решений: что проверить, почему именно это, как доказать влияние и как убедиться, что патч реально сработал.»

ССЫЛКИ

— Открыть демонстрацию ROOT: https://madnessbrainsbl.github.io/ROOT/

— Посмотреть исходный код и инструкции по запуску: https://github.com/madnessbrainsbl/ROOT

ROOT пока не отвечает на все вопросы и не заменяет реальные стенды — и не претендует на это.

Но он уже решает главную проблему: превращает сотни разрозненных вкладок, команд, CVE и чек-листов в один понятный процесс.

Подбрасывание монеты все считают образцом случайности. Но полёт монеты — обычная механика: если знать силу броска, вращение и сопротивление воздуха, исход вычислим до приземления. Где же тогда живёт «случайность»?

Программа отвечает на это числом. Для каждого события она считает величину L — долю неопределённости, которую снимает знание конкретного наблюдателя.

Наблюдатель не знает ничего: L = 0 — событие для него неотличимо от честной монетки, ровно 50/50.

Наблюдатель знает полное состояние системы: L = 1 — никакой монетки не существует, исход предрешён.

Внимание, фокус: это ОДНО И ТО ЖЕ событие. Одновременно случайное и предопределённое — в зависимости от того, кто смотрит. Случайность оказалась не в монетке, а в отношениях между монеткой и вами.

Дальше программа делает то, что руками не сделать: перебирает все возможные варианты знания и находит минимальный набор фактов, при котором событие становится предсказуемым. И выясняется, что этот минимум — в точности «световой конус» события: те и только те клетки мира, откуда до события физически успевает дойти сигнал. Теория информации сама переоткрыла причинность.

СТЕНА ПЕРВАЯ: ПРОШЛОЕ

Лаплас обещал демону не только будущее, но и прошлое. Проверяем: программа перебирает все состояния мира, из которых могло получиться нынешнее.

Результат неприятный для демона. Вперёд из любого состояния мир идёт ровно в одно будущее. А вот назад — вариантов бывает ноль (так называемые «сады Эдема»: состояния, которые нельзя получить эволюцией, только создать руками), бывает одно, а бывает восемь. Если возможных прошлых восемь — значит, три бита истории уничтожены физически, и никакое знание настоящего их не вернёт. Это стрела времени, посчитанная поштучно, в битах.

СТЕНА ВТОРАЯ: У ПРИРОДЫ НЕ ВСЕГДА ЕСТЬ ФОРМУЛА

У демона есть законные читы. Часть «законов природы» игрушечной вселенной устроена так удачно (математики говорят — линейно), что будущее через квинтиллион шагов считается напрямую, без проживания этих шагов. Программа прыгает через 10^18 шагов за 0.3 миллисекунды.

А для соседнего закона — знаменитого «правила 30» — такого чита не знает никто на Земле. Программа честно отказывает: хочешь узнать, что будет через тысячу шагов, — изволь прожить всю тысячу. Это называется вычислительной несводимостью (термин Стивена Вольфрама): некоторые процессы сами являются кратчайшим способом узнать собственный результат. Никакой суперкомпьютер не поможет — дело не в мощности, а в устройстве задачи.

СТЕНА ТРЕТЬЯ: ХАОС ПОРТИТ ВСЁ ЗА КОНЕЧНОЕ ВРЕМЯ

Для непрерывного мира (летящий мяч, двойной маятник) программа измеряет — не предполагает, а именно измеряет — скорость разбегания близких траекторий. У мяча ошибка измерения не растёт: его будущее честно вычислимо. У двойного маятника ошибка удваивается примерно каждые полсекунды, и любая неточность стартовых данных — хоть миллионная доля — за считанные секунды раздувается до полной непредсказуемости.

Забавная деталь: в ранней версии коэффициент хаотичности маятника был вписан «на глазок» — 5. Честное измерение дало 1.64, и вывод о границе предсказуемости поменялся на противоположный. Мораль: даже у программы про честность враньё находят только измерением.

СТЕНА ЧЕТВЁРТАЯ, ЕДИНСТВЕННАЯ НАСТОЯЩАЯ: КВАНТ

Все стены выше — про цену информации: добыть можно, но дорого. Квантовая стена — про то, что информации НЕТ.

Программа умеет считать квантовые системы и задаёт вопрос: пусть наблюдатель знает о квантовой паре частиц абсолютно всё, что разрешает физика, — полную волновую функцию. Что он скажет об исходе одного измерения? Ответ: ничего. Ноль снятой неопределённости при максимальном знании. L = 0 у всезнающего.

«Так добавьте скрытые параметры, которые мы просто не видим!» — предлагали физики полвека. Программа воспроизводит ответ: тест Белла. Любая теория с заранее записанными ответами даёт корреляции не выше определённого порога (числа 2). Квантовая механика — и программа вслед за ней — выдаёт 2√2, примерно 2.83. Эксперименты 2015 года (без единой лазейки) намерили ровно это. Заранее записанных ответов не существует нигде во Вселенной — Нобелевская премия 2022 года, к слову, ровно за это.

Бонус: программа показывает, что само чтение квантовой информации оставляет следы (одно измерение необратимо портит состояние), а вот непотревоженный квантовый мир помнит всё — запусти эволюцию вперёд и назад, и он вернётся в исходное состояние с точностью до последнего знака.

СТЕНА ПЯТАЯ: ЗНАНИЕ СТОИТ ЭНЕРГИИ

Принцип Ландауэра: стирание одного бита памяти обязано выделить тепло — минимум kT·ln2 джоулей. Проверено экспериментально в 2012 году. Программа считает энергетический счёт демона: сколько джоулей стоит держать и обновлять знание о событии. Знание — не бесплатная абстракция, оно физично.

И вишенка: второй закон термодинамики программа воспроизводит в полностью детерминированном мире, где нет ни одного случайного события. Достаточно, чтобы наблюдатель видел мир «крупными пикселями» — и его неосведомлённость растёт по всем законам термодинамики. Беспорядок — не свойство мира, а свойство размытого взгляда.

СТЕНА ШЕСТАЯ: ДЕМОНА НЕЛЬЗЯ ПОСЕЛИТЬ ВНУТРИ МИРА

Все рассуждения выше молча предполагали: демон смотрит на мир снаружи. А если поселить его внутрь?

Ломается всё, дважды. Во-первых, сигналы в мире распространяются с конечной скоростью, и встроенный наблюдатель знает только свой «световой конус». Программа показывает: способность предсказать событие зависит от того, ГДЕ ты сидишь, а не насколько ты умён. Знать «состояние всей Вселенной прямо сейчас» может только тот, кто вне Вселенной. Таких нет.

Во-вторых, логическая ловушка. Определим событие: «предсказатель объявит, что этого события не будет». Что бы предсказатель ни сказал — он ошибётся. Программа перебирает все возможные стратегии предсказателя: внутри мира проигрывают все до единой. Это тот же приём, что в теореме Гёделя, а физик Дэвид Вольперт доказал общий случай — и даже больше: двух всезнающих во Вселенной быть не может (он в шутку зовёт это «теоремой монотеизма»)

ФИНАЛ: СЫГРАЙТЕ ПРОТИВ ДЕМОНА

Скрытый мир из 31 клетки живёт по правилу 30. Вам показывают одну-единственную клетку и просят угадать её следующее состояние.

Демон не угадывает — он вычисляет: 100% попаданий. Люди зависают на ~50%, как на монетке. При этом каждый бит был предопределён до вашего клика: эту самую последовательность пакет Mathematica годами использовал как генератор случайных чисел — притом что случайности в ней ноль.

Разница между вашими 50% и демонскими 100% — это ваш личный, лично измеренный зазор знания. Та самая «случайность».

ИТОГ

Случайность и вероятность — разные вещи. Классическая случайность (монетка, хаос, беспорядок) — это недостаток знания: её можно скупать за биты, джоули и правильное место во Вселенной. И только квантовая случайность — не дыра в знаниях, а дно мира.

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

Код (MIT, Python + Go, ноль зависимостей): https://github.com/madnessbrainsbl/Laplace_Demon

Из бонусов можно выделить еще Qoder и абсолютно бесплатный Qwen (лимиты до 2000 запросов в день). Каждого из агентов можно абьюзить.

Сохраняем иишки, пока вас еще не удалил AGI.

Гинкго билоба

— нейропротектор + улучшает микроциркуляцию и снабжение мозга кислородом, стабилизирует мембраны нейронов, снижает агрегацию тромбоцитов, действует как антиоксидант

Своего рода аналог Гинкго это Пирацетам + Циннаризин

— классическая схема ноотропа и цереброваскулярного препарата. Усиливает связи между нейронами и улучшает память и обучение, мозговую перфузию.

Из уже не сильно легального фенотропил — ноотроп и психостимулятор. Усиливает выработку энергии в мозге, повышает концентрацию и скорость реакции. Это своего рода «энергетик» при повышенных нагрузках.

Из БАДов можно отметить Омега-3 и жирные кислоты (рыба, лен, грецкие) — улучшают обработку информации и поддерживают клетки мозга.

Бонусом янтарная кислота — природный участник цикла Кребса. Разгоняет производство энергии в митохондриях, помогает при усталости, улучшает работу мозга при гипоксии. А главное если хотите пить алкоголь и не пьянеть, то он идеален.

https://vk.com/clip295755996_456240176

https://t.me/madnessbrainsru/120