mptteam's picture

Researched by William Spires and Stephen Jensen.

That Was Then, This is Now

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.

This post will focus on a well-known mobile development framework called Kony. Kony mobile apps can be created in either the Lua or JavaScript scripting languages. We will focus on Kony mobile applications created using JavaScript, and demonstrate how easily, given a certain skill level, these applications can be reverse engineered.

Technically Speaking

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”.

Figure #1


Attempting to open the app_script.js file in a normal text editor revealed nothing, as seen in Figure #2 below.

Figure #2

Content of app_script.js file Content of app_script.js file

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.

Figure #3

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:

Figure #4

Content of JSScriptLoader.h header file Content of JSScriptLoader.h header file

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.

Figure #5

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.

Figure #6

Content of JSScriptLoader.h header file Content of JSScriptLoader.h header file

Having identified these methods within the header file, our next step was to create a Theos mobile substrate tweak, using Theos’ 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.

Figure #7

Tweak.xm file created by Theos’ script Tweak.xm file created by Theos’ script

Once we compiled and installed the mobile substrate tweak, we launched the application and watched the console log the activity. Immediately, we discovered the “evaluateScript” method was dumping what appeared to be huge amounts of JavaScript code. After a couple of hours of trial and error, and a crash course in Objective-C programming, we modified our Tweak.xm mobile substrate file and wrote some custom code, as seen in Figure #8, that would run in conjunction with the original code within the “evaluateScript” method.

Figure #8

The custom code shown above first creates a JSFiles directory within the Documents folder of the application. Next it utilizes the parameters, “script” and “fileName” that are passed to the method to create a JavaScript file using the “fileName” parameter as the name of the file. The code then writes the value stored, the actual executing JavaScript in this case, within the “script” parameter into the newly created JavaScript file.

After compiling and installing the updated mobile substrate tweak and launching the application, we confirmed the JSFiles directory had been created and within that directory there were 112 newly created JavaScript files, as seen in Figure #9.

Figure #9

New JavaScript files created from custom code New JavaScript files created from custom code

Upon opening these newly created JavaScript files, we were presented with the actual functional code the application executed. In a nutshell, the custom code that we wrote within the mobile substrate tweak dumped the raw executing source code of the application, as seen in Figure #10.

Figure #10

At the end of the assessment, we knew the internal workings of the application, and were able to easily identify potential vulnerabilities within the JavaScript source code.

We did identify other Kony JS mobile applications that contained the “app_scripts.js” file, as well as the “JSScriptLoader.h” header file. However, the header file did not contain the exact same methods mentioned above. This difference may be the result of a refactoring of the code by the Kony framework. Your mileage in reversing Kony JavaScript mobile applications may differ.

Comments (1)

Aaron Bryson | December 21, 2015 4:07 pm

Thank you William Spires and Stephen Jensen for your research this is a great analysis of one of our older versions of the platform. Much has changed in our software since this was published and your analysis was performed.

As your article states, "That Was Then, This is Now", I invite you to learn about the security in our modern Mobile Application Development Platform (MADP) and Mobile Backend-as-a-service (MBaaS).

Please Post Your Comments & Reviews

Your email address will not be published. Required fields are marked *

Love to learn about Application Security?

Get all the latest news, tips and articles delivered right to your inbox.