Программно изменить Манифест-пользовательские разрешения Android

текущего система разрешений Android вызывает следующую проблему:

App a определяет пользовательское разрешение:

com.package.permission.READ_APP_DATA

когда приложение B установлено, объявляя пользовательское разрешение, оно предоставляется.

однако, если приложение a установлено после app B, то разрешение не предоставлен в приложении Б.

хотя это не может быть обычным явлением, из-за того, что приложение B часто является плагином приложения A, это конечно может произойти и делает для моего приложения.

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

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

checkPermissions(this, getCallingActivity().getPackageName()); // get the package name from the sender first

private boolean checkPermissions(Context context, String callingPackage) {

    final List<PackageInfo> apps = context.getPackageManager().getInstalledPackages(PackageManager.GET_PERMISSIONS);

    for (PackageInfo pi : apps) {

        if (pi.packageName.equals(callingPackage)) {

            String[] permissions = pi.requestedPermissions;

            if (permissions != null) {
                for (String permission : permissions) {
                    if (permission.equals("com.package.permission.READ_APP_DATA")) {
                        return true;
                    }
                }
            }
        }
    }
    return false;

В соответствии с названием этого вопроса: Является ли этот метод "безопасным"? Или есть способ / root-hack, что манифест приложения может быть изменен после его установки и разрешения программно "добавлен" в приложение B?

11
android android-manifest permissions

2 ответов

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

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

Итак, то, что мы использовали в моде, изменяет метод grantPermissionsLPw в классе com.android.server.pm.PackageManagerService.

он используется для предоставления пусковой установки разрешения android.permission.EXPAND_STATUS_BAR, который он не объявил в своем манифесте.

Я не уверен, если это когда-либо будет использоваться для вашего приложения. Но подводя итог: если пользователь хочет предоставить приложению арбитраж, пользовательское разрешение: Да, это возможно.

обновление

Я могу уточнить немного больше, конечно. Я вижу, что происходит два сценария

1. Статический мод

вышеупомянутый класс находится в services.jar. Как мы знаем, такие файлы могут быть декомпилированы, изменены и перекомпилированы. На самом деле, это довольно простое редактирование этого файла. Я не знаю, как это сделать по телефону напрямую, но я бы счел это возможным. Это просто не так возможно, что широко распространенные решения доступны, так как для этого требуется хорошее количество вычислительной мощности. Злоумышленник не может просто предоставить универсальный файл. Эти файлы меняются с устройства на устройство, а также между версиями прошивки. Либо злоумышленнику потребуется предоставить огромное количество исправленных файлов, либо выполнить исправление в реальном времени, загрузив его на сервер, исправив, повторно загрузив и установив. На мой взгляд, такой сценарий маловероятен.

2. динамический мод

есть несколько доступных механизмов, которые позволяют процессы изменения, пока они opertae. Наиболее популярным из них является Экспоузд Framework. В основном, это заплатанный app_process и соответствующий API, который использует Reflection для изменения запущенных процессов. Теперь злоумышленник может отправить свое приложение с этой платформой и, имея корневой доступ, установить его молча. С доступом root он может даже включить модуль самостоятельно, что обычно требует взаимодействия с пользователем. После включения такого модуля злоумышленник может подключиться к вышеупомянутому методу и изменить запрошенные разрешения. Он будет делать это, получая поле объекта, который содержит запрошенные разрешения, добавьте тот, который требуется, затем запустите исходный метод, который добавляет первоначально определенные разрешения.

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

9

Я вижу проблему, где, если приложение A установлено перед приложением B и <permission> элемент не объявлен в приложении A, пользователь никогда не увидит запрос разрешения. Если вам требуется использование <permission> элемент в приложении A, однако, аналогичный подход может быть использован для проверки точности метки и описания, показанного пользователю.

0