4 ms·
One concern I have is that they'll just move this one step further down the road. For example, I believe that you can get the address of a function like dlopen(
by vitd 11y ago
One concern I have is that they'll just move this one step further down the road. For example, I believe that you can get the address of a function like dlopen() by manually loading the bundle and looking up the function name (via something like CFBundleGetFunctionPointerForName()), constructing the name "dlopen()" through some obfuscated method as they do with Objective-C symbols. Then it becomes harder to detect that they're even using dlopen(). Any plans on how to detect that? It seems like an arms race that can't easily be won.
- NateLawson 11y agoYou're exactly right. You can go even further in gathering environmental data from syscalls and using it to construct strings at runtime. At some point, you have to include dynamic analysis in addition to static analysis. The iRiS paper we mentioned in the blog post describes a really great approach to doing this. They do "forced execution" using a port of Valgrind to iOS. They also do the exact right thing by resolving as many call targets as possible statically, then using dynamic analysis only for the call sites that can't be resolved. This saves on runtime and complexity, though you might notice that even this approach didn't resolve 100% of them. Ultimately, you're dealing with a variant of the halting problem, where the app uses a specific value only on a full moon, on iOS 4.1, where the username is "sjobs". And that's why computers are still fun. PDF: http://www.cse.buffalo.edu/~mohaisen/classes/fall2015/cse709/docs/deng-ccs15.pdf http://www.cse.buffalo.edu/~mohaisen/classes/fall2015/cse709...