4 ms·

Objectiv-C works by sending a message to an object. If that object responds to the message, it does something. The message is essentially just a string and in f

Objectiv-C works by sending a message to an object. If that object responds to the message, it does something. The message is essentially just a string and in fact you can use strings to build selectors. Normally, these private API selectors would show up in a class dump and Apple will reject you app. But, if you're clever, you can hide them from a class dump. You could encrypt the strings, then decrypt them at runtime and Apple could no longer find your private API usage in a static scan. At runtime they could detect you calling private APIs, but it would be easy enough to code it so that you don't call any private APIs for a few days after first launch or make them so they're turned on with a server side flag. That way Apple would never notice the private api usage during an App Store review.

achr2 11y ago
The question is why don't these APIs require authorization in the first place? Obfuscation is a terrible security practice.
- josso 11y ago
  Because as soon as Apple publish something as an API, they can't change the method because third party apps could now be depending on it. As long as the API is private and undocumented, Apple can change the method from release to release as they see fit.
  - JupiterMoon 11y ago
    But what about making them private APIs that also require authorisation.
- NateLawson 11y ago
  Many do require this, but there are current sandbox limitations that make this harder to change quickly.
saurik 11y ago
Your same argument would stand without modification for reading all data from the keychain, accessing files saved by other applications, using your location, or any other things that require permissions: clearly, then, it is wrong on the face of it, because Apple has simply failed to secure a wide class of things from these processes. It honestly doesn't matter whether there is an "API" for it at the C or Objective-C layers, and that is a red herring: the issue is that there is an IPC layer somewhere (whether a Mach server or a file on disk) that exposes an API by which this data can be obtained by this process.
- NateLawson 11y ago
  Exactly right. What we expect to happen next is runtime generation of an XPC identifier to call the underlying service, replicating the behavior of the private API with none of its code. We're moving ahead with detecting this too as it's an obvious next step.

achr2 11y ago

The question is why don't these APIs require authorization in the first place? Obfuscation is a terrible security practice.

josso 11y ago
Because as soon as Apple publish something as an API, they can't change the method because third party apps could now be depending on it. As long as the API is private and undocumented, Apple can change the method from release to release as they see fit.
- JupiterMoon 11y ago
  But what about making them private APIs that also require authorisation.
NateLawson 11y ago
Many do require this, but there are current sandbox limitations that make this harder to change quickly.

saurik 11y ago

Your same argument would stand without modification for reading all data from the keychain, accessing files saved by other applications, using your location, or any other things that require permissions: clearly, then, it is wrong on the face of it, because Apple has simply failed to secure a wide class of things from these processes. It honestly doesn't matter whether there is an "API" for it at the C or Objective-C layers, and that is a red herring: the issue is that there is an IPC layer somewhere (whether a Mach server or a file on disk) that exposes an API by which this data can be obtained by this process.

NateLawson 11y ago
Exactly right. What we expect to happen next is runtime generation of an XPC identifier to call the underlying service, replicating the behavior of the private API with none of its code. We're moving ahead with detecting this too as it's an obvious next step.