In this article, I’ll walk you through solving the Photon Lockdown hardware challenge from the platform HackTheBox.

Challenge description is the following block of text:

We’ve located the adversary’s location and must now secure access to their Optical Network Terminal to disable their internet connection. Fortunately, we’ve obtained a copy of the device’s firmware, which is suspected to contain hardcoded credentials. Can you extract the password from it?

The objective seems to be find some hard-coded credentials hidden in these files. I downloaded the challenge files, which seem to be firmware files according to the description.

The challenge file contains a single zip named ‘Photon Lockdown.zip’. When I extracted it using unzip 'Photon Lockdown.zip', it revealed a directory named ONT with three files in it:

  • fwu_ver
  • hw_ver
  • rootfs

First, I checked what these files contained. The fwu_ver file had raw text data: 3.0.5. Based on the file name and the content, it’s safe to assume this might be the firmware version.

$ file fwu_ver
  fwu_ver: ASCII text

$ cat fwu_ver
  3.0.5

The second file, hw_ver, seemed to contain some kind of archived data. So, I thought, why not try to extract it? But I couldn’t. That’s when I decided to check the file size, and to my surprise, it was only 3 bytes. This means it likely isn’t an archive, or there’s nothing useful inside. Still, I ran the cat command on the file just to be sure, and it returned a simple string: “X1” and nothing else. We can safely assume this represents some kind of hardware version.

$ file hw_ver
  hw_ver: X1 archive data

$ ls -la
  .rw-r--r--   6 clevrf0x 11 Oct  2023 fwu_ver
  .rw-r--r--   3 clevrf0x 11 Oct  2023 hw_ver
  .rw-r--r-- 11M clevrf0x  1 Oct  2023 rootfs

$ cat hw_ver
  X1

The final file is called rootfs, and from the name, we can guess it’s the firmware’s root file system. To confirm, I ran the file command, which backed up my suspicion.

$ file rootfs
  rootfs: Squashfs filesystem, little endian, version 4.0, zlib compressed, 10936182 bytes, 910 inodes, blocksize: 1310
  72 bytes, created: Sun Oct  1 07:02:43 2023

The next step is to mount the file system and explore its contents. Let’s create a temporary directory to mount the file system, and then proceed with mounting it.

$ mkdir fw_fs
$ sudo mount rootfs ./fw_fs

Let’s cd into the newly mounted directory and check what it contains.

$ ls -la
  .rw-rw-r-- 0 root 10 Aug  2022 .lstripped
  drwxrwxr-x - root 10 Aug  2022 bin
  lrwxrwxrwx - root 10 Aug  2022 config -> ./var/config/
  drwxrwxr-x - root 10 Aug  2022 dev
  drwxrwxr-x - root  1 Oct  2023 etc
  drwxrwxr-x - root  1 Oct  2023 home
  drwxrwxr-x - root  1 Oct  2023 image
  drwxrwxr-x - root 10 Aug  2022 lib
  lrwxrwxrwx - root 10 Aug  2022 mnt -> /var/mnt
  drwxrwxr-x - root 10 Aug  2022 overlay
  drwxrwxr-x - root 10 Aug  2022 proc
  drwxrwxr-x - root 10 Aug  2022 run
  lrwxrwxrwx - root 10 Aug  2022 sbin -> /bin
  drwxrwxr-x - root 10 Aug  2022 sys
  lrwxrwxrwx - root 10 Aug  2022 tmp -> /var/tmp
  drwxrwxr-x - root 10 Aug  2022 usr
  drwxrwxr-x - root 10 Aug  2022 var

As you can see, there’s a config file symlinked to ./var/config/, so I initially tried exploring that. However, the symlink was broken, and the /var directory was empty. Then, I noticed the /home directory and checked if it contained anything useful. It did, in fact, have a hidden directory with a file inside. I quickly read through it, but it didn’t contain the flag. However, it did have a string: “almost there,” which means we’re on the right track.

$ ls -la home
  drwxr-xr-x - root  1 Oct  2023 .41fr3d0

$ ls -la home/.41fr3d0
  .rw-r--r-- 13 root  1 Oct  2023 s.txt

$ cat home/41fr3d0/s.txt
  almost there

So where could the flag be? I then looked into the etc directory since that’s where Unix/Linux-based systems generally store application-specific config files. I found an interesting file there. Remember the broken config file located in the root directory? The etc directory also had a config file, along with a config_default.xml. That looked promising, so I opened it in vim and searched for anything related to the flag. It contained a lot of application-specific config options, including hard-coded credentials.

$ ls -la etc
  lrwxrwxrwx    - root 10 Aug  2022 config -> /var/config
  .rwxrwxr-x  51k root  1 Oct  2023 config_default.xml
  .rwxrwxr-x  185 root 10 Aug  2022 config_default_hs.xml
  drwxrwxr-x    - root 10 Aug  2022 cups
  drwxrwxr-x    - root 10 Aug  2022 default
  .rwxrwxr-x  18k root 10 Aug  2022 dhclient-script
  .rwxrwxr-x  19k root 10 Aug  2022 dnsmasq.conf
  .rwxrwxr-x 1.1k root 10 Aug  2022 ethertypes
  .rw-rw-r--  637 root 10 Aug  2022 fstab
  lrwxrwxrwx    - root 10 Aug  2022 group -> /var/group
  .rw-rw-r--  127 root 10 Aug  2022 inetd.conf
  drwxrwxr-x    - root 10 Aug  2022 init.d
  ...

$ vim etc/config_default.xml
  ...
  <Value Name="SUSER_NAME" Value="admin"/>
  <Value Name="SUSER_PASSWORD" Value="HTB{N0******************1n}"/>
  ...

So, let’s unmount the file system since it is no longer needed and then submit the flag.

$ cd ..
$ sudo umount ./fw_fs