The BMa, 2015/04/15 10:09

0x00 AppUse – Overview

From:https://appsec-labs.com/wp-content/uploads/2014/10/appuse_userguide_v2-2.pdf

AppUse (Android Pentest Platform Unified Standalone Environment) is designed to act as an Android app penetration testing Platform. Android is an operating system for Android application penetration testers that includes a custom Android ROM loaded with hooks for viewing and manipulating applications at run time.

At the heart of AppUse is a customized “Hostile” Android ROM that contains a customized emulator-based runtime environment for security testing of applications. Using rootkit-like technology, many hooks are injected into the core of its execution engine so that the application can be easily manipulated, as observed by “ReFrameworker”.

AppUse includes any tools penetration testers need in order to run and test applications: Android emulators, development tools, SDKS, decomcompilers, disassemblers, etc. The AppUse environment is designed to be as intuitive as possible for all ordinary Android penetration testers and security researchers. It comes with the AppUse Dashboard — which allows users to control their entire environment from the UI. Install APK on the device or configure the emulator agent by pulling, decompilating, debugging, or manipulating binaries. Everything can be done with the click of a few buttons, making it easy to focus on all the necessary steps to focus on the most important issues.

Additionally, AppUse comes preloaded with many “Hack Me” apps, including their server. It is essential for penetration testers to have these applications when testing several new tools or technologies and for some purpose.

To sum up, AppUse is a collection of the following:

• Android Emulator • Hacking & reversing tools for Android • Development tools for Android • Custom “hostile” Android ROM loaded with hooks • ReFrameworker Android runtime manipulator • Vulnerable applications • The AppUse dashboard

0x01 AppUse- Operating System

AppUse is based on Linux Ubuntu and is already equipped with common attack tools to save time and improve efficiency.

certificate

Although AppUse automatically logs in to root, you’ll find it useful to find this data when the system interacts.

Terminal and command-line tools

Environment variables for these tools have been configured for Android security testers. The tools used in the study, such as ADB, have been pre-installed and configured. In addition, all research and attack tools are embedded in the PATH environment variable, so they can be accessed from anywhere on the terminal and can be completed automatically.

The new alias feature has many aliases added to terminals in Version AppUse >1.8 to help penetration testers work faster.

Signapk <apk name>

APK requires a signature to run on the device. Since modifying the APK will make the original APK signature invalid, the researcher needs to sign the APK. Can be located in/AppUse/Pentest SignAPK/sign. Sh SignAPK do, the script need parameters: [existing_apk], so the script will be in the current directory to create a named _signed. The apk signature apk, and delete the old signature apk

Alias: signapk < apk path > is to perform/AppUse/Pentest signapk/sign. Sh shorter way, so that the signature is modified apk file.

Figure 4: SignApk

Search <string>

The search alias is a Python script that uses bash to search for strings in files, which is useful when penetration testers search for a method name in files to get other strings.

Rootdevice Rootdevice is to perform/AppUse/Emulator/rooting/root. The fast way of sh root device.

Jdgui

Jdgui is a fast way to perform JD-gui.

The development tools

The AppUse environment includes Android development and debugging tools that make it easy to perform penetration tests for your applications. This environment comes preloaded with ECLIPSE and ADT for writing applications or EXps. In addition, the environment comes preloaded with IPYTHON, which makes it easy to develop Python scripts to help test in special scenarios.

AppUse directory structure

AppUse is located in the /AppUse directory, which contains a number of directories:

Android -- contains two directories, one containing SDK and the other containing the entire ReFrameworker platform.Emulator -- contains Emulator directories, such as sdcard, wallpaper, Rooting etc Logs -- containing AppUse Dashboard log file Pentest -- multiple directories containing test tools, Targets such as Burp, Apktool, JDgui, Mercury, dex2JAR, etc. -- the most important directory containing the target APK/ application data directory described in the following paragraphCopy the code

The Targets directory

The main goal of AppUse is to organize all the work of penetration testers. To achieve this goal, all work applied in AppUse will be stored in the same directory, the Targets directory. The Targets directory contains all target application directories and contains the output of all tools in the dashboard.

One of the features used in the reverse section or in the application data section, the target APK/APP data will be printed in the Targets directory under the target app. For example, if you decompiled appsec.dropboxPo-c 1.apk, the output would be saved at /AppUse/Targets/ appsec.dropboxpo-c -1/disassembled/

Pentest directory

AppUse is a growing project. A major goal is to always keep up with the latest tools that enable researchers to implement full coverage attacks on a given application. The AppUse directory structure contains the /Pentest directory, which contains all the tools. A brief view of the folder is as follows:

You may notice that not all tools are present in DashBorad. Dashboard has so many features that it can cover all researcher needs in standard research, and some are still under development and not yet embedded in Dashboard. AppUse won’t stop you from using these, because we know there are researchers who need them. All of these can be found in the /Pentest directory.

For example, APK Analyzer in action is shown below:

0x02 AppUse – Dashboard

An overview of the

Dashboard is the heart of the AppUse test environment. Dashboard, a GUI view that organizes the test tools and runtime environment, puts together all the data linked by various tools and saves valuable time in its special features, linking several actions together and further demonstrating them in documentation.

Double-click the link on your desktop to run the Dashboard and it will run immediately:

Structure:

Dashboard is divided into seven options, each with a specific purpose.

General:

In Dashboard, APK is the main component. The AppUse Dashboard is meant to allow researchers to start working with a single click. To accomplish this, Dashboards are designed to operate on APK to invoke its other actions.

Load APK

Load APK is the most basic operation. Load APK loads an APK from the file system into the Dashboard to make the Dashboard perform its actions. This is the first necessary action when starting an application research. The loaded APK will be copied to /AppUse/Targets/

/.

Install APK

After the user loads APK from the file system, the Install APK button will appear. This button allows penetration testers to install an APK into a running emulator. In case the application has already been installed, Dashboard asks whether to reinstall or uninstall the application and install it again.

Current equipment status

The device status picture shows the status of the currently connected devices. The AppUse VM turns green when the device is connected, the label is ON, red when no device is connected, and the note is OFF. It helps you avoid using the Check Device button for quick instructions when the Device is connected.

Help

The help image allows you to get information about the currently selected section. By clicking on it, the user guide for the current section of AppUse will open in the browser, which will help you understand the purpose of each button in the Dashboard.

Android Device implements the Android part to perform the actions on the emulator. Click to perform the following actions:

The Launch Emulator button is used to open the AppUse Emulator

The Restart ADB Restart ADB is used to Restart the ADB service so that AppUse can recognize the device in case the ADB server does not come up. An automatic mechanism is implemented in AppUse1.8 to check if the service is down and restart ADB.

Install Burp Certificate new feature

The Install Burp Certificate button allows AppUse to Install Burp certificates in the emulator, and in the next release it will Install Burp certificates whenever any device is connected to the AppUse VM.

Root permissions on the Root Device emulator come in handy for penetration testing, but are often time-consuming. AppUse Dashboard has a built-in option to automatically root the emulator with the click of a button.

Take Screenshot

Take Screenshot Screenshots, is used to implement the simulator Screenshots stored in the/AppUse/Emulator/Screenshots/directory

Open ADB shell

The Open ADB shell button is used to make it easier for penetration testers to Open the ADB SHLL terminal

Proxy Settings new feature

The Proxy Settings panel is used to make it easier for penetration testers to root devices and open proxies on devices. AppUse comes preloaded with application communication with Dashboard, allowing penetration testers to turn agents ON and OFF in the emulator by clicking ON/OFF. Setting up the proxy requires an IP and PORT, and another important feature is allowing you to determine the redirection PORT. In case the target application uses binary protocols, it may need to set specific ports or listen on all ports and interrupt binary protocol traffic. If the device does not have root, AppUse will automatically root.

The TOOLS section is designed to give penetration testers quick access to these useful TOOLS during testing. Click to perform the following operations:

Launch Burp Run the Burp agent

Launch Firefox Launch Firefox

Launch Wireshark AppUse The Wireshark is pre-installed and runs in dashboards.

Launch Eclipse Launches the Eclipse IDE

Launch NetBeans Run NetBeans 8.0 to debug applications

Launch IDA To disassemble the binaries

Launch Mercury Client Runs the Mercury Console client. After opening the service through Mercury Agent on the device, port forwarding is performed, and then the Mercury Console is opened. All operations can be done by clicking Launch Mercury Client

Launch SQLLite Browser Launch SQLLite Browser Launch SQLLite Browser to view database files

Launch JD-gui Launch JD-gui Run jD-gui and view the JAR file source code

Open Terminal Open Terminal Opens the shell and performs operations in the system

Download the app from Google Play because There is no Google in the emulator

Open AppUse Directory Open the AppUse Directory to view files and operations

Their Reversing AppUse includes state-of-the-art tools for decoding and Reversing APK. Once APK is loaded into the Dashboard, all the tools are configured and ready for direct use, enabling full coverage. The reverse part is used to perform things like pulling APK from the device, decompiling, disassembling, assembling, converting to APK mode, etc. This section will make the work faster by clicking to do the following:

Reverse APK Content is used to implement three actions: decompilation, disassembly, and unzip

Decompile (JD-GUI) JD-GUI is a framework for decompiling JAR files. Once the.dex files must be converted to.jar files, JD-GUI will be ready to take apart the code. Using JD-GUI, you can audit application source code to discover hidden secrets and logic. The Decompile button is used to help penetration testers Decompile the target APK, convert it to a JAR file using dex2Jar, and then view the source code using JD-GUI. All of this is done with the click of a button. AppUse will pull the APK, decomcompile it, and open the jar file of the target APK via JD-GUI.

Decompile (Luyten) does the same as the button above, but this opens the JAR file through Luyten Decompiler

Save Java Sources saves the Java source code of the target APK to the Decomcompiled directory of the target APK directory

Dissemble (Baksmali) Baksmali is a tool to Dissemble apk Dalvik bytecods. The researchers are able to look at the Dalvik encoding of the application and modify it with a human-readable format. This button is used to help penetration testers decompilate APK with multiple commands, all with one click: Once baksmali is used on the APK, the /AppUse/Targets/

/Dissasembled/ directory contains all Dalvik compiled code that the penetration testers can then modify and provide additional instructions

Reassemble(SMALI) Baksmali gives researchers access to human-readable Dalvik compiled code and the opportunity to edit it with any editor. Smali is a tool to complete the packaging code. With Smali, the researchers were able to change the compiled code of the application and repackage it as a new.dex file. Once the.dex file is applied to the APK file, these updates are patched and applied in real time once the APK is installed. Using this feature can take security research to a new level.

This button is a directory compiled and decomcompiled by Baksmali Dissasemble. After modifying the Smali code, you want to convert it to an APK file and install it. All of this can be done by clicking this button. AppUse will compile the decompile directory and create a signature APK.

This button will open the APK Manifest file. It will extract apK’s Menifest and open it in Firefox.

Debug Mode This button enables debugging of APK by automatically entering Debug Mode. With one click, the application will decompile APK, modify Menifest, recompile, and sign.

Open Target Directory This button opens the Target application’s Directory to view files and perform actions.

The Application Data section is the file used to access the target Application. Load APK Loads the application data directory to the list. You can filter the directory name. The penetration tester will select the directory of the target application from the list, and then click Load Folder to perform the action on the target directory. Click to perform the following operations:

View File is used to View files in the target application. After loading the directory into a tree, select a file and click cat file to view its contents.

Edit File is used to modify files in the target application. By clicking AppUse, the file will be pulled and opened in the editor. After modification and saving, it will be automatically pushed to the device.

Pull File/Folder is used to Pull files or directories from the target application. The tree view allows faster viewing and selection of files and directories.

Extract Databases is used to view database files. Instead of pulling the DB file and opening each one in the SQLLITE browser, clicking AppUse will pull the DB file and parse the database data into HTML through Doxygen, allowing it to view every table in every file.

You can Open the target App Data Directory, view files, and perform actions.

ReFrameworker

Launch ReFrameworker To run the ReFrameworker platform, described later in the documentation.

The Enable/Disable ReFrameworker command is used to replace JAR files and restart the emulator. Allows ReFramewoker to load hooks in the emulator.

To send messages to Reframeworker’s dashboard, it creates a Web request from the application to the Dashboard. If you send or proxy on Reframeworker’s dashboard and the application does not have Web request permissions, it will not work. This button gives the application temporary Internet rights.

The Vulnerable Apps training section is used to open the training application on the server, which might open HackMePal HTTP/S Servers, GoatDroid, ExploitMe.

Appuse-runtime Modifications and Inspection Via AppSec ReFrameworker The simulator in AppUse has been modified to meet the requirements of the penetration tester. It comes with a prefabricated ROM, preloaded with tools to interact with the system.

At the heart of AppUse is a custom Hostile Android ROM built specifically for app security testing that contains a modified real-time environment running custom emulators. With rootkit-like technology, many hooks are injected into the core of its execution engine, so the application can be easily manipulated and observed through a command & controller called ReFrameworker.

How It Works — an Overview The Android runtime configures a number of hooks in key parts of the code. These constructs look for a file called reframeworker.xml, which is located at /data/system. At each application run time, each time a checked runtime method is called, the ReFrameworker configuration file is loaded with the contained rules (“items”) and reacted accordingly. Managing configuration files with its rules is already done via the ReFrameworker Dashboard, which allows you to define a set of rules that Android will follow when it runs. This will generate a configuration file, which the runtime environment will then parse and execute. For example, it launches with a configuration file that can be local or directly connected to an Android device. After clicking the Load Config button, the panel marks all loaded rules and allows the user to enable/disable or configure them,

After the file is loaded, the panel marks all defined rules in bold, and marks which rules are used in green.

The user can then choose the behavior of the runtime. For example, you can turn on sniffing for important messages, bypass some logic, perform string substitutions, send data to the ReFrameworker dashboard, and so on.

The user can then save the configuration of the row. If the user chooses to save to the device, the device is immediately able to follow these rules.

You can configure the behavior of each rule by clicking on the target of the rule, selecting configuration from the submenu,

A new window appears containing the value of the rule. Each rule has the following properties:

• Name -- The Name of the rule • Enabled -- is it Enabled? • Calling method -- The name of the Runtime method upon which this rule should apply • Mode -- can have 3 possible values - Send, Proxy, Or Modify o Send -- Send the hooked content to the ReFrameworker dashboard o Proxy - let the user control the value of The hooked content by using a proxy-like UI o Modify -- replace a particular content with another content • Value -- Specify the condition for the hooked content. An asterisk (*) means "always." • toValue - Specify the action for the Hooked content. An asterisk (*) means "always."Copy the code

The following is an example of a configuration rule:

Here is the configuration file after the new rule is generated. The following is an example of reframeworker.xml configuration:

The idea here is to turn this file into a fidgety run at a particular place where our hook is able to find it. File path is: / data/system/Reframeworker. Dynamic parsing XML — so that hooks in the process of the injection will, loading and execution, we may submit them on the outside of the Android devices.

Since the device can communicate with Dashboard, Dashboard includes a listener that listens for incoming communication connections from the device. Therefore, dashboard has a listener button:

When the listener is turned on, Dashboard is ready to accept any incoming messages. AppUse also has some advanced features that let users interrupt internal messages from internal Android objects. We can do this by creating a proxy between the Android application and the runtime environment. This is a very similar approach to implementing HTTP proxies, but only at a very low level within the Android runtime.

The AppUse environment is compiled with a number of hooks in key places. As part of the research, after finding interesting areas that we want to control, such as file processing, communication, encryption, etc., we put them in the ReFrameworker Controller. The controller checks to see if any rules are defined for this particular location and if they work as configured.

For example, as part of our research to find interesting places to insert hooks, we decided to insert hooks into SQLiteDatabase’s executeSql, where all requests will go through executeSql. Inserting hooks into this class enables us to end all SQL requests sent from the application to the local DB. Our hook will interrupt all values and execute all instructions in the configuration file.

Hooks are usually placed in important values, so if a rule is defined for a particular hook, the controller can do anything with it. The controller can do nothing, send data to a remote location, allow the user to modify the value in real time, or automatically replace it with another value.

For example, this is a preloaded hook that hooks the SQL parameters of the excuteSql method. The actual query will be executed through the runtime environment as an indication of the higher-level application.

Assume that the related configuration rules have been defined as proxies. The device now sends data to the agent each time it calls this method and replaces the original value with the modified value received.

What you need to do in the dashboard is to operate the proxy:

When a message is received, the proxy wakes up and lets the user observe and modify the message. The Android app waits for a response as it works.

Configuration examples

Example #1– Send the values of all executed commands to Dashboard

Explanation – Set to send when we want to send data, the value is, which means we want to send all commands. ToValue is not used in this scenario, but is also set to. Calling Method is set to the method that is checked.

Example #2 — Send all values to Dashboard for executing SQL requests

Explanation: Calling Method is set to a special method related to the SQL query, otherwise the values remain the same.

Example #3 –proxy (break and modify) all executed SQL request values to dashboard

Explanation: Since we want to change the data in real time, set Method to proxy and keep the other values the same.

Example #4 — Trust all certificates

Explanation: Since we want to replace all hooked values (especially Boolean values regardless of whether the certificate trusts them or not). Since we want to replace all values, value is set to *. Since you want to always trust certificates, toValue is set to true. Method Sets the approximate hooked method.

Example #5 — Disable hostname identification

Explanation: Quite similar to the previous example. The only difference is that the calling method has a value of Hostname verification

Example #6 — Replace the IMEI of the mobile phone with another value

Explanation: Since we want to replace the data, mode is set to modify, value is set to * to replace all values, toValue is set to 11111111 as we want in this example, callingMethod is similar to hooked method.

Example #7 —   the proxy (break and modify) is the value phone IMEI number

Explanation: Since we want to change the data in real time, set mode to Proxy and keep all other values the same.

Of course, this is only a very brief introduction to ReFrameworker, and the rules that AppUse can manage, each with many different Settings.