What makes a private api private? Is it merely undocumented, but still usable in the exact same way as a "public" api? I.e., in my code I invoke it like normal, but I just need to know the name?
Or do I have to fiddle with the compiled code of my app to get it to call the instruction location of the otherwise invisible function?
If they were meant to be private, why can't the app, which surely runs in some underpriviledged mode, be blocked from calling the function, which knows it itself is privileged?
They are usually undocumented/internal calls, not necessarily privileged.
They can't be blocked that easily because the public APIs will necessarily call the private APIs at some point internally in order to implement their functionality.
The main reason private API calls are not allowed by Apple is that it would introduce a lot of app breakage when updating iOS versions. Either that or Apple would need to manually add hacks to account for specific apps that are misbehaved. (What Microsoft usually does for important/popular apps)
Security-sensitive calls do require special permissions from the Operating System, which is usually granted on a process-per-process basis. (Which is why we only got JIT compilation in WebViews recently, once the WebView process was separated from the App process thanks to WebKit2)
During the review phase of the App Store submission, Apple will use static analysis tools to figure out if the App is calling the private APIs. Some people have successfully used dynamic execution techniques to game that, to some extent. F.lux attempted to bypass the review issue entirely by shipping their app as an Xcode project, so you could manually compile it and install on your iOS device, but got a Cease and Desist from Apple IIRC.
I've read somewhere that Apple has started to take extra measures to further disallow calling private APIs starting on 9.3, but I'm not sure on the details.
For objective c on osx generally "private" means: we didn't put it in the header file, but you can obviously dump out that information and glean what functions do what.
Then because objective c function calls are just message passing, you can send that off.
It is no real different than C in this regard, private means just that it isn't publicly exported. It also generally means it could go away or change with an os update. So they tend to break often as they're generally ending up as public apis that apple doesn't yet want to commit to.
To block things from using the api means you would be checking every call site invocation. Not really possible with the message passing style of objective c.
Even if it is running as a user you would have to do something like:
function () {
if !allowed_uid()
dunno segfault
else
ok cool do things
}
That whole process would use up needless energy or ram which on a mobile why bother, just tell people to stop using private apis and kick them out if they do.
Strictly speaking, a private API is a callable function which is not documented as a public API. If you expose an API to the user/customer, you have to decide which functions are supposed to be called and for those public functions document them. As soon as you declare a function "public" you also have to make certain guarantees about them working, and ensure they continue to work as intended into the future.
Private functions are residing in the same libraries as the public ones, so depending on the language used, it takes a little bit more or less effort to find out about them and call them, but they are not intended to be used from the outside. Often enough, it is just because no one wants to document them or guarantee for future compatibility. But private functions are not as rigorously tested as public ones, or not for all use cases. Also, the caller can only guess how they are supposed to work, this directly leads to security implications, the call could screw up or just crash the device. So it is quite understandable, that calling private functions is discouraged by software companies.
Apple forbids the usage of private APIs in their app store guidelines. f.lux worked around this "limitation" by loading the binary code which did the private calls after being installed by the user - which is also against the app store guidelines. So they overstepped the rules on two accounts which caused the ban.
It's not documented or in the public headers. Meaning you do have to do a bit of fiddling in your app, but that just amounts to using reflection to use the API.
Just because an API is private doesn't mean it's privileged. Indeed, many once private APIs have later become public. Apple does scan the binaries that are uploaded for private API use, effectively banning them from the store.
One of the main reasons for banning use of private APIs is that those are usually in flux. They're not release worthy, and the last thing any platform maker, be they Apple, Google, or Microsoft, wants, is for a private change to break a bunch of 3rd party apps. These private APIs might also be doing things that they don't want just anyone to be able to do.
What makes a private api private? Is it merely undocumented, but still usable in the exact same way as a "public" api? I.e., in my code I invoke it like normal, but I just need to know the name?
Or do I have to fiddle with the compiled code of my app to get it to call the instruction location of the otherwise invisible function?
If they were meant to be private, why can't the app, which surely runs in some underpriviledged mode, be blocked from calling the function, which knows it itself is privileged?