Bootloader Kilit Açma, dm-verity Doğrulaması ve Mobil Cihaz Güvenli Başlatma (Secure Boot) Zinciri

Bölüm 1: Bu Nedir ve Neden Hayati Önem Taşır?

Mobil cihaz güvenli başlatma (Secure Boot) zinciri, donanım tabanlı güvenilir kök (Root of Trust – RoT) kimliğinden başlayarak yazılım katmanlarına (Bootloader, Kernel, System Image) kadar uzanan bir şifreleme tabanlı doğrulama hiyerarşisidir. Bu arketip, Bootloader kilidinin açılma (Unlock) sürecinin, dm-verity (Device Mapper Verity) blok cihazı bütünlük doğrulama mekanizmasının devre dışı bırakılması veya yeniden yapılandırılması ile sonuçlanan güven zincirindeki kırılma noktalarını, rollback (geri alma) koruması etkileşimlerini ve AVB (Android Verified Boot) 2.0 politikalarını inceler. Temel yaklaşim, “Güvenilmeyen Kod Çalıştırma” riskini minimize eden, ancak geliştirici ve güvenlik araştırmacısı erişimine izin veren kontrollü bir “Geliştirici Modu” geçiş protokolünü tanımlamaktır. Analiz kapsamı; SoC (System on Chip) ROM kodunun ilk aşama yükleyicisini (Primary Bootloader) nasıl doğruladığı, vbmeta (Verified Boot Metadata) yapısının hash ağacı (Merkle Tree) yapısı ve kilit açma komutlarının (fastboot flashing unlock) TEE (Trusted Execution Environment) veya RPMB (Replay Protected Memory Block) üzerindeki kalıcı durum değişikliklerini kapsar.

Bölüm 2: Perde Arkası: Sistem Nasıl Çalışıyor?

Güvenli başlatma zinciri, “Zincirleme Güven” (Chain of Trust) prensibiyle işler. SoC üretimi sırasında eflenen ve değiştirilemeyen ROM kodu (Immutable Root of Trust), fabrika anahtarı (OEM Public Key) ile imzalanmış ilk aşama bootloader’ı (xbl, aboot, lk vb.) doğrular. Bu aşama, ikinci aşama bootloader’ı (UEFI/EDK2 veya LK second stage) ve vbmeta bölümündeki hash kökünü (Root Hash) doğrular. dm-verity, system, vendor, product gibi salt-okunur bölümleri blok seviyesinde korur; her 4KB’lık veri bloğu SHA-256 ile hashlenir, bu hashler Merkle ağacı yapısına dizilir ve kök hash vbmeta içinde OEM özel anahtarıyla imzalanır. Kernel başlatma sırasında dm-verity modülü, blok cihazı okumaları sırasında her bloğu kök hashe kadar olan yolu (Merkle Proof) kullanarak doğrular. Bootloader kilidi açıldığında (Unlock), OEM kilit durumu (Lock State) RPMB’de UNLOCKED olarak yazılır, vbmeta doğrulaması AVB_SLOT_VERIFY_FLAGS_ALLOW_VERIFICATION_ERROR bayrağı ile bypass edilmeye zorlanır veya vbmeta özel bir test anahtarıyla yeniden imzalanır. Bu işlem, TEE içindeki Keymaster/StrongBox anahtarlarının sıfırlanmasına (Wipe) ve cihazın DEVICE_STATE_UNLOCKED bayrağı set edilmesine neden olur.

Bölüm 3: Bilim Dünyası ve Uzmanlar Nasıl İnceliyor?

Standartlaşma çerçevesi; Google Android Verified Boot (AVB) 2.0 spesifikasyonu, NIST SP 800-193 (Platform Firmware Resiliency), GlobalPlatform TEE Client API ve TEE Internal Core API, JEDEC eMMC/UFS RPMB (JESD84-B51) standartları üzerine kuruludur. Doğrulama metodolojisi; statik analizde avbtool (Python/C++ implementasyonu) ile vbmeta imza ve hash ağacı doğrulaması, dinamik analizde fastboot oem get_identifier_token / fastboot flashing unlock_critical komut akışlarının USB paket seviyesinde (Wireshark/USBpcap) incelenmesi ve dmesg/logcat üzerinden verity/fsverity hata kodlarının (EIO, ENODATA) korelasyon analizi yapılır. Rollback koruması testleri için AVB_PROPERTY_ROLLBACK_INDEX değerlerinin fastboot getvar ile okunması ve avbtool add_hash_footer ile düşürülmeye çalışılan indekslerin Red/Yellow/Green state makinesi (AVB Slot Verify) davranışları gözlemlenir. Sektörel sertifikasyon süreçleri (CVE taraması, Project Zero raporları) referans alınır.

Bölüm 4: Önemli Parametreler ve Karşılaştırma Rehberi

Bölüm 5: Günlük Hayatta ve Doğada Nerede Karşımıza Çıkar?

Kurumsal mobilite yönetimi (EMM/MDM) senaryolarında, cihaz kaydı sırasında DevicePolicyManager API’si aracılığıyla isDeviceSecure() ve KeyAttestation doğrulaması yapılır; Bootloader UNLOCKED bayrağı tespit edilirse cihaz “Rooted/Compromised” olarak etiketlenir ve kurumsal veriler (Work Profile) uzaktan silinir (Remote Wipe). Geliştirici akışında (AOSP Porting, Custom ROM), fastboot flashing unlock sonrası avbtool ile özel vbmeta.img (disable_verity, disable_verification bayrakları set edilmiş) üretilip flashlanır; bu süreçte vbmeta_system, vbmeta_vendor zincirleme doğrulama (Chained Partitions) için ayrı anahtar çiftleri (x509 sertifikaları) yönetilir. Güvenlik araştırmacılığı (Vulnerability Research) için UNLOCK_CRITICAL (bazı SoC’lerde fastboot flashing unlock_critical) ile boot/dtbo/vbmeta bölümlerinin yazılabilir hale getirilmesi, dinamik analiz (Frida, MagiskHide) ve kernel exploit geliştirme ortamı sağlar. OEM fabrika geri yükleme (EDL Mode / Firehose) senaryolarında, kilitli bootloader üzerinden sahara/firehose protokolleri ile partition.xml tanımlı tüm bölümler (rpm, tz, hyp, abl, xbl, vbmeta) fabrika imzalı imajlarla yeniden yazılarak Chain of Trust sıfırdan kurulur.

Bölüm 6: Karşılaşılan Zorluklar ve Pratik Çözümler

Rollback Saldırısı (Downgrade): Eski, zaafiyetli boot.img/vbmeta flashlanmaya çalışılır. Çözüm: Monotonik artan rollback_index (RBI) eFuse/RPMB’de saklanır; avbtool ile imza atılırken indeks artırılır, bootloader düşük indeksli imajı AVB_SLOT_VERIFY_RESULT_ERROR_ROLLBACK_INDEX hatasıyla reddeder. Brick (Kesin Ölüm) Riski: Yanlış vbmeta imzası veya super partition tablo bozulması cihazı boot etmez hale getirir. Çözüm: EDL (Emergency Download) modu ve OEM Firehose programmer (prog_firehose_ddr.elf) ile QFIL/QSahara araçları kullanılarak raw flash kurtarması. Verity Korelasyon Hataları: system bölümü resize2fs ile genişletilirse Merkle ağacı bozulur. Çözüm: avbtool add_hash_footer ile yeni boyut için hash ağacı yeniden hesaplanır ve vbmeta yeniden imzalanır. Anti-Rollback eFuse Tükenmesi: Çok sık OTA/test döngüleri eFuse bitlerini tüketir. Çözüm: RBI slot bazlı (A/B) tutulur, eFuse sadece kritik güvenlik yamaları için artırılır. MDM/Enterprise Reddi: Kilit açık cihazlar SafetyNet/Play Integrity API BASIC/DEVICE_INTEGRITY verdiremez. Çözüm: Kilit kapatma (fastboot flashing lock) ve fabrika imajı flashlama zorunluluğu.

Bölüm 7: Gelecek Perspektifi ve Yeni Gelişmeler

Android 14/15 (UpsideDownCake/VanillaIceCream) ile Virtual A/B Compression (snapuserd) ve Dynamic System Updates (DSU) yaygınlaştı; bu da dm-verity metadata’sının super partition içinde sıkıştırılmış bloklar üzerinden yönetilmesini gerektiriyor. Pixel 8/9 serisinde tanıtılan Hardware-Backed Key Attestation (StrongBox) artık ROT (Root of Trust) sertifika zincirini cihaz üretim anında imzalıyerek, kilit açma sonrası bile donanım kimliğinin sahteleştirilememesini sağlıyor. Generic Kernel Image (GKI) 2.0 ve Bootconfig modülleri, vendor boot imajını (vendor_boot.img) vbmeta_vendor ile ayrı doğrulama zincirine soktu. Gelecek 5-10 yılda; Post-Quantum Cryptography (PQC) (CRYSTALS-Dilithium/Kyber) AVB imza algoritmalarına (AVB 3.0+) entegre edilecek, Confidential Computing (CC) ortamlarında (pVM – protected VM) boot ölçümlerinin (TCG Event Log) uzaktan doğrulanması (Remote Attestation) standartlaşacak. RISC-V tabanlı SoC’lerde (Örn: Google Tensor RISC-V çekirdekleri) PMP (Physical Memory Protection) ve PMA (Physical Memory Attribution) donanım kilitleri ile bootloader kilidi mekanizması yazılımdan donanıma taşınıyor.

Bölüm 8: Merak Edilen Sorular ve Cevaplar

Soru 1: Bootloader kilidi açıldığında (OEM Unlock) dm-verity otomatik olarak devre dışı mı kalır?

Cevap: Hayır. Bootloader kilidi açılması (UNLOCKED state), sadece fastboot flash komutlarının imzasız imajları yazmasına izin verir. dm-verity kernel cmdline parametresi (androidboot.veritymode=enforcing) ve vbmeta içindeki disable_verity bayrağı ayrı ayrı kontrol edilir. Kilit açıkken bile vbmeta imzası geçerliyse ve disable_verity set edilmemişse, kernel dm-verity korumasını aktif başlatır ve sistem bölümü değiştirilmişse bootloop’a girer.

Soru 2: “Fastboot flashing unlock_critical” ile “Fastboot flashing unlock” farkı nedir?

Cevap: unlock (Standart), kullanıcı verisi bölümü (userdata) silinerek cihazı fabrika ayarlarına döndürür ve LOCKED -> UNLOCKED geçişi yapar; genellikle boot/dtbo/vbmeta yazımına izin verir. unlock_critical (Kritik), super partition içindeki vbmeta_system, vbmeta_vendor, modem, tz, hyp gibi kritik güvenlik bölümlerinin yazılmasına izin verir. Bu komut genellikle fastboot flashing unlock yapıldıktan sonra ikinci bir onay akışıyla (ekran üzerinde “Allow critical unlock” onayı) çalışır ve cihazı “Unlocked Critical” durumuna sokar.

Soru 3: Rollback Index (RBI) nasıl çalışır ve eFuse mu yoksa RPMB mi kullanır?

Cevap: RBI, her slot (A/B) için ayrı tutulan monotonik artan bir sayaçtır. Modern cihazlarda (Android 11+), RBI değeri RPMB (Replay Protected Memory Block) içinde şifreli ve monotonic counter ile saklanır. eFuse (One-Time Programmable) genellikle sadece Bootloader/Kernel seviyesindeki kritik güvenlik yamaları (Örn: Bootloader exploit yaması) için “Minimum Rollback Index” olarak yazılır. Normal OTA güncellemeleri RPMB sayacını artırır; eFuse sadece “Point of No Return” anında yanılır.

Soru 4: Magisk “Zygisk” ve “DenyList” dm-verity ile nasıl ilişkilidir?

Cevap: Magisk, boot.img içindeki ramdisk‘e kendini enjekte ederek init sürecini kapar. dm-verity etkinse system bölümü salt-okunurdur. Magisk “Systemless” yöntemiyle system bölümüne yazmaz; yerine overlayfs veya bind mount ile /system görünümünü değiştirir. Zygisk (Zygote Injection), dm-verity tarafından korunmayan apex/apex_* bölümlerini veya vendor overlay’lerini hedefler. DenyList (eski MagiskHide), Play Integrity gibi uygulamaların dm-verity durumunu (ro.boot.veritymode) veya Magisk tarafından yaratılan mount namespace’lerini tespit etmesini engeller.

Soru 5: AVB 2.0 “Chained Partitions” (Zincirleme Bölümler) mimarisi nedir?

Cevap: Tek bir vbmeta imzasının tüm bölümleri kapsamasından ziyade, ana vbmeta (boot/vbmeta) diğer bölümlerin (vbmeta_system, vbmeta_vendor, vbmeta_product, vbmeta_odm) hash’lerini (descriptor) içerir. Ana vbmeta OEM anahtarıyla imzalanır. Alt vbmeta bölümleri kendi içindeki hash ağacını (Merkle Tree) ve kendi imzasını (genelde aynı OEM anahtarı veya ayrı bir alt anahtar) taşır. Bu, system güncellemesi yapılırken vendor/boot imajlarına dokunmadan sadece vbmeta_system ve system imajının yenilenmesini, ana vbmeta içindeki vbmeta_system descriptor’ının (hash/size) güncellenmesini sağlar (Modülerlik).

Soru 6: Kilitli bootloader (Locked) cihazda “Fastbootd” (Dynamic Partitions) nasıl çalışır?

Cevap: fastbootd, recovery modunda çalışan bir userspace daemon’dır. Kilitli bootloader’da fastboot (bootloader mode) sadece flash boot/dtbo/vbmeta (bazı OEM’lerde) izin verir. super partition içindeki dinamik bölümler (system, vendor, product) fastbootd üzerinden flashlanır. fastbootd başlatıldığında (fastboot reboot fastboot), cihaz recovery kernel’ına boot eder. Burada vbmeta doğrulaması yine geçerlidir; fastbootd OTA paketlerini (payload.bin) update_engine ile uygularken vbmeta descriptor’larını ve rollback_index kontrolünü yapar. Kilitli cihazda fastbootd sadece OEM imzalı payload’ları kabul eder.

Bölüm 9: Bilmeniz Gereken Temel Terimler

AVB (Android Verified Boot): Android’in güvenli başlatma standardı. vbmeta metadata yapısı, rollback koruması ve chained partition doğrulamasını tanımlar.
dm-verity (Device Mapper Verity): Linux Kernel Device Mapper çerçevesinde, salt-okunur blok cihazlarının bütünlüğünü Merkle Hash Tree (SHA-256) ile blok seviyesinde doğrulayan modül.
vbmeta (Verified Boot Metadata): AVB’nin çekirdek veri yapısı. Bölümün hash kökü (root hash), hash algoritması, rollback index, imza ve chained partition descriptor’larını içerir.
RPMB (Replay Protected Memory Block): eMMC/UFS depolama biriminde donanımla korunan, şifreli ve monotonic counter (sayac) içeren özel bölge. Kilit durumu, RBI ve Keymaster anahtarları burada saklanır.
RoT (Root of Trust): Güven zincirinin en başlangıç noktası. Değiştirilemez ROM kodu ve fabrika eflenen OEM Public Key hash’i (SHA-256) oluşturur.
Fastbootd: Dynamic Partitions (Süper Bölüm) mimarisi için recovery modunda çalışan, userspace tabanlı flash protokolü daemon’u. update_engine entegrasyonlu OTA uygulamasını sağlar.

Bölüm 10: Özet ve Çıkarılması Gereken Dersler

Mobil cihaz güvenli başlatma zinciri, donanım kök güveninden (RoT) başlayarak yazılım katmanlarına (AVB, dm-verity, fs-verity) kadar uzanan, kriptografik olarak kanıtlanabilir bir bütünlük zinciridir. Bootloader kilidinin açılması (Unlock), bu zincirin ilk halkasını (Bootloader Doğrulaması) kırarak, sonraki halkaların (Kernel, System) doğrulama bağlamını “Güvenilmeyen” (Untrusted) durumuna iter; bu da StrongBox/Keymaster anahtarlarının sıfırlanmasına, Play Integrity/SafetyNet güveni kaybına ve Kurumsal MDM politikalarının tetiklenmesine neden olur. Stratejik olarak; Geliştiriciler için fastboot flashing unlock + vbmeta patch (disable_verity) yolu kontrollü riskle yönetilmelidir. Kurumsal Savunma için; cihaz kaydı anında Key Attestation (Hardware-backed) doğrulaması, ro.boot.verifiedbootstate (Green/Orange/Red) ve ro.boot.veritymode (enforcing) kontrolleri zorunlu kılınmalıdır. OEM’ler için; AVB 2.0 Chained Partitions, GKI ayrımı ve PQC geçişi ile geleceğe dönük esneklik sağlanmalı, RPMB tabanlı monotonic counter koruması ile rollback vektörleri tamamen kapatılmalıdır. Gelecek, “Unlock” kavramının “Güvenli Geliştirici Modu” (Secure Developer Mode – TEE içinde izole) ile yeniden tanımlanacağı, donanım kilitlerinin (PMP/PMA) yazılımdan bağımsızlaştığı bir mimariye doğru evrilmektedir.