This is the platform for TJCTF. It's (what I think is) the best of the MITRE, CTFd, and picoCTF platforms rolled up into a Flask application.
I'm bad at naming things.
You're going to want to edit config.py
. The variable names should be fairly
self-explanatory.
You're going to want to create a file called secrets
. It will look like this:
mailgun_url: https://api.mailgun.net/v3/tjctf.org
mailgun_key: key-asdflkjasdhflkjsdahflkhsdaklfjhasd
recaptcha_key: asdlkfjhasdlkjfhlsdakjfh
recaptcha_secret: sdakjfhsdalkfjhsdalkfjh
key: this can be anything you want, it is your flask secret_key
You should edit line 2 of database.py, unless you want to use SQLite. This uses Peewee, so you can use any Peewee-supported database.
You can create some problem YAML files that look like this:
name: Problem Name
author: ME!
category: Binary
description: binary binary binary binary. i love binary
points: 250
flags: "flag{whatever}"
Then add them with ./ctftool add-challenge problem.yml
and it'll get put in the
database.
Run python app.py
and you have a server running. You probably want to deploy
it with gunicorn
or similar, long-term.
You can do some really fancy stuff with ctftool
. If you have a directory structure
like this:
- ctf-platform
- ctf-problems
- problem1
- problem.yml
- static.yml
- problem2
- problem.yml
- static.yml
- problem3
- problem.yml
- problem4
- problem1
You can run ./ctftool scan ../ctf-problems/
and get a fully populated database
with information from all the problem.yml files, and automatically generated
static file names, and automatic substitutions for static file links in
problem.yml. More documentation on this to come soon.
Flagbase is under really heavy development right now. That means
-
Absolutely do submit issues: bugs and feature requests are awesome.
-
Don't submit a pull request for:
- a major feature addition
- database model changes
-
Do submit pull requests for:
- documentation addition/edits
- minor bugfixes
- small changes to existing features
If you're touching database.py
or config.py
, you're probably doing it wrong.
If you decide to ignore my guidelines, write detailed documentation on what your pull request consists of, what problems it fixes, how it works, and what issues it could bring up.
Of course, you are more than welcome to fork the repository.