khanhduy032Hello @zhuowei, it’s been 4 years since you tried running WindowServer on iPhone. Would you like to try it again, if I told you I made it work using iOS simulator’s Metal-over-XPC? (I don’t know whether Metal on simulator was a thing back then or not)
Zhuowei Zhang@khanhduy032 ... that's amazing
@zhuowei lol I’m kinda surprised it just worked seamlessly, I just had to patch out some simulator-unsupported checks in it and modify decompiled MTLSimDriverHost.xpc a bit. Here’s Boot Picker.app
To actually boot it up, you’ll also need to run launchservicesd. I had to convert it to a dylib by shifting PAGEZERO since dylibify or changing cpusubtype would cause bind opcode errors.
To actually boot it up, you’ll also need to run launchservicesd. I had to convert it to a dylib by shifting PAGEZERO since dylibify or changing cpusubtype would cause bind opcode errors.
@zhuowei yeah, it’s iPhone XS Max, iOS 16.5
@khanhduy032 Congratulations! This is really amazing work.
... really stupid question: can you do this on an unjailbroken device with JIT and NSExtension's XPC?
... really stupid question: can you do this on an unjailbroken device with JIT and NSExtension's XPC?
@zhuowei thank you! about using NSExtension, I think it might be possible but it would probably need a lot of work… (though I managed to use NSExtension to run multiples iOS apps and run SpringBoard sandboxes just by patching out aborts😅). I don’t know how loading dyld shared cache would be done there?
Also, I think running newer iOS simulators might also be possible if this actually works (would be so cool to have like jailbroken iOS simulator on iDevice)
Also, I think running newer iOS simulators might also be possible if this actually works (would be so cool to have like jailbroken iOS simulator on iDevice)
@khanhduy032 > I don’t know how loading dyld shared cache would be done there
DYLD_SHARED_REGION=private? it'd be very, very slow, but it should work.
And if you run out of RAM, attach debugger and set VM_LEDGER_FLAG_NO_FOOTPRINT (https://github.com/zhuowei/ryujinx-ios/blob/932ab6d418d080c33a4d389b1a53b50ac630f659/swiftpkgs/RyujinxKit/Sources/RyujinxKit/RyujinxKit.swift#L269)
DYLD_SHARED_REGION=private? it'd be very, very slow, but it should work.
And if you run out of RAM, attach debugger and set VM_LEDGER_FLAG_NO_FOOTPRINT (https://github.com/zhuowei/ryujinx-ios/blob/932ab6d418d080c33a4d389b1a53b50ac630f659/swiftpkgs/RyujinxKit/Sources/RyujinxKit/RyujinxKit.swift#L269)
@zhuowei oh thank you I didn’t know about that, very interesting way to bypass memory limit. In LiveContainer we used NSExtensionPointIdentifier=com.apple.ar.viewer which sets both ActiveHardMemoryLimit and InactiveHardMemoryLimit to -1
@khanhduy032 > I don’t know how loading dyld shared cache would be done there?
Last time I checked, codesign will re-sign an entire dyld cache if you asked it to.
You probably don't have to, though, since you can attach a debugger and JIT.
Last time I checked, codesign will re-sign an entire dyld cache if you asked it to.
You probably don't have to, though, since you can attach a debugger and JIT.
@zhuowei it would be more interesting to like make this JIT-less because of iOS 26 banning JIT (though there's still a loophole but also a flaw with it), but I think patching dyld to accept DYLD_SHARED_CACHE_DIR would still need JIT...
@khanhduy032 ... crap
... how do debuggers work on iOS 26, then; are they only allowed to do hardware breakpoints now or something?
... how do debuggers work on iOS 26, then; are they only allowed to do hardware breakpoints now or something?
@zhuowei the debugger is still allowed to modify, while app itself is not. Here is Apple's response
@khanhduy032 this says debugger can still map JIT memory: https://old.reddit.com/r/EmulationOniOS/comments/1lxbs6f/stephen_got_jit_working_in_ios_26/n2l2g01/
@khanhduy032 Let me know if there's anything I can do to help - this is well beyond my skill level to contribute, but if you need any help testing, I have an iOS 16.1 device and a iOS 14 device
@zhuowei sure, maybe I’ll try to finish my code and upload it today so you can check it out
@khanhduy032 I don't really have the time to look deeply into this in the next few weeks (I have a different project going on), but let me know if there's anything I can do.
@khanhduy032 > dylibify or changing cpusubtype would cause bind opcode errors.
I thought arm64e dyld can link an arm64e dylibwith cputype changed to arm64 binary perfectly fine?
I thought arm64e dyld can link an arm64e dylibwith cputype changed to arm64 binary perfectly fine?
@zhuowei it didn’t for me: `bad bind opcode 0xAF`; and using dylibify: `out of range bind ordinal 27748 (max 559)`. So I used another way that’s shifting `PAGEZERO` (check out https://github.com/LiveContainer/LiveContainer/blob/main/README.md?plain=1#L141-L144 )
Ozzelot 
@khanhduy032 @zhuowei As the era of hackintoshing dwindles, the era of hackiPhoning is upon us. :D
(I have basically zero understanding of this stuff, but feel free to explain the intricate implications this joke undoubtedly makes.)