4 ms·

Hey all, I'm the founder of SourceDNA and happy to answer any questions about how we found this or about binary code search in general. We take a different app

Hey all, I'm the founder of SourceDNA and happy to answer any questions about how we found this or about binary code search in general. We take a different approach to understanding code than the traditional antivirus world. Rather than try to hunt for a needle in a haystack, we've created a system for finding anomalies in code that's already published. For example, you can build a set of signatures for "bad apps" and then repeatedly search for them (AV model) or you can profile what makes an app "good" and then look for clusters of apps that deviate from it (SourceDNA). Consider an ad SDK like Youmi here. They weren't always scraping this private data from your phone. There are some apps that have this library but that version is a typical, only sorta intrusive, ad network. But, over time, they began adding in these private API calls and obfuscating them. This change sticks out when you track the history of this code and compare to other libraries. There was more and more usage of dlopen/dlsym with string prep functions beforehand. This is quite different from other libraries, where they stick to more common syscalls. By looking for anomalies, we can be alerted to new trends, whatever the underlying cause. Then we dig into the code to try to figure out what it means, which is still often the hardest part. Still, being able to test our ideas against this huge collection of indexed apps makes it much easier to figure out what's really going on.

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 ago
  You'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...
anatari 11y ago
How did you get access to the binaries? I would think the AppStore requires a session and valid purchase in order to download. Or is this analysis based on binaries submitted by your users?
- NateLawson 11y ago
  We both download apps and scan apps developers upload to us.

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 ago
You'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...

anatari 11y ago

How did you get access to the binaries? I would think the AppStore requires a session and valid purchase in order to download. Or is this analysis based on binaries submitted by your users?

NateLawson 11y ago
We both download apps and scan apps developers upload to us.