Drive Badger: open source platform for covert data exfiltration operations, ranging from small computers to big servers.

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/ 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:

  • exclude-windows - exclude Windows system files, drivers, popular OEM software, PDF readers, standard office applications (Firefox, Thunderbird, LibreOffice) and other irrelevant stuff
  • exclude-linux - exclude Linux system directories
  • exclude-macos - exclude Mac OS system directories
  • exclude-antivirus - exclude virus databases and other similar, completely irrelevant files
  • exclude-software - exclude irrelevant files related to various common software (popular, but installed rather individually)
  • exclude-devel - exclude irrelevant, software development-related files
  • exclude-user - exclude irrelevant, user-related files: multimedia (except photos), games, caches, telemetry etc.
  • exclude-erp - exclude ERP systems installation files
  • 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:

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 /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/ 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:

  1. Now you can clone this repository using this command:
GIT_SSH=/opt/drivebadger/internal/git/ \
    GIT_KEY=~/.ssh/id_github_repository-name \
    git clone \ \

Updating device configuration

You can update all device configuration by executing /opt/drivebadger/ 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/ script needs to be run (it is done automatically by /opt/drivebadger/ script).

From the founder...

Being in IT security business for almost 25 years, I realized, that breaking protections (or preventing it) is becoming less and less important. We are not living in Outlook Express times anymore...
The key point is the ability to keep the privileges permanent, once obtained. This becomes more and more difficult, as IT systems get more and more complicated - and this is exactly the goal of Drive Badger project: to give non-ITSEC people the ability to keep either the privileges, or the outcome of the successful break-in.