Lucifer – A Powerful Penetration Tool For Automating Penetration Tasks

Setup

git clone https://github.com/Skiller9090/Lucifer.git
cd Lucifer
pip install -r requirements.txt
python main.py --help

If you want the cutting edge changes add -b dev to the end of git clone https://github.com/Skiller9090/Lucifer.git

Commands

Command Use

No-Arg Commands

• help – to display help menu
• name – shows name of current shell
• id – shows current shell id
• options – shows a table of set options/vars
• set_vars – automatically sets vars needed for the loaded module (default defined in a module)
• description – show description of current loaded module
• auto_vars – displays current setting of auto_vars (auto_vars if true will automatically run set_vars on module load)
• run – runs the module with the current options, exploit works the same
• spawn_shell – spawns a new Shell instance
• show_shells – shows all open shells ids and names
• clear – clears the terminal/console screen
• close – kills the input to current shell
• reset – resets everything (not implemented)
• exit – quits the program

• Arg Commands
  • show <options/modules> – displays a list of set options or modules depending on argument.
  • set <var_name> <value> – sets a variable/option
  • change_auto_vars <to_set> <args>:
    • <to_set> – can be true or false (t or f) (-t or -f)
    • <args>:
      • -g = global – sets for all shells spawned
      • -n = new – sets this option for future shell spawns
      • -i = inclusive – no matter what, set current shell to <to_set>
  • use <module> <args>:
    • <module> – path to module
    • <args>:
      • -R – Override cache (reload dynamically)
  • open_shell <id> – opens a shell by its id
  • set_name <name> – set the name of the current shell
  • set_name_id <id> <name> – set the name of the shell specified by

Examples

Settings Variables

Running Module

Settings

Versioning

The standard of versioning on this project is:

MAJOR.MINOR.PATCH.STAGE.BUILD

Major:

• incremented when either there has been a significant amount of new features since the start of the major or if there is a change which is so big that is can cause compatibility issues (Major of 0 if very unstable
• Could cause incompatibility issues

Minor:

• incremented when a new feature or feature-set is added to the project
• should not cause incompatibility errors due to only additions made

Patch:

• incremented on bugfixes or if feature is so small that it is worth incrementing minor
• very low risk of incompatibility error

Stage:

• The stage of current MAJOR.MINOR.PATCH BUILD, either alpha, beta, release candidate or release
• Indicates how far through development the new MAJOR.MINOR.PATCH is
• Stage number to name translation:
  • 0 => beta (b)
  • 1 => alpha (a)
  • 2 => release candidate (rc)
  • 3 => release (r)

Build:

• this should be incremented on every change made to the code, even on a one character change

This version structure can be stored and displayed in a few ways:

• The best way to store the data within code is via a tuple such as:
  • (Major, Minor, Patch, Stage, Build)
    • Example is: (1, 4, 1, 2, 331)
• The long display would be:
  • {stage} {major}.{minor}.{patch} Build {build}
    • Example is: Alpha 1.4.1 Build 331
• The short display would be:
  • {major}.{minor}.{patch}{stage}{build}
    • Example is: 1.4.1a331

Download: https://github.com/Skiller9090/Lucifer

Please follow and like us: