การทำ Virtualization iOS บน Apple Silicon

 (nickb.website)
2 คะแนน โดย GN⁺ 2024-10-08 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • เป็นการทดลองบูตบิลด์ iOS 15.0.2 สำหรับ iPhone XR บน Mac Apple silicon โดยใช้ Virtualization.framework และสภาพแวดล้อม vma2 จนถึง PreBoard.app
  • แกนหลักของแนวทางนี้คือการนำ บูตเชน ของ macOS 12.0.1 มาใช้ซ้ำ แล้วเปลี่ยนเฉพาะอิมเมจระบบ iOS, mtree, root_hash, trustcache เพื่อลดภาระในการแก้ไขบูตเชนช่วงต้น
  • เมื่อเรียกใช้ฟังก์ชันที่ไม่เปิดเผยต่อสาธารณะ _setProductionModeEnabled(false) เพื่อลดสถานะ VM ลงเป็น CPFM 01 แล้ว TSS จะเซ็นเฟิร์มแวร์ใด ๆ ให้กับอุปกรณ์ vma2 แบบสาธารณะ ทำให้ความจำเป็นของวิธี vma2pwn เดิมลดลง
  • การบูตจริงต้องใช้ แพตช์ระดับเคอร์เนลและระบบ ที่แตะการตรวจสอบแพลตฟอร์มของ XNU, system keybag, การตรวจสอบขนาด IOMFB, ramdisk, launchd, mount, DYLD shared cache, lockdownd, mobileactivationd
  • ปัญหาที่ยังไม่แก้ไขที่ใหญ่ที่สุดคือ ความเข้ากันได้ของ system keybag และยังไม่ยืนยันว่าการป้อนข้อมูลแบบสัมผัสจะทำได้ผ่าน private API ของ Virtualization.framework หรือไม่

เป้าหมายและจุดเริ่มต้นของการทดลอง

  • หลังจากการเปลี่ยนผ่านสู่ Apple silicon และ Mac Catalyst ระยะห่างระหว่าง iOS กับ macOS ก็ใกล้ขึ้น และเมื่อสามารถทำ virtualization ของ macOS ได้ คำถามหลักจึงกลายเป็นว่า iOS จะถูกนำมาทำ virtualization ได้หรือไม่โดยแก้ไขบูตเชนตระกูลเดียวกัน
  • งานก่อนหน้านี้อย่าง vma2pwn เป็นโปรเจกต์สำหรับสร้าง บูตเชน vma2 macOS ที่แก้ไขได้สำหรับ VM แขก macOS และกลายเป็นพื้นฐานของการทดลองครั้งนี้
  • ตัวอย่างการทำ virtualization/emulation iOS ที่สำเร็จและเผยแพร่ต่อสาธารณะคือผลิตภัณฑ์ virtual iPhone cloud ของ Corellium
  • ยังอ้างอิง qemu-t8030, งานบน QEMU และบทความของ Zhuowei Zhang ด้วย โดยเฉพาะความสัมพันธ์ระหว่าง IOSurfaceRoot ของ macOS กับ IOCoreSurfaceRoot ของ iOS ที่ช่วยในการค้นหาแพตช์เคอร์เนลในภายหลัง
  • บทความของ Zhuowei Zhang มองว่าแอป macOS แบบ GUI ไม่สามารถรันบน iOS ได้ แต่แอป iOS แบบกราฟิกรันบน macOS ได้ และคุณสมบัตินี้ใช้ได้กับส่วนสำคัญของระบบกราฟิก iOS ด้วย

ฟีเจอร์ที่ไม่เปิดเผยต่อสาธารณะของ Virtualization.framework

  • Virtualization.framework ของ Apple มีฟังก์ชัน private ที่ไม่ได้อยู่ในเอกสารชื่อ _setProductionModeEnabled(false)
  • การเรียกนี้และฟีเจอร์ที่สอดคล้องกันในการตั้งค่า VM จะลด VM ลงเป็น Chip Fuse Mode หรือ CPFM 01 ทำให้อุปกรณ์เสมือนถูกตั้งค่าให้อยู่ในสถานะ “secure” แต่ “non-production”
  • บนอุปกรณ์จริง TSS จะปฏิเสธการเซ็น SHSH blob ที่จำเป็นสำหรับอุปกรณ์ non-production/non-secure เช่น CPFM 00 หรือ 01
  • แต่สำหรับ อุปกรณ์ vma2 แบบสาธารณะ TSS จะเซ็นเฟิร์มแวร์ใด ๆ ที่ส่งให้ ดังนั้นความจำเป็นของวิธี vma2pwn ที่เคยใช้สร้างเชนเฟิร์มแวร์ดัดแปลงจึงลดลงอย่างมาก

วิธีประกอบ VM iOS

  • แนวทางที่ประสบความสำเร็จมากที่สุดคือใช้บูตเชน macOS 12.0.1 ตามเดิม แล้วแทนที่อิมเมจระบบ OS ด้วยอิมเมจและไฟล์ที่เกี่ยวข้องจากบิลด์ iOS 15.0.2 สำหรับ iPhone XR
    • สิ่งที่ถูกแทนที่คืออิมเมจระบบ, mtree, root_hash, trustcache
    • วิธีนี้หลีกเลี่ยงความจำเป็นส่วนใหญ่ในการแก้ไขบูตเชนและ ramdisk กู้คืนก่อนขั้นตอน initialization ของ iOS
  • เลือกบิลด์ iPhone XR เพราะรองรับ arm64e และมีโอกาสใช้ความละเอียดต่ำกว่า
  • การตั้งค่าอุปกรณ์ arm64e แบบอื่นก็อาจสำเร็จได้ แต่เคอร์เนล vma2 ถูกฮาร์ดโค้ดให้คืนค่า "iPad8,6" สำหรับคีย์ sysctl บางตัว
  • ประเมินว่าบิลด์ arm64 ไม่คุ้มลอง เพราะเจอปัญหาเพิ่มเติมและความไม่เข้ากันของไบนารี
  • การรัน VM ใช้ super-tart ซึ่งเป็นฟอร์กของ tart แอป third-party สำหรับจัดการ VM บน Apple silicon
    • super-tart ทำให้ใช้ฟีเจอร์ private ที่จำเป็นของ Virtualization.framework ได้
    • การเปลี่ยนแปลงบางส่วน เช่น การตั้งค่า _setProductionModeEnabled(false) ยังไม่ได้ push ทั้งหมด
    • เครื่องมือ Virtualization.framework ที่ใช้ private API ต้องปิด SIP และอาจต้องปิด AMFI ด้วย
  • เครื่องมือ restore ที่ใช้คือ ฟอร์กของ idevicerestore

แพตช์เคอร์เนล

  • อาจต้องใช้แพตช์ตรวจสอบลายเซ็นที่ใช้ใน vma2pwn แต่ยังไม่แน่ชัดว่าในแนวทาง CPFM 01 จำเป็นเสมอไปหรือไม่
  • แพตช์ที่เกี่ยวกับลายเซ็นอยู่ในรูปแบบทำให้ฟังก์ชันต่อไปนี้ในเคอร์เนล vma2 คืนค่า 0
    • _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
  • เนื่องจากไบนารี iOS ไม่ใช่ไบนารีแพลตฟอร์ม simulator ช่วงแรกจึงถูกจบการทำงานด้วย EXEC, [0xe] Binary with wrong platform
    • แก้ได้โดยแพตช์ให้ข้ามบรรทัดตรวจสอบ PLATFORM_IOS ของ XNU
    • ในเคอร์เนล vma2 ใช้วิธีเปลี่ยน B.NE เป็น B
  • เนื่องจาก system keybag ไม่เข้ากัน PreBoard.app จึงแสดง “Swipe up to upgrade.” แทน Setup.app
    • หากใส่แพตช์สองรายการที่ ipc_make_system_keybag เพื่อบังคับไม่ให้ฟังก์ชันคืน error จะไปถึง PreBoard.app ได้
    • ข้อจำกัดนี้ยังไม่ได้รับการแก้ไขอย่างสมบูรณ์
  • ความไม่ตรงกันของขนาด struct IOMFB ระหว่างเฟรมเวิร์กระบบ iOS กับเคอร์เนล macOS ทำให้เกิด kernel panic พร้อมข้อความ CLCDTransaction size mismatch. Returning error 0x%X.
    • เมื่อลบการตรวจสอบขนาดใน IOMobileFramebufferUserClient::swap_submit แล้ว panic จะหยุดลง

การเตรียมแพตช์ไฟล์ระบบ

  • recovery ramdisk และไฟล์ระบบ iOS ถูกเซ็นไว้ ดังนั้นถ้าไม่เซ็นใหม่หลังแพตช์จะถูกจบการทำงานขณะรัน
  • ในสภาพแวดล้อมที่แก้ไข แนะนำให้ใช้ ldid ของ Procursus
    • ตัวอย่างการติดตั้ง: brew install ldid-procursus
    • ตัวอย่างการเซ็นใหม่: ldid_macosx_arm64 -S -M <binary>
    • -S จะ pseudo-sign ไบนารี และ -M จะคง entitlements เดิมไว้
  • ไบนารีจำนวนมากตรวจสอบ identity ดังนั้นก่อนเซ็นใหม่ต้องเปลี่ยนชื่อเป็น identity แล้วค่อยเปลี่ยนกลับเป็นชื่อเดิม
    • keybagd ตรวจพบ Identifier=com.apple.keybagd ด้วย codesign -d -v keybagd
    • mv keybagd com.apple.keybagd
    • ldid_macosx_arm64 -S -M com.apple.keybagd
    • mv com.apple.keybagd keybagd
  • ฟังก์ชันที่ไม่ได้ติดสัญลักษณ์โดยอัตโนมัติสามารถหาได้ด้วยการค้นหา string XRef แล้วไล่ตามฟังก์ชันที่เรียกผ่าน reference ของ logging call
  • สามารถพอร์ต Bash และ LaunchDaemon เพื่อให้ได้ shell ที่โต้ตอบได้ผ่าน serial terminal
    • วิธีที่ใช้คือคัดลอกไฟล์ที่เกี่ยวข้องจาก payload ของ iOS jailbreak ที่เข้ากันได้ตามเวอร์ชัน เช่น Procursus

การแก้ไข DMG และ ramdisk

  • หากต้องการแพตช์ระบบหรือ recovery ramdisk ต้องแก้ไขวอลุ่ม DMG โดยตรง
  • ในตัวอย่าง iOS 15.0.2 จะแปลงวอลุ่ม iOS System ที่อยู่ใน IPSW ให้เป็นรูปแบบอ่าน/เขียนได้
    • hdiutil convert -format UDRW -o 018-66258-074-rw.dmg 018-66258-074.dmg
    • หลังเมานต์แล้ว sudo mount -uw /Volumes/Sky19A404.N104N841OS
    • หลังแก้ไขแล้ว hdiutil convert -format ULFO -o 018-66258-074.dmg 018-66258-074-rw.dmg
    • จากนั้น asr imagescan --source 018-66258-074.dmg
  • ก่อนบูต iOS ต้องแก้ไข /usr/local/bin/restored_external ใน recovery ramdisk
    • restored_external เวอร์ชัน iOS พยายามสร้าง system keybag ด้วย MKBKeyBagCreateSystem แต่เข้ากันไม่ได้กับเคอร์เนล macOS
    • ใช้วิธีลบการตรวจสอบ error เพื่อหลีกเลี่ยง
    • แพตช์เงื่อนไขการเรียก ramrod_set_NVRAM_variable ให้ตั้ง allow-root-hash-mismatch เป็น true หรือ 1 แล้วข้ามการยืนยัน root hash
  • ต้องแก้ไข /usr/sbin/asr ใน recovery ramdisk ด้วย
    • สามารถใช้ asr64_patcher ของ iSuns9 ได้
    • ค้นหาฟังก์ชันที่พิมพ์สตริง "Image failed signature verification." แล้วในฟังก์ชันที่อ้างอิงถึงฟังก์ชันนั้น ให้เปลี่ยนคำสั่งเรียก BL ของ ARMv8-A เป็น jump แบบ B ที่ไปยังเส้นทาง "Image passed signature verification"
    • ในไบนารี asr ของ iOS 15.0.2 ให้ใช้ b #0x7c ที่ออฟเซ็ตไฟล์ 0x27A18

การแก้ไขวอลุ่มระบบ iOS

  • เพื่อปรับ iOS system เองให้เข้ากับเคอร์เนล macOS ต้องย้ายไฟล์ส่วนใหญ่ที่จะถูกติดตั้งที่ root ของไฟล์ซิสเต็มจากวอลุ่มระบบไปยัง /System/Library/Templates/Data
  • เมื่อระบบบูตแล้ว ไฟล์เหล่านี้จะปรากฏอยู่ที่ /
  • โฟลเดอร์ว่างใน root ปกติอาจต้องคงอยู่ในวอลุ่มระบบ แม้ว่าจะว่างจริงก็ตาม
    • ตัวอย่างคือ /Applications
    • ส่วนนี้ยังไม่ได้ทดสอบอย่างเพียงพอ

แพตช์ launchd และ keybagd

  • ในช่วงต้นของการบูต iOS จะรัน /sbin/launchd และต้องมีแพตช์เพื่อเริ่มกระบวนการบูตช่วงต้นได้โดยไม่ล้มเหลว
  • แพตช์แรกใช้กับ plist การตั้งค่าที่ฝังอยู่ในไบนารี
    • ค้นหาสตริง <key>SIGTERMTimeout</key> แล้วดูย้อนหลังไปประมาณ 172 ไบต์ จะพบการตั้งค่านั้น
    • เพิ่ม <key>PerformAfterUserspaceReboot</key><true/> ใน section mount-phase-2, fips, tzinit, finish-demo-restore, fud, xpcroleaccountd, prng_seedctl, MSUEarlyBootTask
    • เปลี่ยน RequireSuccess ใน section data-protection เป็น <false/>
  • การเปลี่ยน data-protection จำเป็นเพราะ /usr/libexec/init_data_protection ล้มเหลวเมื่อรันใน VM
    • ไฟล์ดังกล่าวเป็น symbolic link ไปยัง /usr/libexec/seputil
  • การเปลี่ยน plist ที่ฝังอยู่ในไบนารีอาจเกินพื้นที่สตริงเดิมได้ ดังนั้นสามารถบีบอัด XML ด้วย XML minimizer แล้ววาง XML ที่บีบอัด จากนั้นเขียนทับพื้นที่ที่เหลือด้วยอักขระช่องว่างที่เป็นมิตรกับ XML
  • launchd ยัง initialize /usr/libexec/keybagd ด้วย แต่ไบนารีนี้ล้มเหลวเพราะความแตกต่างของเคอร์เนลข้างต้น
    • วิธีเลี่ยงอย่างหนึ่งคือคอมไพล์ executable ที่เพียงจบด้วย exit code 0 แล้วใช้แทน keybagd
    • เคยพิจารณาโปรเจกต์ fixkeybag แล้ว แต่โค้ดสร้าง system keybag ของแอปนั้นก็เรียก MKBKeyBagCreateSystem จึงล้มเหลวแม้อยู่ในสถานะ iOS ที่บูตแล้ว
  • launchd ต้องมีแพตช์เพิ่มเติมโดยทำ NOP กับ conditional branch TBZ ที่ทำให้เกิดสตริง panic Userspace reboot changed system version: previous %s != current %s

การแก้ไข mount, DYLD shared cache และเลเยอร์กราฟิก

  • เนื่องจากใช้บูตเชน macOS และ macOS ramdisk จัดการกระบวนการ restore ทำให้ /sbin/mount ของ iOS ไม่สามารถจัดการวอลุ่ม APFS ที่สร้างขึ้นได้อย่างถูกต้อง
  • วิธีแก้คือเอาไบนารี mount จากวอลุ่มระบบ macOS มาแก้ metadata ของ Mach-O ให้รันบน iOS ได้ แล้วใช้แทน
    • ทำด้วยมือได้ และสามารถใช้ vtool ที่รวมมากับ macOS ได้ด้วย
  • การแก้ที่ยากกว่าคือแพตช์ DYLD shared cache
    • IOSurfaceRoot ของ macOS และ IOCoreSurfaceRoot ของ iOS โดยพื้นฐานแล้วเป็น driver เดียวกัน แต่ไม่เข้ากันเพราะชื่อต่างกัน
    • ใน DYLD shared cache ของ iOS มีสตริงที่ยาวกว่าคือ "IOCoreSurfaceRoot" ดังนั้นให้เปลี่ยนเป็น "IOSurfaceRoot" แล้วเติมไบต์ที่เหลือด้วย 0x00
  • การวิเคราะห์และแยก DYLD shared cache ใช้เครื่องมือ ipsw ของ blacktop
    • แยก dylib ที่ฝังอยู่ด้วย ipsw dyld split <dsc file>
    • ในไบนารี /System/Library/Frameworks/IOSurface.framework/IOSurface ค้นหา reference ไปยัง "IOCoreSurfaceRoot" ของฟังก์ชัน __iosConnectInitalize
    • ใช้ ipsw dyld a2o แปลง virtual address เป็น file offset
    • ในตัวอย่าง แพตช์ออฟเซ็ต 0x28fde373 ของ dyld_shared_cache_arm64e
  • หลังแก้ไข DYLD shared cache แล้ว cdhash ในตำแหน่งอื่นไม่ตรงกัน ทำให้เกิด exception
    • ใช้ GDB stub ที่ฟรอนต์เอนด์ของ Virtualization.framework ให้มา ตั้ง breakpoint ที่ฟังก์ชัน cs_validate_hash ของเคอร์เนลเพื่อดู cdhash ทั้งหมด
    • ในตัวอย่าง iOS 15.0.2 แพตช์ไบต์เดิมที่ออฟเซ็ตไฟล์ 0x5a9cffc0 ด้วย cdhash ใหม่

แพตช์ system daemon และ activation

  • watchdogd ตรวจสอบว่ากำลังรันอยู่ใน VM หรือไม่ และเกิด crash-loop เพราะไม่มี code path ของ macOS ที่จบการทำงานอย่างปกติ แต่ crash นี้ถือว่าไม่เป็นอันตราย
  • ใน backboardd มีการทดลองแพตช์ call ที่เกี่ยวข้องกับ data migration ซึ่งอาจกระตุ้น PreBoard.app แต่ไม่เห็นความแตกต่างนอกจากค้างที่โลโก้ Apple
  • ในฟังก์ชัน get_device_type_internal_block_invoke ของ lockdownd แพตช์การเรียก getMGInt สำหรับ "ShouldHactivate" เป็น mov x0, #1 เพื่อบังคับ hactivation ซึ่งข้ามข้อจำกัดการ activate iOS ปกติในสภาพแวดล้อมพัฒนา
  • mobileactivationd ก็สามารถแพตช์ให้อนุญาต hactivation ได้เช่นกัน
    • เปลี่ยนฟังก์ชัน shouldHactivate เป็นคำสั่ง ARMv8-A mov x0, #0 และ ret
  • การแก้ไขเพิ่มเติมที่จำเป็นกับ vma2 device tree ถูกปล่อยไว้เป็นงานให้ผู้อ่านจัดการเอง
  • สำหรับการทำงานบางอย่าง อาจต้องใช้มาตรการที่ไม่ปกติ เช่น chmod -R 777 /

ข้อจำกัดที่เหลือและการป้อนข้อมูลแบบสัมผัส

  • หากต้องการข้ามปัญหา system keybag ต้องทำความเข้าใจโครงสร้างที่เกี่ยวข้องในระบบ iOS และเคอร์เนลให้มากขึ้น แล้วสร้างแพตช์เพิ่มเติม
  • โปรเจกต์นี้ใช้เวลาไปอย่างน้อยหลายร้อยชั่วโมงแล้ว และสถานะที่เผยแพร่ในปัจจุบันคือบูตได้ถึง PreBoard.app
  • ยังไม่ยืนยันว่า ฟังก์ชันสัมผัส ทำงานได้ผ่านเคอร์เนลและเฟิร์มแวร์ public vma2 Mac หรือไม่
  • Virtualization.framework มี private API ที่เกี่ยวกับการสัมผัส
    • _VZAppleTouchScreenConfiguration
    • _VZUSBTouchScreenConfiguration
    • _VZTouch
    • _VZMultiTouchEvent
  • สามารถส่ง touch event ด้วย API เหล่านี้ได้ แต่ยังไม่เข้าใจวิธีใช้พารามิเตอร์ที่ถูกต้องอย่างสมบูรณ์
    • enum TouchPhase เป็น enum ง่าย ๆ ที่ implement ค่าชื่อเดียวกับ NSTouch.Phase
    • โค้ดตัวอย่างบางครั้งอาจทำให้เกิด exception
    • ยังไม่ยืนยันว่าค่าพิกัดถูก map ในแบบที่ VM คาดหวังหรือไม่ และ VM จัดการค่านั้นได้หรือไม่
  • เดโมแสดงลำดับการบูต โดยช่วงรอประมาณ 30 วินาทีตรงกลางถูกตัดออก

บทความที่เกี่ยวข้อง

1 ความคิดเห็น

 
GN⁺ 2024-10-08
ความคิดเห็นบน Hacker News

  • Corellium ชนะคดีความ ทำให้สามารถให้เช่า iOS cloud VM สำหรับงานวิจัยด้านความปลอดภัยได้ https://hn.algolia.com/?query=corellium
    ถ้าสามารถทำ virtualization ของ iOS บน Apple Silicon MacBook ได้ ความต้องการบริการ iOS virtualization เชิงพาณิชย์อาจลดลง
    สำหรับบุคคลทั่วไปอยู่ที่เดือนละ $400 ส่วนองค์กรอยู่ราวปีละ $60,000 https://support.corellium.com/subscriptions/pricing

    • โอ้พระเจ้า ชั่วโมงละ $4~$8 เลยนะ สงสัยจริง ๆ ว่าใครยอมจ่ายเงินให้ VM แบบนี้

  • ดีเลย ต่อไปก็หวังว่าจะมีคนหาวิธีติดตั้ง macOS บน iPad ได้ด้วย จะได้ใช้ คอมพิวเตอร์เครื่องนั้น ที่เราอยากให้ Apple ทำให้สักที

    • เริ่มจาก Windows XP ก็ได้
      https://www.theverge.com/2024/7/22/24200536/windows-xp-ipad-...
    • ตามส่วนงานวิจัยก่อนหน้า [Zhuowei Zhang] สรุปว่า แอป macOS แบบ GUI ไม่สามารถรันบน iOS ได้ แต่แอป iOS แบบกราฟิกสามารถรันบน macOS ได้
      Mac Catalyst ก็ดูเหมือนจะทำงานได้ทางเดียวตามที่คาดไว้
    • เห็นด้วยแบบพันครั้งเลย ช่วงไม่กี่สัปดาห์ที่ผ่านมาผมกำลังหาเรื่องนี้พอดี คือ แท็บเล็ตที่รันระบบปฏิบัติการสำหรับงานพัฒนาได้
      ถ้าดูแค่ขนาด iPad Mini น่าสนใจ แต่ iPadOS ใช้ทำอะไรไม่ได้ ตอนนี้เลยกำลังดู Surface Go อยู่ แต่ก็ค่อนข้างใหญ่ไปนิด
      รู้ว่าไม่มีผลิตภัณฑ์ที่ใส่ MacOS มาให้ แต่ถ้ามีแท็บเล็ตขนาดเล็กที่รัน Win11 ได้แนะนำก็บอกด้วย ยินดีสั่งจากจีนถ้าจำเป็น
    • iPad Pro เป็น อุปกรณ์ที่เร็วที่สุด ที่ใช้ M4
    • ถ้าเรียกมันว่า MacBook Air ที่มีติ่งยื่นออกมากลับหัวกลับหางกับคีย์บอร์ดถอดได้ แค่นั้นพอไหม?

  • ดูโปรไฟล์ GitHub ของผู้เขียนแล้ว เหมือนเพิ่งเป็น บัณฑิตวิทยาการคอมพิวเตอร์ ใหม่ ๆ งานนี้น่าประทับใจจริง ๆ

    • คิดว่าอีกไม่นาน Apple คงยื่นข้อเสนองานให้

  • รู้สึกว่าเหตุผลที่ Apple ไม่ทำ Simulator ให้เป็น Emulator ก็เพราะไม่อยากให้คนไปขุดคุ้ย ชั้นฐานภายในของ iOS

    • อีกเหตุผลที่เดิมทีมันเป็น Simulator ไม่ใช่ Emulator อาจเป็นเพราะในตอนนั้นส่วนประกอบจำนวนมากของ iOS หรือ iPhone OS เป็น fork ของ ไลบรารี Mac OS X เดิม
    • นักพัฒนายังมีคนใช้ Intel Mac อยู่ และบนเครื่องพวกนั้นไม่สามารถทำ virtualization ของ ARM iOS ได้
    • ตอนนี้ iPhone, Mac, iPad ล้วนเป็น arm64 แถมยังเป็น Apple Silicon กันหมดแล้ว เลยสงสัยจริง ๆ ว่า bootloader ของ iOS กับ macOS ต่างกันแค่ไหน
      พอผ่าน bootloader ไปแล้ว โดยเฉพาะในสถานการณ์ที่ Apple ควบคุมฮาร์ดแวร์เองด้วย ก็สงสัยว่ามีเหตุผลอะไรที่ต้องคงความแตกต่างจำนวนมากระหว่างสองระบบปฏิบัติการไว้ต่อไป

  • คนที่สร้าง qemu-t8030 เคยรัน SpringBoard ได้สำเร็จ https://mastodon.social/@ntrung03/109712247237110967 แต่ไม่ได้เปิดเผยโค้ด
    ถ้าความคืบหน้านั้นเอามารวมกับงานนี้ได้ก็น่าจะยอดเยี่ยม

  • คอมเมนต์ในอดีต: https://news.ycombinator.com/item?id=40219423

  • บทความที่เกี่ยวข้อง: https://worthdoingbadly.com/hv/
    พูดถึง เครื่องเสมือนแบบเร่งด้วยฮาร์ดแวร์ บน iPhone 12 ที่เจลเบรกแล้ว / iOS 14.1

  • ออกนอกเรื่องนิดหน่อย แต่อยากรู้ว่ามีใครเคยทำ virtualization ของ ARM macOS บน x86-64 บ้างไหม

    • เป็นไปไม่ได้ โดยทั่วไป “virtualization” หมายถึงการรันระบบปฏิบัติการผ่าน hardware virtualization โดยให้ CPU ของโฮสต์รันโค้ดแบบ native และส่งต่อ I/O ทั้งหมดให้ hypervisor
      ดังนั้นจึงทำ virtualization ได้เฉพาะระบบปฏิบัติการที่ build มาสำหรับ สถาปัตยกรรม CPU เดียวกับระบบโฮสต์เท่านั้น
      กรณีอื่น ๆ เช่นรันซอฟต์แวร์ ARM บน x86 หรือกลับกัน ต้องใช้ emulation ซึ่งใช้วิธีตีความโค้ดหรือ recompile แบบไดนามิก
      ตามนิยามแล้ว อะไรก็สามารถ emulate บนอะไรก็ได้ ช่วงหลังยังมีกรณีที่บูต Linux สำหรับ MIPS บน Intel 4004 ซึ่งเป็นไมโครโปรเซสเซอร์ตัวแรกได้ด้วย แต่ประสิทธิภาพอาจเป็นปัญหา
    • ลองทำ virtualization ของ ARM ทั่วไปใน QEMU จะเห็นว่าประสิทธิภาพยังไม่ถึงระดับ Raspberry Pi ด้วยซ้ำ เวอร์ชันใหม่ ๆ น่าจะมีมาให้โดยค่าเริ่มต้น
      การทำ virtualization ของ CPU ตระกูล Mn ก็น่าจะยิ่งมีประโยชน์น้อยกว่า
    • ลองดูโปรเจกต์ Hackintosh ก็น่าจะดี

  • Apple มี iOS Simulator อยู่ใน Xcode อยู่แล้ว เลยสงสัยว่าโปรเจกต์นี้ดีกว่าเครื่องมือที่ Apple ให้มาอย่างไร

    • Simulator ไม่ได้รัน iOS จริงหรือรัน iOS build ของแอปจริง ๆ เมื่อรันแอปใน Simulator แอปจะถูกคอมไพล์เป็นชุดคำสั่ง native ของ Mac เครื่องปัจจุบัน แล้วลิงก์กับเฟรมเวิร์กและไลบรารีของ Mac ที่เลียนแบบพฤติกรรม iOS ที่คาดไว้ หรือบางส่วนก็เป็นแค่เปลือก
      เช่น คุณไม่สามารถเอา iOS binary จาก App Store มารันตรง ๆ ใน iOS Simulator ได้ โดยเฉพาะบน Intel Mac ยิ่งไม่ได้
      เพราะ Simulator ไม่ได้รัน iOS แบบสมบูรณ์ คุณจึงตรวจสอบและเรียนรู้ไม่ได้ว่า iOS ภายในทำงานอย่างไรจริง ๆ ถ้าขุดลึกพอในเฟรมเวิร์กของ Simulator สุดท้ายก็จะกลับไปเจอ macOS
      ในทางกลับกัน emulator คือการรัน iOS build เต็มชุดแบบเดียวกับอุปกรณ์จริง ตามทฤษฎีแล้ว iOS binary ใด ๆ ก็สามารถรันได้โดยไม่ต้องแก้ไข และสามารถตรวจสอบได้ว่าระบบปฏิบัติการจริงทำงานอย่างไร
      คล้ายความต่างระหว่างการรันแอปด้วย Wine กับการรันแอปใน Windows VM เพียงแต่กรณีของ Simulator จะใกล้เคียงกับสถานการณ์ที่ต้อง recompile และลิงก์แอป Windows ใหม่ให้เข้ากับสภาพแวดล้อมของ Wine ก่อนจะรันมากกว่า
      ถ้าอยากศึกษาภายในของ Windows การรันด้วย Wine อย่างเดียวคงเรียนรู้ได้ไม่มาก แต่ถ้าตรวจสอบ Windows VM จะเรียนรู้ได้มากกว่ามาก

  • น่าจะเป็น ของขวัญคริสต์มาส ล่วงหน้าสำหรับพวก click farm