Hi everyone it’s been a while since I wrote a blog post almost 1 year, Today in this blog I’ll share my writeup for the creds challenge from payatu hiring CTF it ended 2 months before at the time of writing this blog.
IoT - CTF
I was interested in the IoT category from the whole CTF that’s why I participated in it. I liked the challenge creds & 32F411. I haven’t solved 32F411 till now based on its name I guess it’s a bare metal firmware but I’ll post a writeup once I finish it. I didn’t solve this challenge while the CTF was running, because I overcomplicated this challenge but it was really a simple challenge if you had done IoT firmware reversing before this was a piece of cake for you.
At the time of writing this blog creds challenge is available to download.
I downloaded the firmware file. Using file utility we couldn’t identify the file type. Because sometimes firmware can be compressed with gzip, tar, zip, etc.. but that’s not the case here.
Next, I checked the Entropy of the file it looks like the firmware isn’t encrypted but a few sections are compressed (maybe the filesystem is compressed). If it were a full flatline reaching 1.0 It would be encrypted. luckily this firmware is not encrypted.
binwalk can extract the sections from the firmware based on the signatures of the file. Squashfs file system is used we can use dd to dump the squashfs file system from the firmware but binwalk can do it for us and extract the file system.
-e option will automatically extract the known file types & it successfully extracted the filesystem from the firmware.
To get the flag we know the flag format is flag{} so using grep I get the flag within 3 mins we can complete the whole challenge but this is where I overcomplicated the challenge based on the name I thought the flag type would be a hardcoded credential from configuration, webpage or binaries? and I also missed the first blood because of my stupid mistake.
I didn’t thought the flag was hardcoded so I was searching for hardcoded credentials from config files and cracked the password from the shadow
passwd and shadow have different hashes and it’s too simple to crack so I suspect it updates at runtime
When I reverse engineer firmware’s first thing I look for is /etc/rcS. when firmware starts booting this file gets loaded and starts the required services. inittab first loads this script to up the services. So checking the script the Flag is hardcoded into it. I know the challenge can be solved from the static analysis that’s why I haven’t looked at the script at the beginning.
The End
I hope you liked the write-up, if I made any mistake feel free to contact me I’ll correct it. From now on I’m gonna start writing about IoT pentesting in upcoming blogs I’ll cover more about reversing and finding bugs in firmware
