Разработка
Взлом приложения Tea: разбираем нелепый исходный код
Приложение Tea — не результат работы плохого ИИ, а вопиющая халатность разработчика, вероятно, одного, с очень небольшим опытом, которому нельзя было позволять публиковать такое приложение без надзора.
К настоящему моменту все уже слышали о взломе приложения Tea: «Хакеры слили 13 000 фотографий и удостоверений пользователей из приложения Tea». Это приложение на Flutter для Android и iOS, написанное парнем с 6-месячным опытом программирования. Tea позволяет женщинам сплетничать о мужчинах, с которыми они встречались на сайтах знакомств. Я дизассемблировал исходный код, так что вам не придётся этого делать. Давайте разберёмся в нем.
Я пошагово объясню, как дизассемблировать исходный код любого приложения для Android. В этой статье я не только наглядно объясню нелепые дилетантские ошибки, из-за которых приложение было взломано, но и расскажу, как это было сделано. Так что, если вы здесь не ради самого приложения, надеюсь, вы останетесь, чтобы увидеть процесс дизассемблирования.
Дизассемблирование приложения для Android
Чтобы получить исходный код приложения, заходим на его сайт teaforwomen.com. Там мы найдём ссылку на Google Play Store, которая приведёт нас к описанию приложения. В адресной строке мы увидим следующий URL-адрес.
https://play.google.com/store/apps/details?id=com.tea.tea
Нам нужен только идентификатор приложения — com.tea.tea. Это уникальный идентификатор приложения для Android. Поскольку мы хотим разобрать приложение на исходный код, нам понадобится APK- или XAPK-файл со всем содержимым, включая исходный код и файлы конфигурации. В этом нам поможет сайт Apkpure: https://apkpure.com/us/com.tea.tea.
После завершения загрузки XAPK-файла нам остаётся только изменить расширение файла с *.xapk на *.zip и распаковать zip-архив. В распакованной папке мы найдём APK-файлы для различных платформ. Мы просто дизассемблируем файл com.tea.tea.apk с помощью jadx, который можно установить на ваш Mac с помощью Homebrew.
jadx -d tea_disassembled com.tea.tea.apk
После завершения дизассемблирования jadx у нас будут все ресурсы и дизассемблированный код Java. Этого достаточно, чтобы понять, что делает это приложение, как оно было создано, и найти уязвимости в безопасности.
Взгляд на этот кошмар
Папка flutter_assets сразу выдаёт, что это приложение написано не на Java или Kotlin, а на Dart с использованием фреймворка Flutter. Неуклюжие названия ресурсов, как и многие из них, уже дают намёк на то, как мыслил тот, кто это собрал.
Помимо файла конфигурации .env в папке resources → assets → flutter_assets, он также содержит файл strings.xml в папке resources → res → values с другими строками конфигурации. Там мы найдём корзину, содержащую изображения водительских прав и ключи API, используемые для экспорта хранилища Firebase.
<string name="google_api_key">AIzaSyD-pAEklUMfUcbWxWrrDRBT0sRuMY2fGf0</string> <string name="google_app_id">1:457976296914:android:02fcec89504005d31b840b</string> <string name="google_crash_reporting_api_key">AIzaSyD-pAEklUMfUcbWxWrrDRBT0sRuMY2fGf0</string> <string name="google_storage_bucket">tea-the-app.appspot.com</string>
Наличие этого имени контейнера и ключа API в конфигурации приложения уже вызывает интерес хакеров и недоумение у опытных разработчиков. В файле конфигурации Flutter .env уже есть конечная точка API, чего должно быть достаточно.
apiUrl="https://api.teatheapp.com" # apiUrl="http://192.168.15.7:3333" # socketUrl="https://hermes.teatheapp.com"
Наличие конечной точки разработки (частный IP-адрес 192.168.15.7 на TCP-порту 3333) в развёрнутом продакшен приложении — ещё один признак подхода к разработке ПО с «нулевым уровнем безопасности». Обычно для загрузки водительских прав использовалась бы следующая практика: основной API предоставляет аутентифицированную ссылку на хранилище (bucket) с учетными данными в строке запроса. Срок действия этих учетных данных также был бы ограничен. Политика TTL (Time-To-Live), настроенная на этом хранилище, автоматически удаляла бы права по истечении определенного времени. Ничего из этого сделано не было.
# Example: This is how professionals do it. # Apple's AWS S3 bucket with the artwork of an album # in the Apple Music app returned with AWS S3 credentials https://store-033.blobstore.apple.com /sq-mq-us-033-000002/90/b0/5b/90b05bf2-f064-b872-bcd3-a8b14d04a3b2/image ?X-Amz-Algorithm=AWS4-HMAC-SHA256 &X-Amz-Date=20250801T135805Z &X-Amz-SignedHeaders=host &X-Amz-Expires=86400 &X-Amz-Credential=MKIAU00801%2Fstore-033%2Fs3%2Faws4_request &X-Amz-Signature=68934f0c6af79ae08815c0f2c28177ba399
Разработчики приложения Tea отказались от предупреждающих сообщений в Google Cloud и основных принципов минимального привилегированного доступа в облаке. Как ресурсы, так и структура приложения весьма красноречивы. Исходный код, структура и поведение приложения дают представление о замысле автора, подобно тому, как произведение искусства отражает замысел художника.
Заключение
Нет необходимости указывать какие-либо облачные контейнеры (AWS, Azure или Google) в файле конфигурации вашего приложения. Наличие их в файле конфигурации сразу же насторожит любого мало-мальски опытного разработчика. Flutter и Firebase — это системы, которые отлично и часто работают вместе. В целом, и с фреймворком, и с платформой всё в порядке. Ни одна из них не поощряет подобное.
После этого первоначального анализа я предполагаю, что это приложение было создано одним неопытным разработчиком или командой, работавшей под его руководством. Приложение, вероятно, не было результатом вайб-кодинга, поскольку ни одна из моделей последних месяцев не допустила бы столь очевидных ошибок. Изображения также не были созданы с помощью искусственного интеллекта, поскольку фотографии мужчин и женщин были взяты из профессиональных библиотек стоковых изображений, таких как iStock или Adobe Stock.
Этого «взлома» не должно было быть. Приложение Tea — не результат работы плохого ИИ, а вопиющая халатность разработчика, вероятно, одного, с очень небольшим опытом, которому нельзя было позволять публиковать такое приложение без надзора. Приложение не было «взломано», оно добровольно опубликовало конфиденциальную персональную информацию.
Google ни за что не должен был допускать публикацию этого приложения в Play Маркете. Сканирование безопасности Play Маркета должно было обнаружить публичный контейнер и ключи API в конфигурации приложения. Это не только плохо для десятков тысяч пострадавших женщин, это кошмар для всей индустрии программного обеспечения. Мы позволили публиковать программное обеспечение людям, чья неопытность представляет угрозу для общества. Я работаю в индустрии программного обеспечения более 20 лет, но такое снижение качества программного обеспечения было недопустимым в мои первые годы.
Будем надеяться, что ситуация изменится к лучшему, если публично указать на такие грубые нарушения стандартов разработки программного обеспечения и обсудить их.
Спасибо за прочтение.
-
Аналитика магазинов2 недели назад
Мобильный рынок Ближнего Востока: исследование Bidease и Sensor Tower выявляет драйверы роста
-
Интегрированные среды разработки3 недели назад
Chad: The Brainrot IDE — дикая среда разработки с играми и развлечениями
-
Новости4 недели назад
Видео и подкасты о мобильной разработке 2025.45
-
Новости3 недели назад
Видео и подкасты о мобильной разработке 2025.46




