Skip to content

Configuration repositories

Tomasz Klim edited this page Feb 20, 2022 · 27 revisions

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:

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:

Demonstration repositories

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

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).

  1. Configure this key at:

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

  1. 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 \
	[email protected]: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).
Clone this wiki locally