Доступ ко всей файловой системе андроида

Залезаем во внутреннее хранилище Android M

В Android 6.0 ввели функцию, позволяющую отформатировать карту памяти так, чтобы она являлась не отдельным хранилищем, а придатком ко внутренней памяти. Это позволяет избежать путаницы с двумя хранилищами данных, особенно при ручной установке некоторых не всегда честно купленных крупных приложений, поставляемых по частям. Однако есть один нюанс: при этом всём нам наглухо блокируют доступ к карте напрямую. Хочешь что-то передать на устройство — используй MTP со всеми вытекающими, вроде скорости передачи файлов, сравнимой с прогулочным шагом контуженной черепахи. Карту теперь не только к ПК через кабель напрямую нельзя подключить: её и из выключенного телефона через кардридер просто так не смонтируешь, ведь она отформатирована в нечто неизвестное ни науке, ни нашим компьютерам.

Но ведь правила созданы для того, чтобы их нарушать? Давайте попробуем обойти это бессовестное ограничение.

Способ первый, простой: adb push/pull

Рекомендуется для ежедневного использования. Судя по всему, даже не требует рут. Всё, что понадобится — это ADB. Те, кто в курсе, могут пролистать до второго способа.

С передачей всё просто: первый аргумент — откуда, второй аргумент — куда. /sdcard — то место, куда на Андроиде монтируется доступное пользователю хранилище, т.е. корневой каталог штатного файлового менеджера почти любого девайса на Андроиде.

Основной плюс — двухсторонний обмен данными на вполне удовлетворительной скорости (если сравнивать с MTP). Также ко всей этой красоте прилагается симпатичный счетчик прогресса в процентах, который, к сожалению, отсюда не видно. Полагаю, что к графическому файловому менеджеру тоже можно как-то приделать нечто похожее, но на практике с такими плагинами сталкиваться не приходилось. Возможно, Android всё-таки не зря нас к карте не подпускает, ну да ладно, кто ж его спрашивает?

Способ второй, интересный: ручное монтирование зашифрованных разделов

На этот раз нам понадобятся root-доступ к смартфону и ПК с системой на базе Linux.

Для начала вытянем карту из девайса, подключим к ПК и сразу же посмотрим на её содержимое.

Отлично, хотя бы таблица разделов имеется.

Невооружённым взглядом видно, что филейная часть — это второй раздел с неопознанной файловой системой. Первый раздел прекрасно монтируется в fat32 и не менее прекрасно пуст, поэтому про него можно забыть, т.к. я не знаю, что на нём хранится у здоровых людей.

Вторая часть зловещего плана — ключ. Да-да, данные зашифрованы: не просто ж так parted не смог обнаружить на целевом разделе ФС. С ключом всё почти так же просто: хранится он на нашем Android-девайсе в двоичном файлике по адресу /data/misc/vold/expand_PARTUUID.key, где PARTUUID — это UUID шифрованного раздела в нижнем регистре без разделителей. Рут нам понадобится как раз для того, чтобы добраться до этого файла через нечитаемый для всех, кроме рута, каталог /data/misc/vold.

Готово. 128 бит заветной информации.

Заключительная часть Мерлезонского балета — подключение раздела. Сделаем это стандартным линуксовским dm-crypt, который, собственно, и самим Андроидом используется.

К сожалению, я не знаю, какой именно метод шифрования используется Андроидом, поэтому понадеюсь на пресвятой дефолт, оставив —cipher неуказанным.

На меня не ругаются, это хорошо. Монтируем.

Кажется, получилось. Неопознанные UID-ы напоминают нам о том, что карточка не с нашего ПК и лучше бы нам здесь особо ничего не ворошить.

Если поковыряться по каталогам, можно увидеть данные приложений, хранящихся на карте памяти, а также непосредственно содержимое SD-карты, которое нам подсовывали в первом способе по адресу /sdcard. Его мы можем найти в каталоге /mnt/media/0.

Источник

Права доступа (permission) в Android

вкл. 26 Сентябрь 2013 . Опубликовано в Статьи

Одним из интереснейших методов безопасности операционной системы Андроид является система разрешений (permissions), используемых приложениями. Когда OS ANDROID только появилась, её разработчики придумали – выделить все возможные функции, доступ к которым необходим приложению, и позволить пользователю их контролировать. Было это реализовано довольно интересно. Список возможных разрешений создан разработчиками Google и зафиксирован в документации. Он очень гибкий, в нем есть всё, что нужно для обеспечения какого угодно сложного функционала. Вместе с тем он грамотно разграничен.

Например, если программа работает с СМС, то ему можно дать права только на чтение сообщений, или только на их отправку, или только на уведомление о событии, которое связано с СМС. Это разграничение очень хорошо позволяет избегать злоупотребления привилегиями со стороны приложений. Ещё во время создания программы разработчик выделяет все функции, которые потребуются его программе. Этот список прописывается в файле AndroidManifest.xml, который на этапе сборки программы помещается в его APK-файл. Когда пользователь Андроид устройства будет устанавливать очередное приложение, то вышеупомянутый список, заданный его создателем, будет отображаться на экране. И только после того, как пользователь согласится дать все эти права устанавливаемому приложению, оно будет установлено. Считается, что именно на этом этапе большинство пользователей избежит вирусов, заподозрив программу в плохом поведении и отклонив установку.

С технической точки зрения, обойти существующий механизм прав доступа приложений к функциональности системы Андроид очень непросто. Так как менеджмент разрешений осуществляется на самом низком уровне ядром Linux, программе обязательно нужны права рут, чтобы повлиять на это. Хорошо формализованная система permissions облегчает реализацию инструментов безопасности сторонними разработчиками. Перспективным направлением является создание программ, которые позволяют пользователям тонко настраивать права доступа каждого отдельного приложения, предотвращая любые утечки информации с устройства.

Права доступа (permission) на папки и файлы в Андроид

Права доступа разделяются на две группы зто:
1.Права доступа к файлам
2.Права доступа к папке (директории)

Права доступа к файлам могут иметь такие атрибуты:
r — право на чтение данных. (read)
w — право на изменение содержимого или запись, но не удаление. (write)
x — право на исполнение файла. (xxxxxx)

Права доступа к папке (директории):
r — право на чтение папки (директории).
w — право на изменение содержимого директории можно создавать и удалять объекты в этой директории.
x — право, которое позволяет вам войти в директорию.

Сами права доступа подразделяются на три категории:
«user» — u владелец файла.
«group» — g член той же группы, к которой принадлежит владелец.
«world» — o все остальные.

Порядок записи прав доступа:
сначала права для владельца — «u»
затем для группы — «g»
и в конце права для всех остальных — «o»

Например: предположим что у вас на работе есть компьютер, вы его владелец, он состоит в локальной сети (группа) а есть пользователи, которые хотят что либо на вашем компьютере сделать. По всем этим категориям задаются права на файлы и папки в виде RWX которые дают какие либо права на выполнение чего либо, если в заданных правах RWX присутствует знак «-» то это означает что право отсутствует.
Например: rwx r— r— означает что владелец файла имеет все права: право на чтение, запись в него и исполнение, а все остальные пользователи только право на чтение.

Помимо буквенных выражений есть числовые выражения:
r — (читать) это 4
w (запись) это 2
x (исполнение) это 1
«—» ничего не делать тоесть знак дефиса, 0
И их сумма означает конечные права
7 (rwx) = 4 + 2 +1 (полные права)
5 (r-x)= 4 + 0 + 1 (чтение и выполнение)
6 (rw-) = 4 + 2 + 0 (чтение и запись)
4 (r—) =4 + 0 + 0 (только чтение)

Часто используемые параметры:
400 (-r———) — владелец будет иметь право чтения, никто кроме него не имеет права выполнять никакие действия.
644 (-rw-r—r—) — все пользователи имеют право чтения, а владелец может редактировать.
660 (-rw-rw—-) — владелец и группа могут читать и редактировать, все остальные не имеют никаких прав.
664 (-rw-rw-r—) — все пользователи имеют право чтения, а владелец и группа могут редактировать.
666 (-rw-rw-rw-) — все пользователи могут читать и редактировать.
700 (-rwx——) — владелец может читать, записывать и запускать на выполнение, у других нет права выполнять никакие действия.
744 (-rwxr—r—) — все пользователи могут читать, а владелец имеет право редактировать и запускать на выполнение.
755 (-rwxr-xr-x) — каждый пользователь может читать и запускать на выполнение, владелец может редактировать.
777 (-rwxrwxrwx) — каждый пользователь может читать, редактировать и запускать на выполнение.
sudo passwd root — пароль суперпользователя root.

Здесь представлен онлайн калькулятор , и программа которая может задавать права на файл Root Explorer
Бывает что права состоят из 4х цифр это означает что помимо владельца, группы, остальных есть еще и SUPERUser (Супер Админ)
тогда список будет выглядеть вот так:
«SuperUser» — SuperUser
«user» — u владелец файла
«group» — g член той же группы, к которой принадлежит владелец
«world» — o все остальные

Источник

Обновления в Android 11: Scoped Storage и другие улучшения конфиденциальности

Nov 11, 2020 · 8 min read

Все последние улучшения в Android на уровне ОС касаются защиты приложений и пользовательских данных, а также более упорядоченного предоставления доступа. Несмотря на преимущества изменений, они также предполагают дополнительную работу для разработчиков.

В целях повышения конфиденциальности пользователей Android 11 добавлены некоторые существенные изменения и ограничения. Как указано в превью поведенческих изменений, они состоят в следующем:

Принудительное использование хранилища с ограниченной областью видимости (Scoped storage) : доступ к каталогам внешних хранилищ ограничен каталогом конкретного приложения и определенными типами носителей, созданных приложением.

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

Фоновый доступ к местоположению : пользователи должны быть направлены в системные настройки, чтобы предоставить приложениям разрешение на фоновое определение местоположения.

Видимость пакета : когда приложение запрашивает список установленных приложений на устройстве, возвращенный список фильтруется.

Недавно я глубоко погрузился в концепцию Scoped storage, чтобы понять, чего ожидать в будущем, и соответственно подготовить свое Android-приложение к переменам.

Структура хранилища (до Android 10)

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

• Частное хранилище (Private Storage): все приложения имеют собственный частный каталог во внутреннем хранилище, то есть Android/data/<имя пакета>, невидимый для других приложений.
• Общее хранилище (Shared Storage): остальная часть хранилища, помимо частных разделов, называлась общим хранилищем. Оно включает в себя все медиа- и немедийные файлы, сохраненные в системе, и приложение с разрешением на хранение может легко получить к ним доступ.

Проблемы с текущим состоянием структуры и доступа

Есть ли , на ваш взгляд, какие-то проблемы в структуре, которую мы рассмотрели выше? Не хотелось ли вам, чтобы Google что-нибудь здесь изменил?

Давайте подробнее остановимся на некоторых проблемах.

• Допустим, у нас приложение для электронной коммерции, которому нужен доступ к хранилищу только для того, чтобы пользователь смог загрузить фото профиля. Значит, ему нужно предоставить доступ к определенному файлу или файловой системе. Другой пример: нам нужно загрузить или сохранить медиа-файл из чат-приложения, а для этого нужен доступ к одному медиа-файлу. Так зачем же предоставлять доступ к хранилищу целиком?
• Может оказаться так, что конфиденциальные данные, такие как медицинские рецепты или банковские чеки, будут доступны всем приложениям, установленным на устройстве.
• После удаления приложения нет возможности убедиться, что все связанные с ним данные и файлы полностью очищены.

Уверен, это должно заставить вас задуматься о безопасности приложений и данных, а также о конфиденциальности и организации. Не волнуйтесь, недавнее обновление Google для Android уже спешит на помощь.

Хранилище с ограниченной областью видимости

Google приводит две веские причины, по которым вводится это изменение: безопасность и уменьшение оставшихся после удаления приложений данных.

Песочница приложений, изолирующая приложения друг от друга, — это ключевая часть дизайна Android. Взяв за основу все тот же самый основополагающий принцип, в Android Q компания Google представила хранилище с ограниченной областью видимости.

Эти изменения первоначально планировалось применить к каждому приложению на телефоне под управлением Android 10 или более поздней версии, но из-за негативной реакции разработчиков Google изменил курс и потребовал использовать хранилище с ограниченной областью видимости только для приложений, ориентированных на Android API уровня 29, то есть Android 10. Но с Android 11 Scoped Storage вернулся, и на сей раз Google вряд ли передумает.

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

Посмотрите на структуру хранения данных в Android 10 и выше:

Частное хранилище остается без изменений, но общее хранилище дополнительно делится на коллекцию медиа и загрузок (немедийных файлов).

• Уменьшение беспорядка в файлах: система свяжет хранилище с приложениями-владельцами, чтобы системе было легче находить файлы, относящиеся к приложению. Таким образом, при удалении приложения все связанные с ним данные также будут удалены.
• Предотвращение злоупотребления разрешением READ_EXTERNAL_STORAGE: предоставление этого разрешения на сегодняшний день дает приложению доступ ко всему внешнему хранилищу, где хранятся личные фотографии, документы, видео и другие потенциально конфиденциальные файлы. Однако при применении Scoped storage приложения смогут видеть только собственные папки данных и определенные типы носителей, такие как музыкальные файлы, используя другие API хранилища.

С этими обновлениями пользователи смогут лучше контролировать файлы и предоставление к ним доступа. Кроме того, на устройстве освободится дополнительное пространство, так как ненужные файлы будут удаляться вместе с приложением.

Изменения в разрешениях доступа к файлам

• Неограниченный доступ к индивидуальному хранилищу приложений: приложение будет иметь неограниченный доступ к внутреннему и внешнему хранилищу как для чтения, так и для записи. В Android 10 не нужно предоставлять разрешение на хранение для записи файлов в каталог приложений на SD-карте.
• Неограниченный доступ к коллекциям медиафайлов и загрузок (добавленным собственноручно): вы получаете неограниченный доступ для добавления файлов в коллекции и загрузки приложения. При сохранении изображения, видео или любого другого медиафайла из коллекции не нужно запрашивать разрешение (если файл хранится в организованной коллекции.)
• Доступ к коллекции медиафайлов других приложений можно получить с помощью разрешения READ_STORAGE_PERMISSION. Разрешение WRITE_STORAGE_PERMISSION со следующей версии станет устаревшим и будет работать так же, как READ_STORAGE_PERMISSION.
• Для записи и чтения немедийных файлов, добавляемых другими приложениями, понадобятся API-интерфейсы доступа к хранилищу.

Примечание из документации по обновлению хранилища в Android 11: Если приложение использует устаревшую модель хранения и ранее предназначалось для Android 10 или ниже, возможно, его данные сохраняются в каталоге, к которому приложение не может получить доступ, когда задействована модель хранилища с областью видимости. Прежде чем перейти на Android 11, перенесите данные в каталог, совместимый с хранилищем ограниченной области видимости. В большинстве случаев перенести данные можно в каталог конкретного приложения.

Отказ от изменений для приложений на Android 10 и выше

Чтобы дать разработчикам дополнительное время для тестирования, приложения, ориентированные на Android 10 (уровень API 29), все еще могут запрашивать атрибут requestLegacyExternalStorage. Этот флаг позволяет приложениям временно отказаться от изменений, связанных с областью хранения, таких как предоставление доступа к различным каталогам и различным типам медиафайлов.

Любое приложение, предназначенное для Android 11 или более поздней версии, должно использовать новые API хранилища, включая хранилище с ограниченной областью видимости. Изменения в соглашении разработчика Google Play гласят, что, начиная с 1 августа 2020 года, все новые приложения, представленные в Google Play, должны быть нацелены на Android 10 или более позднюю версию, а все обновления существующих приложений должны быть ориентированы на Android 10 или более позднюю версию с 1 ноября 2020 года. Если все продолжится в том же духе, то в следующем году приложения, скорее всего, будет обязательно ориентировать уже на Android 11.

Сейчас самое подходящее время для того, чтобы изучить и реализовать новые изменения.

Операции хранения

Кратко рассмотрим некоторые часто выполняемые операции хранения и способы их выполнения:

• Выбор файла: используйте ACTION_OPEN_DOCUMENT — он открывает системное приложение для выбора файлов, предоставляя пользователю возможность выбрал файл, который нужно открыть. Чтобы отобразить только те типы файлов, которые поддерживаются приложением, укажите тип MIME.

• Выбор папки: Интент ACTION_OPEN_DOCUMENT можно заменить на ACTION_OPEN_DOCUMENT_TREE .

Примечание: этот доступ будет действителен до тех пор, пока пользователь не перезагрузит устройство. Если приложение хочет сохранить доступ, получая доступ к URI с помощью преобразователя содержимого, преобразователь содержимого должен вызвать метод takePersistableUriPermission .

Кроме того, если вы перебираете большое количество файлов в каталоге, доступ к которому осуществляется с помощью ACTION_OPEN_DOCUMENT_TREE , производительность приложения может снизиться.

• Создание файла: чтобы сохранить файл в определенном месте, используйте ACTION_CREATE_DOCUMENT .

Примечание из документации разработчиков Android: ACTION_CREATE_DOCUMENT не может перезаписать существующий файл. Если приложение пытается сохранить файл с тем же именем, система добавляет число в скобках в конце имени файла.

Разрешение на определение локации медиа-файлов

Если приложение предназначено для Android 10 (уровень API 29) или выше, то для того, чтобы оно могло извлекать неотредактированные метаданные Exif из фотографий, необходимо объявить разрешение ACCESS_MEDIA_LOCATION в манифесте приложения, а затем запросить это разрешение во время выполнения.

Внимание: поскольку вы запрашиваете разрешение ACCESS_MEDIA_LOCATION во время выполнения, нет никакой гарантии, что приложение имеет доступ к неотредактированным метаданным Exif из фотографий. Приложение требует явного согласия пользователя, чтобы получить доступ к этой информации.

Приложения-менеджеры файлов

Существует обходной путь для приложений по типу файловых менеджеров, которые тоже должны иметь полный доступ ко всему. Нужно выполнить следующие простые шаги, перечисленные в инструкции по обновлению хранилища в Android 11:

Чтобы приложение запрашивало у пользователя “доступ ко всем файлам”, нужно выполнить следующие действия:
1. Объявить разрешение MANAGE_EXTERNAL_STORAGE в манифесте.
2. С помощью действия ACTION_MANAGE_ALL_FILES_ACCESS_PERMISSION направить пользователей на страницу системных настроек, где они могут включить следующую опцию: “Разрешить доступ для управления всеми файлами”.

Приложениям, действующим по закону, эти разрешения необходимы.

Как только пользователь предоставит разрешение на широкий доступ, он получит нефильтрованное представление MediaStore, которое включает в себя немедийные файлы.

Только приложения, которым Google предоставит такую возможность, будут иметь полный доступ к хранилищу. Для этого отправьте форму декларации в Google Play и получите место в утвержденном списке.

Приложения с кастомным средством выбора файлов

Что делать, если приложение задействует кастомный выбор файлов, который отображает точные каталоги данных? В этом случае ничего нельзя сделать. Возможно, стоит перейти на системное средство выбора файлов.

Что нужно помнить во время реализации

1. Не используйте статический путь. Заблокируйте доступ к пути к файлу.
2. Используйте медиахранилище (рекомендуется).
3. Медиахранилище следует использовать правильно. Например, не помещайте музыкальные файлы в каталог изображений.
4. Немедийные файлы должны находиться в каталоге загрузки (рекомендуется).
5. Чтобы предоставить другим приложениям доступ к немедийным файлам, воспользуйтесь системным выбором файлов вместе с SAF (storage access framework). Для полного доступа к этому приложению будет запрошено разрешение среды выполнения.

При реализации можно воспользоваться примером на Github.

Источник