Unlike software vulnerabilities, hardware security flaws are not always possible to fix. However, this is no reason to be frustrated! The security of IoT, phones, tablets, control units, etc. still needs to be researched. At the very least, this will help alert users to the vulnerabilities as well as fix the flaws in new versions of the products.
Our team dug into one of the most popular debuggers for microcontrollers — J-Link, and found some vulnerabilities in its licensing system which may allow you to turn a budget version of the device into an expensive one in seconds.
Some background to J-Link, the device in question
J-Link is one of the most popular microcontroller debuggers among developers, enthusiasts, and cybersecurity specialists. Its benefits include:
- a huge list of supported microcontrollers and processor cores
- support for all common debugging protocols
- high-speed performance
- excellent free software
SEGGER, the manufacturer of J-Link, has been producing its flagship product for over 15 years, and in that time it has fully experienced the problem of counterfeiting. Various marketplaces are filled with offers of J-Link clones for a much lower price than the original. However, most of them copy old versions of J-Link (v8, v9, or older).
SEGGER developers must have relied on their anti-counterfeiting experience when implementing more reliable methods of protection against cloning in the new versions — v10 and v11. They were the focus of our research.
J-Link models
J-Link is not just one device, but a whole line of products that differ both in their hardware and software features. The available features are defined by licenses that can be integrated into the device or purchased separately from the manufacturer’s website.
J-Link BASE
The set of embedded licenses in this model is limited to basic features only.
J-Link PLUS
This model has an extended set of embedded licenses that provides access to all software features and technologies of the vendor.
J-Link PRO
This model, like J-Link PLUS, has a full set of embedded licenses. J-Link PRO:
- can operate at higher speeds.
- has an Ethernet port.
- is based on a different microcontroller and has an integrated field-programmable gate array (FPGA).
J-Link EDU
This is the lowest-end model designed for non-commercial use that comes without technical support. Its available features are identical to those of J-Link BASE. The user must agree to the Terms of Use before each use (Fig. 1).
J-Link EDU, J-Link BASE, and J-Link PLUS are in fact the same device: the schematic, the electronic components, and the firmware are identical, so the three are only different in their sets of embedded licenses.
In this article, we will be looking into J-Link EDU v10, even though all the vulnerabilities we have found apply to EDU, BASE, and PLUS v10 & v11 as well.
Our research: the milestones
Collecting the info
As with any hardware and software appliance, we should start security analysis from its attacker model. For J-Link, it is quite interesting. While researching the device, we realized that protection mechanisms are aimed at preventing a single scenario: a cloned device works with the original software and firmware and continues to operate even after upgrading to new software versions.
The vendor’s focus is on preventing the mass cloning of devices — that is, creating fake devices that the vendor’s software cannot distinguish and block during future updates. However, protection against unscrupulous users who are happy to work with fixed versions of cracked software is of secondary concern. This makes sense as SEGGER sells only the devices, while the software with all updates is supplied free of charge.
Protection mechanisms cope well with their main task, which is to prevent device cloning. In any case, we have not found any vulnerabilities during our research that enable the creation of such fake devices, which could operate with the original firmware and software. However, we have identified certain flaws that allow some licensing mechanisms to be bypassed.
Digging into J-Link EDU v10
Having disassembled the device (Fig. 2), we found a NXP LPC4322 microcontroller, which implements all the low-level logic, stores embedded licenses, and is controlled from a PC via the USB interface.
There is a debug interface on the printed circuit board that is probably used at the factory for flashing the microcontroller. However, the interface is blocked and cannot be used to connect to the microcontroller and dump the firmware. Of course, this is an intentional measure of protection against those looking to manipulate the device.
Thus, we have found that it is impossible to simply read the firmware from the device via the debug connector. Following a little research into the vendor’s PC software, it became clear that the firmware can be dumped using the J-Link update procedure via USB. After updating the software to a new version and connecting the device to a PC, a dialog box would normally appear prompting to update it.
The firmware can also be forcibly overwritten using the command InvalidateFW. In performing either of these procedures while capturing the USB traffic, we see that the new firmware is transmitted in open, unencrypted form. However, you won’t find this data in the same form in the software folder: firmware is stored in encrypted files, and, in the earlier software versions, firmware was stored in compressed form in JLinkARM.dll. Thus, we have obtained the firmware dump, which opens up opportunities for reverse engineering and research.
A quick analysis shows that the developers have divided the flash memory of the LPC4322 microcontroller into three parts:
The configuration area can be seen in the screenshot (Fig. 3).
Here is how the main firmware and PC software verify that they are working with a genuine device:
- When launched, the firmware reads the serial number of the device, the unique ID of the microcontroller and checks the digital signature
RSASSA-PSS(SHA1(serial_number + uniq_chip_ID)). While the device serial number and the signature itself are stored in the flash memory, the unique ID is burned in by the microcontroller manufacturer (NXP) during production and cannot be changed. All LPC4322 microcontrollers have their own unique IDs that cannot be overwritten. This way, the serial number and signature of one licensed J-Link device cannot be used to make its clones. - The PC software checks the same digital signature of the device by requesting the microcontroller’s unique ID with a special command. Naturally, this check can be bypassed by “patching” it in the original firmware, but such clones will lose functionality after the first update.
We have established that copy protection is only in place to distinguish genuine devices from clones. The remaining question is: how does the vendor’s software on a PC differentiate between the various licensed devices based on the same platform? It turns out, this is done by an OEM string and a set of embedded licenses. For instance, J-Link EDU has the OEM string SEGGER-EDU and the licenses FlashBP and GDB, whereas J-Link PLUS has an empty OEM string and the following set of licenses: RDI, FlashBP, FlashDL, JFlash, and GDB. When a J-Link is connected to a PC, the software requests the device's digital signature. With a valid signature, the OEM string and the list of licenses that the device returns are considered trusted.
We found some flaws and reported them to the vendor
Flaw 1. The OEM string and the list of embedded licenses do not have a cryptographic signature and are not tied, in any way, to the device serial number. By overwriting this data, a J-Link EDU can be easily converted into a J-Link PLUS.
The OEM string and the list of licenses are stored in the flash memory in the configuration area. Unlike the microcontroller’s unique ID, this memory can be modified.
One of the overwriting options that first comes to mind is to somehow get a dump of the flash memory, add any changes, and then use the built-in ISP in BootROM LPC4322 and the UART interface to erase the flash memory and write the new, manipulated dump into the device. Though, this will require, at the very least, a disassembly of the device.
But there is another way. After several experiments with the firmware update procedure and attempts to make changes to it, it became clear that the firmware has a digital signature that is checked by the device’s bootloader. This is checked using the manufacturer’s public key, which blocks any attempts to modify the firmware. However, there is a command to force update the firmware, InvalidateFW, which works in a rather peculiar way. During its execution, the device receives the firmware where the ASCII string with the compilation date is modified. For example, the string "compiled Mar 21 2019" is changed to "compiled MAR 21 2019". A computer will check the device's firmware version the next time the device is connected, the date in the latter string will be considered invalid, thus, the firmware will be updated to the version that comes with the vendor's software pack. This is done to enable a rollback to an older version of the firmware in case there are problems after the update.
Interestingly, a dump containing an invalid date successfully passes the bootloader signature check and is thereby executed. As we discovered, this is because the first 0x1A0 bytes of the firmware are not signed or checked by the bootloader. Ironically, this area is the most important part of the firmware—it contains interrupt vectors, including the reset vector, which specifies the instruction to begin code execution (Fig. 4).
Flaw 2. Partial coverage of the firmware by a digital signature makes it possible to execute arbitrary code on the device. Using this vulnerability, it is easy to run your own code that would modify the OEM string and the license set. As a demonstration, we have prepared a script that turns a J-Link EDU into a J-Link PLUS in a matter of seconds. We are not going to publish it as we don’t want to encourage piracy, but we’ll show how it works:
To summarize our discoveries, we would like to note that they are not classical memory corruption vulnerabilities, but rather architectural flaws. Such bugs are much more difficult to patch by releasing a security update as this requires a reworking of the existing device operation logic. And sometimes such a fix is not possible at all because that would break backward compatibility. The following aspects make these flaws easy for users to commit piracy:
- The exploitation of these flaws does not require device disassembly or PCB soldering manipulations — just a PC and a USB interface will suffice.
- The device continues to operate with the original bootloader and firmware.
- The device continues to receive firmware updates and continues to be recognized as original (fixed starting from software version v7.58).
- The script that replaces the licenses needs to be run only once.
- The device can be reverted to its original state at any time without any traces of modification.
Having completed the research, we reported the discovered vulnerabilities to SEGGER. In this communication, we were guided by BI.ZONE Vulnerability Disclosure Policy. SEGGER representatives immediately engaged in a dialogue and promptly prepared and issued a software release that partially fixes the discovered vulnerabilities. The timeline was as follows:
- October 25, 2021: BI.ZONE reported the flaws to SEGGER via a technical support form. After SEGGER’s request, we sent the technical details and PoCs to demonstrate the flaws.
- October 28, 2021: SEGGER confirmed the flaws.
- November 1, 2021: SEGGER informed that a new version of the software was being prepared that would contain partial fixes.
- November 5, 2021: SEGGER released software v7.58 that contained the partial fixes.
After our cursory analysis of the new v7.58 release and communication with the manufacturer, we can produce the following summary of the changes made:
Flaw 1 (missing license signatures) has been partially fixed. In the new versions of the software, the list of embedded licenses is checked based on the device model (EDU, BASE, etc.) The device model is determined by its serial number. For example, if the serial number begins with 26 (which corresponds to the J-Link EDU model) and JFlash is found among the embedded licenses, the device is considered counterfeit. The software versions before v7.58 will still treat the device as licensed.
Flaw 2 (arbitrary code execution) has not been fixed and is not planned to be fixed in the updates for v10 and v11. Fixing this vulnerability requires overwriting the bootloader in the devices that have been manufactured and distributed to users. This is a very risky operation, and it also breaks backward compatibility with previous versions of the software. The fixed bootloader, according to SEGGER, will be implemented only in new versions of the debugger.
Possible implications of the flaws. What is at stake?
Here is what can happen because of the problems in the user device security mechanisms.
User piracy
This is quite costly for the manufacturer. A simple way to bypass the licensing system that does not require disassembly of the device can be attractive to a large number of users. After all, a J-Link Plus is roughly 10 times more expensive than a J-Link EDU.
Supply chain attacks
In this case, it is hard to imagine that someone would introduce malicious code into the debugger firmware. Nevertheless, the very example of the incorrect implementation of firmware signature verification is quite revealing. Such flaws allow a malicious code to be implanted into various user devices while they are en route to the end user.
Conclusions
Correct implementation of protection mechanisms is not an easy task, even for engineers with extensive experience. It is important that security features be examined not only by the developer, but also by third-party experts. Some fresh outlook certainly won’t hurt.
An analysis of device architecture and source code will help to identify vulnerabilities as early as in the design stage — when fixing flaws is far easier and cheaper. Unlike software, not all vulnerabilities in embedded systems can be fixed with a patch update. Some of them will remain in the device for its entire service. Thus, a stitch in time saves nine!
A bonus picture of a debugger debugging itself. Watch for free, no registration
