search

tweaselORG / meta

(Currently) only used for the issue tracker.
2 stars 0 forks source link

Investigate problems with the iPhone on iOS 16 #12

Open baltpeter opened 1 year ago

baltpeter commented 1 year ago

The silver iPhone X (currently on iOS 16, not sure if that's related) is exhibiting quite a few problems that the black one (currently on iOS 15) doesn't have:

[^1]: Annoyance: on iOS 16, it's frida -U Preferences, on iOS 15, it's frida -U Settings. -.-

baltpeter commented 1 year ago

I have tried the Tools -> Do All (UICache, Remount r/w, Launch Daemons, Respring, Activate Tweaks) option in the palera1n app multiple times. That didn't help.

baltpeter commented 1 year ago

Reinstalling Frida doesn't help either.

Maybe relevant: After install, it fails to load the launch daemon. But Frida is still getting started and runs.

image

baltpeter commented 1 year ago

It's entirely possible that this could be fixed by a reboot. But reapplying the jailbreak annoyingly takes like half an hour. I'll switch to the black iPhone for now and look into this again in the future.

baltpeter commented 1 year ago

A reboot did not fix the problem. At least I learned that re-jailbreaking after a reboot only takes like two minutes.

zner0L commented 1 year ago

I cannot reproduce any of the problems you encountered on my iPhone X with iOS 16.3.1 and frida-server version 16.0.19. However, setting the proxy seems to be broken somehow. The process starts to hang on saveSettingsOperation.start() in the setProxy frida script.

zner0L commented 1 year ago

The problems with frida-server are apparently a bug in frida (https://github.com/frida/frida/issues/2375). It seems like removing LimitLoadToSessionType as suggested (https://github.com/frida/frida/issues/2375#issuecomment-1425714146) fixed it as a workaround. What do you say, should I implement this in https://github.com/tweaselORG/appstraction/issues/59?

baltpeter commented 1 year ago

The problems with frida-server are apparently a bug in frida (frida/frida#2375). It seems like removing LimitLoadToSessionType as suggested (frida/frida#2375 (comment)) fixed it as a workaround. What do you say, should I implement this in tweaselORG/appstraction#59?

I would like to understand what that option does before deciding. But I have had that problem as well, so a fix would be nice.

zner0L commented 1 year ago

Session types define the context in which a services runs. In the case of leaving this option out, the default is the Aqua context on macOS, which is the GUI context. I guess, the system context would be nicer, but considering the iPhone always has a GUI context and we cannot bind to the System context anyway this should be fine. We could also try to the the Background context. More info on session types in macOS: https://developer.apple.com/library/archive/technotes/tn2083/_index.html#//apple_ref/doc/uid/DTS10003794-CH1-SUBSUBSECTION5

I tried it out now and I didn’t encounter any problem with frida so far. But I guess, if we consider to start frida ourselves anyway (https://github.com/tweaselORG/appstraction/issues/73) this isn’t as necessary anymore.

baltpeter commented 1 year ago

I still don't really understand the implications of these contexts, but if the default works, that's fine I guess.

I would consider the fact that the startup script doesn't work an upstream bug that I would much rather have them fix. But if we do implement a workaround, changing the startup script seems nicer, since that also fixes the problem when not using our tools.

zner0L commented 1 year ago

Well, I would like to implement both, I guess. The latter would of course only work if the ssh capability is enabled.

zner0L commented 1 year ago

I implemented the workarounds in https://github.com/tweaselORG/appstraction/pull/74.

baltpeter commented 1 year ago

I am now on Frida 16.0.19. Somewhere along the line, the following problems seem to have been fixed:

Those were the major ones, I guess. Running the iOS example script now works.