Drive Badger is configured by cloning special configuration repositories into /opt/drivebadger/config directory. Each such repository should contain 1 or more configuration files.

Configuration file types

There are several recognized file names:

• exclude.list - contains rsync exclusion rules
• bitlocker.keys - Bitlocker recovery keys
• filevault.keys - Apple FileVault recovery keys or user passwords
• veracrypt.keys - VeraCrypt passwords
• luks.keys - LUKS passwords
• ignore.uuid - UUID partition identifiers to be ignored by Mobile Badger (to avoid exfiltrating known ISO images, eg. Kali Linux image)
• target.uuid - UUID partition identifiers of target partitions for Mobile Badger

Drive Badger can recognize and handle multiple files of each type - eg. if you split Bitlocker recovery keys into several repositories and thus several bitlocker.keys files, it will just merge and test them all. Most files (except exclude.list) can contain comments and empty lines.

Recommended repositories

Configuration repositories should be cloned into /opt/drivebadger/config directory as subdirectories - eg. /opt/drivebadger/config/exclude-windows or /opt/drivebadger/config/keys-luks-yourchosenname.

Each /opt/drivebadger/config/yourchosenname local directory can be:

• a working copy of Git repository
• a working copy of Subversion repository
• a standalone directory, not synchronized with any repository (configured and updated manually, or generated by some external tool)

All subdirectories being repository working copies, can be updated at once, using /opt/drivebadger/update.sh script (it supports also private repositories, if you properly set corresponding ssh keys). For standalone directories, you are responsible for keeping them up to date.

If you're not sure, if some part of your device configuration could be public, just make the particular repository private.

Repositories meant for direct use

The below repositories are developed as parts of Drive Badger project, so you can rely on their quality. You can also fork each of them and continue developing them yourself:

• all exclude-* repositories containing rsync exclusion rules, eg. exclude-windows
• ignore-known - ignore given partitions in Mobile Badger mode (see details)

Demonstration repositories

The below repositories are not meant for direct use. Your should create your own private repositories from scratch, based on these examples:

• target-demo - recognize given partitions as targets in Mobile Badger mode (see details)
• keys-bitlocker-demo - sample bitlocker.keys file
• keys-filevault-demo - sample filevault.keys file
• keys-veracrypt-demo - sample veracrypt.keys file
• keys-luks-demo - sample luks.keys file

Installing public repositories

To install any public configuration repository, you just need to execute 1 command on your Kali Linux terminal (as root, during installation):

git clone https://github.com/drivebadger/chosen-repository /opt/drivebadger/config/chosen-repository

Installing private repositories

Installing private repositories is just a bit more complicated:

1. For each private repository create a deploy key - separate for each operator that you want to give access to Drive Badger:

/opt/drivebadger/internal/git/key.sh repository-name

Generated key will be displayed on console and will end with local hostname - you can replace it with the name that better describes particular device or memory card (in case of losing it, to be able to quickly find and remove it from Github).

2. Configure this key at:

https://github.com/your-github-login/repository-name/settings/keys

3. Now you can clone this repository using this command:

GIT_SSH=/opt/drivebadger/internal/git/helper.sh \
    GIT_KEY=~/.ssh/id_github_repository-name \
    git clone \
    git@github.com:your-github-login/repository-name.git \
    /opt/drivebadger/config/repository-name

Updating device configuration

You can update all device configuration by executing /opt/drivebadger/update.sh script as root. It first updates:

• base repository
• all configuration repositories
• hooks
• injectors
• external modules

Next, it rebuilds UUID files required by Mobile Badger.

Creating your own configuration files

Writing your own exclude.list files

1. Empty lines are allowed.
2. Comments are NOT allowed.
3. Duplicated rules are allowed.
4. All rules are case sensitive.

Writing your own *.keys files

1. Empty lines are allowed.
2. Comments are allowed.
3. Comments must start from # as the first character in line (no leading spaces allowed).
4. All keys/passwords can be split into multiple *.keys files.
5. Duplicated keys/passwords are allowed, both in the same file and across the files.

Writing your own *.uuid files

1. Empty lines are allowed.
2. Comments are allowed.
3. Comments must start from # as the first character in line (no leading spaces allowed).
4. All UUIDs can be split into multiple *.uuid files.
5. Duplicated UUIDs are allowed, both in the same file and across the files.
6. After each update, /opt/drivebadger/internal/mobile/rebuild-uuid-lists.sh script needs to be run (it is done automatically by /opt/drivebadger/update.sh script).