Я не силен в мобильной разработке. Но скормил Ваш клиент чатужпт, чтобы провести аудит. Вот его ответ:
Конфиги с секретами сохраняются в plaintext в SharedPreferences. В сериализацию попадают uuid, password, publicKey, shortId и даже rawUri, то есть фактически полный импортированный URI. Подписки тоже сохраняют URL целиком. См. /tmp/ teapod‑stream/lib/core/models/vpn_config.dart:99, /tmp/teapod‑stream/lib/core/models/vpn_config.dart:120, /tmp/teapod‑ stream/lib/core/models/vpn_config.dart:122, /tmp/teapod‑stream/lib/core/services/config_storage_service.dart:64, /tmp/ teapod‑stream/lib/core/services/config_storage_service.dart:117, /tmp/teapod‑stream/lib/core/services/ config_storage_service.dart:121.
Поверх этого в AndroidManifest не отключён backup/export rules. Там нет ни android:allowBackup=«false», ни явных dataExtractionRules. Для обычного пользователя это не мгновенная межприложная утечка, но для high‑risk сценария это плохая гигиена хранения секретов. См. /tmp/teapod‑stream/android/app/src/main/AndroidManifest.xml:11.
Клиент действительно генерирует случайные SOCKS‑логин/пароль и порт, это хороший ход. Но затем сервис логирует полный запуск tun2socks, включая строку вида socks5://user:password@127.0.0.1:port, в logcat. То есть секреты, которые только что защитили localhost‑прокси, тут же утекли в системный лог. См. /tmp/teapod‑stream/lib/providers/vpn_provider.dart: 96, /tmp/teapod‑stream/lib/providers/vpn_provider.dart:103, /tmp/teapod‑stream/lib/protocols/xray/xray_config_builder.dart:20, /tmp/teapod‑stream/android/app/src/main/kotlin/com/teapodstream/teapodstream/XrayVpnService.kt:234, /tmp/te apod‑stream/android/app/src/main/kotlin/com/teapodstream/teapodstream/XrayVpnService.kt:249, /tmp/teapod‑stream/andro id/app/src/main/kotlin/com/teapodstream/teapodstream/XrayVpnService.kt:430.
README обещает больше, чем реально реализовано. Заявлены Trojan, Shadowsocks, H2, QUIC, но builder по факту собирает полноценные outbound‑настройки только для VLESS и VMess; для остальных протоколов возвращается пустой settings‑блок, а supportsConfig() всё равно отвечает true. Это не прямая уязвимость, но плохой сигнал по зрелости и может дать ложное ощущение «всё поддерживается». См. /tmp/teapod‑stream/README.md:7, /tmp/teapod‑stream/README.md:8, /tmp/teapod‑stream/ lib/protocols/xray/xray_config_builder.dart:124, /tmp/teapod‑stream/lib/protocols/xray/xray_config_builder.dart:150, / tmp/teapod‑stream/lib/protocols/xray/xray_engine.dart:230.
Допускаю, что ИИ мог нафантазировать. И свою безграмотность в этом вопросе тоже беру в расчет. Но если я правильно понял - Вы сами несколько раз в открытом виде кладете секреты
"Платно" там только одна функция вроде - удаленное управление репой. И то дает это бесплатно сделать, если подождать 10 секунд.
Я не силен в мобильной разработке. Но скормил Ваш клиент чатужпт, чтобы провести аудит. Вот его ответ:
Конфиги с секретами сохраняются в plaintext в SharedPreferences. В сериализацию попадают uuid, password, publicKey, shortId и даже rawUri, то есть фактически полный импортированный URI. Подписки тоже сохраняют URL целиком. См. /tmp/ teapod‑stream/lib/core/models/vpn_config.dart:99, /tmp/teapod‑stream/lib/core/models/vpn_config.dart:120, /tmp/teapod‑ stream/lib/core/models/vpn_config.dart:122, /tmp/teapod‑stream/lib/core/services/config_storage_service.dart:64, /tmp/ teapod‑stream/lib/core/services/config_storage_service.dart:117, /tmp/teapod‑stream/lib/core/services/ config_storage_service.dart:121.
Поверх этого в AndroidManifest не отключён backup/export rules. Там нет ни android:allowBackup=«false», ни явных dataExtractionRules. Для обычного пользователя это не мгновенная межприложная утечка, но для high‑risk сценария это плохая гигиена хранения секретов. См. /tmp/teapod‑stream/android/app/src/main/AndroidManifest.xml:11.
Клиент действительно генерирует случайные SOCKS‑логин/пароль и порт, это хороший ход. Но затем сервис логирует полный запуск tun2socks, включая строку вида socks5://user:password@127.0.0.1:port, в logcat. То есть секреты, которые только что защитили localhost‑прокси, тут же утекли в системный лог. См. /tmp/teapod‑stream/lib/providers/vpn_provider.dart: 96, /tmp/teapod‑stream/lib/providers/vpn_provider.dart:103, /tmp/teapod‑stream/lib/protocols/xray/xray_config_builder.dart:20, /tmp/teapod‑stream/android/app/src/main/kotlin/com/teapodstream/teapodstream/XrayVpnService.kt:234, /tmp/te apod‑stream/android/app/src/main/kotlin/com/teapodstream/teapodstream/XrayVpnService.kt:249, /tmp/teapod‑stream/andro id/app/src/main/kotlin/com/teapodstream/teapodstream/XrayVpnService.kt:430.
README обещает больше, чем реально реализовано. Заявлены Trojan, Shadowsocks, H2, QUIC, но builder по факту собирает полноценные outbound‑настройки только для VLESS и VMess; для остальных протоколов возвращается пустой settings‑блок, а supportsConfig() всё равно отвечает true. Это не прямая уязвимость, но плохой сигнал по зрелости и может дать ложное ощущение «всё поддерживается». См. /tmp/teapod‑stream/README.md:7, /tmp/teapod‑stream/README.md:8, /tmp/teapod‑stream/ lib/protocols/xray/xray_config_builder.dart:124, /tmp/teapod‑stream/lib/protocols/xray/xray_config_builder.dart:150, / tmp/teapod‑stream/lib/protocols/xray/xray_engine.dart:230.
Допускаю, что ИИ мог нафантазировать. И свою безграмотность в этом вопросе тоже беру в расчет. Но если я правильно понял - Вы сами несколько раз в открытом виде кладете секреты
Аналогия не является аргументом в споре. Особенно, если она некорректная.
Спасибо, почитал с интересом
Што, опять?
Вы имеете ввиду платную его версию?