Xiaomi Cihazlarda Temp Root Çalışma Mekanizması: Kernel Seviyesinde Reverse Engineering Analizi

Yazan: Mert — Cep Telefonu Tamir Kursu  |  Güncelleme: Eylül 2026  |  Okuma süresi: ~14 dk

1. Temp Root Nedir, Kalıcı Root’tan Farkı Ne?

Mobil onarım literatüründe temp root (geçici kök erişimi), bir Android cihazda dosya sistemine ve çekirdek (kernel) kaynaklarına uid=0 yetkisiyle erişim sağlayan, ancak bu yetkinin yalnızca ilgili işlem/oturum ömrü boyunca geçerli olduğu bir yetki yükseltme biçimidir. Cihaz yeniden başlatıldığında, ilgili kabuk (shell) sonlandırıldığında veya çekirdek durumu sıfırlandığında bu yetki kaybolur; sistem bölümünde kalıcı hiçbir değişiklik bırakmaz.

Bu, kalıcı root çözümlerinden (Magisk ile yamalanmış boot.img, SuperSU dönemindeki sistem tabanlı çözümler, systemless root) temelde ayrılır. Kalıcı yöntemler önyükleme zincirine (boot chain) bir bileşen ekleyerek her açılışta root yetkisini yeniden kurar; temp root ise yalnızca çalışan bir süreç üzerinde, RAM’de tutulan çekirdek veri yapılarını hedef alır.

2. Xiaomi’nin Güvenlik Mimarisi: MIUI/HyperOS, VaultKeeper ve Bootloader Kilidi

Xiaomi, MIUI ve devamında HyperOS ile birlikte katmanlı bir güvenlik yapısı kullanır. Bootloader varsayılan olarak kilitlidir; resmi açma işlemi Mi Unlock aracı üzerinden hesap doğrulaması ve bekleme süresi (genellikle 7–360 gün arası, hesap geçmişine göre değişir) gerektirir. Bootloader kilitliyken fastboot flash komutlarının büyük kısmı reddedilir ve dm-verity/AVB (Android Verified Boot) bütünlük kontrolleri aktif kalır.

MIUI’ye özgü VaultKeeper servisi ve ilgili güvenlik modülleri, sistem bütünlüğünü izleyen ve anormal yetki değişikliklerini algılamaya çalışan ek bir katman oluşturur. Bu nedenle Xiaomi cihazlarda “stock” bir AOSP cihaza kıyasla temp root elde etmek genellikle daha fazla sayıda savunma katmanını aşmayı gerektirir: SELinux politikaları, dm-verity, anti-rollback sayaçları ve bazı modellerde ek çekirdek sertleştirmeleri (kernel hardening, ör. KASLR, PXN/PAN) art arda sıralanır.

3. Kernel Seviyesinde Yetki Yükseltmenin Genel Mantığı

Linux çekirdeğinde her süreç, task_struct adlı bir veri yapısıyla temsil edilir ve bu yapı içinde bir cred (credential/yetki belgesi) alanı bulunur. cred yapısı; uid, gid, euid, egid ve yetenek (capability) bitlerini tutar. Normal şartlarda bu alanlar yalnızca çekirdeğin kendi iç fonksiyonları (ör. setuid() sistem çağrısı, uygun yetkiye sahip bir çağrı zinciri üzerinden) tarafından değiştirilebilir.

Genel temp root yaklaşımının mantığı şu şekilde özetlenebilir:

1. Çalışan sürecin kendi task_struct yapısının çekirdek belleğindeki adresi tespit edilir.
2. Bu yapı içindeki cred işaretçisi bulunur.
3. Belirli bir çekirdek zafiyeti veya yanlış yapılandırılmış bir arayüz (ör. korumasız bir ioctl, hatalı sınır kontrolü olan bir sürücü) kullanılarak bu bellek bölgesine yazma işlemi gerçekleştirilir.
4. uid/gid alanları 0 (root) olarak değiştirilir; süreç artık çekirdek gözünde root yetkisine sahiptir.

Bu işlem sistem çağrı arayüzünün resmi yollarını kullanmadığı için “istismar” (exploit) olarak sınıflandırılır. Kritik nokta şudur: değişiklik yalnızca ilgili sürecin bellek görüntüsünde yapılır; diskteki hiçbir dosya değiştirilmez. Bu yüzden kalıcılığı yoktur ve iz bırakma riski, dosya sistemine yazan yöntemlere göre daha düşüktür.

4. Kallsyms ve Sembol Çözümleme Süreci

Bir çekirdek belleği manipülasyonunun yapılabilmesi için önce hedef veri yapılarının bellekteki adreslerinin bilinmesi gerekir. Çoğu Android çekirdeği, hata ayıklama ve modül yükleme amacıyla /proc/kallsyms adlı bir sanal dosya üzerinden çekirdek sembol tablosunu (fonksiyon ve değişken adları ile bunlara karşılık gelen sanal adresler) dışa açar.

Temp root araçlarının büyük bölümü şu sırayı izler:

• /proc/kallsyms okunarak init_task, selinux_enforcing gibi anahtar sembollerin adresleri elde edilir.
• init_task referans alınarak süreç listesi (list_head tasks) gezilir ve hedef sürecin (genellikle çalışan kabuğun) task_struct‘ı bulunur.
• Yapı içindeki alan uzaklıkları (offset), farklı çekirdek sürümleri ve üretici yamalarına göre değişebildiğinden, araç genellikle bilinen imzalar/desenler üzerinden bu uzaklıkları otomatik tahmin eder.

5. SELinux: Enforcing’den Permissive’e Geçiş

Uid değerini 0 yapmak tek başına yeterli değildir; çünkü Android’de SELinux, kök yetkisine sahip bir sürecin dahi hangi dosyalara/servislere erişebileceğini Mandatory Access Control (MAC) politikalarıyla ayrıca sınırlar. Bu yüzden aynı bellek manipülasyonu genellikle ikinci bir hedefi de kapsar: çekirdek içindeki selinux_enforcing global değişkenini 1 (enforcing) durumundan 0 (permissive) durumuna çevirmek.

Permissive modda SELinux ihlalleri engellenmez, yalnızca dmesg/audit günlüklerine kaydedilir. Bu sayede elde edilen root kabuğu, DAC (uid=0) seviyesinde tam yetkiye ek olarak MAC seviyesinde de fiilen sınırsız hale gelir. Bazı güncel çekirdeklerde bu değişkenin salt-okunur bellek sayfasına (__ro_after_init) taşınmış olması, bu adımı doğrudan engelleyebilir; bu tür sertleştirmeler, yöntemin güncel MIUI/HyperOS sürümlerinde neden tutarlı biçimde çalışmadığını açıklayan teknik nedenlerden biridir.

6. MediaTek Tabanlı Xiaomi Modellerinde Yaklaşım

Redmi ve POCO serisinin MediaTek (Dimensity/Helio) tabanlı modellerinde topluluk tarafından en çok bilinen genel amaçlı araç kategorisi, yukarıda anlatılan kallsyms okuma → task_struct/cred bulma → uid ve selinux_enforcing üzerine yazma zincirini otomatikleştiren, ARMv8 64-bit MediaTek çekirdeklerini hedef alan açık kaynaklı topluluk araçlarıdır (XDA Developers platformunda uzun süredir belgelenen bir kategori). Bu araçlar bootloader kilidini açmadan, /data/local/tmp gibi yazılabilir bir dizinden çalıştırılarak geçici bir kök kabuk elde eder ve yalnızca o kabuk kapatılana ya da cihaz yeniden başlatılana kadar geçerlidir.

Bu yöntemin çalışıp çalışmayacağı; MediaTek çekirdek sürümüne, Xiaomi’nin o modelde uyguladığı ek çekirdek yamalarına ve güvenlik yaması (patch level) tarihine göre değişir. Yeni nesil modellerde MediaTek ve Xiaomi’nin ortak yayınladığı güvenlik güncellemeleri bu tür genel amaçlı zafiyetleri kapatma eğilimindedir; bu yüzden yöntem model/firmware bazında “dene-gör” niteliğindedir, evrensel bir prosedür değildir.

7. Qualcomm (Snapdragon) Tabanlı Modellerde Farklar

Qualcomm platformlu Xiaomi modellerinde çekirdek mimarisi ve önyükleme zinciri farklı bileşenlerden oluştuğu için (ör. Qualcomm’a özgü abl/xbl önyükleyici aşamaları, farklı bir TrustZone/QSEE uygulaması) MediaTek’e özgü genel araçlar doğrudan çalışmaz. Bu ailede temp root senaryoları daha çok şu iki eksende ilerler:

• Chipset’e özgü çekirdek zafiyetleri: Belirli bir Qualcomm çekirdek sürümüne veya sürücüsüne (ör. GPU/DSP sürücüleri) özgü, halka açık CVE kayıtlarına konu olmuş zafiyetlerin, cihaza uyarlanmış bir kanıtlama kodu (proof-of-concept) ile denenmesi.
• EDL (Emergency Download Mode) tabanlı düşük seviye erişim: Test point veya fastboot oem edl/deep flash kısayoluyla 9008 moduna geçilerek Firehose/Sahara protokolü üzerinden bölüm okuma-yazma yapılması. Bu, klasik anlamda “root” değildir; işletim sistemi hiç çalışmadan donanım seviyesinde bölümlere erişimdir ve genellikle IMEI/EFS onarımı, tuğlalanmış (bricked) cihazların firmware ile geri getirilmesi gibi senaryolarda kullanılır.

Pratikte Qualcomm tabanlı Xiaomi modellerinde “temp root” ihtiyacının büyük bölümü, EDL yoluyla dosya sistemine doğrudan erişilerek veya bootloader resmi olarak açılıp geçici bir boot.img ile önyükleme yapılarak (kalıcı flaş olmadan, yalnızca fastboot boot ile) karşılanır; bu ikincisi teknik olarak “temp root” değil “temporary boot ile root” kategorisine girer ve daha kararlı, tekrarlanabilir bir yoldur.

8. Temp Root’un Sınırları ve Kalıcı Root’a Geçiş

Temp root ile elde edilen kabuk üç önemli sınırla çalışır:

• Kapsam sınırı: Yetki yalnızca o kabuk sürecine ve onun çocuk süreçlerine aittir; sistemde çalışan diğer uygulamalar (ör. bir dosya yöneticisi) otomatik olarak root yetkisi kazanmaz.
• Kalıcılık sınırı: Yeniden başlatma, ilgili sürecin sonlanması veya çekirdek panikleri bu yetkiyi sıfırlar.
• Üçüncü parti yönetim eksikliği: Magisk gibi bir “Superuser” yöneticisi olmadığı için uygulamalar root isteği gönderemez; yalnızca komut satırından manuel işlem yapılabilir.

Bazı senaryolarda temp root, kalıcı roota geçişte bir “sıçrama tahtası” olarak kullanılır: elde edilen geçici kök kabuk üzerinden, kullanıcı alanında Magisk’in enjekte edilmesi (bootloader kilidini açmadan, yalnızca çalışan sistem içinde) denenebilir. Ancak bu, dm-verity aktifken sistem bölümüne kalıcı yazma anlamına gelmediği için genellikle bir sonraki yeniden başlatmada etkisini yitirir; gerçek kalıcılık için resmi bootloader açma ve yamalı boot.img‘in flaşlanması gerekir.

9. Tamir Sektöründe Kullanım Senaryoları

Bir servis teknisyeni açısından temp root’un pratikteki karşılığı, ekranı kırık ya da dokunmatik arızalı bir cihazdan kullanıcı verisini kurtarmak için gerektiğinde dosya sistemine kısa süreliğine erişmek, arıza teşhisinde dmesg/logcat çıktısını root seviyesinde okumak, EFS/NV bölümünün yedeğini (bkz. IMEI onarımı ile ilgili önceki yazılarımız) almadan önce bölüm izinlerini doğrulamak ve kilitli/FRP korumalı bir cihazda arıza teşhisi için geçici komut çalıştırmaktır. Bu işlemler, cihazın kalıcı olarak değiştirilmesini gerektirmediği için müşteri cihazına en az müdahaleyle sonuç almak isteyen servisler açısından tercih edilir.

10. Riskler, Garanti ve Etik Boyut

Ayrıca bu tür yöntemlerin yalnızca sahibi olunan veya servis yetkisiyle işlem yapılan cihazlarda, ilgili ülke mevzuatına ve cihaz garanti şartlarına uygun biçimde kullanılması gerektiği unutulmamalıdır; başkasına ait bir cihazda izinsiz yetki yükseltmesi hem etik hem hukuki sorumluluk doğurur.

Sık Sorulan Sorular