Binary Digits picoCTF 2026 Solution

Description

1. Step 1Inspect how the digits are framed

   Observation

   The file is 71096 bytes of ones and zeros. Before slicing them into groups of eight, find out whether spaces or newlines sit between the bits.

   Look at the first ~200 bytes with od -c. You need to know whether '0' and '1' are space-separated, newline-separated, or contiguous before you slice into 8-bit groups.

   bash

   head -c 200 digits.bin | od -c

   Copied!

   bash

   wc -c digits.bin

   Copied!

   Expected output

   0000000   1   1   1   1   1   1   1   1   1   1   0   1   1   0   0   0
   0000020   1   1   1   1   1   1   1   1   1   1   1   0   0   0   0   0
   0000040   0   0   0   0   0   0   0   0   0   0   0   1   0   0   0   0
   ...
         71096 digits.bin

   What didn't work first

   Tried: Run 'xxd digits.bin' or 'hexdump digits.bin' to inspect the file instead of od -c.

   xxd and hexdump show the hex value of each byte, confirming the file holds ASCII zeros and ones, but their columnar layout hides whether separators sit between the bits. od -c prints the character for each byte, so whitespace shows up as its own visible entry.

   Tried: Skip the inspection step and assume 8-bit grouping with no separators based on the file size.

   If newlines follow every eighth bit, a common layout, wc counts them too and dividing by 8 gives the wrong byte count, which misaligns every slice. The od -c pass reveals separators so you can strip them first.

   Learn more

   od -c prints each byte as a printable character (or escape), so you immediately see whether the file is one long run of 0/1, or whether there are spaces, tabs, or newlines between groups. wc -c divided by the bit-grouping (usually 8) tells you how many bytes the decoded flag should be, which catches off-by-one mistakes early.

2. Step 2Inspect the file

   Observation

   Ones and zeros means ASCII-encoded binary rather than raw bytes. Read the content directly to confirm before decoding anything.

   Open digits.bin and confirm it contains a sequence of '1' and '0' ASCII characters representing binary data.

   bash

   cat digits.bin

   Copied!

   What didn't work first

   Tried: Run 'file digits.bin' or 'xxd digits.bin | head' to determine the file type before reading it.

   file reads the magic bytes and correctly reports ASCII text, which says nothing about the encoding. xxd shows the byte values, but the hex listing reads as noise without context. Printing the content shows the pattern of ones and zeros at a glance.

   Tried: Try to open digits.bin in an image viewer or treat it as a raw binary file after seeing it is 71096 bytes.

   The file holds ASCII characters, not pixel data, so a viewer either fails or shows garbage. Decode first, eight characters to a byte, then save the result as a JPEG and open that.

   Learn more

   The distinction between binary data and ASCII text representing binary is fundamental. The file here contains the literal characters '0' (ASCII 48) and '1' (ASCII 49) - not actual binary values 0 and 1. The file is valid text that you read with your eyes and then interpret mathematically.

   This encoding is common in low-level education and CTF introductory challenges because it makes binary arithmetic visible. Every 8 characters form one byte (octet), and each character position represents a power of two from 2⁷ (128) down to 2⁰ (1). For example, 01100101 = 0+64+32+0+0+4+0+1 = 101 = ASCII 'e'.

   In real-world applications, binary-to-text representations are used whenever binary data must traverse a text-only channel: Base64 is the most common (used in email MIME, JSON web tokens, and PEM certificates), while raw binary-as-ASCII is mostly pedagogical or used in signal-level protocols like old-school modems.

3. Step 3Decode binary in CyberChef or Python

   Observation

   The file holds ASCII zeros and ones with no separators, so group them eight at a time and convert each group base 2. The JPEG magic bytes at the front confirm the output is an image.

   The fastest path is CyberChef: paste the binary string, add a "From Binary" operation, and the decoded data appears. The file decodes to a JPEG image. Save the output as a .jpg and open it to see the flag hidden in the image. See CTF encodings for the broader toolkit.

   python

   python3 -c "
   data = open('digits.bin').read().strip().replace('\n','').replace(' ','')
   img = bytes(int(data[i:i+8],2) for i in range(0,len(data),8))
   open('decoded.jpg','wb').write(img)
   print('Saved decoded.jpg - open it to see the flag')
   "

   Copied!

   What didn't work first

   Tried: Use CyberChef 'From Hex' or 'From Base64' instead of 'From Binary' because the file extension is .bin.

   The .bin extension says the content is binary in concept, not that it is hex or base64. The bytes on disk are ASCII zeros and ones, so only the From Binary operation reads them correctly. From Hex wants pairs of hex digits and From Base64 wants its own alphabet; both garble a string of ones and zeros.

   Tried: Decode directly with 'int(data, 2)' on the entire string and then call chr() on the result, expecting a flag string.

   Converting the whole string at once gives one very large number, not a sequence of bytes. Slice it into eight-character chunks and convert each separately into a bytes object. And the result here is a JPEG rather than text, so chr() fails too: write raw bytes and open the file as an image.

   Learn more

   Python's int(bits, 2) converts a binary string to an integer using base 2. Slicing with data[i:i+8] steps through the string in 8-character windows, one byte at a time. Building a bytes object first lets you call .rstrip(b'\x00') to strip trailing null padding before decoding - many encoders zero-pad to a block boundary, and a stray \x00 in the decoded string trips up downstream tooling.

   The same logic applies to other bases: int(s, 8) for octal, int(s, 16) for hexadecimal. bytes.fromhex() and base64.b64decode() handle the most common CTF encodings.

   A useful mental shortcut: printable ASCII (32-126) fits in 7 bits, so the MSB is always 0 for those characters. If the flag is all printable ASCII you can sanity-check by confirming every 8th bit is 0, but always slice the full 8 bits when decoding so you don't mangle non-ASCII bytes.

Flag

The binary string decodes to a JPEG image. Use CyberChef 'From Binary' to decode, save as .jpg, and open the image - the flag text is printed on it. The flag is shown abbreviated on this page; work the steps above to recover the full value.