whats-the-difference picoCTF 2019 Solution

Description

1. Step 1

   Compare the two files byte by byte

   Observation

   I noticed the challenge described kitters.jpg and cattos.jpg as looking 'nearly identical' but guaranteed a difference, which suggested the images shared the same visual content while hiding data in individual byte values that fall below the threshold of visual perception and required a byte-level comparison to extract.

   Read both files in binary mode, zip them together, and collect every byte that differs between them. The differing bytes from cattos.jpg are ASCII characters that spell out the flag.

   python

   python3 -c "a=open('kitters.jpg','rb').read(); b=open('cattos.jpg','rb').read(); print(''.join(chr(y) for x,y in zip(a,b) if x!=y))"

   Copied!

   Expected output

   picoCTF{th3yr3_a5_d1ff3r3nt_4s_bu773r_4nd_j311y_...}

   What didn't work first

   Tried: Running 'diff kitters.jpg cattos.jpg' to find the differing bytes

   The 'diff' command operates line by line on text and treats binary files as opaque blobs, so it reports 'Binary files kitters.jpg and cattos.jpg differ' with no further detail. The correct tool for byte-level comparison is 'cmp -l' or a Python script that reads both files in binary mode ('rb') and iterates every byte position.

   Tried: Collecting the bytes from kitters.jpg instead of cattos.jpg - using 'chr(x)' rather than 'chr(y)' in the zip loop

   Swapping which file's byte is collected prints the original cover bytes rather than the substituted flag characters, producing garbled JPEG data instead of readable ASCII. The flag is encoded in cattos.jpg, so 'y' (the second file) must be selected when the pair differs.

   Learn more

   This challenge hides the flag by substituting individual bytes in an image file at specific positions. Visually, the images are indistinguishable - the changed bytes represent tiny color variations invisible to human perception. But a byte-by-byte comparison instantly reveals every differing position and its value.

   The Python approach here uses zip(a, b) to pair up bytes at identical positions from both files simultaneously, then filters to pairs where x != y (the byte differs) and collects the byte from the second file (cattos.jpg). Since the differing bytes are ASCII characters spelling the flag, joining them with ''.join(chr(y) ...) produces the readable flag string.

   The standard Unix tool for binary file comparison is cmp (byte-by-byte comparison) or diff (line-by-line for text files). For binary files specifically:

   • cmp -l file1 file2 - list all differing byte offsets and values
   • xxd file | diff - <(xxd file2) - hex dump diff for visual inspection
   • vbindiff file1 file2 - interactive binary diff viewer
   • dhex file1 file2 - another hex diff tool

   In real-world digital forensics, binary diffing is used to analyze firmware patches (to see what vulnerabilities were fixed), compare malware samples (to find new variants), and verify file integrity. Tools like BinDiff (by Google/Zynamics) perform sophisticated binary diffing at the function and basic-block level for compiled executables, which is essential for reverse engineering patched binaries.

   Patch diffing for vulnerability research: when a vendor releases a security patch, researchers download both the old and new versions of the binary and diff them with BinDiff or Diaphora. The changed functions reveal exactly which code was modified to fix the vulnerability. From there, reversing the fix often reveals the root cause, and writing a proof-of-concept exploit becomes feasible within hours - which is why unpatched systems face elevated risk in the days immediately after a security patch release. This technique, called "n-day exploitation", is a major part of real-world vulnerability research.

   File integrity monitoring (FIM) uses the same concept to detect unauthorized changes to system files. Tools like AIDE (Advanced Intrusion Detection Environment) and Tripwire compute cryptographic hashes (SHA-256) of critical system files at a known-good baseline and periodically re-hash them, alerting when any file changes. A rootkit that modifies /bin/ls to hide processes would be caught by FIM because the file's hash would no longer match the baseline. Binary-level diffing then identifies exactly what was changed.

   Hash verification is the reliable alternative to byte-by-byte comparison for integrity checking. Computing sha256sum file1 file2 and comparing hashes is orders of magnitude faster than diffing entire files and provides a definitive answer: if hashes match, the files are identical bit-for-bit; if not, something differs (though it does not tell you what). In CTF challenges involving forensics or steganography, computing hashes of suspicious files and cross-referencing them with known-good versions of common images online can instantly confirm whether a file has been tampered with.

Flag

The two images are nearly identical - flag bytes were substituted at scattered positions, making visual comparison impossible but byte-by-byte comparison trivial.