3 ms·
Apple's static analyzer will catch you if you import/include private framework headers, but it can't stop you from sending messages to private framework objects
by pkghost 15y ago
Apple's static analyzer will catch you if you import/include private framework headers, but it can't stop you from sending messages to private framework objects that are sitting around at runtime because it's a dynamically typed language, which means it resolves method calls at runtime, and static analysis can't touch runtime[1].
http://www.youtube.com/watch?v=otCpCn0l4Wo#t=21s http://www.youtube.com/watch?v=otCpCn0l4Wo#t=21s
1. Otherwise, it would be dynamic analysis.
- bri3d 15y agoYou can easily detect most trivial methods of performing direct message sends to private framework objects via static analysis - both the name of the class and the message are used as string data. You can even find a naive message send using strings and grep, regardless of the use or non-use of a header! The use of the header is irrelevant - using [NSClassFromString(@"WebView") _enableRemoteInspector]; is going to show up the same way in a static analysis tool regardless of whether I made a WebView.h header defining +(void) enableRemoteInspector; or not - it compiles to the exact same thing! You have to be at least one level more clever to defeat Apple's static analysis tool - it looks at the values of the objc_msgSend's message only. Hence, using methodForSelector defeats it - the static analyzer sees a "methodForSelector" message (which isn't blacklisted), ignores the parameters, and then sees a straight function call (also not blacklisted).