JTAG to every home: full access via USB
Positive Technologies researchers activated hardware debugging (JTAG) for the Intel Management Engine, which allows you to get full access to all PCH devices (Platform Controller Hub) using Intel DCI technology (via USB interface). We plan to share details at one of the upcoming conferences. And how to activate this interface, but for the main processor, we will tell below.
No one is immune from mistakes. This statement also applies to low-level programming, where such familiar tools as debug printing or a software debugger may not be enough at some point. To solve this problem, hardware developers use so-called in-circuit emulators or special JTAG debugging interface if it is present on the target platform (IEEE1149.1 [1]). These debugging mechanisms appeared in the 1980s [2]. Over time, chip manufacturers have expanded the capabilities of these interfaces. Due to this, developers were able to obtain detailed information about energy consumption, find bottlenecks in high-performance algorithms and got many other possibilities.
')
For security researchers, hardware debugging tools are also of interest. They allow you to get low-level access to the system, bypassing the main security tools, to study the behavior of the target platform and its undocumented features. Obviously, such opportunities turned out to be attractive for special services [3].
For a long time, access to these technologies for Intel processors was available only to a limited number of people, which was due to the need to use expensive specialized equipment. But with the release of the Skylake family of processors, the situation changed dramatically: debugging mechanisms were built into PCH [4], which makes it possible to use such a powerful tool for ordinary users - including intruders who can thus gain complete control over the processor. For security reasons, these mechanisms are not activated by default, but in this article we will show that they can be made to work on hardware that is available in regular computer stores.
1. From in-circuit emulator to JTAG
Initially, the in-circuit emulator (ICE) for Intel 80286 processors was a separate computer (“big blue box” [5]), which included a keyboard and monitor. ICE connected instead of the processor being debugged and emulated its behavior. Such an emulator allowed to set breakpoints, change the memory and registers of the processor, write and read.
Later, Intel introduced the I2ICE hardware debugger (Fig. 1), which no longer replaced the standard processor. Using special adapters, the user connected to the system being debugged, and to communicate with the host machine, such a hardware debugger used a standard serial port at 9600 Baud [5].
Fig. 1. Intel I2ICE - one of the first in-circuit debuggers for Intel 80386 processors (recycledgoods.com/intel-series-iv-emul-system-iii514b.html)
As technology advances and clock speeds increase, Intel refuses to develop individual full-featured debugging tools and partially transfers it inside the processor, in the form of a special undocumented ICE-mode (which by its operating principles was very similar to another mode - System Management Mode (SMM), for some The developers of that time were firmly convinced that SMM is nothing more than documented and extended ICE-mode [6]). In turn, the general standardization of debugging mechanisms in the electronics industry leads to the fact that in some Intel 80486 processors there is support for the test interface IEEE1149.1 (JTAG) [7].
The Joint Test Action Group (JTAG) is actually the name of the working group that developed the Standard Test Access Port and Boundary-Scan Architecture (IEEE1149.1 [1]). It allows the use of standard testing and debugging equipment for a wide class of devices. Over time, the abbreviation JTAG became associated with the IEEE1149 standard. In modern microcircuits, it is widely used in industry and is used for testing, firmware, debugging, and output control of microcircuits during production. Physically, JTAG is four or five dedicated lines that make up the Test Access Port (TAP). The standard provides for chaining devices, allowing access to each connected device (Figure 2).
Fig. 2. Consolidation of debugged devices into a JTAG chain
Often, hardware developers extend the basic functionality of JTAG by introducing new features; Intel processors did not become an exception in this sense; starting with the Pentium, a cheaper and more powerful version of the external debugger appears, which uses a special probe mode.
2. Probe debug mode
The probe debug mode (probe mode) is another undocumented mode of operation of Intel processors. It is used for diagnostics and debugging. It cannot be activated without access to the processor JTAG registers. In probe mode, the processor can change memory, write and read from I / O ports. In this mode, the normal execution of instructions is interrupted and the processor goes into idle mode, waiting for commands on the JTAG interface. This behavior fundamentally distinguishes this mechanism from ICE-mode, when instructions on the processor continued to be executed. When entering the probe mode, prefetching and decoding of commands are stopped. Commands from JTAG for modification or reading go directly to the execution units of the processor, thereby bypassing the stages of prefetching and decoding [8], which allows access to a number of registers that are inaccessible from normal modes.
Probe mode is implemented as an extension of JTAG with the addition of several registers and additional R / S #, PRDY signals (for more details on how the probe mode is implemented, see [8], [9]). Third-party companies, along with Intel, are releasing JTAG adapters for x86 processors, which support this expansion, but we will only consider original debugging hardware.
3. Modern hardware and debugging technologies for Intel processors.
Modern Intel processors provide JTAG through three interfaces:
- USB3 Hosting DCI (USB-Debug cable) - through a regular DbC cable;
- BSSB Hosting DCI (Intel SVT Closed Chassis Adapter) - through a specialized adapter (Fig. 5).
Fig. 3. ITP-XDP
Fig. 4. DCI Connection Types
Figure 5. Intel SVT Closed Chassis Adapter
The Intel ITP-XDP interface has a closed protocol, it requires a specialized connector on the board and specialized software Intel System Studio (a trial version is available on the manufacturer's website). The disadvantages also include the high price (about 3,000 US dollars) and the need to sign documents on non-disclosure of information (Corporate Non-Disclosure Agreement) [10]. The high price and CNDA make this debugger inaccessible to the average developer or home use.
However, starting from the processors of the Skylake family, Intel introduced the Direct Connect Interface (DCI) technology, its rather superficial description can be found in the documentation [4]. This technology aims to simplify the development of mobile devices, which implies its disadvantage: it can be activated without any hardware modifications (if there are JTAG lines between PCH and CPU). It is also worth noting that the connection using the Intel SVT adapter uses USB 3.0 lines, but implements its own protocol, which allows you to work with the target system in deep sleep modes. Unfortunately, the SVT adapter at its relatively low price ($ 390) is also available for purchase only after signing by the CNDA.
The most interesting option for an ordinary programmer, which at the same time does not require the signing of any documents before use, is USB3 Hosting DCI. It presents the JTAG interface via a standard USB 3.0 debug cable. When DCI is activated on the target system, the USB 3.0 port goes into slave mode and starts receiving commands from the host system.
One of the important questions about USB 3.0 DbC DCI Hosting is whether it is possible to connect to DCI through any external USB 3.0 port — or if you need a debugging port that is available only on special motherboards for developers. You should consider this issue in more detail.
Among system developers, there is confusion caused by the fact that USB debugging itself appeared quite a long time ago (since USB 2.0) and is currently used by many developers for software debugging of operating system kernels and UEFI applications. However, software debugging via USB (in windbg, UEFI debug agent, etc.) has nothing to do with hardware debugging mechanisms through JTAG, except for the transport itself. The USB 2.0 Bus Controller Specification (EHCI, Enhanced Host Controller Interface) provides a special mechanism called the Debug Port (PCI capability) by which interaction between the server (software or hardware) on the machine being debugged and the client on the host is possible. In particular, the Windows kernel supports debugging via the EHCI Debug Port (this requires a USB 2.0 debug cable, with an integrated USB 2.0 device). In this case, indeed, not every external USB 2.0 port could work as a Debug Port, and this possibility was assigned to certain ports that could not be brought out. It all depended on the hardware manufacturer. Therefore, the developers specifically looked for hardware with a Debug Port output, for debugging via USB. Thus, the Debug Port is an attribute of the USB port.
However, the situation has completely changed with the advent of USB 3.0 and the specification of the controller of this bus XHCI (eXtended Host Controller Interface). This specification also supports USB debugging, but it has undergone significant development and has become known as USB Debug Capability (DbC). According to XHCI, DbC is not a port attribute, but a property of a particular XHCI controller. That is, if this XHCI controller supports DbC, then debugging via USB 3.0 will be available on any (including external) USB 3.0 port. At the same time, DbC automatically selects the first port to which the client is connected, which performs the USB 3.0 transaction, to the debugging cable.
It is important to note here that the first XHCI controllers did not support DbC; therefore, debugging via USB was impossible on systems with such controllers. However, in PCH version 100 and higher (for Skylake), Intel has built its own XHCI controller, which supports DbC. Intel DCI technology (which appeared since the Skylake processors) uses USB 3.0 DbC as a transport to connect the JTAG client. It does not use USB 2.0 Debug Port.
Thus, through any USB 3.0 port you can connect to DCI and perform JTAG debugging.
How can you activate this debugging interface? We found three ways:
1. Activation through EFI Human Interface Infrastructure
EFI Human Interface Infrastructure is a special mechanism that allows you to create a user interface in UEFI, process and control user input. If you look at the structure of modern UEFI BIOS, you can find in them a lot of hidden options that are not available to the user, but are processed. This is the basis of our first method. EFI HII defines default values for all options, including hidden. Having found the option associated with DCI, you can activate it for the default setting, and then, by setting the factory settings in the BIOS, activate DCI. To edit these settings, use the AMI BIOS Configuration Program 5.0 utility. The edited image is programmed in the SPI-flash programmer or through a regular BIOS firmware mechanism, if access permissions allow.
However, this method has a drawback: the system will not boot if Boot Guard is activated, as the utility modifies the EFI module.
2. Activation via Flash Descriptor Region
DCI can also be activated by setting the special bits of the PCH configuration — either manually (they are in Flash Descriptor Region) or by using the Flash Image Tool utility. This method works even when Boot Guard is on.
3. Activation via P2SB device
In the end, you can try to act directly - through a P2SB device. In the documentation for different generations of PCH, you can find a special index and register, using which you can activate DCI on the fly, if the BIOS has not blocked changing the DCI setting.
This method is a vulnerability, because if the BIOS does not block writing to the ECTRL register, then due to the peculiarities of the operation (the ability to save the configuration between reboots after power off), it allows to activate DCI once, and then use the JTAG interface as a hardware backdoor to the system ( for example, disable the lock screen).
We conducted a study [12], as a result of which it turned out that the largest motherboard manufacturers do not set a lock on this register, which allows activating DCI and using this mechanism, for example, to overwrite the BIOS, bypassing all security features, including digital signature verification.
The presence of debugging mechanisms in modern Intel processors allows you to facilitate the development of UEFI modules, operating systems, hypervisors. Security researchers receive a low-level mechanism of privileged access to hardware, which can be used to search for malicious software, research the undocumented capabilities of hardware or specific hardware drivers. But, like any debugging mechanism, DCI can also be used by attackers for unauthorized access to data.
As a defense against such attacks, we recommend activating Boot Guard, checking the DCI activation bit and disabling debugging in the IA32_DEBUG_INTERFACE register (DCI can work, but you cannot stop execution, so you cannot access the memory and registers).
Authors: Maxim Goryachiy, Mark Ermolov.
1. 1149.1-1990 - IEEE Standard Test Access Port and Boundary-Scan Architecture.
2. www.jtag.com/en/content/about-jtag-technologies
3. resources.infosecinstitute.com/close-look-nsa-monitor-catalog-server-hacking
4. 6th Generation Intel Core Processor I / O Datasheet. Vol. 2
5. In-Circuit Emulation, Robert R. Collins (rcollins.org/ddj/Jul97).
6. Intel's System Management Mode by Robert R. Collins // Dr. Dobb's Journal. January 1997.
7. Guk M. Intel processors from 8086 to Pentium II - St. Petersburg: Peter, 1998.
8. Overview of Pentium Probe Mode by Robert R. Collins (rcollins.org/articles/probemd/ProbeMode.html).
9. Guk M. Processors Pentium II, Pentium Pro and just Pentium - SPb: Peter, 1999.
10. www-ssl.intel.com/content/www/us/en/forms/design/registration-privileged.html
11. www.asset-intertech.com/products/jtag-interposers-and-arium-jtag-adapters
12. habrahabr.ru/company/pt/blog/321440
No one is immune from mistakes. This statement also applies to low-level programming, where such familiar tools as debug printing or a software debugger may not be enough at some point. To solve this problem, hardware developers use so-called in-circuit emulators or special JTAG debugging interface if it is present on the target platform (IEEE1149.1 [1]). These debugging mechanisms appeared in the 1980s [2]. Over time, chip manufacturers have expanded the capabilities of these interfaces. Due to this, developers were able to obtain detailed information about energy consumption, find bottlenecks in high-performance algorithms and got many other possibilities.
')
For security researchers, hardware debugging tools are also of interest. They allow you to get low-level access to the system, bypassing the main security tools, to study the behavior of the target platform and its undocumented features. Obviously, such opportunities turned out to be attractive for special services [3].
For a long time, access to these technologies for Intel processors was available only to a limited number of people, which was due to the need to use expensive specialized equipment. But with the release of the Skylake family of processors, the situation changed dramatically: debugging mechanisms were built into PCH [4], which makes it possible to use such a powerful tool for ordinary users - including intruders who can thus gain complete control over the processor. For security reasons, these mechanisms are not activated by default, but in this article we will show that they can be made to work on hardware that is available in regular computer stores.
The evolution of debugging tools on Intel processors
1. From in-circuit emulator to JTAG
Initially, the in-circuit emulator (ICE) for Intel 80286 processors was a separate computer (“big blue box” [5]), which included a keyboard and monitor. ICE connected instead of the processor being debugged and emulated its behavior. Such an emulator allowed to set breakpoints, change the memory and registers of the processor, write and read.
Later, Intel introduced the I2ICE hardware debugger (Fig. 1), which no longer replaced the standard processor. Using special adapters, the user connected to the system being debugged, and to communicate with the host machine, such a hardware debugger used a standard serial port at 9600 Baud [5].
Fig. 1. Intel I2ICE - one of the first in-circuit debuggers for Intel 80386 processors (recycledgoods.com/intel-series-iv-emul-system-iii514b.html)
As technology advances and clock speeds increase, Intel refuses to develop individual full-featured debugging tools and partially transfers it inside the processor, in the form of a special undocumented ICE-mode (which by its operating principles was very similar to another mode - System Management Mode (SMM), for some The developers of that time were firmly convinced that SMM is nothing more than documented and extended ICE-mode [6]). In turn, the general standardization of debugging mechanisms in the electronics industry leads to the fact that in some Intel 80486 processors there is support for the test interface IEEE1149.1 (JTAG) [7].
The Joint Test Action Group (JTAG) is actually the name of the working group that developed the Standard Test Access Port and Boundary-Scan Architecture (IEEE1149.1 [1]). It allows the use of standard testing and debugging equipment for a wide class of devices. Over time, the abbreviation JTAG became associated with the IEEE1149 standard. In modern microcircuits, it is widely used in industry and is used for testing, firmware, debugging, and output control of microcircuits during production. Physically, JTAG is four or five dedicated lines that make up the Test Access Port (TAP). The standard provides for chaining devices, allowing access to each connected device (Figure 2).
Fig. 2. Consolidation of debugged devices into a JTAG chain
Often, hardware developers extend the basic functionality of JTAG by introducing new features; Intel processors did not become an exception in this sense; starting with the Pentium, a cheaper and more powerful version of the external debugger appears, which uses a special probe mode.
2. Probe debug mode
The probe debug mode (probe mode) is another undocumented mode of operation of Intel processors. It is used for diagnostics and debugging. It cannot be activated without access to the processor JTAG registers. In probe mode, the processor can change memory, write and read from I / O ports. In this mode, the normal execution of instructions is interrupted and the processor goes into idle mode, waiting for commands on the JTAG interface. This behavior fundamentally distinguishes this mechanism from ICE-mode, when instructions on the processor continued to be executed. When entering the probe mode, prefetching and decoding of commands are stopped. Commands from JTAG for modification or reading go directly to the execution units of the processor, thereby bypassing the stages of prefetching and decoding [8], which allows access to a number of registers that are inaccessible from normal modes.
Probe mode is implemented as an extension of JTAG with the addition of several registers and additional R / S #, PRDY signals (for more details on how the probe mode is implemented, see [8], [9]). Third-party companies, along with Intel, are releasing JTAG adapters for x86 processors, which support this expansion, but we will only consider original debugging hardware.
3. Modern hardware and debugging technologies for Intel processors.
Modern Intel processors provide JTAG through three interfaces:
- Intel In-Target Probe eXtended Debug Port (ITP-XDP) (Fig. 3);
- Intel Direct Connect Interface (DCI) is a specialized technology that provides a JTAG interface through a USB 3.0 port. There are two connectivity options (Fig. 4):
- USB3 Hosting DCI (USB-Debug cable) - through a regular DbC cable;
- BSSB Hosting DCI (Intel SVT Closed Chassis Adapter) - through a specialized adapter (Fig. 5).
Fig. 3. ITP-XDP
Fig. 4. DCI Connection Types
Figure 5. Intel SVT Closed Chassis Adapter
The Intel ITP-XDP interface has a closed protocol, it requires a specialized connector on the board and specialized software Intel System Studio (a trial version is available on the manufacturer's website). The disadvantages also include the high price (about 3,000 US dollars) and the need to sign documents on non-disclosure of information (Corporate Non-Disclosure Agreement) [10]. The high price and CNDA make this debugger inaccessible to the average developer or home use.
However, starting from the processors of the Skylake family, Intel introduced the Direct Connect Interface (DCI) technology, its rather superficial description can be found in the documentation [4]. This technology aims to simplify the development of mobile devices, which implies its disadvantage: it can be activated without any hardware modifications (if there are JTAG lines between PCH and CPU). It is also worth noting that the connection using the Intel SVT adapter uses USB 3.0 lines, but implements its own protocol, which allows you to work with the target system in deep sleep modes. Unfortunately, the SVT adapter at its relatively low price ($ 390) is also available for purchase only after signing by the CNDA.
The most interesting option for an ordinary programmer, which at the same time does not require the signing of any documents before use, is USB3 Hosting DCI. It presents the JTAG interface via a standard USB 3.0 debug cable. When DCI is activated on the target system, the USB 3.0 port goes into slave mode and starts receiving commands from the host system.
One of the important questions about USB 3.0 DbC DCI Hosting is whether it is possible to connect to DCI through any external USB 3.0 port — or if you need a debugging port that is available only on special motherboards for developers. You should consider this issue in more detail.
Among system developers, there is confusion caused by the fact that USB debugging itself appeared quite a long time ago (since USB 2.0) and is currently used by many developers for software debugging of operating system kernels and UEFI applications. However, software debugging via USB (in windbg, UEFI debug agent, etc.) has nothing to do with hardware debugging mechanisms through JTAG, except for the transport itself. The USB 2.0 Bus Controller Specification (EHCI, Enhanced Host Controller Interface) provides a special mechanism called the Debug Port (PCI capability) by which interaction between the server (software or hardware) on the machine being debugged and the client on the host is possible. In particular, the Windows kernel supports debugging via the EHCI Debug Port (this requires a USB 2.0 debug cable, with an integrated USB 2.0 device). In this case, indeed, not every external USB 2.0 port could work as a Debug Port, and this possibility was assigned to certain ports that could not be brought out. It all depended on the hardware manufacturer. Therefore, the developers specifically looked for hardware with a Debug Port output, for debugging via USB. Thus, the Debug Port is an attribute of the USB port.
However, the situation has completely changed with the advent of USB 3.0 and the specification of the controller of this bus XHCI (eXtended Host Controller Interface). This specification also supports USB debugging, but it has undergone significant development and has become known as USB Debug Capability (DbC). According to XHCI, DbC is not a port attribute, but a property of a particular XHCI controller. That is, if this XHCI controller supports DbC, then debugging via USB 3.0 will be available on any (including external) USB 3.0 port. At the same time, DbC automatically selects the first port to which the client is connected, which performs the USB 3.0 transaction, to the debugging cable.
It is important to note here that the first XHCI controllers did not support DbC; therefore, debugging via USB was impossible on systems with such controllers. However, in PCH version 100 and higher (for Skylake), Intel has built its own XHCI controller, which supports DbC. Intel DCI technology (which appeared since the Skylake processors) uses USB 3.0 DbC as a transport to connect the JTAG client. It does not use USB 2.0 Debug Port.
Thus, through any USB 3.0 port you can connect to DCI and perform JTAG debugging.
DCI activation
How can you activate this debugging interface? We found three ways:
- through the EFI Human Interface Infrastructure;
- PCH Strap (Intel Flash Image Tool);
- P2SB device.
1. Activation through EFI Human Interface Infrastructure
EFI Human Interface Infrastructure is a special mechanism that allows you to create a user interface in UEFI, process and control user input. If you look at the structure of modern UEFI BIOS, you can find in them a lot of hidden options that are not available to the user, but are processed. This is the basis of our first method. EFI HII defines default values for all options, including hidden. Having found the option associated with DCI, you can activate it for the default setting, and then, by setting the factory settings in the BIOS, activate DCI. To edit these settings, use the AMI BIOS Configuration Program 5.0 utility. The edited image is programmed in the SPI-flash programmer or through a regular BIOS firmware mechanism, if access permissions allow.
However, this method has a drawback: the system will not boot if Boot Guard is activated, as the utility modifies the EFI module.
2. Activation via Flash Descriptor Region
DCI can also be activated by setting the special bits of the PCH configuration — either manually (they are in Flash Descriptor Region) or by using the Flash Image Tool utility. This method works even when Boot Guard is on.3. Activation via P2SB device
In the end, you can try to act directly - through a P2SB device. In the documentation for different generations of PCH, you can find a special index and register, using which you can activate DCI on the fly, if the BIOS has not blocked changing the DCI setting.
This method is a vulnerability, because if the BIOS does not block writing to the ECTRL register, then due to the peculiarities of the operation (the ability to save the configuration between reboots after power off), it allows to activate DCI once, and then use the JTAG interface as a hardware backdoor to the system ( for example, disable the lock screen).
We conducted a study [12], as a result of which it turned out that the largest motherboard manufacturers do not set a lock on this register, which allows activating DCI and using this mechanism, for example, to overwrite the BIOS, bypassing all security features, including digital signature verification.
Summary
The presence of debugging mechanisms in modern Intel processors allows you to facilitate the development of UEFI modules, operating systems, hypervisors. Security researchers receive a low-level mechanism of privileged access to hardware, which can be used to search for malicious software, research the undocumented capabilities of hardware or specific hardware drivers. But, like any debugging mechanism, DCI can also be used by attackers for unauthorized access to data.
As a defense against such attacks, we recommend activating Boot Guard, checking the DCI activation bit and disabling debugging in the IA32_DEBUG_INTERFACE register (DCI can work, but you cannot stop execution, so you cannot access the memory and registers).
Authors: Maxim Goryachiy, Mark Ermolov.
Sources
1. 1149.1-1990 - IEEE Standard Test Access Port and Boundary-Scan Architecture.
2. www.jtag.com/en/content/about-jtag-technologies
3. resources.infosecinstitute.com/close-look-nsa-monitor-catalog-server-hacking
4. 6th Generation Intel Core Processor I / O Datasheet. Vol. 2
5. In-Circuit Emulation, Robert R. Collins (rcollins.org/ddj/Jul97).
6. Intel's System Management Mode by Robert R. Collins // Dr. Dobb's Journal. January 1997.
7. Guk M. Intel processors from 8086 to Pentium II - St. Petersburg: Peter, 1998.
8. Overview of Pentium Probe Mode by Robert R. Collins (rcollins.org/articles/probemd/ProbeMode.html).
9. Guk M. Processors Pentium II, Pentium Pro and just Pentium - SPb: Peter, 1999.
10. www-ssl.intel.com/content/www/us/en/forms/design/registration-privileged.html
11. www.asset-intertech.com/products/jtag-interposers-and-arium-jtag-adapters
12. habrahabr.ru/company/pt/blog/321440
Source: https://habr.com/ru/post/341946/
All Articles