Photon Lockdown Firmware walkthrough
Hey everyone — 404Yeti here. Today we crack open a firmware image from HackTheBox and do a friendly firmware-forensics walk: binwalk → carve → inspect → decode → flag. I’ll show you the exact workflow I use in my lab, sprinkle in some Yeti wisdom, and finish with fixes and defensive notes. Let’s dig into the ice cave.
TL;DR / What we’ll do
- Use
binwalkto find and extract filesystems. - Inspect the carved squashfs root for config files and credentials.
- Convert weird blobs to hex, paste into CyberChef, and decode.
- Find the flag and explain why this matters.
“Firmware hides secrets like glaciers hide rivers — pry carefully.” — 404Yeti 🐾
So we should do after downloading and unzipping our file is use binwalk. Binwalk is used to extract the filesystem from a binary so we can analyze the insides of the firmware.

This enumerates embedded files (SquashFS, JFFS2, compressed blobs). The -e tells binwalk to attempt extraction. If you see squashfs-root or similar directories appear, binwalk has carved the filesystem for you.
Tip: small “systemlink” warnings or library messages often aren’t fatal — they’re just informative. Move on unless binwalk errors out.

now we can see we have access to the few file systems like squashfs-root and squashfs-root-0. Let's observe the first one.

here we can start to look for many items or grep for many things. But lets look at some good common files look for info
Common juicy files:
/etc/config_default.xmlorconfig_default.xml/etc/passwd(or shadow-like files)- web UI templates under
/www,/var/www,/html - startup scripts in
/etc/init.dor/etc/rc.local

For firmware, we want to look for some important things, such as config_default.xml files and passwd. They typically provide valuable information, such as hard-coded credentials.
Let's take a look at config_default.xml and see if there is anything interesting.

We can actually cat this information out and look, or we can also use a technique that takes this file and turns it into hex, and we can put it into CyberChef, so let's try that.

now we can ideally take this and put it into CyberChef

now we need to find what "recipe" will unlock this. If you remember from our previous steps we created a hex out of this information so lets try to decode from hex.

now we have a more readable format. So let's look for our flag. You can either scroll down or use the find function in your browser

Here we are!
Why this matters
- Default creds and plaintext configs are primary vectors for compromise in IoT devices.
- Hardcoded keys or weak obfuscation let attackers decrypt config blobs offline.
- Compromised routers / cameras are ideal pivot points for lateral movement, botnets, or MITM attacks.
How to fix it
- Change factory passwords immediately on any device.
- Isolate IoT devices on their own VLAN.
- Keep firmware up-to-date and subscribe to vendor advisories.
- Report responsibly if you discover real-world vendor secrets.
Final thoughts
Firmware triage is satisfying: quick wins (binwalk + strings) often reveal the low-hanging fruit attackers use. But with power comes responsibility — don’t be the Yeti that stomps the village. If you discover something real, be helpful: report, redact, and help patch.
“Find the flag. Fix the hole. Leave the world a little frostier — but safer.” — 404Yeti ❄️🐾