XOR Brute Force Tool

XOR compares two bits and returns 1 only when they differ: 0 XOR 0 = 0, 0 XOR 1 = 1, 1 XOR 0 = 1, 1 XOR 1 = 0. Applied to a byte it flips every bit where the key byte has a 1. The key trick is that XOR undoes itself: (p XOR k) XOR k = p. So the same key encrypts and decrypts, and from any two of plaintext, key and ciphertext you can compute the third.

A worked byte: the letter f is 0x66 (01100110). With the key byte 0x2a (00101010) the result is 0x4c (01001100), the letter L. XOR 0x4c with 0x2a again and you are back at 0x66. Real CTF files repeat this for every byte; with a longer key, byte i is combined with key byte i mod key length.

A one-byte key has only 256 possibilities, so the tool tries all of them and ranks the outputs. Printable text alone is a weak test: for the 16-byte sample 4c464b4d51524558754359754c5f4457, 50 of the 256 keys give output that is entirely ASCII printable (0x20–0x7E), and 53 if tab, line feed and carriage return are also allowed. The ranking therefore uses an English score as well, plus a flag-prefix badge.

The English score compares the letter-and-space mix of the output with English (26 letters and the space; digits and punctuation are neutral), multiplies by the share of bytes that count and subtracts a penalty for control and high bytes. For text in scripts without ASCII letters (Chinese, for example) the English score is near zero, so the tool also measures the share of bytes inside valid multi-byte UTF-8 sequences (counted only when at most 2% of the bytes are invalid) and ranks by the larger of the two, the text score. The table is sorted by flag-prefix tier, then text score, then text-like share, then the key. Entropy is shown as a hint and never used for ranking. Key 0x00 appears as the unchanged input so you can see it is a candidate, not a result.

When the key is longer than one byte, the tool scores every length from 2 to 40 that has at least 8 × length bytes of data with two measures. The Hamming score takes the bit distance between four pairs of neighbouring blocks, averages them and divides by the length (lower is better). The Index of Coincidence is computed per column and averaged (higher is better). Each measure ranks the lengths, the two ranks are averaged, and ties go to the smaller length.

This is a guided repeating-key attack, not an exhaustive search of every possible multi-byte key: statistical key-length estimates and per-column scoring narrow the candidates (the top 3 key bytes per column), and you can correct any byte by hand. Length detection is ambiguous by nature, so the tool shows the combined top 5 plus the top 3 of each measure, says when the two measures disagree and lets you type any length from 1 to 64. For the 228-byte prose fixture encrypted with the key ICE (true length 3), the combined top 5 is 24, 27, 6, 12, 18; length 3 appears only through the Index of Coincidence top 3, and the tool shows the disagreement notice. For the same text with the key flag (true length 4), length 28 ranks first and length 4 second, which is the Index of Coincidence favouring multiples when columns are short.

When most of the best lengths share a divisor that is not itself listed (for example 36, 33, 6, 24 and 30 all divide by 3), the tool adds a hint to check that divisor, because multiples of the true length often score best; it is a hint and never a decision. Once a length is chosen each column is solved as a single-byte XOR with the English score, and the top 3 key bytes per column stay clickable so a wrong byte can be changed. There is also a most-frequent-character mode: tell the tool the most common plaintext byte (space or null) and each key byte is taken from the most common ciphertext byte in its column.

If you know any part of the plaintext, the key is the ciphertext XOR the known bytes. Enter the crib, the byte offset where it sits in the ciphertext and, if you know it, the key length. Key position for crib byte i is (offset + i) mod length. If two recovered bytes land on the same key position and differ, that length is rejected and the first conflict is shown.

Without a length the tool tests every period shorter than the crib and proposes the smallest consistent one. On the sample 0d09180c1e010417260216260d101716 the crib flag{ at offset 0 recovers the bytes k e y k e; periods 1, 2 and 4 are inconsistent, 3 is consistent and the key is key. The crib xor at offset 5 with length 3 recovers y, k, e at key positions 2, 0, 1 — the first recovered byte is key byte 2, not byte 0. A crib that covers only some key positions leaves ? at the others and the tool will not decrypt until they are filled.

File header cribs apply the same idea to the start of common files: MZ (4D 5A), ZIP (50 4B 03 04), PNG (the first four signature bytes, 89 50 4E 47), GIF (47 49 46 38, “GIF8”), PDF (25 50 44 46, “%PDF”), ELF (7F 45 4C 46) and gzip (1F 8B 08). Only these leading bytes are used, so a header crib fixes at most four key bytes. If every derived key byte is equal, that is a single-byte key (MZ 90 00 encrypted with 0x5c starts 11 06 cc 5c, and the MZ header gives 0x5c).

If two messages were encrypted with the same keystream starting at the same position, XORing the two ciphertexts cancels the keystream and leaves plaintext 1 XOR plaintext 2. Guess a word in one message and slide it along; the bytes it implies in the other message are shown at every offset, and readable ones are highlighted. Equal key length is not enough: with a repeating key the same key started at a different phase does not cancel.

Example: attack at dawn and retreat at six, both encrypted with the repeating key K3y!. The crib “ at ” at offset 6 gives “t at” in the other message. When the second message is shifted by one key position, the same crib gives 2c 4a 19 3e, which is not text — the method does not apply. If the messages differ in length, only the overlap is used and the extra bytes are reported as unmatched.

File scan searches for text-like runs and selected file signatures under each of the 256 single-byte keys; it does not decrypt and validate the whole file, and a hit does not prove that a recovered file is valid or fully decrypted. It covers a whole file or a byte range, read in 1 MiB pieces. For each key it reports the longest text-like run, the number of runs of at least N bytes (default 16) and signature candidates for ZIP, PNG, PDF, GIF and ELF at any offset, and MZ only at the start of the range. Runs and signatures that cross a 1 MiB boundary are counted once. You can cancel; a cancelled scan keeps what it found and is labelled partial.

Single-byte search versus multi-byte search: the single-byte mode tests exactly 256 keys and ranks them, so its limit is that the ranking can mislead on short data; the multi-byte mode is a bounded exhaustive search whose key count depends on the key length and the byte set you allow, so its limit is a search space that can become enormous. Multi-byte keys: a 2-byte key has 65,536 possibilities; a 4-byte key over every byte value has 4,294,967,296, which the page refuses to start. Pick a smaller byte set (printable characters, letters and digits, lowercase letters or hex digits) and the page shows the exact key count, measures this device's speed on a short test and gives a time estimate — an estimate, not a promise. Keys are screened on the first 256 bytes.

Rolling XOR uses the previous byte as part of the next byte's key, and the two variants behave differently: with the previous ciphertext byte (c[i] = p[i] XOR c[i-1]) the start value affects only the first plaintext byte; with the previous plaintext byte (c[i] = p[i] XOR p[i-1]) the start value carries through every later byte. Counter XOR changes the key by position: c[i] = p[i] XOR ((start + i × step) mod 256), with a step you set (default 1). The tool tries all 256 start values for each mode. A chained-steps panel runs XOR, Base64 decode or encode and hex decode or encode in order and keeps every stage. A settings link copies only the method, format, flag switches, offset, key length and charset — never the input, a key, a crib or any output.

Short ciphertexts decode to printable-looking text under many keys: 50 of 256 for the 16-byte sample. Treat the top row as a lead. Check that the preview is a sentence you recognise, that the flag badge (if any) matches a prefix you expect, and that the UTF-8 line reports no invalid sequences. Binary payloads are legitimate: a candidate with control bytes is ranked lower, never removed.

Garbled output usually means a wrong key length or one wrong key byte (compare the neighbouring candidates in the column solver), data that was not XOR to begin with (try the Encoding Auto-Decoder first for Base64 or hex layers), a key that is longer than the data allows the length detection to see (fewer than 8 × length bytes), or a variant such as rolling XOR. Null bytes in the input and the key are preserved, so an all-zero stretch of output often means the key byte equals the ciphertext byte there.