QEMU में iPhone एमुलेशन करना

 (eshard.com)
4 पॉइंट द्वारा GN⁺ 2025-04-07 | 1 टिप्पणियां | WhatsApp पर शेयर करें

iOS 14 QEMU एमुलेशन यात्रा की शुरुआत

  • मौजूदा open source प्रोजेक्ट alephsecurity/xnu-qemu-arm64 का इस्तेमाल किया, लेकिन यह read-only था इसलिए extensibility की कमी की समस्या थी
  • बाद में TrungNguyen1909/qemu-t8030 प्रोजेक्ट का उपयोग किया, जिससे निम्न फीचर इस्तेमाल किए जा सके:
    • iOS restore फीचर (USB कनेक्शन के लिए QEMU companion के साथ)
    • iOS 14 चलाना
    • नवीनतम QEMU version पर आधारित
    • विस्तृत wiki documentation उपलब्ध
  • launchd.plist में बदलाव करके shell और SSH access सफलतापूर्वक मिला, और इसे एक अच्छे शुरुआती बिंदु के रूप में इस्तेमाल किया गया
  • लक्ष्य UI और apps चला सकने वाला एक पूर्ण iOS emulation environment बनाना है

कर्नेल पैच और PongoOS का परिचय

  • t8030 प्रोजेक्ट की संरचना QEMU के अंदर kernel patching करने की थी → maintenance और extensibility की समस्याएँ थीं
  • jailbreak अनुभव के आधार पर PongoOS के जरिए checkra1n patches लागू करने वाली संरचना में बदलाव किया गया
  • QEMU में SRAM size बढ़ाकर PongoOS चलाया गया, और checkra1n-KPF module inject किया गया
  • boot के समय bootrom/iboot functionality की कमी से FPU configure न होने की समस्या आई → ARM documentation देखकर हल किया गया
  • A13 के बाद PAC(Pointer Authentication) आने से कुछ patches निष्प्रभावी हो गए
  • task_for_pid0 (tfp0) उदाहरण के जरिए PAC आने से पहले और बाद के binaries की तुलना की गई

kernel patch automation tool का विकास

  • मौजूदा checkra1n dynamic patching तरीका पढ़ने में कठिन और बदलने में असुविधाजनक था → declarative text-based patching तरीका अपनाया गया
  • दो Mach-O binaries की तुलना करके assembly differences निकाले गए और उनसे text patch बनाए गए
  • Pongo से boot करने के बाद memory dump लेकर kernel को फिर से assemble किया गया → पूरे patches को text files में व्यवस्थित और annotated किया गया

graphics rendering: Metal vs software rendering

  • iOS सभी UI rendering Metal API के जरिए करता है → GPU की आवश्यकता होती है
  • GPU emulation की जटिलता के कारण विकल्पों पर विचार किया गया:
    • software rendering
    • Metal calls को real device तक proxy के रूप में भेजना
  • iOS 14 में gpu=0 bootarg हटा दिया गया → QuartzCore का विश्लेषण करके fallback behavior की पुष्टि हुई
  • jailbroken phone पर QuartzCore patch करके software rendering के काम करने की पुष्टि हुई (धीमा है, लेकिन संभव है)
  • Metal proxy तरीका भी आज़माया गया, लेकिन Objective-C और API की जटिलता के कारण रोक दिया गया

framebuffer और IOSurface debugging

  • t8030 QEMU में framebuffer implementation नहीं था → ChefKissInc/QEMUAppleSilicon fork का उपयोग किया गया
  • शुरुआती boot में Apple logo और progress indicator दिखाई दिए, लेकिन उसके बाद black screen आई → debugging शुरू हुई
  • IOMFB kext विश्लेषण के नतीजे में दो mode पाए गए:
    • fixed address framebuffer (शुरुआती display के लिए)
    • DMA-based multi-plane configuration
  • system boot के दौरान DMA-based mode उपयोग में था → QEMU trace से kernel register configuration की पुष्टि की गई
  • लेकिन फिर भी स्क्रीन पर कोई output नहीं दिखा

address randomization निष्क्रिय करना

  • kernel address randomization को board initialization code में निष्क्रिय किया जा सकता था
  • user-space randomization को _load_machfile patch करके बंद किया गया
  • dyld cache एक बड़ा binary है जिसमें सभी dynamic libraries शामिल हैं → boot के समय fixed address पर load होता है
  • एक C tool बनाया गया जो dlopen के बाद _dyld_* functions से address की जाँच करता है
  • इससे GDB के जरिए dyld library debugging संभव हुई → खासकर IOMFB, SpringBoard, QuartzCore पर ध्यान दिया गया

USB log access और lockdownd bypass

  • real device पर idevicesyslog से system logs इकट्ठे किए जा सकते हैं → USB authentication की आवश्यकता होती है
  • lockdownd key storage के लिए SEP की जरूरत वाले keybag का उपयोग करता है → emulator में यह नहीं था
  • मौजूदा function की जगह shellcode डालकर key file से सीधे load कराया गया
  • USB से जुड़े QEMU के बीच key authentication bypass सफल रहा → logs इकट्ठे करना संभव हुआ
  • QuartzCore के सामान्य initialization और software rendering के उपयोग की पुष्टि हुई

PAC(Pointer Authentication) bypass

  • backboardd को modify करते समय PAC error आई → यह ARMv8.3 में जोड़ा गया security feature है
  • PAC instructions को NOP से बदलना बहुत अधिक intrusive था
  • PAC instructions को compatible mode में compile किया जा सकता है → QEMU में PAC को ignore करने पर execution संभव हुआ
  • QEMU 7 में PAC bypass संभव नहीं था → QEMU 8.2.1 पर migrate किया गया
  • Apple-specific instructions और GL exception level सहित QEMU के अनेक custom code को port करना पड़ा
  • परिणामस्वरूप QEMU 8 में iOS boot सफल हुआ और PAC को निष्प्रभावी करना संभव हो गया

backboardd और graphics output की पुष्टि

  • backboardd चल रहा था, लेकिन स्क्रीन पर display नहीं था → कई संभावित कारण मौजूद थे
  • DMA memory dump लेने पर भी कोई meaningful output नहीं मिला
  • iosurface_lock में address की पुष्टि करके frame dump लिया गया, लेकिन लगता था कि compressed form में GPU को भेजा जा रहा है
  • iPhone X (t8015) में uncompressed output की पुष्टि हुई → QEMU के DTB में chip-id को t8030 → t8015 में बदला गया
  • परिणामस्वरूप boot के बाद Apple logo प्रदर्शित हुआ

progress bar और system errors का पता लगाना

  • logo के बाद सफेद progress bar दिखी → 90% पर रुक गई
  • log analysis से mobileactivationd और SpringBoardFoundation समस्याएँ मिलीं → patch के बाद UI बदला
  • progress रुकने की समस्या हल करने के लिए बड़ी संख्या में system logs का विश्लेषण आवश्यक था

dyld cache और user-space patch automation

  • kernel की तरह user space में भी text-based patching तरीका इस्तेमाल किया गया
  • dyld cache का आकार 2GB था, इसलिए modification अप्रभावी था → internal tools को बेहतर बनाया गया ताकि:
    • dyld के अंदर offsets track किए जा सकें
    • dd command से specific positions पर सीधे patch किया जा सके
  • साथ ही kernel signature check bypass patch भी आवश्यक था

PreBoard चलाना और UI की पुष्टि

  • PreBoard app एक system app है जो errors होने पर दिखाई देता है → इसे सीधे चलाया जा सकता था
  • VNC server जोड़कर keyboard से screen unlock करने की कोशिश की गई
  • unlock के बाद vImage framework ने AMX(Apple Matrix Coprocessor) instructions का उपयोग किया → QEMU में unsupported था
  • vImage के software fallback path पर patch करके समस्या हल की गई
  • patch के बाद text input संभव वाले screen तक display सफल रहा

निष्कर्ष

  • SpringBoard चलने से ठीक पहले तक पहुँचा गया → अब पूर्ण UI execution केवल समय की बात है
  • kernel, user space, graphics, security features (PAC आदि) पर बहु-आयामी विश्लेषण और patches किए गए
  • QEMU-आधारित व्यावहारिक iOS app debugging और testing environment की संभावना की पुष्टि हुई

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

1 टिप्पणियां

 
GN⁺ 2025-04-07
Hacker News राय
  • उम्मीद है कि https://github.com/devos50/qemu-ios प्रोजेक्ट इतना विकसित हो कि iPhone OS 3.x को सपोर्ट कर सके। इससे शुरुआती iPhone ऐप्स को digital preservation के लिए अनुभव किया जा सकेगा
  • https://github.com/touchHLE/touchHLE भी शानदार है, लेकिन default apps के अलावा बाकी के लिए patch की ज़रूरत पड़ती है
  • https://github.com/TrungNguyen1909/qemu-t8030/… के निर्देशों का पालन करके चलाया, लेकिन कई बार crash हुआ। फिर भी काफ़ी शानदार है
  • मैंने QEMU से NumWorks N0100 और HP Prime G1 को emulate किया है। यह इतना सफल रहा कि official firmware चला सका
  • इस प्रोजेक्ट का मज़ेदार इस्तेमाल: अच्छे hardware support वाले फ़ोन पर postmarketOS इंस्टॉल करना, और QEMU का उपयोग करके Android फ़ोन पर iOS boot करना। QEMU को customize करके फ़ोन hardware को iOS VM तक pass through किया जा सकता है
  • सोच रहा हूँ कि क्या इसका मतलब है कि Apple hardware के बिना Linux सिस्टम पर Safari testing और iOS compilation किया जा सकता है
  • https://github.com/ChefKissInc/QEMUAppleSilicon
  • network connectivity का कोई ज़िक्र नहीं है। लगता है WiFi या cellular modem chipset को emulate नहीं किया जा रहा। सोच रहा हूँ कि emulated डिवाइस को इंटरनेट से कैसे जोड़ा जाएगा। शायद USB के जरिए Ethernet जैसा कोई तरीका हो
  • archived version: https://archive.ph/l1CwO
  • सोच रहा हूँ कि क्या इसे reproduce कर सकने वाला कोई repository है
  • सोच रहा हूँ कि Apple को multi-platform iOS development स्वीकार करने के लिए क्या चाहिए