Memvirtualisasikan iOS di Apple silicon

 (nickb.website)
2 poin oleh GN⁺ 2024-10-08 | 1 komentar | Bagikan ke WhatsApp
  • Ini adalah eksperimen untuk mem-boot build iPhone XR iOS 15.0.2 hingga PreBoard.app dengan memanfaatkan Virtualization.framework di Apple silicon Mac dan lingkungan vma2
  • Inti pendekatannya adalah menggunakan kembali rantai boot macOS 12.0.1 dan hanya mengganti image sistem iOS, mtree, root_hash, dan trustcache untuk mengurangi beban modifikasi rantai boot awal
  • Dengan memanggil _setProductionModeEnabled(false) yang tidak dipublikasikan untuk menurunkan VM ke status CPFM 01, TSS akan menandatangani firmware arbitrer untuk perangkat vma2 publik, sehingga kebutuhan akan pendekatan vma2pwn lama berkurang
  • Booting aktual memerlukan patch kernel dan sistem yang menyentuh pemeriksaan platform XNU, system keybag, pemeriksaan ukuran IOMFB, ramdisk, launchd, mount, DYLD shared cache, lockdownd, dan mobileactivationd
  • Tantangan terbesar yang belum terpecahkan adalah kompatibilitas system keybag, dan belum dipastikan apakah input sentuh juga bisa dilakukan melalui API privat Virtualization.framework

Tujuan eksperimen dan titik awal

  • Setelah transisi ke Apple silicon dan hadirnya Mac Catalyst, jarak antara iOS dan macOS makin dekat, dan ketika virtualisasi macOS menjadi mungkin, pertanyaan utamanya adalah apakah iOS juga bisa divisualisasikan dengan memodifikasi rantai boot dari keluarga yang sama
  • Pekerjaan sebelumnya, vma2pwn, adalah proyek untuk membuat rantai boot macOS vma2 yang bisa dimodifikasi untuk guest VM macOS, dan menjadi fondasi eksperimen kali ini
  • Contoh virtualisasi/emulasi iOS yang selesai dan tersedia secara publik adalah produk virtual iPhone cloud milik Corellium
  • qemu-t8030, pekerjaan berbasis QEMU, dan tulisan Zhuowei Zhang juga dijadikan referensi; khususnya hubungan antara IOSurfaceRoot di macOS dan IOCoreSurfaceRoot di iOS membantu pencarian patch kernel berikutnya
  • Menurut tulisan Zhuowei Zhang, aplikasi macOS GUI tidak bisa dijalankan di iOS, tetapi aplikasi iOS grafis bisa dijalankan di macOS, dan sifat ini juga berlaku pada sebagian besar sistem grafis iOS

Fitur privat Virtualization.framework

  • Virtualization.framework milik Apple memiliki fungsi privat yang tidak terdokumentasi, _setProductionModeEnabled(false)
  • Panggilan ini dan fitur terkait dalam konfigurasi VM menurunkan VM ke CPFM 01 sebagai Chip Fuse Mode, sehingga perangkat virtual dikonfigurasi dalam keadaan “secure” namun “non-production”
  • Pada perangkat fisik, TSS menolak menandatangani SHSH blob yang dibutuhkan oleh perangkat non-production/non-secure seperti CPFM 00 atau 01
  • Untuk perangkat vma2 publik, TSS menandatangani firmware arbitrer yang diberikan, sehingga kebutuhan akan pendekatan vma2pwn untuk membuat rantai firmware yang dimodifikasi sangat berkurang

Cara menyusun VM iOS

  • Pendekatan yang paling berhasil adalah memakai rantai boot macOS 12.0.1 apa adanya, lalu mengganti image OS sistem dengan image dan file terkait dari build iPhone XR iOS 15.0.2
    • Yang diganti adalah image sistem, mtree, root_hash, dan trustcache
    • Pendekatan ini menghindari sebagian besar kebutuhan modifikasi pada rantai boot tahap sebelum inisialisasi iOS dan recovery ramdisk
  • Build iPhone XR dipilih karena dukungan arm64e dan kemungkinan resolusi yang lebih rendah
  • Konfigurasi perangkat arm64e lain mungkin juga bisa berhasil, tetapi kernel vma2 di-hardcode untuk mengembalikan "iPad8,6" pada beberapa kunci sysctl
  • Build arm64 dinilai kurang layak dicoba karena mengalami masalah tambahan dan inkompatibilitas biner
  • Untuk menjalankan VM digunakan super-tart, fork dari aplikasi pihak ketiga tart untuk pengelolaan VM Apple silicon
    • super-tart memungkinkan penggunaan fitur privat Virtualization.framework yang diperlukan
    • Sebagian perubahan seperti pengaturan _setProductionModeEnabled(false) belum semuanya di-push
    • Alat Virtualization.framework yang memakai API privat harus menonaktifkan SIP, dan mungkin juga AMFI
  • Sebagai alat restore digunakan fork idevicerestore

Patch kernel

  • Patch pemeriksaan tanda tangan yang digunakan di vma2pwn mungkin diperlukan, tetapi pada metode CPFM 01 belum pasti apakah wajib
  • Patch terkait tanda tangan berbentuk membuat fungsi-fungsi berikut mengembalikan 0 di kernel vma2
    • _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 perlu dipatch agar mengembalikan 1
  • Karena biner iOS bukan biner platform simulator, pada awalnya proses berakhir dengan EXEC, [0xe] Binary with wrong platform
    • Masalah ini bisa diatasi dengan mem-patch agar melewati baris pemeriksaan PLATFORM_IOS di XNU
    • Pada kernel vma2, ini dilakukan dengan mengubah B.NE menjadi B
  • Karena inkompatibilitas system keybag, PreBoard.app menampilkan “Swipe up to upgrade.” alih-alih Setup.app
    • Dengan menerapkan dua patch pada ipc_make_system_keybag agar fungsi tidak mengembalikan error, sistem bisa mencapai PreBoard.app
    • Batasan ini belum terselesaikan sepenuhnya
  • Ketidakcocokan ukuran struktur IOMFB antara framework sistem iOS dan kernel macOS menyebabkan kernel panic dengan string CLCDTransaction size mismatch. Returning error 0x%X.
    • Menghapus pemeriksaan ukuran di IOMobileFramebufferUserClient::swap_submit menghentikan panic tersebut

Menyiapkan patch file sistem

  • Recovery ramdisk dan file sistem iOS ditandatangani, sehingga setelah dipatch, biner akan berhenti saat dijalankan jika tidak ditandatangani ulang
  • Dalam lingkungan modifikasi, disarankan memakai ldid dari Procursus
    • Contoh instalasi: brew install ldid-procursus
    • Contoh penandatanganan ulang: ldid_macosx_arm64 -S -M <binary>
    • -S membuat pseudo-sign pada biner, dan -M mempertahankan entitlements yang ada
  • Banyak biner memeriksa identity, jadi sebelum ditandatangani ulang namanya perlu diubah ke identity lalu dikembalikan ke nama semula
    • keybagd memeriksa Identifier=com.apple.keybagd dengan codesign -d -v keybagd
    • mv keybagd com.apple.keybagd
    • ldid_macosx_arm64 -S -M com.apple.keybagd
    • mv com.apple.keybagd keybagd
  • Untuk fungsi tanpa simbol otomatis, bisa dicari dengan menemukan string XRef lalu menelusuri fungsi pemanggil lewat referensi pemanggilan logging
  • Untuk mendapatkan shell interaktif di terminal serial, Bash dan LaunchDaemon bisa di-port
    • Metode yang dipakai adalah menyalin file terkait dari payload jailbreak iOS yang kompatibel versinya seperti Procursus

Memodifikasi DMG dan ramdisk

  • Untuk mem-patch sistem atau recovery ramdisk, volume DMG harus dimodifikasi langsung
  • Pada contoh iOS 15.0.2, volume iOS System yang ada di IPSW diubah menjadi bentuk yang bisa dibaca/tulis
    • hdiutil convert -format UDRW -o 018-66258-074-rw.dmg 018-66258-074.dmg
    • Setelah di-mount: sudo mount -uw /Volumes/Sky19A404.N104N841OS
    • Setelah dimodifikasi: hdiutil convert -format ULFO -o 018-66258-074.dmg 018-66258-074-rw.dmg
    • Lalu: asr imagescan --source 018-66258-074.dmg
  • Sebelum iOS boot, /usr/local/bin/restored_external pada recovery ramdisk perlu dimodifikasi
    • restored_external versi iOS mencoba membuat system keybag dengan MKBKeyBagCreateSystem, tetapi tidak kompatibel dengan kernel macOS
    • Ini diakali dengan menghapus pemeriksaan error
    • Kondisi pemanggilan ramrod_set_NVRAM_variable dipatch untuk mengatur allow-root-hash-mismatch ke true, yaitu 1, dan melewati autentikasi root hash
  • /usr/sbin/asr pada recovery ramdisk juga harus dimodifikasi
    • Bisa menggunakan asr64_patcher dari iSuns9
    • Temukan fungsi yang mencetak string "Image failed signature verification.", lalu pada fungsi yang mereferensikannya ubah panggilan ARMv8-A BL menjadi lompatan B ke jalur "Image passed signature verification"
    • Pada biner asr iOS 15.0.2, patch b #0x7c diterapkan pada file offset 0x27A18

Memodifikasi volume sistem iOS

  • Agar sistem iOS sendiri cocok dengan kernel macOS, sebagian besar file yang akan dipasang di root filesystem pada volume sistem harus dipindahkan ke /System/Library/Templates/Data
  • Setelah sistem boot, file-file ini akan muncul di /
  • Folder kosong pada root biasa mungkin tetap harus ada di volume sistem meskipun benar-benar kosong
    • Salah satu contohnya adalah /Applications
    • Bagian ini belum diuji secara memadai

Patch launchd dan keybagd

  • Di awal boot iOS, /sbin/launchd dijalankan, dan agar proses boot awal berjalan tanpa gagal diperlukan patch
  • Patch pertama diterapkan pada plist konfigurasi yang tertanam di dalam biner
    • Cari string <key>SIGTERMTimeout</key>, lalu sekitar 172 byte sebelumnya ada konfigurasi terkait
    • Tambahkan <key>PerformAfterUserspaceReboot</key><true/> ke bagian mount-phase-2, fips, tzinit, finish-demo-restore, fud, xpcroleaccountd, prng_seedctl, dan MSUEarlyBootTask
    • Ubah RequireSuccess di bagian data-protection menjadi <false/>
  • Perubahan data-protection diperlukan karena /usr/libexec/init_data_protection gagal saat dijalankan di VM
    • File tersebut adalah symlink ke /usr/libexec/seputil
  • Mengubah plist tertanam bisa melewati ruang string yang tersedia, jadi XML yang dipadatkan dengan XML minimizer bisa ditempelkan dan sisa area ditimpa dengan karakter spasi yang ramah XML
  • launchd juga menginisialisasi /usr/libexec/keybagd, tetapi biner ini gagal karena perbedaan kernel tadi
    • Salah satu cara mengakalinya adalah mengompilasi executable pengganti yang cukup berakhir dengan exit code 0 lalu menggantikan keybagd
    • Proyek fixkeybag juga ditinjau, tetapi kode pembuatan system keybag pada aplikasi itu juga memanggil MKBKeyBagCreateSystem, sehingga tetap gagal bahkan pada iOS yang sudah boot
  • launchd juga memerlukan patch tambahan dengan menjadikan cabang kondisi TBZ yang memicu string panic Userspace reboot changed system version: previous %s != current %s menjadi NOP

Memodifikasi mount, DYLD shared cache, dan lapisan grafis

  • Karena proses restore ditangani oleh rantai boot macOS dan ramdisk macOS, /sbin/mount milik iOS tidak bisa menangani volume APFS yang dibuat dengan benar
  • Solusinya adalah mengambil biner mount dari volume sistem macOS, memodifikasi metadata Mach-O agar bisa dijalankan di iOS, lalu menggantinya
    • Ini bisa dilakukan manual, dan vtool bawaan macOS juga bisa dipakai
  • Modifikasi yang lebih sulit adalah patch DYLD shared cache
    • IOSurfaceRoot di macOS dan IOCoreSurfaceRoot di iOS pada dasarnya adalah driver yang sama, tetapi perbedaan nama membuatnya tidak kompatibel
    • Di DYLD shared cache iOS terdapat string yang lebih panjang, "IOCoreSurfaceRoot", sehingga string ini diubah menjadi "IOSurfaceRoot" dan byte sisanya diisi 0x00
  • Untuk analisis dan ekstraksi DYLD shared cache digunakan alat ipsw dari blacktop
    • Gunakan ipsw dyld split <dsc file> untuk memisahkan dylib tertanam
    • Di biner /System/Library/Frameworks/IOSurface.framework/IOSurface, cari referensi "IOCoreSurfaceRoot" dalam fungsi __iosConnectInitalize
    • Gunakan ipsw dyld a2o untuk mengubah alamat virtual menjadi file offset
    • Pada contoh ini, offset 0x28fde373 di dyld_shared_cache_arm64e yang dipatch
  • Setelah DYLD shared cache dimodifikasi, exception muncul karena cdhash di lokasi lain tidak lagi cocok
    • Dengan GDB stub yang disediakan frontend Virtualization.framework, breakpoint dipasang pada fungsi kernel cs_validate_hash untuk memeriksa seluruh cdhash
    • Pada contoh iOS 15.0.2, byte lama pada file offset 0x5a9cffc0 dipatch dengan cdhash baru

Daemon sistem dan patch aktivasi

  • watchdogd memeriksa apakah sistem berjalan di VM dan tidak punya jalur kode macOS untuk keluar normal, sehingga masuk crash-loop, tetapi crash ini dianggap tidak berbahaya
  • Di backboardd, pernah diuji patch pada pemanggilan terkait migrasi data yang bisa memicu PreBoard.app, tetapi selain berhenti di logo Apple tidak terlihat perbedaan lain
  • Pada fungsi get_device_type_internal_block_invoke di lockdownd, panggilan getMGInt untuk "ShouldHactivate" dipatch menjadi mov x0, #1 untuk memaksa hactivation dan melewati batasan aktivasi iOS biasa di lingkungan pengembangan
  • mobileactivationd juga bisa dipatch agar mengizinkan hactivation
    • Ubah fungsi shouldHactivate menjadi instruksi ARMv8-A mov x0, #0 dan ret
  • Modifikasi tambahan yang diperlukan pada device tree vma2 diserahkan sebagai tugas untuk pembaca
  • Untuk sebagian perilaku, mungkin diperlukan langkah tidak normal seperti chmod -R 777 /

Batasan yang tersisa dan input sentuh

  • Untuk melampaui masalah system keybag, perlu pemahaman yang lebih dalam tentang struktur terkait di sistem iOS dan kernel agar bisa membuat patch tambahan
  • Proyek ini sudah memakan setidaknya ratusan jam, dan status progres yang dipublikasikan saat ini baru mencapai boot hingga PreBoard.app
  • Belum dipastikan apakah fitur sentuh dapat berfungsi melalui kernel dan firmware Mac vma2 publik
  • Virtualization.framework memiliki API privat terkait sentuh
    • _VZAppleTouchScreenConfiguration
    • _VZUSBTouchScreenConfiguration
    • _VZTouch
    • _VZMultiTouchEvent
  • Dengan API ini event sentuh bisa dikirim, tetapi cara penggunaan parameter yang tepat belum sepenuhnya dipahami
    • Enum TouchPhase adalah enum sederhana yang mengimplementasikan nilai dengan nama yang sama seperti NSTouch.Phase
    • Kode contoh kadang dapat menimbulkan exception
    • Belum dipastikan apakah nilai koordinat dipetakan sesuai cara yang diharapkan VM, atau apakah VM bisa memprosesnya
  • Demo menunjukkan urutan boot, dan sekitar 30 detik waktu tunggu di tengah sudah dipotong

Bacaan terkait

1 komentar

 
GN⁺ 2024-10-08
Komentar di Hacker News

  • Corellium menang dalam sengketa hukum, sehingga bisa menyewakan VM cloud iOS untuk riset keamanan https://hn.algolia.com/?query=corellium
    Jika iOS bisa divirtualisasikan di MacBook Apple Silicon, permintaan untuk layanan virtualisasi iOS komersial bisa berkurang
    Harganya sekitar $400 per bulan untuk individu, dan $60.000 per tahun untuk perusahaan https://support.corellium.com/subscriptions/pricing

    • Astaga, harganya $4–$8 per jam; jadi penasaran siapa yang mau membayar untuk VM seperti ini

  • Bagus. Berikutnya semoga ada yang menemukan cara memasang macOS di iPad, supaya akhirnya kita bisa memakai komputer itu yang selama ini kita harapkan dibuat oleh Apple

    • Bisa mulai dari Windows XP
      https://www.theverge.com/2024/7/22/24200536/windows-xp-ipad-...
    • Menurut bagian penelitian sebelumnya, [Zhuowei Zhang] menyimpulkan bahwa aplikasi macOS berbasis GUI tidak bisa berjalan di iOS, tetapi aplikasi iOS grafis bisa berjalan di macOS
      Mac Catalyst tampaknya juga bekerja satu arah saja, seperti yang diperkirakan
    • Sangat setuju, sampai 1000 kali. Selama beberapa minggu terakhir saya memang mencari topik persis ini, yaitu tablet yang bisa menjalankan sistem operasi untuk pengembangan
      Dari segi ukuran, iPad Mini bagus, tetapi iPadOS tidak berguna; sekarang saya sedang melirik Surface Go. Hanya saja agak besar
      Saya tahu tidak ada produk dengan MacOS, tetapi kalau ada rekomendasi tablet kecil yang bisa menjalankan Win11, tolong beri tahu. Kalau perlu, saya juga bersedia memesannya dari Tiongkok
    • iPad Pro adalah perangkat tercepat yang memakai M4
    • Kalau disebut MacBook Air dengan tonjolan yang terbalik atas-bawah dan keyboard lepas-pasang, apakah itu sudah cukup?

  • Melihat profil GitHub penulisnya, sepertinya dia baru saja menjadi lulusan ilmu komputer, dan pekerjaannya benar-benar mengesankan

    • Sepertinya tawaran kerja dari Apple akan segera datang

  • Saya merasa alasan Apple tidak membuat Simulator menjadi Emulator adalah karena mereka tidak ingin orang-orang mengutak-atik lapisan dasar internal iOS

    • Alasan lain mengapa sejak awal ia berupa Simulator dan bukan Emulator mungkin karena saat itu banyak komponen iOS atau iPhone OS merupakan fork dari library Mac OS X yang sudah ada
    • Para developer masih memakai Intel Mac juga, dan di sana iOS ARM tidak bisa divirtualisasikan
    • Sekarang iPhone, Mac, dan iPad semuanya berbasis arm64, bahkan Apple Silicon, saya benar-benar penasaran seberapa berbedanya bootloader iOS dan macOS
      Setelah melewati bootloader, apalagi dalam situasi Apple juga mengendalikan perangkat kerasnya, saya bertanya-tanya apakah masih ada alasan kuat untuk terus mempertahankan banyak perbedaan antara kedua sistem operasi itu

  • Orang yang membuat qemu-t8030 berhasil menjalankan SpringBoard https://mastodon.social/@ntrung03/109712247237110967, tetapi tidak membuka kodenya
    Akan bagus jika kemajuan itu bisa digabungkan dengan pekerjaan ini

  • Komentar lama: https://news.ycombinator.com/item?id=40219423

  • Artikel terkait: https://worthdoingbadly.com/hv/
    Membahas mesin virtual berakselerasi perangkat keras pada iPhone 12 / iOS 14.1 yang sudah dijailbreak

  • Sedikit keluar topik, tetapi saya penasaran apakah pernah ada yang memvirtualisasikan macOS ARM di x86-64

    • Tidak mungkin. Secara umum, “virtualisasi” berarti menjalankan sistem operasi lewat virtualisasi perangkat keras, dengan CPU host menjalankan kode secara native sambil menyerahkan semua I/O ke hypervisor
      Karena itu, hanya sistem operasi yang dibangun untuk arsitektur CPU yang sama dengan sistem host yang bisa divirtualisasikan
      Untuk kasus lain, seperti menjalankan perangkat lunak ARM di x86 atau sebaliknya, harus memakai emulasi, yang bekerja dengan menginterpretasikan kode atau melakukan recompilation dinamis
      Secara definisi, apa pun bisa diemulasikan di atas apa pun. Belakangan ini bahkan ada contoh Linux untuk MIPS di-boot pada Intel 4004, mikroprosesor pertama, tetapi performa bisa menjadi masalah
    • Kalau mencoba memvirtualisasikan ARM biasa di QEMU, Anda akan melihat performanya bahkan tidak mencapai Raspberry Pi. Versi terbaru seharusnya sudah menyertakannya secara default
      Memvirtualisasikan CPU Mn tampaknya akan lebih tidak berguna lagi
    • Sebaiknya lihat proyek Hackintosh

  • Apple sudah menyediakan iOS Simulator di Xcode, jadi saya penasaran apa keunggulan proyek ini dibanding alat yang disediakan Apple

    • Simulator tidak menjalankan iOS asli atau build iOS dari aplikasi. Saat Anda menjalankan aplikasi di Simulator, aplikasi itu dikompilasi untuk instruction set native Mac saat ini, lalu dijalankan dengan terhubung ke framework dan library Mac yang meniru perilaku iOS yang diharapkan, atau sebagian hanya menyediakan shell kosong
      Misalnya, Anda tidak bisa mengambil binary iOS dari App Store lalu menjalankannya begitu saja di iOS Simulator, apalagi di Intel Mac
      Karena Simulator tidak menjalankan iOS secara penuh, Anda juga tidak bisa meneliti dan mempelajari bagaimana internal iOS sebenarnya bekerja. Jika Anda menggali framework Simulator cukup dalam, pada akhirnya Anda akan kembali ke macOS
      Sebaliknya, emulator menjalankan build iOS lengkap yang sama seperti perangkat sungguhan. Secara teori, binary iOS apa pun bisa dijalankan tanpa modifikasi, dan Anda bisa meneliti bagaimana sistem operasi sebenarnya bekerja
      Ini mirip perbedaan antara menjalankan aplikasi dengan Wine dan menjalankan aplikasi di VM Windows. Namun untuk Simulator, situasinya lebih mirip harus mengompilasi ulang dan menautkan aplikasi Windows secara terpisah agar sesuai dengan lingkungan Wine sebelum menjalankannya
      Jika ingin meneliti internal Windows, tidak banyak yang bisa dipelajari hanya dari menjalankannya di Wine, tetapi Anda bisa belajar jauh lebih banyak dengan meneliti VM Windows

  • Ini bakal jadi hadiah Natal lebih awal bagi para click farm