Apple Silicon üzerinde iOS sanallaştırma

 (nickb.website)
2 puan yazan GN⁺ 2024-10-08 | 1 yorum | WhatsApp'ta paylaş
  • Apple silicon Mac’in Virtualization.framework’ü ve vma2 ortamı kullanılarak iOS 15.0.2 iPhone XR derlemesini PreBoard.app aşamasına kadar önyükleme denemesi
  • Yaklaşımın özü, macOS 12.0.1 boot chain’ini yeniden kullanıp yalnızca iOS sistem imajı, mtree, root_hash, trustcache bileşenlerini değiştirerek erken önyükleme zincirini değiştirme yükünü azaltmak
  • Özel _setProductionModeEnabled(false) çağrısıyla VM’i CPFM 01 durumuna düşürünce, genel vma2 aygıtları için TSS’in rastgele firmware’i imzalayabildiği ve böylece mevcut vma2pwn yöntemine olan ihtiyacın azaldığı görülüyor
  • Gerçek önyükleme için XNU platform denetimi, system keybag, IOMFB boyut denetimi, ramdisk, launchd, mount, DYLD shared cache, lockdownd, mobileactivationd üzerinde kernel ve sistem yamaları gerekiyor
  • En büyük çözümsüz sorun system keybag uyumluluğu; ayrıca dokunmatik girişin Virtualization.framework’ün özel API’leriyle mümkün olup olmadığı da henüz doğrulanmış değil

Deneyin hedefi ve çıkış noktası

  • Apple silicon’a geçiş ve Mac Catalyst sonrasında iOS ile macOS birbirine daha da yaklaştı; macOS sanallaştırılabiliyorken iOS’un da aynı aileden bir boot chain değiştirilerek sanallaştırılıp sanallaştırılamayacağı temel soruya dönüştü
  • Önceki çalışma olan vma2pwn, macOS guest VM için değiştirilebilir bir vma2 macOS boot chain üretmeyi amaçlayan projeydi ve bu deneyin temelini oluşturdu
  • Kamuya açık, tamamlanmış iOS sanallaştırma/emülasyon örneği olarak Corellium’un virtual iPhone cloud ürünü bulunuyor
  • qemu-t8030, QEMU tabanlı çalışmalar ve Zhuowei Zhang’ın yazısı da referans alındı; özellikle macOS’taki IOSurfaceRoot ile iOS’taki IOCoreSurfaceRoot arasındaki ilişki, sonraki kernel yaması arayışında yardımcı oldu
  • Zhuowei Zhang’ın yazısına göre GUI macOS uygulamaları iOS’te çalıştırılamazken grafik tabanlı iOS uygulamaları macOS’te çalıştırılabiliyor ve bu özellik iOS grafik sisteminin önemli bir kısmı için de geçerli

Virtualization.framework’ün özel işlevleri

  • Apple’ın Virtualization.framework içinde belgelenmemiş özel bir _setProductionModeEnabled(false) fonksiyonu bulunuyor
  • Bu çağrı ve VM ayarındaki karşılığı, VM’i Chip Fuse Mode olan CPFM 01 seviyesine indirerek sanal aygıtı “secure” ama “non-production” durumda yapılandırıyor
  • Fiziksel aygıtlarda TSS, CPFM 00 veya 01 gibi non-production/non-secure aygıtlar için gereken SHSH blob imzasını vermeyi reddediyor
  • Ancak genel vma2 aygıtı için TSS, verilen rastgele firmware’i imzalayabildiğinden, değiştirilmiş firmware zinciri oluşturan vma2pwn yaklaşımına duyulan ihtiyaç büyük ölçüde azalıyor

iOS VM yapılandırma yöntemi

  • En başarılı yaklaşım, macOS 12.0.1 boot chain’ini olduğu gibi kullanıp sistem OS imajını iOS 15.0.2 iPhone XR derlemesinin imajı ve ilgili dosyalarıyla değiştirmek oldu
    • Değiştirilenler: sistem imajı, mtree, root_hash, trustcache
    • Bu yöntem, iOS başlatılmadan önceki boot chain aşamalarını ve kurtarma ramdisk’ini değiştirme ihtiyacının büyük kısmını baypas ediyor
  • iPhone XR derlemesi, arm64e desteği ve daha düşük çözünürlük olasılığı nedeniyle seçildi
  • Başka arm64e aygıt yapılandırmalarında da başarı mümkün olabilir, ancak vma2 kernel’i bazı sysctl anahtarları için "iPad8,6" döndürecek şekilde sabit kodlanmış durumda
  • arm64 derlemeleri ek sorunlar ve ikili uyumsuzluklar yaşadığından denemeye çok değmez görülüyor
  • VM’i çalıştırmak için, Apple silicon VM yönetim aracı tart’ın bir fork’u olan super-tart kullanıldı
    • super-tart, Virtualization.framework’ün gerekli özel işlevlerini kullanabilmeyi sağlıyor
    • _setProductionModeEnabled(false) ayarı gibi bazı değişiklikler henüz tamamen push edilmedi
    • Özel API kullanan Virtualization.framework araçlarında SIP kapatılmalı, gerekirse AMFI da kapatılmalı
  • Geri yükleme aracı olarak idevicerestore fork’u kullanıldı

Kernel yamaları

  • vma2pwn’de kullanılan imza denetimi yamaları gerekebilir, ancak CPFM 01 yönteminde bunların kesin olarak zorunlu olup olmadığı net değil
  • İmza ile ilgili yamalar, vma2 kernel’inde şu fonksiyonların 0 döndürmesini sağlayacak şekilde uygulanıyor
    • _apfs_extract_root_hash_arm
    • _authenticate_root_hash
    • __img4_firmware_property_callback
    • _is_root_hash_authentication_required
    • _img4_firmware_evaluate
  • lookup_in_static_trust_cache ise 1 döndürecek şekilde yamalanmalı
  • iOS ikilileri simulator platform ikilisi olmadığından başlangıçta EXEC, [0xe] Binary with wrong platform hatasıyla sonlanıyor
    • XNU içindeki PLATFORM_IOS denetim satırı atlanacak şekilde yamalanınca sorun çözülüyor
    • vma2 kernel’inde bu, B.NE komutunu B ile değiştirme şeklinde uygulanıyor
  • system keybag uyumsuzluğu nedeniyle PreBoard.app, Setup.app yerine “Swipe up to upgrade.” gösteriyor
    • ipc_make_system_keybag üzerine iki yama uygulanıp fonksiyonun hata döndürmesi engellenirse PreBoard.app aşamasına ulaşılabiliyor
    • Bu sınırlama hâlâ tamamen çözülmüş değil
  • iOS sistem framework’leri ile macOS kernel’i arasındaki IOMFB yapı boyutu uyuşmazlığı, CLCDTransaction size mismatch. Returning error 0x%X. dizesiyle birlikte kernel panic’e yol açıyor
    • IOMobileFramebufferUserClient::swap_submit içindeki boyut denetimini kaldırmak panic’i durduruyor

Sistem dosyası yaması hazırlığı

  • Kurtarma ramdisk’i ve iOS sistem dosyaları imzalı olduğundan, yama sonrası yeniden imzalanmazlarsa çalışırken sonlandırılıyorlar
  • Değiştirilmiş ortamda Procursus’un ldid aracı öneriliyor
    • Kurulum örneği: brew install ldid-procursus
    • Yeniden imzalama örneği: ldid_macosx_arm64 -S -M <binary>
    • -S, ikiliyi pseudo-sign eder; -M ise mevcut entitlements’ları korur
  • Birçok ikili identity denetimi yaptığından, yeniden imzalamadan önce adın identity ile değiştirilip sonra eski adına döndürülmesi gerekiyor
    • keybagd için codesign -d -v keybagd çıktısından Identifier=com.apple.keybagd doğrulanıyor
    • mv keybagd com.apple.keybagd
    • ldid_macosx_arm64 -S -M com.apple.keybagd
    • mv com.apple.keybagd keybagd
  • Otomatik olarak sembollenmemiş fonksiyonlar, string XRef aranarak ve log çağrısı referansları üzerinden çağıran fonksiyon izlenerek bulunabiliyor
  • Seri terminalde etkileşimli shell elde etmek için Bash ve LaunchDaemon taşınabiliyor
    • Bunun için Procursus gibi sürüm uyumlu iOS jailbreak payload’larından ilgili dosyaları kopyalama yöntemi kullanılıyor

DMG ve ramdisk değişiklikleri

  • Sistemi ya da kurtarma ramdisk’ini yamalamak için DMG volume’ünü doğrudan değiştirmek gerekiyor
  • iOS 15.0.2 örneğinde, IPSW içindeki iOS System volume’ü yazılabilir biçime dönüştürülüyor
    • hdiutil convert -format UDRW -o 018-66258-074-rw.dmg 018-66258-074.dmg
    • Mount edildikten sonra sudo mount -uw /Volumes/Sky19A404.N104N841OS
    • Değişikliklerden sonra hdiutil convert -format ULFO -o 018-66258-074.dmg 018-66258-074-rw.dmg
    • Ardından asr imagescan --source 018-66258-074.dmg
  • iOS önyüklemesinden önce kurtarma ramdisk’indeki /usr/local/bin/restored_external dosyasının değiştirilmesi gerekiyor
    • iOS sürümündeki restored_external, system keybag oluşturmak için MKBKeyBagCreateSystem çağırıyor ama bu macOS kernel’iyle uyumlu değil
    • Bu durum hata denetimini kaldırarak baypas ediliyor
    • ramrod_set_NVRAM_variable çağrısının koşulu yamalanarak allow-root-hash-mismatch true yani 1 yapılıyor ve root hash doğrulaması atlanıyor
  • Kurtarma ramdisk’indeki /usr/sbin/asr da değiştirilmek zorunda
    • Bunun için iSuns9’un asr64_patcher aracı kullanılabiliyor
    • "Image failed signature verification." dizesini yazdıran fonksiyon bulunuyor ve bunu referans alan fonksiyonda ARMv8-A BL çağrısı, "Image passed signature verification" yoluna giden bir B sıçramasına çevriliyor
    • iOS 15.0.2’nin asr ikilisinde dosya ofseti 0x27A18 için b #0x7c uygulanıyor

iOS sistem volume’ünü değiştirme

  • iOS sisteminin kendisini macOS kernel’iyle uyumlu hâle getirmek için, sistem volume’ündeki dosya sistemi köküne kurulacak dosyaların çoğu /System/Library/Templates/Data altına taşınmalı
  • Sistem açıldığında bu dosyalar / altında mevcut oluyor
  • Normal kökteki boş klasörlerin, gerçekte boş olsalar bile sistem volume’ünde bırakılması gerekebilir
    • Örnek: /Applications
    • Bu bölüm yeterince test edilmiş değil

launchd ve keybagd yamaları

  • iOS açılışının erken aşamalarında /sbin/launchd çalışıyor ve ilk boot sürecinin hatasız başlaması için yamalanması gerekiyor
  • İlk yama, ikili içine gömülü yapılandırma plist’ine uygulanıyor
    • <key>SIGTERMTimeout</key> dizesi bulunup yaklaşık 172 bayt öncesine bakıldığında ilgili yapılandırma görülebiliyor
    • mount-phase-2, fips, tzinit, finish-demo-restore, fud, xpcroleaccountd, prng_seedctl, MSUEarlyBootTask bölümlerine <key>PerformAfterUserspaceReboot</key><true/> ekleniyor
    • data-protection bölümündeki RequireSuccess değeri <false/> olarak değiştiriliyor
  • data-protection değişikliği gerekli çünkü /usr/libexec/init_data_protection, VM içinde çalıştırıldığında başarısız oluyor
    • Bu dosya /usr/libexec/seputil için sembolik bağlantı
  • Gömülü plist’i değiştirirken mevcut string alanı aşılabileceğinden, XML minimizer ile sıkıştırılmış XML yapıştırılıp kalan alan XML dostu boşluk karakterleriyle doldurulabiliyor
  • launchd, /usr/libexec/keybagd dosyasını da başlatıyor ancak bu ikili önceki kernel farkları nedeniyle başarısız oluyor
    • Baypas yöntemlerinden biri, yalnızca çıkış kodu 0 ile sonlanan bir çalıştırılabilir dosya derleyip keybagd yerine koymak
    • fixkeybag projesi de incelendi, ancak onun system keybag oluşturma kodu da MKBKeyBagCreateSystem çağırdığından, boot edilmiş iOS durumunda bile başarısız oluyor
  • launchd için ayrıca Userspace reboot changed system version: previous %s != current %s panic dizesine yol açan koşullu TBZ dalını NOP yapacak ek yama gerekiyor

mount, DYLD shared cache ve grafik katmanı değişiklikleri

  • Geri yükleme işlemi macOS boot chain’i ve macOS ramdisk’iyle yapıldığından, iOS’taki /sbin/mount oluşturulan APFS volume’lerini düzgün ele alamıyor
  • Çözüm, macOS sistem volume’ündeki mount ikilisini alıp Mach-O metadata’sını iOS’te çalışabilir olacak şekilde değiştirerek yerine koymak
    • Bu işlem elle yapılabilir; macOS içindeki vtool da kullanılabilir
  • Daha zor kısım DYLD shared cache yaması
    • macOS’taki IOSurfaceRoot ile iOS’taki IOCoreSurfaceRoot temelde aynı sürücü, ancak ad farkı yüzünden uyumsuzluk oluşuyor
    • iOS DYLD shared cache içinde daha uzun olan "IOCoreSurfaceRoot" dizesi bulunduğundan, bu "IOSurfaceRoot" ile değiştiriliyor ve kalan baytlar 0x00 ile dolduruluyor
  • DYLD shared cache analizi ve çıkarımı için blacktop’un ipsw aracı kullanılıyor
    • ipsw dyld split <dsc file> ile gömülü dylib’ler ayrılıyor
    • /System/Library/Frameworks/IOSurface.framework/IOSurface ikilisinde __iosConnectInitalize fonksiyonunun "IOCoreSurfaceRoot" referansı bulunuyor
    • ipsw dyld a2o ile sanal adres dosya ofsetine çevriliyor
    • Örnekte dyld_shared_cache_arm64e içindeki 0x28fde373 ofseti yamalanıyor
  • DYLD shared cache değiştirildikten sonra başka bir konumdaki cdhash uyuşmadığı için exception oluşuyor
    • Virtualization.framework frontend’inin verdiği GDB stub ile kernel’deki cs_validate_hash fonksiyonuna breakpoint konup tam cdhash okunuyor
    • iOS 15.0.2 örneğinde, dosya ofseti 0x5a9cffc0 içindeki eski baytlar yeni cdhash ile değiştiriliyor

Sistem daemon’ları ve aktivasyon yamaları

  • watchdogd, VM içinde çalıştığını doğrulayıp düzgün kapanan bir macOS kod yoluna sahip olmadığından crash-loop’a giriyor, ancak bu çökme zararsız kabul ediliyor
  • backboardd içinde, PreBoard.app ile ilişkili olabilecek veri migrasyonu çağrılarını yamalama denemeleri yapıldı ama Apple logosunda takılmak dışında belirgin bir fark görülmedi
  • lockdownd içindeki get_device_type_internal_block_invoke fonksiyonunda, "ShouldHactivate" için yapılan getMGInt çağrısı mov x0, #1 ile değiştirilerek geliştirme ortamında normal iOS aktivasyon kısıtlarını baypas eden hactivation zorlanıyor
  • mobileactivationd de hactivation’a izin verecek şekilde yamalanabiliyor
    • shouldHactivate fonksiyonu ARMv8-A komutları mov x0, #0 ve ret ile değiştiriliyor
  • vma2 device tree için gereken ek değişiklikler okuyucuya bırakılmış bir görev olarak duruyor
  • Bazı davranışlar için chmod -R 777 / gibi alışılmadık önlemler gerekebiliyor

Kalan sınırlamalar ve dokunmatik giriş

  • system keybag sorununu aşmak için iOS sistemi ve kernel içindeki ilgili yapının daha iyi anlaşılması ve ek yamalar geliştirilmesi gerekiyor
  • Bu projeye şimdiden en az yüzlerce saat harcandı ve şu an kamuya açık ilerleme seviyesi PreBoard.app aşamasına kadar önyükleme
  • Genel vma2 Mac kernel’i ve firmware’i üzerinden dokunmatik işlevin çalışıp çalışmadığı henüz doğrulanmadı
  • Virtualization.framework içinde dokunmatik ile ilgili özel API’ler bulunuyor
    • _VZAppleTouchScreenConfiguration
    • _VZUSBTouchScreenConfiguration
    • _VZTouch
    • _VZMultiTouchEvent
  • Bu API’lerle dokunmatik olayları gönderilebiliyor, ancak doğru parametrelerin nasıl kullanılacağı tam olarak çözülebilmiş değil
    • TouchPhase enum’u, NSTouch.Phase ile aynı isimlerde değerler içeren basit bir enum
    • Örnek kod bazen exception üretebiliyor
    • Koordinatların VM’in beklediği şekilde eşlenip eşlenmediği ve VM’in bunları işleyip işleyemediği de bilinmiyor
  • Demo, boot sırasını gösteriyor; ortadaki yaklaşık 30 saniyelik bekleme bölümü ise kesilmiş

İlgili okumalar

1 yorum

 
GN⁺ 2024-10-08
Hacker News yorumları

  • Corellium hukuki anlaşmazlığı kazandı; böylece güvenlik araştırmaları için iOS bulut VM kiralayabiliyor https://hn.algolia.com/?query=corellium
    Eğer iOS, Apple Silicon MacBook üzerinde sanallaştırılabiliyorsa ticari iOS sanallaştırma hizmetlerine olan talep azalabilir
    Bireyler için aylık 400 $, şirketler için yıllık 60.000 $ seviyesinde https://support.corellium.com/subscriptions/pricing

    • Vay canına, saatlik 4~8 $ iken bu tür VM’lere kimin para verdiğini merak ediyorum

  • Güzel. Sıradaki adım iPad’e macOS kurmanın yolunu da bulmak olsun; böylece Apple’ın yapmasını beklediğim o bilgisayarı sonunda kullanabilelim

    • Windows XP ile başlayabilirsiniz
      https://www.theverge.com/2024/7/22/24200536/windows-xp-ipad-...
    • Önceki çalışmalara göre [Zhuowei Zhang], GUI tabanlı macOS uygulamalarının iOS’ta çalışamayacağı, ancak grafik tabanlı iOS uygulamalarının macOS’ta çalışabileceği sonucuna varmış
      Görünüşe göre Mac Catalyst de beklendiği gibi yalnızca tek yönde çalışıyor
    • Buna gerçekten 1000 kez katılıyorum. Son birkaç haftadır tam da bu konuyu, yani üzerinde geliştirme amaçlı bir işletim sistemi çalışan bir tablet arıyordum
      Boyut olarak iPad Mini iyi görünüyor ama iPadOS işe yaramaz; şu anda Surface Go’ya bakıyorum. Yalnız biraz büyük
      macOS’li bir ürün olmadığını biliyorum ama küçük, Win11 çalıştırabilen tablet öneriniz varsa duymak isterim. Gerekirse Çin’den sipariş vermeyi bile düşünüyorum
    • iPad Pro, M4’lü en hızlı cihaz
    • Ona üstü altı ters çevrilmiş çıkıntılı ve ayrılabilir klavyeli bir MacBook Air dersek yeterli olur mu?

  • Yazarın GitHub profiline baktım; sanırım yeni mezun bir bilgisayar mühendisliği öğrencisi ve gerçekten etkileyici bir iş çıkarmış

    • Apple’dan yakında bir iş teklifi gelebilir diye düşünüyorum

  • Apple’ın Simulator’ü Emulator yapmamasının nedeni, insanların iOS’un dahili temel katmanlarını kurcalamasını istememesi gibi geliyor

    • En başta Simulator olup Emulator olmamasının bir başka nedeni de, o dönemde iOS veya iPhone OS’nin birçok bileşeninin mevcut Mac OS X kütüphanelerinin fork’u olması olabilir
    • Geliştiriciler hâlâ Intel Mac kullanıyor ve orada ARM iOS sanallaştırılamaz
    • Artık iPhone, Mac ve iPad’in hepsi arm64, üstelik Apple Silicon tabanlı olduğuna göre iOS ile macOS’un bootloader’larının ne kadar farklı olduğunu gerçekten merak ediyorum
      Bootloader aşaması geçildikten sonra, özellikle Apple donanımı da kontrol ediyorken, iki işletim sistemi arasında bu kadar çok farkı sürdürmek için gerçekten bir neden olup olmadığını sorguluyorum

  • qemu-t8030’u yapan kişi SpringBoard’u çalıştırmayı başardı https://mastodon.social/@ntrung03/109712247237110967 ama kodu paylaşmadı
    O ilerleme bu çalışmayla birleştirilebilirse harika olur

  • Geçmiş yorumlar: https://news.ycombinator.com/item?id=40219423

  • İlgili yazı: https://worthdoingbadly.com/hv/
    Jailbreak yapılmış iPhone 12 / iOS 14.1 üzerinde donanım hızlandırmalı sanal makineleri ele alıyor

  • Biraz konu dışı ama birinin ARM macOS’u x86-64 üzerinde sanallaştırıp sanallaştıramadığını merak ediyorum

    • Mümkün değil. Genel olarak “sanallaştırma”, işletim sisteminin donanım sanallaştırması üzerinden çalıştırılması anlamına gelir; ana makine CPU’su kodu yerel olarak yürütür ve tüm G/Ç’yi hipervizöre devreder
      Bu yüzden yalnızca ana makine sistemiyle aynı CPU mimarisi için derlenmiş işletim sistemleri sanallaştırılabilir
      ARM yazılımını x86’da ya da tersini çalıştırmak gibi diğer tüm durumlarda emülasyon gerekir; bu da kodu yorumlayarak veya dinamik olarak yeniden derleyerek yapılır
      Tanım gereği teoride her şey başka bir şeyin üzerinde emüle edilebilir. Yakın zamanda ilk mikroişlemci olan Intel 4004 üzerinde MIPS için Linux önyükleyenler bile oldu, ama performans sorun olabilir
    • QEMU’da genel ARM sanallaştırmasını denerseniz performansın Raspberry Pi’nin bile altında kaldığını görebilirsiniz. Son sürümlerde varsayılan olarak bulunuyor olmalı
      Mn CPU sanallaştırmak ise daha da az kullanışlı olurdu sanırım
    • Hackintosh projelerine bakabilirsiniz

  • Apple zaten Xcode’da iOS Simulator sunuyor; bu projenin Apple’ın sağladığı araçlardan ne açıdan daha iyi olduğunu merak ediyorum

    • Simulator, gerçek iOS’u veya uygulamanın iOS derlemesini çalıştırmaz. Bir uygulamayı Simulator’de çalıştırdığınızda uygulama mevcut Mac’in yerel komut kümesi için derlenir; beklenen iOS davranışını taklit eden ya da bazı bölümleri sadece kabuk olarak sunan Mac framework ve kütüphanelerine bağlanarak çalışır
      Örneğin App Store’dan bir iOS ikili dosyası alıp onu doğrudan iOS Simulator’de çalıştıramazsınız; özellikle Intel Mac’te hiç çalıştıramazsınız
      Simulator tam bir iOS çalıştırmadığı için gerçek iOS’un iç yapısının nasıl işlediğini inceleyip öğrenemezsiniz. Simulator framework’lerini yeterince derine kazarsanız sonunda yine macOS’a ulaşırsınız
      Buna karşılık emülatör, gerçek cihazla aynı tam iOS derlemesini çalıştırır. Teorik olarak herhangi bir iOS ikili dosyasını değiştirmeden çalıştırabilir ve gerçek işletim sisteminin nasıl davrandığını araştırabilirsiniz
      Bu, Wine ile uygulama çalıştırmak ile bir Windows VM içinde uygulama çalıştırmak arasındaki farka benzer. Yalnız Simulator durumunda, Windows uygulamasını çalıştırmadan önce onu Wine ortamına uygun şekilde ayrıca yeniden derleyip bağlamanız gereken bir duruma daha yakındır
      Windows’un iç yapısını araştırmak istiyorsanız yalnızca Wine üzerinde çalıştırarak öğreneceğiniz şey sınırlı olur; ama bir Windows VM’i incelerseniz çok daha fazlasını öğrenebilirsiniz

  • Click farm’lar için erken bir Noel hediyesi olur