MARA Framework - How it all started...
For the past few months, i have been digging into the Android Operating system to understand its inner workings and how different elements are pieced together. I decided to start of with trying to understand how applications are developed and that didn't go so well. I tried to learn java and well, lets just say i didn't have the patience and required consistency to learn. So i decided to start by learning the Android architecture. This was very confusing at first considering i was an avid Blackberry user. I hadn't owned an Android phone for about 3 to 4 years.
I decided to start of with Android forensics, because i thought it would give me a basic understanding of the Android file system and the various libraries and processes. This turned out to be a solid approach and soon is was scouring through an Android phone i had access to. I scavenged through it to extract and examine apps,files and the data i could find. I didn't use any forensic tools at this point, just simple, old fashioned, manual forensics to better understand where certain data is located and how to extract it.
I soon developed interest in android applications as it seemed like a point of familiarity. The first step was to understand the components of an android application, then later how the operating system executes it, what data is stored, where its stored and who had access to it.
Every Android reverse engineering blog post i read, gave somewhat similar tools on decompiling android applications. Dex2jar, apktool, JD GUI and baksmali were the most commonly mentioned tools. After successful reverse engineering the next steps were the static and dynamic analysis which also had another horde of tools that assist do the job.
It soon started to become quite frustrating on having to run various tools to get different output. For example, running dex to jar to convert the android application (apk) into a jar file or converting the apk into smali bytecode using baksmali. This process was not only inconvenient and slow, but i could only reverse engineer and study one app at a time. At this point in time my good friend Chrispus was also facing the same challenges on reverse engineering android apps.
So what now? Well, we decided to download all the Android application reverse engineering tools we could our hands on and try figure out which ones were the most reliable in terms of the provided output and easy to use. In a few weeks of tests, we had a list of tools that became our standard go to tools for the android application reverse engineering. While this was great, we still had two main challenges. We had to run all the tools individually to get the output we needed and we still, could only analyze one app at a given time.
At this point we decided to write a script that would allow us to automate the android application reverse engineering process. This took a couple of weeks and we were done. We could reverse engineer one application at a time or multiple application in a specified folder.
This was great but we faced yet another challenge. We now had the reverse engineered application,and what was to follow was the static analysis. After a bit of googling we came across MobSF. Its an awesome tool that performs both static and dynamic analysis of both Android and iOS applications. After downloading the tool from github and poking around in it, we found the strings it was using to perform the static analysis, and that was when we had the light bulb moment.
We figured, why don't we use the same strings to perform the static analysis but dumping the identified matches to a text file for review. First thing first, was to ask Ajin, the creator of MobSF for permission to use the detection strings, of which he obliged. What crossed our minds next was the OWASP mobile top 10, We wanted to figure out which checks are supposed to be performed on an mobile application in accordance to OWASP mobile security threats. We then came across the list of mobile app checklist on the OWASP website for both static and dynamic analysis. This was simply like finding gold to us.
We decided to integrate the static analysis strings from MobSF in line with the OWASP checks into our reverse engineering script. We wanted to begin with the OWASP top 10 as the main focus then include all the other 91 checks progressively. After a few months of bash scripting, the simple reverse engineering script morphed into the MARA framework. A tool that decompiles android application, java classes, dex file and class files into java class files, then proceeds to statically analyze them.
We included androbugs to scan for potential vulnerabilities in the apk, alongside a number of other tools. There is also an integrated SSL scanner for scanning domains extracted from the resulting source code. This was nothing more than a script to make our work easier, faster and more efficient.
We saw the potential of the tool to assist not only mobile application developers but also mobile app penetration testers in analyzing mobile applications. So we uploaded it here on github for any developer or pentester to make use of and contribute to its development.
It currently only supports static analysis of Android applications but within the next few months we intend to integrate iOS mobile application reverse engineering and static analysis support alongside dynamic analysis of android applications. The MARA framework is fairly easy to setup and use. The wiki highlights its decencies and the installation procedure.
In the next follow up blog post, i will give an overview of the MARA Framework setup process and how it can expedite your android app reverse engineering and static analysis process. I'll also dive into the mobile app pentest methodology that i use to try and identify potential vulnerabilities and insecure coding practices in android apps.
