AppSync
AppSync copied to clipboard
akemin-dayo
An bug in the ElleKit code injection framework causes AppSync Unified to not work correctly on some jailbreak environments (※ Dopamine, palera1n-c in `-l` rootless mode, etc.) in certain configurations
Multiple people over in the Reddit post announcing version 112 reported this issue, so I am formally filing a bug since it seems none of them did. We are getting a "Couldn't communicate with a helper application" error with the following combination:
- iPadOS 16.5.1
- Palera1n 2.0 beta 7
- Ellekit tweak injector installed
- Installing .IPA via Filza
It seems one person also claims to have his this on iPadOS 15.1 using Dopamine, so maybe the above aren't strict requirements. I also tried loading a .IPA directly without Filza via a site that hooks directly into AppSync Unified (if installed) and the app silently failed to install.
I’m having the exact same issue. iPad Pro 10.5”, iOS 16.5.1, palera1n, same error on Filza. It didn’t work with the command line tweak either.
I found you can install .ipa's by installing "TrollStore Helper" via Sileo/Zebra which in turn installs TrollStore. It should be available from the default repos and will self-sign the app. Even though the original exploit it worked on was patched, if you're already jailbroken, the signing still works fine.
Note that this has nothing to do with AppSync whatsoever. AppSync still has issues in terms of hooking into Filza and web-hosted .ipa links.
I never even thought to try that. Can you specify your dev account or will it endlessly resign?
You don't need a dev account. You just point Trollstore to an .ipa hosted in the Files app, and it installs it.
Again though, I would really like to see AppSync properly fixed since a lot of things are designed to work with it.
iPhone 8 iOS 16.5.1c palen1x rootless Jailbreak, install Appsync(Couldn't communicate with a helper application), then Trollhelper and TrollStore, now it works!
I found you can install .ipa's by installing "TrollStore Helper" via Sileo/Zebra which in turn installs TrollStore. It should be available from the default repos and will self-sign the app. Even though the original exploit it worked on was patched, if you're already jailbroken, the signing still works fine.
Note that this has nothing to do with AppSync whatsoever. AppSync still has issues in terms of hooking into Filza and web-hosted .ipa links.
OMG it worked!! I thought Trollstore wasn’t available for iOS 16 but I guess it is. Thanks!
I have the exact same issue: IPad 7th Gen (Cellular) on iPadOS 16.5.1 and palera1n rootless. Filza says couldn't communicate with helper application, and appinst on the command line simply says it failed installing. This happens with every IPA i tried.
I doubt this is a problem with AppSync. Filza can't even properly install DEB files on rootless. With AppSync I can install IPAs via sideloadly with my dev account.
For Filza you need to wait for them to fix their mess.
As I said, the problem occurs also with the appinst command, which is provided by the AppSync author himself, and thus I would expect it to work properly, but it doesn't.
And what does that have to do with Filza? I’m not required to address your entire comment. I addressed Filza. Your follow up wasn’t needed.
My follow-up is indeed needed, because it proves that the install issue is related to AppSync and not Filza. Your argument from before claimed that probably the problem is not in AppSync, since Filza has many issues. The fact that also appinst, the basic cli tool provided by the author to install IPAs has the same issue means the issue is not exclusive to Filza.
There is no need to be so passive-aggressive btw. Relax.
It proves no such thing and appsync works outside of filza. Filza can’t install anything in rootless, regardless of appsync.
Your problem is with appinst as you have failed to explain how all my IPAs are installed with my dev account to which sideloadly must not use appinst. Either that or you are doing something completely wrong.
So exactly like I said, filza has nothing to do with whether for not appsync works as filza can’t install squat with or without it.
Relax yourself kid.
If even the most basic tool such as appinst, that uses AppSync to install IPAs, and which comes from the AppSync author himself has issues, then sorry, but I still tend to believe the problem is in AppSync itself, or at least in the way apps communicate with it. Considering also the OP comment: "I also tried loading a .IPA directly without Filza via a site that hooks directly into AppSync Unified (if installed) and the app silently failed to install."
Anyway, there is no point in keeping this discussion going. I will wait for a proper technical answer.
Good, quit yapping and wait. Meanwhile my comment which you attempted to negate and failed is that appsync works outside of filza and filza has nothing to do with anything and should never be used as a metric for something else working or not.
On my iPad AppSync does NOT work even OUTSIDE Filza, this is what I am trying to say since the beginning, but you are purposely ignoring what I am saying. Also the OP points out that AppSync does not work even outside Filza. So the discussion about Filza was over already after my first comment. It is just you that keep talking about that. I am not talking about Filza. AppSync simply does not work (even outside Filza) as pointed out multiple times.
Apologies for the late reply to this issue thread in general — I've been quite busy with a deadline for something that I had to attend to after I released the latest version of ASU.
Thank you everyone, for all the reports.
What happened here?
During pre-release testing, I had attributed the appinst IPC failure behaviour that was presenting only on the Dopamine jailbreak to something being broken in some bizarre way specific to the Dopamine environment that I was unable to find the root cause of at the time (and had the aforementioned deadline coming up).
The thing about appinst is that it is… an extremely simple utility with not much room for error — it was utterly incomprehensible to me what was even breaking as all it really does is call native Apple APIs to trigger app installation by way of LSApplicationWorkspace on iOS >= 8, or MobileInstallation on anything lower. In other words, it's just what iOS natively already does to begin with.
My best guess at the time was that the IPC failure was occurring either due to some kind of sandboxing issue, some kind of entitlements issue, or some other bizarre quirk regarding Dopamine that I simply did not understand. I did try isolating that second possibility — just to make sure I hadn't gone completely insane, I stripped all the entitlements off of the appinst binary once during testing just to observe the behaviour, and the failure mode was completely different… so, that meant entitlements were working, as far as I could tell…
After days of repeatedly smashing my head into my keyboard, in the interest of allowing users with compatible configurations to use ASU as quickly as possible, I decided to release the updated versions of both ASU and appinst as-is, with an explicit warning regarding the known issues with Dopamine left in various places in the documentation, as seen below.
※ appinst does NOT currently work with the Dopamine jailbreak due to an IPC issue on that specific jailbreak. [Twitter] [Fediverse (Mastodon, Misskey, etc.)] [Bluesky]
After release, @opa334 (the developer of Dopamine) decided to take a closer look at what was happening, and discovered that at least on their configuration, appinst itself was fine, and AppSync Unified was actually the one that was somehow just… completely broken!?
I looked into it for a bit and it seems appinst works fine on Dopamine, but AppSync is broken to the point where not even App Store app installations work. Disabling the installd hook fixes this so there must be something wrong with it. Looked at source code but cannot see what's wrong :/. It could be an ellekit bug but then I don't see why it would work on palera1n rootless.
EDIT: There seems to be a null pointer dereference in installd but for some reason instead of crashing it just spins forever:
(lldb) thread select 2 * thread #2, queue = 'com.apple.root.utility-qos' frame #0: 0x0000000199eb7490 libobjc.A.dylib`objc_retain + 16 libobjc.A.dylib`objc_retain: -> 0x199eb7490 <+16>: ldr x10, [x9, #0x20] 0x199eb7494 <+20>: tbz w10, #0x2, 0x199eb74d8 ; <+88> 0x199eb7498 <+24>: tbz w8, #0x0, 0x199eb74f8 ; <+120> 0x199eb749c <+28>: mov x9, #0x100000000000000 (lldb) reg read General Purpose Registers: x0 = 0x0000000104a163a0 x1 = 0x00000001ce2c966e x2 = 0x0000000104a163a0 x3 = 0x00000001dc74fb98 @"Apple Inc." x4 = 0x0000000104716750 x5 = 0x000000010472a580 x6 = 0x99a0ff7499d2056b x7 = 0x00000001047307c0 x8 = 0x2000000000000000 x9 = 0x0000000000000000
In other words, the root cause of failure here at least on opa334's configuration appears to be with AppSync Unified itself and not appinst.
I am inclined to agree with their deduction of the root cause simply because as I said, appinst is so incredibly simple that I really cannot imagine what could have gone wrong there, other than the fabric of reality beginning to fray at the edges or something like that.
The weird thing is, during pre-release testing I did try to isolate whether appinst itself or AppSync Unified was the root cause of the IPC failure. For one, I never observed any installd crashes. (Though given opa334's "it just spins forever" observation… yeah, that's not really a crash, hence why CrashReporter would not fire a crash event.)
Another thing I did was that I downloaded a FairPlay-encrypted IPA using ipatool, and tried to install it on a Dopamine system with only appinst installed and no ASU package.
And that… failed. That's what led me to attribute the failure to appinst specifically instead of AppSync Unified. (That being said, I did still add a "※ Users using the Dopamine jailbreak may encounter issues." warning for AppSync Unified before I released it regardless, just to err on the side of caution since it became clear that the very fabric of reality was breaking down before my eyes…)
Another thing of note is that I never actually encountered this peculiar "not even App Store app installations work" behaviour that opa334 mentioned. Had this been the case for me, it would have definitely led me to discover that AppSync Unified was the root cause of the issue.
I even had a dev version of AppSync Unified that spewed some debug logging once it was injected into installd, and that worked just fine. Why and how opa334's Dopamine environment differs from mine in this regard, I have not yet figured out.
The rootless-mode (-l) palera1n-c reports
All that being said… the various reports I've seen (both in this thread and on reddit) of AppSync Unified (and appinst) not working correctly on some rootless-mode (-l argument) palera1n-c configurations are… unexpected, and actually did not occur with my very limited pre-release testing of this particular combination.
(※ I do not personally own an iOS 16 device that can be used with palera1n-c, and thus had to resort to remote testing. At some point soon I will properly fully set up and post my Throne account on all my relevant SNS platforms so I can hopefully crowdfund a D22/D221 or other palera1n-c-able device for development purposes so I can properly test locally.)
The fact that some rootless-mode palera1n-c configurations are also exhibiting the same failure mode makes me feel that, as opa334 had suggested, this may be an issue somewhere in ElleKit, as both Dopamine and rootless-mode palera1n-c use ElleKit as their code injection framework. It's the closest thing that links both jailbreak environments, and it would also make sense as not many other things could cause this kind of failure. (※ Rooted/rootful/fakefs-mode palera1n-c does not use ElleKit.)
Gods know I've broken both Substrate and Substitute with my code (including ASU) in the past, might as well add ElleKit to the list of code injection frameworks I've somehow managed to utterly break. ;P
I will spend some time in the coming week looking into this, and probably will poke Évelyne to see if she has any idea as to what's going on.
Do note that it's also possible the root cause might not even be ElleKit (it's simply just the most likely scenario right now with the information we currently have), but rather something else entirely.
We'll see.
And again, thank you all for reporting!
Yeah, I… uh… I'm not reading all that.
tl;dr: Sorry for the late reply, and thank you for all the reports. My best guess at the cause of the issue as of this writing is that this is likely an issue with the ElleKit code injection framework. I will look into it and ask Évelyne if she has any idea as to what's going on.
Thanks a lot for your detailed reply! You are doing a great job with ASU. I am looking forward for updates on this!
If it can help, when installing palera1n in rootful mode, ASU works both using appinst, as well as other installers using ASU.
If it can help, when installing palera1n in rootful mode, ASU works both using appinst, as well as other installers using ASU.
@marco-calautti Yes, this is expected behaviour — the rooted/rootful/fakefs (-f) version of palera1n-c does not use ElleKit, and has no other known issues that came up during pre-release testing. Thanks for reporting, though!
You don't need a dev account. You just point Trollstore to an .ipa hosted in the Files app, and it installs it.
Again though, I would really like to see AppSync properly fixed since a lot of things are designed to work with it.
Hey, I had the same issue (iPhoneX iOS 16.5.1, palera1n rootless jb, ellekit 1.0) I made a gist for it https://gist.github.com/hackcatml/f7b7e0458df04e9bdd13583490cf0be1 You can check it out if you still want to install an .ipa using Filza You need to build AppSync yourself, though
I looked into this now, this is the full backtrace I got from the crash:
frame #0: 0x0000000198e27490 libobjc.A.dylib`objc_retain + 16
frame #1: 0x000000010408e174 installd`___lldb_unnamed_symbol1143 + 72 -[MICodeSigningInfo initWithSignerIdentity:signerOrganization:codeInfoIdentifier:teamIdentifier:signatureVersion:entitlements:signerType:profileType:signingInfoSource:]
frame #2: 0x00000001040ae684 installd`___lldb_unnamed_symbol1474 + 3996 -[MICodeSigningVerifier performValidationWithError:]
frame #3: 0x0000000104085250 installd`___lldb_unnamed_symbol1033 + 1896 -[MIExecutableBundle codeSigningInfoByValidatingResources:performingOnlineAuthorization:ignoringCachedSigningInfo:checkingTrustCacheIfApplicable:skippingProfileIDValidation:error:]
frame #4: 0x00000001040841f0 installd`___lldb_unnamed_symbol1029 + 68 -[MIExecutableBundle needsDataContainer]
frame #5: 0x0000000104053dac installd`___lldb_unnamed_symbol525 + 80 +[MILaunchServicesDatabaseGatherer entryForBundle:inContainer:withError:]
frame #6: 0x0000000104054fcc installd`___lldb_unnamed_symbol533 + 324 -[MILaunchServicesDatabaseGatherer scanExecutableBundle:inContainer:withError:]
frame #7: 0x00000001040771d4 installd`___lldb_unnamed_symbol846 + 488 -[MIFilesystemScanner _scanBundleContainerType:withError:ignoredErrorOccurredOnOneOrMoreItems:]
frame #8: 0x0000000104077484 installd`___lldb_unnamed_symbol847 + 92 -[MIFilesystemScanner _scanBundleContainersWithError:ignoredErrorOccurredOnOneOrMoreItems:]
frame #9: 0x00000001040775b4 installd`___lldb_unnamed_symbol850 + 136 -[MIFilesystemScanner performScanWithError:]
frame #10: 0x00000001040558d0 installd`___lldb_unnamed_symbol536 + 324 -[MILaunchServicesDatabaseGatherer performGatherWithError:]
frame #11: 0x000000010405b974 installd`___lldb_unnamed_symbol623 + 996 sub_100013590
The issue is the following: -[MICodeSigningVerifier performValidationWithError:] calls SecCertificateCopySubjectSummary, which is hooked by AppSync, that hook seems to return garbage which is later passed to -[MICodeSigningInfo initWithSignerIdentity:signerOrganization:codeInfoIdentifier:teamIdentifier:signatureVersion:entitlements:signerType:profileType:signingInfoSource:] as the first argument, that method attempts to call objc_retain on it, which crashes the process (or makes it get stuck on Ellekit 1.0 apparently, but on 1.1 upstream it crashes).
Even just returning orig in SecCertificateCopySubjectSummary seems to trigger this issue, leading me to believe this is indeed an ellekit bug.
(lldb) disassemble -n SecCertificateCopySubjectSummary
Security`SecCertificateCopySubjectSummary:
0x1895c673c <+0>: cbz x0, 0x1895c6858 ; <+284>
0x1895c6740 <+4>: pacibsp
0x1895c6744 <+8>: sub sp, sp, #0x60
0x1895c6748 <+12>: stp x22, x21, [sp, #0x30]
0x1895c674c <+16>: stp x20, x19, [sp, #0x40]
0x1895c6750 <+20>: stp x29, x30, [sp, #0x50]
The issue is that that SecCertificateCopySubjectSummary has a cbz before the function prologue, this causes ellekit to incorrectly hook it in a way where the call to orig will skip over the entire function and just return the value that just so happens to be in x0. As an experiment I have manually added +4 to the SecCertificateCopySubjectSummary function pointer. That solved it and both appinst and AppSync now work fine (Although only adhoc signed IPAs will run as Dopamine doesn't add anything non-adhoc-signed to trustcache). Reported this to evelyne now so it will hopefully be fixed in ellekit soon.
@akemin-dayo Something confuses me about your explanation.
I’m currently using an iPhone 8 Plus, palera1n rootful jb AND using Ellekit, as Substrate/Substitute crashes my phone out of the jb continuously when using checkl0ck and a couple other tweaks, while Ellekit works with EVERYTHING.
But App Sync Unified does not work for me…
Edit: also handy to know I’m running on iOS 16.5
@mhdj14 The issue is as opa334 said above — there's a bug in ElleKit (at least, on some devices/configurations…?) that results in a process crash when a specific C function, SecCertificateCopySubjectSummary() is hooked at all (※ even if you simply return the original implementation's behaviour).
The only thing you or I can do at this point is to remain patient and wait for Évelyne to determine the root cause of the issue whenever she has the free time to do so, and fix it in an update to ElleKit.
@mhdj14 The issue is as opa334 said above — there's a bug in ElleKit (at least, on some devices/configurations…?) that results in a process crash when a specific C function,
SecCertificateCopySubjectSummary()is hooked at all (※ even if you simply return the original implementation's behaviour).The only thing you or I can do at this point is to remain patient and wait for Évelyne to determine the root cause of the issue whenever she has the free time to do so, and fix it in an update to ElleKit.
Okay, cool. Thank you for your reply 👍
I must have misread your original explanation based on how you worded it. I thought that using Ellekit on a rootful jb caused App Sync Unified not to work.
But it’s Ellekit in general instead.
Hey! I fixed these issues, and the installd issue isn't present anymore on my device. Could some of you test these debs (rootful & rootless) and confirm, they're zipped because GitHub won't upload debs.
I'm busy travelling with some close friends at the moment, but I will test this as soon as possible!
Thank you for your hard work!!
Hopefully this leads to Apple File Conduit getting fix. SSH is such a nightmare and because every SSH app out there doesn't have proper entitlements, no access to app folders.