Researched by William Spires and Stephen Jensen.
Just five short years ago, if you wanted to create an iOS application, you had to either take a crash course in Objective-C programming or hire someone to create the application for you. It was truly the beginning of a mobile revolution, and people wanted to jump on the bandwagon. However, with limited skills (and funds) how could the average .NET/Java/etc. programmer leverage his skills to create mobile applications? He couldn’t - he was forced to learn a completely new language. He had to learn the syntax and all of the various nuances of that new language and then, maybe, just maybe, within a couple of months, he might be close to actually developing a functional, albeit simple, mobile application.
Fast-forward a couple of years and we now see the mobile development market inundated with a multitude of mobile development platforms, covering the gamut of programming languages. No longer are you confined to Objective-C. Know Ruby? Great -you can develop mobile apps using the Rhodes Mobile framework. Know .NET? Perfect - you can create apps using Xamarin, and the list goes on and on. Enterprises no longer have to specifically hire Objective-C programmers. Now they can utilize the various programming skills of their current development staff to create robust, highly functional mobile applications.
On a technical level, it’s the desire of every mobile pentester, and every attacker for that matter, to get to the heart of a mobile application. It’s an adaptive process, as very few mobile applications are engineered exactly the same. The ultimate goal is to pull back the curtain and see what’s going on behind the scenes.
One part of a mobile pentester’s methodology involves file system analysis. This is where we start analyzing all of the application files, resources, dependencies, etc. that are stored locally on the device. We come across various common file types on the system, including property list files, databases, etc. During our assessment we located, via the applications Info.plist file, a key that identified the application as being built using the Kony mobile framework. The key looked like this:
As we continued looking at the file system we identified, as seen in Figure #1, a “JSScripts” directory that contained a file called, “app_script.js”.
Attempting to open the app_script.js file in a normal text editor revealed nothing, as seen in Figure #2 below.
It was obvious this file was being protected for some unknown reason. Our next step involved reversing the application binary to determine what it was doing with this file. First, we used Doxygen and Graphviz to generate a call-flow graph of all method calls, as seen in Figure #3, so we could get a high level understanding of the inner workings of the Kony app framework.
We then loaded the application into IDA Pro to start narrowing down the methods that were handling the app_script.js file, as seen in Figure #4. Our analysis led us to several methods within the JSScriptLoader class:
What tipped us off about this class in particular was that the “contentsOfJSScriptsDirectory” method, besides having a method name that was self-explanatory, also contained a call to “contentsOfDirectoryAtPath:error:” from the NSFileManager class. This appears to search the contents of the JSScripts path, which was the parent directory containing our suspicious “app_script.js” file.
Figure #5 shows the disassembly of the “+[JSScriptLoader contentsOfJSScriptsDirectory]” method.
We also used class_dump_z to dump the headers of the iOS binary. After searching through the various methods and header files, we identified a JSScriptLoader.h header file, seen in Figure #6, which contained various script related method calls.
Having identified these methods within the header file, our next step was to create a Theos mobile substrate tweak, using Theos’ logify.pl script, as seen in Figure #7, which would allow us to log the behavior of these method calls to see exactly what they were doing.