Apple silicon पर iOS का वर्चुअलाइजेशन

 (nickb.website)
2 पॉइंट द्वारा GN⁺ 2024-10-08 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • यह Apple silicon Mac के Virtualization.framework और vma2 environment का उपयोग करके iOS 15.0.2 iPhone XR build को PreBoard.app तक boot कराने का एक प्रयोग है
  • approach का core यह है कि macOS 12.0.1 boot chain को reuse किया जाए और केवल iOS system image, mtree, root_hash, trustcache को replace करके शुरुआती boot chain modification का बोझ कम किया जाए
  • private _setProductionModeEnabled(false) call से VM को CPFM 01 state तक नीचे लाने पर, public vma2 device के लिए TSS arbitrary firmware को sign करता है, जिससे मौजूदा vma2pwn तरीके की जरूरत कम हो जाती है
  • वास्तविक booting के लिए XNU platform check, system keybag, IOMFB size check, ramdisk, launchd, mount, DYLD shared cache, lockdownd, mobileactivationd को छूने वाले kernel और system patches की जरूरत होती है
  • सबसे बड़ा unresolved challenge system keybag compatibility है, और touch input भी Virtualization.framework की private API से संभव होगा या नहीं, यह अभी confirm नहीं है

प्रयोग का लक्ष्य और शुरुआत

  • Apple silicon transition और Mac Catalyst के बाद iOS और macOS के बीच दूरी कम हुई, और macOS virtualization संभव होने के साथ core question यह बना कि क्या iOS को भी उसी family की boot chain modify करके virtualize किया जा सकता है
  • पिछला काम vma2pwn macOS guest VM के लिए modifiable vma2 macOS boot chain बनाने का project था, और यही इस experiment का base बना
  • publicly complete iOS virtualization/emulation example के रूप में Corellium का virtual iPhone cloud product मौजूद है
  • qemu-t8030, QEMU-based work और Zhuowei Zhang के लेख का भी reference लिया गया; खासकर macOS के IOSurfaceRoot और iOS के IOCoreSurfaceRoot का relation बाद में kernel patch खोजने में मददगार रहा
  • Zhuowei Zhang के लेख ने माना कि GUI macOS apps iOS पर नहीं चल सकते, लेकिन graphical iOS apps macOS पर चल सकते हैं, और यह property iOS graphics system के बड़े हिस्से पर भी लागू होती है

Virtualization.framework की private capabilities

  • Apple के Virtualization.framework में undocumented private function _setProductionModeEnabled(false) है
  • यह call और VM settings की corresponding capability VM को Chip Fuse Mode यानी CPFM 01 तक नीचे लाती है, जिससे virtual device “secure” लेकिन “non-production” state में configure होता है
  • physical devices पर TSS, CPFM 00 या 01 जैसे non-production/non-secure devices के लिए जरूरी SHSH blob signing को reject करता है
  • public vma2 device के लिए TSS supplied arbitrary firmware को sign करता है, इसलिए modified firmware chain बनाने वाले vma2pwn approach की जरूरत काफी कम हो जाती है

iOS VM configuration approach

  • सबसे successful approach macOS 12.0.1 boot chain को जस का तस रखना और system OS image को iOS 15.0.2 iPhone XR build की image और related files से replace करना था
    • replace किए जाने वाले targets: system image, mtree, root_hash, trustcache
    • यह तरीका iOS initialization से पहले के boot chain और recovery ramdisk modification की जरूरत को अधिकांशतः bypass करता है
  • iPhone XR build को arm64e support और lower resolution की संभावना के कारण चुना गया
  • अन्य arm64e device configurations में भी सफलता की संभावना है, लेकिन vma2 kernel कुछ sysctl keys के लिए "iPad8,6" return करने के लिए hardcoded है
  • arm64 builds ने additional issues और binary incompatibility झेली, इसलिए उन्हें try करना कम worthwhile माना गया
  • VM run करने के लिए Apple silicon VM management की third-party app tart का fork super-tart इस्तेमाल हुआ
    • super-tart Virtualization.framework की जरूरी private capabilities इस्तेमाल करने देता है
    • _setProductionModeEnabled(false) setting change समेत कुछ changes अभी push नहीं किए गए हैं
    • private API इस्तेमाल करने वाले Virtualization.framework tools के लिए SIP बंद करना पड़ता है, और AMFI भी बंद करना पड़ सकता है
  • restore tool के रूप में idevicerestore fork इस्तेमाल हुआ

Kernel patches

  • vma2pwn में इस्तेमाल signature check patch की जरूरत हो सकती है, लेकिन CPFM 01 approach में यह अनिवार्य है या नहीं, यह पक्का नहीं है
  • signature-related patches vma2 kernel में नीचे दिए functions को 0 return कराने के रूप में हैं
    • _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 को 1 return करने के लिए patch करना होगा
  • iOS binaries simulator platform binaries नहीं हैं, इसलिए शुरुआत में वे EXEC, [0xe] Binary with wrong platform के साथ terminate होते हैं
    • XNU की PLATFORM_IOS check line skip करने के लिए patch करने पर यह solve होता है
    • vma2 kernel में इसे B.NE को B में बदलकर apply किया गया
  • system keybag incompatibility के कारण PreBoard.app, Setup.app की जगह “Swipe up to upgrade.” दिखाता है
    • ipc_make_system_keybag पर दो patches apply करके function को error return न करने के लिए force करने पर PreBoard.app तक पहुंचना संभव है
    • यह limitation अभी पूरी तरह solve नहीं हुई है
  • iOS system framework और macOS kernel के बीच IOMFB structure size mismatch CLCDTransaction size mismatch. Returning error 0x%X. string के साथ kernel panic पैदा करता है
    • IOMobileFramebufferUserClient::swap_submit की size check हटाने पर panic रुक जाता है

System file patches की तैयारी

  • recovery ramdisk और iOS system files signed हैं, इसलिए patch के बाद फिर से sign न करने पर execution के समय terminate हो जाते हैं
  • modified environment में Procursus का ldid इस्तेमाल करने का सुझाव दिया गया है
    • install example: brew install ldid-procursus
    • re-sign example: ldid_macosx_arm64 -S -M <binary>
    • -S binary को pseudo-sign करता है, और -M existing entitlements preserve करता है
  • कई binaries identity check करती हैं, इसलिए re-sign करने से पहले name को identity में बदलकर फिर original name पर वापस करना पड़ता है
    • keybagd में codesign -d -v keybagd से Identifier=com.apple.keybagd confirm होता है
    • mv keybagd com.apple.keybagd
    • ldid_macosx_arm64 -S -M com.apple.keybagd
    • mv com.apple.keybagd keybagd
  • जिन functions पर symbols automatically attached नहीं होते, उन्हें string XRef खोजकर और logging call references के जरिए caller functions trace करके पाया जा सकता है
  • serial terminal में interactive shell पाने के लिए Bash और LaunchDaemon port किए जा सकते हैं
    • Procursus जैसे version-compatible iOS jailbreak payload से related files copy करने की method इस्तेमाल हुई

DMG और ramdisk modification

  • system या recovery ramdisk patch करने के लिए DMG volume को directly modify करना होगा
  • iOS 15.0.2 example में IPSW में शामिल iOS System volume को read/write capable form में convert किया गया
    • hdiutil convert -format UDRW -o 018-66258-074-rw.dmg 018-66258-074.dmg
    • mount के बाद sudo mount -uw /Volumes/Sky19A404.N104N841OS
    • modification के बाद hdiutil convert -format ULFO -o 018-66258-074.dmg 018-66258-074-rw.dmg
    • फिर asr imagescan --source 018-66258-074.dmg
  • iOS boot से पहले recovery ramdisk के /usr/local/bin/restored_external को modify करना जरूरी है
    • iOS version का restored_external, MKBKeyBagCreateSystem से system keybag बनाने की कोशिश करता है, लेकिन macOS kernel से compatible नहीं है
    • error check हटाकर इसे bypass किया गया
    • ramrod_set_NVRAM_variable call condition को patch करके allow-root-hash-mismatch को true, यानी 1, set किया गया और root hash authentication skip किया गया
  • recovery ramdisk के /usr/sbin/asr को भी modify करना होगा
    • iSuns9 का asr64_patcher इस्तेमाल किया जा सकता है
    • "Image failed signature verification." string print करने वाले function को खोजें, और उसे reference करने वाले function में ARMv8-A BL call को "Image passed signature verification" path पर जाने वाले B jump में बदलें
    • iOS 15.0.2 के asr binary में file offset 0x27A18 पर b #0x7c apply किया गया

iOS system volume modification

  • iOS system को macOS kernel से match कराने के लिए, system volume में filesystem root पर install होने वाली अधिकांश files को /System/Library/Templates/Data में move करना होगा
  • system boot होने पर ये files / में मौजूद होंगी
  • normal root के empty folders को भले ही वे वास्तव में खाली हों, system volume में रहना पड़ सकता है
    • example के तौर पर /Applications है
    • यह हिस्सा पर्याप्त रूप से test नहीं किया गया

launchd और keybagd patches

  • iOS boot के शुरुआती चरण में /sbin/launchd execute होता है, और बिना failure initial boot process शुरू करने के लिए patching जरूरी है
  • पहला patch binary में embedded settings plist पर apply होता है
    • <key>SIGTERMTimeout</key> string खोजें और लगभग 172 bytes पहले देखें तो वह setting मिल सकती है
    • mount-phase-2, fips, tzinit, finish-demo-restore, fud, xpcroleaccountd, prng_seedctl, MSUEarlyBootTask sections में <key>PerformAfterUserspaceReboot</key><true/> जोड़ें
    • data-protection section के RequireSuccess को <false/> में बदलें
  • data-protection change इसलिए जरूरी है क्योंकि /usr/libexec/init_data_protection VM में run होने पर fail होता है
    • यह file /usr/libexec/seputil पर symbolic link है
  • embedded plist change existing string space से आगे जा सकता है, इसलिए XML minimizer से compressed XML paste करके बची हुई जगह XML-friendly whitespace characters से overwrite की जा सकती है
  • launchd, /usr/libexec/keybagd को भी initialize करता है, लेकिन यह binary पहले बताए kernel differences के कारण fail होती है
    • workaround में से एक है ऐसा executable compile करना जो बस exit code 0 के साथ समाप्त हो, और उससे keybagd replace कर देना
    • fixkeybag project भी review किया गया, लेकिन उस app का system keybag creation code भी MKBKeyBagCreateSystem call करता है, इसलिए booted iOS state में भी fail होता है
  • launchd में Userspace reboot changed system version: previous %s != current %s panic string trigger करने वाली conditional branch TBZ को NOP करने वाला additional patch जरूरी है

mount, DYLD shared cache, graphics layer modification

  • macOS boot chain और macOS ramdisk से restore process handle होने के कारण, iOS का /sbin/mount generated APFS volumes को ठीक से handle नहीं कर पाता
  • solution है macOS system volume से mount binary लाना, उसकी Mach-O metadata को iOS में executable बनाने के लिए modify करना, और फिर उसे replace करना
    • यह manually भी possible है और macOS में शामिल vtool भी इस्तेमाल किया जा सकता है
  • ज्यादा कठिन modification DYLD shared cache patch है
    • macOS का IOSurfaceRoot और iOS का IOCoreSurfaceRoot मूलतः वही driver हैं, लेकिन नाम के अंतर के कारण compatible नहीं हैं
    • iOS DYLD shared cache में लंबी string "IOCoreSurfaceRoot" होती है, इसलिए इसे "IOSurfaceRoot" में बदलकर बाकी bytes को 0x00 से भरें
  • DYLD shared cache analysis और extraction के लिए blacktop का ipsw tool इस्तेमाल हुआ
    • ipsw dyld split <dsc file> से embedded dylib अलग करें
    • /System/Library/Frameworks/IOSurface.framework/IOSurface binary में __iosConnectInitalize function की "IOCoreSurfaceRoot" reference खोजें
    • ipsw dyld a2o से virtual address को file offset में convert करें
    • example में dyld_shared_cache_arm64e के 0x28fde373 offset को patch किया गया
  • DYLD shared cache modification के बाद दूसरी location पर cdhash mismatch होने से exception आता है
    • Virtualization.framework frontend द्वारा दिए गए GDB stub से kernel के cs_validate_hash function पर breakpoint लगाकर पूरा cdhash confirm करें
    • iOS 15.0.2 example में file offset 0x5a9cffc0 के existing bytes को नए cdhash से patch किया गया

System daemons और activation patches

  • watchdogd VM में चल रहा है या नहीं, यह check करता है और normal exit वाला macOS code path न होने से crash-loop पैदा करता है, लेकिन इस crash को harmless माना गया
  • backboardd में PreBoard.app trigger कर सकने वाले data migration related calls के patches experiment किए गए, लेकिन Apple logo पर रुकने के अलावा कोई difference confirm नहीं हुआ
  • lockdownd के get_device_type_internal_block_invoke function में "ShouldHactivate" के लिए getMGInt call को mov x0, #1 में patch करके development environment में normal iOS activation restrictions bypass करने वाला hactivation force किया गया
  • mobileactivationd को भी hactivation allow करने के लिए patch किया जा सकता है
    • shouldHactivate function को ARMv8-A instructions mov x0, #0 और ret में बदलें
  • vma2 device tree में जरूरी additional modifications reader के खुद handle करने के task के रूप में छोड़े गए हैं
  • कुछ behaviors के लिए chmod -R 777 / जैसे abnormal measures की जरूरत पड़ सकती है

बची हुई limitations और touch input

  • system keybag issue से आगे बढ़ने के लिए iOS system और kernel में मौजूद उस structure को और समझना होगा और additional patches बनाने होंगे
  • project में पहले ही कम से कम कई सौ घंटे लग चुके हैं, और current public progress PreBoard.app तक boot करने के level पर है
  • public vma2 Mac kernel और firmware के जरिए touch functionality काम करती है या नहीं, यह अभी confirm नहीं है
  • Virtualization.framework में touch-related private APIs हैं
    • _VZAppleTouchScreenConfiguration
    • _VZUSBTouchScreenConfiguration
    • _VZTouch
    • _VZMultiTouchEvent
  • इन APIs से touch events भेजे जा सकते हैं, लेकिन exact parameter usage पूरी तरह समझ में नहीं आया है
    • TouchPhase enum, NSTouch.Phase जैसे नाम वाले values implement करने वाला simple enum है
    • example code कभी-कभी exceptions बना सकता है
    • coordinate values VM की expected mapping से match होते हैं या VM उन्हें process कर सकता है या नहीं, यह भी confirm नहीं है
  • demo boot sequence दिखाता है, और बीच का लगभग 30-second wait section काट दिया गया है

संबंधित पढ़ाई

1 टिप्पणियां

 
GN⁺ 2024-10-08
Hacker News टिप्पणियाँ

  • Corellium ने कानूनी विवाद जीत लिया, जिससे वह security research के लिए iOS cloud VM किराये पर दे सकता है https://hn.algolia.com/?query=corellium
    अगर iOS को Apple Silicon MacBook पर virtualize किया जा सके, तो commercial iOS virtualization services की मांग घट सकती है
    व्यक्तिगत उपयोगकर्ताओं के लिए यह लगभग $400 प्रति माह और enterprises के लिए $60,000 प्रति वर्ष है https://support.corellium.com/subscriptions/pricing

    • हे भगवान, यह $4~$8 प्रति घंटा है; सोच रहा हूँ कि ऐसे VM के लिए कौन पैसा देता होगा

  • अच्छा है। अगली बार iPad पर macOS install करने का तरीका भी निकाल दें, ताकि हम आखिरकार वह computer इस्तेमाल कर सकें जिसे Apple से बनाने की उम्मीद थी

    • Windows XP से शुरुआत कर सकते हैं
      https://www.theverge.com/2024/7/22/24200536/windows-xp-ipad-...
    • prior work सेक्शन के मुताबिक, [Zhuowei Zhang] ने निष्कर्ष निकाला कि GUI macOS apps iOS पर नहीं चल सकते, लेकिन graphical iOS apps macOS पर चल सकते हैं
      लगता है Mac Catalyst भी अपेक्षा के अनुसार सिर्फ एक दिशा में ही काम करता है
    • इससे 1000 बार सहमत हूँ। पिछले कुछ हफ्तों से मैं ठीक इसी चीज़ की तलाश में था, यानी development OS चलाने वाला tablet
      आकार के हिसाब से iPad Mini अच्छा है, लेकिन iPadOS बेकार है, और अभी मैं Surface Go देख रहा हूँ। हालांकि वह थोड़ा बड़ा है
      पता है कि macOS वाला कोई product नहीं है, लेकिन अगर Win11 चलाने वाला छोटा tablet सुझा सकें तो अच्छा होगा। जरूरत पड़ी तो China से order करने को भी तैयार हूँ
    • iPad Pro, M4 वाला सबसे तेज़ device है
    • क्या उसे उल्टा लगा हुआ उभार और detachable keyboard वाला MacBook Air कह देना ही काफी है?

  • लेखक का GitHub profile देखकर लगता है कि वे अभी-अभी computer science graduate हुए हैं; वाकई प्रभावशाली काम है

    • लगता है Apple से hiring offer जल्द ही आ सकता है

  • मुझे लगता है Apple ने Simulator को Emulator इसलिए नहीं बनाया क्योंकि वे नहीं चाहते कि लोग iOS के internal base layers में खोदाई करें

    • इसके शुरू से Simulator होने और Emulator न होने की एक और वजह यह भी हो सकती है कि उस समय iOS या iPhone OS के कई components मौजूदा Mac OS X libraries के forks थे
    • developers अभी भी Intel Mac इस्तेमाल कर रहे हैं, और वहाँ ARM iOS को virtualize नहीं किया जा सकता
    • अब जब iPhone, Mac और iPad सभी arm64 हैं, वह भी Apple Silicon आधारित, तो सच में उत्सुकता है कि iOS और macOS के bootloaders कितने अलग हैं
      bootloader के बाद, खासकर जब Apple hardware तक नियंत्रित करता है, तो समझ नहीं आता कि दोनों operating systems और उनके बीच इतनी ज्यादा अलगियाँ बनाए रखने की जरूरत क्यों है

  • qemu-t8030 बनाने वाले व्यक्ति ने SpringBoard चलाने में सफलता हासिल की थी https://mastodon.social/@ntrung03/109712247237110967, लेकिन code public नहीं किया
    अगर वह progress इस काम के साथ मिल सके तो बढ़िया होगा

  • पिछली comments: https://news.ycombinator.com/item?id=40219423

  • संबंधित लेख: https://worthdoingbadly.com/hv/
    jailbroken iPhone 12 / iOS 14.1 पर hardware-accelerated virtual machine के बारे में है

  • थोड़ा off-topic है, लेकिन सोच रहा हूँ कि क्या किसी ने कभी ARM macOS को x86-64 पर virtualize किया है

    • असंभव है। आम तौर पर “virtualization” का मतलब hardware virtualization के जरिए operating system चलाना होता है, जहाँ host CPU code को natively execute करता है और सभी I/O hypervisor को सौंप देता है
      इसलिए केवल वही operating systems virtualize किए जा सकते हैं जो host system जैसी ही CPU architecture के लिए बने हों
      बाकी मामलों में, जैसे ARM software को x86 पर चलाना या उल्टा, emulation इस्तेमाल करनी पड़ती है, जिसमें code को interpret या dynamically recompile किया जाता है
      परिभाषा के हिसाब से किसी भी चीज़ को किसी भी दूसरी चीज़ पर emulate किया जा सकता है। हाल में पहले microprocessor Intel 4004 पर MIPS के लिए Linux boot करने का उदाहरण भी है, लेकिन performance समस्या हो सकती है
    • QEMU में generic ARM को virtualize करके देखें तो पता चलेगा कि performance Raspberry Pi से भी कम है। हाल की versions में यह default रूप से शामिल होना चाहिए
      Mn CPU को virtualize करना और भी कम उपयोगी लगेगा
    • Hackintosh projects देखना अच्छा रहेगा

  • Apple पहले से Xcode में iOS Simulator देता है; सोच रहा हूँ कि यह project Apple के tool से बेहतर क्या देता है

    • Simulator असली iOS या app का iOS build नहीं चलाता। Simulator में app चलाने पर app वर्तमान Mac के native instruction set के लिए compile होता है, और उन Mac frameworks और libraries से link होकर चलता है जो expected iOS behavior की नकल करते हैं या कुछ जगह सिर्फ shell provide करते हैं
      उदाहरण के लिए, आप App Store से iOS binary लेकर उसे iOS Simulator में सीधे नहीं चला सकते, खासकर Intel Mac पर तो बिल्कुल नहीं
      क्योंकि Simulator पूरा iOS नहीं चलाता, इसलिए आप असली iOS internals कैसे काम करते हैं, इसकी जांच और learning भी नहीं कर सकते। Simulator के frameworks में पर्याप्त गहराई तक जाएँ तो आखिरकार macOS पर वापस पहुँच जाते हैं
      इसके उलट emulator उसी पूरे iOS build को चलाता है जो real device पर होता है। सिद्धांत रूप में कोई भी iOS binary बिना modification के चल सकती है और असली operating system कैसे काम करता है, इसकी जांच की जा सकती है
      यह Wine में app चलाने और Windows VM में app चलाने के अंतर जैसा है। हालांकि Simulator के मामले में यह उस स्थिति के और करीब है जहाँ Windows app चलाने से पहले उसे Wine environment के लिए अलग से recompile और link करना पड़े
      अगर Windows internals का अध्ययन करना है, तो सिर्फ Wine में चलाकर बहुत कुछ सीखने को नहीं मिलेगा, लेकिन Windows VM की जांच करने पर कहीं ज्यादा सीखा जा सकता है

  • click farms के लिए यह जल्दी आया हुआ Christmas gift होगा