Debugging Interface - HackTheBox Challenge Writeup

Challenge Information

Description

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?

The challenge ships a logic-analyzer capture of a single digital channel and asks the player to recover the plaintext being sent over it — a classic UART-sniffing exercise, except the capture file format itself turns out to be the real puzzle.

Solution

The provided artifact was a .sal file — Saleae Logic’s session format, which is just a password-protected zip. Inside sat meta.json (describing an 8-channel Logic capture at 50 MS/s sample rate with one digital channel recorded, spanning ~1.94 s) and a digital-0.bin file holding the actual sample data.

The catch: digital-0.bin does not match Saleae’s documented binary-export struct format. There’s no public spec for this internal session-format encoding, so it had to be reverse-engineered from scratch by inspecting the byte layout directly.

Once decoded, the digital trace resolved into a stream of edge transitions. Measuring the shortest pulse width against the known 50 MS/s sample rate gave a bit period matching standard 31250 baud — the classic MIDI/embedded UART rate — and decoding the trace as 8N1 UART (idle-high) produced a readable console log of [MSG] Activity from: <sha256> lines, the last of which contained the flag.

Key Steps

1. Recover the artifact and unpack the .sal container

The challenge zip’s internal .sal file was password-protected with the standard HTB zip password:

unzip -o -P hackthebox debugging_interface_signal.sal -d sal/
# -> meta.json, digital-0.bin

meta.json confirmed the capture parameters:

{
  "devices": [{"type": "Logic 8", "digital_channels": [0]}],
  "sample_rate": 50000000,
  "duration": 1.94
}

2. Reverse-engineer the digital sample encoding

digital-0.bin is organized into chunks, each with a fixed header followed by a delta-encoded transition stream:

import struct

# Chunk header layout (little-endian):
#   u64 begin, end, length, sample_rate, <const 1>, stream_len
# followed by the delta stream, then a 28-byte trailer
# and 20-byte resync index entries.
pos = 51
prev_end = 0
chunk = struct.unpack_from('<QQQQQQ', d, pos)
begin, end, length, sample_rate, _, stream_len = chunk

The delta stream uses a custom varint scheme (not the usual LEB128):

# byte 0: bit 6 = continuation flag, bits 0-5 = data
# byte N (N>0): bit 7 = continuation flag, bits 0-6 = data
# actual sample-delta = decoded_value + 1
def decode_varint(buf, i):
    b0 = buf[i]
    value = b0 & 0x3F
    cont = b0 & 0x40
    shift = 6
    i += 1
    while cont:
        b = buf[i]
        value |= (b & 0x7F) << shift
        cont = b & 0x80
        shift += 7
        i += 1
    return value + 1, i

The decoding was confirmed correct because each chunk’s summed deltas landed exactly on that chunk’s declared length — with the final delta in each chunk simply padding to the chunk boundary rather than representing a real signal edge.

3. Decode the UART trace

7,560 transitions were recovered. Taking the shortest observed run length (~1601.5 samples at 50 MS/s) gave the bit period:

baud = 50_000_000 / 1601.5   # ≈ 31250 baud

With the bit rate known, the transition list was walked as standard 8N1 UART (idle-high, LSB-first):

import bisect

SAMPLES_PER_BIT = 1601.5
transitions = load_transition_list()  # [(sample_idx, level), ...]

def level_at(sample):
    i = bisect.bisect_right(transitions, (sample, 2)) - 1
    return transitions[i][1] if i >= 0 else 1  # idle-high

def read_byte(start_sample):
    # skip start bit, sample 8 data bits + stop bit at bit-cell centers
    bits = []
    for n in range(1, 9):
        t = start_sample + int((n + 0.5) * SAMPLES_PER_BIT)
        bits.append(level_at(t))
    return sum(b << i for i, b in enumerate(bits))

This produced a clean console log:

[MSG] Activity from: <sha256 hash 1>
[MSG] Activity from: <sha256 hash 2>
...
[MSG] Activity from: ...HTB{REDACTED}

4. Extract and submit the flag

The flag appeared embedded in the final log line and was submitted directly to the HTB grader.

HTB{REDACTED}

Tools Used

• unzip — extracting the password-protected .sal container (hackthebox password)
• xxd — manual hex inspection of digital-0.bin to locate chunk headers and the delta stream
• Python (struct, bisect, custom varint decoder) — reverse-engineering the proprietary Saleae session digital-channel format and reconstructing sample-level edge transitions
• Custom UART bit-banger — decoding the recovered transition list as 8N1 asynchronous serial at ~31250 baud

Key Learnings

• Saleae’s .sal session format is a password-protected zip, but the digital-channel binary payload inside it is a proprietary, undocumented encoding distinct from Saleae’s publicly documented binary-export struct — treating it as the latter fails silently, so byte-level reverse engineering was required.
• The chunked delta-stream encoding used a two-tier varint: the first byte reserves bit 6 as its continuation flag (6 data bits), while subsequent bytes use the more conventional bit 7 (7 data bits) — a subtle asymmetry that’s easy to misdiagnose as corrupted data if assumed uniform.
• A strong self-check for a from-scratch binary format guess: verify that decoded values sum to an independently-known total (here, each chunk’s summed deltas had to equal its declared length) — this caught the correct varint scheme and revealed that trailing deltas were chunk-boundary padding, not genuine signal edges.
• Once sample-accurate transitions are recovered, standard signal-analysis techniques apply directly: the shortest pulse width reveals the UART bit period/baud rate, and decoding proceeds as ordinary 8N1 asynchronous serial — the hard part of this challenge was entirely in the capture-format archaeology, not the UART decode itself.