การจำลอง iPhone ด้วย QEMU

 (eshard.com)
4 คะแนน โดย GN⁺ 2025-04-07 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • eShard ตั้งเป้าพัฒนาอีมูเลเตอร์ที่ต่อยอดจากงานโอเพนซอร์สด้านการจำลอง iOS เดิม โดยสามารถ บูต iOS 14 บน QEMU และรัน UI รวมถึงบางแอปได้
  • แทนที่จะใส่แพตช์เคอร์เนลเข้าไปใน QEMU โดยตรง ใช้ PongoOS และ checkra1n KPF เพื่อแยกแพตช์ XNU ออกมา และทำให้ตรวจสอบเนื้อหาแพตช์ได้ด้วยเครื่องมือที่อิง Mach-O diff
  • การจำลอง GPU ของ Apple Silicon มีขอบเขตกว้างเกินไป จึงเลือกใช้ software rendering ก่อน และยืนยันได้จากการแพตช์ QuartzCore บน iPhone ที่เจลเบรกแล้วว่า UI ของ UIKit สามารถถูกวาดได้ แม้จะช้า
  • เพื่อแก้ปัญหาหน้าจอยังคงดำ ได้ดำเนินการต่อเนื่องทั้ง ปิด address randomization, ดีบักด้วย GDB, อ้อมกระบวนการ pairing ของ lockdownd, ปิด PAC, พอร์ตไป QEMU 8.2.1 และทำระบบอัตโนมัติสำหรับการแพตช์ dyld cache
  • ท้ายที่สุดสามารถแสดง UI ป้อน passcode ของ UIKit บนหน้าจอ QEMU และควบคุม textbox ด้วยอินพุตคีย์บอร์ดผ่าน VNC พร้อมมีพื้นฐานที่จำเป็นจนถึงขั้นแสดง SpringBoard

จุดเริ่มต้นของการจำลอง iOS

  • จากการตรวจสอบโซลูชันโอเพนซอร์สเดิม alephsecurity/xnu-qemu-arm64 เคยใช้งานได้จริง แต่โปรเจกต์อยู่ในสถานะอ่านอย่างเดียว
  • จากนั้นใช้ TrungNguyen1909/qemu-t8030 เป็นจุดเริ่มต้น
    • สามารถ restore iOS ได้ผ่านการเชื่อมต่อ USB ด้วย QEMU “companion” ตัวที่สอง
    • รองรับการรัน iOS 14
    • อิง QEMU เวอร์ชันใหม่กว่า
    • มีวิกิอธิบายวิธีรันอีมูเลเตอร์
  • แก้ไข System/Library/xpc/launchd.plist เพื่อให้เข้าถึง shell และ SSH ได้อย่างรวดเร็ว
  • เป้าหมายระยะยาวคือ การจำลอง iOS ที่ใช้งานได้จริง มี UI และสามารถรันอย่างน้อยบางแอปได้

แยกแพตช์เคอร์เนลด้วย PongoOS

  • โปรเจกต์ t8030 ใส่โค้ดแพตช์เคอร์เนล XNU ไว้ใน QEMU เอง แต่เนื่องจากมีโอกาสที่แพตช์จะเพิ่มขึ้นในอนาคต จึงต้องการโครงสร้างที่สะอาดกว่า
  • จากประสบการณ์กับ iPhone ที่เจลเบรกจริง จึงพิจารณาวิธีใช้ PongoOS เพื่อใช้ แพตช์ checkra1n
  • ใน flow เจลเบรกทั่วไป หลังจากถูก pwn ด้วย checkmate แล้ว PongoOS จะถูก inject เข้า SRAM และโมดูล checkra1n-kpf จะถูกส่งผ่าน USB
    • ในงานนี้ เพื่อเลี่ยงการจัดการ USB ช่วงต้น จึง เพิ่ม SRAM ของ iPhone ที่จำลอง และใช้ PongoOS กับโมดูล checkra1n KPF
  • ช่วงแรกของการรัน PongoOS เกิดปัญหาเพราะไม่มีโค้ด initialization ที่ปกติ bootrom หรือ iBoot ทำให้
    • ต้อง ตั้งค่า FPU ก่อนคำสั่ง double/float
    • แก้ไขได้โดยอ้างอิงเอกสาร ARM และโค้ดที่เกี่ยวข้องกับ QEMU เดิม
  • ฟีเจอร์ของอุปกรณ์ตั้งแต่ A13 เป็นต้นไป Pongo ไม่รองรับ ทำให้ pattern matching ของบางแพตช์พัง
    • มีการเพิ่มคำสั่ง Pointer Authentication(PAC) อย่าง autda, xpacd
    • Apple ใช้ slide แบบอื่น
    • ในแพตช์ task_for_pid(tfp0) พบความแตกต่างของ address และ binary pattern ระหว่าง iPhone X กับ iPhone 11

ไฟล์แพตช์เคอร์เนลแบบ declarative

  • Pongo ช่วยให้ใช้แพตช์ checkra1n เดิมสำหรับ iOS หลายเวอร์ชันได้ แต่รูปแบบการ apply แบบ dynamic อ่าน แก้ไข และแชร์ได้ยาก
  • เพื่อให้จัดการเหมือนแพตช์โค้ดจริง จึงสร้างไฟล์ แพตช์แบบ declarative ด้วยเครื่องมือภายใน
    • diff Mach-O สองไฟล์เพื่อสร้างไฟล์แพตช์ข้อความที่อิงความต่างของ assembly
    • เขียนโปรแกรมแยกต่างหากสำหรับ apply ไฟล์แพตช์ที่สร้างขึ้นกับไบนารี
  • หลังบูตด้วย Pongo ใช้ QEMU monitor dump ส่วน memory ที่ Pongo แพตช์ไว้
  • จากนั้นประกอบเคอร์เนลที่แพตช์แล้วกลับเข้าไปใหม่ และสร้างไฟล์แพตช์ขนาดใหญ่ที่รวมการแก้ไขทั้งหมด
  • เมื่อนำแพตช์ใหญ่ไปแบ่งส่วนและใส่คอมเมนต์ ก็สามารถ ตรวจสอบและควบคุม ได้ว่าส่วนใดของเคอร์เนลถูกแพตช์

กลยุทธ์วาดหน้าจอโดยไม่มี GPU

  • การเรนเดอร์กราฟิกของ iPhone รุ่นใหม่สุดท้ายต้องผ่าน API Metal ของ Apple และต้องใช้ GPU จริง
  • มองว่าการจำลอง GPU ของ Apple Silicon ซับซ้อนเกินไป จึงพิจารณาสองทางเลือก
    • ใช้ bootarg gpu=0 เพื่อทำ software rendering เหมือนที่เคยทำได้ใน iOS รุ่นเก่า
    • ส่งต่อ Metal call ไปยัง iPhone จริงหรือ Mac ที่มี macOS เพื่อทำการเรนเดอร์
  • ใน iOS 14 ตัวเลือก bootarg gpu=0 ของเคอร์เนล XNU ถูกนำออกไปแล้ว
  • จากการวิเคราะห์ framework QuartzCore ด้วย Ghidra พบว่า software rendering ถูกเรียกในฐานะ fallback เมื่อไม่มี renderer ของ Metal
  • แพตช์ QuartzCore บน iPhone ที่เจลเบรกจริงและยืนยันการใช้ software rendering
    • UI ช้าลงมาก
    • บางพื้นที่เกิด artifact และส่วนนั้นอาจต้องการการเรนเดอร์ด้วย Metal โดยตรง
  • จากการทดลองนี้ จึงมองว่าในขอบเขตที่ไม่ได้ใช้ Metal หรือ OpenGL โดยตรง หรือก็คือ แอป UIKit ส่วนใหญ่ น่าจะทำ software rendering บน QEMU ได้

ทดลอง proxy Metal call

  • อีกทางเลือกคือการ proxy Metal call โดยทดลองกับ iPhone จริงสองเครื่อง
    • parse header ของ iOS ทั้งหมดด้วย LLVM
    • แทน pointer ของ Objective-C object ฝั่ง server เป็น stub pointer ฝั่ง client
    • สร้างโค้ดแลกเปลี่ยน struct และ pointer อัตโนมัติ
    • hook function และ method ทั้งหมด
    • ส่งต่อทุก call ไปยัง server และคืนผลลัพธ์การรัน
  • การเรียกไปกลับพื้นฐานของการ initialize Metal สำเร็จบางส่วน
  • แต่ภาษา Objective-C และ API Metal มีความซับซ้อนและมีฟีเจอร์จำนวนมาก งานที่ต้องทำเพื่อให้ทำงานจริงจึงใหญ่มาก
  • จึงเลื่อนวิธีนี้ไว้ภายหลัง และตัดสินใจแก้ปัญหาอื่นด้วย software rendering ก่อน แม้จะมีข้อจำกัด
  • framework ของ iOS ยัง expose private API ที่ไม่มีใน public header ด้วย และแม้จะมีวิธี parse เพื่อสร้าง header ได้ แต่ส่วนใหญ่ใช้งานโดยตรงได้ยากและเพิ่มความซับซ้อน

ดีบัก IOSurface และ framebuffer

  • หลังพยายามใช้ software rendering ก็ยังต้องมีอุปกรณ์ framebuffer ขั้นต่ำ แต่ QEMU t8030 เดิมไม่ได้ implement ไว้
  • พบ fork QEMUAppleSilicon ที่มีงานรองรับ IOMFB และนำมาใช้ดีบัก display
  • เมื่อ restore iOS ด้วยเวอร์ชันนี้ จะเห็นโลโก้ Apple และ progress bar แต่ในการบูตปกติหน้าจอยังคงดำสนิท
  • จากการดู IOMFB kext ด้วย Ghidra และตรวจสอบ implementation ของ QEMU framebuffer ดูเหมือนมีสองโหมด
    • raw framebuffer ที่ address ฮาร์ดแวร์คงที่
    • API ที่ซับซ้อนกว่า โดยตั้งค่า plane หลายตัวด้วย register และเขียน surface data ด้วย DMA
  • สามารถแสดง ARGB surface ใด ๆ ผ่าน raw framebuffer ได้ แต่ระหว่างบูตระบบไม่ได้เขียนไปยัง framebuffer นั้น
  • ใน display mode ที่สอง เห็น trace ว่าเคอร์เนลตั้งค่า graphical plane ผ่าน register แต่หลังจากนั้นไม่มี output บนหน้าจอ

ปิด address randomization และดีบักด้วย GDB

  • การเข้าถึงผ่าน SSH อย่างเดียวมีข้อจำกัดในการสังเกตระบบที่กำลังรัน จึงจำเป็นต้อง ดีบักเคอร์เนลและ user space ด้วย GDB
  • kernel address randomization ถูกตั้งค่าในการ initialize บอร์ด t8030 จึงสามารถปิดได้ทั้งหมด
  • ใน userland มี randomization ของ executable และ dynamic library ภายใน dyld cache
    • executable ถูกปิดผ่านการแพตช์ฟังก์ชัน _load_machfile ของเคอร์เนล
    • ไลบรารีใน dyld cache จะถูก randomize address หนึ่งครั้งตอนบูต แล้วถูกโหลดที่ address เดียวกันในทุก executable
  • dyld cache ที่ /System/Library/Caches/com.apple.dyld/dyld_shared_cache_arm64e มี framework library ทั้งหมดอยู่ในรูป binary blob ขนาดใหญ่
  • สร้างเครื่องมือภาษา C เพื่อ dlopen framework library ทั้งหมด แล้วใช้ฟังก์ชัน _dyld* แสดงรายการ image ที่โหลดและ offset
  • ใช้วิธีนี้ร่วมกับกระบวนการย้อน address ของ GDB ทำให้ดีบักไลบรารีใน dyld cache ได้
  • เป้าหมายที่สนใจเป็นพิเศษคือ IOMFB kext, backboardd, SpringBoard, QuartzCore
  • ต่อมาพบวิธีปิด dyld cache ด้วยแพตช์เคอร์เนล และใช้ไลบรารี Rust object ของโปรเจกต์ Gimli เพื่อหา virtual address ของ dyld cache บน host โดยตรง
  • การดีบัก user space ต้องใช้ GDB server ฝั่ง guest เช่นใช้แพ็กเกจ debugserver ของ Procursus

system log และการอ้อม lockdownd

  • จาก GDB ดูเหมือน backboardd เริ่มทำงานปกติ แต่เพื่อเข้าใจสถานการณ์จริงจำเป็นต้องมี system log
  • บน iPhone จริง สามารถดู system log ด้วย idevicesyslog หลัง pair USB กับคอมพิวเตอร์
  • กระบวนการ pairing รวมถึงการสร้าง key pair โดย private key จะถูกเก็บใน iPhone และ lockdownd จะตรวจสอบตัวตนของคอมพิวเตอร์
  • ในสภาพแวดล้อมจำลอง แม้โต้ตอบผ่าน USB ได้ แต่ lockdownd ทำงานไม่ถูกต้อง
  • จากการวิเคราะห์ด้วย Ghidra พบว่า lockdownd พยายามใช้ keybag เพื่อเก็บ private key ซึ่งต้องใช้ SEP ที่ไม่มีอยู่
  • inject shellcode ที่แทนที่บางฟังก์ชันเดิม เพื่ออ่าน public/private key pair ที่สร้างไว้ล่วงหน้าจาก filesystem และโหลดทุกครั้งที่ lockdownd พยายามดึงจาก keybag
  • ด้วยการดีบักและแพตช์เพิ่มเติม จำลองสถานะว่าผู้ใช้เชื่อถือคอมพิวเตอร์แล้วและ iPhone ถูกปลดล็อกแล้ว
  • สุดท้ายสามารถ pair กับ iPhone ที่จำลองผ่าน companion QEMU ได้
  • ใน log ยืนยันได้ว่า QuartzCore initialize ปกติ ตรวจพบขนาด display และใช้ fallback ของ software rendering
  • ทุกอย่างดูเหมือนปกติ แต่หน้าจอยังไม่แสดงผล
  • ข้อผิดพลาดเดียวที่เกี่ยวกับ pixel format ถูกอ้อมด้วยการบังคับระบุ RGBA แต่ภายหลังถูกถอดออก

ปัญหา PAC และการพอร์ต QEMU 8

  • ระหว่างแก้ข้อผิดพลาด pixel format ของ backboardd พบปัญหาเพิ่มเติมจากฟีเจอร์ด้านความปลอดภัยของ iOS
  • การตรวจสอบ signature ตอนโหลดและ runtime แก้ได้ด้วยแพตช์เคอร์เนล แต่ระหว่างรัน backboardd ที่ถูกแก้ไขเกิดความล้มเหลวของ Pointer Authentication
  • Pointer Authentication เป็นฟีเจอร์ที่เพิ่มใน ARMv8.3 และเป็นปัญหาใหม่ที่พบกับบอร์ด t8030 ที่กำลังจำลอง ไม่ใช่ t8015 ที่เคยใช้ก่อนหน้า
  • ตอนแรกคิดจะเปลี่ยนคำสั่ง PAC ทั้งหมดเป็น NOP หรือคำสั่งเทียบเท่าที่ไม่มี PAC
  • ต่อมาพบว่า binary ARM64 PAC สามารถ build ได้สองแบบ
    • ใช้ชุดคำสั่ง PAC เฉพาะที่รันได้เฉพาะบน CPU ARMv8.3+ เท่านั้น
    • ใช้ชุดคำสั่ง “unused” ที่บน ARMv8.3+ จะถูกตีความเป็น PAC และบน ARM รุ่นก่อนหน้าจะถูกตีความเป็นคำสั่งเทียบเท่าที่ไม่มี PAC
  • ทดสอบบน buildroot และระบบ ARM64 Linux เพื่อยืนยันพฤติกรรมนี้ และยืนยันว่า binary สำหรับ t8030 ใช้ arm64e ซึ่งเป็นชุดคำสั่งแบบ backward compatible
  • คาดว่าถ้าปิดเฉพาะ PAC enforcing ใน QEMU ก็จะรันเหมือนโค้ดที่ไม่มี PAC ได้ แต่ QEMU 7 ใช้งานไม่ได้ ขณะที่ QEMU 8 มีพฤติกรรมต่างออกไป
  • พอร์ต codebase ปัจจุบันไปยัง QEMU 8.2.1
    • คำสั่งเฉพาะของ Apple genter, gexit
    • โค้ดจัดการ GL exception levels
    • มีการแก้ไข QEMU generic code จำนวนมาก ทำให้พอร์ตยาก
  • หลังเจอ XNU panic หลายครั้ง ดีบักเคอร์เนลด้วย GDB ดีบัก QEMU เอง และทำ git bisect ในที่สุดก็บูต iOS บน QEMU 8 ได้อีกครั้ง
  • ทำให้สามารถปิด PAC และแก้ไขโค้ดใด ๆ ที่รันอยู่ ณ ตำแหน่งที่ต้องการได้

ไล่หาสาเหตุของหน้าจอดำ

  • จาก system log ดูเหมือน backboardd ทำงานปกติ จึงไล่หาสาเหตุที่ไม่แสดงผลให้ลึกขึ้น
  • หากเขียน raw ARGB frame ไปยัง address โดยตรง display จริงจะเปลี่ยน และสามารถวาดไปยัง graphical plane หลายตัวได้
  • ดังนั้น implementation ของ display เองดูเหมือนปกติ เหลือความเป็นไปได้สามอย่าง
    • backboardd ไม่เขียนอะไรเลย
    • เขียนไปยัง address ที่ไม่ถูกต้อง
    • data ที่เขียนไม่ valid
  • ใช้ QEMU monitor เพื่อดึง physical address ที่ไม่ต่อเนื่อง และใช้สคริปต์ dump physical DMA memory แล้วรวมเป็นไฟล์เดียว
  • ตีความเป็น ARGB frame ด้วย ffplay แต่ไม่ได้ผลลัพธ์ที่มีความหมาย
  • ถัดมาตั้ง breakpoint ที่ iosurface_lock เพื่อรับ address ของ surface ที่ map ใน memory ของ backboardd แล้วตรวจสอบ
  • บางครั้งพบรูปทรงแปลก ๆ ที่ดูคล้ายโลโก้ Apple แต่ดูเหมือนมีปัญหาในวิธีเขียน frame
  • เมื่อทำงานเดียวกันบน iPhone 10 จริง สามารถ dump raw ARGB frame ของหน้าจอปัจจุบันได้อย่างง่ายดาย
  • บน iPhone 11 หรือก็คือตั้งแต่ t8030 เป็นต้นไป ดูเหมือน surface จะถูกส่งใน รูปแบบบีบอัด ที่ GPU สามารถประมวลผลได้
  • เนื่องจากเรื่องนี้ไม่เกิดบน t8015 ของ iPhone X จึงแก้ให้ DTB ของ QEMU ส่ง chip-id เป็น 8015 แทน 8030
  • ผลคือหลังบูต หน้าจอแสดงโลโก้ Apple

progress bar และแพตช์ authentication

  • แม้โลโก้ Apple จะแสดงแล้ว แต่ UI ยังไม่ไปต่อ และ system log มีข้อความจำนวนมากจาก daemon และไลบรารีหลายตัว
  • เดินหน้าโดยเดาว่าข้อผิดพลาดใดเกี่ยวข้องกับปัญหา UI จริง แล้วแก้ทีละจุด
  • พบปัญหาที่เกี่ยวข้องกับ user authentication โดยแหล่งที่มาของข้อผิดพลาดคือ daemon mobileactivationd และ framework SpringBoardFoundation
  • หลังแพตช์สิ่งเหล่านี้ มี progress bar สีขาว ที่คล้ายกับที่เห็นในขั้น restore แสดงขึ้นมา
  • progress bar ดูเหมือนกำลังเคลื่อนที่ แต่หลังผ่านไปหลายชั่วโมงก็ดูเหมือนค้างที่ 90%

ปรับปรุงการวนซ้ำแพตช์ dyld cache และ user space

  • การปิด address randomization ทำให้แพตช์ user space และ framework ใน dyld cache ได้
  • สร้างไฟล์แพตช์ข้อความสำหรับแต่ละ binary/library ด้วยวิธีเดียวกับเคอร์เนล และ apply ด้วยเครื่องมือภายใน
  • dyld cache มีขนาดราว 2GB การแพตช์โดยตรงหรือคัดลอกซ้ำผ่าน SSH จึงไม่เหมาะสม
  • เนื่องจากทำงานบน Linux จึงแก้ไข NVMe โดยตรงไม่ได้เช่นกัน
  • ขยายเครื่องมือ diff/patch ภายในให้รองรับ dyld cache โดยหา offset ของ framework ภายใน blob ของ dyld cache
  • เพิ่มตัวเลือกสร้างคำสั่ง dd แบบง่ายที่ apply บน iPhone ได้ทันที พร้อมคำสั่ง revert
  • หลัง remount filesystem เป็นโหมดอ่าน/เขียนแล้ว apply คำสั่ง dd ก็สามารถวนแก้ dyld cache ได้อย่างรวดเร็ว
  • การทำให้การแก้ไขมีผลต้องรีบูต iOS เท่านั้น
  • เพื่อให้วิธีนี้ทำงานได้ ต้องมีแพตช์เพิ่มเติมบางส่วนต่อ signature check ของเคอร์เนล

รัน PreBoard และแสดงหน้าจอ UIKit

  • ก่อนจะแก้ progress bar ที่ค้าง ได้ทดลองกับโปรเซสระบบ PreBoard
  • PreBoard ดูเหมือนจะแสดงให้ผู้ใช้เห็นเฉพาะเมื่อมีปัญหา เช่น การอัปเดตถูกขัดจังหวะ
  • เป็น system application ที่วาดโดยตรงผ่าน backboardd เหมือน SpringBoard จึงสามารถเริ่มจาก command line ได้โดยตรง
  • ผลการรันคือหน้าจอสีขาวที่ขอให้ “swipe to upgrade” แสดงขึ้นมา
  • จากประสบการณ์เดิมที่เคยใช้ VNC server บน iPhone จริง จึงเพิ่ม VNC และหลังล้มเหลวหลายครั้ง ก็ปลดล็อกหน้าจอได้ด้วย ปุ่มคีย์บอร์ด แทนการ swipe
  • ทันทีหลังปลดล็อก QEMU หยุดการรันเพราะ iOS ใช้ illegal instruction
  • จากการวิเคราะห์ backboardd พบว่า framework vImage ใช้คำสั่ง AMX(Apple Matrix Coprocessor) สำหรับงานกราฟิกแบบ hardware-accelerated เช่น _vHorizontal_Scale_ARGB_8888_Accelerate
  • AMX เป็นชุดคำสั่งเฉพาะของ Apple ที่ไม่ได้ implement ใน ARM CPU ที่ QEMU จำลอง
  • framework vImage มีเวอร์ชัน software สำรองที่ใช้เฉพาะคำสั่ง ARM generic จึงแพตช์ให้กลับไปใช้เวอร์ชันนี้
  • ผลลัพธ์สุดท้ายคือหน้าต่าง UIKit จริงแสดงขึ้นมา พร้อมหน้าจอป้อน passcode และ textbox ที่ใช้งานได้
  • สามารถป้อนข้อความลง textbox ผ่าน keyboard event ที่ inject ด้วย VNC
  • ณ จุดนี้ องค์ประกอบที่จำเป็นสำหรับให้ SpringBoard แสดงอย่างถูกต้องพร้อมแล้ว และดูเหมือนเหลือแค่เรื่องเวลาในการเริ่มต้น
  • บทความถัดไปต่อที่ Part 2

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

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

 
GN⁺ 2025-04-07
ความคิดเห็นบน Hacker News

  • หวังว่า https://github.com/devos50/qemu-ios จะพัฒนาไปจนรองรับได้ถึง iPhone OS 3.x เพื่อให้ได้ลองสัมผัสแอป iPhone ยุคแรก ๆ ในเชิง การอนุรักษ์ดิจิทัล
    https://github.com/touchHLE/touchHLE ก็ยอดเยี่ยม แต่ถ้าไม่ใช่แอปพื้นฐานมาก ๆ ก็ต้องมีแพตช์เฉพาะแอป

    • iPhone 11 ที่เอมูเลตด้วย QEMU สามารถรองรับได้ตั้งแต่ iOS 13.x ถึง iOS 18.x: https://github.com/ChefKissInc/QEMUAppleSilicon
      ถ้าจะรันแอป 32 บิตบน iOS 10 QEMU ก็ต้องรองรับ iPhone 7 ด้วย
    • ถ้าได้กลับมาใช้งานเกมยุคแรก ๆ หรือแอปเก่าเจ๋ง ๆ ที่ตอนนี้ไม่มีทางเลือกทดแทน ก็น่าจะยอดเยี่ยมจริง ๆ

  • เมื่อก่อนเคยเอมูเลต NumWorks N0100[1] และ HP Prime G1[2] ด้วย QEMU จนถึงระดับที่เฟิร์มแวร์ทางการรันได้จริง
    [1] https://github.com/boricj/qemu/tree/numworks_calculators
    [2] https://github.com/boricj/qemu/tree/s3c2416-boricj

  • ถ้านำโปรเจกต์นี้ไปประยุกต์แบบสนุก ๆ ก็น่าจะติดตั้งอิมเมจ pmOS แบบขั้นต่ำกับ QEMU เวอร์ชันนี้บนมือถือที่รองรับฮาร์ดแวร์ postmarketOS ได้ค่อนข้างดี แล้วบูต iOS บนโทรศัพท์ Android ได้
    อาจเป็นไปได้ด้วยซ้ำที่จะปรับแต่ง QEMU เพิ่มเพื่อส่งผ่านฮาร์ดแวร์ของมือถืออย่างโมเด็มหรือ Bluetooth ไปยังเครื่องเสมือน iOS

    • เป็นไอเดียที่น่าสนุก แต่ปัญหาแรกคือการหามือถือที่บน postmarketOS ใช้กล้องได้และโทรศัพท์ได้อย่างถูกต้อง
      แค่นั้นโดยไม่ต้องมีการเอมูเลต iOS/Android ก็น่าจะพอใจแล้ว
    • ถ้าทำเล่น ๆ ก็โอเค แต่ในทางปฏิบัติมันไร้ประสิทธิภาพมากจนยากจะกลายเป็นอุปกรณ์ที่ใช้งานได้จริง และงานที่ต้องทำก็มหาศาล
    • ให้ความรู้สึกเหมือน paravirtualization แบบหนึ่งหรือเปล่า? น่าจะเป็นโปรเจกต์ที่สนุกดี

  • เวอร์ชันที่เก็บถาวร: https://archive.ph/l1CwO

  • นี่หมายความว่าตอนนี้สามารถทำอย่าง การทดสอบ Safari หรือคอมไพล์สำหรับ iOS บนระบบ Linux ได้โดยไม่ต้องมีฮาร์ดแวร์ Apple แล้วใช่ไหม?

  • https://github.com/ChefKissInc/QEMUAppleSilicon
    เป็น อุปกรณ์ Apple Silicon ที่ถูกเอมูเลตใน QEMU และตอนนี้รองรับเฉพาะ iPhone 11
    วิดีโอเดโม: https://nitter.poast.org/eshard/status/1908162866609311962

  • ลองทำตามคำแนะนำการรันแล้ว: https://github.com/TrungNguyen1909/qemu-t8030/wiki/Bringing-...
    มันแครชหลายครั้งจนน่าอายที่จะยอมรับ แต่ก็เท่มากทีเดียว

  • ไม่มีการพูดถึง การเชื่อมต่อเครือข่าย เลย ดูเหมือนว่าจะไม่ได้เอมูเลตชิปเซ็ต Wi-Fi หรือโมเด็มเซลลูลาร์
    สงสัยว่าจะเชื่อมต่ออุปกรณ์ที่เอมูเลตนี้เข้ากับอินเทอร์เน็ตอย่างไร อาจเป็นวิธีอย่าง Ethernet ผ่าน USB ก็ได้

    • iOS รองรับ USB Ethernet

  • ต้องมีอะไรบ้าง Apple ถึงจะยอมรับ การพัฒนา iOS แบบหลายแพลตฟอร์ม?

    • Apple จะไม่มีวันทำแบบนั้น พฤติกรรมที่ผ่านมาชี้ไปในทางตรงกันข้าม คือการควบคุมอุปกรณ์และระบบนิเวศอย่างสมบูรณ์ การไม่ร่วมมือกับบริษัทอื่นในเรื่องมาตรฐาน และการควบคุม App Store อย่างเข้มงวด
      จากมุมมองของ Apple ไม่มีอะไรที่ได้จากการอนุญาตโมเดลการพัฒนาแบบนั้น
    • Apple ใช้ซอฟต์แวร์ขายฮาร์ดแวร์ นั่นจึงเป็นเหตุผลที่ไม่มี iMessage สำหรับ Android
      กว่าสิ่งนี้จะเกิดขึ้นได้ วิธีที่ Apple มองโลกทั้งใบต้องเปลี่ยนไป และคงเป็นการเปลี่ยนแปลงใหญ่พอ ๆ กับตอนที่ Microsoft ยอมรับ Linux ในระดับหนึ่งผ่าน WSL และ .NET สำหรับ Linux
    • วัฒนธรรมองค์กรต้องเปลี่ยนไปอย่างสิ้นเชิง
    • Apple เป็น บริษัทฮาร์ดแวร์ มีเหตุผลอะไรที่พวกเขาจะอยากรองรับอะไรบนฮาร์ดแวร์ที่ตัวเองไม่ได้ขาย?
    • คงต้องถึงขั้นถูกขู่จะแยกบริษัทเหมือนยุค Internet Explorer

  • มี repository ที่ใช้ทำซ้ำสิ่งนี้ได้ไหม?