Mem

Platform: hackerlab | Category: Steganography | Type: Challenge | Difficulty: Easy | OS: Linux | Author: XESXOR | Date: 2026-04-05 | Status: Solved Techniques: appended_file_carving, iend_based_payload_recovery, png_trailer_extraction

Summary

Task: a single PNG image named meme.png appears ordinary, but metadata inspection reports extra data after the PNG end marker. Solution: carve everything after the IEND chunk, recover the appended second PNG, and read the flag directly from the extracted image.

Mem — Hackerlab

Description

Мем

English summary: The challenge provides a PNG image inside a ZIP archive. The visible image looks ordinary, but the goal is to determine whether the PNG structure hides appended content and recover the CODEBY{...} flag.

Recon

The archive was extracted and the main artifact was meme.png.

Initial triage:

 bash read-only • copy allowed Copy
file meme.png
exiftool meme.png
strings meme.png

Observed results:

• file identified a normal PNG image: 690 x 401, 8-bit RGB, non-interlaced
• exiftool reported the decisive warning: Trailer data after PNG IEND chunk
• strings did not reveal useful plaintext
• binwalk could not be used in this environment because the installed version failed on the deprecated Python imp import ‍​‌‌​​​​‌​‌‌​​‌‌​​‌‌​​‌‌​​‌‌​​‌​​​​‌‌​​​​​‌‌​​‌‌​​‌‌​​‌​‌​‌‌​​‌​‌‍

The key point is that a PNG should normally end at the IEND chunk. If extra bytes exist after that marker, they are often an appended payload worth carving manually.

Knowledge Base References

Before extracting data, similar solved tasks were reviewed through the knowledge base:

• CTF Writeup_search("PNG IEND chunk trailer data steganography", category="stego")
• relevant writeups included 20260221_taipanbyte_SomeText and 20250414_hackerlab_find_me_if_you_can
• HackTricks material for png trailer data after IEND chunk confirmed the same workflow: validate the PNG, locate IEND, and inspect bytes after the final chunk ‍​‌‌​​​​‌​‌‌​​‌‌​​‌‌​​‌‌​​‌‌​​‌​​​​‌‌​​​​​‌‌​​‌‌​​‌‌​​‌​‌​‌‌​​‌​‌‍

Those references suggested a simple and reliable approach: carve everything after IEND + 8 bytes because the IEND chunk is followed by its 4-byte type and 4-byte CRC, and any remaining bytes belong to appended data.

Extraction

The payload was recovered by locating the IEND marker and writing all bytes after the end of that chunk into a separate file:

 python read-only • copy allowed Copy
#!/usr/bin/env python3
from pathlib import Path

p = Path('meme.png')
data = p.read_bytes()

iend = data.find(b'IEND')
if iend == -1:
    raise SystemExit('IEND not found')
‍​‌‌​​​​‌​‌‌​​‌‌​​‌‌​​‌‌​​‌‌​​‌​​​​‌‌​​​​​‌‌​​‌‌​​‌‌​​‌​‌​‌‌​​‌​‌‍

trailer = data[iend + 8:]
Path('trailer.bin').write_bytes(trailer)

print('iend_offset', iend)
print('trailer_len', len(trailer))
print('first_64_hex', trailer[:64].hex())

Then the carved file was identified:

 bash read-only • copy allowed Copy
file trailer.bin

Result:

 text read-only • copy allowed Copy
PNG image data, 1800 x 1800, 8-bit/color RGBA, non-interlaced

That confirmed the appended payload was not text, whitespace, or compressed junk. It was a complete second PNG image embedded after the first PNG had already ended.

Saving the carved payload as hidden.png and opening it revealed the flag directly in the image. ‍​‌‌​​​​‌​‌‌​​‌‌​​‌‌​​‌‌​​‌‌​​‌​​​​‌‌​​​​​‌‌​​‌‌​​‌‌​​‌​‌​‌‌​​‌​‌‍