\n\n\nThis page has been machine-translated from the original page.
\n
This challenge was presented as follows.
\n\n\nHello expert.\nMy PC sent @yuki_kashiwaba’s twitter icon for C&C server.\nBut I couldn’t find any suspicious point.\nCould you investigate this?
\nFormat: HimitsukichiCTF{XXXX}\nFile: flag.png
\n
The image provided as the challenge file (flag.png) was the following.
\nThe image downloadable from my Twitter profile (rUFTyqG400x400.png) was the following.
\nThis challenge is themed around LSB Steganography — a steganography technique that exploits the property that “even if the RGB values of each pixel in an image change by only a tiny amount, humans cannot visually detect the change” — by tampering with the least significant 1 bit of each pixel’s RGB value to embed arbitrary text.
\nSince 3 bits per pixel (or 4 bits if the Alpha channel is also used) can be embedded, a 400×400 image can hold 480,000 bits.
\nUsing 8-bit ASCII characters, this translates to up to 60,000 characters that can be embedded.
\nDespite being a straightforward technique, I felt that LSB Steganography rarely appears in entry-level CTFs, so I decided to implement it myself this time.
\nFrom the problem statement, we understand the scenario: a Twitter profile image was apparently sent to a C&C server, but no suspicious point can be found, and we are asked to investigate.
\nWe therefore start by comparing the actually transmitted flag.png with _rUFTyqG_400x400.png, obtainable from the Twitter profile page.
As a precaution, we verify the file type with the file command, then use the strings command to confirm that no suspicious strings are embedded.
Next, we compare the exiftool output, but no flag-related information was found there either.
\nSince the file is a PNG, we try binwalk, but there doesn’t appear to be any useful information embedded.
\n$ binwalk -e flag.png \n\nDECIMAL HEXADECIMAL DESCRIPTION\n--------------------------------------------------------------------------------\n0 0x0 PNG image, 399 x 399, 8-bit/color RGB, non-interlaced\n54 0x36 Zlib compressed data, default compression\n427 0x1AB Zlib compressed data, default compressionNo digital watermarks were visible to the naked eye, and adjusting color tones didn’t reveal any useful information.
\nFor image comparison we use magick’s composite, but the output was completely black.
\nSince composite takes the color difference, it makes sense that two visually identical images produce a solid black result.
\n$ ./magick composite -compose difference flag.png _rUFTyqG_400x400.png diff.pngSince composite couldn’t confirm the presence of differences, we try WinMerge instead.
\nAs shown below, differences were found in almost every part of the image.
\nIncidentally, when only some pixels have differences, WinMerge displays the differing areas as follows.
\nTo see exactly where within each pixel the difference lies, you can check the information displayed at the bottom of the WinMerge window when hovering the mouse over the images.
\nThis shows the RGBA values at the same coordinates in each image, and we can see a slight difference in one or more of the RGB values.
\nChecking the same information at multiple coordinates, we find that the difference in one of the RGB values is always exactly 1.
\nSince the challenge binary is an image sent to a C&C server, it is assumed that some information is embedded in these differences.
\nGiven that the difference in each RGB value is always 1, we can infer that the LSB Steganography technique is being used.
\nReference: PNG - CTF Wiki EN
\nUsing Stegsolve’s Extract Preview, we found that the flag could be retrieved from bit 0.
\nThis yields the flag I implemented LSB Steganography — a straightforward technique that is nonetheless rarely seen in entry-level CTFs.HimitsukichiCTF{I_know_you_can_not_notice_for_this_image_is_already_tampered_by_me}.Summary
\n