Termux ID: Analysis -->

    Social Items

Home / Analysis

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


Fuzzer for Linux Kernel Drivers

Tested on
Ubuntu >= 14.04.5 LTS
As explained in our paper, There are two main components of difuze: Interface Recovery and Fuzzing Engine

1. Interface Recovery
The Interface recovery mechanism is based on LLVM analysis passes. Every step of interface recovery are written as individual passes. Follow the below instructions on how to get the Interface Recovery up and running.

1.1 Setup
This step takes care of installing LLVM and c2xml:
First, make sure that you have libxml (required for c2xml):
sudo apt-get install libxml2-dev
Next, We have created a single script, which downloads and builds all the required tools.
cd helper_scripts
python setup_difuze.py --help
usage: setup_difuze.py [-h] [-b TARGET_BRANCH] [-o OUTPUT_FOLDER]

optional arguments:
  -h, --help        show this help message and exit
  -b TARGET_BRANCH  Branch (i.e. version) of the LLVM to setup. Default:
                    release_38 e.g., release_38
  -o OUTPUT_FOLDER  Folder where everything needs to be setup.
Example:
python setup_difuze.py -o difuze_deps
To complete the setup you also need modifications to your local PATH environment variable. The setup script will give you exact changes you need to do.

1.2 Building
This depends on the successful completion of Setup. We have a single script that builds everything, you are welcome.
cd InterfaceHandlers
./build.sh

1.3 Running
This depends on the successful completion of Build. To run the Interface Recovery components on kernel drivers, we need to first the drivers into llvm bitcode.

1.3.1 Building kernel
First, we need to have a buildable kernel. Which means you should be able to compile the kernel using regular build setup. i.e., make. We first capture the output of make command, from this output we extract the exact compilation command.

1.3.1.1 Generating output of make (or makeout.txt)
Just pass V=1 and redirect the output to the file. Example:
make V=1 O=out ARCH=arm64 > makeout.txt 2>&1
NOTE: DO NOT USE MULTIPLE PROCESSES i.e., -j. Running in multi-processing mode will mess up the output file as multiple process try to write to the output file.
That's it. Next, in the following step our script takes the generated makeout.txt and run the Interface Recovery on all the recognized drivers.

1.3.2 Running Interface Recovery analysis
All the various steps of Interface Recovery are wrapped in a single script helper_scripts/run_all.py How to run:
cd helper_scripts
python run_all.py --help

usage: run_all.py [-h] [-l LLVM_BC_OUT] [-a CHIPSET_NUM] [-m MAKEOUT]
                  [-g COMPILER_NAME] [-n ARCH_NUM] [-o OUT]
                  [-k KERNEL_SRC_DIR] [-skb] [-skl] [-skp] [-skP] [-ske]
                  [-skI] [-ski] [-skv] [-skd] [-f IOCTL_FINDER_OUT]

optional arguments:
  -h, --help           show this help message and exit
  -l LLVM_BC_OUT       Destination directory where all the generated bitcode
                       files should be stored.
  -a CHIPSET_NUM       Chipset number. Valid chipset numbers are:
                       1(mediatek)|2(qualcomm)|3(huawei)|4(samsung)
  -m MAKEOUT           Path to the makeout.txt file.
  -g COMPILER_NAME     Name of the compiler used in the makeout.txt, This is
                       needed to filter out compilation commands. Ex: aarch64
                       -linux-android-gcc
  -n ARCH_NUM          Destination architecture, 32 bit (1) or 64 bit (2).
  -o OUT               Path to the out folder. This is the folder, which could
                       be used as output directory during compiling some
                       kernels.
  -k KERNEL_SRC_DIR    Base directory of the kernel sources.
  -skb                 Skip LLVM Build (default: not skipped).
  -skl                 Skip Dr Linker (default: not skipped).
  -skp                 Skip Parsing Headers (default: not skipped).
  -skP                 Skip Generating Preprocessed files (default: not
                       skipped).
  -ske                 Skip Entry point identification (default: not skipped).
  -skI                 Skip Generate Includes (default: not skipped).
  -ski                 Skip IoctlCmdParser run (default: not skipped).
  -skv                 Skip V4L2 ioctl processing (default: not skipped).
  -skd                 Skip Device name finder (default: not skipped).
  -f IOCTL_FINDER_OUT  Path to the output folder where the ioctl command
                       finder output should be stored.
The script builds, links and runs Interface Recovery on all the recognized drivers, as such it might take considerable time(45 min-90 min).
The above script performs following tasks in a multiprocessor mode to make use of all CPU cores:

1.3.2.1 LLVM Build
  • Enabled by default.
All the bitcode files generated will be placed in the folder provided to the argument -l. This step takes considerable time, depending on the number of cores you have. So, if you had already done this step, You can skip this step by passing -skb.

1.3.2.2 Linking all driver bitcode files in s consolidated bitcode file.
  • Enabled by default
This performs linking, it goes through all the bitcode files and identifies the related bitcode files that need to be linked and links them (using llvm-link) in to a consolidated bitcode file (which will be stored along side corresponding bitcode file).
Similar to the above step, you can skip this step by passing -skl.

1.3.2.3 Parsing headers to identify entry function fields.
  • Enabled by default.
This step looks for the entry point declarations in the header files and stores their configuration in the file: hdr_file_config.txt under LLVM build directory.
To skip: -skp

1.3.2.4 Identify entry points in all the consolidated bitcode files.
  • Enabled by default
This step identifies all the entry points across all the driver consolidated bitcode files. The output will be stored in file: entry_point_out.txt under LLVM build directory.
Example of contents in the file entry_point_out.txt:
IOCTL:msm_lsm_ioctl:/home/difuze/kernels/pixel/msm/sound/soc/msm/qdsp6v2/msm-lsm-client.c:msm_lsm_ioctl.txt:/home/difuze/pixel/llvm_out/sound/soc/msm/qdsp6v2/llvm_link_final/final_to_check.bc
IOCTL:msm_pcm_ioctl:/home/difuze/kernels/pixel/msm/sound/soc/msm/qdsp6v2/msm-pcm-lpa-v2.c:msm_pcm_ioctl.txt:/home/difuze/pixel/llvm_out/sound/soc/msm/qdsp6v2/llvm_link_final/final_to_check.bc
To skip: -ske

1.3.2.5 Run Ioctl Cmd Finder on all the identified entry points.
  • Enabled by default.
This step will run the main Interface Recovery component (IoctlCmdParser) on all the entry points in the file entry_point_out.txt. The output for each entry point will be stored in the folder provided for option -f.
To skip: -ski

1.4 Example:
Now, we will show an example from the point where you have kernel sources to the point of getting Interface Recovery results.
We have uploaded a mediatek kernel 33.2.A.3.123.tar.bz2. First download and extract the above file.
Lets say you extracted the above file in a folder called: ~/mediatek_kernel

1.4.1 Building
cd ~/mediatek_kernel
source ./env.sh
cd kernel-3.18
# the following step may not be needed depending on the kernel
mkdir out
make O=out ARCH=arm64 tubads_defconfig
# this following command copies all the compilation commands to makeout.txt
make V=1 -j8 O=out ARCH=arm64 > makeout.txt 2>&1

1.4.2 Running Interface Recovery
cd <repo_path>/helper_scripts

python run_all.py -l ~/mediatek_kernel/llvm_bitcode_out -a 1 -m ~/mediatek_kernel/kernel-3.18/makeout.txt -g aarch64-linux-android-gcc -n 2 -o ~/mediatek_kernel/kernel-3.18/out -k ~/mediatek_kernel/kernel-3.18 -f ~/mediatek_kernel/ioctl_finder_out
The above command takes quite some time (30 min - 1hr).

1.4.3 Understanding the output
First, all the analysis results will be in the folder: ~/mediatek_kernel/ioctl_finder_out (argument given to the option -f), for each entry point a .txt file will be created, which contains all the information about the recovered interface.
If you are interested in information about just the interface and don't care about anything else, We recommend you use the parse_interface_output.py script. This script converts the crazy output of Interface Recovery pass into nice json files with a clean and consistent format.
cd <repo_path>/helper_scripts
python parse_interface_output.py <ioctl_finder_out_dir> <output_directory_for_json_files>
Here <ioctl_finder_out_dir> should be same as the folder you provided to the -f option and <output_directory_for_json_files> is the folder where the json files should be created.
You can use the corresponding json files for the interface recovery of the corresponding ioctl.

1.4.4 Things to note:

1.4.4.1 Value for option -g
To provide value for option -g you need to know the name of the *-gcc binary used to compile the kernel. An easy way to know this would be to grep for gcc in makeout.txt and you will see compiler commands from which you can know the *-gcc binary name.
For our example above, if you do grep gcc makeout.txt for the example build, you will see lot of lines like below:
aarch64-linux-android-gcc -Wp,-MD,fs/jbd2/.transaction.o.d  -nostdinc -isystem ...
So, the value for -g should be aarch64-linux-android-gcc.
If the kernel to be built is 32-bit then the binary most likely will be arm-eabi-gcc
For Qualcomm (or msm) chipsets, you may see *gcc-wrapper.py instead of *.gcc, in which case you should provide the *gcc-wrapper.py.

1.4.4.2 Value for option -a
Depeding on the chipset type, you need to provide corresponding number.

1.4.4.3 Value for option -o
This is the path of the folder provided to the option O= for make command during kernel build.
Not all kernels need a separate out path. You may build kernel by not providing an option O, in which case you SHOULD NOT provide value for that option while running run_all.py.

1.5 Post Processing
Before we can begin fuzzing we need to process the output a bit with our very much research quality (sorry) parsers.
These are found here. The main script to run will be run_all.py:
$ python run_all.py --help
usage: run_all.py [-h] -f F -o O [-n {manual,auto,hybrid}] [-m M]

run_all options

optional arguments:
  -h, --help            show this help message and exit
  -f F                  Filename of the ioctl analysis output OR the entire
                        output directory created by the system
  -o O                  Output directory to store the results. If this
                        directory does not exist it will be created
  -n {manual,auto,hybrid}
                        Specify devname options. You can choose manual
                        (specify every name manually), auto (skip anything that
                        we don't identify a name for), or hybrid (if we
                        detected a name, we use it, else we ask the user)
  -m M                  Enable multi-device output most ioctls only have one
                        applicable device node, but some may have multiple. (0
                        to disable)
You'll want to pass -f the output directory of the ioctl analysis e.g. ~/mediatek_kernel/ioctl_finder_out.
-o Is where you where to store the post-processed results. These will be easily digestible XML files (jpits).
-n Specifies the system to what degree you want to rely on our device name recovery. If you don't want to do any work/name hunting, you can specify auto. This of course comes at the cost of skipping any device for which we don't recover a name. If you want to be paranoid and not trust any of our recovery efforts (totally reasonable) you can use the manual option to name every single device yourself. hybrid then is a combination of both -- we will name the device for you when we can, and fall back to you when we've failed.
-m Sometimes ioctls can correspond to more than one device (this is common with v4l2/subdev ioctls for example). Support for this in enabled by default, but it requires user interaction to specify the numberof devices for each device. If this is too annoying for you, you can disable the prompt by passing -m 0 (we will assume a single device for each ioctl).
After running, you should have, in your out folder, a folder for each ioctl.

2 Fuzzing

2.1 Mango Fuzz
MangoFuzz is our simple prototype fuzzer and is based off of Peach (specifically MozPeach).
It's not a particularly sophisticated fuzzer but it does find bugs. It was also built to be easily expandable. There are 2 components to this fuzzer, the fuzz engine and the executor. The executor can be found here, and the fuzz engine can be found here.

2.1.1 Executor
The executor runs on the phone, listening for data that the fuzz engine will send to it.
Simply compile it for your phones architecture, adb push it on to the phone, and execute with the port you want it to listen on!

2.1.2 Fuzz Engine
Interfacing with MangoFuzz is fairly simple. You'll want an Engine object and a Parser object, which you'll feed your engine into. >From here, you parse jpits with your Parser, and then run the Engine. Easy! We've provided some simple run scripts to get you started.
To run against specific drivers you can use runner.py on one of the ioctl folders in the output directory (created by our post processing scripts).
e.g. ./runner.py -f honor8/out/chb -num 1000. This tells MangoFuzz to run for 1000 iterations against all ioctl command value pairs pertaining to the chb ioctl/driver.
If instead we want to run against an entire device (phone), you can use dev_runner.py. e.g. ./dev_runner.py -f honor8/out -num 100. This will continue looping over the driver files, randomly switching between them for 100 iterations each.
Note that before the fuzz engine can communicate with the phone, you'll need to use ADB to set up port forwarding e.g. adb forward tcp:2022 tcp:2022


difuze - Fuzzer for Linux Kernel Drivers


DR.CHECKER: A Soundy Vulnerability Detection Tool for Linux Kernel Drivers

Tested on
Ubuntu >= 14.04.5 LTS

1. Setup
The implementation is based on LLVM, specifically LLVM 3.8. We also need tools like c2xml to parse headers.
First, make sure that you have libxml (required for c2xml):
sudo apt-get install libxml2-dev
Next, We have created a single script, which downloads and builds all the required tools.
cd helper_scripts
python setup_drchecker.py --help
usage: setup_drchecker.py [-h] [-b TARGET_BRANCH] [-o OUTPUT_FOLDER]

optional arguments:
  -h, --help        show this help message and exit
  -b TARGET_BRANCH  Branch (i.e. version) of the LLVM to setup. Default:
                    release_38 e.g., release_38
  -o OUTPUT_FOLDER  Folder where everything needs to be setup.
Example:
python setup_drchecker.py -o drchecker_deps
To complete the setup you also need modifications to your local PATH environment variable. The setup script will give you exact changes you need to do.

2. Building
This depends on the successful completion of Setup. We have a single script that builds everything, you are welcome.
cd llvm_analysis
./build.sh

3. Running
This depends on the successful completion of Build. To run DR.CHECKER on kernel drivers, we need to first convert them into llvm bitcode.

3.1 Building kernel
First, we need to have a buildable kernel. Which means you should be able to compile the kernel using regular build setup. i.e., make. We first capture the output of make command, from this output we extract the exact compilation command.

3.1.1 Generating output of make (or makeout.txt)
Just pass V=1 and redirect the output to the file. Example:
make V=1 O=out ARCH=arm64 > makeout.txt 2>&1
NOTE: DO NOT USE MULTIPLE PROCESSES i.e., -j. Running in multi-processing mode will mess up the output file as multiple process try to write to the output file.
That's it. DR.CHECKER will take care from here.

3.2 Running DR.CHECKER analysis
There are several steps to run DR.CHECKER analysis, all these steps are wrapped in a single script helper_scripts/runner_scripts/run_all.py How to run:
python run_all.py --help
usage: run_all.py [-h] [-l LLVM_BC_OUT] [-a CHIPSET_NUM] [-m MAKEOUT] [-g COMPILER_NAME] [-n ARCH_NUM] [-o OUT] [-k KERNEL_SRC_DIR] [-skb] [-skl] [-skp] [-ske] [-ski] [-f SOUNDY_ANALYSIS_OUT]

optional arguments:
  -h, --help            show this help message and exit
  -l LLVM_BC_OUT        Destination directory where all the generated bitcode files should be stored.
  -a CHIPSET_NUM        Chipset number. Valid chipset numbers are:
                        1(mediatek)|2(qualcomm)|3(huawei)|4(samsung)
  -m MAKEOUT            Path to the makeout.txt file.
  -g COMPILER_NAME      Name of the compiler used in the makeout.txt, This is
                        needed to filter out compilation commands. Ex: aarch64-linux-android-gcc
  -n ARCH_NUM           Destination architecture, 32 bit (1) or 64 bit (2).
  -o OUT                Path to the out folder. This is the folder, which
                        could be used as output directory during compiling
                        some kernels. (Note: Not all kernels needs a separate out folder)
  -k KERNEL_SRC_DIR     Base directory of the kernel sources.
  -skb                  Skip LLVM Build (default: not skipped).
  -skl                  Skip Dr Linker (default: not skipped).
  -skp                  Skip Parsing Headers (default: not skipped).
  -ske                  Skip Entry point identification (default: not
                        skipped).
  -ski                  Skip Soundy Analysis (default: not skipped).
  -f SOUNDY_ANALYSIS_OUT    Path to the output folder where the soundy analysis output should be stored.
The script builds, links and runs DR.CHECKER on all the drivers, as such might take considerable time(45 min-90 min). If you want to run DR.CHECKER manually on individual drivers, refer standalone
The above script performs following tasks in a multiprocessor mode to make use of all CPU cores:

3.2.1. LLVM Build
  • Enabled by default.
All the bitcode files generated will be placed in the folder provided to the argument -l. This step takes considerable time, depending on the number of cores you have. So, if you had already done this step, You can skip this step by passing -skb.

3.2.2. Linking all driver bitcode files in s consolidated bitcode file.
  • Enabled by default
This performs linking, it goes through all the bitcode files and identifies the related bitcode files that need to be linked and links them (using llvm-link) in to a consolidated bitcode file (which will be stored along side corresponding bitcode file).
Similar to the above step, you can skip this step by passing -skl.

3.2.3.Parsing headers to identify entry function fields.
  • Enabled by default.
This step looks for the entry point declarations in the header files and stores their configuration in the file: hdr_file_config.txt under LLVM build directory.
To skip: -skp

3.2.4.Identify entry points in all the consolidated bitcode files.
  • Enabled by default
This step identifies all the entry points across all the driver consolidated bitcode files. The output will be stored in file: entry_point_out.txt under LLVM build directory.
Example of contents in the file entry_point_out.txt:
FileRead:hidraw_read:/home/drchecker/33.2.A.3.123/llvm_bc_out/drivers/hid/llvm_link_final/final_to_check.bc
FileWrite:hidraw_write:/home/drchecker/33.2.A.3.123/llvm_bc_out/drivers/hid/llvm_link_final/final_to_check.bc
IOCTL:hidraw_ioctl:/home/drchecker/33.2.A.3.123/llvm_bc_out/drivers/hid/llvm_link_final/final_to_check.bc
To skip: -ske

3.2.5.Run Soundy Analysis on all the identified entry points.
  • Enabled by default.
This step will run DR.CHECKER on all the entry points in the file entry_point_out.txt. The output for each entry point will be stored in the folder provided for option -f.
To skip: -ski

3.2.6 Example:
Now, we will show an example from the point where you have kernel sources to the point of getting vulnerability warnings.
We have uploaded a mediatek kernel 33.2.A.3.123.tar.bz2. First download and extract the above file.
Lets say you extracted the above file in a folder called: ~/mediatek_kernel

3.2.6.1 Building
cd ~/mediatek_kernel
source ./env.sh
cd kernel-3.18
# the following step may not be needed depending on the kernel
mkdir out
make O=out ARCH=arm64 tubads_defconfig
# this following command copies all the compilation commands to makeout.txt
make V=1 -j8 O=out ARCH=arm64 > makeout.txt 2>&1

3.2.6.2 Running DR.CHECKER
cd <repo_path>/helper_scripts/runner_scripts

python run_all.py -l ~/mediatek_kernel/llvm_bitcode_out -a 1 -m ~/mediatek_kernel/kernel-3.18/makeout.txt -g aarch64-linux-android-gcc -n 2 -o ~/mediatek_kernel/kernel-3.18/out -k ~/mediatek_kernel/kernel-3.18 -f ~/mediatek_kernel/dr_checker_out
The above command takes quite some time (30 min - 1hr).

3.2.6.3 Understanding the output
First, all the analysis results will be in the folder: ~/mediatek_kernel/dr_checker_out (argument given to the option -f), for each entry point a .json file will be created which contains all the warnings in JSON format. These json files contain warnings organized by contexts.
Second, The folder ~/mediatek_kernel/dr_checker_out/instr_warnings (w.r.t argument given to the option -f) contains warnings organized by instruction location.
These warnings could be analyzed using our Visualizer.
Finally, a summary of all the warnings for each entry point organized by the type will be written to the output CSV file: ~/mediatek_kernel/dr_checker_out/warnings_stats.csv (w.r.t argument given to the option -f).

3.2.7 Things to note:

3.2.7.1 Value for option -g
To provide value for option -g you need to know the name of the *-gcc binary used to compile the kernel. An easy way to know this would be to grep for gcc in makeout.txt and you will see compiler commands from which you can know the *-gcc binary name.
For our example above, if you do grep gcc makeout.txt for the example build, you will see lot of lines like below:
aarch64-linux-android-gcc -Wp,-MD,fs/jbd2/.transaction.o.d  -nostdinc -isystem ...
So, the value for -g should be aarch64-linux-android-gcc.
If the kernel to be built is 32-bit then the binary most likely will be arm-eabi-gcc

3.2.7.2 Value for option -a
Depeding on the chipset type, you need to provide corresponding number.

3.2.7.3 Value for option -o
This is the path of the folder provided to the option O= for make command during kernel build.
Not all kernels need a separate out path. You may build kernel by not providing an option O, in which case you SHOULD NOT provide value for that option while running run_all.py.

3.3 Visualizing DR.CHECKER results ❄️
We provide a web-based UI to view all the warnings. Please refer Visualization.

3.6 Disabling Vulnerability checkers
You can disable one or more vulnerability checkers by uncommenting the corresponding #define DISABLE_* lines in BugDetectorDriver.cpp

3.5 Post-processing DR.CHECKER results
To your liking, we also provide a script to post-process the results. Check it out.
Have fun!!


DR.CHECKER - A Soundy Vulnerability Detection Tool for Linux Kernel Drivers

What this tool does is taking a file (any type of file), encrypt it, and embed it into an HTML file as ressource, along with an automatic download routine simulating a user clicking on the embedded ressource.

Then, when the user browses the HTML file, the embedded file is decrypted on the fly, saved in a temporary folder, and the file is then presented to the user as if it was being downloaded from the remote site. Depending on the user's browser and the file type presented, the file can be automatically opened by the browser.

This tool comes in two flavors, providing the same overall functionnality but with some slight changes in the way of using it:
  1. An python script which generates the output HTML file based on a template, using RC4 encryption routines, and embedding the decryption key within the output file. The resulting HTML can either be browsed by the targeted user or sent as an attachement.
  2. An HTML/Javascript that you can drag the file into be encrypted to, which generates the output HTML file, using the WebCrypto API, but NOT embedding the decryption material (key and counter). Instead, the decryption material is displayed as a set of URL parameters to be added into a URL pointing to the HTML resulting file: 
    http(s)://hosting.server.com/result.html#hexencodedkey!hexencodedcounter
    . So the resulting HTML file cannot be sent as an attachment. The main advantage of this technique is that the decryption material is not embedded into the file itself, hence preventing analysis and even retrieval of the payload by any system which doesn't have the full URL (eg: intercepting proxy)
Side notes:

Usage
Few payload examples files are provided in the payloads_examplesdirectory. For instance the
calc.xllis an Excel add-in (XLL) file that contains a metasploit shellcode for x86 processes to launch the calc.exeprocess.

Using the python script
1/ Generate the malicious html file from the XLL file, along with a secret key: 
python embedInHTML.py -k mysecretkey -f example_calc.xll -o index.html

2/ Expose the html file on a web server (one can be optionnaly started for you with the-w flag)

Using the HTML/Javascript
1/ Open the embedInHTML.html file within a browser
2/ Simply drag the payload file into the page (you can optionnaly change the output file name)
3/ Save the resulting file and take note of the decryption material as URL parameters to be added to the file name in the form: 
http(s)://hosting.server.com/result.html#hexencodedkey!hexencodedcounter

Eventually...
Point the target's browser to the html file and let the magic happen:



EmbedInHTML - Embed and hide any file in an HTML file


IP-Biter is an open source, easy to deploy, tracking framework that generate high configurables and uniques tracking images and links to embed in e-mails, sites or chat systems and visualize, in an hacker-friendly dashboard, high detailed reports of the tracked users who visualize the image or open the links.

Features
  • Very high configurable tracking image generation
  • Tracking links generation
  • Tracking hided and not recognizable from the target point of view
  • Integrated Dashboard
  • Self-tracking prevention
  • Possibility to stop and start the tracking at any time
  • Possibility to hide the Dashboard and protect its access with a password
  • Live tracking reports from the Dashboard
  • Tracking reports live delivered to a configurable mail address
  • Different IP analysis services
  • User-Agent analysis service
  • Integrate URL shortening service
  • AllInOne PHP file
  • No need for a Database
  • Open Source
...and many many more!
Give it a try!

Getting Started

Access the Dashboard
  1. Access the dashboard through ipb.php?op=$dashboardPage (or through ipb.php if $dashboardPage=='')
    • If $dashboardPageSecret!='' then a login page will appear asking for the $dashboardPageSecret value

Create a new configuration
  1. When the dashboard is opened without parameters, a new configuration is created
    • Another empty new configuration can be generate clicking the "New" button
  2. Configure the tracking image and the advanced setting if needed
    • It is possible to left the original image url empty. In this case an empty image will be used.
  3. Add tracking links if needed
    • It is possible to left the original link empty. In this case the link will generate a 404 page.
  4. Save the configuration
  5. Distribute the generated image or the links to start the tracking
    • You can click the copy button and paste in a html rich email editor like gmail
    • NOTE: If you try to open the generated image or links but have in the same browser the dashboard page opened and loaded, your request will not be tracked (self-tracking prevention feature)

Load an existing configuration
  1. When the dashboard is opened with the parameter "uuid", the associated configuration is loaded
    • Another configuration can be loaded pasting the "Track UUID" in the dashboard relative field and clicking the "Load" button
  2. The reports will be automatically visualized in the "Tracking Reports" section of the dashboard

Security Notes
  • Change the folders name and the dashboard page in the configuration section in order to improve the security
  • Add the following lines to the .htaccess file in order to deny the access to the "configs" and "reports" folders:
DirectoryIndex ipb.php
<IfModule mod_rewrite.c>
    RewriteEngine On
    RewriteRule ^(configs/|reports/) - [F]
</IfModule>

Live DEMO
Have a look at the DEMO (notifications limited at 50 mail/day and 1h/day downtime expected)


IP-Biter - The Hacker-friendly E-Mail Tracking Framework


PortEx is a Java library for static malware analysis of Portable Executable files. Its focus is on PE malformation robustness, and anomaly detection. PortEx is written in Java and Scala, and targeted at Java applications.

Features
  • Reading header information from: MSDOS Header, COFF File Header, Optional Header, Section Table
  • Reading standard section formats: Import Section, Resource Section, Export Section, Debug Section, Relocations
  • Dumping of sections, resources, overlay, embedded ZIP, JAR or .class files
  • Scanning for file anomalies, including structural anomalies, deprecated, reserved, wrong or non-default values.
  • Visualize a PE file structure as it is on disk and visualize the local entropies of the file
  • Automatic repair of PE files
  • Calculate Shannon Entropy for files and sections
  • Calculate hash values for files and sections
  • Scan for PEiD signatures or your own signature database
  • Scan for Jar to EXE wrapper (e.g. exe4j, jsmooth, jar2exe, launch4j)
  • Extract Unicode and ASCII strings contained in the file
  • Overlay detection and dumping
  • Extraction of ICO files from resource section
  • Extraction of version information from the file
For more information have a look at PortEx Wiki and the Documentation

PortExAnalyzer
PortExAnalyzer is a command line tool that runs the library PortEx under the hood. If you are looking for a readily compiled command line PE scanner to analyse files with it, download it from here PortexAnalyzer.jar

Using PortEx

Including PortEx to a Maven Project
You can include PortEx to your project by adding the following Maven dependency:
<dependency>
   <groupId>com.github.katjahahn</groupId>
   <artifactId>portex_2.10</artifactId>
   <version>2.0.8</version>
</dependency>
To use a local build, add the library as follows:
<dependency>
   <groupId>com.github.katjahahn</groupId>
   <artifactId>portex_2.10</artifactId>
   <version>2.0.8</version>
   <scope>system</scope>
   <systemPath>$PORTEXDIR/target/scala-2.10/portex_2.10-2.0.6.jar</systemPath>
</dependency>

Including PortEx to an SBT project
Add the dependency as follows in your build.sbt
libraryDependencies += "com.github.katjahahn" % "portex_2.10" % "2.0.2"

Building PortEx

Requirements
PortEx is build with sbt

Compile and Build With sbt
To simply compile the project invoke:
$ sbt compile
To create a jar:
$ sbt package
To compile a fat jar that can be used as command line tool, type:
$ sbt assembly

Create Eclipse Project
You can create an eclipse project by using the sbteclipse plugin. Add the following line to project/plugins.sbt:
addSbtPlugin("com.typesafe.sbteclipse" % "sbteclipse-plugin" % "2.4.0")
Generate the project files for Eclipse:
$ sbt eclipse
Import the project to Eclipse via the Import Wizard.

Author and Contact
Karsten Hahn (previously Katja Hahn)
E-Mail: portx (at) gmx (dot) de


PortEx - Java library to analyse Portable Executable files with a special focus on malware analysis and PE malformation robustness

This small script will simulate fake processes of analysis, sandbox and/or VM software that some malware will try to avoid. You can download the original script (made by @x0rz ) in the orig directory.

You can also download my slightly optimized script in the main directory. The file is named fsp.ps1.

Script-Features
  • Some (good) spyware will stop spying on you as long as the processes run, which are created by this script.
  • Requirements: Powershell (preinstalled on Win 7 and newer)
  • Runs on every Windows since Vista
  • Tiny size
  • No CPU load
  • Easy to use
  • No network connection required

Installer-Features
  • Automatically install the script to your autostart directory
  • Extremely easy to install
  • Uninstaller to purge all files
  • NO requirements
  • Tiny size
  • Offline package
  • Automatic updater included - only if you want!

Usage:
Open the command line and paste this command (don't forget to adjust the path!):
Powershell -executionpolicy remotesigned -File "Your\Path\fsp.ps1"
After pressing ENTER you will be asked to either start or stop all processes.

Autostart
If you execute the powershell script with the above command, you will have to rerun it after every login or startup. In order to autostart the script I made an easy-to-use installer.
  • Download the fsp-installer.bat file from the release section.
  • Double-click it.
  • Now you will see this cmd window:

  • Choose "i" to start the installer.
  • Now enter "y" to start installing or "n" to abort.
  • If you entered "y" this image will now pop up:

  • Enter "y" to install the auto-updater or "n" to not install it (it'll work anyways, but it is recommended to install the updater).
You can now close the window or press any key to close it. The (un)installation is complete.

Uninstall
If you no longer want this program on your computer, you'll need the fsp-installer.bat file again. Run it and chose "u" to start the uninstallation process. Then enter "y" if you are ready to uninstall it.


If the process was successful, you'll see a confirmation screen.

Successfully tested on the following Windows versions:
  • Win 10 Professional
  • Win 8.1 Home
  • Win 7 Professional


Fake Sandbox Processes (FSP) - Tool to simulate fake processes of analysis sandbox/VM software


This tool is designed to manipulate FAT filesystems, in order to explore, extract, repair, recover and forensic them. It currently supports FAT12, FAT16 and FAT32.
Tutorials & examples

Building and installing
You can build fatcat this way:
mkdir build
cd build
cmake ..
make
And then install it:
make install

Exploring

Using fatcat
Fatcat takes an image as argument:
fatcat disk.img [options]
You can specify an offset in the file with -O, this could be useful if there is multiple partitions on a block devices, for instance:
fatcat disk.img -O 1048576 [options]
This will tell fatcat to begin on the 1048576th byte. Have a look to the partition tutorial.

Listing
You can explore the FAT partition using -l option like this:
$ fatcat disk.img -l /
Listing path /
Cluster: 2
d 24/10/2013 12:06:00  some_directory/                c=4661
d 24/10/2013 12:06:02  other_directory/               c=4662
f 24/10/2013 12:06:40  picture.jpg                    c=4672 s=532480 (520K)
f 24/10/2013 12:06:06  hello.txt                      c=4671 s=13 (13B)
You can also provide a path like -l /some/directory.
Using -L, you can provide a cluster number instead of a path, this may be useful sometime.
If you add -d, you will also see deleted files.
In the listing, the prefix is f or d to tell if the line concerns a file or a directory.
The c= indicates the cluster number, s= indicates the site in bytes (which should be the same as the pretty size just after).
The h letter at the end indicates that the file is supposed to be hidden.
The d letter at the end indicates that the file was deleted.

Reading a file
You can read a file using -r, the file will be wrote on the standard output:
$ fatcat disk.img -r /hello.txt
Hello world!
$ fatcat disk.img -r /picture.jpg > save.jpg
Using -R, you can provide a cluster number instead of a path, but the file size information will be lost and the file will be rounded to the number of clusters it fits, unless you provide the -s option to specify the file size to read.
You can use -x to extract the FAT filesystem directories to a directory:
fatcat disk.img -x output/
If you want to extract from a certain cluster, provide it with -c.
If you provide -d to extract, deleted files will be extracted too.

Undelete

Browsing deleted files & directories
As explaines above, deleted files can be found in listing by providing -d:
$ fatcat disk.img -l / -d
f 24/10/2013 12:13:24  delete_me.txt                  c=5764 s=16 (16B) d
You can explore and spot a file or an interesting deleted directory.

Retrieving deleted file
To retrieve a deleted file, simply use -r to read it. Note that the produced file will be read contiguously from the original FAT system and may be broken.

Retreiving deleted directory
To retrieve a deleted directory, note its cluster number and extract it like above:
# If your deleted directory cluster is 71829
fatcat disk.img -x output/ -c 71829
See also: undelete tutorial

Recover

Damaged file system
Assuming your disk has broken sectors, you may want to do recovering on it.
The first advice is to make a copy of your data using ddrescue, and save your disk to another one or into a sane file.
When sectors are broken, their bytes will be replaced with 0s in the ddrescue image.
A first way to go is trying to explore your image using -l as above and check -i to find out if fatcat recognizes the disk as a FAT system.
Then, you can try to have a look at -2, to check if the file allocation tables differs, and if it looks mergeable. It is very likely that is will be mergeable, in this case, you can try -m to merge the FAT tables, don't forget to backup it before (see below).

Orphan files
When your filesystem is broken, there are files and lost files and lost directories that we call "orphaned", because you can't reach them from the normal system.
fatcat provides you an option to find those nodes, it will do an automated analysis of your system and explore allocated sectors of your filesystem, this is done with -o.
You will get a list of directories and files, like this:
There is 2 orphaned elements:
Directory clusters 4592 to 4592: 2 elements, 49B
File clusters 4611 to 4611: ~512B
You can then use directly -L and -R to have a look into those files and directories:
$ fatcat disk.img -L 4592
Listing cluster 4592
Cluster: 4592
d 23/10/2013 17:45:06  ./                             c=4592
d 23/10/2013 17:45:06  ../                            c=0
f 23/10/2013 17:45:22  poor_orphan.txt                c=4601 s=49 (49B)
Note that orphan files have an unknown size, this mean that if you read it, you will get a file that is a multiple of the cluster sizes.
See also: orphaned files tutorial

Hacking
You can use fatcat to hack your FAT filesystem

Informations
The -i flag will provide you a lot of information about the filesystem:
fatcat disk.img -i
This will give you headers data like sectors sizes, fats sites, disk label etc. It will also read the FAT table to estimate the usage of the disk.
You can also get information about a specific cluster by using -@:
fatcat disk.img -@ 1384
This will give you the cluster address (offset of the cluster in the filesystem) and the value of the next cluster in the two FAT tables.

Backuping & restoring FAT
You can use -b to backup your FAT tables:
fatcat disk.img -b backup.fats
And use -p to write it back:
fatcat disk.img -p backup.fats

Writing to the FATs
You can write to the FAT tables with -w and -v:
fatcat disk.img -w 123 -v 124
This will write 124 as value of the next cluster of 123.
You can also choose the table with -t, 0 is both tables, 1 is the first and 2 the second.

Diff & merge the FATs
You can have a look at the diff of the two FATs by using -2:
# Watching the diff
$ fatcat disk.img -2
Comparing the FATs

FATs are exactly equals

# Writing 123 in the 500th cluster only in FAT1
$ fatcat disk.img -w 500 -v 123 -t 1
Writing next cluster of 500 from 0 to 123
Writing on FAT1

# Watching the diff
$ fatcat disk.img -2
Comparing the FATs
[000001f4] 1:0000007b 2:00000000

FATs differs
It seems mergeable
You can merge two FATs using -m. For each different entries in the table, if one is zero and not the other, the non-zero file will be choosen:
$ fatcat disk.img -m
Begining the merge...
Merging cluster 500
Merge complete, 1 clusters merged
See also: fixing fat tutorial

Directories fixing
Fatcat can fix directories having broken FAT chaining.
To do this, use -f. All the filesystem tree will be walked and the directories that are unallocated in the FAT but that fatcat can read will be fixed in the FAT.

Entries hacking
You can have information about an entry with -e:
fatcat disk.img -e /hello.txt
This will display the address of the entry (not the file itself), the cluster reference and the file size (if not a directory).
You can add the flag -c [cluster] to change the cluster of the entry and the flag -s [size] to change the entry size.
See also: fun with fat tutorial
You can use -k to search for a cluster reference.

Erasing unallocated files
You can erase unallocated sectors data, with zeroes using -z, or using random data using -S.
For instance, deleted files will then become unreadables.


fatcat - FAT Filesystems Explore, Extract, Repair, And Forensic Tool

Subscribe to: Posts (Atom)