ctfpal for instructors

Why it works in a classroom

Nothing to install
It is a web page. A student on a locked-down lab machine, a Chromebook, or a borrowed laptop has exactly the same environment as everyone else. There is no virtualenv to break and no package that fails to compile ten minutes into the session.
Nothing leaves the browser
Every algorithm runs client-side. Challenge files, hashes, and pasted text are never uploaded, so there is no third-party service processing student work and no data protection question to answer before the first class.
No accounts, no roster, no cost
There is no sign-up, no per-seat licence, and no free tier that expires mid-semester. Nothing to administer and nothing to renew.
It works offline
The page registers a service worker and caches itself. Once loaded, it keeps working without a network - which matters in an isolated lab, and matters more during a live competition when the venue wifi collapses.
Algorithms, not a black box
There is no generative AI in the solving path: results come from named, deterministic algorithms that produce the same answer every time, which is what makes them teachable and gradeable. Every tool page explains the method - chi-squared scoring, index of coincidence, Hamming-distance keysize detection, continued fractions - so students learn the technique rather than which button produces a flag.

For your IT or data protection review

ctfpal is a static web application. All processing - decoding, cryptanalysis, hashing, file parsing, steganography extraction - happens in the browser using JavaScript and WebAssembly. Files that students open are read locally through the File API and are never transmitted. The application has no user accounts, no authentication, and no server-side storage. It uses Google Analytics, which records page views: which pages were opened, the kind of device, and the approximate region. No student input, file, or workspace content is passed to it. Workspace state is stored in the browser’s own IndexedDB on the student’s machine and can be cleared like any other site data. The source is public and MIT licensed, so it can be reviewed, forked, or self-hosted on institutional infrastructure.

Three features send student work outbound, and only when a student explicitly uses them. The HTTP request replayer and the path scanner send requests to a target the student names - both are for authorised targets only, and are covered by the responsible-use note below. The optional LLM triage helper sends the student’s input to whichever provider their own API key belongs to; it is off unless a key is entered, it is never wired into a solver, and the alternative in-browser model runs locally with no requests at all. If sending student work to a third-party model is not acceptable in your setting, simply do not issue a key - every other tool is unaffected.

Take it away with you

A list of modules is not a lesson. These are the documents between a syllabus and something you can walk into a room holding - all printable, all MIT licensed, none of them asking for an email address.

Course syllabus

The whole course as one printable document - hours, objectives, assessment, the data-protection statement, and the responsible-use policy, in the order an approvals committee asks for them.

Lesson packs

One per module: minute-by-minute running order, what to demonstrate live, the practice set, the gradeable checkpoint, and where the room reliably stalls. Each module links its own pack.

Classroom link builder

Produces a URL that opens ctfpal with this challenge already loaded.

Challenge title

The module outline

Copy this into a syllabus as-is, or take the formatted version. Each module links to a student page with objectives, the lesson, the tools, practice challenges ordered by difficulty, and a gradeable checkpoint - and to a lesson pack for teaching it.

Foundations

Triage, encodings, statistics and the habits every other track assumes.

Cryptography

Not the primitives - the ways they are wired up wrong: reused keys, weak parameters, leaking oracles.

Web and applications

From finding the endpoint nobody linked to, through injection and the browser's trust model, to code running on the server.

Forensics and defence

Files, captures, memory images and malware - reading what happened out of what was left behind.

Reversing and exploitation

Binaries, mobile apps, firmware and contracts: what the code really does, and what it does when you break it.

Ways people use it

A full semester
One module per week, with the checkpoint as the weekly deliverable and the practice challenges as homework. A fourteen-week term fits Foundations plus three of the four remaining tracks; a full year fits all five. The advanced modules - binary exploitation, fuzzing, memory forensics - are heavier and comfortably expand to two weeks each.
One track at a time
The tracks are self-contained after Foundations, so a crypto elective, a web-security unit and a reversing unit can each be taught on their own. Each module names the modules it assumes, so a student arriving mid-sequence can see what to read first.
A single workshop
Modules 1 to 3 stand alone as a three-hour introduction that takes a room of complete beginners to a solved crypto challenge. No prerequisites beyond a browser.
A competition prep session
Skip the curriculum and use the decision guide directly. It is organised by symptom rather than technique, which is the shape a team needs during a live event.
A lab reference
Point students at the tool index and let them use it alongside whatever material you already teach. Each page is a self-contained explanation of one technique.

What this is not

It is not a learning-management system, and it will not become one. There is no roster, no sign-in, no submission, no gradebook and no progress dashboard - not because those are hard, but because every one of them requires an account and a server holding your students’ work, which is the exact thing that lets this site promise that nothing a student pastes ever leaves their own machine. You cannot have both, and this is the half we chose.

Practically, that means the checkpoint in each module is written to be graded the way a lab exercise is graded - the student shows you the artifact and says how they got it - and the practice challenges check themselves in the browser for the student’s own benefit, with nothing reported anywhere. If your institution requires completion tracking, run this alongside a platform that does that (picoCTF’s classroom features and CTFd both do it well) and use these pages as the material rather than the system of record.

Two smaller limits, said plainly so you find them here rather than in front of a class. The dense workspace panels are laid out for a laptop: reading works on a phone and is tested that way, and a handful of essentials are usable with a thumb, but a student on a phone alone cannot follow a full module. And the curriculum links out to real challenges hosted by other people - picoCTF above all, now part of CMU’s CyLab Security Academy - so a term plan should be checked the week before it runs, the same as any syllabus with external readings.

Responsible use

Several tools here - the request replayer, the path scanner, the payload catalog, the reverse shell generator, the padding oracle driver - perform active testing against a target the user names. Used against systems the user does not own and has no written permission to test, that is a criminal offence in most jurisdictions, and a student who learns the technique without learning that boundary has been taught badly.

The module on web attacks flags this explicitly, and every relevant tool page repeats it. We would encourage covering it before the tools rather than alongside them.