| Name | mkctf JSON |
| Version |
7.0.6
JSON |
| download |
| home_page | None |
| Summary | MaKe Capture The Flag |
| upload_time | 2024-10-18 20:02:22 |
| maintainer | None |
| docs_url | None |
| author | None |
| requires_python | >=3.10 |
| license | MIT License Copyright (c) 2017-2024 koromdako Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the "Software"), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions: The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software. THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE. |
| keywords |
ctf
framework
cli
|
| VCS |
 |
| bugtrack_url |
|
| requirements |
No requirements were recorded.
|
| Travis-CI |
No Travis.
|
| coveralls test coverage |
No coveralls.
|
# mkCTF
## Why ?
This framework aims at helping your team create jeopardy CTF challenges
using a configurable structure which will enable efficient integration and
deployment on the CTF infrastructure.
This project was initially created for managing challenges for
[INS'hAck 2017](https://github.com/HugoDelval/inshack-2017).
You can find challenges and writeups of the past editions of INS'hAck in
[this repository](https://github.com/InsecurityAsso).
This project evolved over time to enable even more automation when deploying
challenges on a Rancher-based infrastructure.
## Caution
Your mkCTF repository **shall remain private until the CTF event ends**. It
stores flags in plaintext to allow CTF admins to rebuild challenges from
sources without generating new flags. It is recommended to enable 2FA add
defensive layers to your repository. Do not generate or manage read-only access
token lightly. Do not give access to your repository to untrusted users.
## Dependencies
This project requires Python 3.9+ and has been designed and tested on Linux
only. It might work on Darwin and Windows Subsystem for Linux as well.
Other dependencies will depend on the challenges themselves.
## Setup
You can setup mkCTF in a few steps:
```bash
curl -o setup.sh https://raw.githubusercontent.com/koromodako/mkctf/master/setup.sh
chmod +x setup.sh
./setup.sh
rm setup.sh
```
Then create your first CTF:
```bash
mkdir example-ctf && cd example-ctf
mkctf-cli init
# then simply follow the terminal prompts
```
## Tools
Each tool description may refer to concepts defined in **Concepts** section so
make sure to check it out if you encounter an new concept.
### mkctf-cli
`mkctf-cli` helps you and CTF co-authors to manipulate a mkCTF repository. It
ensures that challenges integration with the CTF infrastructure won't give you
a headache.
You can enumerate challenges to have a quick overview of the work progression
and distribution across tags and categories.
You can also export public files of your challenges in a single command. Public
files location in a challenge directory can be configured.
### mkctf-monitor
`mkctf-monitor` is an all-in-one monitoring solution running healthchecks on a
regular basis and sending reports to the dashboard using an HTTP API defined in
**Dashboard** section.
Once you have initialized your mkCTF repository, you can build a monitoring
image and run it by following this procedure:
```bash
cd example-ctf
mkdir monitoring/ctf
cp -r .mkctf challenges monitoring/ctf
sudo DOCKER_BUILDKIT=1 docker build -t example-ctf-monitoring:1.0.0 .
sudo docker container run --rm \
--env monitoring.env \
--name monitoring \
example-ctf-monitoring:1.0.0
```
## Concepts
### Challenge
Challenges are the base of jeopardy CTF. Each challenge can be described using
some metadata:
```yaml
# challenge author to be displayed on the dashboard
author: someone
# category in terms of infrastructure requirements
# - `simple` means that the challenge is static (downloadable elements only)
# - `server` means that the challenge requires a server and server can be shared
# between all players, challenge vulnerabilities allow read-only access at most
# - `sandbox` means that the challenge can be destroyed/altered by a player and
# shall be allocated on a per team or player basis
category: simple
# challenge estimated difficulty to be displayed on the dashboard
difficulty: hard
# enabled is set to true when the challenge is considered production-ready:
# - it runs
# - it is stable
# - it has been integrated successfully with the CTF infrastructure
# - it has been tested successfully (at least manually)
enabled: false
# challenge flag to be found by the player and to be used when building or
# health-checking, it can be set manually or generated automatically
flag: INSA{Th1s_Is_N0t_A_R34L_flag;)}
# challenge logo to be displayed on the dashboard
logo_url: ''
# display name of the challenge
name: My New Challenge
# number of points to be awarded when the challenge is solved. `-3` is a specific
# value meaning that the number of points must be calculated dynamically for this
# challenge
points: -3
# slug of the challenge
slug: my-new-challenge
# static url of the challenge archive. It is generated automatically from repo
# `salt` and `base_url`
static_url: https://static.ctf.insecurity-insa.fr/9afb7029e93ed50c280c69c8443418c5683d05f8.tar.gz
# tags are chosen by the author to specify the nature the challenge
tags:
- forensics
```
### Repository
A repository contains a collection of challenges and monitoring resources. It
can described using some metadata:
```yaml
general:
# difficulties holds a list of difficulties which can be used to describe a
# challenge complexity
difficulties:
- very easy
- easy
- medium
- hard
- insane
# docker holds the information related to the registry where challenge images
# will be stored.
docker:
registry: registry.example.ctf
user: examplectf
# domain holds the parent domain of all challenges
domain: example.ctf
# flag holds the prefix and suffix to be used for challenges
flag:
prefix: ECTF{
suffix: '}'
# tags holds a list of tags available to categorize challenge content
tags:
- for
- rev
- pwn
- web
- web3
- prog
- osint
- radio
- crypto
- mobile
- bounty
- stegano
# categories holds the list of files and directories to be created for each
# infrastructure category (sandbox, server, simple)
categories:
sandbox:
dirs:
private:
- server
public: []
files:
- exec: false
from: Dockerfile.sandbox-server
name: server/Dockerfile
- exec: false
from: Dockerfile.server
name: server/Dockerfile.sandbox
- exec: false
from: banner
name: server/banner
- exec: false
from: sshd_config
name: server/sshd_config
- exec: true
from: sandbox_start.sh.jinja
name: server/sandbox_start.sh
server:
dirs:
private:
- server
public: []
files:
- exec: false
from: Dockerfile.server
name: server/Dockerfile
simple:
dirs:
private:
- private
public: []
files: []
# display name of the jeopardy CTF
name: ExampleCTF
# standard holds the common files and directories to be created for each
# challenge
standard:
build:
exec: true
from: build.jinja
name: build
deploy:
exec: true
from: deploy.jinja
name: deploy
description:
exec: false
from: description.md.jinja
name: description.md
dirs:
private: []
public:
- public
files:
- exec: false
from: null
name: .gitignore
- exec: false
from: writeup.md.jinja
name: writeup.md
- exec: false
from: healthcheck.deps
name: healthcheck.deps
healthcheck:
exec: true
from: healthcheck.jinja
name: healthcheck
# static holds information about which domain will be used to serve each
# challenge archive (exported using `mkctf-cli export /tmp/export-example`)
# and a salt to make archive name impossible to predict
static:
base_url: https://static.example.ctf
salt: # hex-encoded bytes (randomly generated)
```
### Standard Programs
mkCTF framework defines some mandatory programs that have a specific purpose
in the context of integrating each challenge into the CTF infrastructure. These
programs are described below.
| Program | Purpose |
|:-------:|:--------|
| `build` | This executable builds the challenge from the sources and the configuration (flag) |
| `deploy` | This executable perform the deployment-related operations for the challenge |
| `healthcheck` | This executable performs a healcheck on the deployed challenge (checking checksum or playing an exploit) |
Previously defined programs shall respect the following specifications:
| ID | Specification | Comments |
|:----:|:-------------------------------------------------------------------------------|:---------|
| `S0` | The executable **shall not take positional arguments** | The caller will not provide any positional argument |
| `S1` | The executable **shall be able to to handle an optional** `--dev` **argument** | This argument might be given by the caller which will expect the executable to run in `development` mode when applicable |
| `S2` | The executable **execution shall end before a timeout is triggered** | Timeout defaults to 2 minutes. `--timeout` option enable you to override this value |
| `S3` | The executable **shall return an exit code** | This code will be interpreted using the rules defined in the next table |
As explained in `S3` the program exit code will be interpreted according to
the following table:
| Exit Code | Meaning | Description |
|:---------:|:-------:|:------------|
| `0` | `SUCCESS` | The executable execution succeeded |
| `2` | `N/A` | The executable does have a meaning in the context of this challenge |
| `3` | `MANUAL` | The executable cannot perform this task entirely, you will have to get your hands dirty |
| `4` | `NOT IMPLEMENTED` | The executable is not implemented yet |
| _OTHER_ | `FAILURE` | The executable execution failed |
When using `build`, `deploy` or `healthcheck` commands, the CLI will behave as
described below.
If the **exit code** differs from `0` executable output (both _stdout_ and _stderr_)
will be printed out. You can use this behavior to print meaningful instructions
from within these programs. This behavior is particularly interesting if your
program returns a code `3` which means the user must perform a manual operation
to complete the task.
A special status `TIMEOUT` may occur when using `build`, `deploy` or `healthcheck`
commands. In that case, it means that your executable took too long to execute
as explained in specification`S2`.
### Dashboard
The dashboard is expected to provide HTTP APIs defined below. Generic endpoint
specifications are the following:
| ID | Specification | Details |
|:----:|:--------------|:--------|
| `R1` | The dashboard API **shall implement HTTPS with a valid certificate** | `mkctf-cli` will always use `https` scheme to post the configuration |
| `R2` | The dashboard API **endpoint shall implement basic authentication** | `mkctf-cli` will set the Authorization header using Basic method |
| `R3` | The dashboard API **endpoint shall expect a HTTP POST query** | `mkctf-cli` will POST challenge configuration to the dashboard |
| `R4` | The dashboard API **endpoint shall expect a application/json body** | `mkctf-cli` will POST a JSON body to the dashboard |
#### Configuration Synchronization API
`mkctf-cli push` command allows to push every challenge configuration to the
dashboard.
```
POST /mkctf-api/push
```
```json
{
"challenges": [
{
"name": "Dont Mess With My Memory",
"slug": "dont-mess-with-my-memory",
"tags": [
"pwn"
],
"flag": "ECTF{fake_flag_for_u_buddy}",
"author": "koromodako",
"points": -3,
"enabled": true,
"category": "sandbox",
"logo_url": "",
"difficulty": "easy",
"static_url": "https://static.example.ctf/4f9bb3ac75a3cc0e5995aaa1af345ab62de6a697.tar.gz"
}
]
}
```
The dashboard **shall store flags using a secure hashing mecanism** such as
[argon2](https://pypi.org/project/argon2-cffi).
#### Healthcheck Notification API
`mkctf-monitor` will push reports to the dashboard.
```
POST /mkctf-api/healthcheck
```
```json
{
"dont-mess-with-my-memory": true,
"stylish-leak": false,
}
```
Previous body means `dont-mess-with-my-memory` is healthy and `stylish-leak`
isn't.
Raw data
{
"_id": null,
"home_page": null,
"name": "mkctf",
"maintainer": null,
"docs_url": null,
"requires_python": ">=3.10",
"maintainer_email": null,
"keywords": "ctf, framework, cli",
"author": null,
"author_email": "koromodako <koromodako@gmail.com>",
"download_url": null,
"platform": null,
"description": "# mkCTF\n\n## Why ?\n\nThis framework aims at helping your team create jeopardy CTF challenges\nusing a configurable structure which will enable efficient integration and\ndeployment on the CTF infrastructure.\n\nThis project was initially created for managing challenges for\n[INS'hAck 2017](https://github.com/HugoDelval/inshack-2017).\n\nYou can find challenges and writeups of the past editions of INS'hAck in\n[this repository](https://github.com/InsecurityAsso).\n\nThis project evolved over time to enable even more automation when deploying\nchallenges on a Rancher-based infrastructure.\n\n\n## Caution\n\nYour mkCTF repository **shall remain private until the CTF event ends**. It\nstores flags in plaintext to allow CTF admins to rebuild challenges from\nsources without generating new flags. It is recommended to enable 2FA add\ndefensive layers to your repository. Do not generate or manage read-only access\ntoken lightly. Do not give access to your repository to untrusted users.\n\n\n## Dependencies\n\nThis project requires Python 3.9+ and has been designed and tested on Linux\nonly. It might work on Darwin and Windows Subsystem for Linux as well.\n\nOther dependencies will depend on the challenges themselves.\n\n\n## Setup\n\nYou can setup mkCTF in a few steps:\n\n```bash\ncurl -o setup.sh https://raw.githubusercontent.com/koromodako/mkctf/master/setup.sh\nchmod +x setup.sh\n./setup.sh\nrm setup.sh\n```\n\nThen create your first CTF:\n\n```bash\nmkdir example-ctf && cd example-ctf\nmkctf-cli init\n# then simply follow the terminal prompts\n```\n\n\n## Tools\n\nEach tool description may refer to concepts defined in **Concepts** section so\nmake sure to check it out if you encounter an new concept.\n\n\n### mkctf-cli\n\n`mkctf-cli` helps you and CTF co-authors to manipulate a mkCTF repository. It\nensures that challenges integration with the CTF infrastructure won't give you\na headache.\n\n\n\nYou can enumerate challenges to have a quick overview of the work progression\nand distribution across tags and categories.\n\n\n\nYou can also export public files of your challenges in a single command. Public\nfiles location in a challenge directory can be configured.\n\n\n\n\n### mkctf-monitor\n\n`mkctf-monitor` is an all-in-one monitoring solution running healthchecks on a\nregular basis and sending reports to the dashboard using an HTTP API defined in\n**Dashboard** section.\n\n\n\nOnce you have initialized your mkCTF repository, you can build a monitoring\nimage and run it by following this procedure:\n\n```bash\ncd example-ctf\nmkdir monitoring/ctf\ncp -r .mkctf challenges monitoring/ctf\nsudo DOCKER_BUILDKIT=1 docker build -t example-ctf-monitoring:1.0.0 .\nsudo docker container run --rm \\\n --env monitoring.env \\\n --name monitoring \\\n example-ctf-monitoring:1.0.0\n```\n\n\n## Concepts\n\n### Challenge\n\nChallenges are the base of jeopardy CTF. Each challenge can be described using\nsome metadata:\n\n```yaml\n# challenge author to be displayed on the dashboard\nauthor: someone\n# category in terms of infrastructure requirements\n# - `simple` means that the challenge is static (downloadable elements only)\n# - `server` means that the challenge requires a server and server can be shared\n# between all players, challenge vulnerabilities allow read-only access at most\n# - `sandbox` means that the challenge can be destroyed/altered by a player and\n# shall be allocated on a per team or player basis\ncategory: simple\n# challenge estimated difficulty to be displayed on the dashboard\ndifficulty: hard\n# enabled is set to true when the challenge is considered production-ready:\n# - it runs\n# - it is stable\n# - it has been integrated successfully with the CTF infrastructure\n# - it has been tested successfully (at least manually)\nenabled: false\n# challenge flag to be found by the player and to be used when building or\n# health-checking, it can be set manually or generated automatically\nflag: INSA{Th1s_Is_N0t_A_R34L_flag;)}\n# challenge logo to be displayed on the dashboard\nlogo_url: ''\n# display name of the challenge\nname: My New Challenge\n# number of points to be awarded when the challenge is solved. `-3` is a specific\n# value meaning that the number of points must be calculated dynamically for this\n# challenge\npoints: -3\n# slug of the challenge\nslug: my-new-challenge\n# static url of the challenge archive. It is generated automatically from repo\n# `salt` and `base_url`\nstatic_url: https://static.ctf.insecurity-insa.fr/9afb7029e93ed50c280c69c8443418c5683d05f8.tar.gz\n# tags are chosen by the author to specify the nature the challenge\ntags:\n- forensics\n```\n\n\n### Repository\n\nA repository contains a collection of challenges and monitoring resources. It\ncan described using some metadata:\n\n```yaml\ngeneral:\n # difficulties holds a list of difficulties which can be used to describe a\n # challenge complexity\n difficulties:\n - very easy\n - easy\n - medium\n - hard\n - insane\n # docker holds the information related to the registry where challenge images\n # will be stored.\n docker:\n registry: registry.example.ctf\n user: examplectf\n # domain holds the parent domain of all challenges\n domain: example.ctf\n # flag holds the prefix and suffix to be used for challenges\n flag:\n prefix: ECTF{\n suffix: '}'\n # tags holds a list of tags available to categorize challenge content\n tags:\n - for\n - rev\n - pwn\n - web\n - web3\n - prog\n - osint\n - radio\n - crypto\n - mobile\n - bounty\n - stegano\n# categories holds the list of files and directories to be created for each\n# infrastructure category (sandbox, server, simple)\ncategories:\n sandbox:\n dirs:\n private:\n - server\n public: []\n files:\n - exec: false\n from: Dockerfile.sandbox-server\n name: server/Dockerfile\n - exec: false\n from: Dockerfile.server\n name: server/Dockerfile.sandbox\n - exec: false\n from: banner\n name: server/banner\n - exec: false\n from: sshd_config\n name: server/sshd_config\n - exec: true\n from: sandbox_start.sh.jinja\n name: server/sandbox_start.sh\n server:\n dirs:\n private:\n - server\n public: []\n files:\n - exec: false\n from: Dockerfile.server\n name: server/Dockerfile\n simple:\n dirs:\n private:\n - private\n public: []\n files: []\n# display name of the jeopardy CTF\nname: ExampleCTF\n# standard holds the common files and directories to be created for each\n# challenge\nstandard:\n build:\n exec: true\n from: build.jinja\n name: build\n deploy:\n exec: true\n from: deploy.jinja\n name: deploy\n description:\n exec: false\n from: description.md.jinja\n name: description.md\n dirs:\n private: []\n public:\n - public\n files:\n - exec: false\n from: null\n name: .gitignore\n - exec: false\n from: writeup.md.jinja\n name: writeup.md\n - exec: false\n from: healthcheck.deps\n name: healthcheck.deps\n healthcheck:\n exec: true\n from: healthcheck.jinja\n name: healthcheck\n# static holds information about which domain will be used to serve each\n# challenge archive (exported using `mkctf-cli export /tmp/export-example`)\n# and a salt to make archive name impossible to predict\nstatic:\n base_url: https://static.example.ctf\n salt: # hex-encoded bytes (randomly generated)\n```\n\n\n### Standard Programs\n\nmkCTF framework defines some mandatory programs that have a specific purpose\nin the context of integrating each challenge into the CTF infrastructure. These\nprograms are described below.\n\n| Program | Purpose |\n|:-------:|:--------|\n| `build` | This executable builds the challenge from the sources and the configuration (flag) |\n| `deploy` | This executable perform the deployment-related operations for the challenge |\n| `healthcheck` | This executable performs a healcheck on the deployed challenge (checking checksum or playing an exploit) |\n\nPreviously defined programs shall respect the following specifications:\n\n| ID | Specification | Comments |\n|:----:|:-------------------------------------------------------------------------------|:---------|\n| `S0` | The executable **shall not take positional arguments** | The caller will not provide any positional argument |\n| `S1` | The executable **shall be able to to handle an optional** `--dev` **argument** | This argument might be given by the caller which will expect the executable to run in `development` mode when applicable |\n| `S2` | The executable **execution shall end before a timeout is triggered** | Timeout defaults to 2 minutes. `--timeout` option enable you to override this value |\n| `S3` | The executable **shall return an exit code** | This code will be interpreted using the rules defined in the next table |\n\nAs explained in `S3` the program exit code will be interpreted according to\nthe following table:\n\n| Exit Code | Meaning | Description |\n|:---------:|:-------:|:------------|\n| `0` | `SUCCESS` | The executable execution succeeded |\n| `2` | `N/A` | The executable does have a meaning in the context of this challenge |\n| `3` | `MANUAL` | The executable cannot perform this task entirely, you will have to get your hands dirty |\n| `4` | `NOT IMPLEMENTED` | The executable is not implemented yet |\n| _OTHER_ | `FAILURE` | The executable execution failed |\n\nWhen using `build`, `deploy` or `healthcheck` commands, the CLI will behave as\ndescribed below.\n\nIf the **exit code** differs from `0` executable output (both _stdout_ and _stderr_)\nwill be printed out. You can use this behavior to print meaningful instructions\nfrom within these programs. This behavior is particularly interesting if your\nprogram returns a code `3` which means the user must perform a manual operation\nto complete the task.\n\nA special status `TIMEOUT` may occur when using `build`, `deploy` or `healthcheck`\ncommands. In that case, it means that your executable took too long to execute\nas explained in specification`S2`.\n\n### Dashboard\n\nThe dashboard is expected to provide HTTP APIs defined below. Generic endpoint\nspecifications are the following:\n\n| ID | Specification | Details |\n|:----:|:--------------|:--------|\n| `R1` | The dashboard API **shall implement HTTPS with a valid certificate** | `mkctf-cli` will always use `https` scheme to post the configuration |\n| `R2` | The dashboard API **endpoint shall implement basic authentication** | `mkctf-cli` will set the Authorization header using Basic method |\n| `R3` | The dashboard API **endpoint shall expect a HTTP POST query** | `mkctf-cli` will POST challenge configuration to the dashboard |\n| `R4` | The dashboard API **endpoint shall expect a application/json body** | `mkctf-cli` will POST a JSON body to the dashboard |\n\n\n#### Configuration Synchronization API\n\n`mkctf-cli push` command allows to push every challenge configuration to the\ndashboard.\n\n```\nPOST /mkctf-api/push\n```\n```json\n{\n \"challenges\": [\n {\n \"name\": \"Dont Mess With My Memory\",\n \"slug\": \"dont-mess-with-my-memory\",\n \"tags\": [\n \"pwn\"\n ],\n \"flag\": \"ECTF{fake_flag_for_u_buddy}\",\n \"author\": \"koromodako\",\n \"points\": -3,\n \"enabled\": true,\n \"category\": \"sandbox\",\n \"logo_url\": \"\",\n \"difficulty\": \"easy\",\n \"static_url\": \"https://static.example.ctf/4f9bb3ac75a3cc0e5995aaa1af345ab62de6a697.tar.gz\"\n }\n ]\n}\n```\n\nThe dashboard **shall store flags using a secure hashing mecanism** such as\n[argon2](https://pypi.org/project/argon2-cffi).\n\n\n#### Healthcheck Notification API\n\n`mkctf-monitor` will push reports to the dashboard.\n\n```\nPOST /mkctf-api/healthcheck\n```\n```json\n{\n \"dont-mess-with-my-memory\": true,\n \"stylish-leak\": false,\n}\n```\n\nPrevious body means `dont-mess-with-my-memory` is healthy and `stylish-leak`\nisn't.\n",
"bugtrack_url": null,
"license": "MIT License Copyright (c) 2017-2024 koromdako Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the \"Software\"), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions: The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software. THE SOFTWARE IS PROVIDED \"AS IS\", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE. ",
"summary": "MaKe Capture The Flag",
"version": "7.0.6",
"project_urls": {
"Bug Tracker": "https://github.com/koromodako/mkctf/issues",
"Homepage": "https://github.com/koromodako/mkctf",
"Repository": "https://github.com/koromodako/mkctf"
},
"split_keywords": [
"ctf",
" framework",
" cli"
],
"urls": [
{
"comment_text": "",
"digests": {
"blake2b_256": "3a170d301ecadc77d72663bacc1ed4df8327528a0cd6c03fd887de2781c75e95",
"md5": "9fc7b846f1a1937e30493d7ae3663cd0",
"sha256": "1ccd000697b211103fdc7559c0bb9448034834ab450ec63c9e1674b308828af8"
},
"downloads": -1,
"filename": "mkctf-7.0.6-py3-none-any.whl",
"has_sig": false,
"md5_digest": "9fc7b846f1a1937e30493d7ae3663cd0",
"packagetype": "bdist_wheel",
"python_version": "py3",
"requires_python": ">=3.10",
"size": 42663,
"upload_time": "2024-10-18T20:02:22",
"upload_time_iso_8601": "2024-10-18T20:02:22.596834Z",
"url": "https://files.pythonhosted.org/packages/3a/17/0d301ecadc77d72663bacc1ed4df8327528a0cd6c03fd887de2781c75e95/mkctf-7.0.6-py3-none-any.whl",
"yanked": false,
"yanked_reason": null
}
],
"upload_time": "2024-10-18 20:02:22",
"github": true,
"gitlab": false,
"bitbucket": false,
"codeberg": false,
"github_user": "koromodako",
"github_project": "mkctf",
"travis_ci": false,
"coveralls": false,
"github_actions": false,
"lcname": "mkctf"
}
