Based on my related question on Info Sec SE I want to know if I could track all changes to register state (and perhaps memory too) on multiple cores of an x86-64 CPU.

Some of my research so far suggested the max bandwidth of JTAG on any given system is only as fast as the slowest component can support because of the way it's daisy-chained. That source suggested the max might be around 100MHz or as low as 10MHz (hopefully I heard MHz, not Hz). I'm really not sure about any of it yet, maybe this is a rabbit hole I shouldn't be going down.

So for an x86 CPU / mobo can the dedicated debug port for JTAG allow me to monitor the states of all cores on an x86 machine, even one at a time? In other words, is there enough bandwidth to record the state changes of every core via JTAG with the physical debug port, constantly?

If not the state changes, perhaps the machine instructions executed would fit within the bandwidth?

My thinking / knowledge so far:

I'm approaching this from a malware analysis angle and want to know if JTAG is at all viable as a mechanism to observe the activity of cores on the x86 CPU.

To show my line of thinking trying to solve this so far, don't laugh but here's my math:

Electrical engineering is a new realm for me to dive into, so I don't currently know what 100MHz on one bus translates to in terms of KB/s, but perhaps I can compare frequencies of something like RAM to get a rough comparison, which would be:

25,600 MB/s for 3200MHz == 8MB/s for 1Mhz, or 80MB/s for 10Mhz (Which I've seen cited as a low-end frequency for the JTAG busses to run at).

I don't know if the listed RAM frequency is per-bus (in which case I'm miles off) or total combined frequency of all busses.

If I'm not wrong so far, and we have a 3GHz/s CPU to record state changes for operating at full capacity, let's say we're writing (and hoping to monitor via JTAG) one 64-bit register value per cycle, and we have 3,000,000,000 cycles per second, so:

64 x 3M = 24MB/s required to record that.

So with my perhaps horribly naïve math, 24MB/s fits within 10Mhz (80MB/s)

But could my math really be correct? It must not, since if RAM can send 25,600 MB/s, the CPU must be able to write much more than that per second to the registers.


2 Answers 2


In a word, no.

JTAG is a bit-serial interface that runs at a maximum of 100 Mbits/sec, including all of the overhead bits for the protocol. That's something less than 12.5 Mbytes/sec of actual data.

If you want to record 64 bits (8 bytes) @ 3 GHz, that would produce 24 Gbytes/second of data, more than 2000× what the JTAG interface can handle.


Depending on how broadly you define state, there's somewhere between kilobytes to megabytes of state per core, and it updates billions of times per second. Conservatively you would terabytes to petabytes per second of bandwidth. This is not realistic.

The other, bigger problem is that state changes are not broadcast (by design), so even if you had a bus millions of times faster than JTAG, there would be no way to read out this information in real time.

A better approach to studying software is to design an emulator with the instrumentation programmed in to monitor whatever you are interested in studying. You can playback software at less than real time, parsing and recording whatever state you seem important.

  • \$\begingroup\$ Doesn't JTAG allow us to see which machine code op is being executed on the current instruction? In that case, we know which register to look at. But yes, as Dave Tweed pointed out as well not enough bandwidth even if you know which 64 bit register to read \$\endgroup\$
    – J.Todd
    Jun 11, 2021 at 9:09
  • \$\begingroup\$ @J.Todd To read out registers you (frequently) have to stop CPU execution first. Basically a lot of hardware cannot be shared between execution and the debug interface at the same time. \$\endgroup\$ Jun 11, 2021 at 13:38
  • \$\begingroup\$ Based on the information cited in this question I believe some processor models make it possible to read register values without halting execution. That's according the the JTAG website. That's one of the reasons I'm interested in JTAG as an observation vector versus just using a debugger. \$\endgroup\$
    – J.Todd
    Jun 11, 2021 at 14:20
  • \$\begingroup\$ Also the reason this capability is interesting instead of emulation is that it's essentially impossible to develop an emulator that the attacker can't detect and evade by not showing malicious behavior. \$\endgroup\$
    – J.Todd
    Jun 11, 2021 at 14:22
  • \$\begingroup\$ @J.Todd Some processors do, but probably not the ones you are asking about. Lots of emulators are transparent to the software they're running and so cannot be detected. \$\endgroup\$ Jun 11, 2021 at 14:43

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.