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

A pattern based Dalvik deobfuscator which uses limited execution to improve semantic analysis. Also, the inspiration for another Android deobfuscator: Simplify.

Before

After

sha1: a68d5d2da7550d35f7dbefc21b7deebe3f4005f3
md5: 2dd2eeeda08ac8c15be8a9f2d01adbe8

Installation

Step 1. Install Smali / Baksmali
Since you're an elite Android reverser, I'm sure you already have Smali and Baksmali on your path. If for some strange reason it's not already installed, this should get you started, but please examine it carefully before running:
mkdir ~/bin || cd ~/bin
curl --location -O https://bitbucket.org/JesusFreke/smali/downloads/smali-2.1.2.jar && mv smali-*.jar smali.jar
curl --location -O https://bitbucket.org/JesusFreke/smali/downloads/baksmali-2.1.2.jar && mv baksmali-*.jar baksmali.jar
curl --location -O https://bitbucket.org/JesusFreke/smali/downloads/smali
curl --location -O https://bitbucket.org/JesusFreke/smali/downloads/baksmali
chmod +x ./smali ./baksmali
export PATH=$PATH:$PWD

Step 2. Install Android SDK / ADB
Make sure adb is on your path.

Step 3. Install the Gem
gem install dex-oracle
Or, if you prefer to build from source:
git clone https://github.com/CalebFenton/dex-oracle.git
cd dex-oracle
gem install bundler
bundle install

Step 4. Connect a Device or Emulator
You must have either an emulator running or a device plugged in for Oracle to work.
Oracle needs to execute methods on an live Android system. This can either be on a device or an emulator (preferred). If it's a device, make sure you don't mind running potentially hostile code on it.
If you'd like to use an emulator, and already have the Android SDK installed, you can create and start emulator images with:
android avd

Usage
Usage: dex-oracle [opts] <APK / DEX / Smali Directory>
    -h, --help                       Display this screen
    -s ANDROID_SERIAL,               Device ID for driver execution, default=""
        --specific-device
    -t, --timeout N                  ADB command execution timeout in seconds, default="120"
    -i, --include PATTERN            Only optimize methods and classes matching the pattern, e.g. Ldune;->melange\(\)V
    -e, --exclude PATTERN            Exclude these types from optimization; including overrides
        --disable-plugins STRING[,STRING]*
                                     Disable plugins, e.g. stringdecryptor,unreflector
        --list-plugins               List available plugins
    -v, --verbose                    Be verbose
    -V, --vverbose                   Be very verbose
For example, to only deobfuscate methods in a class called Lcom/android/system/admin/CCOIoll; inside of an APK called obad.apk:
dex-oracle -i com/android/system/admin/CCOIoll obad.apk

How it Works
Oracle takes Android apps (APK), Dalvik executables (DEX), and Smali files as inputs. First, if the input is an APK or DEX, it is disassembled into Smali files. Then, the Smali files are passed to various plugins which perform analysis and modifications. Plugins search for patterns which can be transformed into something easier to read. In order to understand what the code is doing, some Dalvik methods are actually executed with and the output is collected. This way, some method calls can be replaced with constants. After that, all of the Smali files are updated. Finally, if the input was an APK or a DEX file, the modified Smali files are recompiled and an updated APK or DEX is created.
Method execution is performed by the Driver. The input APK, DEX, or Smali is combined with the Driver into a single DEX using dexmerge and is pushed onto a device or emulator. Plugins can then use Driver which uses Java reflection to execute methods from the input DEX. The return values can be used to improve semantic analysis beyond mere pattern recognition. This is especially useful for many string decryption methods, which usually take an encrypted string or some byte array. One limitation is that execution is limited to static methods.

Hacking

Creating Your Own Plugin
There are three plugins which come with Oracle:
  1. Undexguard - removes certain types of Dexguard obfuscations
  2. Unreflector - removes some Java reflection
  3. String Decryptor - simple plugin which removes a common type of string encryption
If you encounter a new type of obfuscation, it may be possible to deobfuscate with Oracle. Look at the Smali and figure out if the code can either be:
  1. rearranged
  2. understood by executing some static methods
If either of these two are the case, you should try and write your own plugin. There are four steps to building your own plugin:
  1. identify Smali patterns
  2. figure out how to simplify the patterns
  3. figure out how to interact with driver and invoke methods
  4. figure out how to apply modifications directly
The included plugins should be a good guide for understanding steps #3 and #4. Driver is designed to help with step #2.
Of course, you're always welcome to share whatever obfuscation you come across and someone may eventually get to it.

Updating Driver
First, ensure dx is on your path. This is part of the Android SDK, but it's probably not on your path unless you're hardcore.
The driver folder is a Java project managed by Gradle. Import it into Eclipse, IntelliJ, etc. and make any changes you like. To finish updating the driver, run ./update_driver. This will rebuild the driver and convert the output JAR into a DEX.

Troubleshooting
If there's a problem executing driver code on your emulator or device, be sure to open monitor (part of the Android SDK) and check for any clues there. Even if the error doesn't make sense to you, it'll help if you post it along with the issue you'll create.
Not all Android platforms work well with dex-oracle. Some of them just crap out when trying to execute arbitrary DEX files. If you're having trouble with Segfaults or driver crashes, try using Android 4.4.2 API level 19 with ARM.
It's possible that a plugin sees a pattern it thinks is obfuscation but is actually some code it shouldn't execute. This seems unlikely because the obfuscation patterns are really unusual, but it is possible. If you're finding a particular plugin is causing problems and you're sure the app isn't protected by that particular obfuscator, i.e. the app is not DexGuarded but the DexGuard plugin is trying to execute stuff, just disable it.

More Information
  1. TetCon 2016 Android Deobfuscation Presentation
  2. Hacking with dex-oracle for Android Malware Deobfuscation


Dex-Oracle - A pattern based Dalvik deobfuscator which uses limited execution to improve semantic analysis


TROMMEL sifts through directories of files to identify indicators that may contain vulnerabilities.
TROMMEL identifies the following indicators related to:
  • Secure Shell (SSH) key files
  • Secure Socket Layer (SSL) key files
  • Internet Protocol (IP) addresses
  • Uniform Resource Locator (URL)
  • email addresses
  • shell scripts
  • web server binaries
  • configuration files
  • database files
  • specific binaries files (i.e. Dropbear, BusyBox, etc.)
  • shared object library files
  • web application scripting variables, and
  • Android application package (APK) file permissions.
TROMMEL has also integrated vFeed which allows for further in-depth vulnerability analysis of identified indicators.

Dependencies

Usage
$ trommel.py --help
Output TROMMEL results to a file based on a given directory
$ trommel.py -p /directory -o output_file

Notes
  • TROMMEL has been tested using Python 2.7 on macOS Sierra and Kali Linux x86_64.
  • TROMMEL was written with the intent to help with identifying indicators that may contain vulnerabilities found in firmware of embedded devices.

References


TROMMEL - Sift Through Directories of Files to Identify Indicators That May Contain Vulnerabilities


The Rekall Framework is a completely open collection of tools, implemented in Python under the Apache and GNU General Public License, for the extraction and analysis of digital artifacts computer systems.
The Rekall distribution is available from: http://www.rekall-forensic.com/
Rekall should run on any platform that supports Python
Rekall supports investigations of the following 32bit and 64bit memory images:
  • Microsoft Windows XP Service Pack 2 and 3
  • Microsoft Windows 7 Service Pack 0 and 1
  • Microsoft Windows 8 and 8.1
  • Microsoft Windows 10
  • Linux Kernels 2.6.24 to 4.4.
  • OSX 10.7-10.12.x.
Rekall also provides a complete memory sample acquisition capability for all major operating systems (see the tools directory).

Quick start
Rekall is available as a python package installable via the pip package manager. To install it, first create a virtal env, switch to it and then install rekall:
$ virtualenv  /tmp/MyEnv
New python executable in /tmp/MyEnv/bin/python
Installing setuptools, pip...done.
$ source /tmp/MyEnv/bin/activate
$ pip install --upgrade setuptools pip wheel
$ pip install rekall-agent rekall
For windows, Rekall is also available as a self contained installer package. Please check the download page for the most appropriate installer to use Rekall-Forensic.com
To install from this git repository you will need to use pip --editable and follow the correct order of installation (otherwise pip will pull released dependencies which might be older):
$ virtualenv  /tmp/MyEnv
New python executable in /tmp/MyEnv/bin/python
Installing setuptools, pip...done.
$ source /tmp/MyEnv/bin/activate
$ pip install --upgrade setuptools pip wheel
$ git clone https://github.com/google/rekall.git rekall
$ pip install --editable rekall/rekall-lib
$ pip install --editable rekall/rekall-core
$ pip install --editable rekall/rekall-agent
$ pip install --editable rekall
On Windows you will need to install the Microsoft Visual C compilers for python (for more info see this blog post http://rekall-forensic.blogspot.ch/2015/09/installing-rekall-on-windows.html)

History
In December 2011, a new branch within the Volatility project was created to explore how to make the code base more modular, improve performance, and increase usability. The modularity allowed Volatility to be used in GRR, making memory analysis a core part of a strategy to enable remote live forensics. As a result, both GRR and Volatility would be able to use each other's strengths.
Over time this branch has become known as the "scudette" branch or the "Technology Preview" branch. It was always a goal to try to get these changes into the main Volatility code base. But, after two years of ongoing development, the "Technology Preview" was never accepted into the Volatility trunk version.
Since it seemed unlikely these changes would be incorporated in the future, it made sense to develop the Technology Preview branch as a separate project. On December 13, 2013, the former branch was forked to create a new stand-alone project named "Rekall.” This new project incorporates changes made to streamline the codebase so that Rekall can be used as a library. Methods for memory acquisition and other outside contributions have also been included that were not in the Volatility codebase.
Rekall strives to advance the state of the art in memory analysis, implementing the best algorithms currently available and a complete memory acquisition and analysis solution for at least Windows, OSX and Linux.

More documentation
Further documentation is available at http://www.rekall-forensic.com/


Rekall v1.7 - Forensic and Incident Response Framework


Seccubus automates regular vulnerability scans with various tools and aids security people in the fast analysis of its output, both on the first scan and on repeated scans.
On repeated scan delta reporting ensures that findings only need to be judged when they first appear in the scan results or when their output changes.
Seccubus 2.x is the only actively developed and maintained branch and all support for Seccubus V1 has officially been dropped.

Seccubus V2 works with the following scanners:
  • Nessus
  • OpenVAS
  • Skipfish
  • Medusa (local and remote)
  • Nikto (local and remote)
  • NMap (local and remote)
  • OWASP-ZAP (local and remote)
  • SSLyze
  • Medusa
  • Qualys SSL labs
  • testssl.sh (local and remote)
For more information visit [www.seccubus.com]

Seccubus Docker container

Usage

Running a full stack (db/app/frontend) in a single container. And get an interactive shell
docker run -it seccubus/seccubus /bin/bash
By default the container holds a mysql server that runs and stores data locally. If you want data persistency there are two options:
Connect the container to a remote mysql/MariaDB database with environment viariables:
docker run -ti seccubus/seccubus -e DBHOST=dns.name.of.db.host \
-e DBPOSRT=3306 \
-e DBNAME=name.of.database \
-e DBUSER=db.username \
-e DBPASS=password \
/bin/bash
Or, mount a data volume with a db directory on it
mkdir data
mmdir data/db
docker run -it seccubus/seccubus -v ($pwd)/data:/opt/seccubus/data /bin/bash
Please be aware that you can only run one container at a time if you mount a local directory on /var/lib/mysql.

Running a scan
Run the following command to start the scan 'ssllabs' in workspace 'Example' (this workspace is created by default if you use the local mysql database)
docker run -ti seccubus/seccubus scan Example ssllabs
Please be aware that you need soem data persistency here or the data will be stored in a local database that will be deleted whent he container terminates

Running a scheduler
You can run a docker container as a scheduler. This will make it run cron and allow your crontab to execute scans.You can populate the crontab by either placing a file called crontab in the /opt/seccubus/data volume or puting the lines of you crontab in evironement variables starting with CRON_
docker run -e "STACK=cron" -e "CRON_1=* 0 * * * bin/do-scan -w Example -s ssllabs" -ti seccubus/seccubus
This will spin up a container that executes scan ssllabs from workspace Example at midnight every night.
You can set the TZ vairable to control the timezone.

Controlling TLS certificates
The Seccubus container is TLS enabled by default. The environment variable TLS controls this behaviour. Of it is set to anything other then yes, TLS is turned off.
There are three ways to control the certificate:
  • Do nothing : Self signed certificates will be generated for you
  • Populate the variables TLSCERT and TLSKEY : The contents will be placed in /opt/seccubus/data/seccubus.pem and /opt/seccubus/data/seccubus.key and used
  • Put the certificates in the files seccubus.pem and seccubus.key on a data volume and mount it on /opt/seccubus/data

Show this help message
docker run -ti seccubus/seccubus help

Default command
If you don't specify a command to docker run
docker run seccubus/seccubus
The web server access log and error log will be tailed to the screen.

Other options
You can set the following environment variables:
  • STACK - Determines which part of the stack is run
    • full - Run everything
    • front - Start apache to serve the html/javascript frontend (this requires that the APIURL variable is set too)
    • api - Start apache to serve the json api at / (starts MariaDB too if required)
    • web - Start apache to serve both the html/javascript frontend and the json
    • perl - Do not start apache, just use this container as an perl backend
  • DBHOST, DBPORT, DBNAME, DBUSER, DBPASS - Database connection parameters
    • If DBHOST/DBPORT are set to 127.0.0.1/3306 the local MariaDB instance is started
  • APIURL - Path to the API url
    • Set this if your set STACK to front to redirect the API calls to an alternative relative or absolute URL.
  • BASEURI - Base URI for seccubus
    • Server the application at the value provided
  • SMTPSERVER - IP address or host name of an SMTP server to be used for notifications
  • SMTPFROM - From address used in notifications
  • TICKETURL_HEAD/TICKETURL_TAIL - If these are set ticket numberrs will be linked to this URL
  • SSHKEY1, SSHKEY2, SSHKEY3 .. SSHKEY9
    • The content of this environment variable will stored in the file /opt/seccubus/.ssh/SSHKEY1 etc.
    • You can use this mechanism to provide ssh keys that are used to start remote scans
  • HTTP_AUTH_HEADER - Set the http authentication header
    • If you are using something like OpenAM to authenticate your users, this allows you to set which http request header contains the user that OpenAM detected
  • TZ - Set the timezone of the container
  • TLS - Controls TLS behaviour yes means TLS is on, otherwise TLS is off. TLS is on by default.
  • JIT_GROUP - Controls JIT provisioning of users
  • CRON_MAIL_TO - Mail cron messages to this addres
  • CRON_* - Add these lines to crontab in alphabetical order

Seccubus - Easy Automated Vulnerability Scanning, Reporting And Analysis

Subscribe to: Posts (Atom)