Android shareduserid android uid system

Русские Блоги

Об использовании android: sharedUserId = «android.uid.system»

Иногда нам нужно использовать некоторые системные разрешения в наших приложениях, такие как разрешения USB. Если процесс нашего собственного приложения и системный процесс имеют одинаковый UID, у нас будет это разрешение по умолчанию, и его не нужно предоставлять пользователю. Во многих случаях Так будет намного удобнее. Это разрешение используется в большинстве проектов, над которыми я недавно работал. Измените системное время, вызовите скрытый метод, выключите и перезапустите систему, установите, обновите и удалите приложения в автоматическом режиме и т. Д. Вначале добавьте разрешение напрямую и запустите его. Если сообщается об ошибке, независимо от симулятора или реальной машины, вы всегда будете получать сообщение «Невозможно открыть драйвер сигнализации: разрешение отклонено» в logcat. Для использования этой функции требуется разрешение root или она запускается в системном процессе.

После долгого поиска в Интернете я обнаружил, что есть два способа решить эту проблему:

Один из них — скомпилировать с помощью make в среде исходного кода системы Android:

1. Добавьте атрибут android: sharedUserId = «android.uid.system» в узел манифеста в AndroidManifest.xml приложения. .

2. Измените файл Android.mk и добавьте строку LOCAL_CERTIFICATE: = platform.

3. Используйте команду mm для компиляции, и сгенерированный apk будет иметь право изменять системное время.

Этот метод не может быть скомпилирован с .mk, поэтому я должен обратиться ко второму методу:
1. Добавьте атрибут android: sharedUserId = «android.uid.system». ,

2. Используйте eclipse для компиляции неподписанного файла apk, но этот файл apk использовать нельзя.

3. Используйте ключ платформы целевой системы, чтобы повторно подписать файл apk.

Этот шаг более сложен, сначала найдите файл ключа, расположение в моем каталоге исходного кода Android — «build / target / product / security»,

Следующие два файла — это platform.pk8 и platform.x509.pem. Затем используйте инструмент Signapk, предоставляемый Android, чтобы подписать,

Исходный код signapk находится в папке «build / tools / signapk», используется «signapk platform.x509.pem platform.pk8 input.apk output.apk»,

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

Наконец, чтобы объяснить принцип, сначала добавьте атрибут android: sharedUserId = «android.uid.system».

С помощью общего идентификатора пользователя можно настроить несколько APK-файлов с одним и тем же идентификатором пользователя для работы в одном процессе.

Затем сопоставьте UID программы с android.uid.system, то есть позвольте программе работать в системном процессе, чтобы у вас было право изменять системное время.

Недостаточно просто добавить UID. Если APK-файл установлен в это время, он не будет установлен, а подпись не будет совпадать.

Причина в том, что программа хочет запускаться в системном процессе, но также имеет ключ платформы целевой системы, которым являются два файла platform.pk8 и platform.x509.pem, упомянутые во втором методе выше.

После подписания этими двумя ключами apk фактически может быть помещен в системный процесс. Добавление LOCAL_CERTIFICATE: = platform к первому методу фактически использует эти два ключа для подписи.

Также существует проблема, то есть программа, сгенерированная таким образом, может использоваться только в исходной системе Android или системе, скомпилированной вами, потому что такая система может получить два файла platform.pk8 и platform.x509.pem.

Если Android, сделанный другой компанией, даже не может быть установлен. Попробуйте подписать ключ в исходном Android, программа работает на эмуляторе ОК, но при установке на G3 сразу же выдается запрос «Пакет . не имеет подписей, соответствующих подписям общего пользователя android.uid.system». Защитите безопасность системы.

Наконец, атрибут android: sharedUserId может не только помещать apk в системный процесс, но также настраивать несколько APK для работы в одном процессе.

Обмен данными должен быть полезным.

Что такое UID

Как мы все знаем, Pid — это идентификатор процесса, Uid — это идентификатор пользователя, но Android — это не то же самое, что компьютер. У каждого пользователя компьютера есть Uid, который запускает программу, Uid этой программы — это этот пользователь, и каждая программа в Android Существует Uid. По умолчанию Android назначает Uid с разным общим уровнем для каждой программы. Если вы звоните друг другу, только Uid может быть одинаковым. Это обеспечивает определенную степень безопасности общих данных. Данные не могут быть получены произвольно между программами.

Установите UID вашего собственного приложения на UID системного процесса

Существует три типа UID системного процесса:

• android:sharedUserId=»android.uid.system»
• android:sharedUserId=»android.uid.shared»
• android:sharedUserId=»android.media»
  Давайте поэкспериментируем с первым. Две другие реализации будут такими же.

Объявить UID

Во-первых, нам нужно объявить UID приложения в манифесте:

Фирменная упаковка

Предварительным условием для упаковки подписи является наличие файла подписи системы, который обычно находится в каталоге build / target / product / security исходного кода, а пользовательские системы некоторых производителей размещаются в других каталогах. Например, Nanopc3, который я использую, находится в следующем каталоге, который может быть глобальным Найдите его. Сначала я также использовал каталог сборки, но его не удалось установить после упаковки. Позже я обнаружил, что в каталоге vendor также был / (ㄒ o ㄒ) /

загрузка… повторно загрузитьОтмена загрузка… повторно загрузитьОтмена

Среди них android: sharedUserId = «android.uid.system» соответствует двум файлам platform.pk8 и platform.x509.pem.
Вот три распространенных способа импорта системных подписей:

• Повторно подписать сгенерированный apk
• Повторно подписать собственный файл подписи приложения
• Скомпилировать из mk файла

Уже есть apk

Созданный файл apk можно повторно подписать с помощью следующей команды через файл signapk.jar в каталоге исходного кода / out / host / linux-x86 / framework.

java -jar signapk.jar platform.x509.pem platform.pk8 my.apk new.apk

Обратите внимание, что четыре файла signapk.jar, platform.x509.pem, platform.pk8 и my.apk должны находиться по одному и тому же пути при использовании этой инструкции, в противном случае вам нужно изменить путь самостоятельно.

Восстановить подпись

После создания собственного файла ключа используйте инструмент keytool-importkeypair для повторного создания подписи с помощью следующей команды:

keytool-importkeypair -k demo.jks -p 123456 -pk8 platform.pk8 -cert platform.x509.pem -alias demo

• demo.jks: файл подписи
• 123456: пароль файла подписи
• platform.pk8, platform.x509.pem: файл подписи системы
• демо: псевдоним файла подписи

Инструмент keytool-importkeypair можно загрузить сСкачать здесь。

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

Я не тестировал этот метод, потому что плохо разбираюсь в файлах mk. В обычных условиях он не будет использоваться. В конце концов, он в основном разработан с использованием инструментов ide. Достаточно двух вышеуказанных методов. При необходимости добавим позже.

Источник

Информация О Системном Приложении Android

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

и затем мне нужно подписать мое приложение с ключом производителей? Я не уверен, может ли кто-нибудь объяснить мне каким именно будет этот процесс?

также причина, по которой мое приложение должно быть системным приложением, заключается в том, что пользователь не может удалить его, но мое приложение все еще нуждается в обновлении. Можно ли обновить мое приложение, когда это системное приложение? Я бы обновил, если из google play, как обычно.

Спасибо за любую помощь, я просто не мог найти очень много информации на эту тему и был бы признателен за помощь.

3 ответов

эта ссылка здесь даст вам немного информации.

системное приложение не является приложением, которое подписано ОС подписи платформы. Это распространенная ошибка, в которую верят многие, и мы к этому мы еще вернемся. Системное приложение-это просто приложение, которое находится в папке / system / app в Android устройство. Приложение может быть установлено только в этой папке, если у нас есть доступ к ПЗУ ОС (system.НВФ.) Приложение помещенный под / App папка после извлечения ПЗУ. Устройство для загрузки пользовательский ROM будет иметь новое системное приложение добавлено. Благо системное приложение заключается в том, что приложение не может быть удалено из устройство (не может быть удалено пользователем). Это только потому, что / system / app-это папка только для чтения.

как для обновляя приложение через play store, я предполагаю, что вы сможете сделать это без каких-либо проблем, если приложение находится в play store, и вы используете одну и ту же подпись каждый раз. Он не должен быть сертификат производителя, но лучше использовать этот сертификат для подписи приложения.

Итак, единственное, что вам нужно убедиться, это то, что при создании ПЗУ производитель помещает ваш apk в системную папку, и он должен работать.

1. использовать mkkey.sh http://www.kandroid.org/online-pdk/guide/release_keys.html скрипт для создания новых сертификатов, включая сертификаты x509. вам не понадобятся эти шаги, поскольку производитель дает вам ключи.
2. В AndroidManifest.xml вашего приложения : под элементом добавить атрибут android: sharedUserId= » android.идентификатор uid.система»
3. экспорт неподписанной версии приложения для Android с помощью eclipse. Проект > > Инструменты Для Android > > Экспорт Неподписанный Пакет Приложений
4. использовать /out / host/ / framework / signapk.jar подписать приложение с помощью платформы.x509-на.pem и платформа.pk8 in/build/target/продукт/ безопасность / сгенерированный ранее

java-jar signapk.платформа jar.x509-на.платформа pem.pk8 your_app_unsigned.apk your_app_signed.apk

ответ на некоторые из ваших других вопросов уже дан Кумар Бибек. Вот шаги, которым я следовал, когда мне пришлось сделать то же самое. Это было в сделано в Android ICS. Шаги, возможно, изменились, но все же стоит попробовать.

поскольку Android O (Oreo), вам нужно подписать системные приложения с помощью клавиш dev, в отличие от прошлых версий, вы можете просто скопировать их в системную папку, которая менялась в прошлом.

Источник

Android security part 1: application signatures & permissions

This is the first of a series of posts about Android security. This one will describe the security around the applications, their signature/certificates as well as their permissions.

Introduction & Theory

Signature

Android requires that each application be signed with the developer’s digital keys to enforce signature permissions and application requests to use shared user ID or target process.

The core Android platform uses four keys to maintain security of core platform components:

• platform: a key for packages that are part of the core platform.
• shared: a key for things that are shared in the home/contacts process.
• media: a key for packages that are part of the media/download system.
• testkey: the default key to sign with if not otherwise specified.

These keys are used to sign applications separately for release images and are not used by the Android build system. The build system signs packages with the testkeys provided by default in build/target/product/security/, but this setting can be overwritten by specifying another path to PRODUCT_DEFAULT_DEV_CERTIFICATE.

In our builds, we use the keys located under device/fsl/common/security/ as specified in device/fsl/imx6/imx6.mk. Because those keys are part of a publicly available source tree, they should never be used for production devices . Instead, you should generate your own private keys for building your production images.

Each key comes in two files: the certificate, which has the extension .x509.pem, and the private key, which has the extension .pk8. The private key should be kept secret and is needed to sign a package. The key may itself be protected by a password — a reasonable strategy is to store your keys in source control along with the code — but keep them protected by a password known only to the people who make final releases. The certificate, in contrast, contains only the public half of the key, so it can be distributed widely. It is used to verify a package has been signed by the corresponding private key.

One more thing to be noted is that Android’s Package Manager uses an .apk signature in two ways:

• When an application is replaced, it must be signed by the same key as the old application in order to get access to the old application’s data.
  • If you change the certificate of an app already installed, it has to be un-installed first
• If two or more applications want to share a user ID (so they can share data, etc.), they must be signed with the same key .

Permissions

First the term “permissions” can mean two very different things:

1. Standard UNIX/Linux file system permissions, or
2. Android (JAVA) API permissions as described on the Android developer website

Let’s start with the file permissions which are related to your process User Identifier (UID) and Group Identifier (GID). Looking at the serial nodes for instance we can see:

The above means that ttymxc2 can only be accessed by a process having a bluetooth UID or the net_bt_stack GID. Those nodes permissions are set in the ueventd.rc.

Now looking at the process list:

This means that only those two applications can read/write for that node.

What about a standard JAVA application UID? Android’s package manager creates a unique user id (UID) and group (GID) when it installs an application and these are retained until the application is un-installed.

This output shows a typical UID assigned to a standard application (u0_a27), however some critical apps can require a specific UID such as system:

These parts (UID and GID) allow the kernel to enforce restrictions on files and devices. It is possible (and tempting) to allow “World” access to particular files, and we do it on occasion (see /dev/ttymxc0 in ueventd.rc), but this is somewhat dangerous.

The proper way to communicate to a driver in Android is for the JAVA application to call a standard API that uses a system service with the right permissions for the hardware. This brings us to the more Android-specific API permissions.

A basic Android application has no permissions associated with it by default, meaning it cannot do anything that would adversely impact the user experience or any data on the device. To make use of protected features of the device, you must include in your AndroidManifest.xml one or more tags declaring the permissions that your application needs.

Here is an example, if an application needs to get frames from the camera, it needs to ask for the CAMERA permission in its AndroidManifest.xml.

However, looking at the list of permissions you can notice that some permissions are marked as “Not for use by third-party applications“. This means that said permission can only be requested by a “system application” which means that it need to be signed with the platform keys . A good example is the REBOOT permissions which we are glad not every application can use.

Practical questions

It is assumed below that you are in possession of our last release source tree under your

How do I generate my own keys?

As explained in the README provided in the AOSP source tree under build/target/product/security/.

Once this is done, you can either overwrite the keys located under device/fsl/common/security/ or copy them in your own device folder and modify the PRODUCT_DEFAULT_DEV_CERTIFICATE variable in device/fsl/imx6/imx6.mk.

How do I re-sign an application with my keys?

In the source tree resides a JAVA tool that allow to sign/re-sign applications and package. This tool, signapk.jar, is built automatically when building any target available. It can be used as follows to sign an application:

Note for Android 7 (Nougat) and above: you now need to provide some extra parameters to the java tool:

How do I re-sign an update package with my keys?

The same goes for an update package (zip file):

How do I make my application a system app?

As said in the first section, an application considered a system app when signed with platform keys. It has nothing to do with its UID nor its location. Many people only suggest to copy the apk file from /data/app to /system/app but it doesn’t make it a system application per se. Here is an example to sign with the keys used in our build:

How do I grant my app the system uid?

It is actually very simple, you just need to add one line to your AndroidManifest.xml.

However this also requires your application to be signed with the platform keys.

Should all my apps be signed with platform keys then?

Signing with the platform keys gives access to many API that can be dangerous so you have to be careful. Moreover, it depends if your application is to be used across many different platforms or just one. As soon as your application requires to be signed with the platform keys, it will either only work to this specific platform or need to be re-sign for other products.

Remember that with great power comes great responsibility.

What about root uid?

A JAVA application cannot have a root UID but as you may have seen in the past, some applications rely on the su binary to execute some commands with root permissions. A su solution as been integrated in our latest release.

But it is to be noted that the init process has a root uid which means that any process forked from it would have the same uid by default. So if you have a native process that requires root permissions, declare it as a service in init.rc in order to be forked with the right permissions.

Test application

In order to demonstrate was has been said above, a repository containing a test application has been created:

More specifically there are two branches of interest:

• reboot_app: very simple application which only has one button that triggers a reboot() call that requires the REBOOT permission
• reboot_app_systemuid: same application but with the system uid

Why two different branches? Because we don’t want people to be confused about the “system app” term that doesn’t mean system uid. But we still wanted you to witness the system uid and how simple it is. So here is a step-by-step process to try the app:

• Download the source code

• Import the app into Android Studio
  • When Android Studio starts, click on “Import project (Eclipse, gradle etc…)”
  • Select the root of the android-tests source code
• Build and deploy the app by click on the play icon (please don’t make fun of the UI)

• Click on the Reboot button

• You can see the application crashed as expected because the application requires a permissions that only system app. It is time to sign it with the proper key:

• Note that we had to un-install the previous package first as the certificates have changed
• We can check our application uid and see it hasn’t changed, just its signature:

• Click again on the reboot button

From this moment on, our application can access any API marked as “Not for use by third-party applications“. The README under the security folder of android-tests also describes how to get Android Studio to automatically sign your application with the platform keys.

But we know some customers are interested in having an app with system uid, here is the procedure to achieve it.

• Switch to the second branch

• Build the application and sign it with platform keys as described above
  • Same you have to first un-install the previous app as Package Manager would otherwise complain that the uid changed
• Start the application and check the process uid

Источник