# За 9 дней с AI: как Calif Research собрала червя для WeChat — и что это значит для вашего приложения
Каноническая страница: https://plainews.ru/posts/weworm-zero-click-wechat-ai-exploit-protection
Опубликовано: 2026-09-10T07:01:13.705Z

Calif Research собрала червя для WeChat за 9 дней с помощью AI. Разбираем, как устроена атака и что делать разработчику прямо сейчас.
Стартап Calif Research из Пало-Альто опубликовал демо WeWorm — первого zero-click червя, который распространяется через входящие звонки WeChat на iOS и Android. Жертва не берёт трубку. Жертва вообще не касается телефона. Эксплойт всё равно срабатывает. Команда нашла уязвимость и написала первый RCE-эксплойт (удалённое выполнение кода) примерно за два дня работы с AI, ещё неделя ушла на сам червь.

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

## Как работает атака, которую не нужно принимать

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

Calif нашла баг в слое обработки медиа (memory-corruption, то есть повреждение памяти). Именно там, где приложение разбирает аудио- или видеопоток до любого пользовательского взаимодействия. Атакующий звонит — устройство обрабатывает служебные пакеты — происходит переполнение буфера или use-after-free — выполняется произвольный код. Если жертва всё же берёт трубку, она слышит тишину. Эксплойт к этому моменту уже отработал.

Червь распространяется дальше: получив контроль над устройством, он звонит контактам из адресной книги. Цепочка самовоспроизводится без участия человека.

## Что AI сделал за два дня

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

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

1. **Статический анализ кода WeChat** — LLM просматривал декомпилированный или реверс-инжинированный код в поисках паттернов небезопасной работы с памятью.
2. **Генерация фаззинг-кейсов** — модель предлагала входные данные, которые с высокой вероятностью триггерят граничные условия в парсере медиапакетов.
3. **Написание PoC-эксплойта** — после того как баг был локализован, AI помог написать первый работающий proof-of-concept под конкретную архитектуру.
4. **Итерация по обходу защит** — ASLR, stack canaries и прочие митигации (механизмы защиты) обходились итеративно: модель предлагала варианты, исследователи проверяли.

Именно итерационная скорость — главное, что дал AI. Цикл «гипотеза → тест → результат» сжался с часов до минут.

## Что проверить в своём приложении прямо сейчас

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

**Проверьте обработку медиа и бинарных протоколов.** Нативные библиотеки для аудио/видео (особенно форки libvpx, opus, ffmpeg) исторически богаты memory-corruption багами. Убедитесь, что используете актуальные версии.

```bash
# Проверить версию встроенного ffmpeg в Android-проекте
grep -r "ffmpeg" ./app/build.gradle --include="*.gradle"
grep -r "libvpx\|libopus\|libwebrtc" ./app/src/main/jni/
```

**Включите все доступные компиляторные защиты.** Для Android NDK:

```plain
# CMakeLists.txt
target_compile_options(your_lib PRIVATE
  -fstack-protector-strong
  -D_FORTIFY_SOURCE=2
  -fsanitize=address   # только для debug/CI-сборок
)
target_link_options(your_lib PRIVATE
  -Wl,-z,relro
  -Wl,-z,now
)
```

**Запустите фаззинг на парсерах входящих данных.** AFL++ или libFuzzer покрывают большинство сценариев. Точка входа — любая функция, которая принимает внешние байты до аутентификации пользователя.

```bash
# Пример запуска libFuzzer для изолированного парсера
clang++ -fsanitize=fuzzer,address -o fuzz_parser fuzz_parser.cpp parser.cpp
./fuzz_parser -max_len=65536 -jobs=4 corpus/
```

**Изолируйте обработку медиа в отдельный процесс.** На Android это android:process в манифесте плюс минимальные разрешения через android:isolatedProcess="true". Если эксплойт сработает в изолированном процессе, он не получит доступ к контактам и хранилищу.

```plain
<!-- AndroidManifest.xml -->
<service
    android:name=".MediaProcessingService"
    android:isolatedProcess="true"
    android:permission="android.permission.BIND_JOB_SERVICE" />
```

## Где это ломается — подводные камни

**Изоляция процессов не панацея.** Ядерные эксплойты (privilege escalation) позволяют выбраться из изолированного процесса. WeWorm, судя по описанию, работает именно так — сначала RCE в контексте WeChat, потом расширение привилегий.

**Фаззинг не найдёт логические баги.** Он хорош для memory-corruption, но пропустит уязвимости в бизнес-логике или криптографии. Нужен ручной code review критических путей.

**Обновления зависимостей блокируются «стабильностью».** Команды часто откладывают обновление нативных библиотек, потому что боятся регрессий. Это именно то окно, в которое заходят атаки уровня WeWorm.

**AI-ускорение работает в обе стороны.** То, что Calif сделал за два дня, завтра сделает менее квалифицированный атакующий за четыре. Временной буфер между раскрытием уязвимости и массовой эксплуатацией сокращается.

## Что попробовать дальше

Запустите OSS-Fuzz на открытых компонентах своего стека — Google бесплатно фаззит библиотеки с открытым кодом. Посмотрите на Semgrep с правилами для C/C++ memory-safety — он ловит паттерны небезопасного использования памяти на уровне статического анализа в CI. Если используете WebRTC или любой медиастек в нативном коде, изучите Memory-safe media processing — Google постепенно переписывает критические части Chromium на Rust именно из-за таких атак.

---

## FAQ

### Что такое zero-click атака и чем она опаснее обычной?

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

### WeWorm уже используется в реальных атаках?

Calif Research опубликовала демо в исследовательских целях. На момент публикации это proof-of-concept, а не инструмент в открытом доступе. Tencent (разработчик WeChat) должен был получить уведомление по стандартной процедуре ответственного раскрытия.

### Как AI помогает находить такие уязвимости быстрее?

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

### Что делать, если мой стек использует нативные медиабиблиотеки?

Первый шаг — аудит версий: убедитесь, что libvpx, opus, ffmpeg и WebRTC обновлены до последних стабильных релизов. Второй — изоляция: вынесите обработку медиа в отдельный процесс с минимальными привилегиями. Третий — фаззинг парсеров входящих данных в CI.

### Применимо ли это к iOS так же, как к Android?

Да. Calif подтвердила работу WeWorm на обеих платформах. iOS ограничивает изоляцию процессов сильнее, но уязвимость в нативном коде WeChat работает независимо от ОС — приложение запускает один и тот же медиастек на обеих платформах.

## Источники

- Simon Willison: Quoting Calif Research