JTAG: Guida Completa all’Interfaccia di Debug Hardware e alle Sue Implicazioni di Sicurezza #

Se non hai mai sentito parlare di JTAG prima d’ora: è l’interfaccia che quasi ogni chip moderno nasconde al suo interno per essere testato e “parlato” direttamente dagli sviluppatori, senza passare dal sistema operativo del dispositivo. Per un ingegnere serve a caricare firmware e trovare bug. Per chi fa pentest hardware, quella stessa porta — quando resta accessibile e non protetta sul prodotto finito — può diventare il modo più diretto per leggere la memoria di un dispositivo, estrarne il firmware, e in certi casi interferire persino con i controlli di sicurezza pensati per impedire proprio questo.

Questa guida parte da zero: cos’è, come si trova fisicamente su una scheda, come ci si collega, e cosa si può fare una volta collegati — con i comandi reali, non solo la teoria.

Cos’è JTAG (e Perché il Nome Non Aiuta a Capirlo) #

JTAG è l’acronimo di Joint Test Action Group, il comitato che ha portato alla pubblicazione dello standard IEEE 1149.1 nel 1990. Il nome ufficiale dello standard — Test Access Port and Boundary-Scan Architecture — spiega meglio a cosa serviva in origine: verificare che ogni singola saldatura su un circuito stampato fosse elettricamente corretta, senza dover collegare una sonda su ogni singolo pin a mano. Questa funzione originale si chiama boundary scan.

Con il tempo, la stessa infrastruttura fisica è stata riutilizzata per fare molto di più: caricare firmware su un chip, mettere in pausa l’esecuzione della CPU per il debug, leggere e scrivere registri interni. Sono usi diversi, costruiti sopra lo stesso Test Access Port (TAP), ma non tutti i chip li implementano tutti — e questo è il punto più importante di tutto l’articolo: JTAG non è una singola funzione con capacità fisse. Cosa puoi fare tramite JTAG su un dispositivo specifico dipende da come quel produttore ha configurato l’accesso al debug su quel SoC.

Il Pinout: I Segnali che Compongono JTAG #

Un’interfaccia JTAG completa espone questi segnali:

Gli ultimi due — GND e VREF — sono spesso dimenticati nelle guide introduttive, ma sono indispensabili: senza una massa comune e un riferimento di tensione, l’adapter non sa nemmeno a quale livello logico (1.8V, 3.3V, 5V) interpretare i segnali che riceve. Collegare un adapter impostato sulla tensione sbagliata è uno degli errori più comuni — e più distruttivi — per chi inizia con l’hardware hacking.

JTAG Connector: Come Si Presenta Fisicamente #

Non esiste un unico connettore JTAG standard — varia molto da produttore a produttore. I formati più comuni che troverai:

• Header 2×5 o 2×10 — file doppie di pin su passo 2.54mm o 1.27mm, il formato più diffuso su schede di sviluppo
• ARM JTAG a 20 pin — standard usato storicamente sui chip ARM
• Cortex Debug Connector — versione più compatta (10 pin), comune sui microcontrollori ARM moderni, spesso condivisa con SWD (vedi sotto)
• Test pad senza connettore — semplici pad di rame sul PCB, senza alcun header saldato, pensati per essere usati solo in fabbrica

Un avvertimento pratico: non dare per scontato che un header con 10 o 20 pin sia per forza JTAG solo perché “sembra quello”. Molti header con lo stesso numero di pin servono per altro (alimentazione, altri bus). Va sempre verificato.

Come Trovare i Pin JTAG su un PCB #

1. Cerca connettori o gruppi di pad sospetti #

Cerca header non popolati, gruppi di 4-6 pad ravvicinati, o connettori dedicati vicino al chip principale (il SoC). Spesso si trovano sul retro della scheda o in un angolo isolato.

2. Controlla la serigrafia #

A volte i produttori lasciano etichette leggibili vicino ai pin: TCK, TMS, TDI, TDO, TRST, GND, VREF, oppure semplicemente JTAG o DEBUG. Se le trovi, il lavoro è quasi finito.

3. Consulta datasheet e documentazione della scheda #

Prima di collegare qualsiasi cosa, cerca se esiste un datasheet pubblico del SoC o una board revision documentata: a volte il pinout JTAG è già noto e pubblicato online.

4. Usa un multimetro come primo indizio (non come prova) #

In modalità continuità, alcuni pin JTAG mostrano un pattern elettrico riconoscibile — ad esempio un pull-up verso l’alimentazione. Questo è un indizio da seguire, non un metodo di identificazione affidabile da solo: le caratteristiche elettriche cambiano da implementazione a implementazione, e basarsi solo su questo porta spesso a conclusioni sbagliate.

5. Usa il JTAGulator per l’identificazione automatica #

Quando i pin non sono etichettati, il JTAGulator (un dispositivo hardware open source dedicato proprio a questo) automatizza la ricerca. Ci si collega via terminale seriale:

screen /dev/ttyUSB0 115200

Prima di qualsiasi scan, si imposta la tensione del target — passaggio obbligatorio, sbagliarlo può danneggiare il dispositivo:

JTAGulator> V
Enter target I/O voltage [1.2 - 3.3, or 'S' to skip]: 3.3

Poi si lancia una JTAG Scan (comando J), che combina la ricerca dell’IDCODE e un test BYPASS in un’unica passata, indicando su quali canali collegare i pin candidati non identificati del target:

JTAGulator> J
Enter starting channel [0]: 0
Enter ending channel [max]: 12
Number of samples [50]: 
Warning: This process can be destructive to some circuits. Continue [Y/N]?: Y

Se un IDCODE valido viene trovato, il JTAGulator restituisce la combinazione di canali che corrisponde a TCK, TMS, TDI e TDO — il pinout è identificato senza dover indovinare a mano.

JTAG vs SWD: Non Sono la Stessa Cosa #

Sui microcontrollori ARM moderni (in particolare i Cortex-M), è sempre più comune trovare SWD (Serial Wire Debug) al posto di JTAG, o accanto ad esso sullo stesso connettore Cortex Debug.

Se stai cercando un’interfaccia di debug su una scheda basata su un microcontrollore ARM e non trovi nulla che assomigli a JTAG, controlla se c’è invece un header SWD prima di concludere che il dispositivo non abbia alcuna interfaccia di debug esposta.

Gli Strumenti per Collegarsi #

Una volta trovati i pin, serve un adapter che parli JTAG e lo colleghi al computer:

• Adapter basati su FTDI (es. FT2232H) — economici, ben supportati da OpenOCD, un buon punto di partenza
• Segger J-Link — uno degli adapter più diffusi nell’industria embedded, supporto driver molto ampio per architetture ARM
• Bus Pirate — economico e multiprotocollo (oltre a JTAG supporta SPI, I2C, UART), utile se non si sa ancora esattamente cosa si sta affrontando

Lo schema di collegamento fisico, in versione semplificata:

ADAPTER JTAG            SCHEDA TARGET

TCK  ──────────────────  TCK
TMS  ──────────────────  TMS
TDI  ──────────────────  TDI
TDO  ──────────────────  TDO
GND  ──────────────────  GND
VREF ──────────────────  VREF (riferimento tensione)

Collegarsi con OpenOCD #

OpenOCD (Open On-Chip Debugger) è il software che fa da ponte tra l’adapter fisico e strumenti di analisi come GDB. Serve un file di configurazione che dica a OpenOCD che tipo di adapter stai usando e come parlare con il target. Un esempio minimo per un adapter FTDI:

interface ftdi
ftdi_vid_pid 0x0403 0x6014
transport select jtag
adapter_khz 1000

telnet_port 4444
gdb_port 3333

jtag newtap mytarget tap -irlen 4 -expected-id 0x12345678
init
scan_chain

Si avvia con:

openocd -f mio_config.cfg

Un output tipico, riga per riga:

Info : Listening on port 4444 for telnet connections
Info : clock speed 1000 kHz
Info : JTAG tap: mytarget.tap tap/device found: 0x12345678
Info : Listening on port 3333 for gdb connections

La riga JTAG tap: ... tap/device found è la conferma che OpenOCD ha effettivamente parlato con il chip e ricevuto una risposta valida — se questa riga non compare, i pin identificati in precedenza sono probabilmente sbagliati, oppure il debug è disabilitato o protetto.

A questo punto ci si collega via telnet per interagire manualmente:

telnet localhost 4444

> scan_chain
TapName Enabled IdCode     Expected   IrLen
------- ------- ---------- ---------- -----
mytarget.tap  Y 0x12345678 0x12345678     4

> halt
target halted due to debug-request

> reg
(mostra i registri della CPU nel loro stato attuale)

> mdw 0x20000000 16
(legge 16 word di memoria a partire dall'indirizzo indicato)

halt ferma l’esecuzione della CPU, reg mostra i registri nel loro stato in quel momento, mdw (memory display word) legge memoria. Tutti questi comandi funzionano solo se il debug access sul target lo consente — su un chip con debug bloccato o autenticato, scan_chain potrebbe anche funzionare (mostrando che un TAP esiste) mentre halt e reg falliscono.

Boundary Scan: Non È lo Stesso di Debuggare la CPU #

È un errore comune pensare che “fare JTAG” significhi automaticamente accedere alla CPU. Il boundary scan — la funzione originale di JTAG — è tutt’altra cosa: non tocca il core del processore, ma una catena di celle di test collegate lungo il perimetro logico del chip, usata per verificare i collegamenti elettrici del PCB.

JTAG
 │
 ▼
TAP Controller
 │
 ▼
Instruction Register  →  seleziona quale registro dati collegare
 │
 ▼
Boundary Scan Register  →  celle di test sul perimetro del chip
 │
 ▼
Pin fisici del PCB

Il debug della CPU è un’istruzione diversa, che alcuni chip supportano e altri no, indipendente dal boundary scan. Ecco perché non si può dire in generale “con JTAG accedi alla CPU”: dipende da quali istruzioni quello specifico TAP controller espone.

Cosa Puoi Effettivamente Fare (Dipende dal Target) #

Estrarre il Firmware #

Se l’accesso alla memoria è disponibile, il comando OpenOCD per estrarla è:

> dump_image firmware.bin 0x08000000 0x100000

L’indirizzo 0x08000000 qui è solo un esempio — va sempre verificato sulla memory map specifica del target, non copiato da un altro progetto. La sintassi generale è:

dump_image <file_output> <indirizzo_iniziale> <dimensione>

Una volta ottenuto il file, l’analisi inizia con strumenti standard:

file firmware.bin
strings firmware.bin
binwalk firmware.bin

binwalk è particolarmente utile perché riconosce automaticamente filesystem, header noti e dati compressi incorporati nel dump. Una ricerca mirata su credenziali o chiavi:

strings firmware.bin | grep -Ei 'pass|password|token|secret|key'

Per un’analisi più approfondita del codice estratto, lo strumento di riferimento è Ghidra: si importa il binario, si indica l’architettura della CPU (spesso deducibile dal datasheet del SoC), e si lascia partire l’analisi automatica prima di esplorare manualmente le funzioni.

Perché “JTAG Bypassa il Secure Boot” È una Semplificazione Pericolosa #

Il secure boot verifica la firma del firmware all’avvio. Se un attaccante può fermare l’esecuzione della CPU via JTAG prima che quella verifica sia completata, o modificare la memoria dopo che il controllo è già passato, le garanzie del secure boot possono effettivamente essere aggirate — ma questo succede solo se l’architettura di debug del chip lo permette, non come conseguenza automatica del fatto che JTAG esista.

I produttori che prendono sul serio questo rischio implementano contromisure concrete:

• Disabilitazione via fuse — un bit bruciato a fine produzione, garanzia fisica e irreversibile
• Debug autenticato — ad esempio AMD, sui suoi SoC Versal, richiede un messaggio firmato crittograficamente (RSA o ECDSA) prima di riabilitare JTAG quando è attivo il secure boot; il meccanismo può comunque essere disabilitato in modo permanente via eFUSE

Rimuovere solo il connettore fisico dal PCB finale, senza disabilitare l’interfaccia a livello di silicio, non basta: se i pin restano elettricamente attivi su via del circuito, chi ha tempo e un saldatore può comunque raggiungerli.

Un Caso Reale: CVE-2024-7726 su Kioxia CM6/PM6/PM7 #

Accesso fisico temporaneo
        │
        ▼
JTAG esposto (apertura nell'enclosure)
        │
        ▼
Accesso ai 2 core CPU del SoC
        │
        ▼
Lettura/scrittura firmware e memoria
        │
        ▼
Esecuzione di codice arbitrario
        │
        ▼
Bypass della verifica firma al boot

Su questi dischi, un’ampia apertura nell’enclosure rende la porta JTAG raggiungibile senza nemmeno smontare il drive. Da notare che la classificazione ufficiale è CWE-306 — autenticazione mancante per una funzione critica — non genericamente “JTAG pericoloso”: è un controllo di accesso specifico che qui non è stato implementato, esattamente il tipo di distinzione spiegata sopra.

Metodologia Completa: Dalla Scheda al Report #

1. Identifica il target — SoC, datasheet, revisione della scheda
2. Localizza l’interfaccia — serigrafia, documentazione, o ricerca fisica dei pin
3. Mappa i pin — multimetro come indizio, JTAGulator per la conferma
4. Verifica il livello di tensione prima di collegare qualsiasi cosa
5. Collega l’adapter e avvia OpenOCD
6. Enumera la scan chain — conferma che un TAP risponde e con quale IDCODE
7. Verifica cosa è davvero accessibile — halt, reg, lettura memoria: funzionano o il debug è bloccato/autenticato?
8. Estrai firmware o memoria, se l’accesso lo consente e l’attività è autorizzata
9. Analizza quanto estratto — binwalk, strings, Ghidra
10. Documenta nel report la causa specifica (es. CWE-306, CWE-1191), non solo “JTAG esposto”

Dal Firmware al Privilege Escalation #

Una volta ottenuto l’accesso al firmware — che su molti dispositivi embedded è un sistema Linux minimale — le tecniche di privilege escalation Linux tornano rilevanti come su qualsiasi altro target: SUID mal configurati, cron job scrivibili, capability eccessive. Vale la pena controllare anche GTFOBins, dato che molti sistemi embedded includono BusyBox e un set ridotto ma spesso sufficiente di utility sfruttabili per l’escalation.

JTAG non è di per sé la vulnerabilità — è un’interfaccia che fa esattamente quello per cui è stata progettata. Il problema, come descrive CWE-1191, è quando quell’interfaccia resta accessibile senza un controllo degli accessi adeguato fino al prodotto finito.