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.

[SongXiaoXi]

238

[badger200]

@SongXiaoXi Absolutely incredible work!! 👏🏼👏🏼👏🏼 Outstanding root cause analysis. Man you just did the exact thing I hoped for on a long shot when I documented this 2 weeks ago on #238. What's even crazier is by sheer coincidence you're the same guy who did the bulk of the work when I set out to bring the official D0m0 CocoaTop64 BigBoss release up to iOS 13+ support and iPad SplitView compatibility etc.! (The only 2 major GitHub jailbreak projects I've participated on)

I'm ecstatic and cannot wait to try this out. I don't have a Mac and do all my development with Clang and theos on device, is there a way I can compile this? Or can you post a binary? I have a swiftc and repl but I've never used them.

[SongXiaoXi]

@badger200 Oh yeah, nice to see you here.
You can make these unsafe modifications even without compiling any code. The key is about username and the owner of some paths. Since your device is iOS 14.4, the cicuta_virosa is not available. It may corrupt your Fugu14 untether or even bootloop and it's a hassle to fix them. Please be careful.
I tested these manual steps on two iOS 14.2.1 and iOS 14.5.1 devices a month ago, without taking any notes. So my memory may not be accurate. (Sorry for my procrastination.）You can refer to Linus's incredible Writeup to understand what the next steps are doing.

• Replace the lines containing _analyticsd and _nanalyticsd in /etc/passwd and /etc/master.passwd with the following: (the line containing _nanalyticsd must precede _analyticsd)

passwd:

_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

master.passwd:

_nanalyticsd:*:263:263::0:0:Analytics Daemon:/var/db/analyticsd:/usr/bin/false
_analyticsd:*:263:263::0:0:Haxx Daemon:/private/var/mobile/Containers/Data/Fugu14Untether:/usr/bin/false

• You can check the file format is correct by some user switch commands sudo su in the terminal.
• Change the owner all subdirectory of /private/var/Fugu14UntetherDYLD/Caches/, /private/var/mobile/Containers/Data/Fugu14Untether and /private/var/db/analyticsd to user id and group id 263.
• Terminate the analyticsd.back with CocoaTop64. You can check in the section 'Open files' in CocoaTop64 whether this daemon can open files in /var/db/analyticsd/. After this, the analyticsd daemon should work properly.
• Make sure processes with user id 263 have permission to read analyticsd.closure and stage2.closure in /private/var/Fugu14UntetherDYLD/Caches/com.apple.dyld/. Both of files are protected by chflag. If not, first use chflags to remove noschg and nouchg flag on these files. Remember the flag must be changed to noschg and nouchg back. Otherwise, Fugu14 will not work after reboot!
• If you are confident that your changes are correct, reboot to check whether Fugu14 can work.

Good luck enjoying analyticsd!

[nildeveloper]

老哥 要不要简单出个修改脚本先

[dlevi309]

Have you been regularly rebooting to ensure that this all applies indefinitely? And great work

[user-wyc]

老哥方便做个脚本给普通用户使用嘛感激不尽

[dlevi309]

I think you should fully test out something like this before submitting a PR, I’m not doubting the logic, but the implementation seems to be broken atm.

[SongXiaoXi]

@dlevi309 Can you point out what implementation is wrong? I have it running on iPhone 12 iOS 14.2.1 and iOS 14.5.1. And this fix doesn't rely on struct offsets to be patched, so I don't think it's necessary to test all devices between these two system versions (of course, I don't own all of them).
Of course, this code does not guarantee compatibility, and fugu14 needs to be completely removed first.

[dlevi309]

@SongXiaoXi Hi, and I was getting a permissions issue error when the jailbreak would try drop the analyticsd plist onto the device, but I guess it was my fault for not fully unjailbreaking first. And I just want to confirm that you’ve installed this patch by running this project? because I noticed that you mentioned doing this manually. Sorry, I just wanna make sure before I attempt to run it again 😅

[SongXiaoXi]

@dlevi309 Yes, I have encountered this problem, it seems that fugu14 itself will not overwrite /Library/LaunchDaemon/analyticsd.plist if you forgot to delete it beforehand.

[dlevi309]

@SongXiaoXi You should probably add that to the explanation above then, because that would have been good to know :p either way, I’ll try this out again at some point, so thank you again for your contribution

[badger200]

@SongXiaoXi Success!! I finally got the nerve to do this. You were right, I needed to remove the schg,uchg chflags from /var/mobile/Containers/Data/Fugu14Untether/Library/Caches/com.apple.dyld/*.closure (analyticsd.closure and stage2.closure) in order to chown 263:263 them, then I restored it via chflags -v schg,uchg *.closure.

The rest was straightforward but I was triple checking everything and caution anyone following this, I made sure to use chown -h 263:263 /var/mobile/Containers/Data/Fugu14Untether/Library to affect the symbolic link itself (via the -h), then proceeded to chown -R 263:263 /var/db/analyticsd/.

For anyone following this, here's a list of my exact commands from my .bash_history, I left in all my checks so you can remember to confirm each step yourself:

I have several aliases: xls is a Darwin copy of the ls binary (as opposed to GNU coreutils) I got from binpack64. xlsxf is my alias for xls -l@O which displays flags (and xattrs, not needed here but useful to have). v and vl are just my personal favorite bash aliases for dir listing:

alias v='ls -lapsF --group-directories-first' alias vl='ls -lapF --color=always --group-directories-first'

Several more extremely handy aliases I use:

alias llg='launchctl list | grep' (usage: llg (servicename)) alias lpg='launchctl print' (usage: lpg system/(servicename)) alias lstop='launchctl stop' (usage: lstop (servicename)) alias lsop='lsof -p' (usage: lsop (pid)) alias p=nano (used so often I give it a 1-letter alias) alias pg='ps aux | grep' (usage: pg (pid or process name))

46412  xlsxf /User/Containers/Data/Fugu14Untether/Library/Caches/com.apple.dyld/
46414  xlsxf /var/Fugu14UntetherDYLD/
46415  xlsxf /var/Fugu14UntetherDYLD/Caches/
46416  xlsxf /var/Fugu14UntetherDYLD/Caches/com.apple.dyld/
46417  xlsxf /var/db/analyticsd/
46418  xlsxf /User/Containers/Data/Fugu14Untether/
46419  xlsxf /User/Containers/Data/Fugu14Untether/Library
46420  xlsxf /User/Containers/Data/Fugu14Untether/Library/
46421  xlsxf /var/mobile/Containers/Data/Fugu14Untether
46422  xlsxf /var/mobile/Containers/Data/Fugu14Untether/Library/Caches/com.apple.dyld/
46423  cd /etc
46424  v *pass*
46425  cp -a passwd passwd.LKG
46426  cp -a master.passwd master.passwd.LKG
46427  p passwd
46428  p master.passwd
46429  cd /var/Fugu14UntetherDYLD/
46430  vl
46431  vl Caches/
46432  vl Caches/com.apple.dyld/
46434  chown --help
46435  v
46436  chown 263:263 .
46437  v
46438  chown 263:263 Caches/
46439  v
46440  cd Caches/
46441  v
46442  chown 263:263 com.apple.dyld/
46443  cd com.apple.dyld/
46444  v
46445  chown 263:263 *
46446  v /var/mobile/Containers/Data/Fugu14Untether/
46447  chown 263:263 /var/mobile/Containers/Data/Fugu14Untether/
46448  v /var/mobile/Containers/Data/Fugu14Untether/
46449  chown -h 263:263 /var/mobile/Containers/Data/Fugu14Untether/Library
46450  v /var/mobile/Containers/Data/Fugu14Untether/Library
46451  v /var/mobile/Containers/Data/Fugu14Untether/
46452  v /var/mobile/Containers/Data/Fugu14Untether/Library/Caches/
46453  v /var/mobile/Containers/Data/Fugu14Untether/Library/Caches/com.apple.dyld/
46454  v /var/db/analyticsd/
46455  chown -R 263:263 /var/db/analyticsd/
46456  v /var/db/analyticsd/
46457  v /var/db/analyticsd/state/
46458  v /var/db/analyticsd/Library/
46459  v /var/db/analyticsd/Library/Preferences/
46460  xlsxf /var/db/analyticsd/Library/Preferences/
46461  xlsxf
46462  man chflags
46463  v
46464  chflags -v noschg,nouchg *.closure
46465  xlsxf
46466  chown 263:263 *.closure
46467  xlsxf
46468  chflags -v schg,uchg *.closure
46469  xlsxf
46470  pg analytics
46471  alias xlsxf
46472  xlsx -lO
46473  alias xlsx
46474  xls -lO
46475  stat *
46476  lstop com.apple.analyticsd
46477  llg analyt 
46478  lsop 1234

(Verified that analyticsd.back (pid 1234) had immediately restarted itself and now has /var/db/analyticsd/config.sqlite open for the first time since I jailbroke!)

Notice command 46449 does NOT have a trailing / on the path, crucial for affecting the symlink itself, rather than the dir it points to)

[nildeveloper]

@SongXiaoXi Success!! I finally got the nerve to do this. You were right, I needed to remove the schg,uchg chflags from /var/mobile/Containers/Data/Fugu14Untether/Library/Caches/com.apple.dyld/*.closure (analyticsd.closure and stage2.closure) in order to chown 263:263 them, then I restored it via chflags -v schg,uchg *.closure.

The rest was straightforward but I was triple checking everything and caution anyone following this, I made sure to use chown -h 263:263 /var/mobile/Containers/Data/Fugu14Untether/Library to affect the symbolic link itself (via the -h), then proceeded to chown -R 263:263 /var/db/analyticsd/.

For anyone following this, here's a list of my exact commands from my .bash_history, I left in all my checks so you can remember to confirm each step yourself:

I have several aliases: xls is a Darwin copy of the ls binary (as opposed to GNU coreutils) I got from binpack64. xlsxf is my alias for xls -l@O which displays flags (and xattrs, not needed here but useful to have). v and vl are just my personal favorite bash aliases for dir listing:

alias v='ls -lapsF --group-directories-first' alias vl='ls -lapF --color=always --group-directories-first'

Several more extremely handy aliases I use:

alias llg='launchctl list | grep' (usage: llg (servicename)) alias lpg='launchctl print' (usage: lpg system/(servicename)) alias lstop='launchctl stop' (usage: lstop (servicename)) alias lsop='lsof -p' (usage: lsop (pid)) alias p=nano (used so often I give it a 1-letter alias) alias pg='ps aux | grep' (usage: pg (pid or process name))

46412  xlsxf /User/Containers/Data/Fugu14Untether/Library/Caches/com.apple.dyld/
46414  xlsxf /var/Fugu14UntetherDYLD/
46415  xlsxf /var/Fugu14UntetherDYLD/Caches/
46416  xlsxf /var/Fugu14UntetherDYLD/Caches/com.apple.dyld/
46417  xlsxf /var/db/analyticsd/
46418  xlsxf /User/Containers/Data/Fugu14Untether/
46419  xlsxf /User/Containers/Data/Fugu14Untether/Library
46420  xlsxf /User/Containers/Data/Fugu14Untether/Library/
46421  xlsxf /var/mobile/Containers/Data/Fugu14Untether
46422  xlsxf /var/mobile/Containers/Data/Fugu14Untether/Library/Caches/com.apple.dyld/
46423  cd /etc
46424  v *pass*
46425  cp -a passwd passwd.LKG
46426  cp -a master.passwd master.passwd.LKG
46427  p passwd
46428  p master.passwd
46429  cd /var/Fugu14UntetherDYLD/
46430  vl
46431  vl Caches/
46432  vl Caches/com.apple.dyld/
46434  chown --help
46435  v
46436  chown 263:263 .
46437  v
46438  chown 263:263 Caches/
46439  v
46440  cd Caches/
46441  v
46442  chown 263:263 com.apple.dyld/
46443  cd com.apple.dyld/
46444  v
46445  chown 263:263 *
46446  v /var/mobile/Containers/Data/Fugu14Untether/
46447  chown 263:263 /var/mobile/Containers/Data/Fugu14Untether/
46448  v /var/mobile/Containers/Data/Fugu14Untether/
46449  chown -h 263:263 /var/mobile/Containers/Data/Fugu14Untether/Library
46450  v /var/mobile/Containers/Data/Fugu14Untether/Library
46451  v /var/mobile/Containers/Data/Fugu14Untether/
46452  v /var/mobile/Containers/Data/Fugu14Untether/Library/Caches/
46453  v /var/mobile/Containers/Data/Fugu14Untether/Library/Caches/com.apple.dyld/
46454  v /var/db/analyticsd/
46455  chown -R 263:263 /var/db/analyticsd/
46456  v /var/db/analyticsd/
46457  v /var/db/analyticsd/state/
46458  v /var/db/analyticsd/Library/
46459  v /var/db/analyticsd/Library/Preferences/
46460  xlsxf /var/db/analyticsd/Library/Preferences/
46461  xlsxf
46462  man chflags
46463  v
46464  chflags -v noschg,nouchg *.closure
46465  xlsxf
46466  chown 263:263 *.closure
46467  xlsxf
46468  chflags -v schg,uchg *.closure
46469  xlsxf
46470  pg analytics
46471  alias xlsxf
46472  xlsx -lO
46473  alias xlsx
46474  xls -lO
46475  stat *
46476  lstop com.apple.analyticsd
46477  llg analyt 
46478  lsop 1234

(Verified that analyticsd.back (pid 1234) had immediately restarted itself and now has /var/db/analyticsd/config.sqlite open for the first time since I jailbroke!)

Notice command 46449 does NOT have a trailing / on the path, crucial for affecting the symlink itself, rather than the dir it points to)

How about making a shell script？

[badger200]

@nildeveloper I considered it, it would be pretty easy to do, but given the possibility of bricking someone's device or at least breaking their jailbreak possibly irreversibly (or necessitating an orig-fs restore which loses everything you've ever added on disk0s1s1 (all except /private/var or /var), I don't feel it would be a responsible thing to do. Also I only have iOS 14.4 to test on and I can't assume my shell script would correctly handle everyone using it. I really hope LinusHenze and Pwn2ownd will accept @SongXiaoXi 's PR to make this all part of the proper fix.

If you're willing to accept all those risks, I can take the terminal history I posted and just strip out all the verbose checks and let you try it...?

Or you could even do it yourself by pasting that into a file, then simply running something like cut -b7- myscript.sh > my scriptfixed.sh (might have to experiment with the number 7, I'm assuming that's enough to strip the 5 digit command numbers from each line in my bash history, plus the two spaces after them.) Of course you'd have to make sure you activated all the aliases I mentioned and have the Darwin ls binary available as xls in your path, plus chflags (available on bigboss, a package like system-cmds or similar name; just search and it'll come up, or use binpack64 from googling "newosxbook binpack64"

[nildeveloper]

@nildeveloper I considered it, it would be pretty easy to do, but given the possibility of bricking someone's device or at least breaking their jailbreak possibly irreversibly (or necessitating an orig-fs restore which loses everything you've ever added on disk0s1s1 (all except /private/var or /var), I don't feel it would be a responsible thing to do. Also I only have iOS 14.4 to test on and I can't assume my shell script would correctly handle everyone using it. I really hope LinusHenze and Pwn2ownd will accept @SongXiaoXi 's PR to make this all part of the proper fix.

If you're willing to accept all those risks, I can take the terminal history I posted and just strip out all the verbose checks and let you try it...?

Or you could even do it yourself by pasting that into a file, then simply running something like cut -b7- myscript.sh > my scriptfixed.sh (might have to experiment with the number 7, I'm assuming that's enough to strip the 5 digit command numbers from each line in my bash history, plus the two spaces after them.) Of course you'd have to make sure you activated all the aliases I mentioned and have the Darwin ls binary available as xls in your path, plus chflags (available on bigboss, a package like system-cmds or similar name; just search and it'll come up, or use binpack64 from googling "newosxbook binpack64"

Thanks for your reply, i have restored rootfs last night，bacause of the random reboot when using some APP. It seems that the operation is still a bit complicated at present, let's wait for LinusHenze and Pwn2ownd to fix it.

[UInt2048]

I think the bigger news here is your claim on line 774 of arm/shared/KernelExploit/Sources/KernelExploit/offsets.swift that this works without issue on iOS 14.2.x

[Purool]

I had installed fugu14 with your change, now battery usage is normal. (12mini ,14.3)

[dlevi309]

pulled the trigger on this and battery usage + all the smaller bugs caused by the original bug (which was.. a lot) are all fixed up! Thanks for your work on this! (and I didn’t do the manual method, I restored rootfs, reinstalled the jailbreak with xcode, etc. on an iPhone 12 Pro Max, 14.4)

btw, if someone wrote a script to automate the manual method, this fix could easily be deployed as a package for users who currently have the original installed

[badger200]

Guys 🚨I've been getting kernel panics🚨 every time I play Real Racing 3 and click video ads (not sure why, but this is a very reliable trigger) usually panic log saying "Unexpected SoC watchdog reset" otherwise it's a use after free zone in panicked task launchd pid 1.

Ever since about 2 days after I did this fix... I have carefully traced everything else I changed on my system in this timeframe and step by step isolated it but the panics continue EVEN if I disable tweak injection altogether!

Could it possibly be related to the analyticsd fix?

Do any of you who implemented this fix have Real Racing 3 installed and can try clicking 5-10 ads? I cannot watch 5-10 ads without a panic. Usually it panics on the first ad. Sometimes it panics as soon as the RR3 game menu loads!

If anyone knows how to debug a kernel panic I'm all ears. I used jtool2 to symbolicate my panic-full-xxx.ips log but don't see any obvious culprit.

[UInt2048]

Does this occur with and without this PR? I have not tested PR #242, but I’ve experienced what I believe to be panics attempting to watch SimCity Buildit ads when jailbroken.

iPadから送信

2022/06/12 5:18、badger200 @.***>のメール:

 Guys I've been getting kernel panics every time I play Real Racing 3 and click video ads (not sure why, but this is a very reliable trigger) usually panic log saying "Unexpected SoC watchdog reset" otherwise it's a use after free zone in panicked task launchd pid 1.

Ever since about 2 days after I did this fix... I have carefully traced everything else I changed on my system in this timeframe and step by step isolated it but the panics continue EVEN if I disable tweak injection altogether!

Could it possibly be related to the analyticsd fix?

Do any of you who implemented this fix have Real Racing 3 installed and can try clicking 5-10 ads? I cannot watch 5-10 ads without a panic. Usually it panics on the first ad. Sometimes it panics as soon as the RR3 game menu loads!

If anyone knows how to debug a kernel panic I'm all ears. I used jtool2 to symbolicate my panic-full-xxx.ips log but don't see any obvious culprit.

— Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you commented.

[badger200]

@UInt2048 Unfortunately I found this Issue for uncover 8.0.2 on the same iOS 14.4 I'm on: unc0ver 8.0.2 ios 14.4 kernel panic when launching game He gets panics launching Fruit Ninja 2 on his iPhone.

Update: Wow, I installed Fruit Ninja 2, and just as his Issue describes, I ☠️immediately got a kernel panic☠️ (pink screen/reset) 10 seconds after launching the app. It was merely playing an intro screen.

Are you also using iOS 14.4?

I did the analyticsd user/group edits all manually (see my long comment above) and it's not easily reversible, I didn't take detailed notes on what all files/dirs/symlinks original perms were. So now I'm nervous about undoing the change, but I will have to do it if I can't find another solution.

[SongXiaoXi]

@badger200 As far as I know, the substituted spawned by unc0ver will patch struct task at the time when a process is created. If the process exits or some other thing happens, this patch will corrupt the task zone. This bug is common using Fugu14 and unc0ver. Because the kernel rw primitive of Fugu14 is slow and this race condition happens more frequently than the unc0ver with cicuta_virosa. If your device is iOS 14.3 or below, you can remove or rename /usr/lib/libkrw/libFugu14Krw.dylib to force unc0ver using cicuta_virosa even with Fugu14 untether.

[badger200]

@SongXiaoXi Very good insight into the issue. Unfortunately I am using 14.4. I believe even when I disabled Tweak Injection in the SubstituteSettings.app, it still injects substitute-loader.dylib etc into every app.

I wonder if I could switch to Cydia Substrate somehow as a test?

[SongXiaoXi]

@badger200 No. substituted is a part of unc0ver with code obfuscation and only injects substitute. Cydia Substrate does not work.

[UInt2048]

Yes, my device is an iPad Air 4 on iPadOS 14.4.

iPadから送信

2022/06/12 5:35、badger200 @.***>のメール:

 @UInt2048 Unfortunately I found this Issue for uncover 8.0.2 on the same iOS 14.4 I'm on: pwn20wndstuff/Undecimus#2288 He gets panics launching Fruit Ninja 2 on his iPhone.

Are you also using iOS 14.4?

I did the analyticsd user/group edits all manually (see my long comment above) and it's not easily reversible, I didn't take detailed notes on what all files/dirs/symlinks original perms were. So now I'm nervous about undoing the change, but I will have to do it if I can't find another solution.

— Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you were mentioned.

[badger200]

@UInt2048 Can you install Fruit Ninja 2 and report whether it panics 10 seconds after launching the app?

I'm curious if anyone else here using unc0ver 8.0.2/Fugu14 on iOS 14.4+ gets panics on Fruit Ninja 2 a mere 10 seconds later?

[badger200]

@SongXiaoXi Do you think I should try changing my analyticsd groups etc back to original to see if my panics stop? Is there any step that could kill my jailbreak? I absolutely cannot afford to lose my /dev/disk0s1s1 data with an orig-fs restore.

(Unless it's possible to make a new snapshot, restore, then restore to this other snapshot, so the net result is as if I never did any restoring?)

[SongXiaoXi]

@badger200 I'v suffered the panic a lot, with the official Fugu14 and unc0ver, but cannot fix it. It is impossible to reverse engineer unc0ver. So I rename /usr/lib/libkrw/libFugu14Krw.dylib to use the cicuta_virosa exploitation. Still panic, but less frequently.

[UInt2048]

I don’t even need to install it to report that - I got one just now ten seconds after opening SimCity Buildit, so it’s definitely the same issue.

In addition, when opening Safari and an automation ran, I received another one.

iPadから送信

2022/06/12 6:01、badger200 @.***>のメール:

 @UInt2048 Can you install Fruit Ninja 2 and report whether it panics 10 seconds after launching the app?

I'm curious if anyone else here using unc0ver 8.0.2/Fugu14 on iOS 14.4+ gets panics on Fruit Ninja 2 a mere 10 seconds later?

— Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you were mentioned.

[badger200]

@SongXiaoXi Exciting news! With the new Linus Henze CoreTrust root certificate exploit being used to install unc0ver v6-v8 which never expires, (search Cydia for unc0ver to install), is there a way I can test disabling the untether to see if it eliminates panics?

What about renaming the 2 .closure files in /private/var/Fugu14UntetherDYLD/Caches/com.apple.dyld/? Theoretically I could use the non-expiring unc0ver to retail real and restore their original names. But I want to check with you before I do something foolish...

I found a new game I love SpotRacer but it panics every single time when jailbroken, so I'm more desperate than ever to ditch Fugu14...

[SongXiaoXi]

@badger200 Does the CoreTrust root certificate exploit contain a kernel r/w primitive? If not, you will probably get an 'Unsupported' in unc0ver although unc0ver never expires.

By the way, do not modify these files unless you know what you'ar doing. You can easily corrupt things that the offical Fugu14 cannot rejailbreak. At that point you have to modify Fugu14 untether process to revoke what you did first.

[badger200]

@SongXiaoXi I'm not sure, I'm guessing it doesn't.

I was able to use the Fugu14 boot-arg "no_untether" to test safely, and you are right I simply got "Unsupported". I removed the boot-arg and I'm back to normal.

Really disappointing there's a whole series of major apps that cannot be run with this jailbreak... Fruit Ninja 2 and Real Racing 3 are flagship apps featured in the App Store with tens of millions of users.

[combustor]

Has anyone made a package or bash script that automates this fix?

If so, please let me know

[badger200]

Has anyone made a package or bash script that automates this fix?

If so, please let me know

I'm willing to make one if someone is willing to risk their device testing it.

I guess the likely worst case scenario would be you have to restore orig-fs, ...but there's always a chance you could break Fugu14 altogether and lose your jailbreak. I'd be 99% confident in my script if I make one, but that 1% possibility is just so dreadful I couldn't bear it if I caused someone to needlessly lose their jailbreak.

[combustor]

Has anyone made a package or bash script that automates this fix?

If so, please let me know

I'm willing to make one if someone is willing to risk their device testing it.

I guess the likely worst case scenario would be you have to restore orig-fs, ...but there's always a chance you could break Fugu14 altogether and lose your jailbreak. I'd be 99% confident in my script if I make one, but that 1% possibility is just so dreadful I couldn't bear it if I caused someone to needlessly lose their jailbreak.

I'll try it if you want me to

I'll risk that 1% chance haha

I'm on 14.4.2 A12 using the latest unc0ver

[combustor]

I tried it today because I didn't have access to a PC yesterday

Edited the /var/ files using Filza because I trust myself with it more than I trust myself with nano/vi

SSH'd into my phone, did all the commands (with no checks) 😅 and it worked! Thank you @badger200 and @SongXiaoXi

Now hopefully the kernel panics while playing certain games gets fixed soon (although that's an unc0ver issue I guess 🤷)

[junior2377]

Has anyone made a package or bash script that automates this fix? If so, please let me know

I'm willing to make one if someone is willing to risk their device testing it.

I guess the likely worst case scenario would be you have to restore orig-fs, ...but there's always a chance you could break Fugu14 altogether and lose your jailbreak. I'd be 99% confident in my script if I make one, but that 1% possibility is just so dreadful I couldn't bear it if I caused someone to needlessly lose their jailbreak.

I would really like a package or script for this because I’m not familiar enough to do it manually, but that being said I don’t want to lose my jailbreak either.

I’m on a 12 pro 14.3

[Manan2004]

I also would really love to have this script or package, i dont even mind doing manually just need proper tutorial

11 pro max 14.5

[aizeron1]

I had installed fugu14 with your change, now battery usage is normal. (12mini ,14.3)

hello, can you share the compiled version of fugu?

[Gasem1412]

I also would really love to have this script or package, i dont even mind doing manually just need proper tutorial

11 pro max 14.5

[Liam0205]

Hey Guys, I've just written a tweak to fix this issue, based on @SongXiaoXi's and @badger200's posts. It's now at public beta.

You could now find it by searching FixBatteryUsageFugu14 from the source https://liam.page/apt-beta/. Later, it might be removed from beta and be added into https://liam.page/apt/.

[badger200]

@Liam0205 Awesome! I just downloaded it and unpacked and ran "strings" on the dylib and it looks good to me. I can't test it, but I'm assuming this is a package a user would only need to install, reboot, and remove, correct? That would be worth mentioning somewhere, perhaps both in the control description and in the postinst or wherever triggers it to display in Cydia during the install process the way Karen's appsync and others do it.

[SongXiaoXi]

@Liam0205 Awesome! But it seems that you inject a dylib into SpringBoard running as mobile? Should NOPASSWD be enabled for mobile in /etc/sudoers? The default sudoers does not include this. And if you do the passwd magic trick mentioned above, there is no need to run scripts after each boot. The whole deb only contains one simple preinst or postinst script running commands like this. Then remove it.

[badger200]

@SongXiaoXi Boy do I wish I had just spent the time to whittle down my script to just the essentials, back when this was all fresh in my mind. I cringe when I look how noisy and cluttered it is.

[Liam0205]

@SongXiaoXi @badger200 Thanks for your replies.

In the world of iOS reverse engineering, I am still a novice. So if I say or do something wrong or not good enough, please point it out to me like you did before.

Yes, my solution here is to inject a dynamic library into SpringBoard. Using the language features of Objective-C and the system library function in C language, a string of shell commands (the ones previously mentioned by @badger200) will be executed every time SpringBoard is loaded.

Before implementing this tweak, I manually executed these commands. They are effective, but they become invalid after reboot or respring. Observing that after launchctl stop com.apple.analyticsd, the owner of /var/db/analyticsd will be changed back to the original. So I thought of writing a tweak to execute these commands every time SpringBoard is loaded. Apparently, I didn't pay attention to the parts about passwd and master.passwd.

The part about sudoers... it may be because I had modified it a long time ago, so I didn't pay attention to it when testing. It's another mistake made by a beginner, haha.

As for preinst and postinst, I haven't tried these things yet. I'll think about how to use them. After I get it done, I'll open source the code of the tweak on GitHub and ask you two seniors to help me take a look.

[Manan2004]

Man total noob here but what am i supposed to do after installing the tweak so tweak alone does not fix it for me

[Liam0205]

Man total noob here but what am i supposed to do after installing the tweak so tweak alone does not fix it for me

Sorry for the inconvenience I caused.

It's probably because I didn't handle the part about the sudoers mentioned above. I'll fix it later.

[badger200]

@UInt2048 from the bottom of my huge script post, i mention using ps aux | grep analyticsd to find PID of analyticsd.back and then use lsof -p (pid) and verify it now has /var/db/analyticsd/config.sqlite open. Then you know it's functioning, collecting battery analytics data.

[Liam0205]

the postisnt, @badger200 might give a check?

#!/usr/bin/env bash

set -eu

# the directory of the script
DIR="$( cd "$( dirname "${BASH_SOURCE[0]}" )" && pwd )"

# the temp directory used, within $DIR
# omit the -p parameter to create a temporal directory in the default location
WORK_DIR=`mktemp -d -p "$DIR"`

# check if tmp dir was created
if [[ ! "$WORK_DIR" || ! -d "$WORK_DIR" ]]; then
  echo "Could not create temp dir"
  exit 1
fi

# deletes the temp directory
function cleanup {
  rm -rf "$WORK_DIR"
  echo "Deleted temp working directory $WORK_DIR"
}

# register the cleanup function to be called on the EXIT signal
trap cleanup EXIT

########

# backup
if [[ ! -f /etc/passwd.backup.page.liam ]]; then
  cp /etc/passwd /etc/passwd.backup.page.liam
fi
if [[ ! -f /etc/master.passwd.backup.page.liam ]]; then
  cp /etc/master.passwd /etc/master.passwd.backup.page.liam
fi

# modification
cd $WORK_DIR
cp /etc/passwd ./
cp /etc/master.passwd ./

sed -i '/_nanalyticsd/c\PAGE_LIAM_PLACEHOLDER' ./passwd
sed -i '/_analyticsd/c\_nanalyticsd:*:263:263:Analytics Daemon:/var/db/analyticsd:/usr/bin/false' ./passwd
sed -i '/PAGE_LIAM_PLACEHOLDER/c\_analyticsd:*:263:263:Haxx Daemon:/private/var/mobile/Containers/Data/Fugu14Untether:/usr/bin/false' ./passwd

mv ./passwd /etc/passwd

sed -i '/_nanalyticsd/c\PAGE_LIAM_PLACEHOLDER' ./master.passwd
sed -i '/_analyticsd/c\_nanalyticsd:*:263:263::0:0:Analytics Daemon:/var/db/analyticsd:/usr/bin/false' ./master.passwd
sed -i '/PAGE_LIAM_PLACEHOLDER/c\_analyticsd:*:263:263::0:0:Haxx Daemon:/private/var/mobile/Containers/Data/Fugu14Untether:/usr/bin/false' ./master.passwd

mv ./master.passwd /etc/master.passwd

# do the dirty work
cd /var/mobile/Containers/Data/Fugu14Untether/Library/Caches/com.apple.dyld
chflags -v noschg,nouchg *.closure >/dev/null >2&
chown 263:263 *.closure
chflags -v schg,uchg *.closure >/dev/null >2&
chown -h 263:263 /var/mobile/Containers/Data/Fugu14Untether/Library
chown -R 263:263 /var/db/analyticsd/
launchctl stop com.apple.analyticsd

# show
>2& echo "Work Completed!"
>2& echo "You can now *REMOVE* this package!"

[badger200]

@Liam0205

Looks good to me. The only things I might change are: cp -a instead of just cpon the 2 passwd files, as the -a preserves permissions etc. Idk if it matters but good practice.

At the end consider adding:

sleep 3
launchctl start com.apple.analyticsd

When I tried making a script for this, I got stuck doing the search and replace with Perl, I thought you needed to escape all special characters in the regex s/orig/new/g string , but I don't see any escapes in your sed script. Does sed work without them?