{"componentChunkName":"component---src-templates-post-template-js","path":"/ctf-sec4b-2021-en","result":{"data":{"markdownRemark":{"id":"f6e2bd44-838a-5fd3-997c-16700e59315f","html":"
\n

This page has been machine-translated from the original page.

\n
\n

I participated in SECCON Beginners CTF 2021, held on May 22–23.

\n

In fact, the first CTF I ever entered when I started was last year’s SECCON Beginners CTF, and at the time I could only solve one or two problems and lost badly.

\n

This time I was pumped up to participate as a rematch, to confirm how much I had grown over the past year.

\n

And the result — I managed to solve all five Reversing problems!

\n

\n \n \n \n \n \n \n \n \n

\n

This time I would like to write a brief writeup for the “firmware” problem from among the Reversing challenges.

\n

Disclaimer

\n

The content of this article is not intended to promote any actions that violate social order.

\n

Please note in advance that attempting to attack systems other than those you own or have been authorized to test may violate the “Act on Prohibition of Unauthorized Computer Access.”

\n

WriteUp

\n

First, extracting the provided archive file revealed the following two files:

\n\n

The contents of README.txt were as follows:

\n
ctf4b networks SUPER SECURE device's firmware\n\n*NOTE*\n\nIt is allowed to reverse engineer this firmware.\nI hope you enjoy reversing this file!
\n

It appears that firmware.bin is a firmware program for some kind of network device.

\n

Running the file command on it showed that it is a data file:

\n
$file firmware.bin \nfirmware.bin: data
\n

Next, running strings on it revealed the following filenames:

\n
ascii.txt \nsquare.svg\nbootstrap-grid.css\nfa-regular-400.woff2\nfile.svg\nlogo.png\nfirm\nlogo.jpg\nfolder.svg\ncertificate.pem\nindex.html\nplus-square.svg\nstar.svg
\n

The following text was also found:

\n
This is a IoT device made by ctf4b networks. Password authentication is required to operate.\nInput password (password is FLAG) > \nIncorrect password.\nCorrect password!!!\nGCC: (Ubuntu 9.3.0-17ubuntu1~20.04) 9.3.0
\n

It became clear that firmware.bin consists of multiple files, and that the executable inside it would ask for a password string that is the FLAG.

\n

However, since firmware.bin showed as a data file, I could not successfully analyze it with Ghidra, radare2, objdump, or similar tools.

\n

About firmware.bin

\n

So I changed my approach and researched firmware analysis tools, and found that binwalk is a tool designed specifically for firmware analysis.

\n

I had used binwalk before to decompress ZLIB files in steganography challenges, but I did not realize that firmware analysis was its original purpose.

\n

Running binwalk on firmware.bin produced the following output:

\n
$binwalk firmware.bin \n\nDECIMAL       HEXADECIMAL     DESCRIPTION\n--------------------------------------------------------------------------------\n127           0x7F            Base64 standard index table\n2343          0x927           Copyright string: \"Copyright 2011-2021 The Bootstrap Authors\"\n2388          0x954           Copyright string: \"Copyright 2011-2021 Twitter, Inc.\"\n83503         0x1462F         PNG image, 594 x 100, 8-bit grayscale, non-interlaced\n83544         0x14658         Zlib compressed data, best compression\n90593         0x161E1         ELF, 32-bit LSB shared object, ARM, version 1 (SYSV)\n100906        0x18A2A         Unix path: /usr/lib/gcc/arm-linux-gnueabihf/9/../../../arm-linux-gnueabihf/Scrt1.o\n103485        0x1943D         JPEG image data, JFIF standard 1.01\n117167        0x1C9AF         PEM certificate\n117786        0x1CC1A         HTML document header\n118641        0x1CF71         HTML document footer
\n

From this output, it is clear that I need to extract the ELF file that handles the FLAG password string.

\n

Extracting Binary Data Between Arbitrary Addresses

\n

I had done this a few times before, so it was not particularly difficult.

\n

Specifically, I used the dd command.

\n

Many people have used dd when writing an ISO image to a USB drive on Linux — it is a command for file conversion and copying.

\n

Reference: dd(1) - Linux manual page

\n

Using dd to extract binary data requires nothing particularly complicated.

\n

As shown below, I specified firmware.bin as the input file, set bs to 1 to write one byte at a time, and set the start address and byte count obtained from binwalk:

\n
$ dd if=./firmware.bin of=./program bs=1 skip=90593 count=12892\n12892+0 records in\n12892+0 records out\n12892 bytes (13 kB, 13 KiB) copied, 0.0391655 s, 329 kB/s
\n

Checking the extracted file confirms it was properly obtained as an ELF file:

\n
$ file program \nprogram: ELF 32-bit LSB pie executable, ARM, EABI5 version 1 (SYSV), dynamically linked, interpreter /lib/ld-linux-armhf.so.3, missing section headers
\n

Analyzing the Binary File

\n

I considered setting up an ELF32 execution environment for dynamic analysis to extract the FLAG, but setting up the dynamically linked libraries was too much trouble, so I skipped it.

\n

Since the binary was fairly straightforward, static analysis alone was sufficient to obtain the FLAG.

\n

I loaded it into Ghidra.

\n

\n \n \n \n \n \n \n \n \n

\n

The main function is a bit lengthy, but the important parts are not that many.

\n

Since strings had already revealed a section that receives a password input and checks whether it is correct, I searched for that.

\n

The branch just before reaching the “Correct Password” address looked suspicious.

\n

\n \n \n \n \n \n \n \n \n

\n

Searching around, I found a branch that clearly looked like a password check.\n(Variable names were edited during analysis.)

\n

Reading the decompiled code, it appears to compare the input value against the FLAG string character by character from position 0 to 60.

\n

The input is XORed with 0x53 (83) for each character before comparison.

\n

\n \n