«WhatsApp проверяет память на следы Xposed-мостов» - фраза, которая объясняет слишком много и слишком уверенно. Реальная картина сложнее: индустрия anti-hooking действительно умеет находить инъекции в память, но что именно из этого арсенала использует WhatsApp - Meta никогда не публиковала. Разберём, где проверяемая техника Android, а где - реконструкция сообщества автоматизаторов.
Модифицированный APK (GBWhatsApp) и официальный APK с инъекцией в память через LSPosed - разные вещи технически, но одинаково рискованные на практике. Подпись защищает мод-клиенты на этапе файла; здесь риск в рантайме. Официальное приложение из Google Play защищает от детекта по подписи, но не защищает от детекта по поведению процесса, если внутрь этого процесса на лету внедряется сторонний код.
Было:
WhatsApp проверяет память на следы Xposed-мостов, модулей Magisk, Zygisk, изменённых системных библиотек.
Стало:
Это распространённая и технически правдоподобная гипотеза, основанная на стандартных практиках anti-tampering в индустрии Android в целом. Но прямого подтверждения, что именно WhatsApp сканирует память на конкретные сигнатуры Xposed или Magisk, в открытых источниках нет.
Было:
Главный маркер: команда отправки уходит без физического события отрисовки и нажатия на экран - слишком быстрые системные вызовы в обход UI-слоя.
Стало:
Подтверждённый антиспам-механизм WhatsApp - это анализ поведенческих паттернов: скорости отправки, всплесков активности, неестественно равномерных интервалов между сообщениями. Что детект строится именно вокруг отсутствия физического тапа по экрану или разрыва между UI-слоем и системным вызовом - не подтверждено ни одним источником - как и MotionEvent-гипотезы в сторонних APK.
| Техника | Существует в индустрии Android | WhatsApp подтверждённо это применяет |
|---|---|---|
Сканирование /proc/self/maps на артефакты hook-фреймворков |
Да [✓] | Не подтверждено |
| Проверка PLT/GOT на подмену адресов | Да [✓] | Не подтверждено |
| Поиск inline-хуков по байтам критичных функций | Да [✓] | Не подтверждено |
| Контроль целостности Zygote-процесса | Да [✓] | Не подтверждено |
ART method verification через JNI FromReflectedMethod |
Да [✓] | Не подтверждено |
| Play Integrity API (Device/Strong Integrity) | Да [✓] | Да [✓] |
| Поведенческий антиспам: скорость, паттерны, всплески | Да [✓] | Да [✓] |
Единственные две строки с прямым подтверждением для WhatsApp - Play Integrity и поведенческий антиспам. Всё остальное - общая техническая база индустрии, которую правдоподобно, но не доказанно проецируют на WhatsApp.
LSPosed и Xposed внедряют код в процесс приложения через мост (de.robv.android.xposed.XposedBridge) и перехватывают методы - Java через ART, нативные через GOT/PLT или inline-патчи. Это не теория, а задокументированная механика самих фреймворков.
Проблема для автоматизатора в том, что эти техники объективно создают артефакты: загруженные классы моста в памяти процесса, смещённые указатели в таблицах виртуальных методов, аномальные структуры soinfo в Bionic linker с пустым путём к файлу или разрывами в связном списке загруженных библиотек. Современные Android-приложения умеют искать подобные артефакты - это общеотраслевая практика, а не специфика WhatsApp.
LSPosed при этом обнаруживается приложениями именно тогда, когда процесс реально попадает в scope модуля и подвергается модификации - это подтверждённое поведение фреймворка, зафиксированное в обсуждениях разработчиков, а не предположение.
Здесь подтверждение твёрдое. WhatsApp использует Google Play Integrity API для оценки целостности устройства и среды. Активные модули LSPosed/Xposed, даже скрытые инструментами вроде Shamiko, часто проваливают проверку по критерию MEETS_STRONG_INTEGRITY - потому что загрузчик разблокирован, а системный образ модифицирован на уровне, который Google и так умеет детектировать независимо от WhatsApp.
Это значит, что даже без гипотетического «сканирования памяти на XposedBridge» само наличие активного root-окружения создаёт реальную проблему через совершенно другой, официально задокументированный канал - тот же API фигурирует в разборе эмуляторов и мод-клиентов.
Разработчик собрал бота на физическом Pixel: официальный WhatsApp Business из Google Play, LSPosed перехватывает входящие сообщения и вызывает внутренние методы отправки напрямую, без эмуляции UI-цепочки. Несмотря на оригинальное приложение и качественную резидентскую сеть, номер получил постоянный бан через 15 сообщений.
Что показывает кейс: прямой вызов внутренних методов в обход интерфейса - реально рискованная практика, подтверждённая опытом конкретной команды. Чего кейс не доказывает: что причиной стал именно разрыв между UI-событием и системным вызовом, а не общая скорость и паттерн отправки, которые WhatsApp подтверждённо отслеживает - см. поведенческий антиспам. Корреляция здесь не равна вскрытому механизму.
Вторая команда модифицировала подход - хук стал эмулировать ввод текста через системные буферы Android и добавлять задержки перед финальным вызовом, имитируя работу UI-потока. Срок жизни аккаунтов вырос, но каскадные баны продолжились при плановых обновлениях защитных библиотек WhatsApp - это говорит скорее о гонке обновлений, чем о конкретном найденном и устранённом маркере.
Часть разработчиков утверждает, что при полной программной эмуляции цепочки UI-событий и скрытии классов Xposed через кастомную сборку ядра (KernelSU) детекция невозможна в принципе. Другие возражают: проприетарные антифрод-библиотеки Meta обфусцированы и постоянно меняют проверочные векторы, что делает любую долгосрочную маскировку в памяти нерентабельной.
Подтверждений ни одной стороне нет - это область реконструкций без проверяемых данных от Meta, как и в серых схемах инфраструктуры.
Форумные оценки без подтверждения [~]:
Подтверждённые антиспам-бенчмарки из практики автоматизации [✓]:
Официальных цифр Meta по проценту банов за LSPosed/Xposed, количеству обнаруженных модулей или таймингу проверки памяти не существует.
«Официальный APK = аккаунт в безопасности» Неверно. Подпись защищает от детекта по происхождению файла, но не от детекта по поведению модифицированного в рантайме процесса.
«DenyList или Shamiko полностью скрывают root» Не подтверждено. В сообществе разработчиков обсуждаются новые методы обнаружения Zygisk-инъекций, которые срабатывают даже при включённом DenyList.
«Хуки в памяти безопаснее обычной UI-автоматизации» Не подтверждено. Практики сообщества скорее считают memory-hooking одним из самых рискованных способов автоматизации именно из-за множественности точек детекта - целостность среды плюс поведенческий антиспам одновременно.
«Если отправлять редко, хук не заметят» Не подтверждено. Если технический маркер модификации процесса зафиксирован, теоретически это не зависит от объёма рассылки - но прямого доказательства превентивного бана при нулевой активности тоже нет.
Если автоматизация уже построена на LSPosed-хуках в официальный WhatsApp, сначала проверьте результат Play Integrity API на устройствах фермы - это единственный официально задокументированный канал, через который модификация среды реально влияет на доступ. Для коммерческих рассылок рассмотрите официальный WABA - он не зависит от целостности процесса на устройстве.
Практическое правило:
Официальный APK защищает подпись файла, а не поведение процесса, который вы в него внедрили.
