RedPie is a comprehensive toolkit designed for Red Team professionals and penetration testers. This versatile suite offers a range of tools and utilities to aid in simulating attacks, performing vulnerability assessments, and enhancing overall security posture.
- Advanced Port Scanning: Detect open ports and services with detailed information.
- Web Fuzzing: Discover hidden web directories and vulnerabilities through configurable fuzzing.
- Password Cracking: Efficiently crack hashed passwords with customizable wordlists.
- OS Detection: Identify operating systems using advanced techniques and integrations.
- Modular Design: Easily extend and integrate with other tools and scripts.
The full documentation for RedPie is available to guide you through installation, usage, features, and best practices. Whether you're just getting started or looking to dive deep into advanced features, the documentation has you covered.
Thank you for your interest in contributing to this project! To ensure a smooth collaboration, please follow these guidelines when submitting issues, feature requests, or code contributions.
We aim to create a welcoming and inclusive environment. Please be respectful and courteous to other contributors. We follow the Contributor Covenant Code of Conduct.
-
Fork the Repository: Before making any changes, fork the repository to your own GitHub account.
-
Create a Branch: Always create a new branch for your work. Branch names should follow this convention:
- For features:
feature/feature-name - For bug fixes:
bugfix/issue-number-description - For documentation:
docs/description
Example:
feature/add-authenticationorbugfix/issue-42-login-error - For features:
-
Make Changes:
- Ensure your changes are well-documented, and the code is clean and readable.
- Follow the coding style of the project (e.g., indentation, variable naming, etc.).
- Include comments when necessary to explain complex logic.
-
Test Your Code: Before submitting a pull request, please test your code to make sure it works as expected and does not break existing functionality.
-
Create a Pull Request (PR): Once your changes are ready, create a pull request.
- PRs should have a meaningful title and a clear description of the changes you’ve made.
- Reference any relevant issue numbers (e.g.,
Closes #42). - If your PR addresses a feature or bug fix, please explain the reasoning behind your solution.
-
Review Process:
- One or more maintainers will review your pull request.
- If changes are requested, please address them promptly.
- Once approved, your pull request will be merged into the
mainbranch.
-
Avoid Large Pull Requests: Try to break large changes into smaller, focused pull requests to make them easier to review.
If you find a bug or have a feature request, please follow these guidelines:
- Check Existing Issues: Before opening a new issue, check if there’s already an issue covering your problem.
- Open a New Issue: If no issue exists, create a new one with a descriptive title and detailed information.
- For bug reports, include steps to reproduce the issue, expected behavior, and any relevant logs or screenshots.
- For feature requests, explain the use case and how it will benefit the project.
The main branch is protected. No direct commits are allowed. All changes must be made via pull requests.
Please follow these conventions for writing commit messages:
- Use the present tense (e.g., "Add feature" not "Added feature").
- Keep commit messages short and informative.
- Reference the issue number in your commit message if applicable (e.g.,
Fix issue #42).
By contributing, you agree that your contributions will be licensed under the project's MIT License.
We appreciate your contributions and look forward to working with you!