Termux ID: iOS -->

    Social Items

Home / iOS

BootStomp is a boot-loader bug finder. It looks for two different class of bugs: memory corruption and state storage vulnerabilities. For more info please refer to the BootStomp paper at https://seclab.cs.ucsb.edu/academic/publishing/#bootstomp-security-bootloaders-mobile-devices-2017
To run BootStomp's analyses, please read the following instructions. Note that BootStomp works with boot-loaders compiled for ARM architectures (32 and 64 bits both) and that results might slightly vary depending on angr and Z3's versions. This is because of the time angr takes to analyze basic blocks and to Z3's expression concretization results.

Directory structure
  • analysis: Contains analysis results (Ex: IDA idbs etc) of boot images of different devices.
  • tools: Contains tools that can be used to work with various images.

Pre-requisites
$ pip install angr

How to run it

Run BootStomp using docker
The easiest way to use BootStomp is to run it in a docker container. The folder docker contains an appropriate Dockerfile. These are the commands to use it.
cd docker
# build the docker image
docker build -t bootstomp .
# run the docker image (if you need, use proper options to have persistent changes or shared files)
docker run -it bootstomp

# now you are inside a docker container
cd BootStomp
# run BootStomp's taint analysis on one of the examples
# this will take about 30 minutes
python taint_analysis/bootloadertaint.py config/config.huawei
# the last line of the output will be something like:
# INFO    | 2017-10-14 01:54:10,617 | _CoreTaint | Results in /tmp/BootloaderTaint_fastboot.img_.out

# you can then "pretty print" the results using:
python taint_analysis/result_pretty_print.py /tmp/BootloaderTaint_fastboot.img_.out
The output should be something like this:
...
17)
===================== Start Info path =====================
Dereference address at: 0x5319cL
Reason: at location 0x5319cL a tainted variable is dereferenced and used as address.
...
Tainted Path 
----------------
0x52f3cL -> 0x52f78L -> 0x52f8cL -> 0x52fb8L -> 0x52fc8L -> 0x52fecL -> 0x53000L -> 0x53014L -> 0x5301cL -> 0x53030L -> 0x53044L -> 0x53050L -> 0x5305cL -> 0x53068L
===================== End Info path =====================
# Total sinks related alerts: 5
# Total loop related alerts: 8
# Total dereference related alerts: 4

Run BootStomp manually

Automatic detection of taint sources and sinks
  1. Load the boot-loader binary in IDA (we used v6.95). Depending on the CPU architecture of the phone it has been extracted from, 32 bit or 64 bit IDA is needed.
  2. From the menu-bar, run File => Script file => find_taint.py
  3. Output will appear in the file taint_source_sink.txt under the same directory as the boot-loader itself.

Configuration file
Create a JSON configuration file for the boot-loader binary (see examples in config/), where:
  • bootloader: boot-loader file path
  • info_path: boot-loader source/sink info file path (i.e., taint_source_sink.txt )
  • arch: architecture's number of bits (available options are 32 and 64)
  • enable_thumb: consider thumb mode (when needed) during the analysis
  • start_with_thumb: starts the analysis with thumb mode enabled
  • exit_on_dec_error: stop the analysis if some instructions cannot be decoded
  • unlock_addr: unlocking function address. This field is necessary only for finding insecure state storage vulnerabilities.

Finding memory corruption vulnerabilities
Run
python bootloadertaint.py config-file-path
Results will be stored in /tmp/BootloaderTaint_[boot-loader].out, where [boot-loader] is the name of the analyzed boot-loader. Note that paths involving loops might appear more than once.

Finding insecure state storage vulnerability
Run
python unlock_checker.py config-file-path
Results will be stored in /tmp/UnlockChecker_[boot-loader].out, where [boot-loader] is the name of the analyzed boot-loader. Note that paths involving loops might appear more than once.

Checking results
To check BootStomp results, use the script result_pretty_print.py, as follows:
python result_pretty_print.py results_file

Exploit for CVE-2017-2729

Other references


BootStomp - A Bootloader Vulnerability Finder


objection is a runtime mobile exploration toolkit, powered by Frida. It was built with the aim of helping assess mobile applications and their security posture without the need for a jailbroken or rooted mobile device.
The project's name quite literally explains the approach as well, whereby runtime specific objects are injected into a running process and executed using Frida.
Note: This is not some form of jailbreak / root bypass. By using objection, you are still limited by all of the restrictions imposed by the applicable sandbox you are facing.

features
Supporting both iOS and Android and having new features and improvements added regularly as the tool is used in real world scenarios, the following is a short list of only a few key features:
For all supported platforms, objection allows you to:
  • Patch iOS and Android applications, embedding a Frida gadget that can be used with objection or just Frida itself.
  • Interact with the filesystem, listing entries as well as upload & download files where permitted.
  • Perform various memory related tasks, such as listing loaded modules and their respective exports.
  • Attempt to bypass and simulate jailbroken or rooted environments.
  • Discover loaded classes and list their respective methods.
  • Perform common SSL pinning bypasses.
  • Dynamically dump arguments from methods called as you use the target application.
  • Interact with SQLite databases inline without the need to download the targeted database and use an external tool.
  • Execute custom Frida scripts.
iOS specific features in objection include the ability to:
  • Dump the iOS keychain, and export it to a file.
  • Dump data from common storage such as NSUserDefaults and the shared NSHTTPCookieStorage.
  • Dump various formats of information in human readable forms.
  • Bypass certain forms of TouchID restrictions.
  • Watch for method executions by targeting all methods in a class, or just a single method.
  • Monitor the iOS pasteboard.
  • Dump encoded .plist files in a human readable format without relying on external parsers.
Android specific features in objection include the ability to:
  • List the applications Activities, Services and Broadcast receivers.
  • Start arbitrary Activities available in the target application.
  • Watch a class method, reporting execution as it happens.

screenshots
The following screenshots show the main objection repl, connected to a test application on both an iPad running iOS 10.2.1, and Samsung Galaxy S5 running Android 6.

A file system listing of the iOS applications main bundle


A file system listing of the Android applications bundle


iOS Keychain dumped for the current application, and later written to a file called keychain.json


Inline SQLite query tool


SSL Pinning bypass running for an iOS application


SSL Pinning bypass running for an Android application


sample usage
A sample session, where objection version 0.1 is used to explore the applications environment. Newer versions have the REPL prompt set to the current applications name, however usage has remained the same:



prerequisites
To run objection, all you need is the python3 interpreter to be available. Installation via pip should take care of all of the dependencies needed. For more details, please see the prerequisites section on the project wiki.
As for the target mobile applications though, for iOS, an unencrypted IPA is needed and Android just the normal APK should be fine. If you have the source code of the iOS application you want to explore, then you can simply embed and load the FridaGadget.dylib from within the Xcode project.

installation
Installation is simply a matter of pip3 install objection. This will give you the objection command.
For more detailed update and installation instructions, please refer to the wiki page here.


objection - Runtime Mobile Exploration

Subscribe to: Posts (Atom)