Leap project branch

src/LEAP-master/Makefile

@@ -0,0 +1,43 @@
+VENV=LEAP_venv
+INVENV = $(shell pip3 -V | grep $(VENV))
+
+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 "\n${GREEN}This is fairly general Makefile that does the same job as the makefiles in previous projects. You can add new things, modify it, or just delete it if you don't need it.${RESET}\n"
+
+venvcheck:
+ifeq ($(INVENV),)
+	$(error ${RED}You should only run this from within the venv. Use '${YELLOW}. ./$(VENV)/bin/activate${RED}'${RESET})
+else
+	@echo "${GREEN}venv check passed${RESET}\n"
+endif
+
+
+test: FORCE message venvcheck
+	py.test -v  tests/ 
+
+docs: FORCE message venvcheck
+	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 '${YELLOW}make venv${RED}' followed by '${YELLOW}. ./${VENV}/bin/activate${RED}' and finally '${YELLOW}make prereqs${RED}'${RESET}\n"
+
+
+venv: FORCE
+	python3 -m venv $(VENV)
+
+prereqs: FORCE venvcheck
+	pip install -r requirements.txt
+
+
+FORCE:

src/LEAP-master/README.md

@@ -0,0 +1,142 @@
+# LEAP
+
+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:
+<https://www.sciencedirect.com/topics/computer-science/design-by-contract>. 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 or using branching. 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 might
+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. If using branches, then each team member can merge into their
+branch from either the master (if any system changes are made) or from
+other users' forks (to incorporate their plugins).
+
+If using forks, with team members being A, B, C and D, they 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.
+
+
+
+
+# Your Submission
+
+Key points for submission:
+
+ - You should submit your work through Aula as a PDF.
+ - We will be marking anonymously, so try not to identify yourself in
+   the report. Use a pseudonym or redact any code or screenshots that
+   includes your name.
+ - In the information on the repository, provide a screenshot of the
+   sequence of commits as well as a link to your final commit. You can
+   find this information from the github.coventry.ac.uk web interface
+   by clicking on the "X commits" button: ![commit button](./commit.png)
+ - Do not use screenshots for code.  You can format your code for Word
+   using a tool such as the
+   <http://www.planetb.ca/syntax-highlight-word> website
+   - And **definitely** do not take photographs of your screen in order to show code
+ - Make sure you include **ALL** of the source code required for your
+   submission in appendices. This includes the code imported from your
+   group members.
+ - But **also** make it clear which parts are **not** yours.
+   - The easiest method is to have a section showing **just your
+     code** and the full code as an appendix.
+ - Each person should have their own privesc and enumeration code as
+   well as the privescs and enumerations of their group.  You should
+   not be developing these components as a group.
+ - For the basic task, **you can** share the menu code or use the one
+   provided, modified as required.
+ - For the intermediate tasks onward, you should make **your own
+   modifications or alternative menu code**.  This means you can work
+   on the same base as your group, but add your own modifications
+   **not shared with your group** in order to achieve the later tasks.
+ - If your group failed to work together, you can still show you
+   incorporated the work of others.  The **phantom member** branch of
+   the master LEAP repository
+   (<https://github.coventry.ac.uk/CUEH/LEAP/tree/phantom_member>) can
+   be used as a source. Imagine this is the code of a member of your
+   group and use the privesc and enumeration classes that it contains
+   to add to your tool.  You may need to make modifications, just as
+   you might with members of your group, if you have diverged from the
+   shared menu system. This is expected if you are attempting the
+   intermediate or advanced tasks.
+
+## Suggested Report Outline
+
+This is just a suggestion.
+
+1. Introduction. 
+  - Explain the tool. What is it's purpose?
+2. User documentation
+  - How do we run this? How do we operate it?
+3. Unit Tests
+  - A table of the tests you created. Like last time: <https://github.coventry.ac.uk/pages/CUEH/4061CEM/assessment/cw1/example.html#org1514c40>
+4. Plugins
+  - What plugins did **you** create?
+  - What plugins did **your team members** create?
+5. Repository 
+  - A screenshot of your commits, demonstrating your sequence of
+    development and where you incorporated group-members' code
+  - A link to the repository
+5. Appendix A: Your Code 
+  - This is the code that is **yours**. If you used code from other
+    sources in this section, make clear which parts and where it came
+    from.  This includes things from web-pages and the code you were
+    given in the master repo
+6. Appendix B: All source code
+  - Include all source code here, including that which comes from your
+    team for plugins.  Again, make sure to highlight the source of any
+    code that is not yours.  You can simply say that your team
+    contributions are from "team members" in order to maintain
+    anonymity.

src/LEAP-master/requirements.txt

@@ -0,0 +1,2 @@
+pytest
+pdoc3

src/LEAP-master/src/leap.py

@@ -0,0 +1,22 @@
+def dummyFunc(data):
+    """ This function is a placeholder """
+    import base64
+    out=""
+    for i in data:
+        v=ord(i)
+        v=((v&1)<<6) | (v>>1)
+        out+=chr(v)
+    return base64.b64encode(str.encode("".join(out))).decode()
+
+def unDummyFunc(data):
+    """ This function is a placeholder """
+    import base64
+    out=""
+    for i in base64.b64decode(str.encode(data)).decode("utf-8"):
+        v=ord(i)
+        v=((v&64)>>6) | ((v<<1)&127)
+        out+=chr(v)        
+    return "".join(out)
+
+if __name__=="__main__":
+    print("Your code goes here")

src/LEAP-master/tests/test_dummy.py

@@ -0,0 +1,11 @@
+import pytest
+import sys
+sys.path.append("./src/")
+import leap
+
+
+flag="MzZwcx15NHQzOnxzcnI9cjk="
+
+
+def test_dummy():
+    assert leap.dummyFunc(leap.unDummyFunc(flag))==flag

src/LEAP-phantom_member/Makefile

@@ -0,0 +1,43 @@
+VENV=LEAP_venv
+INVENV = $(shell pip3 -V | grep $(VENV))
+
+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 "\n${GREEN}This is fairly general Makefile that does the same job as the makefiles in previous projects. You can add new things, modify it, or just delete it if you don't need it.${RESET}\n"
+
+venvcheck:
+ifeq ($(INVENV),)
+	$(error ${RED}You should only run this from within the venv. Use '${YELLOW}. ./$(VENV)/bin/activate${RED}'${RESET})
+else
+	@echo "${GREEN}venv check passed${RESET}\n"
+endif
+
+
+test: FORCE message venvcheck
+	py.test -v  tests/ 
+
+docs: FORCE message venvcheck
+	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 '${YELLOW}make venv${RED}' followed by '${YELLOW}. ./${VENV}/bin/activate${RED}' and finally '${YELLOW}make prereqs${RED}'${RESET}\n"
+
+
+venv: FORCE
+	python3 -m venv $(VENV)
+
+prereqs: FORCE venvcheck
+	pip install -r requirements.txt
+
+
+FORCE:

src/LEAP-phantom_member/README.md

@@ -0,0 +1,72 @@
+# LEAP
+
+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:
+<https://www.sciencedirect.com/topics/computer-science/design-by-contract>. 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 or using branching. 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 might
+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. If using branches, then each team member can merge into their
+branch from either the master (if any system changes are made) or from
+other users' forks (to incorporate their plugins).
+
+If using forks, with team members being A, B, C and D, they 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.
+
+
+
+

src/LEAP-phantom_member/requirements.txt

@@ -0,0 +1,3 @@
+pytest
+pdoc3
+console-menu