Хотел следить за собакой, а следил за TP-Link

Купил дешёвую камеру Tapo, чтобы наблюдать за собакой в своё отсутствие. В итоге пришлось реверсить процесс подключения, декомпилировать APK, перехватывать TLS-трафик и писать криптографические скрипты.

Камера раздражала с первого дня: настройка в frigate оказалась сложной, а информации в сети почти не было.

Примечание: для двустороннего аудио в frigate используйте tapo:// вместо rtsp://. TP-Link ленивы и реализовали аудио только в своём API.

Выяснилось, что после подключения устройство ожидает логин admin и пароль от облака Tapo. Но если сменить пароль в облаке, устройства об этом не узнают. Это навело на мысли:

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

Раздражение из-за навязчивых подписок в приложении Tapo подтолкнуло к поиску облачного решения для подключения.

Перехват трафика

Для перехвата трафика мобильного приложения нужно направить весь HTTP(S)-трафик через прокси. Современные приложения игнорируют прокси и используют привязку сертификатов. Надёжный метод — динамическая инструментация через frida, которая заставляет приложение использовать нужные прокси и сертификаты.

Схема перехвата:

Приложение Tapo (с frida) -> Ноутбук (mitmproxy) -> Камера Tapo

После запуска mitmproxy и внедрения скриптов frida удалось увидеть первоначальный логин до смены пароля:

{
  "method": "login",
  "params": {
    "cnonce": "AD0E189F6E1BA335",
    "encrypt_type": "3",
    "username": "admin"
  }
}

Последующие запросы были зашифрованы:

{
  "method": "securePassthrough",
  "params": {
    "request": "bAhdgihJ9j6PrrknnbXWATBohGTZK5llv3MEzRcmoAmcxexmlVNz3OUX2r0h9a9EG/3X0tBpPi654T2+BjqVEOn2D178kokBpf8RQj01AvBZLYD5S5sFeaCXWiRXA7MgQUppROV4AbrU4f+GOM37KgPqT59qgLVja2slw6CzrKjPzOrG4Ho6Mu6wBa1xepcj"
  }
}

Выводы:

• У Tapo есть пароль по умолчанию, так как логин происходит до знания облачного пароля.
• API использует зашифрованный канал securePassthrough.

Декомпиляция APK

Следующий шаг — декомпиляция APK в JADX для поиска пароля по умолчанию. Запрос логина содержит имя пользователя admin. Поиск по коду привёл к классу CameraOnboardingViewModel, где функция возвращала пароль, передаваемый в new Account().

Пароль по умолчанию для encrypt_type: 3: TPL075526460603

Анализ трафика

С паролем по умолчанию можно получать ключи сессии и расшифровывать сообщения securePassthrough. Для анализа процесса аутентификации пригодилась библиотека PyTapo. С её помощью можно было декодировать запросы из mitmproxy и провести статический анализ.

• Использование Frida-скриптов для перехвата трафика и обхода проверки сертификатов в Android-приложении Tapo для получения пароля от камеры
• Обход ограничений TP-Link: для двустороннего аудио необходимо использовать проприетарный протокол tapo:// в go2rtc, но это лишает возможности использовать ONVIF для управления поворотом камеры
• Критика безопасности IoT и потребительских роутеров: прошивки часто не обновляются годами, содержат уязвимости (CVE), пользователи редко меняют пароли по умолчанию
• Предложение выбирать устройства, изначально поддерживающие открытые стандарты (например, RTSP) и не требующие обязательного использования облачного сервиса и мобильного приложения
• Обсуждение последствий будущих ограничений Android (требование подписи приложений) для реверс-инжиниринга: на рутованных устройствах и эмуляторах методы останутся работоспособными
• Упомянуты полезные инструменты и проекты: HTTP Toolkit, go2rtc для совместимости с разными потоками, библиотека PyTapo для работы с камерами Tapo
• Найдены и использованы уязвимости (CVE-2022-37255) с хардкодными паролями, которые пользователь должен сменить при первоначальной настройке
• Разочарование в IoT-устройствах, требующих обратного инжиниринга для базового функционала; снижение энтузиазма к такому взлому
• Проблема отсутствия URL для получения статичного снимка (snapshot) с камер Tapo и необходимость использовать FFmpeg для извлечения кадра из видеопотока

Как превратить старый iPhone в камеру UniFi Protect

Переехав на экосистему UniFi, я захотел добавить в Protect ещё одну камеру. Под рукой оказался старый iPhone — компактный «мини-ПК» с хорошей камерой. Официально Protect работает только с UniFi-камерами, но поддерживает сторонние устройства через ONVIF.

В App Store не нашёл приложений, которые напрямую транслируют по ONVIF, зато понял: ONVIF лишь «рукопожатие», а сам поток идёт через RTSP. Значит, схема такая:

iPhone (RTSP) → ONVIF-прокси → Protect

1. RTSP-поток с iPhone
   Установил IP Camera Lite (бесплатный тестовый режим). Настроил поток:
   rtsp://admin:admin@192.168.17.189:8554/live
   Проверил через ffplay — картинка и звук пошли.

2. ONVIF-прокси в Docker
   Нашёл на Reddit упоминание контейнера rtsp-to-onvif. Поднял его на Synology, поправил config.yaml:

   • интерфейс eth4 (10 GbE-адаптер);
   • IP и путь RTSP-потока;
   • точные width/height, взятые из вывода ffplay.

3. Добавление в Protect
   В веб-интерфейсе Protect включил «Discover 3rd-Party Cameras», увидел новое устройство, нажал Adopt, ввёл admin/admin. После донастройки камера появилась в списке.

Результат: iPhone теперь полноценная камера Protect, а Surveillance Station и Scrypted можно отключить.

• Пользователь подключил iPhone к UniFi Protect, но не раскрыл, как победил «бесконечный спиннер» и зависание видео.
• Сообщество разочаровано отсутствием деталей и подозревает, что сам автор уже не помнит, что именно помогло.
• UniFi Protect не умеет в live-аудио и детекцию людей/машин на сторонних камерах без отдельного «AI-устройства» за ≈ $200.
• Старые iPhone как 24/7-камеры критикуют за перегрев и разбухание батарей; предлагают либо удалить аккумулятор, либо купить $30–50 камеру.
• Кто-то пошутил, что фанаты UniFi — «веганы техно-мира»: всем обязательно расскажут, что у них UniFi.