doronz88/pymobiledevice3

What happened? cloudOS is a stripped down iOS system that grants advanced research capabilities. A "new" security mitigation, described in the context of cloudOS, is the Restricted Execution Mode (REM) (docs). While it is described only for cloudOS, also iOS is capable of these functionalities. We find that when restoring cloudOS with pymobiledevice (or idevicerestore), REM is not being activated. We further find that other functionalities, such as mounting Cryptexes fails. While we assume that this might be some initial configuration of TXM or the environment, we have not found the difference to the MobileDevice restore process. How can we reproduce this? Let's follow [the Apple docs](https://security.apple.com/documentation/private-cloud-compute/vresetup) and [the blog post by matteyeux](https://matteyeux.com/posts/2024-11-01-pcc-2/) on how to create a virtual research environment to restore cloudOS (Apple Silicon-only). 1. `csrutil allow-research-guests enable` 2. `pccvre release d

What happened? pymobiledevice3 developer dvt sysmon system fails when xcuitest is already running on the same device. Two different failure modes: iOS ≤ 16: The command exits with code 0 and writes nothing to stdout. Only stderr shows "Connection was terminated abruptly". Since exit code is 0, there's no way to programmatically detect the failure. iOS 17+: The command gets InvalidServiceError, falls back to tunneld, but the fallback works for some devices and fails for others — on the same host, same tunneld process. Failing devices get IncompleteReadError: 0 bytes read on a total of 9 expected bytes during XPC handshake. rsd-info works fine for all devices. Expected: sysmon should either coexist with xcuitest, or fail with a non-zero exit code. On iOS 17+, tunneld fallback should work consistently for all connected devices. How can we reproduce this? # 1. Start xcuitest on device pymobiledevice3 developer dvt xcuitest com.facebook.WebDriverAgentRunner.xctrunner --udid <UDID> &

I think that gtk is the best framework to create such front end for this tool

Is your feature request related to a problem? Please describe. When tunneld runs on a different network stack then the client ( e.g. different docker network or different host altogether ), the returned RSD endpoints are useless as the client doesn't have access to such interfaces. Describe the solution you'd like Add a /connect endpoint ( or any other name ) to enable the client to connect to the tunnel interface through tunneld HTTP API, removing the need to share the same network stack. Describe alternatives you've considered To achieve this, it would be possible to use MASQUE over HTTP/3, which enable the client to use the tunnel interface over HTTP. Alternatively, it would be possible to use the SOCKS5 proxy protocol. I haven't explored all the options nor their feasibility in detail tho. Additional context If #1647 is taken care of, tunneld itself looses its utility for pymobiledevice library users, making this request irrelevant for such cases. However, for other users that migh

Programs often leave their files in a hidden folder in the user's home directory. The XDG Base Directory Specification details how this should be handled. The gist of it is that program files should be stored in specific locations based on how the program uses them, rather than storing all data in one place. Currently, pymobiledevice3 stores all files in ~/.pymobiledevice3. This directory, for me, only contains one file, so I can't speak to how files should be organized without exploring beyond the needs of my use case. Ideally, config files would go in $XDG_CONFIG_HOME/pymobiledevice3, temporary/cached files in $XDG_CACHE_HOME/pymobiledevice3, and other files in $XDG_DATA_HOME/pymobiledevice3. However, it is somewhat common for programs just to migrate all of their files from ~/.program to $XDG_DATA_HOME/program, and, though this does not technically comply with the spec, it is, for neurotic people like me, preferable to having another dotfile in the home directory. To remain backward