Apple Ships Jailbreakable iPhones in a Box. This Repo Boots One on Your Mac.

One story owned Hacker News yesterday: vphone-cli — 404 points, 111 comments, #1 on the front page. "Boot a Virtual iPhone via Apple's Virtualization.framework." That headline undersells it. This isn't an emulator and it isn't the iOS Simulator. It boots real iOS 26.1 as a native VM on Apple Silicon, patches the boot chain, jailbreaks it, and installs Sileo and TrollStore on first boot. I cloned it, read the Swift VM core, the patchers, and all 6,236 lines of research docs. The uncomfortable finding: Apple gives you almost all of this. A guy named Lakr233 just assembled it into the thing Apple never wanted assembled.

The pieces Apple already hands out

The trick is that Apple's Private Cloud Compute security program publishes research IPSWs — bootable cloudOS builds for device classes with names like vresearch101ap and vphone600ap. They're real firmware: boot chain (LLB/iBSS/iBEC), security monitors (SPTM/TXM), SEP, kernelcache — some in RESEARCH_RELEASE builds with research kernels. Apple publishes these so security researchers can poke at PCC. Then there's the entitlement: com.apple.private.virtualization.security-research, one of seven keys in the repo's vphone.entitlements. With it, Virtualization.framework's private _VZMacHardwareModelDescriptor API returns a PV=3 hardware model — the iPhone class VM — instead of the Mac class. The source even documents the check: the validity byte requires (entitlements & 0x12) != 0.

So the raw ingredients were all in circulation. What was missing was the pipeline. That's the 400-point achievement.

What the pipeline actually does

graph TD
  A[vm new myphone] --> B[fw prepare: download + merge IPSWs]
  B --> C[fw patch: boot chain + kernel + TXM]
  C --> D[vm launch --dfu]
  D --> E[restore: SHSH + DFU restore]
  E --> F[first boot: JB finalize]
  F --> G[Sileo + apt + TrollStore]
  C --> H[variants: regular 52 / dev 66 / jb 127 / exp 141 patches]

The firmware is a hybrid of three sources: PCC vresearch101ap for the boot chain and security monitors, PCC vphone600ap for runtime components (DeviceTree, SEP, kernelcache — chosen because its DeviceTree sets MKB dt=1, allowing boot without a system keybag), and an iPhone17,3 IPSW for the OS image, trust caches, and filesystem. fw_manifest.py merges the manifests; the restore path fetches SHSH blobs and DFU-restores like a real device. Because the machine identity lives in a VZMacMachineIdentifier persisted to a config plist, the ECID stays stable across reboots — SHSH stays valid.

The patch tables are the real content

The research/ directory is the deepest part of the repo — surgical documentation of what gets NOP'd and why, with exact offsets and bytes:

• Boot chain (iBSS/iBEC/LLB): image4_validate_property_callback signature bypass, boot-args redirect to serial=3 -v debug=0x2014e, rootfs+panic bypasses. JB adds skip generate_nonce to keep apnonce stable for SHSH.
• Kernel: NOP the _apfs_vfsop_mount sealed-volume check, _authapfs_seal_is_broken, _bsd_init rootvp panic; force PE_i_can_has_debugger; AMFI _postValidation bypass; dyld policy check; stub five sandbox MACF hooks with mov x0,#0; ret. Every variant gets these — even "regular."
• TXM trust cache, JB-only: hash_cmp bypass, Selector24 validation skips, get-task-allow, a shellcode cave for Selector42 — fourteen instructions such as strb w0, [x20, #0x30] to set the manifest flag.
• Experimental variant (141 patches): makes Apple services believe the device is not a VM — renames the kern.hv_vmm_present sysctl OID, patches watchdogd to force the "am I a VM?" byte to 1 — while keeping VM-specific fast paths working.

And the discipline holds: validation docs are dated months back, with before/after bytes at absolute offsets (off=0x0248AB50: cbz x0 → nop). One doc even flags its own residual risk — the launchd jetsam patch picks a conditional branch by pattern scan, and without binary-level replay evidence, there's honest "residual false-hit risk." Most security repos don't self-audit in writing like this.

What I could and couldn't verify

I'm on Linux; vphone-cli needs macOS 15+ on Apple Silicon with SIP/AMFI relaxed. I couldn't boot it, and I was honest about that going in. What I could verify from source: the entitlements, the PV=3 hardware path, the hybrid manifest logic, the patch tables, and the preflight that refuses to run inside a nested VM (sysctl kern.hv_vmm_present — PV=3 can't nest). The repo itself is a 2026 artifact: it ships CLAUDE.md, AGENTS.md, and a skills/kernel-analysis-vphone600/ skillset, with workflow rules carved into the agent prompt. This is what agent-assisted systems research looks like now — and it's scarily competent.

Corellium went research-only and stopped selling to the general public. The HN thread's most telling comment: "I lost the ability to profile my apps the way I'd like." vphone-cli is the local, $0 answer.

Will Apple break this?

The top comment asked. The honest answer: probably, eventually. Every dependency is a knob Apple owns — the entitlement, the research IPSWs, the private VM API, the PV=3 hardware model's isSupported gate. macOS 15.1 could flip a bit and kill it. That's the real fragility here, and it's worth sitting with: Apple's security-research infrastructure is now the substrate for a mass-market jailbreak pipeline, and the only reason it isn't already a cat-and-mouse war is that it requires an Apple Silicon Mac and a disabled SIP.

One operational footnote from the docs, for whoever actually runs this: during iOS setup, don't pick Japan or the EU as region — the VM can't satisfy the extra regulatory checks. Pick the United States.

Bottom line

vphone-cli isn't a jailbreak tool in the traditional sense. It's an assembler: it takes the research-VM firmware and private entitlements Apple publishes for its own security team, and wires them into a bootable, patchable, package-manager-equipped iPhone VM that runs on your desk. Apple's reaction will tell you more about how it views its own security-research program than any policy page will. Until then: 127 patches, one command, real iOS.