-
Notifications
You must be signed in to change notification settings - Fork 66
AndroidOTA
Signatures are stored in build/target/product/security and platform is used to sign packages and updates
build/target/product/security/README::
The following commands were used to generate the test key pairs:
development/tools/make_key testkey ‘/C=US/ST=California/L=Mountain View/O=Android/OU=Android/CN=Android/emailAddress=android@android.com’
development/tools/make_key platform ‘/C=US/ST=California/L=Mountain View/O=Android/OU=Android/CN=Android/emailAddress=android@android.com’
development/tools/make_key shared ‘/C=US/ST=California/L=Mountain View/O=Android/OU=Android/CN=Android/emailAddress=android@android.com’
development/tools/make_key media ‘/C=US/ST=California/L=Mountain View/O=Android/OU=Android/CN=Android/emailAddress=android@android.com’
The following standard test keys are currently included:
testkey — a generic key for packages that do not otherwise specify a key.
platform — a test key for packages that are part of the core platform.
shared — a test key for things that are shared in the home/contacts process.
media — a test key for packages that are part of the media/download system.
These test keys are used strictly in development, and should never be assumed
to convey any sort of validity. When $BUILD_SECURE=true, the code should not
honor these keys in any context.
signing using the openssl commandline (for boot/system images)
———————————————————————————————
1. convert pk8 format key to pem format
% openssl pkcs8 -inform DER -nocrypt -in testkey.pk8 -out testkey.pem
2. create a signature using the pem format key
% openssl dgst -binary -sha1 -sign testkey.pem FILE > FILE.sig
extracting public keys for embedding
——————————————————
it’s a Java tool
but it generates C code
take a look at commands/recovery/Android.mk
you’ll see it running $(HOST_OUT_JAVA_LIBRARIES)/dumpkey.jar
List of keys::
build/target/product/security
build/target/product/security/shared.pk8
build/target/product/security/verity.pk8
build/target/product/security/platform.×509.pem
build/target/product/security/Android.mk
build/target/product/security/releasekey.×509.pem
build/target/product/security/README
build/target/product/security/releasekey.pk8
build/target/product/security/shared.×509.pem
build/target/product/security/testkey.pk8
build/target/product/security/platform.pk8
build/target/product/security/verity.×509.pem
build/target/product/security/testkey.×509.pem
build/target/product/security/platform.jks
build/target/product/security/media.×509.pem
build/target/product/security/verity_key
build/target/product/security/media.pk8
Android APK packages are signed in almost the same way Java jar files are signed. Both APK and normal jar file are a collection
of files contained in a zip archives. This zip file contains a special directory called META-INF. You can list the content
of an apk or jar by unzipping it.
https://github.com/keesj/gomo/wiki/AndroidPackageSignatures
In the recovery keys are read from a special file system.
The OTA is based on an existing build using a script called
./build/tools/releasetools/ota_from_target_files
- c Code to perform the update itself contains a meta language (META-INF/com/google/android/update-binary)
- The update script itself META-INF/com/google/android/updater-script
- ota_from_target_files allows to add parts to this script
- the c code and update stuff are located bootable/recovery
- the updater language is found here bootable/recovery/edify also described here https://source.android.com/devices/tech/ota/inside_packages.html
- the c code gets executed from a “ui” program to allow to show something on the screen
Debug recovery:
/cache/recovery/log
/cache/recovery/last_log
Recovey command via /cache/recovery/command
https://android.googlesource.com/platform/bootable/recovery/+/fadc5ac81d6400ebdd041f7d4ea64021596d6b7d/recovery.c
most usefull:
—update_package=/cache/update.zip
reboot recovery
Look at
-bootable/recovery/applypatch
and
build/tools/releasetools/common.py::
sh = """#!/system/bin/sh
if ! applypatch -c s:(recovery_device)s:%(recovery_size)d:%(recovery_sha1)s; then
applypatch s %(boot_type)s:(boot_device)s:%(boot_size)d:%(boot_sha1)s s:(recovery_device)s %(recovery_sha1)s %(recovery_size)d %(boot_sha1)s:/system/recovery-from-boot.p && log -t recovery “Installing new recovery image: succeeded” || log -t recovery “Installing new recovery image: failed”
else
log -t recovery “Recovery image already installed”
fi
""" % { ‘boot_size’: boot_img.size,
‘boot_sha1’: boot_img.sha1,
‘recovery_size’: recovery_img.size,
‘recovery_sha1’: recovery_img.sha1,
‘boot_type’: boot_type,
‘boot_device’: boot_device,
‘recovery_type’: recovery_type,
‘recovery_device’: recovery_device,
‘bonus_args’: bonus_args,
}