Debugging Interface is a very easy challenge in the hardware category. The challenge description is as follows:
‘We accessed the embedded device’s asynchronous serial debugging interface while it was operational and captured some messages that were being transmitted over it. Can you decode them?’
SHA-256 of the files necessary to download: 98e289c5b0eec6e53a01e99bd4953c03020055e5990c7113c5634c6732103fd0.
File Analysis
First step is to download the provided zip file and see what we have. The .zip contains a single .sal file, debugging_interface_signal.sal. Nothing found after a quick inspection of properties and any potential metadata. It’s a filetype I’m not familiar with, so after some scans, I open it in Windows VS Code, and get the notice it’s either in binary or uses an unsupported text encoding. Continuing to view file contents regardless, nothing stands out in the file outside of a digital-0.bin string.
Some more scans, and opening the .zip in Linux instead of Windows gives us a little more information – the digital-0.bin file above alongside a meta.json file. First thing will be to review the .json file. It contains a lot of floats and integers, channel references, and reads more like raw collected data rather than anything else. No flags, URL’s, encoded data or further hints so we’ll move on to opening the file now.
Next step is to research what a .sal file, and the primary results point to it being an .mp3, playlist file or a MySQL related filetype. I’m relatively certain the playlist/.mp3 link is a generic website result/incorrect. So the next thing I try is to open the file in MySQL Workbench – no result. On the off chance the .sal is an incorrect renaming of an earlier file, I try to change the extension of the file to .sql and open it – no result.
Opening File
A search on the filetype gives another high result that is promising: Utilities for .sal files – Logit 2 Software – Salaea. While I’m not overly keen on installing more small and single-purpose potentially bloatware software on my machine (not claiming this specific one is – just in general), I’m going to in order to explore the file further. A quick dive into the page discusses reading and writing to the .sal file format. It even discusses the previously mentioned .bin and .json file found on Linux. I download the Logic 2 software and open the file, I’m assuming as a channel.
So it opens up – looks like the file is supported, but what is going on I have no idea. In hindsight, not rushing the challenge and instead reading the supporting documentation of Logic 2 would have been the logical and professional step to take next. But I do what I always do when I’m blankly looking at a new piece of software where I have no idea what I’m doing. I stopped thinking about the challenge and just pressed every available button and viewed every available window until a picture formed in my head of what it does.
Analysing File and Data
White block of code – zoom in and see dots and a signal pattern. Hovering over the white block the frequency in kHz was referenced – so I knew we were working with some kind of wavelength or signal (I came into this challenge relatively blind from a hardware perspective). After opening multiple channels (all channels but original channel 0 appeared empty) and using many different analysers. Now most analysers output no data in the data window view to the right – to the point I thought I was misconfiguring something. Eventually data appeared but it made no sense. Still, I kept exploring the analysers until I captured everything that was apparently available on the initial Channel 0. Analyzer tab to the right hand side – a hint from the challenge information – ‘captured.. asynchronous serial debugging interface‘ – one of the analysers is the Async Serial.
I instantiate an Async Serial analyser screenshot as shown – but we’re getting a lot of framing errors as we can see to the right. At this point, when setting up the Async Serial analyser, I try every combination of options, the majority of which are displayed as the ‘Standard’. There is one value that is entirely user inputted with no standard: the Bit Rate (Bits/s). Since I’m aware that a different bitrate could lead to entirely different outputs, there’s that trigger at the back of my mind that this is the one to figure out exactly. And no matter what settings I try with the Async Signal analyser – the data outputted in the right hand data table and data terminal windows make no sense. I do try to decode a few in case a flag is hidden behind, but still the output makes no sense.
We can view the data in 1 of 4 formats: binary, decimal, hexadecimal and Ascii. The Wikipedia search result information mentions a common kind being Ascii, so we’ll start there. It also explains the data has a start signal and a stop signal. Zooming in to the block of data, I can start to explore what is going on. Each value is assigned a block, and that output data is what is constantly changing based on the analyser settings. I’m also going to assume we aren’t meant to be getting the (framing error) with every block. So at this point I need to read up some more information on asynchronous serial communication, as well as what framing errors are.
Calculating the Correct Bit Rate for Data Readability
After tinkering with the software for a good 45 minutes, I learn more about framing errors, asynchronous serial communications, expected number vs actual number of bits being read as well as how to analyse, calculate and measure the actual bitrate of signals. But since I’m still in fast discovery and experimentation mode – I just start changing the bit rate while keeping all the other analyser options at their standard value. I enter the most common rates to see if I can first, remove the framing errors, and secondly, get some kind of readable output in the data terminal window. I try to encapsulate 8 bits at a time to each block and watch as the number of framing errors change each time.
I still know at this point that I’m playing a guessing game so I turn to more Googling on how to calculate bit rates of a .sal file or asynchronous serial communication. There is a detailed explanation on the asynchronous serial analyser as well as methods on how to determine the proper bit rate outlined in the software’s user guide online (link here). An important lesson to take away was don’t waste too much time stumbling in the dark even if you are working at a pace – reading the software readme/manual will likely save you time in the long run. Once read, I experiment a little further until I find a bit rate where everything just clicks. The outputted data in the data terminal becomes readable – no decoding or further analysis required.
Approximate time taken was 2 hours. If I did hardware subjects in computer science or a related field – I imagine it would have taken me 15 minutes max.
Flag: HTB{d38u991n9_1n732f4c35_c4n_83_f0und_1n_41m057_3v32y_3m83dd3d_d3v1c3!!52}
Leave a Reply