Fix a race condition in GUI when printing and fix malfunctioning analyticsd daemon.

[SongXiaoXi]

Fix a race condition in GUI when printing.

And it seems the exploitation and post-exploitation work on my iPhone 12 iOS 14.2.1 without any modification.

Fix malfunctioning analyticsd daemon

While the patch in Fugu14 preserved the user id and $HOME by changing the name of the user _analyticsd to _nanalyticsd, it seems that some other daemon changes the owner of /private/var/db/analyticsd and its subdirectories to ·_analyticsd·, whose uid has changed to 264. This will cause the _analyticsd.back with uid 263 to not be able to read /private/var/db/analyticsd at all, with error: Home directory is not setup. Waiting to see if it gets repaired....
This fix is based on the following facts:

• dyld enables independent closure loading by checking the env $HOME is a subdirectory in /private/var/mobile/Containers/Data/.
• launchd sets the daemons' $HOME env via getpwname_r.
• analyticsd get its own working path via getuid and getpwuid.
• An unknown daemon will set the owner of /private/var/db/analyticsd to the user name _analyticsd.

So if the passwd and master.passwd have the following contents, things can be easily fixed.

passwd (master.passwd is similar)
_nanalyticsd:*:263:263:Analytics Daemon:/var/db/analyticsd:/usr/bin/false
_analyticsd:*:263:263:Haxx Daemon:/private/var/mobile/Containers/Data/Fugu14Untether:/usr/bin/false

And then, after the system is powered on:

• launchd launches /System/Library/LaunchDaemon/com.apple.analyticsd.plist with username _analyticsd and set $HOME to /private/var/mobile/Containers/Data/Fugu14Untether based on the username.
• Then the dyld will load the closure exploitation and the system will be jailbroken.
• The unknown daemon will set the user ID of /private/var/db/analyticsd to 263, based on the username _analyticsd.
• Then the analyticsd.back with the user name _nanalyticsd is launched, which will use the uid 263. Although there are two user with the same uid 263, it will only pick the first one by getpwuid. So it will use /private/var/db/analyticsd with the correct owner, uid 263

Then the battery detail in Settings works properly.

If you have jailbroken by Fugu14, you can try the manual steps below, or remove origin Fugu14 jailbreak modification then and use this PR to jailbreak. Restoring rootfs is a easy way, but loses all tweaks. Or manually undo all modification according "Jailbreak" section in Fugu14 writeup.

[Liam0205]

@badger200 well, this might need to be check later. I cannot get into Jailbreak state after executing the script.

I need to fix this first and then give the script another examine.

[badger200]

@Liam0205 Ooo that doesn't sound good. Remember Fugu14 starts a simple iDownload shell via telnet port 1337 that runs at all times even when not jailbroken. I have used that in the past to rescue my jailbreak when I corrupted my dpkg which prevented Unc0ver from succeeding. I use Termius from App Store to connect to 127.0.0.1 port 1337 telnet (NOT SSH). It's extremely crude and you can't even use backspace to fix errors but it's better than nothing. If you can't connect to it then you might've really broken your JB and need to consider restore rootfs from Fugu14 installer. Be advised the iDownload shell only works from localhost/127.0.0.1, it will fail if you try connecting from another machine. Hence my recommendation of Termius.

[UInt2048]

@badger200 Thank you. I can confirm the version 0.0.0-5+debug does not work:

Note the su is necessary as I just receive “lsof: PID ___ information error: Operation not permitted” for a long list of PID including the one I’m looking for otherwise.

[UInt2048]

I also couldn’t help but notice there’s no firmware restriction in the control file to stop people not on Fugu14 from installing this tweak. That might be worth looking into for future builds.

[junior2377]

I can also confirm that this isn’t working. Installed and no change in battery reporting

[Liam0205]

@Liam0205 Ooo that doesn't sound good. Remember Fugu14 starts a simple iDownload shell via telnet port 1337 that runs at all times even when not jailbroken. I have used that in the past to rescue my jailbreak when I corrupted my dpkg which prevented Unc0ver from succeeding. I use Termius from App Store to connect to 127.0.0.1 port 1337 telnet (NOT SSH). It's extremely crude and you can't even use backspace to fix errors but it's better than nothing. If you can't connect to it then you might've really broken your JB and need to consider restore rootfs from Fugu14 installer. Be advised the iDownload shell only works from localhost/127.0.0.1, it will fail if you try connecting from another machine. Hence my recommendation of Termius.

@badger200 Unfortunately, that information did not help me in the end. I tried telnetting to localhost:1337, but Termius says it can't connect to the target port. It looks like Fugu14 is completely broken.

But after restoring the RootFS, I was able to enter the jailbreak state again. Of course, the bad news is that all installed tweaks are gone, the good news is that I remember what they are and the preferences are preserved after re-installation.

Modifying passwd and master.passwd seems to break Fugu14, at least in my case (iPhone Xr, iOS 14.5.1, unc0ver 8.0.2). After fixing the jailbreak, I directly modified it once using Vim and confirmed that sudo su is normal, but after restarting, Fugu14 is not working properly again. c.c. @SongXiaoXi

At present, I am not quite sure why this is the case, but I have to go to work, so the exploration on this path may have to be postponed until the weekend. I will first try to bypass this issue using the previously injected SpringBoard method.

[Liam0205]

@junior2337 @UInt2048

I have received your feedback. As previously mentioned, due to the incorrect handling of the /etc/sudoers part, version 0.0.0-5debug in beta cannot be used properly on your devices. I will fix this issue later.

Additionally, seeing config.sqlite in lsof -p <pid> is not necessary in my case. In actual testing, the battery usage function is still normal even when it is not seen. I am not sure if it is related to my system version, but it has indeed fixed the issue. @badger200

[SongXiaoXi]

@Liam0205 If you have a Mac, Hackintosh or macOS in VM, I highly recommand you to use my fork of Fugu14, since you have already restored the rootfs. You just need to follow the installation steps in ios_install.py. The manual steps, the one-time script and your multiple-time script are unreliable because there are too many exceptions to consider. Not only are the files modified by users or tweaks, but also jailbreak itself is unstable. Kernel panics happen anytime. Processes spawned by the shell may be killed by jetsam or OOM. Fake-signed cmds may be killed with SIGKILL due to a few CoreTrust bypass failures. Even a bad battery may shutdown system unsafely. It is difficult for scripts to handle these exceptions, which is why I only provide manual steps which are not recommended. Although these are low-probability events, as the number of your users increases and the number of script executions increases, more and more people will encounter problems.

[Liam0205]

@Liam0205 If you have a Mac, Hackintosh or macOS in VM, I highly recommand you to use my fork of Fugu14, since you have already restored the rootfs. You just need to follow the installation steps in ios_install.py. The manual steps, the one-time script and your multiple-time script are unreliable because there are too many exceptions to consider. Not only are the files modified by users or tweaks, but also jailbreak itself is unstable. Kernel panics happen anytime. Processes spawned by the shell may be killed by jetsam or OOM. Fake-signed cmds may be killed with SIGKILL due to a few CoreTrust bypass failures. Even a bad battery may shutdown system unsafely. It is difficult for scripts to handle these exceptions, which is why I only provide manual steps which are not recommended. Although these are low-probability events, as the number of your users increases and the number of script executions increases, more and more people will encounter problems.

@SongXiaoXi You are right. Since it is a bug from Fugu14, the most correct way is to solve it within Fugu14 itself. Any additional methods will result in a series of instability.

But it must also be acknowledged that it is difficult for ordinary users to install your fork version of Fugu14. So seeking a convenient way to solve this problem for more ordinary users is still valuable. Although this solution may bring some instability, as long as we can reduce this instability to an acceptable range within our capabilities, it will still be beneficial overall.

I have already jailbroken through unc0ver. If I mess up the jailbreak again in the future, I will consider installing Fugu14 from your fork.

[junior2377]

Is the 0.0.1-5 update safe to try?

[Liam0205]

Is the 0.0.1-5 update safe to try?

@junior2377 Please wait patiently. I will leave a message here when it is available.

[Liam0205]

0.1.0-1+debug is now at public beta (https://liam.page/apt-beta), and is safe to try.

Basically, it does the following:

1. Restricts the iOS system version to between 14.0 -- 14.8
2. Depends on the package sudo, because the sudo command is required
3. Depends on the package file-cmds, because the chflags command is required
4. Checks during installation if the mobile user has permission to execute sudo without a password
5. If there is no permission, a file is written to /etc/sudoers.d/ to ensure the permission
6. Does some dirty work every time SpringBoard loads, by executing the following commands:

sudo chflags -v noschg,nouchg /var/mobile/Containers/Data/Fugu14Untether/Library/Caches/com.apple.dyld/*.closure
sudo chown 263:263 /var/mobile/Containers/Data/Fugu14Untether/Library/Caches/com.apple.dyld/*.closure
sudo chflags -v schg,uchg /var/mobile/Containers/Data/Fugu14Untether/Library/Caches/com.apple.dyld/*.closure
sudo chown -h 263:263 /var/mobile/Containers/Data/Fugu14Untether/Library
sudo chown -R 263:263 /var/db/analyticsd/
sudo launchctl stop com.apple.analyticsd
sleep 3
sudo launchctl start com.apple.analyticsd

What I've tested:

• [x] Battery usage graph (even after respring/ldrestart)
• [x] reboot and re-Jailbreak

---

Project GitHub: https://github.com/Liam0205/FixBatteryUsageFugu14/tree/13e8d62034eb127aeee95baa5984fe621c2dd239

[Manan2004]

Even this version still does not work. I even tried to install the deb with root

[Liam0205]

Even this version still does not work. I even tried to install the deb with root

Tested on two different device (one of it is a "clean" jb): in lsof -p you might still not see config.sqlite, but the usage chart should be normal. just wait and see.

[junior2377]

14.3 unc0ver. Installed 0.1.0-1 and no change on my battery graph 👎🏻

[junior2377]

[Manan2004]

Same man iphone 11 pro max 14.5. Could it be its because of system info tweak

[UInt2048]

I have installed version 0.1.0-1+debug. Without rebooting, I can already see it:

Obviously it will take a little bit for enough data to be collected to create a usage graph.

[UInt2048]

@Manan2004 Try checking it again. It doesn’t show up initially, because it hasn’t been collecting data. Thirty minutes later, you should see a graph.

[junior2377]

5 hours later. Still nothing

[Manan2004]

Same man nothing. How can i check if tweak is working

[Liam0205]

The following checks can be performed if necessary.

1. Login to the iOS device as the mobile user via SSH and execute the sudo -iu root command. The expected result is to enter without having to type the password for mobile or root. If a password is prompted, there is a problem.
2. Execute launchctl list | grep com.apple.analyticsd, reload the SpringBoard on the iOS device, wait for about 30 seconds and execute the same command again. Observe the number in the first column of the command output, which is the process ID of the service process. The expected result is that the process ID changes after restarting the SpringBoard. If it remains unchanged, there is a problem.

[Manan2004]

Yup u were right the first number changed after i reloaded the springboard - i ran command killall SpringBoard and killall -9 backboard Process id was different after each time

[Liam0205]

@Manan2004

This indicates that the tweak has been running as expected. On my i-Devices (and on other test devices I have access to), the code should resolve the issue once it runs correctly. If the issue persists after a waiting period, there may be other factors at play, which are beyond my capabilities.

[junior2377]

The following checks can be performed if necessary.

1. Login to the iOS device as the mobile user via SSH and execute the sudo -iu root command. The expected result is to enter without having to type the password for mobile or root. If a password is prompted, there is a problem.
2. Execute launchctl list | grep com.apple.analyticsd, reload the SpringBoard on the iOS device, wait for about 30 seconds and execute the same command again. Observe the number in the first column of the command output, which is the process ID of the service process. The expected result is that the process ID changes after restarting the SpringBoard. If it remains unchanged, there is a problem.

Ran commands. Logged in as root fine. Didn’t ask for password but the first number remained unchanged. Tried multiple times

[UInt2048]

Is that after updating to 0.1.0-1+debug? I’d also recommend perhaps rebooting the device. I’ve heard respringing can affect it.iPhoneから送信2023/02/17 17:46、junior2377 @.***>のメール:

The following checks can be performed if necessary.

Login to the iOS device as the mobile user via SSH and execute the sudo -iu root command. The expected result is to enter without having to type the password for mobile or root. If a password is prompted, there is a problem. Execute launchctl list | grep com.apple.analyticsd, reload the SpringBoard on the iOS device, wait for about 30 seconds and execute the same command again. Observe the number in the first column of the command output, which is the process ID of the service process. The expected result is that the process ID changes after restarting the SpringBoard. If it remains unchanged, there is a problem.

Ran commands. First number remained unchanged. Tried multiple times

—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you were mentioned.Message ID: @.***>

[junior2377]

Is that after updating to 0.1.0-1+debug? I’d also recommend perhaps rebooting the device. I’ve heard respringing can affect it.iPhoneから送信2023/02/17 17:46、junior2377 @.>のメール: The following checks can be performed if necessary. Login to the iOS device as the mobile user via SSH and execute the sudo -iu root command. The expected result is to enter without having to type the password for mobile or root. If a password is prompted, there is a problem. Execute launchctl list | grep com.apple.analyticsd, reload the SpringBoard on the iOS device, wait for about 30 seconds and execute the same command again. Observe the number in the first column of the command output, which is the process ID of the service process. The expected result is that the process ID changes after restarting the SpringBoard. If it remains unchanged, there is a problem. Ran commands. First number remained unchanged. Tried multiple times —Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you were mentioned.Message ID: @.>

Yes. That’s after updating and rebooting several times as well as respringing and LDrestart. Tried everything.

There are no other steps after installing from the repo correct?

[buGOman7]

IPhone XS max 14.4.2 Fugu 14 uncover работает

[Liam0205]

@junior2377 If you are able to execute sudo without entering a password but the PID of analyticsd does not change after reloading SpringBoard (the first column of the output result of launchctl list | grep com.apple.analyticsd), it means that there was an error in executing the shell commands or the tweak simply did not execute them.

Please SSH into the iOS device as the mobile user and execute the following code, recording the output result of each step.

sudo ls -l /var/mobile/Containers/Data/Fugu14Untether/Library/Caches/com.apple.dyld/*.closure
sudo chflags -v noschg,nouchg /var/mobile/Containers/Data/Fugu14Untether/Library/Caches/com.apple.dyld/*.closure
sudo chown 263:263 /var/mobile/Containers/Data/Fugu14Untether/Library/Caches/com.apple.dyld/*.closure
sudo chflags -v schg,uchg /var/mobile/Containers/Data/Fugu14Untether/Library/Caches/com.apple.dyld/*.closure
sudo ls -l /var/mobile/Containers/Data/Fugu14Untether/Library/Caches/com.apple.dyld/*.closure

sudo ls -l /var/mobile/Containers/Data/Fugu14Untether/
sudo chown -h 263:263 /var/mobile/Containers/Data/Fugu14Untether/Library
sudo ls -l /var/mobile/Containers/Data/Fugu14Untether/

sudo ls -l /var/db | grep analyticsd
sudo chown -R 263:263 /var/db/analyticsd/
sudo ls -l /var/db | grep analyticsd

sudo launchctl list | grep com.apple.analyticsd
sudo launchctl stop com.apple.analyticsd
sleep 3
sudo launchctl start com.apple.analyticsd
sudo launchctl list | grep com.apple.analyticsd

• The first code section tries to modify the owner and group of all files in /var/mobile/Containers/Data/Fugu14Untether/Library/Caches/com.apple.dyld/*.closure. The before and after ls -l is to confirm if the modification is successful. Similarly for the following sections.
• The second code section tries to modify the owner and group of the symbolic link itself of /var/mobile/Containers/Data/Fugu14Untether/Library.
• The third code section tries to modify the owner and group of /var/db/analyticsd and its subdirectories and files recursively.
• The fourth code section tries to restart the analyticsd service. The before and after launchctl list is to observe if the PID has changed.

Please note that the chflags in the first code section should be executed in pairs. Otherwise, after restarting the device, Fugu14 will not work properly. You will need to Restore RootFS and jailbreak again to enter the jailbreak state, and all installed plugins will be lost.

[junior2377]

@junior2377 If you are able to execute sudo without entering a password but the PID of analyticsd does not change after reloading SpringBoard (the first column of the output result of launchctl list | grep com.apple.analyticsd), it means that there was an error in executing the shell commands or the tweak simply did not execute them.

Please SSH into the iOS device as the mobile user and execute the following code, recording the output result of each step.

sudo ls -l /var/mobile/Containers/Data/Fugu14Untether/Library/Caches/com.apple.dyld/*.closure
sudo chflags -v noschg,nouchg /var/mobile/Containers/Data/Fugu14Untether/Library/Caches/com.apple.dyld/*.closure
sudo chown 263:263 /var/mobile/Containers/Data/Fugu14Untether/Library/Caches/com.apple.dyld/*.closure
sudo chflags -v schg,uchg /var/mobile/Containers/Data/Fugu14Untether/Library/Caches/com.apple.dyld/*.closure
sudo ls -l /var/mobile/Containers/Data/Fugu14Untether/Library/Caches/com.apple.dyld/*.closure

sudo ls -l /var/mobile/Containers/Data/Fugu14Untether/
sudo chown -h 263:263 /var/mobile/Containers/Data/Fugu14Untether/Library
sudo ls -l /var/mobile/Containers/Data/Fugu14Untether/

sudo ls -l /var/db | grep analyticsd
sudo chown -R 263:263 /var/db/analyticsd/
sudo ls -l /var/db | grep analyticsd

sudo launchctl list | grep com.apple.analyticsd
sudo launchctl stop com.apple.analyticsd
sleep 3
sudo launchctl start com.apple.analyticsd
sudo launchctl list | grep com.apple.analyticsd

• The first code section tries to modify the owner and group of all files in /var/mobile/Containers/Data/Fugu14Untether/Library/Caches/com.apple.dyld/*.closure. The before and after ls -l is to confirm if the modification is successful. Similarly for the following sections.
  • The second code section tries to modify the owner and group of the symbolic link itself of /var/mobile/Containers/Data/Fugu14Untether/Library.
  • The third code section tries to modify the owner and group of /var/db/analyticsd and its subdirectories and files recursively.
  • The fourth code section tries to restart the analyticsd service. The before and after launchctl list is to observe if the PID has changed.

Please note that the chflags in the first code section should be executed in pairs. Otherwise, after restarting the device, Fugu14 will not work properly. You will need to Restore RootFS and jailbreak again to enter the jailbreak state, and all installed plugins will be lost.

Way too in depth for me to attempt.

[silentcloud]

Thanks @Liam0205 , the tweak resolved my battery usage problem. 12promax unc0ver 8.0.2, 14.4.2

[cdustevich1]

After installing this fork multiple times I still can't seem to get analyticsd working. Running the command "launchctl list | grep com.apple.analyticsd" it gives the output "- -11 com.apple.analyticsd" and never has a number in the first column. iPhone 12 Pro Max 14.5.1. Any ideas? Neither this fork or the tweak has worked. Have done a rootfs restore multiple times...

[SongXiaoXi]

@cdustevich1 Have you ever noticed whether the battery details in settings work properly after restoring rootFS before installing Fugu14? If not, it's possible that some other corruption may exist in your file system. If you still experience issues with the battery details, you can grab some logs of the process analyticsd.back from Console.app on your Mac to see what is causing the problem.

[cdustevich1]

I restored rootfs and battery usage is appearing in settings and normally recording. I can try reinstalling the jailbreak but I have done that to no avail this far…

[badger200]

@SongXiaoXi In my research of the 3D game panics, I saw a kernel panic that suggested this occurs with the Apple Neural Engine, I saw a bunch of "ANExxxxxx" calls in the panic trace. I can't be certain though.

I desperately wish there was a way to temporarily disable the Neural Engine and test that. Apple tells developers there's no way to know if your code will execute on CPU, GPU, or Neural Engine processors, as it handles it automatically and uses its own judgment depending on various factors like how it performs, battery usage, how often the function is being called, etc. (Now I wonder if our crash might occur at a different rate plugged in vs on battery?)

So if there was a way to disable the ANE, theoretically everything should continue to function but just get executed on CPU or GPU.

I would be ecstatic if I had the option of disabling ANE and getting rock solid stability, I don't mind a performance trade off.

[SongXiaoXi]

@badger200 When I reviewed my crash logs from a previous time, I noticed that they all contained 'element modified after free' errors within the tasks or proc zone. This issue seems to occur frequently in low-quality web-based apps and may be related to different users' habits. Therefore, the panic caused by the Neural Engine you mentioned may be one of them, but I don't have any reverse engineering knowledge in this area.

By the way, based on my previous judgment, I conducted numerous tests using the modified Fugu14 and unc0ver/Taurine. For example, I used Fugu14 and the open-source parts of Taurine to construct an experimental jailbreak tool to test its effectiveness against crashes. There is still a small chance of crashing, as Taurine's jailbreakd is also not open source and may patch the kernel in a manner similar to substituted. I have no good way to modify it too. I still believe that the patches made by substituted/jailbreakd using kernel rw before each process starts greatly affect stability.

If I have a significant amount of free time, I plan to explore what Linus and opa334 did in Fugu15 and make one last attempt to build a jailbreak tool using Fugu14 and the fully open-source Fugu15 Max, possibly with my optimizations, similar to what sockH3lix achieved.

[Nonta72]

I tried this but analytics.back daemon won't run and therefore, no fix. I checked cocoatop and saw that it tries every time to fire up but disappears few seconds later. What am I missing?

[SongXiaoXi]

@Nonta72 There are likely some errors occurring with the analytics.back daemon, and it typically prints logs before exiting/crashing. If you have a Mac, you can retrieve the logs containing the keyword "analytics.back" through the Console app. If not, there is a tweak that allows you to view system logs on your device, but I couldn't recall its name even after spending a few minutes thinking about it. Please pay attention to any logs related to analytics.back or ReportCrash.

[cdustevich1]

I get these 5 errors repeating indefinitely. Brand new installation of your fork (after succession rootfs restore) iPhone 12 Pro Max 14.5.1

[Nonta72]

@Nonta72 There are likely some errors occurring with the analytics.back daemon, and it typically prints logs before exiting/crashing. If you have a Mac, you can retrieve the logs containing the keyword "analytics.back" through the Console app. If not, there is a tweak that allows you to view system logs on your device, but I couldn't recall its name even after spending a few minutes thinking about it. Please pay attention to any logs related to analytics.back or ReportCrash.

Hi, thank you for your reply!

I managed to retrieve logs and I have similar error messages just like the ones on the screenshot sent by @cdustevich1 Here's what mostly show up in logs (full file attached to this post) :

Apr 29 13:47:52 Nontas-iPhone-XS analyticsd.back[26214] <Notice>: [Configurer:Build] -- Building config Apr 29 13:47:52 Nontas-iPhone-XS analyticsd.back(libsystem_containermanager.dylib)[26214] <Notice>: container_system_group_path_for_identifier: success Apr 29 13:47:52 Nontas-iPhone-XS analyticsd.back(OSAnalytics)[26214] <Notice>: Using system group container: '/private/var/containers/Shared/SystemGroup/257C7AB7-940C-4876-AB65-09F3B0B8B801' Apr 29 13:47:52 Nontas-iPhone-XS analyticsd.back[26214] <Notice>: XPC Server com.apple.analyticsd.messagetracer: listening Apr 29 13:47:52 Nontas-iPhone-XS analyticsd.back(OSAnalytics)[26214] <Notice>: failed to create directory '/private/var/containers/Shared/SystemGroup/257C7AB7-940C-4876-AB65-09F3B0B8B801/Library/CoreAnalytics': Error Domain=NSCocoaErrorDomain Code=513 "You don\M-b\M^@\M^Yt have permission to save the file \M-b\M^@\M^\CoreAnalytics\M-b\M^@\M^] in the folder \M-b\M^@\M^\Library\M-b\M^@\M^]." UserInfo={NSFilePath=/private/var/containers/Shared/SystemGroup/257C7AB7-940C-4876-AB65-09F3B0B8B801/Library/CoreAnalytics, NSUnderlyingError=0x11bd07b70 {Error Domain=NSPOSIXErrorDomain Code=13 "Permission denied"}} Apr 29 13:47:52 Nontas-iPhone-XS kernel[0] <Notice>: analyticsd.back[26214] Corpse allowed 1 of 5 Apr 29 13:47:52 Nontas-iPhone-XS ReportCrash[26215] <Notice>: osa_update: Pid 26214 'analyticsd.back' CORPSE: Parsing KCData Apr 29 13:47:52 Nontas-iPhone-XS ReportCrash[26215] <Notice>: osa_update: Pid 26214 'analyticsd.back' CORPSE: Extracting Apr 29 13:47:52 Nontas-iPhone-XS ReportCrash[26215] <Notice>: osa_update: Pid 26214 'analyticsd.back' CORPSE: Symbolicating Apr 29 13:47:52 Nontas-iPhone-XS ReportCrash[26215] <Notice>: osa_update: Pid 26214 'analyticsd.back' CORPSE: Symbolicating2 Apr 29 13:47:52 Nontas-iPhone-XS ReportCrash[26215] <Notice>: osa_update: Pid 26214 'analyticsd.back' CORPSE: Capture Complete Apr 29 13:47:52 Nontas-iPhone-XS ReportCrash[26215] <Notice>: Formulating fatal report for corpse[26214] analyticsd.back Apr 29 13:47:52 Nontas-iPhone-XS ReportCrash(CoreAnalytics)[26215] <Notice>: Sending event: com.apple.stability.crash {"exceptionCodes":"KERN_INVALID_ADDRESS at 0x0000000000000000","incidentID":"B06EDDE6-8A72-4141-B8A0-E1B6269A8BCC","logwritten":0,"process":"analyticsd.back","terminationReasonNamespace":"<NO_NS>"} Apr 29 13:48:02 Nontas-iPhone-XS analyticsd.back(substitute-loader.dylib)[26216] <Error>: ExtensionLoader <private>: Safemode parent directory <private> is blocked by sandbox. Apr 29 13:48:02 Nontas-iPhone-XS analyticsd.back(substitute-loader.dylib)[26216] <Error>: ExtensionLoader <private>: Not loading <private>: Invalid filter plist (Bundles is not an array or is empty) Apr 29 13:48:02 Nontas-iPhone-XS analyticsd.back[26216] <Notice>: ==== START ==== Apr 29 13:48:02 Nontas-iPhone-XS analyticsd.back(libMobileGestalt.dylib)[26216] <Notice>: Could not open /private/var/containers/Shared/SystemGroup/systemgroup.com.apple.mobilegestaltcache/Library/Caches/com.apple.MobileGestalt.plist: Permission denied Apr 29 13:48:02 Nontas-iPhone-XS analyticsd.back[26216] <Notice>: [CadenceManager] ==== FRESH INSTALL ==== Apr 29 13:48:02 Nontas-iPhone-XS analyticsd.back[26216] <Notice>: Scrub: [4] removing directory '<private>' Apr 29 13:48:02 Nontas-iPhone-XS analyticsd.back[26216] <Notice>: Scrub: [4] removing directory '<private>' Apr 29 13:48:02 Nontas-iPhone-XS analyticsd.back[26216] <Error>: [Config Store] DATABASE INITIALIZATION: clearing database Apr 29 13:48:02 Nontas-iPhone-XS analyticsd.back[26216] <Error>: [Config Store] DATABASE INITIALIZATION: creating tables Apr 29 13:48:02 Nontas-iPhone-XS analyticsd.back[26216] <Error>: [Config Store] DATABASE INITIALIZATION: complete Apr 29 13:48:02 Nontas-iPhone-XS analyticsd.back[26216] <Notice>: Running with LRU Cache Size: 131072 Apr 29 13:48:02 Nontas-iPhone-XS analyticsd.back[26216] <Notice>: Starting up kernel listener. Apr 29 13:48:02 Nontas-iPhone-XS analyticsd.back[26216] <Notice>: ==== starting mtShimServer Apr 29 13:48:02 Nontas-iPhone-XS analyticsd.back[26216] <Notice>: [Configurer] Bootstrap EMPTY config Apr 29 13:48:02 Nontas-iPhone-XS analyticsd.back[26216] <Notice>: ==== running main loop Apr 29 13:48:02 Nontas-iPhone-XS analyticsd.back[26216] <Error>: [Config Store] Deactivated all device configurations Apr 29 13:48:02 Nontas-iPhone-XS analyticsd.back[26216] <Notice>: Adding sink with privacy group 'Daily' Apr 29 13:48:02 Nontas-iPhone-XS analyticsd.back[26216] <Notice>: Adding sink with privacy group '90Day' Apr 29 13:48:02 Nontas-iPhone-XS analyticsd.back[26216] <Notice>: Adding sink with privacy group 'Never' Apr 29 13:48:02 Nontas-iPhone-XS analyticsd.back[26216] <Notice>: Adding sink with privacy group 'Daily' Apr 29 13:48:02 Nontas-iPhone-XS analyticsd.back[26216] <Notice>: Adding sink with privacy group '90Day' Apr 29 13:48:02 Nontas-iPhone-XS analyticsd.back[26216] <Notice>: Adding sink with privacy group 'Never' Apr 29 13:48:02 Nontas-iPhone-XS analyticsd.back[26216] <Notice>: ==== initialize best choice for config

PS : I'm also on iOS 14.5.1 on an iPhone XS. @cdustevich1 also has an iPhone 12 Pro Max with iOS 14.5.1. Maybe it has something to do with iOS 14.5.1?

29042023_135050_351_Nonta’s_iPhone_XS.log

[Nonta72]

I think I figured it out (somewhat!). As the logs state, there was no permission to write to /private/var/containers/Shared/SystemGroup/257C7AB7-940C-4876-AB65-09F3B0B8B801/Library/CoreAnalytics

I checked the permissions of each directory in /private/var/containers/Shared/SystemGroup/257C7AB7-940C-4876-AB65-09F3B0B8B801 and noticed that folder "Library" had the wrong ownership and permission values. In fact, the owner and group were both set to "nobody" with no permission of course. I changed the owner and usergroup to root:wheel and permissions to rwx-rwx-rwx. Now the daemon has fired up with PID 34883. I will observe the behavior and report back.

@cdustevich1 you should probably try this. Few commands in NewTerm2 or through an SSH tunnel should do the trick. You can use Filza if you don't want to use terminal.

[cdustevich1]

That worked, you are the man! The directory was different but I just looked through filza for the one with CoreAnalytics and set the permissions to 7777 for the Library folder and all subfolders and rebooted. Now if only there was a fix for Unc0ver breaking CarPlay…

[Nonta72]

That worked, you are the man! The directory was different but I just looked through filza for the one with CoreAnalytics and set the permissions to 7777 for the Library folder and all subfolders and rebooted. Now if only there was a fix for Unc0ver breaking CarPlay…

Glad it worked for you too! My battery graph has returned and so far no issue with it. I still face random reboots when I try to open some apps/games.

However, I never had any issue with CarPlay using this jailbreak. I use it with a Renault Clio 5. The only tweak I use that is related to CarPlay is CarBridge which allows me to access any app in CarPlay (not sure it can fix the problem you're facing, but it's worth mentioning).

[SongXiaoXi]

@Nonta72 I also noticed this permission denied error, which might be the reason why your analyticsd.back is not working. But strangely, on my device, the owner of files in this SystemGroup container is also nobody... @Nonta72 Is there any files in /private/var/containers/Shared/SystemGroup/257C7AB7-940C-4876-AB65-09F3B0B8B801/Library/CoreAnalytics? Mine doesn't even have the CoreAnalytics directory.

[Nonta72]

@Nonta72 I also noticed this permission denied error, which might be the reason why your analyticsd.back is not working. But strangely, on my device, the owner of files in this SystemGroup container is also nobody... @Nonta72 Is there any files in /private/var/containers/Shared/SystemGroup/257C7AB7-940C-4876-AB65-09F3B0B8B801/Library/CoreAnalytics? Mine doesn't even have the CoreAnalytics directory.

No, there's nothing inside the folder. There was nothing before I changed the permission and I just checked, still nothing. Here's the output :

Nontas-iPhone-XS:~ root# ls -l /private/var/containers/Shared/SystemGroup/257C7AB7-940C-4876-AB65-09F3B0B8B801/Library/CoreAnalytics total 0 Nontas-iPhone-XS:~ root# Are you on iOS 14.5.1 ? Because so far, it's the only thing @cdustevich1 and I have in common regarding this bug

[cdustevich1]

I also have nothing in the folder either. The permissions survived a rootfs (which surprised me but I guess makes sense) and it is definitely still working after a few hours. 14.5.1 does seem to be what’s in common between our devices so perhaps that’s the issue.

SXX ur looking at the systemgroup.com.apple.osanalytics folder correct? Because that’s the one that has CoreAnalytics in it for me.

[cdustevich1]

Glad it worked for you too! My battery graph has returned and so far no issue with it. I still face random reboots when I try to open some apps/games.

Can you list some of those apps? I can test on my devices and see if I have the same issues.

However, I never had any issue with CarPlay using this jailbreak. I use it with a Renault Clio 5.

Weirdly, CarPlay works on my CRV correctly every time but on my Mustang I have to unplug and replug 3 times for it to work. It's weird that it works differently on different vehicles, but I haven't been able to find a fix.

[Nonta72]

Can you list some of those apps? I can test on my devices and see if I have the same issues.

It mostly happens with a local shopping app (no use for you because you won't be able to download/use it outside my country). I also face the same issue with a crypto mining app called Pi Network. It's a hit or miss really. Sometimes it happens, sometimes it doesn't. I've given up on trying to fix that. I can use the website for shopping instead of the app. The crypto mining app bug doesn't bother me anymore really.

Weirdly, CarPlay works on my CRV correctly every time but on my Mustang I have to unplug and replug 3 times for it to work. It's weird that it works differently on different vehicles, but I haven't been able to find a fix.

Regarding the CarPlay, I'm not sure why it behaves like that with your vehicles. It's too bad because we're kinda stuck with 14.5.1 since iOS 16.3 and newer updates made futurerestore impossible because of the stup!d cryptex.

[Manan2004]

@cdustevich1 Here bro - https://apps.apple.com/us/app/golf-clash/id1089225191

This app will crash 2 mins into it

And it happens every time

[badger200]

@SongXiaoXi Check this out!!! Someone used the new "kfd" to make an unofficial fork of Taurine for 14.4! https://github.com/wh1te4ever/Taurine/releases/tag/v1.1.6-c

Unfortunately it only supports <A11 but still does this open any doors for a 14.4 fix that doesn't panic due to the task structure overwrite or whatever it is? And hopefully to avoid starting processes suspended like unc0ver v8 does? LMK