Hacker News Reader

Comment by ajasmin | Hacker News Reader

Didn't Apple have some rules preventing apps from downloading code from the Internet?

They allow data to be downloaded, and they allow web content (HTML + JavaScript) to be downloaded. Hence, it's possible to use a combination of native-interfaced templating and sandboxed JavaScript (i.e. "put native button with title n here and attach it to this JS action") to make native-feeling downloaded apps.

Presumably these restrictions are designed so that the only code which hasn't been through their static analysis tool is sandboxed, and they trust their JS sandbox to keep the JS where it belongs. Just like most of the Apple restrictions, it's pretty arbitrary in practice, because their "prevent private API usage" static analyzer is not very good (Camera+ was able to use restricted APIs simply by invoking a selector constructed via interpolation).

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

1. Otherwise, it would be dynamic analysis.

You 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).

Twitter for Mac also does this to call private things on Snow Leopard.

https://github.com/twitter/twui/blob/master/lib/UIKit/TUIScr...

They do, but this isn't really downloading 'code'. "Apps that download code in any way will be rejected", but you're not downloading it: you're executing JavaScript, which is totally permissible.

To put it another way: this idea isn't unique, although the packaging might be - there are several frameworks that do similar things (some proprietary internal tools, similar to how this seems to have started) with live apps on the store.

Actually I think the rule is more like - the only scripting is javascript and it must be downloaded and executed by a UIWebkit view.

Reply on news.ycombinator.com