>>47852

> Неофициальное

Я ебал этот говняк. Прочекал слоп через нейронку

Вот что ответил:

Да. Я проверил именно этот репозиторий, а не просто название проекта.

Короткий вывод: по тому, что видно в исходниках сейчас, я не вижу признаков банковского трояна или механизма кражи денег. Но назвать приложение «100% безопасным» только по GitHub нельзя — особенно потому, что это неофициальный форк, у него мало публичной репутационной истории (9 звёзд, 0 форков), а APK подписывается ключом разработчика.
G
GitHub

Что меня насторожило

В AndroidManifest.xml приложение запрашивает:

INTERNET — естественно для imageboard-клиента;
WAKE_LOCK;
сетевой статус;
уведомления;
foreground services;
REQUEST_INSTALL_PACKAGES — разрешение на запрос установки APK;
REQUEST_DELETE_PACKAGES — запрос удаления пакетов;
WRITE_EXTERNAL_STORAGE только для очень старых Android.
G
GitHub

Последние два выглядят страшно, но в контексте проекта они, судя по структуре, связаны с встроенным обновлением приложения. В README прямо указано, что приложение имеет beta/stable каналы обновлений и может скачивать APK с возобновлением загрузки.
G
GitHub

При этом я не обнаружил в Manifest разрешений, которые были бы особенно характерны для банковского вредоноса: SMS, контакты, камера, микрофон, Accessibility Service, VPN, Device Admin и т. п. Это хороший знак.
G
GitHub

Может ли оно украсть данные из PrivatBank?

Напрямую — по имеющимся данным, это выглядит маловероятно.

Например, для классической схемы банковского трояна обычно нужны возможности вроде:

читать SMS с кодами подтверждения;
видеть содержимое других приложений;
перехватывать ввод через Accessibility;
показывать фальшивое окно поверх банковского приложения;
получать уведомления;
управлять экраном/нажатиями.

В манифесте этого набора разрешений я не вижу.
G
GitHub

Поэтому ситуация типа «установил Dashchan → оно само открыло Privat24/PrivatBank и украло пароль/деньги» не выглядит реалистичной на основании проверенной части проекта.

Но есть важный нюанс

В приложении разрешён:

android:usesCleartextTraffic="true"

То есть приложение разрешает незашифрованный HTTP-трафик.
G
GitHub

Для imageboard-клиента это объяснимо: он работает с множеством сторонних форумов/архивов, некоторые из которых могут использовать HTTP. Но с точки зрения безопасности это означает, что я бы не стал вводить в этом приложении никакие чувствительные данные.

Особенно важно: README говорит, что приложение умеет работать с Passcode Двача.
G
GitHub
Это не банковский пароль, но такой пароль тоже не стоит повторно использовать где-либо ещё.

Что я бы сделал на твоём месте

Если ты хочешь установить именно этот APK, я бы не устанавливал случайный APK из Telegram/сайта/файлообменника. Сам репозиторий говорит, что стабильные APK должны публиковаться только в GitHub Releases и рекомендует файл all-abi-signed.apk.
G
GitHub

Оригинальный репозиторий Dashchan_2

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

Если хочешь, я могу сделать гораздо более глубокую проверку: пройтись по исходникам этого репозитория и найти все внешние домены/IP, куда приложение может отправлять данные, все места работы с паролями/cookie/token, WebView, updater и сетевой код, а затем отдельно проверить, может ли оно технически получить доступ к данным Privat24/банковским приложениям. Это будет намного надёжнее простого просмотра Manifest.

>>48012
прогнал кими3 по состоянию на релиз 3.2.15

Этап 2. Исправление сохранения в рабочем профиле
2.1. MainActivity.showStorageInstructionsDialog()
Убрать или сделать безопасным EXTRA_INITIAL_URI. Варианты:
Вариант А (минимальный): не задавать EXTRA_INITIAL_URI, чтобы система сама предложила доступные root'ы в текущем профиле.
Вариант Б (рекомендуемый): определять рабочий профиль и подставлять корректный initial URI:
UserManager userManager = (UserManager) getSystemService(Context.USER_SERVICE);
boolean isManagedProfile = userManager.isManagedProfile();
Uri initialUri = isManagedProfile
? DocumentsContract.buildRootUri("com.android.externalstorage.documents", "primary")
: DocumentsContract.buildRootUri("com.android.externalstorage.documents", "primary");
// Для work profile лучше не фиксировать root, а оставить picker без EXTRA_INITIAL_URI
2.2. Preferences.setDownloadUriTree()
Улучшить обработку:
- Проверять, что uriFlags содержит FLAG_GRANT_WRITE_URI_PERMISSION.
- Для work profile проверять, что authority не com.android.providers.downloads.documents.
- Если takePersistableUriPermission() бросает SecurityException — показывать понятную ошибку.
2.3. DataFile.SafFile.openOutputStream()
Добавить информативные сообщения об ошибках:
- Если DocumentsContract.createDocument() возвращает null — чётко сообщить, что нет прав на запись.
- Если пойман SecurityException — показать R.string.no_access_to_memory с пояснением.
2.4. Диалог выбора пути (DownloadDialog)
Возможно, в рабочем профиле стоит скрыть legacy-режим "общей папки" и всегда использовать SAF-дерево.

Андрей сделай для меня кастомный билд 15 с фиксом сохранения.
Я сам не хочу ебаться с билдом у меня комукдахтера нет

>>48048
прогнал кими по мастеру

Результат проверки мастер-ветки
Проблема с сохранением в рабочем профиле в мастере исправлена частично, но не полностью.
Что изменилось в мастере (версии 3.2.17–3.2.21)
1. Preferences.getDownloadUriTree() — теперь хранит выбранный URI в SharedPreferences (KEY_DOWNLOAD_URI_TREE) и проверяет:
- есть ли persistable permission;
- доступно ли дерево через ContentResolver.query;
- не является ли URI архивным.
2. Preferences.setDownloadUriTree() — улучшена обработка:
- takePersistableUriPermission() теперь в try/catch с показом R.string.no_access_to_memory;
- URI сохраняется в SharedPreferences;
- сторонние (не архивные) разрешения освобождаются только после успешного сохранения нового.
3. Добавлен начальный диалог настройки папки загрузок (showInitialStorageSetupDialog()), который вызывает startStorageDirectoryPicker().
Что НЕ исправлено в мастере
Критично: в MainActivity.startStorageDirectoryPicker() (мастер) всё ещё используется тот же код:
Intent intent = new Intent(Intent.ACTION_OPEN_DOCUMENT_TREE)
.putExtra("android.provider.extra.SHOW_ADVANCED", true)
.putExtra("android.content.extra.SHOW_ADVANCED", true)
.putExtra(Intent.EXTRA_LOCAL_ONLY, true);
intent.putExtra(DocumentsContract.EXTRA_INITIAL_URI, DocumentsContract
.buildRootUri("com.android.externalstorage.documents", "primary"));
То есть EXTRA_INITIAL_URI всё ещё жёстко указывает на "primary", что в рабочем профиле может не открывать правильное хранилище или DocumentsUI отказывается давать write-доступ.
Вывод
- Если причина была в том, что URI не сохранялся/терялся — мастер это исправил.
- Если причина в том, что picker изначально открывается не на тот root и не даёт выбрать/записать в рабочий профиль — мастер это не исправил.

вообщем жду фиксов в гитхабе

По поводу "бэкдора/вируса" в форке — без срача, по фактам. Кто хочет,
перепроверит сам.

1. ЧТО РЕАЛЬНО ШЛЁТСЯ.
Приложение отправляет на свой бэкенд слепок устройства: случайный uuid
(генерится на телефоне, сбрасывается очисткой данных), модель, бренд,
build fingerprint, язык. Часть полей вообще захардкожена-фейковая:
os_version всегда "13", timezone всегда "Europe/Moscow", is_physical
всегда true. Это ровно те Java-классы, что вы сами кидали, — там нет
ничего сверх этого.

2. ЧТО НЕ ШЛЁТСЯ.
Пароли, куки других приложений, контакты, СМС/звонки, GPS/геолокация,
файлы, буфер обмена, список приложений, рекламные id. Ничего этого код не
читает и не отправляет.

3. ПОЧЕМУ ЭТО НЕ БЭКДОР.
Слепок нужен, чтобы получить токен антикапчи. Это attestation-паттерн —
та же схема, что у Google Play Integrity: клиент шлёт признаки устройства
на сервер, сервер решает, выдать ли токен. Бэкдор по определению — это
скрытый доступ ВНУТРЬ твоего устройства без спроса. Тут наоборот: наружу
уходит описание девайса, доступ внутрь никто не получает. Это телеметрия,
вопрос приватности — не "троян" и не "вирус". VT 1/50 — ложное
срабатывание на нативную либу.

4. ПРО GPL.
Претензия по сути честная: раз бета раздавалась как APK, её исходники по
GPLv3 §6 должны быть доступны. Уточнение по самой лицензии: она обязывает
отдать сорцы ТЕМ, КТО ПОЛУЧИЛ БИНАРЬ (по запросу), а не публиковать их
всему миру — публикация в паблик это лишь один из способов, а не
требование. Сорцы беты будут предоставлены как положено; кто хочет
проверить размер 42 -> 87 МБ — это добавленные нативные библиотеки, они
станут проверяемы по коду.

5. F-Droid.
Туда идёт только стабильная сборка (assembleFdroidRelease), в ней
самообновление и бета-канал отключены на этапе компиляции. Бету F-Droid
не раздаёт и раздать не может.

Всё. Политику, национальности и личности сюда не тащу. Хотите проверить —
проверяйте код, для того его и открывают.