Google is committed to advancing racial equity for Black communities. See how.
Bu sayfa, Cloud Translation API ile çevrilmiştir.
Switch to English

APEX Dosya Biçimi

Android Pony EXpress (APEX), daha düşük seviyeli sistem modülleri için yükleme akışında kullanılan, Android 10'da sunulan bir kapsayıcı biçimidir. Bu format, standart Android uygulama modeline uymayan sistem bileşenlerinin güncellemelerini kolaylaştırır. Bazı örnek bileşenler, yerel hizmetler ve kitaplıklar, donanım soyutlama katmanları ( HAL'ler ), çalışma zamanı ( ART ) ve sınıf kitaplıklarıdır.

"APEX" terimi ayrıca bir APEX dosyasına da başvurabilir.

Arka fon

Android, paket yükleyici uygulamaları (Google Play Store uygulaması gibi) aracılığıyla standart uygulama modeline uyan modül güncellemelerini (örneğin, hizmetler, etkinlikler) desteklese de, daha düşük seviyeli işletim sistemi bileşenleri için benzer bir model kullanmanın aşağıdaki dezavantajları vardır:

  • APK tabanlı modüller, önyükleme sırasının başlarında kullanılamaz. Paket yöneticisi, uygulamalarla ilgili merkezi bilgi deposudur ve yalnızca önyükleme prosedürünün sonraki bir aşamasında hazır hale gelen etkinlik yöneticisinden başlatılabilir.
  • APK biçimi (özellikle manifest), Android uygulamaları için tasarlanmıştır ve sistem modülleri her zaman uygun değildir.

Tasarım

Bu bölüm APEX dosya formatının üst düzey tasarımını ve APEX dosyalarını yöneten bir hizmet olan APEX yöneticisini açıklamaktadır.

APEX için bu tasarımın neden seçildiği hakkında daha fazla bilgi için bkz.APEX geliştirilirken dikkate alınan alternatifler .

APEX biçimi

Bu, bir APEX dosyasının formatıdır.

APEX dosya biçimi

Şekil 1. APEX dosya formatı

En üst düzeyde, bir APEX dosyası, dosyaların sıkıştırılmamış olarak depolandığı ve 4 KB sınırlarında bulunduğu bir zip dosyasıdır.

Bir APEX dosyasındaki dört dosya şunlardır:

  • apex_manifest.json
  • AndroidManifest.xml
  • apex_payload.img
  • apex_pubkey

apex_manifest.json dosyası, bir APEX dosyasını tanımlayan paket adını ve sürümünü içerir.

AndroidManifest.xml dosyası, APEX dosyasının ADB, PackageManager ve paket yükleyici uygulamaları (Play Store gibi) gibi APK ile ilgili araçları ve altyapıyı kullanmasına izin verir. Örneğin, APEX dosyası, aapt temel meta verileri incelemek için aapt gibi mevcut bir aracı kullanabilir. Dosya, paket adı ve sürüm bilgilerini içerir. Bu bilgiler genellikle apex_manifest.json da mevcuttur.

apex_manifest.json , APEX ile ilgilenen yeni kod ve sistemler için AndroidManifest.xml yerine önerilir. AndroidManifest.xml , mevcut uygulama yayınlama araçları tarafından kullanılabilecek ek hedefleme bilgileri içerebilir.

apex_payload.img , dm-verity tarafından desteklenen bir ext4 dosya sistemi görüntüsüdür. Görüntü, bir geridöngü cihazı aracılığıyla çalışma zamanında monte edilir. Özellikle, hash ağacı ve meta veri bloğu libavb kullanılarak oluşturulur. Dosya sistemi yükü ayrıştırılmaz (çünkü görüntünün yerine monte edilebilir olması gerekir). apex_payload.img dosyasında normal dosyalar bulunur.

apex_pubkey , dosya sistemi görüntüsünü imzalamak için kullanılan genel anahtardır. Çalışma zamanında bu anahtar, indirilen APEX'in yerleşik bölümlerde aynı APEX'i imzalayan aynı varlık ile imzalanmasını sağlar.

APEX yöneticisi

APEX yöneticisi (veya apexd ), APEX dosyalarının doğrulanmasından, yüklenmesinden ve kaldırılmasından sorumlu bağımsız bir yerel işlemdir. Bu işlem başlatılır ve önyükleme sırasının başlarında hazırdır. APEX dosyaları normalde cihazda /system/apex altına önceden yüklenir. APEX yöneticisi, herhangi bir güncelleme yoksa varsayılan olarak bu paketleri kullanır.

Bir APEX'in güncelleme sırası, PackageManager sınıfını kullanır ve aşağıdaki gibidir.

  1. Bir APEX dosyası, bir paket yükleyici uygulaması, ADB veya başka bir kaynak aracılığıyla indirilir.
  2. Paket yöneticisi kurulum prosedürünü başlatır. Dosyanın bir APEX olduğunu anladıktan sonra, paket yöneticisi kontrolü APEX yöneticisine aktarır.
  3. APEX yöneticisi APEX dosyasını doğrular.
  4. APEX dosyası doğrulanırsa, APEX yöneticisinin dahili veritabanı APEX dosyasının bir sonraki önyüklemede etkinleştirileceğini gösterecek şekilde güncellenir.
  5. Yüklemenin istemcisi, paketin başarılı bir şekilde doğrulanmasının ardından bir yayın alır.
  6. Kuruluma devam etmek için sistem, cihazı otomatik olarak yeniden başlatır.
  7. Yeniden başlatma sırasında APEX yöneticisi başlar, dahili veritabanını okur ve listelenen her APEX dosyası için aşağıdakileri yapar:

    1. APEX dosyasını doğrular.
    2. APEX dosyasından bir geri döngü cihazı oluşturur.
    3. Geridöngü aygıtının üstünde bir aygıt eşleyici blok aygıtı oluşturur.
    4. Aygıt eşleyici blok aygıtını benzersiz bir yola (örneğin, /apex/ name @ ver ) /apex/ name @ ver .

Dahili veritabanında listelenen tüm APEX dosyaları bağlandığında, APEX yöneticisi, diğer sistem bileşenlerinin kurulu APEX dosyaları hakkında bilgi sorgulaması için bir bağlayıcı hizmeti sağlar. Örneğin, diğer sistem bileşenleri, cihazda kurulu APEX dosyalarının listesini sorgulayabilir veya belirli bir APEX'in monte edildiği tam yolu sorgulayabilir, böylece dosyalara erişilebilir.

APEX dosyaları APK dosyalarıdır

APEX dosyaları, bir AndroidManifest.xml dosyası içeren imzalanmış zip arşivleri (APK imza şemasını kullanan) oldukları için geçerli APK dosyalarıdır. Bu, APEX dosyalarının bir paket yükleyici uygulaması, imzalama yardımcı programı ve paket yöneticisi gibi APK dosyaları için altyapıyı kullanmasına izin verir.

Bir APEX dosyası içindeki AndroidManifest.xml dosyası, paket name , versionCode ve maxSdkVersion hedefleme için isteğe bağlı targetSdkVersion , minSdkVersion ve maxSdkVersion . Bu bilgiler, APEX dosyalarının paket yükleyici uygulamaları ve ADB gibi mevcut kanallar aracılığıyla teslim edilmesini sağlar.

Desteklenen dosya türleri

APEX formatı şu dosya türlerini destekler:

  • Yerel paylaşılan kitaplıklar
  • Yerel yürütülebilir dosyalar
  • JAR dosyaları
  • Veri dosyaları
  • Yapılandırma dosyaları

Bu, APEX'in tüm bu dosya türlerini güncelleyebileceği anlamına gelmez. Bir dosya türünün güncellenip güncellenemeyeceği platforma ve dosya türleri için arabirimlerin ne kadar kararlı tanımlandığına bağlıdır.

İmzalama

APEX dosyaları iki şekilde imzalanır. İlk olarak, apex_payload.img (özellikle, eklenen vbmeta açıklayıcısı apex_payload.img ) dosyası bir anahtarla imzalanır. Ardından, tüm APEX, APK imza şeması v3 kullanılarak imzalanır. Bu işlemde iki farklı anahtar kullanılır.

Cihaz tarafında, vbmeta tanımlayıcısını imzalamak için kullanılan özel anahtara karşılık gelen bir genel anahtar kurulur. APEX yöneticisi, kurulması istenen APEX'leri doğrulamak için genel anahtarı kullanır. Her APEX farklı anahtarlarla imzalanmalıdır ve hem derleme zamanında hem de çalışma zamanında zorunlu kılınmalıdır.

Yerleşik bölümlerde APEX

APEX dosyaları, /system gibi yerleşik bölümlerde bulunabilir. Bölüm zaten dm-verity'nin üzerindedir, bu nedenle APEX dosyaları doğrudan geri döngü aygıtının üzerine monte edilir.

Yerleşik bir bölümde bir APEX mevcutsa, APEX, aynı paket adı ve daha yüksek bir sürüm koduna sahip bir APEX paketi sağlanarak güncellenebilir. Yeni APEX, /data içinde saklanır ve APK'lara benzer şekilde, daha yeni sürüm yerleşik bölümde zaten mevcut olan sürümü gölgeler. Ancak APK'lardan farklı olarak, APEX'in yeni sürümü yalnızca yeniden başlatmanın ardından etkinleştirilir.

Çekirdek gereksinimleri

Bir Android cihazda APEX ana hat modüllerini desteklemek için aşağıdaki Linux çekirdeği özellikleri gereklidir: geri döngü sürücüsü ve dm-verity. Geridöngü sürücüsü, dosya sistemi görüntüsünü bir APEX modülüne bağlar ve dm-verity, APEX modülünü doğrular.

Geri döngü sürücüsünün performansı ve dm-verity, APEX modüllerini kullanırken iyi sistem performansı elde etmek için önemlidir.

Desteklenen çekirdek sürümleri

APEX ana hat modülleri, 4.4 veya üstü çekirdek sürümlerini kullanan cihazlarda desteklenir. Android 10 veya üzeri ile başlatılan yeni cihazlar, APEX modüllerini desteklemek için kernel 4.9 veya daha üst sürümünü kullanmalıdır.

Gerekli çekirdek yamaları

APEX modüllerini desteklemek için gerekli çekirdek yamaları, Android ortak ağacında yer almaktadır. Yamaların APEX'i desteklemesi için Android ortak ağacının en son sürümünü kullanın.

Çekirdek sürümü 4.4

Bu sürüm yalnızca Android 9'dan Android 10'a yükseltilen ve APEX modüllerini desteklemek isteyen cihazlar için desteklenir. Gerekli yamaları elde etmek için, android-4.4 şubesinden bir alt birleştirme şiddetle tavsiye edilir. Aşağıda, çekirdek sürüm 4.4 için gerekli tek tek yamaların bir listesi verilmiştir.

  • UPSTREAM: döngü: mantıksal blok boyutunu değiştirmek için ioctl ekleyin ( 4.4 )
  • BACKPORT: blok / döngü: hw_sectors ( 4.4 ) ayarla
  • UPSTREAM: döngü: Uyumlu ioctl'ye ( 4.4 ) LOOP_SET_BLOCK_SIZE ekle
  • ANDROID: mnt: next_descendent'i düzeltin ( 4.4 )
  • ANDROID: mnt: remount, kölelerin kölelerine yayılmalıdır ( 4.4 )
  • ANDROID: mnt: Yeniden bağlanmayı doğru şekilde yay ( 4.4 )
  • "ANDROID: dm verity: minimum ön getirme boyutunu ekle" ( 4.4 ) değerini geri alma
  • UPSTREAM: döngü: offset veya block_size değiştirilirse önbellekleri bırak ( 4.4 )

Çekirdek sürümleri 4.9 / 4.14 / 4.19

Çekirdek sürüm 4.9 / 4.14 / 4.19 için gerekli yamaları almak için android-common dalından aşağı birleştirme.

Gerekli çekirdek yapılandırma seçenekleri

Aşağıdaki liste, Android 10'da tanıtılan APEX modüllerini desteklemek için temel yapılandırma gereksinimlerini gösterir. Yıldız işaretli (*) öğeler, Android 9 ve daha düşük sürümlerde mevcut gereksinimlerdir.

(*) CONFIG_AIO=Y # AIO support (for direct I/O on loop devices)
CONFIG_BLK_DEV_LOOP=Y # for loop device support
CONFIG_BLK_DEV_LOOP_MIN_COUNT=16 # pre-create 16 loop devices
(*) CONFIG_CRYPTO_SHA1=Y # SHA1 hash for DM-verity
(*) CONFIG_CRYPTO_SHA256=Y # SHA256 hash for DM-verity
CONFIG_DM_VERITY=Y # DM-verity support

Çekirdek komut satırı parametresi gereksinimleri

APEX'i desteklemek için, çekirdek komut satırı parametrelerinin aşağıdaki gereksinimleri karşıladığından emin olun.

  • loop.max_loop
  • loop.max_part <= 8 olmalıdır

APEX inşa etmek

Bu bölümde, Android yapı sistemini kullanarak bir APEX'in nasıl oluşturulacağı açıklanmaktadır. Aşağıda Android.bp adlı bir APEX için Android.bp örneği apex.test .

apex {
    name: "apex.test",
    manifest: "apex_manifest.json",
    file_contexts: "file_contexts",
    // libc.so and libcutils.so are included in the apex
    native_shared_libs: ["libc", "libcutils"],
    binaries: ["vold"],
    java_libs: ["core-all"],
    prebuilts: ["my_prebuilt"],
    compile_multilib: "both",
    key: "apex.test.key",
    certificate: "platform",
}

apex_manifest.json örneği:

{
  "name": "com.android.example.apex",
  "version": 1
}

file_contexts örneği:

(/.*)?           u:object_r:system_file:s0
/sub(/.*)?       u:object_r:sub_file:s0
/sub/file3       u:object_r:file3_file:s0

APEX'teki dosya türleri ve konumları

Dosya tipi APEX'te yer
Paylaşılan kitaplıklar /lib ve /lib64 ( /lib64 çevrilmiş kol için /lib/arm )
Yürütülebilir dosyalar /bin
Java kitaplıkları /javalib
Prebuilts /etc

Geçişli bağımlılıklar

APEX dosyaları otomatik olarak yerel paylaşılan kütüphanelerin veya yürütülebilir dosyaların geçişli bağımlılıklarını içerir. Örneğin, libFoo libBar , iki libFoo , native_shared_libs özelliğinde yalnızca libFoo listelendiğinde dahil edilir.

Birden çok ABI'yı işleme

native_shared_libs hem birincil hem de ikincil uygulama ikili arabirimleri ( native_shared_libs için native_shared_libs özelliğini yükleyin. Bir APEX, tek bir ABI'ye sahip cihazları hedeflerse (yani, yalnızca 32 bit veya yalnızca 64 bit), yalnızca karşılık gelen ABI'ye sahip kitaplıklar kurulur.

binaries özelliğini yalnızca aşağıda açıklandığı gibi aygıtın birincil ABI'si için kurun:

  • Aygıt yalnızca 32 bit ise, ikilinin yalnızca 32 bit çeşidi yüklenir.
  • Aygıt yalnızca 64 bit ise, o zaman ikilinin yalnızca 64 bit çeşidi yüklenir.

Yerel kitaplıkların ve ikili dosyaların multilib.[first|lib32|lib64|prefer32|both].[native_shared_libs|binaries] üzerinde ayrıntılı denetim eklemek için, multilib.[first|lib32|lib64|prefer32|both].[native_shared_libs|binaries] özelliklerini kullanın.

  • first : Cihazın birincil ABI'siyle eşleşir. Bu, ikili dosyalar için varsayılandır.
  • lib32 : Destekleniyorsa, aygıtın 32 bit lib32 .
  • lib64 : lib64 64 bit lib64 , desteklenir.
  • prefer32 : Destekleniyorsa, aygıtın 32 bit prefer32 . 32 bit ABI desteklenmiyorsa, 64 bit ABI ile eşleşir.
  • both : Her iki ABI ile eşleşir. Bu, native_shared_libraries için varsayılandır.

java , libraries ve prebuilts özellikleri ABI-agnostiktir.

Bu örnek 32 / 64'ü destekleyen ve 32'yi tercih etmeyen bir cihaz içindir:

apex {
    // other properties are omitted
    native_shared_libs: ["libFoo"], // installed for 32 and 64
    binaries: ["exec1"], // installed for 64, but not for 32
    multilib: {
        first: {
            native_shared_libs: ["libBar"], // installed for 64, but not for 32
            binaries: ["exec2"], // same as binaries without multilib.first
        },
        both: {
            native_shared_libs: ["libBaz"], // same as native_shared_libs without multilib
            binaries: ["exec3"], // installed for 32 and 64
        },
        prefer32: {
            native_shared_libs: ["libX"], // installed for 32, but not for 64
        },
        lib64: {
            native_shared_libs: ["libY"], // installed for 64, but not for 32
        },
    },
}

vbmeta imzalama

Her APEX'i farklı anahtarlarla imzalayın. Yeni bir anahtar gerektiğinde, bir genel-özel anahtar çifti oluşturun ve bir apex_key modülü yapın. key kullanarak APEX'i imzalamak için key özelliğini kullanın. Genel anahtar, avb_pubkey otomatik olarak avb_pubkey adıyla dahil avb_pubkey .

# create an rsa key pair
openssl genrsa -out foo.pem 4096

# extract the public key from the key pair
avbtool extract_public_key --key foo.pem --output foo.avbpubkey

# in Android.bp
apex_key {
    name: "apex.test.key",
    public_key: "foo.avbpubkey",
    private_key: "foo.pem",
}

Yukarıdaki örnekte, genel anahtarın ( foo ) adı, anahtarın kimliği olur. Bir APEX'i imzalamak için kullanılan anahtarın kimliği APEX'e yazılır. Çalışma zamanında apexd , cihazda aynı ID'ye sahip bir genel anahtar kullanarak apexd doğrular.

ZIP imzalama

APEX'leri APK'larla aynı şekilde imzalayın. APEX'leri iki kez imzalayın, biri mini dosya sistemi ( apex_payload.img dosyası) için ve bir kez tüm dosya için.

Dosya düzeyinde bir APEX imzalamak için, certificate özelliğini şu üç yoldan birini kullanarak ayarlayın:

  • Ayarlanmadı: Değer ayarlanmadıysa, APEX, PRODUCT_DEFAULT_DEV_CERTIFICATE adresinde bulunan sertifika ile imzalanır. Hiçbir bayrak ayarlanmadıysa, yol varsayılan olarak build/target/product/security/testkey .
  • <name> : APEX, PRODUCT_DEFAULT_DEV_CERTIFICATE aynı dizindeki <name> sertifikası ile imzalanmıştır.
  • :<name> : APEX, <name> adlı Soong modülü tarafından tanımlanan sertifika ile imzalanır. Sertifika modülü aşağıdaki şekilde tanımlanabilir.
android_app_certificate {
    name: "my_key_name",
    certificate: "dir/cert",
    // this will use dir/cert.x509.pem (the cert) and dir/cert.pk8 (the private key)
}

APEX kurmak

Bir APEX kurmak için ADB kullanın.

adb install apex_file_name
adb reboot

APEX kullanmak

Yeniden başlatmanın ardından APEX, /apex/<apex_name>@<version> dizinine /apex/<apex_name>@<version> . Aynı APEX'in birden fazla versiyonu aynı anda monte edilebilir. Bağlama yolları arasında, en son sürüme karşılık gelen, /apex/<apex_name> .

İstemciler, APEX'ten dosyaları okumak veya yürütmek için bağlanan yolu kullanabilir.

APEX'ler tipik olarak şu şekilde kullanılır:

  1. Bir OEM veya ODM, cihaz sevk edildiğinde /system/apex altına bir APEX'i önceden yükler.
  2. /apex/<apex_name>/ dosyalara /apex/<apex_name>/ yolu üzerinden erişilir.
  3. APEX'in güncellenmiş bir sürümü /data/apex içine kurulduğunda, yol, yeniden başlatmanın ardından yeni APEX'e işaret eder.

Bir hizmeti bir APEX ile güncelleme

APEX kullanarak bir servisi güncellemek için:

  1. Sistem bölümündeki hizmeti güncellenebilir olarak işaretleyin. updatable seçeneği hizmet tanımına ekleyin.

    /system/etc/init/myservice.rc:
    
    service myservice /system/bin/myservice
        class core
        user system
        ...
        updatable
    
  2. Güncellenen hizmet için yeni bir .rc dosyası oluşturun. Mevcut hizmeti yeniden tanımlamak için override seçeneğini kullanın.

    /apex/my.apex@1/etc/init.rc:
    
    service myservice /apex/my.apex@1/bin/myservice
        class core
        user system
        ...
        override
    

Hizmet tanımları yalnızca bir APEX'in .rc dosyasında tanımlanabilir. APEX'lerde eylem tetikleyicileri desteklenmez.

APEX'ler etkinleştirilmeden önce güncellenebilir olarak işaretlenmiş bir hizmet başlarsa, başlatma APEX'lerin aktivasyonu tamamlanana kadar ertelenir.

Sistemi APEX güncellemelerini destekleyecek şekilde yapılandırma

APEX dosya güncellemelerini desteklemek için aşağıdaki sistem özelliğini true olarak ayarlayın.

<device.mk>:

PRODUCT_PROPERTY_OVERRIDES += ro.apex.updatable=true

BoardConfig.mk:
TARGET_FLATTEN_APEX := false

ya da sadece

<device.mk>:

$(call inherit-product, $(SRC_TARGET_DIR)/product/updatable_apex.mk)

Düzleştirilmiş APEX

Eski cihazlar için, eski çekirdeği APEX'i tam olarak destekleyecek şekilde güncellemek bazen imkansız veya mümkün değildir. Örneğin, çekirdek, dosya sistemi görüntüsünü bir APEX içine monte etmek için çok önemli olan CONFIG_BLK_DEV_LOOP=Y olmadan oluşturulmuş olabilir.

Düzleştirilmiş APEX, eski bir çekirdeğe sahip cihazlarda etkinleştirilebilen özel olarak oluşturulmuş bir APEX'tir. Düzleştirilmiş bir APEX'teki dosyalar doğrudan yerleşik bölümün altındaki bir dizine yüklenir. Örneğin, lib/libFoo.so bir flattend APEX my.apex /system/apex/my.apex/lib/libFoo.so yüklenir.

Düzleştirilmiş bir APEX'in etkinleştirilmesi, döngü cihazını içermez. /system/apex/my.apex dizininin tamamı doğrudan /apex/name@ver /system/apex/my.apex bağlanır.

Düzleştirilmiş APEX'ler, APEX'lerin güncellenmiş sürümlerini ağdan indirerek güncellenemez çünkü indirilen APEX'ler düzleştirilemez. Düzleştirilmiş APEX'ler yalnızca normal bir OTA aracılığıyla güncellenebilir.

Düzleştirilmiş APEX, varsayılan yapılandırmadır. Bu, cihazınızı APEX güncellemelerini (yukarıda açıklandığı gibi) desteklemek için düzleştirilmemiş APEX'ler oluşturacak şekilde açıkça yapılandırmadığınız sürece tüm APEX'lerin varsayılan olarak düzleştirildiği anlamına gelir.

Bir cihazda düzleştirilmiş ve düzleştirilmemiş APEX'lerin karıştırılması DESTEKLENMEZ. Bir cihazdaki APEX'ler ya tamamen düzleştirilmiş ya da tamamen düzleştirilmiş olmalıdır. Bu, özellikle Mainline gibi projeler için önceden imzalanmış APEX prebuiltleri gönderirken önemlidir. Önceden imzalanmamış (yani kaynaktan oluşturulmuş) APEX'ler de düzleştirilmemeli ve uygun anahtarlarla imzalanmalıdır. Cihaz, APEX ile bir hizmeti updatable_apex.mk bölümünde açıklandığı gibi updatable_apex.mk devralmalıdır.

APEX geliştirilirken dikkate alınan alternatifler

APEX dosya biçimini tasarlarken göz önünde bulundurduğumuz bazı seçenekler ve bunları neden dahil ettiğimiz veya hariç tuttuğumuz aşağıda açıklanmıştır.

Düzenli paket yönetim sistemleri

Linux dağıtımları, güçlü, olgun ve sağlam olan dpkg ve rpm gibi paket yönetim sistemlerine sahiptir. Ancak, kurulumdan sonra paketleri koruyamadıkları için APEX için benimsenmemişlerdir. Doğrulama yalnızca paketler kurulurken yapılır. Saldırganlar, kurulu paketlerin bütünlüğünü fark edilmeden bozabilir. Bu, tüm sistem bileşenlerinin bütünlüğü her G / Ç için dm-verity ile korunan salt okunur dosya sistemlerinde depolandığı Android için bir regresyondur. Sistem bileşenlerine yapılan herhangi bir tahrifat yasaklanmalı veya algılanabilir olmalıdır, böylece cihaz tehlikeye atılırsa önyüklemeyi reddedebilir.

bütünlük için dm-crypt

Bir APEX kapsayıcısındaki dosyalar, dm-verity tarafından korunan yerleşik bölümlerden (örneğin, /system bölümü), bölümler bağlandıktan sonra bile dosyalarda herhangi bir değişiklik yapılmasının yasak olduğu yerlerde bulunur. Dosyalara aynı düzeyde güvenlik sağlamak için, bir APEX'teki tüm dosyalar, bir karma ağaç ve bir vbmeta tanımlayıcı ile eşleştirilmiş bir dosya sistemi görüntüsünde saklanır. Dm-verity olmadan, /data bölümündeki bir APEX, doğrulandıktan ve kurulduktan sonra yapılan istenmeyen değişikliklere karşı savunmasızdır.

Aslında, /data bölümü ayrıca dm-crypt gibi şifreleme katmanlarıyla da korunmaktadır. Bu, kurcalanmaya karşı bir miktar koruma sağlasa da, birincil amacı gizlilik değil, bütünlüktür. Bir saldırgan /data bölümüne erişim kazandığında, daha fazla koruma olamaz ve bu da /system bölümünde bulunan her sistem bileşenine kıyasla bir gerilemedir. Bir APEX dosyası içindeki karma ağaç dm-verity ile birlikte aynı seviyede içerik koruması sağlar.

Yollara yönlendirme /system etmek /apex

APEX içinde paketlenmiş sistem bileşen dosyalarına /apex/<name>/lib/libfoo.so gibi yeni yollardan erişilebilir. Dosyalar /system bölümünün parçası olduğunda, bunlara /system/lib/libfoo.so gibi yollardan erişilebilirdi. Bir APEX dosyasının istemcisi (diğer APEX dosyaları veya platform) yeni yolları kullanmalıdır. Yollardaki bu değişiklik, mevcut kodda güncelleme gerektirebilir.

Yol değişikliğini önlemenin bir yolu, bir APEX dosyasındaki dosya içeriklerini /system bölümü üzerine bindirmektir. Bununla birlikte, dosyaları /system bölümü üzerine bindirmemeye karar verdik çünkü bunun, üst üste bindirilen (muhtemelen birbiri ardına yığılmış olan) dosyaların sayısı arttıkça performansı olumsuz etkileyeceğine inandık.

Diğer bir seçenek de open , stat ve readlink gibi dosya erişim işlevlerini ele geçirmekti, böylece /system ile başlayan yollar /apex altındaki karşılık gelen yollarına yeniden yönlendirildi. Yolları kabul eden tüm işlevleri değiştirmek pratik olarak mümkün olmadığı için bu seçeneği bir kenara attık. Örneğin, bazı uygulamalar, işlevleri uygulayan Bionic'i statik olarak bağlar. Bu durumda, uygulama için yeniden yönlendirme gerçekleşmez.