🍎 Complete VPHONE600AP Virtual iPhone Research Guide
Building a Virtual iPhone with VPHONE600AP and super-tart In early 2026, security researchers demonstrated a virtual iPhone environment assembled from VPHONE600AP components found in Apple's Private Cloud Compute firmware, modified virtualization tooling and selected iOS firmware files. The result is not the ordinary Xcode Simulator. It is an experimental virtual device capable of progressing through an iPhone-style boot chain, running a modified mobile operating system and exposing its interface through a macOS virtualization window or VNC. This article presents an original, condensed explanation of the research published by wh1te4ever. It focuses on the architecture, major stages, practical requirements and security implications rather than reproducing the original write-up line by line. Original research and images: Link available to registered users Simplified all-in-one launcher: Link available to registered users Underlying vphone-cli project: Link available to registered users Important Security Notice This is experimental security-research software. The workflow can require disabling macOS System Integrity Protection and weakening AMFI enforcement. It also uses modified boot components, jailbroken system files and private virtualization behaviour. Use a dedicated research Mac with a complete backup. Do not use a primary workstation containing personal accounts, production credentials, cryptocurrency wallets or confidential files. Where VPHONE600AP Came From Apple's Private Cloud Compute platform introduced firmware and virtualization components intended for cloud-based Apple silicon workloads. Researchers later identified references to a vphone600-style virtual device in cloudOS 26 firmware. The available information suggested an internal iPhone Research Environment Virtual Machine rather than a conventional consumer simulator. Link available to registered users The device-tree information shown above references VPHONE600-related variants, an iPhone research device and a virtual-machine product string. These identifiers gave researchers a starting point for understanding the expected hardware model. The discovery raised an interesting question: could the available firmware components be combined with Apple's Virtualization framework to boot a functional virtual iPhone on a Mac? Why super-tart Was Needed The open-source Tart project normally creates and manages macOS and Linux virtual machines on Apple silicon. The research required functionality outside Tart's standard platform model. The modified build, commonly called super-tart, extends the virtual-machine configuration with research-oriented components such as: - a custom hardware model; - a research boot ROM; - SEP-related configuration; - serial output; - DFU-style restore support; - custom firmware paths; - experimental graphics and touch devices; - debugging interfaces. Link available to registered users The screenshot shows research-platform handling being added to the Swift virtual-machine configuration. The important idea is that the VM must identify itself as a supported research platform before the private virtualization components will accept the configuration. VRESEARCH101 Virtual-Machine Configuration The following Swift excerpt is the central configuration section discussed in the original write-up. It constructs the research hardware model, assigns the platform identity, connects custom boot and SEP components, enables keyboard and touch devices, and creates an iPhone-sized virtual display. ```swift class VM: NSObject, VZVirtualMachineDelegate, ObservableObject { // vzHardwareModel derives the VZMacHardwareModel configuration // specific to the VM platform type. static private func vzHardwareModel_VRESEARCH101() throws -> VZMacHardwareModel { var hw_model: VZMacHardwareModel guard let hw_descriptor = _VZMacHardwareModelDescriptor() else { fatalError("Failed to create hardware descriptor") } hw_descriptor.setPlatformVersion(3) // .appleInternal4 = 3 hw_descriptor.setBoardID(0x90) hw_descriptor.setISA(2) hw_model = VZMacHardwareModel._hardwareModel(withDescriptor: hw_descriptor) guard hw_model.isSupported else { fatalError("VM hardware config not supported (model.isSupported = false)") } return hw_model } static func craftConfiguration( diskURL: URL, nvramURL: URL, romURL: URL, sepromURL: URL? = nil, vmConfig: VMConfig, network: Network = NetworkShared(), additionalStorageDevices: [VZStorageDeviceConfiguration], directorySharingDevices: [VZDirectorySharingDeviceConfiguration], serialPorts: [VZSerialPortConfiguration], suspendable: Bool = false, nested: Bool = false, audio: Bool = true, clipboard: Bool = true, sync: VZDiskImageSynchronizationMode = .full, caching: VZDiskImageCachingMode? = nil ) throws -> VZVirtualMachineConfiguration { let configuration: VZVirtualMachineConfiguration = .init() // Boot loader let bootloader = try vmConfig.platform.bootLoader(nvramURL: nvramURL) Dynamic(bootloader)._setROMURL(romURL) configuration.bootLoader = bootloader // SEP ROM and persistent SEP storage let homeURL = FileManager.default.homeDirectoryForCurrentUser let sepstoragePath = homeURL .appendingPathComponent(".tart/vms/vphone/SEPStorage").path let sepstorageURL = URL(fileURLWithPath: sepstoragePath) let sep_config = Dynamic._VZSEPCoprocessorConfiguration( storageURL: sepstorageURL ) if let sepromURL { // Otherwise use AVPSEPBooter.vresearch1.bin from the framework. sep_config.romBinaryURL = sepromURL } sep_config.debugStub = Dynamic._VZGDBDebugStubConfiguration(port: 8001) configuration._setCoprocessors([sep_config.asObject]) // VRESEARCH101 platform configuration let pconf = VZMacPlatformConfiguration() pconf.hardwareModel = try vzHardwareModel_VRESEARCH101() let serial = Dynamic._VZMacSerialNumber.initWithString("AAAAAA1337") let identifier = Dynamic.VZMacMachineIdentifier ._machineIdentifierWithECID( 0x1111111111111111, serialNumber: serial.asObject ) pconf.machineIdentifier = identifier.asObject as! VZMacMachineIdentifier pconf._setProductionModeEnabled(true) let auxiliaryStoragePath = homeURL .appendingPathComponent(".tart/vms/vphone/nvram.bin").path let auxiliaryStorageURL = URL(fileURLWithPath: auxiliaryStoragePath) pconf.auxiliaryStorage = VZMacAuxiliaryStorage(url: auxiliaryStorageURL) if #available(macOS 14, ) { let keyboard = VZUSBKeyboardConfiguration() configuration.keyboards = [keyboard] } if #available(macOS 14, ) { let touch = _VZUSBTouchScreenConfiguration() configuration._setMultiTouchDevices([touch]) } configuration.platform = pconf // iPhone-sized virtual display let graphics_config = VZMacGraphicsDeviceConfiguration() let displays_config = VZMacGraphicsDisplayConfiguration( widthInPixels: 1179, heightInPixels: 2556, pixelsPerInch: 460 ) graphics_config.displays.append(displays_config) configuration.graphicsDevices = [graphics_config] // The complete project adds storage, networking, serial, // audio and other devices before validating the configuration. return configuration } } ``` This code relies on private or dynamically accessed virtualization interfaces. Availability and behaviour can change between macOS releases, and App Store software should not depend on these interfaces. High-Level Architecture The complete environment consists of several layers: - a compatible Apple silicon Mac; - Apple's Virtualization framework; - a modified super-tart launcher; - VPHONE600AP or related PCC firmware components; - selected iOS firmware components; - virtual NVRAM and SEP storage; - a custom virtual disk; - local SSH and VNC forwarding; - optional Metal and touch integration. This is why the project cannot be reduced to simply opening an IPSW file in a normal virtual-machine application. Preparing the macOS Host The simplified vphone-aio project documents the following Homebrew dependencies: ```bash brew install git-lfs wget zstd libimobiledevice ``` Xcode or compatible Apple development tools are also required because the launcher uses Swift and code-signing tools while preparing the VM. The downloaded package is large. The vphone-aio repository reports roughly 12 GB of split archive data and recommends more than 128 GB of free storage for downloading, reconstruction, extraction and runtime files. Host Security Changes The underlying research workflow requires access to private or restricted virtualization behaviour. The documented environment therefore expects SIP to be disabled and an AMFI-related boot argument to be configured. These changes reduce host security. They should never be treated as harmless setup switches. Before changing them: - create a complete backup; - record the original configuration; - disconnect unnecessary storage devices; - isolate the Mac from sensitive networks; - use temporary research accounts; - plan how to restore normal protection afterward. Firmware Assembly The original research combined components associated with cloudOS 26.1 and iOS 26.1. Rather than using an untouched consumer IPSW, the workflow assembled a custom restore environment matching the virtual research platform. At a conceptual level, this involved: 1. Extracting the required firmware packages. 2. Selecting the VPHONE-related boot and hardware components. 3. Combining them with compatible iOS system components. 4. Adjusting restore manifests for the virtual device. 5. Preparing a virtual disk and auxiliary storage. 6. Restoring the custom environment through the modified VM. The exact component combination is version-specific. Addresses, manifests and patches from one firmware release should not be assumed to work with another. Reference Firmware and Reproducibility Scope The published experiment used matching build numbers from two sources: - cloudOS 26.1 build 23B85; - iOS 26.1 for iPhone17,3, also build 23B85. Keeping the build number aligned matters because the boot chain, kernel, trust caches, Cryptex images and system libraries are closely coupled. Mixing components from unrelated builds can produce failures that look like configuration errors but are actually binary incompatibilities. The original researcher explicitly notes that the final firmware mixture was developed experimentally and was not completely reconstructed from memory in the narrative. For reproducible work, use the final BuildManifest.plist and Restore.plist supplied in the source repository as versioned research artifacts rather than attempting to infer every manifest field from prose. Build manifest: Link available to registered users Restore configuration: Link available to registered users The SystemVolume, SystemVolumeCanonicalMetadata, OS, StaticTrustCache, RestoreTrustCache and RestoreRamDisk entries were associated with the iPhone firmware side of the combined restore. VPHONE-related kernel, hardware and firmware material came from the PCC-derived side. Record a hash for every input artifact and preserve a machine-readable build log. Without that record, a later boot failure cannot be reliably attributed to a source-file change, an operating-system update or a patching mistake. Boot-Chain Modification Model The experiment builds on ideas demonstrated by vma2pwn. That project extracts firmware payloads from IM4P containers, modifies selected instructions or boot arguments, repackages the payloads and restores the resulting firmware through a DFU workflow. Reference project: Link available to registered users The virtual-phone workflow applies the same general model to several stages: - AVPBooter provides the VM boot-ROM path; - iBSS initializes the early DFU restore stage; - iBEC continues restore and boot preparation; - LLB participates in normal-mode boot; - SPTM and TXM provide security-related runtime components; - the kernelcache provides the research kernel; - DeviceTree describes VPHONE600AP hardware; - SEP firmware and SEPStorage support the virtual security coprocessor; - restore and static trust caches authorize expected code during boot. Each stage must agree on the virtual platform identity and expected image types. A correctly patched kernel cannot compensate for an incompatible DeviceTree or a malformed IMG4 container. AVPBooter Research Patch AVPBooter.vresearch1.bin is used as the VM's research boot ROM. The original work identifies image4_validate_property_callback as a relevant validation path when loading a custom bootloader. The research method locates the function through a constant reference and changes its return behaviour in the laboratory copy. This is a version-specific binary modification. Do not apply offsets from another AVPBooter build, and never modify the framework's original file in place. Use this laboratory procedure: 1. Hash and preserve the original AVPBooter binary. 2. Work on a duplicate stored inside the project directory. 3. Identify the function independently in the exact binary version. 4. document the virtual address, file offset and original bytes. 5. Apply the modification to the duplicate. 6. Hash the patched result. 7. configure super-tart to use the explicit patched ROM path. This preserves rollback and allows another researcher to verify precisely which artifact entered the experiment. libirecovery and the VRESEARCH101AP Target Standard restore tooling may not recognize the research product type. The referenced libirecovery fork adds the identifiers required for the vresearch101ap environment. Link available to registered users After building the modified library, idevicerestore can communicate with the VM in DFU mode and perform the custom restore. Confirm that the tool reports the expected research device before writing firmware. A generic or incorrect product identifier is a sign that the USB personality, DeviceTree or recovery library is not aligned. Firmware Component Patch Inventory The write-up modifies several components for different reasons: - iBSS and iBEC are adjusted for the custom restore path and verbose diagnostics; - LLB is adjusted so the modified system volume and Cryptex arrangement can proceed; - TXM is repackaged while preserving its PAYP structure; - the kernelcache is repackaged with the correct research image type and required boot changes; - boot arguments enable serial logging for failure analysis; - trust caches are rebuilt for binaries introduced into the ramdisk or system volume. Treat every modification as a separate experimental variable. Change one component at a time, save its hash and retain the previous boot log. Otherwise, a successful or failed boot cannot be connected to a specific change. IMG4, IM4P and IM4M Preparation Firmware payloads are commonly stored as IM4P objects and delivered to the device as IMG4 containers. The IMG4 container also needs a suitable manifest object. The documented workflow first asks idevicerestore to obtain the SHSH material for the prepared restore, then extracts an IM4M object with pyimg4. That IM4M is subsequently used when creating bootable IMG4 files for the virtual device. The initial acquisition flow is represented by: ```bash idevicerestore -e -y ./iPhone17,3_26.1_23B85_Restore -t pyimg4 im4m extract -i ./shsh/vphone.shsh -o vphone.im4m ``` The exact SHSH filename contains the experiment's ECID and product identity. Do not copy a filename literally from another system. The prepared ramdisk boot set contains the following logical objects: - iBSS IMG4; - iBEC IMG4; - SPTM IMG4; - TXM IMG4; - ramdisk trust cache IMG4; - ramdisk IMG4; - VPHONE600AP DeviceTree IMG4; - VRESEARCH101 SEP firmware IMG4; - research kernel IMG4. TXM and kernel repackaging preserve the PAYP structure from the original IM4P objects. Losing that trailing structure or failing to correct container length metadata can produce an image that looks valid to a file parser but fails during the device boot path. Building the SSH Ramdisk The restore ramdisk is extracted, mounted on macOS and rebuilt with the utilities required for remote maintenance. Mach-O tools introduced into the ramdisk are ad-hoc signed, and a new trust cache is generated for the resulting filesystem. The scientific objective is not merely to obtain a shell. The ramdisk provides a controlled way to: - mount the restored APFS volumes; - inspect the snapshot layout; - install missing Cryptex contents; - repair symlinks to shared caches; - copy bootstrap tools; - collect logs from an otherwise unbootable guest; - shut the guest down cleanly before the next boot experiment. Keep the ramdisk minimal. Every additional binary expands the trust surface and makes failures harder to reproduce. Ramdisk Boot Order The documented boot sequence sends components in a strict order: 1. iBSS; 2. iBEC, followed by the go command; 3. SPTM as firmware; 4. TXM as firmware; 5. trust cache; 6. ramdisk; 7. DeviceTree; 8. SEP firmware; 9. research kernel, followed by bootx. Changing the order can leave a dependency unavailable when the next stage attempts to initialize. The complete reference script is available here: Link available to registered users Detecting a Successful Ramdisk Boot After the ramdisk starts, macOS System Information should expose an iPhone Research USB device. At that point, iproxy can forward the guest SSH service to localhost. ```bash iproxy 2222 22 ``` Connect only through the loopback interface. The reference environment uses a known research password, so exposing this port beyond localhost would be unsafe. APFS Snapshot Preparation The root volume is mounted read-write from the ramdisk. The active system snapshot is listed, renamed for the experimental root filesystem and then unmounted before further processing. The snapshot hash is unique to the restored build. Record the value produced on the current VM rather than reusing the value shown in another write-up. This stage exists because the experiment needs to work with the restored filesystem instead of an immutable authenticated snapshot that rejects the planned laboratory modifications. Cryptex SystemOS and AppOS Installation The initial restored system can panic in launchd because libSystem.B.dylib is unavailable. In the documented failure, the required shared-cache content was expected through the Cryptex layout but had not been restored correctly. The recovery procedure therefore prepares both Cryptex families: - decrypt the SystemOS AEA image using metadata obtained from the firmware; - obtain the AppOS disk image; - mount both images on the host; - create the System/Cryptexes/OS and System/Cryptexes/App directories in the guest root; - copy the mounted Cryptex contents into their respective locations; - reconstruct the expected symlinks for dyld caches and DriverKit data. The relevant paths include: ```text /System/Cryptexes/OS /System/Cryptexes/App /System/Library/Caches/com.apple.dyld /System/DriverKit/System/Library/dyld ``` Preserve file modes, ownership and symbolic links. A visually complete directory copied with incorrect metadata can still fail during launchd or dyld initialization. SEP and Gigalocker Adjustment The research environment uses virtual SEP storage, but seputil may expect a Gigalocker filename that does not match the restored VM state. The published experiment preserves the original utility, modifies a laboratory copy for the expected filename, signs the result and installs it into the guest. The corresponding file on the SEP-related volume is renamed to match that controlled value. This step is highly build-specific. Verify the observed seputil error and actual volume contents before making any change. Installing the Bootstrap The prepared environment installs iosbinpack64 into the root filesystem. This provides the command-line environment needed for later services and maintenance. The bootstrap supports tools such as: - bash; - Dropbear SSH; - filesystem utilities; - signing and diagnostic helpers; - TrollVNC for graphical access. Do not assume that a bootstrap built for another architecture or iOS generation is compatible. Validate Mach-O architecture, entitlements and library dependencies before adding it to the image. launchd Integration For persistent shell and screen access, the write-up installs LaunchDaemon definitions for bash, Dropbear and TrollVNC. It also updates the launchd configuration so these services are recognized during a normal boot. The research process preserves backups of launchd_cache_loader and launchd.plist before editing them. Modified binaries are re-signed and file permissions are restored after transfer. The intended permissions are important: - executable service binaries must remain executable; - LaunchDaemon property lists normally use mode 0644; - ownership must match the system environment; - malformed property lists must be rejected before reboot. Validate every plist locally before sending it to the guest. One invalid launchd entry can turn a graphics problem into an unrelated early userspace failure. First-Boot Validation Matrix The first normal boot should be evaluated stage by stage: - serial log continues beyond kernel initialization; - APFS root and data volumes mount; - launchd starts without missing-library panic; - Cryptex paths resolve; - SpringBoard or Setup starts; - Dropbear listens only through the intended tunnel; - TrollVNC produces a frame; - reboot preserves NVRAM and SEPStorage; - no unexpected host-facing ports are opened. A black setup screen followed by a respring indicates that boot completion and UI usability are separate milestones. Metal Enablement Method The guest DeviceTree can expose AppleParavirtGPU while Metal still returns no default device. That means hardware discovery alone is insufficient; the matching guest-side Metal support must also be present. The research compares a minimal Metal test program against the guest. Before the fix, MTLCreateSystemDefaultDevice returns nil. The investigation then identifies AppleParavirtGPUMetalIOGPUFamily.bundle in the PCC environment and installs the required bundle into the virtual iPhone through the SSH ramdisk. One compiler-plugin library was not present in the iPhone 16 dyld shared cache and required additional compatibility work based on the PCC version: ```text /System/Library/Extensions/AppleParavirtGPUMetalIOGPUFamily.bundle/ libAppleParavirtCompilerPluginIOGPUFamily.dylib ``` After the guest can create an Apple paravirtual Metal device, rerun the same test and record both the returned device name and kernel version. This provides a reproducible before-and-after result rather than relying on visual smoothness. Touch and Input On macOS Tahoe, the virtual-machine view can provide more of the required interaction directly. On macOS Sequoia, the published work reports that touch interaction required overriding mouse-event handling and translating host pointer events into the virtual touchscreen path. Reference implementation: Link available to registered users Touch, keyboard, VNC and the guest's home-button behaviour should be documented separately. A working VNC pointer does not prove that the native virtual touch device is functioning. Confirmed Host Configurations The original research reports successful operation on: - Apple M3 with 16 GB RAM running macOS Sequoia 15.7.4; - Apple M1 Pro with 32 GB RAM running macOS Tahoe 26.3. The project targets Apple silicon and expects support for the PCC virtual research environment. Intel Macs, Windows and Linux are outside the documented compatibility scope. Required Experimental Records For a scientific reproduction, publish or preserve: - Mac model and memory; - exact macOS build; - Xcode and Swift versions; - source repository commit hashes; - hashes of cloudOS and iOS inputs; - hashes of every patched artifact; - BuildManifest and Restore.plist versions; - virtual ECID and serial configuration; - complete serial logs for each boot; - idevicerestore output; - ramdisk preparation log; - before-and-after MetalTest output; - known deviations from the reference environment. Without these records, the result is a demonstration rather than a reproducible experiment. Boot and Restore Process The virtual device must pass through several stages before reaching the user interface. Researchers use serial output and VM logs to identify failures in the boot chain, storage configuration, SEP initialization and system-volume mounting. Link available to registered users This screenshot captures a restore or early-boot attempt. The virtual iPhone window displays an Apple logo while detailed kernel and SEP-related diagnostics appear in the terminal. Verbose output is essential because an apparently frozen Apple logo can represent many different failures: - incompatible firmware components; - incorrect virtual hardware identity; - SEP initialization errors; - invalid restore manifests; - system-volume verification failures; - missing trust information; - graphics initialization problems. Why an SSH Ramdisk Is Useful When the normal system cannot finish booting, an SSH-enabled ramdisk provides a controlled environment for examining disks and repairing the prepared filesystem. Researchers can use it to inspect mount points, transfer required files, review logs and correct configuration problems before attempting another normal boot. This is a recovery and research technique, not a substitute for understanding the failed boot stage. Blindly replacing files can make the environment harder to diagnose. First Successful Boot Attempts After the firmware and virtual storage are prepared, the device can progress from restore mode toward a normal system boot. Link available to registered users The first successful stages may still produce extensive filesystem and initialization output. A visible Apple logo confirms that graphics output is working, but it does not guarantee that SpringBoard or the full user environment will load. At this stage, researchers typically validate: - root filesystem mounting; - launch services; - SSH availability; - VNC availability; - graphics initialization; - system daemons; - touch or pointer input; - persistence across reboot. VNC and SSH Access The vphone-aio launcher creates local forwarding for graphical and command-line access. VNC address: ```text vnc://127.0.0.1:5901 ``` SSH command: ```bash ssh -p 22222 root@127.0.0.1 ``` Keep these services bound to localhost. Exposing a jailbroken research environment or root SSH service to an untrusted network creates an unnecessary security risk. Metal Acceleration One of the most interesting parts of the research is experimental Metal support. A virtual phone that only produces a basic framebuffer is useful for boot research, but accelerated graphics make the environment substantially more responsive. The original work investigated graphics-device configuration, display dimensions and the relationship between the guest's graphics stack and Apple's host virtualization framework. Metal support remains closely tied to macOS, framework and firmware compatibility. A configuration that works on one machine or release may not behave identically elsewhere. The Running Virtual iPhone Link available to registered users The completed environment can reach an iPhone-style setup screen inside the macOS virtualization window. This demonstrates that the experiment progressed far beyond a static boot logo. However, the result should not be confused with a physical iPhone. Hardware-backed functions, cellular connectivity, cameras, sensors, secure elements, power behaviour and other device-specific services may be missing or simulated. Using the vphone-aio Launcher For readers interested in running the prepared environment rather than rebuilding every firmware component, vphone-aio automates the package reconstruction and startup process. After obtaining the repository and reviewing its source, the launcher is started with: ```bash chmod +x vphone-aio.sh ./vphone-aio.sh ``` On the first run, the script checks dependencies, downloads missing archive segments, reconstructs the compressed package, extracts vphone-cli, starts local forwarding and launches the VM. Press Ctrl+C in the launcher terminal to stop the boot process and forwarding services cleanly. Verifying the Download The vphone-aio repository publishes SHA-256 values for its split archive files. Verify every segment before extraction: ```bash shasum -a 256 vphone-cli.tar.zst.part_a ``` Compare the results with the current README in the official repository. A checksum mismatch can indicate an incomplete or modified download. Known Limitations Expect limitations such as: - dependence on specific macOS and firmware versions; - large storage requirements; - long download and extraction times; - reduced host security during setup; - incomplete hardware emulation; - unstable private APIs; - boot failures after system updates; - limited documentation for unusual errors; - no official support from Apple. This project is suitable for experienced developers and security researchers. It is not a beginner-friendly iPhone emulator. Safe Research Practices - Use a dedicated Mac. - Keep complete offline backups. - Verify downloaded archive checksums. - Review scripts before execution. - Do not enter personal Apple credentials. - Keep SSH and VNC bound to localhost. - Do not store sensitive data inside the guest. - Record macOS and firmware versions. - Restore SIP and AMFI protections after testing. - Treat the environment as untrusted. Conclusion The VPHONE600AP and super-tart research demonstrates that Apple's PCC-related virtual-phone components can be combined with modified virtualization tooling and custom firmware to produce a functional virtual iPhone environment on macOS. The achievement is technically impressive, but the process remains experimental, version-dependent and security-sensitive. Readers who only want to explore the prepared environment should begin with vphone-aio, while those studying the architecture should read the original super-tart write-up and its referenced projects. Original write-up: Link available to registered users vphone-aio launcher: Link available to registered users vphone-cli: Link available to registered users
Software