Intereting Posts

Программно изменить Manifest – пользовательские разрешения для Android

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

Приложение А определяет пользовательское разрешение:

com.package.permission.READ_APP_DATA 

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

Однако, если приложение A установлено после приложения B, тогда разрешение не предоставляется приложению B.

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

С приложениями SuperUser, соглашающимися ввести глобальное пользовательское разрешение android.permission.ACCESS_SUPERUSER это может быть большой проблемой, если пользователь решит переключить приложение 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?

Solutions Collecting From Web of "Программно изменить Manifest – пользовательские разрешения для Android"

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

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

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

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

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

ОБНОВИТЬ

Разумеется, я могу разработать немного больше. Я вижу два сценария

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

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

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

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

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

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