Jailbreak’s hijacking of analyticsd breaks many system services

[badger200]

The Fugu14/unc0ver jailbreak evidently hijacks analyticsd, and renames the stock service to analyticsd.back, also editing /etc/passwd to make the analyticsd service use group _nanalytics instead of _analytics, which seems to be the root cause responsible for infamously breaking the Battery Usage settings history logs (BatteryLife/CurrentPowerLog.PLSQL, etc), as well as possibly the AirPlay speakers and CarPlay breakage(?).

Because these are persistent system modifications, this breaks analyticsd (and thus, services depending on it) even when “not jailbroken”.

iPad8,4 iPad Pro 11” 3rd gen A12X
iOS 14.4
unc0ver 8.0.2

Place an "x" between the brackets if true:

• this is a bug others will be able to reproduce
• this issue is present with all tweaks uninstalled(except for default packages) or disabled
• [unknown] this issue is present after a rootfs restore
• this issue is present on the latest version of unc0ver

I suspect the developer @LinusHenze already knows this perfectly well but felt it should be formally documented, seeing how half the Issues here are people trying to get Battery Usage to work again.

[0chil]

Is there any way an end-user to deal with this issue?

[badger200]

Is there any way an end-user to deal with this issue?

Yes! @0chil Check out the incredible patch and manual steps posted 2 weeks ago by "SXX" on the Fugu14 cross post for this issue I made: LinusHenze/Fugu14#242 He posted an entire root cause analysis, absolutely brilliant work. Fugu14 made a typo when it hijacked analyticsd, something like a GID 263 should've been 264 and vice versa, but also file system permissions to /var/db/analytics.

Beware: the manual steps are not for the faint of heart, unless you're extremely confident of your Unix skills. One mistake and you could lose your jailbreak or even brick your device. I am going to attempt it soon.

Hopefully LinusHenze will accept the PR and it can be incorporated into Fugu14 and @pwn20wndstuff will be able to issue a long-awaited update to unc0ver...

[0chil]

Is there any way an end-user to deal with this issue?

Yes! @0chil Check out the incredible patch and manual steps posted 2 weeks ago by "SXX" on the Fugu14 cross post for this issue I made: LinusHenze/Fugu14#242 He posted an entire root cause analysis, absolutely brilliant work. Fugu14 made a typo when it hijacked analyticsd, something like a GID 263 should've been 264 and vice versa, but also file system permissions to /var/db/analytics.

Beware: the manual steps are not for the faint of heart, unless you're extremely confident of your Unix skills. One mistake and you could lose your jailbreak or even brick your device. I am going to attempt it soon.

Hopefully LinusHenze will accept the PR and it can be incorporated into Fugu14 and @pwn20wndstuff will be able to issue a long-awaited update to unc0ver...

@badger200 what a great analysis on analyticsd which is very clear. 😄
Thanks for the fast comment. It helped a lot.

[badger200]

@0chil You're very welcome; please post your results if you attempt. I think I am going to try tonight, I finally understand the steps. I never used chflags before but now I get it. I think I have a toybox, binbag, or busybox single binary that includes chflags.

or even brick your device

Bootloop at most, unless you trash syscfg or break SSV seal on iOS 15+ (neither of which are the case here), but yeah, you'd be forced to restore to a signed version and could lose your data if you didn't have a backup.