diff --git a/.gitignore b/.gitignore index 14e212ae..7c071a0a 100644 --- a/.gitignore +++ b/.gitignore @@ -103,3 +103,4 @@ venv.bak/ # mypy .mypy_cache/ *~ +/html/ diff --git a/Makefile b/Makefile index 4e95d31a..cad1a651 100644 --- a/Makefile +++ b/Makefile @@ -1,11 +1,29 @@ +BLACK := $(shell tput -Txterm setaf 0) +RED := $(shell tput -Txterm setaf 1) +GREEN := $(shell tput -Txterm setaf 2) +YELLOW := $(shell tput -Txterm setaf 3) +LIGHTPURPLE := $(shell tput -Txterm setaf 4) +PURPLE := $(shell tput -Txterm setaf 5) +BLUE := $(shell tput -Txterm setaf 6) +WHITE := $(shell tput -Txterm setaf 7) +RESET := $(shell tput -Txterm sgr0) + all: FORCE - @echo "This is an empty Makefile. You can put stuff in here, or just delete it if you don't need it." + @echo "\n${GREEN}This is an empty Makefile. You can put stuff in here, or just delete it if you don't need it.${RESET}\n" + -test: FORCE - echo "If you don't have pytest installed, you will need to install it globally or use 'make venv' if you want a virtualenv created with it in" +test: FORCE message py.test -v tests/ +docs: FORCE message + pdoc --html ./src/*.py --force + + +message: FORCE + @echo "\n${RED}If you don't have pytest or pdoc3 installed, you will need to install them globally or inside a virtualenv. This Makefile can build the venv for you, if you use 'make venv' followed by '. ./venv/bin/activate' and finally 'make prereqs'${RESET}\n" + + venv: FORCE python3 -m venv venv diff --git a/README.md b/README.md index 27f6474b..a7cd1d79 100644 --- a/README.md +++ b/README.md @@ -1,2 +1,66 @@ # LEAP -LEAP: Local Enumeration And Privesc. Framework for prohect. + +LEAP: Local Enumeration And Privesc. Framework for 4061CEM project. + + +## What is here? + +Not much. + +This project requires you to generate most of the actual code +yourselves. To start with, each team should work on a fork of this +repository together to define the common features of the individual +pieces of functionality - we'll refer to them as "plugins". This is a +kind of **design by contract**, which you can read about here: +. Some +things to decide might be: + - Will each piece of functionality be in a separate file or subdirectory? + - Will your team have a naming convention? For example, maybe all + windows enumerators will begin with "wEnum_", linux with "lEnum_" + and so on. + - What will each function return or display? Will each function + print out to the user? Or will it return a block of text in a + string? Or a list of lines? Or maybe a dict with some meta-info + (version, plugin name, plugin author, date, time, etc.) and text + data? Or JSON? All are possibilities. + - Will you have a standard set of parameters to be passed in? Or can + each plugin have a different set of required parameters? + - What plugins will be implemented? Who will be the author? + +You should document these decisions here in the ~README.md~ file. Once +you are all happy with this, stage, commit and push it to your shared +fork. Then, each team member can begin writing their own tool by +creating an individual fork. Naming your tool something sensible and +uniquely identifiable at this point will be very helpful. If you all +keep the simple name "LEAP", you will find it tricky to remember which +repository you are working on later. You can call your own fork +whatever you like. + +When the individual tools are working and each team member has their +own plugins working, it is their responsibility to liaise with the +other members of the team to import the other plugins. Each team +member should create a fork of the repositories of each of their +team-mates, integrate their plugins and submit a pull-request for each +fork. + +So, if the team members are A, B, C and D, we will have one fork to +start with in which the team collaborates on defining the basics. +Then A will create a personal fork of the shared repository and work +on their tool and plugins. When they're done, they will create forks +from their team-mate's repositories. Let's call them LEAP-B, LEAP-C +and LEAP-D. A will then port their plugins to each of these new forks +and submit pull requests for them to be merged into the repositories +of their teammates. + +## Why? + +This might seem overly complex, but it's not. In reality, this is one +of the common ways people collaborate using git. You can fork any +public project and work on your own copy without needing to ask +permission or get added to the original repo, then if you want to +recommend your changes to the original author you create a pull +request and they can decide to merge it into their work or not. + +In this project you will be getting experience of working on a project +and receiving multiple pull-requests from contributors and at the same +time, contributing to the repositories of others. diff --git a/requirements.txt b/requirements.txt index e079f8a6..8d98d363 100644 --- a/requirements.txt +++ b/requirements.txt @@ -1 +1,2 @@ pytest +pdoc3 diff --git a/src/leap.py b/src/leap.py index 615af71e..b4c6d13c 100644 --- a/src/leap.py +++ b/src/leap.py @@ -1,4 +1,3 @@ -#TODO Documentation def dummyFunc(data): """ This function is a placeholder """ import base64