Debugging Interface | HackTheBox

5 min readJan 26, 2023

Fig 1. Debugging Interface hardware challenge in HackTheBox

FILE PROVIDED

In this challenge, only a single file is provided which is debugging_interface_signal.sal. You can download the file here.

SOFTWARE NEEDED

To read the given file, we will require a logic analyzer software. As the file is in .sal extension, we should use Saleae‘s logic analyzer to analyze the file. Download the software and install it then you are ready for some analysis work!

ANALYZING THE FILE

Once you open up the file in the logic analyzer, it should look like Fig 4a.

Advertisements

REPORT THIS AD

You can press on the hotkey, ‘=’, to zoom-in or ‘-‘ to zoom-out. Zoom-in until you can see the highs and lows of the graph but not too zoomed-in such that you can see more highs and lows of different duration. Once you have done so, click on the Analyzers tab on the most right panel shown with the ‘1F‘ icon and then click on the ‘Async Serial‘ (see the red boxes on Fig 4b).

The default settings will appear (see Fig 4c). Click on the Save button.

Looking at the graph, you will notice that there are a lot of framing errors with a brunch of hexadecimal values. Based on the information on asynchronous serial communication, we will know that each data being sent are in ASCII and there is a start and stop bit. Therefore, let’s convert the values into ASCII first by clicking on the additional options in the blue box and then select Ascii in the red box as shown in Fig 4d.

Once you converted it into ASCII, you will notice that the values are much more readable (see Fig 4e).

Now it is time for us to solve the framing error. If you have taken some hardware modules in school on signals such as UART, etc, this should be easy to understand for you. A framing error occurs when the bit being read is too fast or too slow. If they are being read too quickly or too slowly, they will give different values. An example show on Fig 4f is a graph read at normal interval shown on the red dotted line. This gives a result of 01010 in binary. However, if we increase the read of bit rate by 2 times, it will read two times faster, causing it to read with more intervals shown on the red dotted line in Fig 4g. This gives a result of 0011001100 instead.

If we look at the graph, we can see that the bit rate is too low as our setting at Fig 4c is reading only 8 bits but there are definitely more than 8 bits being read and treated as only 8 bits being read in Fig 4h. To be exact, 31 bits were being read as 8 bits. That’s why the analyzer warns us that there is a framing error.

If we point our mouse’s cursor at the graph at the shortest interval (the first low is already an example of the shortest interval), we will see that each shortest interval is 32.02 microseconds (see Fig 4i).

To calculate the actual bit rate, we should:

Bit rate (bit/s) = 1 second / (32.02 x 10^(-6)) seconds = 31,230.480949406621 = 31,230

There is no decimal place in number of bits to read so we will just truncate away the decimal number. If we do not get the flag, we will then round up to 31,231 if needed. For now, let’s stick to 31,230 bit/s.

Going back to the setting (see Fig. 4j), it will bring us back to the setting window to adjust out bit rate. Changed the value from 9600 to 31,230 (see Fig 4k). Then click on the save button.