1. Check for available modules¶
First, check that what you're trying to achieve is not already implemented in an existing module.
2. Is it WiFi- or radio-controlled ?¶
This will condition the machinery you will need to implement your new module.
3. Check for available features¶
This machinery is at the root of the package. Its structure is logically made:
drones: this folder is for specific drone-related features
radio: this folder is reserved for radio features
wifi: this folder is reserved for WiFi features (connection, deauthentication, scanning)
4. Prototype a script¶
In order to integrate your work to DroneSploit, you will need to test it first. It is advised to script your interaction/attack on your drone and to test it before writing your module.
Be sure to split what is speficic to:
- The technology, i.e. WiFi or radio signals ; this is generic and could serve for various modules (e.g. mixins).
- A particular brand of drone ; this could serve for multiple modules and this will go into the
dronesfolder (e.g. Hobbico),
- A model of drone (e.g. C-Me).
This way, the integration will be straightforward and you will avoid losses of time and reinventing the wheel.
5. Contribute to DroneSploit¶
From this point, the different parts of the prototype script can now be integrated into DroneSploit.
- Technology: This part is to put in
wifi, ... depending on what is already implemented or what could be modified/improved. For WiFi, be sure to include a regular expression in the drone filter, that is, in the
DRONE_REGEXconstant. Note that, if technology-specific modules are worth adding, these can be put into the
auxiliarycategory folder (e.g.
- Brand: This part typically contains proxy
Module-inherited classes (see example in
hobbico.py) to be added to the existing or created into a new brand-named subpackage.
- Model: This part will be split by module or by group of related modules in files under the
Module class attributes
When writing modules, the following class attributes can be used (see this example):
config: for adding module configuration options
path: for setting the path to the module from within the CLI (e.g. the source file could be
commands/my-drone/modelwith a module named
pathset, it would give
commands/my-drone/model/my_first_module, but the path can be overriden to get for instance
requirements: this dictionary allows to set requirements that will prevent the module from being used if some are not met (multiple keys can be used to set lists of granular requirements, i.e.
pythonfor checking that a Python package is installed, or
systemfor checking that a CLI tool exists)
Be sure to define enough requirements.