iOS 14 QEMU emülasyon yolculuğunun başlangıcı
- Mevcut açık kaynak proje
alephsecurity/xnu-qemu-arm64 kullanıldı, ancak salt okunur (read-only) olduğundan genişletilebilirlik açısından yetersizdi
- Daha sonra
TrungNguyen1909/qemu-t8030 projesi kullanılarak şu özelliklerden yararlanılabildi:
- iOS geri yükleme özelliği (USB bağlantısı için eşlik eden QEMU ile)
- iOS 14 çalıştırma
- Güncel QEMU sürümü tabanlı olması
- Ayrıntılı wiki dokümantasyonu sunması
launchd.plist düzenlenerek kabuk ve SSH erişimi sağlandı ve bu iyi bir başlangıç noktası oldu- Hedef, UI ve uygulamaların çalışabildiği eksiksiz bir iOS emülasyon ortamı kurmaktı
Çekirdek yamaları ve PongoOS’un devreye alınması
t8030 projesi, çekirdeği QEMU içinde yamalıyordu → bu da bakım ve genişletilebilirlik sorunları doğuruyordu- Jailbreak deneyimine dayanarak,
PongoOS üzerinden checkra1n yamalarının uygulanacağı bir yapıya geçildi
- QEMU’da SRAM boyutu artırılarak PongoOS çalıştırıldı ve checkra1n-KPF modülü enjekte edildi
- Önyükleme sırasında bootrom/iboot işlevlerinin eksikliği nedeniyle FPU yapılandırılmama sorunu ortaya çıktı → ARM dokümantasyonu referans alınarak çözüldü
- A13 sonrası PAC(Pointer Authentication) eklendiği için bazı yamalar geçersiz hale geldi
task_for_pid0 (tfp0) örneğiyle, PAC öncesi ve sonrası ikililer karşılaştırıldı
Çekirdek yaması otomasyon aracı geliştirme
- Mevcut checkra1n dinamik yama yöntemi okunması zor ve değiştirmesi zahmetliydi → bildirime dayalı, metin tabanlı bir yama yöntemi benimsendi
- İki adet
Mach-O ikilisi karşılaştırılarak assembly farkları çıkarıldı ve ardından metin yamaları üretildi
- Pongo ile önyükleme yapıldıktan sonra bellek dökümü alınıp çekirdek yeniden birleştirildi → tüm yamalar metin dosyalarında düzenlenip yorumlandı
Grafik işleme: Metal vs yazılım tabanlı işleme
- iOS, tüm UI işlemeyi
Metal API’si üzerinden yapıyor → GPU gerekiyor
- GPU emülasyonu karmaşık olduğundan şu alternatifler değerlendirildi:
- Yazılım tabanlı işleme
- Metal çağrılarını fiziksel cihaza proxy ile iletmek
- iOS 14’te
gpu=0 bootarg kaldırılmıştı → QuartzCore incelenerek fallback davranışı doğrulandı
- Jailbreak’li telefonda
QuartzCore yamalanarak yazılım tabanlı işlemenin çalıştığı doğrulandı (yavaş ama mümkün)
- Metal proxy yaklaşımı da denendi, ancak Objective-C ve API karmaşıklığı nedeniyle bırakıldı
Framebuffer ve IOSurface hata ayıklaması
t8030 QEMU’da framebuffer uygulaması yoktu → ChefKissInc/QEMUAppleSilicon fork’u kullanıldı- İlk önyüklemede Apple logosu ve ilerleme göstergesi görünüyordu, ancak sonrasında siyah ekran geliyordu → hata ayıklama başladı
- IOMFB kext analizi sonucunda iki mod olduğu görüldü:
- Sabit adresli framebuffer (ilk görüntüleme için)
- DMA tabanlı çok düzlemli yapı
- Sistem önyüklenirken DMA tabanlı mod kullanılıyordu → QEMU izleriyle çekirdek register ayarları doğrulandı
- Ancak buna rağmen ekranda hâlâ çıktı yoktu
Adres rastgeleleştirmenin devre dışı bırakılması
- Çekirdek adres rastgeleleştirmesi, kart başlatma kodunda devre dışı bırakılabiliyordu
- Kullanıcı alanındaki rastgeleleştirme ise
_load_machfile yamalanarak kapatıldı
- dyld cache, tüm dinamik kütüphaneleri içeren büyük bir ikiliydi → önyükleme sırasında sabit bir adrese yükleniyordu
dlopen sonrası _dyld_* işlevleriyle adresleri doğrulayan bir C aracı geliştirildi- Böylece GDB ile
dyld kütüphanesini hata ayıklamak mümkün oldu → özellikle IOMFB, SpringBoard, QuartzCore üzerinde duruldu
USB log erişimi ve lockdownd atlatması
- Fiziksel cihazda
idevicesyslog ile sistem logları toplanabiliyor → bunun için USB kimlik doğrulaması gerekiyor
- lockdownd, anahtar saklamak için SEP gerektiren bir keybag kullanıyor → emülatörde bu yok
- Mevcut işlevin yerine shellcode yerleştirilerek anahtarların doğrudan dosyadan yüklenmesi sağlandı
- USB ile bağlı QEMU’lar arasında anahtar doğrulaması atlatıldı → log toplamak mümkün hale geldi
- QuartzCore’un düzgün başlatıldığı ve yazılım tabanlı işleme kullandığı doğrulandı
PAC(Pointer Authentication) atlatması
backboardd değiştirilirken PAC hatası ortaya çıktı → bu, ARMv8.3 ile gelen bir güvenlik özelliği- PAC komutlarını NOP ile değiştirmek aşırı derecede müdahaleciydi
- PAC komutları uyumlu biçimde derlenebiliyor → QEMU PAC’i yok sayarsa çalıştırmak mümkün
- QEMU 7, PAC atlatmasını desteklemiyordu → QEMU 8.2.1’e geçildi
- Apple’a özgü komutlar ve GL exception level gibi çok sayıda QEMU özelleştirme kodunun taşınması gerekti
- Sonuç olarak iOS, QEMU 8 üzerinde önyükletildi ve PAC etkisiz hale getirilebildi
backboardd ve grafik çıktısının doğrulanması
backboardd çalışıyordu ama ekranda görüntü yoktu → birden fazla olası neden vardı- DMA bellek dökümleri de anlamlı bir çıktı vermedi
iosurface_lock içinde adres doğrulanıp frame dökümleri alındı, ancak verinin sıkıştırılmış biçimde GPU’ya iletildiği düşünüldü- iPhone X’te (t8015) sıkıştırılmamış çıktı görüldü → QEMU’nun DTB’si değiştirilerek
chip-id t8030’dan t8015’e çevrildi
- Sonuçta önyükleme sonrasında Apple logosu gösterilebildi
İlerleme çubuğu ve sistem hatalarının izlenmesi
- Logodan sonra beyaz ilerleme çubuğu görüntülendi → %90’da takılı kaldı
- Log analiziyle
mobileactivationd ve SpringBoardFoundation sorunları bulundu → yamalardan sonra UI değişti
- İlerlemenin durması sorununu çözmek için çok sayıda sistem logunun analiz edilmesi gerekti
dyld cache ve kullanıcı alanı yama otomasyonu
- Çekirdekte olduğu gibi kullanıcı alanında da metin tabanlı yama yaklaşımı kullanıldı
- dyld cache 2GB boyutundaydı, bu da değişiklikleri verimsiz kılıyordu → iç araçlar geliştirilerek şunlar sağlandı:
- dyld içindeki offset’leri takip etmek
dd komutuyla belirli konumları doğrudan yamamak
- Buna ek olarak çekirdek imza doğrulamasını atlatan yamalar da gerekiyordu
PreBoard çalıştırma ve UI doğrulaması
PreBoard, hata durumunda gösterilen sistem uygulamasıydı → doğrudan çalıştırılabiliyordu- Ekran kilidini klavyeyle açmayı denemek için VNC sunucusu eklendi
- Kilit açıldıktan sonra
vImage framework’ünde AMX(Apple Matrix Coprocessor) komutlarının kullanıldığı görüldü → QEMU bunu desteklemiyordu
- Sorun,
vImage içindeki yazılım fallback yoluna yama uygulanarak çözüldü
- Yama sonrasında metin girişi yapılabilen ekrana kadar görüntü alındı
Sonuç
- SpringBoard çalıştırılmadan hemen önceki aşamaya ulaşıldı → artık tam UI çalıştırmak sadece zaman meselesi
- Çekirdek, kullanıcı alanı, grafik ve güvenlik özellikleri (PAC vb.) çok yönlü biçimde analiz edilip yamalandı
- QEMU tabanlı, gerçekten kullanılabilir bir iOS uygulama hata ayıklama ve test ortamının mümkün olduğu doğrulandı
1 yorum
Hacker News yorumları