Pocket CTF Reference · Device home

Pocket CTF Glossary

Use this glossary when a module, artifact, or tool introduces an unfamiliar term. Definitions describe how Pocket CTF uses each term; they are not complete standards or protocol specifications. For practical instructions, follow the linked sections of the student guide.

A–C

Access control. The rules and checks that decide who may read, change, or use a resource. Access control includes authentication and authorization, but it can also depend on ownership, role, location, or another policy.

Application programming interface (API). A defined way for software to request data or actions from other software. A web API commonly accepts HTTP requests and returns structured data instead of a rendered page.

Artifact. A file, record, message, page, or other item examined during an investigation. Treat an artifact as evidence only after recording where it came from and what it actually shows.

Asymmetric cryptography. Cryptography that uses a related public and private key pair. The public key can be shared; the private key must remain secret. Encryption and digital-signature schemes use the pair in different ways.

Authentication. Establishing an identity or the origin of data. A login authenticates a user; a valid digital signature can authenticate a publisher. Authentication does not by itself decide what the identity is allowed to do.

Authorization. Deciding whether an authenticated or otherwise identified request may perform a specific action on a specific resource. A system must check authorization on the server for every protected request.

Base64 and Base64url. Encodings that represent bytes with printable characters. Base64url substitutes URL-safe characters and may omit trailing padding. Neither form encrypts or protects the encoded data. See Base64.

Body. The content carried after the headers in an HTTP request or response. A body may contain form fields, JSON, HTML, a downloaded file, or another data format.

Browser developer tools. Built-in browser panels for inspecting page structure, source, storage, requests, responses, and console messages. The browser basics explain the panels used in Pocket CTF.

Brute force. Trying many possible values until one succeeds. Pocket CTF prohibits brute-force traffic against the board; use evidence to narrow a problem and perform any permitted small search locally.

Byte. A group of eight bits. Files, messages, keys, and hashes are sequences of bytes even when a tool displays them as text, hexadecimal, or Base64.

Certificate. A signed digital document that associates an identity with a public key and related details. Trusting a certificate requires checking its signature, validity, intended use, and issuing authority.

Checksum. A value calculated from data to help detect accidental changes. Some checksums use cryptographic hash functions, but a checksum alone usually does not prove who created or authorized the data.

Ciphertext. Data produced by encryption. It should be unreadable without the required key, though its length, structure, or handling can still reveal information.

Client. Software that sends a request to a server. In Pocket CTF, the client is usually a browser or an instructor-approved command-line HTTP tool.

Cookie. A small name-and-value item a server asks a browser to return with later requests. Cookies often identify a session, remember a preference, or carry application state. See Inspect and change a challenge cookie.

Credential. Data used to establish an identity or gain access, such as a password, token, private key, or certificate. Credentials should be scoped, stored safely, rotated when exposed, and never embedded where unauthorized users can recover them.

Cryptography. Techniques for protecting information and establishing properties such as confidentiality, integrity, or authenticity. A cryptographic operation provides only the properties its design and key use support.

D–H

Decoding. Reversing an encoding so the original representation can be read or processed. Decoding Base64 or hexadecimal does not defeat encryption.

Digital signature. A value created with a private key and checked with the related public key. A correctly designed and verified signature can establish data integrity and origin without revealing the private key.

Directory traversal. Causing an application to resolve a user-controlled path outside the directory it intended to expose. Safe applications normalize paths and enforce an allowed root on the server.

Encoding. Representing information in a defined format so another system can store, transmit, or interpret it. Encoding is reversible without a secret and is not encryption.

Encryption. Transforming plaintext into ciphertext using a key to provide confidentiality. Encryption alone does not necessarily establish integrity or authenticity.

Endpoint. A particular API or service location that accepts requests. An endpoint is usually identified by a URL path and the HTTP methods it supports.

Evidence. An observable fact that supports or challenges a conclusion. Strong notes separate the artifact, observation, tool or action, and interpretation so another person can reproduce the reasoning.

File metadata. Information about a file or its content that is separate from the main visible material, such as creator, timestamps, location, software, or embedded attachments. Removing visible content does not necessarily remove metadata. See the file recipes.

Finding. An evidence-backed conclusion in a scenario track. A finding states what the evidence establishes without claiming more certainty than the evidence supports.

Firmware. Software stored on and executed by a hardware device. Pocket CTF runs as an application on a MicroPython firmware runtime.

Flag or seal. A completion token returned after a module accepts a result. Scenario tracks may call the token a seal. A flag records completion; the learner should still be able to explain the evidence and reasoning.

Form data. Name-and-value fields submitted by an HTML form or equivalent HTTP client. A server must validate form data even if the browser marks a field as hidden, disabled, or restricted. See Submit form data.

Hash function. A one-way function that maps data of any length to a fixed-length digest. A cryptographic hash is designed to make collisions and recovery of the original input impractical. An unkeyed hash can detect change, but it does not identify who supplied the data. See SHA-256.

Header. A named piece of metadata in an HTTP request or response. Headers describe matters such as content type, cookies, caching, supported methods, or authorization. Unless a trusted intermediary removes or replaces it, a request header can be supplied by the client.

Hexadecimal (hex). A base-16 representation commonly used to display bytes, addresses, hashes, and keys. Two hexadecimal digits represent one byte. Hex is an encoding, not encryption. See Hexadecimal.

Hint. A staged prompt that advances an investigation without supplying the answer. Reveal one hint, test the idea, and request another only if needed.

HMAC. A standard keyed message authentication code built from a cryptographic hash function. HMAC provides integrity and authenticity to parties that share the secret key; it does not encrypt the message.

HTML. The markup language used to structure web pages. View Source shows the HTML originally returned by the server, while the browser inspector shows the current document after browser processing and script changes.

HTTP. The request-and-response protocol used by web browsers and APIs. A Pocket CTF request has a method, path, headers, and sometimes a body; the response has a status code, headers, and usually a body.

HTTP method. The request operation, such as GET, POST, or OPTIONS. Applications may define additional methods. A server must authorize an action based on what it does, not assume an unusual method is safe. See Ask which HTTP methods are supported.

I–M

Identifier. A value used to name or select an object, record, user, or session. An identifier locates something; it is not proof that the requester is authorized to access it.

Insecure direct object reference (IDOR). An access-control flaw in which a requester can change an identifier and reach an object the server did not authorize them to access. The fix is a server-side authorization check, not an identifier that is merely difficult to guess.

Integrity. Confidence that data has not changed in an unauthorized or unexpected way. A hash can help compare copies, while a MAC or digital signature can also authenticate the source when its key assumptions hold.

Initialization vector (IV). A value used with some encryption modes to make repeated encryption of similar plaintext behave differently. Its security requirements depend on the mode; an IV is not normally the secret key.

JSON. A text format for structured values such as objects, arrays, strings, numbers, booleans, and null. Field names and nesting are part of the data and should be preserved when comparing records. See JSON and JSON Lines.

JSON Lines (JSONL). A format containing one complete JSON value per line. It is useful for event streams and logs because each line can be processed as a separate record.

Key. A value that controls a cryptographic operation. Depending on the scheme, the key may be a shared secret, a public key, or a private key. An algorithm name does not compensate for weak generation, reuse, disclosure, or incorrect key handling.

Message authentication code (MAC). A keyed value used to check message integrity and authenticity between parties that share a secret. A MAC is not a digital signature because any holder of the shared key can create it.

Metadata. Data that describes or gives context to other data. Metadata can be operationally useful and privacy-sensitive even when it is not visible in the main content.

Module. One playable Pocket CTF challenge. A module has an objective, investigation surface, hints, and completion result within a profile or track.

N–R

Nonce. A value intended for one-time use in a cryptographic protocol. Reusing a nonce can reveal relationships between messages or, in some schemes, expose a private key.

Oracle. A system behavior that reveals a small fact about otherwise secret processing, often through different status codes, messages, or timing. Many carefully chosen observations can turn a small difference into a serious information leak.

Padding. Extra bytes added so data fits a required size or format. Secure code validates padding without exposing distinct error behavior that reveals information about decrypted data.

Parameter. An input supplied to an operation. In a web request, parameters may appear in a path, query string, form body, JSON body, cookie, or header.

Path. The part of a URL that identifies a location or resource on a server. File systems also use paths; a URL path does not necessarily map directly to a file.

Payload. The primary data carried by a request, response, record, token, or packet, as distinct from the surrounding structure and metadata.

Plaintext. Data before encryption or after successful decryption. Plaintext does not have to be human-readable text; it can be any bytes.

Profile. A deployable Pocket CTF selection. Each playable profile contains six modules. Core profiles represent difficulty levels; each scenario track is also deployed as its own profile. The selectable docs profile instead serves the Documentation site.

Protocol. A set of rules for how participants format messages, order actions, and interpret results. Security depends on the complete protocol, not only the strength of an individual cryptographic operation.

Proxy. Software that receives a request or response and forwards it, possibly adding or changing information. A server should trust proxy-supplied identity or network headers only when requests can arrive through a controlled, authenticated proxy path.

Query string. The portion of a URL after ?, commonly containing encoded name-and-value parameters separated by &. Repeated names and decoding rules can cause different layers to interpret the same query differently. See Change a URL safely.

Redaction. Removing sensitive information from a released artifact. Covering text or pixels visually is not sufficient if the original data remains selectable, searchable, embedded, or recoverable from metadata.

Replay. Reusing a previously valid message or operation in a new context. Fresh nonces, sequence numbers, timestamps, and server-side replay tracking can help a protocol reject duplicates.

Request. A message a client sends to a server. For HTTP, record the method, URL, headers, and body when comparing two requests.

Response. A message a server returns for a request. An HTTP response includes a status code, headers, and usually a body.

Route. An application's rule that maps a request path and method to the code that handles it. Several methods may share a path while producing different behavior.

S–Z

Server. Software that receives requests and returns responses or performs actions. The Pocket CTF board is the server even when the learner's browser controls some request values or locally displayed page state.

Session. Server or client state that connects a sequence of requests to one browser or participant. Pocket CTF uses a session cookie for progress, hints, and per-boot completion state.

Side channel. Information leaked through something other than the intended result, such as timing, response size, error type, or resource use. An oracle is a side channel when its observable differences reveal secret processing.

Source or page source. The original HTML response sent by a web server. Page source can contain comments, links, form fields, or scripts that are not visible in the rendered page.

Status code. The three-digit result category in an HTTP response. A status code is evidence about how the server handled a request, but its meaning must be interpreted with the response body and application behavior.

Symmetric cryptography. Cryptography in which participants use the same secret key, or directly related secret keys. Symmetric encryption and MACs are fast, but every party with the shared key must protect it.

Token. A compact value representing identity, permission, state, or a completed action. A token may be opaque or structured; its meaning and security depend on server-side validation, integrity protection, lifetime, and scope.

Track. A themed collection of Pocket CTF modules. A scenario track uses a shared setting and may require evidence to be compared across modules.

Trust boundary. A point where data or control passes between components with different levels of trust. Validate and authorize information as it crosses the boundary instead of trusting it because of its field name or claimed origin.

Uniform resource locator (URL). The address of a web resource. A URL can contain a scheme, host, port, path, query string, and fragment.

URL encoding. A representation that replaces characters with % followed by hexadecimal byte values when needed in a URL or form body. Decode according to the component's rules before comparing values.

Verification. Checking a claim against evidence and stated rules. In Pocket CTF documentation, a verified document has also been tested against the recorded engine version and any applicable hardware.

Vulnerability. A weakness that can cause a system to violate a security or privacy requirement. A useful report identifies the affected behavior, evidence, impact, and a proportionate defensive control.

XOR (exclusive OR). A bitwise operation that produces 1 when two input bits differ. XOR is reversible with the same input and appears in many cryptographic constructions; XOR by itself is not secure encryption.

Common distinctions

Verification scope

This glossary covers the shared web, data, evidence, and cryptography terminology used by Pocket CTF 0.4.0. It was checked against all student and instructor module pairs and the physical Pico W flows on 2026-09-20. Classroom, accessibility, and print review remain open.