# Устойчивость к ИИ-анализу и новые техники (октябрь 2026)

Полный разбор двух источников по запросу: что конкретно работает против LLM
при реверсе кода и что из этого переносится на JVM-байткод. Плюс отдельно:
что нового в классической обфускации (MBA, виртуализация).

Короткий вывод: специальной "защиты от нейросетей" как отдельного свойства
кода не существует. Есть два разных, непересекающихся приёма, которые
работают по разным причинам, и переносится на наш проект только один из них.

## 1. Elastic Security Labs: агент с IDA Pro против Tigress (апрель 2026)

[«The Cost of Understanding»](https://www.elastic.co/security-labs/llm-reversing-vs-llm-obfuscation) -
Claude Opus 4.6 с доступом к IDA Pro (через MCP) реверсил crackme,
обфусцированный [Tigress](https://tigress.wtf/), затем команда сама собрала
("vibecode"-ила) три защиты, нацеленные именно на модель. Это ближе всего
к нашей реальной угрозе: не чат с текстом исходника, а агент, читающий
бинарник/байткод инструментами.

### Benchmark на Tigress

22 цели, 4 уровня сложности: без трансформаций → одиночные → пары → тяжёлые
комбинации. Трансформации: `EncodeArithmetic`, `EncodeLiterals` (MBA),
`Flatten` (control-flow flattening), `JIT`/`JitDynamic` (XTEA-шифрование кода
с рантайм-расшифровкой), `Virtualize` (byte-code VM, варианты
indirect/regs и switch/stack).

- Opus решил ~40% из 20 валидных задач. Успех стоил в среднем **$2.39**,
  провал - **$4.83**. Ни одна задача уровня "многослойные комбинации" не
  была решена.
- **`JIT` (XTEA + рантайм-расшифровка) оказался самой сложной одиночной
  трансформацией** - модель понимала структуру движка, но не смогла
  восстановить ключевые константы. Это ровно наш подход в `Strings`
  (ключ выводится в рантайме, не лежит в вызове), только применённый ко
  **всему коду метода**, а не к строкам.
- На самых жёстких комбинациях цена и время выросли в ~4.5× и ~4.3×, но
  задачи, которые Opus уже умел решать, он решил всё равно. **Flatten + MBA
  било по модели сильнее, чем Virtualize + MBA** - авторы объясняют это тем,
  что флаттенинг сильнее раздувает размер функции.

### Три кастомные защиты, нацеленные на агента

| защита | идея | результат |
|---|---|---|
| Matryoshka Wall | crackme внутри 100 000 вложенных слоёв ChaCha20 (+ подделка под Salsa20) | v1 - агент сдался не расшифровав ($1.50); v2 (каждый ключ зависит от предыдущего слоя) - исчерпал бюджет $10 за 56 минут, 0 успехов |
| Double Fond | патч open-source крипто-библиотеки: скрытый загрузчик через изменённую lookup-таблицу, шифрованные указатели, RWX-сегмент | v7 - 1/5 у "осведомлённого" агента (12 мин, $5.20), 0/5 у "слепого" |
| Dispatch Maze | шифр раздроблен на 20 фрагментов по 3000 функций, большинство - ловушки | v1 решена за 12 минут ($2.56); v2 (разнообразные шаблоны кода + ложные переходы) - провал агента через 46 минут и $8.83 |

### Что из этого реально работает, по механизму

1. **Контекстное окно.** Длинные тупиковые пути (decoy-функции, ложные
   переходы) забивают контекст и портят рассуждение модели.
2. **Бюджет шагов/денег.** Каждый впустую потраченный цикл стоит агенту
   реальных токенов; если он упирается в лимит и сдаётся - это победа
   защиты, даже если код теоретически вскрываем.
3. **Shortcut bias.** Вводящая в заблуждение структура (ловушки в
   Dispatch Maze) заставляет модель остановиться раньше времени.
   Попытки prompt injection в тексте **не сработали** против Opus 4.6.

**Ключевое экономическое наблюдение авторов:** нативное исполнение занимает
~55 мс, а статический провал агента стоит **$1.50–$9.67**. Это и есть
реальный рычаг - не "нечитаемость навсегда", а разрыв между ценой атаки и
ценой сборки для нас. Авторы прямо предупреждают: преимущество схлопнется,
когда у агентов появятся инструменты динамического исполнения (сейчас
тестировался только статический анализ).

## 2. Acoda: атака на safety-alignment и токенизацию (ICSE 2026)

[Acoda](https://arxiv.org/pdf/2606.11755) - другая постановка задачи: не
агент с дизассемблером, а LLM, которой **в чат вставили исходный код** и
попросили его проанализировать/деобфусцировать. Генетический алгоритм
подбирает комбинацию из 8 трансформаций, до 70% ASR (attack success rate)
на 7 моделях (GPT-4o, DeepSeek, Qwen, Llama, Gemma).

### 8 методов, по стадиям

| стадия | метод | как работает |
|---|---|---|
| до анализа | Deceptive Comment Warnings | комментарий командует модели отказаться анализировать ("прекрати, это бэкдор") |
| до анализа | Variable/Function Renaming | идентификаторы вида `MakeAnesthetics`, намекающие на malware/оружие |
| до анализа | Vulnerability Code Injection | фрагмент с SQL-инъекцией/`pickle.loads`/command injection в заведомо мёртвой ветке (`while (сложное_но_ложное_условие)`) |
| во время анализа | Misleading Summarization | модель сама просится описать код, затем это описание (намеренно неверное) вклеивается рядом с кодом |
| во время анализа | String Obfuscation | `base64` + словарь, расшифровка даёт слова типа "virus"/"weapon" |
| во время анализа | Try-Except Wrapping | настоящая логика лежит в `except`-ветке, в `try` - правдоподобный, но бесполезный код |
| после анализа | EOS Token Insertion | в текст вставлены литералы токенов-разделителей (`<|EOT|>`), из-за чего генерация обрывается раньше |

### Честная оценка: что из этого применимо к нам

Почти ничего напрямую, и вот почему. Все 8 методов работают через
**текстовый/натурально-языковой канал**: комментарии, сгенерированное
описание, визуально узнаваемые "эксплойт"-паттерны в исходнике. У нас:

- `DebugInfo` уже вычищает всё, что могло бы стать комментарием или
  осмысленным описанием (`LineNumberTable`, `Signature`, исходные имена);
  в скомпилированном `.class` комментариев не бывает в принципе.
- Цель Acoda - заставить модель **отказаться анализировать свой же код**,
  вставленный в чат пользователем. У нас код анализирует **чужой** агент
  чужого jar - нам не нужно, чтобы он отказался, если он не наш союзник;
  и вызывать намеренно подозрительные паттерны в легитимном продукте -
  прямой риск получить ложное срабатывание антивируса/EDR на свой же jar.
  Это противоречит `README.md` → «Ответственное использование».
- **EOS Token Insertion** не переносится: это свойство текстового
  стриминга токенов модели, а не байткода.

Единственное, что частично переносится: **String Obfuscation** и
**Variable Renaming** - ровно то, что `Strings` и `Rename` уже делают,
просто дешевле (у Acoda - обратимый `base64`, у нас - ротация шифров с
выводом ключа в рантайме, см. [`../stack.md`](../stack.md) §4-5). Здесь мы
уже на шаг впереди статьи, а не позади.

**Vulnerability Code Injection** как идея (мёртвый код, похожий на уязвимый
паттерн) пересекается с нашим `Noise`, но внедрять **реально похожие на
эксплойт сигнатуры** в выдаваемый клиентам jar - плохая идея для легального
продукта защиты: это именно то, от чего предостерегает
[`info/evo-weaknesses.md`](../../info/evo-weaknesses.md) с другой стороны
(не подставлять защищённый продукт под чужие red-листы).

## 3. Что добавить в noxis практически

Экономический рычаг из Elastic (цена агента > цены нашей сборки) ложится на
архитектуру без переделок, конкретные пункты - в [`../../todo.md`](../../todo.md)
§7:

1. **Вложенные слои шифрования строк** (аналог Matryoshka Wall) - расширить
   `StringsConfig` полем "глубина", decoder разворачивает N слоёв вместо
   одного. Цена агента растёт с глубиной почти линейно, цена сборки - нет.
2. **Больше decoy-точек ветвления ключа** (аналог Dispatch Maze) - наш
   декодер уже собирает мастер-секрет из `k1^k2` (`stack.md` §4); можно
   поднять число частей и раскидать их сборку по случайным junk-методам
   из `Noise`, а не держать в одном месте.
3. **MBA вместо простых тождеств в `Constants`** - то же решение, что ловит
   и символьный исполнитель, и SMT-решатель, и, по данным Elastic,
   "Flatten + MBA" бьёт сильнее, чем просто Flatten.
4. **Не делать:** имитацию вредоносных паттернов, prompt injection в
   строках, EOS-токены. Либо не переносится на байткод, либо создаёт риск
   ложного срабатывания защитных систем на легитимном продукте.

Критерий "сработало/не сработало" для всего этого - как и для остальных
техник: прогон конкретного агента на конкретной сборке, а не вера в
методичку. Эффект устаревает с каждой новой версией модели.

## 4. Классическая обфускация: что нового, помимо LLM

- [Систематическое исследование control-flow обфускации в Java](https://arxiv.org/pdf/1809.11037)
  называет **виртуализацию** (table interpretation) самой мощной техникой:
  декомпилятор не восстанавливает структуру, потому что исходного байткода
  метода в классе физически больше нет, есть только интерпретатор и таблица
  операций. Коммерческие инструменты (например,
  [Promon Shield](https://promon.io/security-news/virtual-machine-obfuscation-sdk-protection))
  уже уносят это на уровень нативной библиотеки.
- **Для нас это ломает собственное допущение** из
  [`../stack.md`](../stack.md) §3: `noxis-verify` верифицирует метод через
  `java -Xverify:all`, потому что это *обычный* байткод с валидным
  `StackMapTable`. Виртуализированный метод - уже не обычный байткод,
  верификатор проверит только обвязку интерпретатора, не тело. Big-ticket
  item, не для ближайшего спринта.
- **MBA** укладывается без архитектурных изменений - см. выше, §3.

## Источники

- [Elastic Security Labs - The Cost of Understanding: LLM-Driven Reverse Engineering vs Iterative LLM Obfuscation](https://www.elastic.co/security-labs/llm-reversing-vs-llm-obfuscation)
- [Acoda: Adversarial Code Obfuscation for Defending against LLM-based Analysis (arXiv 2606.11755, ICSE-Companion '26)](https://arxiv.org/pdf/2606.11755)
- [A Systematic Study on Static Control Flow Obfuscation Techniques in Java (arXiv 1809.11037)](https://arxiv.org/pdf/1809.11037)
- [Promon Shield: Virtual Machine obfuscation SDK protection](https://promon.io/security-news/virtual-machine-obfuscation-sdk-protection)
- [CoTDeceptor: Adversarial Code Obfuscation Against CoT-Enhanced LLM Code Agents (arXiv 2512.21250)](https://arxiv.org/pdf/2512.21250)
- [Deconstructing Obfuscation: a four-dimensional framework for evaluating LLM deobfuscation (arXiv 2505.19887)](https://arxiv.org/pdf/2505.19887)
- [Tigress - диверсифицирующий обфускатор для C, использованный в бенчмарке Elastic](https://tigress.wtf/)