Flag in Flame

Welcome back, hackers! This time we’re handed a file that calls itself a log, but it turns out to be hiding something completely different. The whole challenge is figuring out what the file really is, and then digging the flag back out of it.

Let’s get into it.

Challenge Overview

• Event: picoMini by CMU-Africa
• Challenge Name: Flag in Flame
• Category: Forensics
• Difficulty: Easy

Challenge Description

The SOC team discovered a suspiciously large log file after a recent breach. When they opened it, they found an enormous block of encoded text instead of typical logs. Could there be something hidden within? Your mission is to inspect the resulting file and reveal the real purpose of it. The team is relying on your skills to uncover any concealed information within this unusual log. Download the encoded data here: Logs Data. Be prepared — the file is large, and examining it thoroughly is crucial .

Hint 1: Use base64 to decode the data and generate the image file.

Step 1: Getting the File and Checking What It Is

The challenge gave me a single file to download, called logs.txt. The name makes it sound like a boring text log, but in a forensics challenge the first thing to do is never trust the name. You check what the file actually is:

file logs.txt

The answer was interesting:

logs.txt: ASCII text, with very long lines (65536), with no line terminators

In plain terms, that means it’s readable text, but it’s one enormous single line of it (65,536 characters), with no line breaks anywhere. A normal log has lots of short lines. One giant unbroken line usually means the text isn’t meant to be read directly, it’s some kind of encoded data packed into a string.

Step 2: Peeking at the Contents

To see what that text actually looked like, I printed just the first part of it instead of dumping the whole thing:

head -c 300 logs.txt

It was a long run of random looking letters and numbers, which is exactly what Base64 looks like. Base64 is a way of writing binary data using only normal text characters, so it can be stored or sent as plain text.

Get SoBatista’s stories in your inbox

Join Medium for free to get updates from this writer.

Remember me for faster sign in

And the very start gave it away. It began with iVBORw0KGgo. That specific opening is the signature of a Base64 encoded PNG image. So logs.txt wasn’t a log at all. It was a picture turned into text.

Step 3: Turning the Text Back into an Image

Since it was a Base64 encoded image, I decoded it back into a real file:

base64 -d logs.txt > out.png

base64 -d means “decode”, and the > saves the result into a new file called out.png.

Step 4: Looking at the Image

I opened the image:

open out.png

It was an illustration of a hooded hacker at a laptop. But the important part was along the very bottom of the picture: a long string of characters that was clearly put there on purpose.

Step 5: Extracting and Decoding the Hidden String

The string was long, and I didn’t want to retype it by hand, so I used an OCR tool (a tool that reads text out of an image) to pull it straight off the picture. I used Tesseract:

tesseract out.png stdout

That printed the text from the image, including the long string along the bottom.

Now I had the string, but I still had to figure out what it was. So I ran it through a hash identifier:

It came back and identified the string as hexadecimal.

So to turn it back into readable text, I ran it through a hex decoder and I got the flag:

Final Thoughts

I liked this one because nothing was really hidden with fancy encryption, it was just disguised. A file pretending to be a log was actually a picture, and the picture was carrying a message written in hex.

The real takeaway is to never trust what a file claims to be. The name said “log,” but checking it properly showed it was something else entirely. In forensics, each layer you peel back tends to reveal the next one: text to image, image to hex, hex to flag.

Happy hacking, and I’ll see you in the next write-up!

Cheers,
SoBatista