pwncat/CONTRIBUTING.md

Contributing

If you have an idea for a new feature or just want to help out with a bug fix, please refer to this guide and follow the rules before submitting a pull request.

Submitting Issues

If you aren't a programmer or don't have the time to contribute code to the project, we would still appreciate bug reports and feature requests. Please use the appropriate issue type in the GitHub issue system to report either bugs or feature requests.

When reporting bugs, ensure you include the current version pwncat you have installed, what type of target/victim you are using, what payload you used on the target to gain a shell, any relevant tracebacks, and of course screenshots if they add context to your problem. In general, the more information we have, the more chance there is we can fix the problem.

For feature requests, please be very specific on what you would like pwncat to do. We can't read your mind, and English isn't perfect. If you are interested in or willing to help implement your new feature, please explicitly let us know. This will help in prioritizing the issue.

Versioning

pwncat follows Semantic Versioning. You can learn about the basics of semver here. pwncat does not currently have any release schedule, but in general the following rules apply:

• PATCH fixes are released whenever there is either significant aggregate of bug fixes or when a significantly agregious bug is fixed. The decision for what "significant" means will be decided by a project owner.
• MINOR releases are for added functionality. The pwncat API is relatively stable, but still has not attained v1.0.0 status, and therefore minor releases could make breaking API changes. However, a concerted effort should be made to make all changes backwards compatible.

As mentioned above, pwncat has not reached v1.0.0 yet. As such, I don't have rules yet for MAJOR version bumps. I will update this file as the situation develops.

Making Changes

In general, when contributing to a project on GitHub, you should work from a branch. This helps organize your changes within the project. There are two main branches which pwncat uses to organize contributions: master and the next release branch (named like release-vX.Y.Z).

• Any bug fixes which do not add new features should be made targeting master.
• Any new features should be made targeting the latest release-vX.Y.Z.

When forking the repository to make contributions, you can work directly out of your fork's master or release branches or fork them. When creating a pull request, you must target the appropriate branch based on the intent of your work.

Pull requests targeting the wrong branch will be retargeted, which could cause issues while merging.

Styling and Format

The majority of pwncat is written in Python. We use python-black to format code in a consistent and readable manner. We recommend you install a Black plugin for your editor or IDE to ensure all code is formatted prior to opening a pull request.

Beyond Black, you should also run isort and flake8 within your branch prior to opening a pull request. isort will sort your imports to ensure they are easy to read. flake8 will notify you of some common Python errors. pwncat has flake8 and isort configurations, so the process is as simple as running the associated tool.

Prior to creating a pull request, please run the following from the repository root to ensure formatting is in order:

# Automatically fixes imports
isort ./pwncat
# Automatically fixes formatting
black ./pwncat
# Warns of errors or other syntax problems
flake8

Testing Your Changes

Testing pwncat is difficult. There are some unit tests implemented in tests/. These tests can be executed with pytest, but you must provide suitable targets for the testing framework. The run-tests.sh script uses podman to start two containers to act as targets, and then runs all tests. One container is a Ubuntu machine with a bind shell and the other is a CentOS container with a bind shell.

If you are creating Windows features, you can run the Windows tests as well by manually providing a Windows bind shell target:

WINDOWS_HOST=10.10.10.10 WINDOWS_BIND_PORT=4444 ./run-tests.sh

The included unit tests are not great. They do not have a lot of coverage, but they at least ensure that the basic automated functionality of pwncat is not broken across some common target types.