Are you building an app X that crashes because of a library installed by app Y?
I imagine that installing via Enterprise Certs doesn't remove the sandboxing around Y...
Can you please elaborate on what's actually happening?
back
1 comments
A lot of sideloaded apps are normal app store apps with "tweaks" applied to them: think Snapchat that lets you keep images, or YouTube with no ads. Sometimes, these resigned apps have malware or ad libraries built into them.
Oh I think I understand the parent better now: he is the author of app X, and someone releases X' which is X with bogus libs/ads/etc with the Enterprise Cert.
The user of X' reports bugs to him/her as if it was legit X running, so he gets reports that don't really come from his/her app.
Yes! Except usually the bug reporting is automatic, and nobody bothers to disable this behavior when modifying the apps.
That was my understanding, hence my question. I don't understand how such app can affect another app (which is what the parent was complaining about I think).
Also I'm confused as to why my question was downvoted... I'm a dev too who's released a few sandboxed apps (on iOS and macOS) and would like to understand if there is a vulnerability in the sandbox somewhere. Seems like this would be useful to understand for many devs.
No, there's no vulnerability in the sandbox. What is happening is that people are grabbing copies of an app, adding code to it (usually, by adding a new dynamic library and forcing the main binary to load it), and then distributing the modified app outside of the App Store. Any crashes in the modified app will still be reported to the original app developer, since aside from the small (or maybe not so small?) tweaks that were made the app functions like it normally would.
Aren't the crash-logging identity of the app, the sandboxing, the developer's identity and the code signing certificate all locked together?
I'm pretty sure everything is just linked to the bundle identifier.