Skip to content

README-RU.md

Latest commit

 

History

History
136 lines (99 loc) · 12.6 KB

README-RU.md

File metadata and controls

136 lines (99 loc) · 12.6 KB

ENG | RUS

Техническое задание: Проект: "Hydra-Core"

License: MIT Language: Go Platform: Cross-Platform Status: Concept/Alpha

Версия: 1.0 (Stable Concept / Adaptive Implementation)
Статус: Проектирование архитектуры активного противодействия
Стек: Go (Core/Logic), Kotlin (Android), Swift (iOS), JavaFX (Desktop), TOML/JSON (Dynamic Configs)
Лицензия: MIT

1. Общее описание и Философия

Hydra-Core — это интеллектуальный кроссплатформенный фреймворк для обхода систем глубокого анализа пакетов (DPI) и ТСПУ (Технических Средств Противодействия Угрозам).

Ключевая инновация: Переход от пассивного обхода к стратегии «Вычислительной асимметрии». Вместо простой маскировки, Hydra-Core эксплуатирует конечность ресурсов памяти (SRAM/TCAM) и процессорного времени DPI-узлов. Используя Go-ядро, приложение находит «бреши» в алгоритмах дефрагментации и сборки пакетов цензора, заставляя его тратить в 100–1000 раз больше ресурсов на анализ одной сессии, чем тратит клиент на её генерацию. Цель — принуждение DPI к переходу в режим Fail-Open (пропуск трафика без анализа при перегрузке).

2. Системная архитектура

2.1. Многоуровневое разделение

  1. L3/L4 Adaptive Core (Go): Прямая манипуляция сырыми пакетами (Raw Sockets/TUN).
    • Модуль Jitter-Buffer: внесение микрозадержек для обхода аппаратных таймеров дефрагментации.
    • Реализация кастомного стека TCP/UDP для генерации невалидных, но «аппетитных» для DPI состояний.
  2. Strategy Hunter Engine (Go): Динамический фаззинг параметров (TTL, Split-position, Window Size).
    • Обратная связь (Feedback Loop) через анализ RTT и типов RST-пакетов.
  3. Orchestrator & FFI: Управление жизненным циклом стратегий.
    • Анонимизированная синхронизация «победных» пресетов через Hydra-Net.
  4. Platform Wrappers: Android: VpnService + JNI (высокая производительность).
    • iOS: NetworkExtension + PacketTunnelProvider.
    • Desktop: Wintun (Windows) / UTUN (macOS) / TUN (Linux).

3. Техническая спецификация Core (Go)

3.1. Модуль хирургической манипуляции (DPI-Evasion)

Реализация методов, эксплуатирующих логику TCP Reassembly:

  • Lazy Fragmenting: Дробление SNI на части (например, по 1-2 байта) с внесением искусственной задержки между ними ($delay > 100ms$). Это заставляет DPI либо блокировать легитимный трафик (вызывая жалобы), либо пропускать сегменты без сборки.
  • Overlapping Segments: Отправка сегментов TCP с перекрывающимися Sequence Numbers, где первый сегмент содержит «мусор», а второй — реальные данные. Некорректная реализация дефрагментации в DPI приведет к анализу мусора.
  • Multi-TTL Desync: Инъекция фейковых пакетов (HTTP/TLS) с выверенным TTL, который позволяет пакету дойти до узла DPI, но заставляет его «умереть» до достижения целевого сервера.

3.2. Advanced Stress Engine (Эксплуатация ресурсов)

Вместо бессмысленного флуда, модуль бьет в узкие места железа:

  • SRAM State Exhaustion: Генерация тысяч uTLS (Client Hello) сессий с валидными фингерпринтами современных браузеров. Это забивает таблицы состояний (State Tables) DPI, вынуждая его включать агрессивный LIFO-drop, под который попадают и другие сессии.
  • QUIC-Spin & Entropy Attack: * Манипуляция Spin Bit в QUIC для дезориентации алгоритмов замера качества сети.
    • Adaptive Padding: Динамическое изменение размера UDP-пакетов QUIC (1200–1450 байт) для мимикрии под потоковое видео и обхода эвристик длины пакета.
  • Zero-Window Attack: Имитация перегрузки клиента через TCP Window Size = 0, заставляющая DPI удерживать сессию в памяти максимально долго в ожидании открытия окна.

3.3. Модель «Phantom Router»

Имитация присутствия за NAT множества устройств:

  • Fingerprint Rotation: Каждая параллельная сессия использует уникальный набор TCP-опций (MSS, SACK_PERM, TSopt), имитируя разные ОС (Windows, iPhone, Android).
  • TTL Randomization: Рандомизация TTL в диапазоне $\pm 3$ от базового, чтобы имитировать разную топологию внутренней сети пользователя.

4. Алгоритм "Strategy Hunter" (Интеллектуальный обход)

Это ключевой модуль адаптации, работающий по принципу биологической эволюции.

4.1. Feedback Loop и Детекция

Алгоритм различает типы блокировок:

  1. Active RST: Если Sequence Number в RST-пакете не совпадает с ожидаемым — это инъекция DPI. Hunter замеряет время прихода (Delta RTT). Если Delta < 10мс — цензор «близко».
  2. Silent Drop: Детектируется через отсутствие ACK после серии ретрансмитов.
  3. Throttling: Детектируется через сравнение RTT для L4 (SYN-ACK) и L7 (TLS Finished).

4.2. Метод поиска «Щели»

  1. Probe Phase: Попытка пройти с split_pos = 2. Если неудача — перебор позиций.
  2. Desync Calibration: Traceroute до целевого хоста для определения точного TTL, на котором стоит «коробка» цензора. Установка fake_ttl = current_hop - 1.
  3. QUIC Migration: При потере пакетов в UDP-канале > 15%, Hunter инициирует Connection Migration, меняя порт и CID, сбрасывая контекст анализа для DPI.

4.3. Hydra-Net (Анонимный обмен)

Обмен найденными стратегиями происходит через Probabilistic Gossiping:

  • Узлы делятся хеш-таблицами вида {ASN_ID: Strategy_Hash}.
  • Данные передаются через стеганографические каналы (например, в заголовках запросов к доверенным Beacon-хостам) или публичные JSON-репозитории.

5. Платформенные особенности (Исправлено)

5.1. Мобильные платформы (Android/iOS)

  • Battery-Aware Stress: Stress Engine автоматически снижает активность при уровне заряда < 20% или при перегреве CPU, переходя в режим чистой мимикрии (VLESS-like).
  • JNI Efficiency: На Android дескриптор TUN передается напрямую в Go через os.NewFile, минуя копирование буферов между Java и C.

5.2. Desktop (Windows/Linux/macOS)

  • Wintun Layer: Использование самого быстрого драйвера для Windows, обеспечивающего пропускную способность до 10 Гбит/с.
  • Visual Debugger: Интерфейс на JavaFX отображает «карту боя»: нагрузку на DPI (оценочно), текущую стратегию обхода и статус «здоровья» маршрутов.

6. Роадмап (Milestones)

  • Phase 1: Foundation (0-2 мес): Go-ядро с поддержкой uTLS и базовой дефрагментации. CLI-версия.
  • Phase 2: Tactical (2-4 мес): Реализация Strategy Hunter и калибровки TTL. Интеграция с Android VpnService.
  • Phase 3: Resilience (4-6 мес): Модуль QUIC-Stealth и Connection Migration. iOS NetworkExtension.
  • Phase 4: Critical Mass (6+ мес): Запуск Hydra-Net для анонимного обмена конфигами. Старт программы «100к узлов» для тестирования гипотезы Fail-Open на национальных сегментах.

7. Технические риски и Противодействие

  1. Риск: White-listing (Default Deny). Ответ: Hydra-Core поддерживает Domain Fronting и мимикрию под разрешенные протоколы (проброс трафика внутри TLS-сессий к легитимным CDN).
  2. Риск: PPS Limiting (Ограничение пакетов). Ответ: Hunter адаптирует интенсивность шума, чтобы не превышать порог фильтрации провайдера («Last Mile Protection»).

Приложение: Структура "QUIC-Stealth" конфига

{
  "protocol": "QUIC/UDP",
  "evasion_level": "surgical",
  "padding": "dynamic_range_1200_1450",
  "spin_bit": "chaos_mode",
  "migration_trigger": "loss_15pct",
  "fake_initials": 50
}

Философия и юридический отказ

Заключение: Hydra-Core — это не просто инструмент для «открытия сайтов». Это инструмент, который делает цензуру финансово невыгодной. Мы перекладываем стоимость блокировок с плеч гражданского общества на бюджеты цензурных ведомств, заставляя их оборудование работать на пределе физических возможностей.

Проект Hydra-Core создается как исследовательский инструмент для изучения устойчивости сетей к цензуре. Разработчики не несут ответственности за использование инструмента в целях, нарушающих локальное законодательство. Однако мы верим, что свобода информации — это фундаментальное право человека, и техническое противодействие цензуре является формой цифровой самообороны.

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