Is your feature request related to a problem? Please describe.
On iOS 17+, developer commands require a valid DDI mounted and a tunnel connection to be available.
To create utun tunnels privileged permissions are required.
This creates friction in using the library, as the use has to manually setup the tunnel first.
Describe the solution you'd like
Instead of creating a utun device, we can have the tunnel interface in-memory.
Projects like lwIP and smoltcp offer the ability to handle virtual interfaces directly in userspace, without having to register them in the kernel.
So, when pymobiledevice3 tries to connect to a developer service ( or when it detects an iOS 17+ device during setup ), it can create a tunnel, attach it to a virtual network interface and then use that interface to carry out all other commands that require a tunnel, entirely in userspace.
To the cli user this will feel transparent, as if the iOS 17+ device supports developer commands without needing a tunnel. For library users the same would happen, except that they will have the ability to manage the tunnel virtual interface to reuse it across different services that might need it.
Describe alternatives you've considered
Both lwIP and smoltcp are valid solutions, however smoltcp seems easier to implement as lwIP requires manual memory management.
Additional context
frida-core current implementation over tcp, using a lwIP fork under the hood.
For community
⬇️ Please click the 👍 reaction instead of leaving a +1 or 👍 comment
Is your feature request related to a problem? Please describe.
On iOS 17+, developer commands require a valid DDI mounted and a tunnel connection to be available.
To create
utuntunnels privileged permissions are required.This creates friction in using the library, as the use has to manually setup the tunnel first.
Describe the solution you'd like
Instead of creating a
utundevice, we can have the tunnel interface in-memory.Projects like lwIP and smoltcp offer the ability to handle virtual interfaces directly in userspace, without having to register them in the kernel.
So, when pymobiledevice3 tries to connect to a developer service ( or when it detects an iOS 17+ device during setup ), it can create a tunnel, attach it to a virtual network interface and then use that interface to carry out all other commands that require a tunnel, entirely in userspace.
To the cli user this will feel transparent, as if the iOS 17+ device supports developer commands without needing a tunnel. For library users the same would happen, except that they will have the ability to manage the tunnel virtual interface to reuse it across different services that might need it.
Describe alternatives you've considered
Both lwIP and smoltcp are valid solutions, however smoltcp seems easier to implement as lwIP requires manual memory management.
Additional context
frida-core current implementation over tcp, using a
lwIPfork under the hood.For community
⬇️ Please click the 👍 reaction instead of leaving a
+1or 👍 comment