How to make work DvtSecureSocketProxyService with iOS > 17?

[fjanisze]

Let's say I've this simple function:

def is_app_running(device,rsd,name,bundle_identifier):
    if rsd is None:
        service_provider = create_using_usbmux(device.serial)
    else:
        service_provider = rsd
    with DvtSecureSocketProxyService(lockdown=service_provider) as dvt:
        device_info = DeviceInfo(dvt)
        for process in device_info.proclist():
            current_name = process.get('name')
            current_bundle_identifier = process.get('bundleIdentifier', '')
            if (bundle_identifier is not None and bundle_identifier in current_bundle_identifier) or \
                    (name is not None and name in current_name):
                return process['pid']
    return 0

That i can use to query if an app is running on the connected iOS device, the function works fine when rsd is None (older iOS).

For iOS >= 17 create_using_usbmux does not work fine as service provider and i get the error pymobiledevice3.exceptions.InvalidServiceError: InvalidService from DvtSecureSocketProxyService so I assumed I need to create the tunnel and obtain the rsd and use it as lockdown parameter, but it does not work either and i get the error pymobiledevice3.exceptions.InvalidServiceError: No such service: com.apple.instruments.dtservicehub again from DvtSecureSocketProxyService

So my question would be: What do i miss here to make this function work properly with devices with iOS >= 17?

[doronz88]

Either the device is not in developer-mode, or you are still providing a non-tunneled client.
In general, starting at iOS 17, Apple moved all the developer-related service to be accessible only via the trusted tunnel

[fjanisze]

Thanks, indeed it seems that the tunnel is not created correctly. I've it as an async task which I thought is working fine, but once i verified the logs from core_device_tunnel_service.py I saw the procedure get's stuck here:

375         self.logger.debug(f'Connecting to {host}:{port}')
376         async with aioquic_connect(
377                 host,
378                 port,
379                 configuration=configuration,
380                 create_protocol=RemotePairingQuicTunnel,
381         ) as client:<
382             self.logger.debug('quic connected')

It never prints quic connect after Connecting to..... I wonder what might be the issue though, the CLI command works fine and i can create the tunnel "manually", but not within my script.

asyncio is raising asyncio.CancelledError and thus failing the tunnel creation, not sure why..

[doronz88]

I don't know what's the reason for that, but maybe you could try the tcp tunnel instead (not working on all setups)

[fjanisze]

Alright, I fixed the issue with my tunnel and now I can see the quic connected print and start_quic_tunnel calls:

390                 yield TunnelResult(
391                     client.tun.name, handshake_response['serverAddress'], handshake_response['serverRSDPort'],
392                     TunnelProtocol.QUIC, client)

Once that my script gets executed again, and I attempt to call the function I mentioned originally is_app_running, where DvtSecureSocketProxyService raises No such service: com.apple.instruments.dtservicehub which is immediately followed by the execution of (in start_quic_tunnel):

393             finally:
394                 await client.stop_tunnel()

So it seems to me this time the tunnel must be ok, but DvtSecureSocketProxyService still isn't happy. I have the slight suspect that for some reason i cannot create the tunnel and then do stuff with DvtSecureSocketProxyService in the same python script, but not sure..

[doronz88]

If you're suddenly getting errors that no such service exists, it very much sounds like some other code is unmounting the ddi while you are using it. Maybe another instance of an opened xcode for some reason?

[fjanisze]

Is it possible that this function is causing the unmount of the ddi?:

 41 def get_device_list() -> List[RemoteServiceDiscoveryService]:<
 42     result = []<
 43     with stop_remoted():<
 44         for address in get_remoted_addresses():<
 45             print(address)<
 46             rsd = RemoteServiceDiscoveryService((address, RSD_PORT))<
 47             try:<
 48                 rsd.connect()<
 49             except ConnectionRefusedError:<
 50                 continue<
 51             result.append(rsd)<
 52     return result<

In particular stop_remoted? Once i create the tunnel i call this function to get the rsd to the device (i found this function in cli/remote.py). I've attempted to remote the stop_remoted call for testing purposes, but if I do that then i get a bunch of new errors: pymobiledevice3.exceptions.StreamClosedError: Got RstStreamFrame(stream_id=1, flags=[]): error_code=5 so that is not probably the right approach.

[doronz88]

Not possible.
But every handshake must be made with remoted stopped or there can be a race

[fjanisze]

I'm running a bit out of ideas, here's a minimum script that reproduces the issue on iOS >= 17*, before running it execute in a separate shell the command sudo python3 -m pymobiledevice3 remote start-tunnel to create manually the tunnel, do you see what could be wrong?:

def is_app_running(device,rsd,name,bundle_identifier):
    if rsd is None:
        service_provider = create_using_usbmux(device.serial)
    else:
        service_provider = rsd
    with DvtSecureSocketProxyService(lockdown=service_provider) as dvt:
        device_info = DeviceInfo(dvt)
        for process in device_info.proclist():
            current_name = process.get('name')
            current_bundle_identifier = process.get('bundleIdentifier', '')
            if (bundle_identifier is not None and bundle_identifier in current_bundle_identifier) or \
                    (name is not None and name in current_name):
                return process['pid']
    return 0

def kill_app(device,pid):
    service_provider = create_using_usbmux(device.serial)
    with DvtSecureSocketProxyService(lockdown=service_provider) as dvt:
        ProcessControl(dvt).kill(pid)

def get_device_list() -> List[RemoteServiceDiscoveryService]:
    result = []
    with stop_remoted():
        for address in get_remoted_addresses():
            rsd = RemoteServiceDiscoveryService((address, RSD_PORT))
            try:
                rsd.connect()
            except ConnectionRefusedError:
                print("Connection refused")
                continue
            result.append(rsd)
    resume_remoted_if_required()
    return result

def select_device(udid: str) -> RemoteServiceDiscoveryService:
    devices = get_device_list()
    if not devices:
        # no devices were found
        raise NoDeviceConnectedError()
    if len(devices) == 1:
        # only one device found
        rsd = devices[0]
    else:
        # several devices were found
        rsd = [device for device in devices if device.udid == udid]
        if len(rsd) > 0:
            rsd = rsd[0]
        else:
            raise NoDeviceConnectedError()
    return rsd

devices = list_devices()
if devices:
    if len(devices) == 0:
        print("No devices connected.")
        exit()
    device = devices[0]  # Select the first device
    rsd = select_device(device.serial)
    pid = is_app_running(device,rsd,"iDOS",None)
    if pid != 0:
        print("the app is running with pid {}".format(pid))
        kill_app(device,pid)
else:
    print("No device connected.")

The error reported is: pymobiledevice3.exceptions.InvalidServiceError: No such service: com.apple.instruments.dtservicehub during the creation of DvtSecureSocketProxyService.

The connected device has iOS 17.2.1 and CLI commands are working fine, so the tunnel should be ok, but the script does not want to work.

Thanks

edit

I've noticed that while creating the rsd connection in get_device_list, connect() first attempt the lockdown service com.apple.mobile.lockdown.remote.trusted but if fails, so it goes with com.apple.mobile.lockdown.remote.untrusted. CLI commands are locking down with the trusted service, perhaps this have an impact on the scenario?

[fjanisze]

I managed to make it work, the issue is that get_remoted_addresses() from remote/bonjour.py is not reporting an address I can actually use to connect with rsd. I suspect it's returning a valid address but not the one where the QUIC tunnel is enabled, if i put manually the address i get from the start-tunnel command then all works.

The problem here is how can i get programmatically the correct address if get_remoted_addresses seems to not work properly, I cannot create RemoteServiceDiscoveryService that i need to create the tunnel without the address

edit

I can create the tunnel within the script and now was trying to get the rsd within the same script, this time using the proper address (not the one obtained by get_remote_addresses()):

 91         async with start_tunnel(service_provider, secrets=secrets, max_idle_timeout=max_idle_timeout,<
 92                                 protocol=protocol) as tunnel_result:<
 93             print("Tunnel to : {}".format(tunnel_result.address))<
 94             rsd = RemoteServiceDiscoveryService((tunnel_result.address, tunnel_result.port))<
 95             with stop_remoted():<
 96                 try:<
 97                     rsd.connect()<
 98                     print("RSD connection to {} OK".format(address))<
 99                 except ConnectionRefusedError:<
100                     print("Connection refused")<

Now the call to rsd.connect() is stuck and never exit, isn't clear why..

[doronz88]

I think you don't understand the entire workflow.

• You first need to establish an untrusted tunnel - that is what get_remote_addresses is for.
• Then you can establish a trusted tunnel using this parameter. This can be used to access trusted services

[doronz88]

I believe you haven't read this:
https://github.com/doronz88/pymobiledevice3/blob/master/misc/RemoteXPC.md

[fjanisze]

I managed to get the thing working, the trick is to start the tunnel in a separate thread (with concurrent.futures not with the asyncio stuff) where the connection does not get stuck, and then the parent thread can operate on the tunneled connection and all works.