macOS ที่รันด้วย QEMU บน Docker

 (github.com/sickcodes)
3 คะแนน โดย GN⁺ 2024-08-01 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • Docker-OSX รัน macOS ที่ใช้ QEMU + KVM ภายในคอนเทนเนอร์ Docker และมีความสามารถอย่างเอาต์พุต X11, SSH, VNC, การเชื่อมต่อ iPhone ผ่าน USB และการสร้างซีเรียลสำหรับงานวิจัยความปลอดภัยของ iMessage
  • รูปแบบการรันคือส่งอุปกรณ์ /dev/kvm, ซ็อกเก็ต X11, การทำ port forwarding และตัวแปรสภาพแวดล้อม SHORTNAME ให้ Docker เพื่อเลือกเวอร์ชัน macOS โดยมีตัวอย่างตั้งแต่ Catalina 10.15 ถึง Tahoe 16
  • โครงสร้างอิมเมจแบ่งตามวัตถุประสงค์ เช่น latest, auto, naked, naked-auto และสามารถแนบไฟล์ .img ที่สร้างเอง หรือรันงาน command line ด้วยอิมเมจ Catalina ที่ตั้งค่าไว้ล่วงหน้าได้
  • ข้อกำหนดคือ โฮสต์ x86_64 ที่ใช้ KVM ได้, เปิดใช้งาน virtualization ใน BIOS และมีพื้นที่ดิสก์อย่างน้อย 20GB ขึ้นไป หากใช้ Xcode ต้องมี 50GB และหากใช้ :auto ต้องมีอย่างน้อย 50GB
  • นอกจาก Linux แล้วยังรันได้บน WSL2 nested virtualization ของ Windows 11 build 22000+ แต่ต้องตั้งค่าเอาต์พุตหน้าจออย่างใดอย่างหนึ่งระหว่าง WSLg, VNC หรือ desktop environment

รัน macOS ภายในคอนเทนเนอร์ Docker

  • Docker-OSX เป็นโปรเจกต์สำหรับ รัน macOS ภายในคอนเทนเนอร์ Docker
    • ทำงานบน QEMU + KVM
    • รองรับ X11 forwarding
    • มีคอนฟิกที่ทำให้ iPhone USB ใช้งานได้
    • ระบุว่าสามารถทำงานวิจัยความปลอดภัยของ macOS บน Linux และ Windows ได้
  • โปรเจกต์นี้สร้างบน OSX-KVM และยังกล่าวถึง KVM-OpenCore, OpenCorePkg ด้วย
  • มีอิมเมจบน Docker Hub ด้วย: sickcodes/docker-osx

เวอร์ชัน macOS ที่รองรับและวิธีรันแบบรวดเร็ว

  • Quick Start เป็นวิธีส่งองค์ประกอบต่อไปนี้ใน docker run
    • --device /dev/kvm
    • -p 50922:10022 สำหรับ SSH
    • วอลุ่ม /tmp/.X11-unix สำหรับ X11
    • DISPLAY
    • SHORTNAME สำหรับเลือกเวอร์ชัน macOS
  • เป้าหมายที่ README มีตัวอย่างการรัน ได้แก่

    • High Sierra 10.13

    • Mojave 10.14

    • Catalina 10.15

    • Big Sur 11

    • Monterey 12

    • Ventura 13

    • Sonoma 14

    • Sequoia 15

      • Tahoe 16
      • ตัวอย่างบางส่วนหลัง Monterey ใช้ GENERATE_UNIQUE=true ร่วมกับ MASTER_PLIST_URL
      • ตัวอย่าง Sonoma, Sequoia และ Tahoe ยังรวม CPU='Haswell-noTSX' และ CPUID_FLAGS ด้วย

ประเภทอิมเมจและวัตถุประสงค์การใช้งาน

  • Docker-OSX มีอิมเมจคอนเทนเนอร์ตามวัตถุประสงค์
    • sickcodes/docker-osx:latest: ใช้สำหรับลองอย่างรวดเร็วหรือสร้างอิมเมจ macOS เอง
    • sickcodes/docker-osx:auto: ใช้ระบบ Catalina ที่ตั้งค่าไว้ล่วงหน้า โดยชื่อผู้ใช้คือ user และรหัสผ่านคือ alpine
    • sickcodes/docker-osx:naked: แนบไฟล์ .img ที่ผู้ใช้มีอยู่แล้วเพื่อรัน
    • sickcodes/docker-osx:naked-auto: ส่ง USERNAME, PASSWORD, OSX_COMMANDS ให้กับอิมเมจของผู้ใช้ เพื่อทำ SSH และการรันคำสั่งแบบอัตโนมัติ
    • sickcodes/docker-osx:big-sur, :monterey, :ventura, :sonoma, :high-sierra, :mojave: สำหรับรันเวอร์ชันเฉพาะ
  • อิมเมจ naked เหมาะกับโฟลว์ที่บูตดิสก์อิมเมจเดิมซ้ำ ๆ หรือย้อนคอนเทนเนอร์กลับไปยังสถานะก่อนหน้า
  • auto และ naked-auto ใช้กับ งานที่เน้น command line หรืองาน headless เช่นการ build ผ่าน Homebrew ได้

ฟีเจอร์หลัก

  • ฟีเจอร์ที่ Docker-OSX ระบุมีดังนี้
    • ใช้งาน iPhone OSX KVM บน Linux ด้วย usbfluxd
    • รัน VM macOS Monterey
    • แชร์โฟลเดอร์
    • USB passthrough และ hotplug
    • เปิดใช้ SSH: localhost:50922
    • เปิดใช้ VNC: localhost:8888 เมื่อใช้เวอร์ชัน ./vnc
    • งานวิจัยความปลอดภัย iMessage ผ่าน serial number generator
    • X11 forwarding
    • รองรับ Big Sur, อิมเมจแบบกำหนดเอง และโหมด headless ผ่าน Xvfb
    • โคลนคอนเทนเนอร์ได้ด้วย docker commit
  • รองรับ Kubernetes ด้วย และระบุว่า Helm Chart กับเอกสารอยู่ในไดเรกทอรี helm

ข้อกำหนดและการตั้งค่าเริ่มต้น

  • ข้อกำหนดขั้นต่ำมีดังนี้
    • พื้นที่ดิสก์ 20GB ขึ้นไป
    • 50GB เมื่อใช้ Xcode
    • อย่างน้อย 50GB เมื่อใช้ :auto
    • เปิดใช้งาน virtualization ใน BIOS
    • โฮสต์ x86_64 ที่ใช้ KVM ได้
  • การตั้งค่าเริ่มต้นเป็นโฟลว์ที่ติดตั้ง QEMU และ dependency ที่เกี่ยวข้องบนโฮสต์ จากนั้นเปิดใช้งาน libvirtd, virtlogd และโมดูลเคอร์เนล KVM
  • มีคำสั่งติดตั้งแพ็กเกจสำหรับ Arch, Ubuntu/Debian และ CentOS/RHEL/Fedora แยกกัน
  • ในบางกรณีผู้ใช้อาจต้องอยู่ในกลุ่ม Docker, KVM และ libvirt และต้องตรวจสอบด้วยว่า Docker daemon กำลังทำงานอยู่

เงื่อนไขการรันบน Windows

  • การรัน Docker-OSX บน Windows ทำได้ในสภาพแวดล้อม Windows 11 + WSL2
    • ต้องใช้ Windows 11 build 22000+, 21H2 ขึ้นไป
    • หลังติดตั้ง WSL ให้เพิ่ม nestedVirtualization=true ใน .wslconfig
    • ตรวจสอบว่าใช้ /dev/kvm และ KVM acceleration ได้หรือไม่ใน WSL distribution ด้วย kvm-ok
    • ต้องเปิดใช้เอนจินบน WSL2 และการผสานรวมกับ WSL distribution หลักใน Docker for Windows
  • วิธีแสดงผลหน้าจอแบ่งเป็น 3 แบบ
    • WSLg: เป็นตัวเลือกที่ง่ายที่สุดและแนะนำ แต่การส่งต่อคีย์บอร์ดหรือปัญหาเมาส์ตัวที่สองปรากฏอาจเกิดขึ้นได้
    • VNC: ใช้ QEMU VNC หรือการตั้งค่าในส่วน VNC
    • Desktop Environment: ใช้ทรัพยากรมากกว่า แต่ให้ประสบการณ์เดสก์ท็อป Linux แบบเต็ม

การแชร์ไฟล์และการจัดการดิสก์

  • เสนอ sshfs เป็นวิธีแชร์ที่ง่ายและปลอดภัยที่สุด
    • บน Linux/Windows ให้เมานต์ macOS rootfs ใน userspace ด้วยรูปแบบ sshfs user@localhost: -p 50922 ~/mnt/osx
  • QEMU 9p sharing ก็ทำได้
    • ส่งโฟลเดอร์ของโฮสต์เข้าไปในคอนเทนเนอร์เป็น /mnt/hostshare
    • เมานต์ภายใน macOS ด้วย sudo -S mount_9p hostshare
  • มีคำแนะนำเรื่อง NFS sharing ด้วย
    • ลงทะเบียนไดเรกทอรีที่จะแชร์ใน /etc/exports ของโฮสต์
    • เริ่มคอนเทนเนอร์ Docker-OSX ด้วย --network host
    • ใช้ mount_nfs ในเทอร์มินัล macOS
  • เมื่อพื้นที่ดิสก์ของ Docker ไม่พอ สามารถย้าย /var/lib/docker ไปยังไดรฟ์ภายนอก, block storage, NFS ฯลฯ แล้วสร้าง symbolic link ได้
    • แนะนำให้ทำตามบทเรียนที่เกี่ยวข้องก็ต่อเมื่อยอมรับความเป็นไปได้ที่จะลบ Docker image และ layer ปัจจุบันได้เท่านั้น

iPhone USB และ USB passthrough

  • สำหรับเดสก์ท็อป PC มีลิงก์แยกอธิบายวิธี iPhone USB passthrough บน VFIO
  • บนโน้ตบุ๊ก, PC ฯลฯ สามารถใช้ USB passthrough แบบเครือข่ายผ่าน usbfluxd ได้
    • เชื่อมต่อ iPhone หรือ iPad กับ Linux ผ่าน USB
    • เปิดเผย usbmuxd ผ่านพอร์ต TCP 5000
    • เชื่อมต่อไปยังโฮสต์จาก guest macOS ด้วยรูปแบบ usbfluxd -f -r 172.17.0.1:5000
    • ระบุว่าเมื่อปิดแล้วเปิดแอปอย่าง Xcode ใหม่ อุปกรณ์จะปรากฏขึ้น
  • สำหรับ USB passthrough ทั่วไป ระบุว่าต้องเริ่ม QEMU ด้วยสิทธิ์ root
    • ตรวจสอบ bus และ port ด้วย lsusb -t
    • ใช้ --privileged, /dev/kvm, EXTRA="-device ... usb-host ..." เป็นต้น
    • ระหว่าง VM ทำงาน ระบบโฮสต์จะเข้าถึงอุปกรณ์ USB นั้นไม่ได้

Headless, VNC, SPICE และการรันระยะไกล

  • การรันแบบ headless ทำโดยลบสองบรรทัดที่เกี่ยวกับ X11 ออกจาก docker run
    • ลบวอลุ่ม /tmp/.X11-unix
    • ลบตัวแปรสภาพแวดล้อม DISPLAY
  • ระบุว่าคอนเทนเนอร์ headless ที่ใช้อิมเมจแบบกำหนดเองมีประโยชน์กับ CI/CD pipeline
  • VNC สามารถใช้แบบ local-only ได้ แต่ README ระบุชัดว่า ไม่มีการเข้ารหัส TLS/HTTPS เลย
    • แนะนำว่าจะปลอดภัยขึ้นเมื่อใช้ SSH tunnel และปิดพอร์ตภายนอก
  • SPICE ก็ใช้งานได้
    • เชื่อมต่อด้วย remote-viewer spice://localhost:3001
    • -disable-ticketing ในตัวอย่างอนุญาตให้เข้าถึง VM โดยไม่มีการยืนยันตัวตน จึงแนะนำให้อ้างอิงการตั้งค่าการยืนยันตัวตนในคู่มือ SPICE

ซีเรียลนัมเบอร์และงานวิจัย iMessage/iCloud

  • ค่าที่ต้องเปลี่ยนเพื่อใช้ iMessage หรือ iCloud ได้แก่
    • SERIAL
    • BOARD_SERIAL
    • UUID
    • MAC_ADDRESS
    • อธิบายว่า ROM คือ MAC address ตัวพิมพ์เล็กที่ลบเครื่องหมายโคลอนออก
  • Docker-OSX มีให้สองวิธี
    • GENERATE_UNIQUE=true: สร้างค่าที่ไม่ซ้ำกันตอน runtime
    • GENERATE_SPECIFIC=true: ใช้ค่าที่กำหนดไว้
  • ./custom/generate-unique-machine-values.sh สามารถสร้างซีเรียลนัมเบอร์, MAC address, เอาต์พุต CSV/TSV และอิมเมจ boot disk ได้
  • ตรวจสอบซีเรียลนัมเบอร์ภายใน macOS ได้ด้วย ioreg -l | grep IOPlatformSerialNumber

ประสิทธิภาพ ความละเอียด และการตั้งค่าเครือข่าย

  • ระบุว่าสามารถใช้ osx-optimizer เพื่อทำให้คอนเทนเนอร์เร็วขึ้นได้
    • ข้ามหน้าจอ login แบบ GUI
    • ปิดใช้งาน Spotlight indexing
    • ปิดใช้งานพื้นหลังหน้าจอ login ที่หนัก
    • ปิดใช้งานการอัปเดต
  • เปลี่ยนความละเอียดได้ด้วยตัวแปรสภาพแวดล้อม WIDTH และ HEIGHT
    • ต้องใช้ร่วมกับ GENERATE_UNIQUE=true หรือ GENERATE_SPECIFIC=true
    • การบูตจะใช้เวลานานขึ้นประมาณ 30 วินาทีเพื่อสร้าง boot partition ใหม่
    • ความละเอียดที่ไม่ถูกต้องจะถูกตั้งเป็นค่าเริ่มต้น 800x600
  • เปลี่ยน network adapter ได้ด้วยตัวแปรสภาพแวดล้อม
    • การเชื่อมต่ออินเทอร์เน็ตเร็ว: NETWORKING=vmxnet3
    • การเชื่อมต่ออินเทอร์เน็ตช้า: NETWORKING=e1000-82545em
  • ระบุว่าการเปิด IPv4 forwarding ในการติดตั้งระยะไกลอาจช่วยเพิ่มประสิทธิภาพ แต่ IP ของโฮสต์อาจรั่วไหลได้แม้จะใช้ VPN ในคอนเทนเนอร์

การแก้ปัญหาและข้อจำกัด

  • หาก Docker daemon ไม่ได้ทำงาน อาจเกิดข้อผิดพลาด docker: unknown server OS: .
    • sudo dockerd
    • sudo systemctl --start dockerd
    • sudo systemctl --enable --now dockerd
  • ไม่สามารถจัดสรร RAM ได้มากกว่าเครื่องจริง
    • ค่าเริ่มต้นคือ -e RAM=3
    • หากจัดสรรเกิน อาจเกิดข้อผิดพลาด cannot set up guest memory 'pc.ram': Cannot allocate memory
  • ข้อผิดพลาดเกี่ยวกับ ALSA อาจปรากฏระหว่างการเริ่มต้นคอนเทนเนอร์หรือการบูต และระบุว่าไม่ต้องกังวลหากการบูตและฟังก์ชันทำงานตามปกติ
  • ใน TODO ยังเหลือรายการต่อไปนี้
    • เอกสารสำหรับนักวิจัยด้านความปลอดภัย
    • GPU acceleration
    • การรองรับ virt-manager

ไลเซนส์และประกาศ

  • Docker-OSX อยู่ภายใต้ไลเซนส์ GPL v3+
  • ระบุว่าอนุญาตให้ใช้ Docker-OSX เป็นเครื่องมือสำหรับสร้างซอฟต์แวร์แบบ proprietary ได้
  • มีประกาศเกี่ยวกับงานวิจัยความปลอดภัยของ Apple และ Apple Bug Bounty Program และลิงก์บทความแยกเกี่ยวกับประเด็นทางกฎหมายของ Hackintosh, OSX-KVM และ Docker-OSX
  • ผลิตภัณฑ์ โลโก้ แบรนด์ และเครื่องหมายการค้าที่กล่าวถึงในโปรเจกต์เป็นทรัพย์สินของเจ้าของแต่ละราย และผู้ถือสิทธิ์ในเครื่องหมายการค้าเหล่านั้นไม่ได้เป็นพันธมิตร สนับสนุน หรือรับรอง repository นี้

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

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

 
GN⁺ 2024-08-01
ความเห็นจาก Hacker News

  • เรื่องนี้สำคัญสำหรับคนที่ตั้งใจจะใช้โปรเจกต์จริง ๆ แต่ไม่เข้าใจว่าทำไม สูตรบิลด์อย่าง Dockerfile จำนวนมากถึงถูกทำให้ดาวน์โหลดทรัพยากรสุ่ม ๆ จากอินเทอร์เน็ตระหว่างกระบวนการบิลด์
    Dockerfile ของโปรเจกต์นี้ก็ดึง Git repository 2 แห่งกับสคริปต์ 1 ตัวมาตอนบิลด์
    แน่นอนว่ามันจะล้มเหลวบนเซิร์ฟเวอร์บิลด์แบบ sandbox ที่ปิดการเข้าถึงอินเทอร์เน็ต และใครก็ตามที่ใส่ใจเรื่องความปลอดภัยแม้แต่นิดเดียวก็ต้อง audit สูตรบิลด์ทั้งหมดก่อนใช้งาน
    แค่ตรวจ dependency ที่ระบุไว้ในข้อกำหนดการบิลด์อย่าง README, requirements.txt หรือ package.json นั้นไม่พอแล้ว และเมื่อดูจากเหตุขัดข้องของโครงสร้างพื้นฐานหลัก ๆ เมื่อเร็ว ๆ นี้กับการเพิ่มขึ้นของ การโจมตี supply chain ก็ถือเป็นแนวโน้มที่น่ากังวลมาก

    • ผมเกลียดจริง ๆ เวลาที่โปรเจกต์ดึงไฟล์สำหรับบิลด์มาจากอินเทอร์เน็ต ปกติมันเกิดขึ้นแบบไม่คาดคิด และนอกจากปัญหาความปลอดภัยแล้ว ยังทำให้การแพ็กเกจซอฟต์แวร์ที่พึ่งพามันยากขึ้นมาก
      มี surprise ที่ไม่น่าพอใจ เช่น ปัญหาเวอร์ชัน ไม่มีอินเทอร์เน็ต หรือแย่ที่สุดคือ dependency ไม่ถูกให้บริการอีกต่อไป การแจกจ่ายแบบ self-contained ควรเป็นค่าเริ่มต้น
    • คำตอบคือ ความปั่นป่วนจากการเปลี่ยนแปลง (churn) พื้นที่ DevOps เปลี่ยนแปลงหนักมากจนตอนนี้ไม่มีใครมีเวลาพอจะเข้าใจว่า “วิธีที่ถูกต้อง” คืออะไรแล้ว
    • ทิศทางที่ถูกต้องคือรอให้ ผู้เล่นโอเพนซอร์ส รายใหญ่อย่าง Red Hat, SUSE, Canonical ทำให้การบิลด์ปลอดภัย
      Fedora และ openSUSE มักมีนโยบายให้การบิลด์ รวมถึงแพ็กเกจของดิสโทรและ container image ใช้เฉพาะแพ็กเกจใน repository หรือไบนารีที่เพิ่มเข้ามาอย่างชัดเจนระหว่างบิลด์เท่านั้น
      ดังนั้นถ้าติดตั้งได้ด้วย dnf/zypper install หรือดึงจาก container registry ของ vendor ได้ ก็สามารถเชื่อถือผลลัพธ์ได้
      ถ้าต้องการของล่าสุดแบบ bleeding edge ก็ต้องยอมรับทรัพยากรสุ่ม ๆ จากอินเทอร์เน็ต
      นักพัฒนาโอเพนซอร์สทั่วไปยากที่จะสร้าง artifact สำหรับบิลด์ที่พร้อมใช้ออฟไลน์และเชื่อถือได้ และพวกเขาไม่มีโครงสร้างพื้นฐานแบบนั้น นั่นจึงเป็นเหตุผลที่บริษัทอย่าง Red Hat หรือ SUSE มีอยู่
      องค์กรระดับหลายพันล้านดอลลาร์ยินดีจ่ายเงินเพื่อให้มีคนทำงานระบบท่อเบื้องหลัง เปลี่ยน artifact สุ่ม ๆ จากอินเทอร์เน็ตให้เป็น artifact ที่เชื่อถือได้ ทำซ้ำได้ และมีลายเซ็น พร้อมติดตาม CVE และอัปเดตเป็นประจำ
    • ไม่เห็นว่ามันต่างอะไรกับการที่ JavaScript ดึง dependency หลายหมื่นตัว แค่เพื่อแสดงเว็บเพจหน้าเดียว
      ในยุค 80 เราเคยจินตนาการถึงคอมโพเนนต์ซอฟต์แวร์แบบ modular reusable ที่เสียบต่อกันเหมือนตัวต่อเลโก้ ตอนนั้นเรียกว่า CASE ตอนนี้มันเป็นจริงแล้ว แต่แน่นอนว่ามีราคาที่ต้องจ่าย
    • เหตุผลหลักน่าจะเป็นการรักษา การจัดระเบียบองค์ประกอบ ไว้ใน Git repository แยกต่างหาก
      ถ้าไม่ clone ใน Dockerfile ก็ต้องมีคำสั่งก่อนบิลด์ว่า “ตอน clone ให้ใช้ --recursive หรือใช้ git submodule init เพื่อดึง repository อื่นเข้ามาใน working directory ปัจจุบัน”

  • ความเป็นไปได้เดียวของการเร่งความเร็วด้วย GPU คือส่งต่อ dGPU ที่รองรับผ่าน PCI passthrough ไปให้ AMD RX 6xxx ขึ้นไปทำได้บน macOS 14.x แต่ Nvidia รุ่นใหม่ ๆ แทบไม่มีทาง
    Intel iGPU ใช้งานได้ถึง Comet Lake และบางส่วนของ Ice Lake แต่รุ่นใหม่กว่านั้นไม่ได้
    macOS ที่เป็น build สำหรับ Apple Silicon ดูเหมือนจะยัง emulate ได้ยากไปอีกสักพัก และมีงานระยะแรก ๆ บ้างเกี่ยวกับการบูต ARM Darwin
    นอกจากนี้ AMD ไม่มี Intel VT-x ทำให้ virtualization บนโฮสต์ AMD พัง แต่มี hack แปลก ๆ ผ่าน VirtualBox รุ่นเก่าที่ทำให้ Docker พอทำงานผ่าน emulation ได้ในระดับหนึ่ง

    • ในทางทฤษฎี อาจมีใครสักคนสร้าง display driver สำหรับ 3D acceleration ของ libvirt/kvm/qemu เหมือนที่มีบน Windows และ Linux ได้ แบบนั้นแม้ประสิทธิภาพจะไม่ดีที่สุด แต่ก็จะทำให้ใช้สมรรถนะ GPU ได้กับ GPU แทบทุกตัว
      AMD มีทางเลือกของตัวเองแทน VT-x คือ AMD-V ดังนั้นควรทำงานได้โดยไม่มีปัญหา อย่างไรก็ตาม การบูต macOS บน CPU AMD ยังมีอุปสรรคอื่น ๆ และมักแก้ด้วยการโหลด kext หรือกลเม็ดอื่น
      ไม่ค่อยเข้าใจความหมายของการรันทั้งระบบปฏิบัติการด้วย Docker เท่าไร แจกจ่ายเป็น OVA หรือรูปแบบ virtualization ที่ชอบก็พอ แค่ qcow2 กับ bash script สำหรับเริ่ม VM ก็น่าจะเพียงพอแล้ว
    • ตรงที่ว่า “AMD ไม่มี Intel VT-x ทำให้ virtualization บนโฮสต์ AMD พัง” ใช้ AMD-V ไม่ได้เหรอ?

  • บทความที่เกี่ยวข้อง:
    Docker-OSX: Run macOS VM in a Docker - https://news.ycombinator.com/item?id=34374710 - มกราคม 2023, 110 ความเห็น
    macOS in QEMU in Docker - https://news.ycombinator.com/item?id=23419101 - มิถุนายน 2020, 186 ความเห็น

  • ผมเคยตั้งค่าเล่นเป็นการทดลองเมื่อไม่กี่เดือนก่อน และมันทำงานได้ค่อนข้างดี แต่พบว่าเพื่อให้ iMessage ทำงาน แอปพลิเคชันจะส่ง hardware ID ไปให้ Apple และโปรเจกต์นี้ใช้ ค่าปลอม
    จากจุดนั้นก็เริ่มไถลลงทางลาดของ “ไม่น่าจะไหว” และพบว่าค่าปลอมอาจถูก Apple flag ทำให้ iCloud ID ถูกระบุว่าเป็นผู้ส่งสแปมที่อาจเป็นไปได้ และจำกัดการเข้าถึงจากอุปกรณ์อื่น ๆ
    ตัวเลือกเดียวคือใช้ สคริปต์สร้าง hardware ID ที่ลิงก์ไว้อย่างคลุมเครือ ลองค่าไปเรื่อย ๆ เพื่อหาค่าที่ “ใช้ได้” แต่ไม่มีสัญญาณชัดเจนว่ามันตรงจริง ๆ และจะไม่ทำลาย reputation ของ iCloud
    นอกเหนือจากนั้นมันทำงานได้ดีจริง ๆ และมีประโยชน์มากเวลาจำเป็น

    • วิธี “เปลี่ยน HWID ไปเรื่อย ๆ จนกว่าจะใช้ได้” ก็เคยพบได้บ่อยในการทำให้ iMessage ทำงานบน Hackintosh สามารถตรวจว่าทำงานหรือไม่ที่ checkcoverage.apple.com
      ไม่นานก็พบว่าการคัดลอก Serial จาก Mac จริงที่เก่าแล้วง่ายกว่า
      อย่างไรก็ตาม เครื่องมือนี้ดูจะมีประโยชน์มากกว่าสำหรับงานอย่าง build script ที่พึ่งพา framework เฉพาะของ macOS มากกว่าจะใช้เหมือนคอมพิวเตอร์ส่วนตัว
    • สำหรับงานวิจัยด้านความปลอดภัย โดยทั่วไปไม่ควรใช้ บัญชี iCloud หลัก หรือบัญชีหลักอื่น ๆ

  • แค่อยากลองดูว่าสามารถบิลด์สำหรับ iOS ได้ไหม เช่นพวก Unity, React Native
    แม้การบิลด์จะใช้เวลานานขึ้น 5 เท่า แต่ในแง่ของ ความยืดหยุ่น ก็น่าจะเจ๋งทีเดียว

    • การคอมไพล์ข้ามแพลตฟอร์ม น่าจะเป็นแนวทางที่ดีกว่า: https://github.com/tpoechtrager/osxcross
      วิธีที่ Godot ใช้บิลด์ไปยังเป้าหมาย iOS ก็เป็นแนวนี้: https://github.com/godotengine/build-containers/blob/main/Do...
      มี Docker image ที่ติดตั้งเครื่องมือไว้ล่วงหน้าด้วย แต่ถ้าจะตั้งเป้าเป็น iOS ต้องแก้เล็กน้อย: https://github.com/shepherdjerred/macos-cross-compiler
      ตอนอยู่ที่ RStudio ซึ่งปัจจุบันคือ Posit เคยทำงานคอมไพล์ข้ามแพลตฟอร์ม C/C++/Fortran/Rust จากโฮสต์ Linux ไปยัง macOS x86_64/aarch64
      ถ้าดาวน์โหลดแพ็กเกจ R ที่มีโค้ด native จาก Posit Package Manager(https://p3m.dev/client/) ก็เป็นแพ็กเกจที่คอมไพล์ข้ามแพลตฟอร์มด้วยวิธีนี้ :)
    • เคยลองทำเองแล้ว ต้องหาทางแชร์พอร์ต USB ข้าม Docker ให้ได้ และถ้าทำตามคำแนะนำในรีโปก็แทบจะเหมือนมนตร์ดำ แต่หลังจาก บิลด์แอป iOS แล้วก็รันบน iPhone ได้
    • ถ้าสามารถบิลด์ React Native iOS ที่มีโมดูล Swift แบบ native ในสภาพแวดล้อมนี้บนเครื่อง Windows แล้วรันใน simulator ได้ ก็น่าประทับใจทีเดียว

  • เคยสัมภาษณ์ Sick Codes เกี่ยวกับแนวทางของผลิตภัณฑ์นี้มาก่อน: https://www.vice.com/en/article/akdmb8/open-source-app-lets-...
    ยังมี OSX-PROXMOX ที่ทำสิ่งคล้ายกันบนโฮมเซิร์ฟเวอร์ Proxmox: https://github.com/luchina-gabriel/OSX-PROXMOX
    ส่วนตัวใช้ตัวหลังบน HP Z420 Xeon อยู่ และเสถียรมาก โดยเฉพาะเมื่อทำ GPU passthrough

  • ถ้ารัน การซิงก์ iCloud บนโฮมเซิร์ฟเวอร์ได้ก็คงดี ตอนนี้ยังไม่มีวิธีดี ๆ ในการสำรอง iCloud ไปยังโฮมเซิร์ฟเวอร์/NAS โดยตรง และมันทำงานได้เฉพาะบน Windows/Apple เท่านั้น

    • สิ่งนี้อาจช่วยซิงก์ข้อมูลแล้วเก็บไว้ในเครื่อง หรือสำรองไปที่อื่นได้:
      https://github.com/steilerDev/icloud-photos-sync
      https://github.com/icloud-photos-downloader/icloud_photos_do...
    • กำลังทำโซลูชันที่ใช้ OSX-Docker กับ OSXPhotos อยู่ ใกล้สำเร็จพอสมควรแล้ว แต่ต้องการสำรองข้อมูลทั้งหมดจาก iCloud รวมถึง การเปลี่ยนแปลงเมทาดาทา ด้วย
      ปรากฏว่า iCloud ไม่ได้อัปเดตรูปต้นฉบับ ก็เข้าใจได้ แต่ไม่ช่วยคนที่คาดหวังว่าการสำรองข้อมูลจะรวมการเปลี่ยนแปลงเหล่านั้นด้วย
    • สงสัยว่าสิ่งนี้จะช่วยแก้ปัญหานั้นได้อย่างไร มันทำให้ทำอะไรต่างจากการ rsync โฟลเดอร์ iCloud จาก Mac/PC ที่เชื่อมต่ออยู่ไปยัง NAS ได้บ้าง?

  • สงสัยว่า การแจกจ่าย image ของ MacOS ซ้ำ ได้รับอนุญาตตามไลเซนส์หรือไม่ หรือโปรเจกต์นี้กำลังแจกจ่ายสำเนาละเมิดลิขสิทธิ์บน Docker Hub อย่างเปิดเผย?

    • ไม่แน่ใจ แต่ Corellium เคย virtualize อินสแตนซ์ iOS แล้วถูก Apple ฟ้อง ก่อนจะตกลงยุติคดีกัน
    • อันนี้ผิดกฎหมายชัดเจน

  • สงสัยว่าถ้ามี MacOS เวอร์ชันใหม่กว่าที่ตัดการรองรับ Intel ออกไปแล้ว ความคืบหน้าจะหยุดหรือไม่
    สามารถรัน Docker ภายในคอนเทนเนอร์นี้เพื่อรัน MacOS ใน MacOS ได้ไหม? ;)

    • ในทางทฤษฎี สามารถรัน qemu ใน โหมดอีมูเลชันเต็มรูปแบบ ได้เสมอ
    • ก็ทำแบบนั้นได้เลยในโปรแกรม VM ใด ๆ ที่รองรับ

  • เกลียดมากเวลาคำว่า “USB passthrough” ถูกใช้กับสถานการณ์ที่จริง ๆ แล้วอย่างดีก็เป็น “USB proxy ผ่านอีเทอร์เน็ต”
    นั่นไม่ใช่ passthrough มันมีข้อเสียหลายอย่างที่ passthrough ทั่วไปไม่มี และ passthrough ขั้นสูงก็อาจไม่มีด้วย

    • QEMU USB passthrough คือ USB passthrough ของจริง ปัญหาของ USB passthrough มาจากตัว USB controller เองและวิธี enumerate อุปกรณ์ และทางแก้ที่ดีกว่าเพียงอย่างเดียวคือทำ PCIe passthrough ของ USB controller ทั้งตัว
      แต่แนวทางนั้นก็นำปัญหาอื่น ๆ มาอีก จากประสบการณ์ที่เคยดูแล VM test farm ขนาดใหญ่ที่มีฮาร์ดแวร์ถูกส่งผ่านจำนวนมาก
      อย่างไรก็ตาม “USB proxy ผ่านอีเทอร์เน็ต” ก็เป็น passthrough ของจริงเช่นกัน เพียงแต่เป็น passthrough ที่มี latency สูงกว่า VirtIO เท่านั้น