I only submit the binary file to Apple. I didn't submit any source code to Apple. Apart from manually check what you used. How Apple check what API you have called? How did Apple know?
+7
A:
I imagine they look at all symbols your binary's trying to import (info no doubt easily available to them in the symbol table thereof) and ding you if any of those symbols are found in their "private API list". Pretty easy to automate, in fact.
Alex Martelli
2010-05-16 02:09:52
+3
A:
A executable isn't exactly a black box. If you call out to a library, it's an easy thing to find. This is why I lament the loss of the assembly languages in modern CS educations. =] Tools like ldd will tell you what you have linked in, though I don't remember what incarnation of ldd made it to the mac iPhone dev kit.
I've frequently wondered: if you were to write your binary to self-modify, only generating the code to import a private API after some criteria had been met (say, after the publication date of your app) whether Apple would catch it. They certainly report back to us some interesting statistics, like the number of our games that are being run on jailbroken phones.
2010-05-16 02:21:51
@user30997, The privileged code can probably only be accessed through a system call; the executing thread switches into a higher privilege and checks if the previous privilege has permissions to execute the code or not. That's just an example though, there are other ways of doing it, but I _highly_ doubt the developers were naive enough to leave out a basic runtime privilege checking mechanism such as this, it would definately have been publicized by now.
Longpoke
2010-05-16 03:07:09
+1
A:
Even if you're statically linking, at worst, they could take samples of the code from the private APIs on their list, and search your binary against them (also relatively easy to automate).
Knowing Apple, I'd bet they have a comprehensive, automated system, and any uncertainty is probably either denied or reviewed manually.
End of the day, I think it's probably not worth the effort to try and fool Apple.
wash
2010-05-16 02:17:27
Knowing Apple their review process upon encountering any uncertainty involves breaking out a set of dice for maximum whimsy.
JUST MY correct OPINION
2010-05-16 10:18:36
+7
A:
1.
2.
3. Listing Objective-C selectors, or
There are 3 ways I know. These are just some speculation, since I do not work in the Apple review team.
1. otool -L
This will list all libraries the app has linked to. Something clearly you should not use, like IOKit and WebKit can be detected by this.
2. nm -u
This will list all linked symbols. This can detect
- Undocumented C functions such as _UIImageWithName;
- Objective-C classes such as UIProgressHUD
- Ivars such as
UITouch._phase(which could be the cause of rejection of Three20-based apps last few months.)
3. Listing Objective-C selectors, or strings
Objective-C selectors are stored in a special region of the binary, and therefore Apple could extract the content from there, and check if you've used some undocumented Objective-C methods, such as -[UIDevice setOrientation:].
Since selectors are independent from the class you're messaging, even if your custom class defines -setOrientation: irrelevant to UIDevice, there will be a possibility of being rejected.
You could use Erica Sadun's APIKit to detect potential rejection due to (false alarms of) private APIs.
(If you really really really really want to workaround these checks, you could use runtime features such as
- dlopen, dlsym
- objc_getClass, sel_registerName, objc_msgSend
-valueForKey:; object_getInstanceVariable, object_getIvar, etc.
to get those private libraries, classes, methods and ivars. )
KennyTM
2010-05-16 07:13:39
A:
Let's say you want to use some private API; objective C allows you to construct any SEL from a string:
SEL my_sel = NSSelectorFromString([NSString stringWithFormat:\
@"%@%@%@", "se","tOr","ientation:"]);
[UIDevice performSelector:my_sel ...];
How could a robot or library scan catch this? They would have to catch this using some tool that monitors private accesses at runtime. Even if they constructed such a runtime tool, it is hard to catch because this call may be hidden in some rarely exercised path.
Chris McLuvin
2010-05-25 16:43:53
A:
This desktop application, App Scanner, can scan .app files for private api usage by pulling apart the Mach-O Binary file. If it can, then Apple can too!
Andrew
2010-10-10 18:26:07