Bplist entitlements need to be XML, causes fail on iOS 14.4 unc0ver 8.0.2

[badger200]

The beta and the 1.0 both would crash on launch and I kept seeing strange "AMFI failed to unserialize XML, line 1" errors constantly in my dmesg. (I thought it was very odd your installer creates libusb /usr/lib symlinks in postinst in a non-kosher manner that doesn't respect dpkg (it silently breaks usbmuxd2 because it changes the md5sum). This should be revised to a proper method.)

Anyway I finally found the problem: your /Applications/LiNUZE/Entitlements.plist is a bplist; it needs to be an XML. I used plutil to convert and then resign with ldid and now it launches for the first time.

Then I discovered you broke my /usr/sbin/usbmuxd with the same corrupt entitlements signing in your postinst, this was the cause of my constant AMFI failed to unserialize dmesg errors (iOS kept trying to launch org.libimobiledevice.usbmuxd and failing.)

After signing usbmuxd with the XML entitlements, now it works.

iOS 14.4 iPad Pro 11" 2018 iPad8,4 Unc0ver 8.0.2 with my own custom Procursus repo debs implemented in an Unc0ver-compatible fashion (all /usr and zero /opt).

I saw someone on Reddit r/jailbreak with the same failure, so I assume this is happening to every unc0ver iOS 14.4-14.8 user.

[rA9stuff]

Sorry about the issues. I’ll update entitlements and revise postinst, thanks for the reports!

[rA9stuff]

The latest nightly build is built with the postinst script fixes you suggested. Could you try running it and let me know how it goes?

[badger200]

@rA9stuff Hi, yes the nightly installs and launches now. Nice work.

I definitely am uncomfortable with those 10 create_symlinks in your postinst however. I get the sense you're trying to fudge the user's system into functioning regardless whether it's an uncover or procursus type jailbreak, but this is not a kosher way to do it, it it's likely to lead to system breakage down the road. For instance, uncover's jailbreak startup verifies a bunch of packages with dpkg and if it fails, sometimes this can render the device unable to jailbreak. (In my case I've had to use the port 1337 telnet iDownload shell Fugu14 provides to recover blindly from such a scenario.)

Arbitrarily symlinking openssl libcrypto.1.1 and libcrypto.3 is something you might get away with for your app, but it almost certainly will break other apps that expect v3 to contain v3 functions. A symlink to v1.1 will cause apps to believe that v3 is installed when in fact it might not be.

If you examine the way procursus packages their debs, they usually provide the versioned dylib in the libwhatever7 package, and the generic dylib symlink in the libwhatever7-dev package. So, there must be a way they're handling that.

I'm not actually certain what the proper protocol is for linking to dylibs, because I've seen a lot of stuff link to specific versioned dylibs, when I believe it would be safer to link to the general major version (like libzstd.1.dylib vs libzstd.1.5.2.dylib.) This could largely be due to incorrectly built install names with install_name_tool.

EDIT: otool -L reports your app LiNUZE uses:

/usr/lib/libimobiledevice.6.dylib
/usr/lib/libirecovery.3.dylib
/usr/lib/libusbmuxd.6.dylib

So, those should be all that's necessary to worry about. Handling the libimobiledevice and libplist stuff should be the responsibility of the libusbmuxd6 package, etc. I'm also familiar with the libplist wonkiness between unc0ver vs procursus and I've broken my system meddling with that in the past, so I would strongly recommend leaving that to the libplist packages to handle, even though I've done that same symlink you did (libplist-2.0.3.dylib to libplist.3.dylib). I think that's basically a numerical conflict between uncover vs procursus's versioning schmemes. Procursus really should've chosen a version that is numerically higher than unc0ver to avoid this. Instead, dpkg gets confused because libplist v2.2 would seem superior to v2.0.3 when in reality it isn't.

In other words, your .deb control depends lists libusbmuxd6, libusb-1.0-0, libirecovery3, libplist3, libimobiledevice6, usbmuxd, ldid , that should be sufficient and you shouldn't need to be creating any /usr/lib dylib symlinks whatsoever.

I'm assuming usbmuxd needs additional entitlements for this app to work; I would contact the libusbmuxd6 package maintainer and/or file a PR to add them, rather than arbitrarily modifying the user's usbmuxd binary which will cause dpkg to believe their usbmuxd2 package is corrupt, potentially leading to breakage of your app down the road if dpkg might attempt usbmuxd2 package repair.