The FaultyCat is the "bump key" of hardware auditing. It sends high-energy electro-magnetic pulses into target devices, which can cause them to glitch. often revealing encryption keys, bypassing security checks or resetting protection mechanisms.
When starting a hardware audit - the FaultyCat should be the first tool you reach for: it can be used to quickly check if the target device is protected, and if not, glitch it to reveal secrets or bypass protection.
Built on the foundations on an open-source product (the PicoEMP) - the FaultyCat has extra functionality, but remains economical, easy-to-use and safe. Version 2.2 adds extended functionality.
It's portable and self-contained - it's powered by 3xAA batteries - so you're never caught short. The onboard RapsberryPi controller is fully accessible and programmable by the user for custom functionality.
1
2
3
4
5
1. Direct Voltage glitching
Precisely glitch and spike signals such as reset or voltage to manipulate the target system
2. External Triggers
Trigger the FaultyCat manually or electronically device via dedicated pins. Use external triggers such as timers or sensors.
3. Voltage Triggers
Monitor the target's voltage levels and trigger at glitch at preset voltage levels. Allows for triggering glitches during critical phases, such as device boot.
4. Analog Input
Monitor and log analog data from the target; build a knowledge-base of actions and responses to make repeatable operations.
5. JTAG/JWD Scanner
Built-in JTAG/JWD Scanner finds and detects hidden JTAG/JWD pads to find undocumented debug interfaces.
Hardware Auditing techniques can be grouped into two categories: Side-Channel Attacks (SCA) and Electro-magnetic Fault Injection (EMFI). Which technique you need depends a lot on the target device. If the chip is locked but you've got access to its power, clock and data lines - Side Channel Attacks would be possible and effective.
However, if the target is protected: hardened against side-channel attacks, or its power, clock and data lines aren't exposed, or you cannot modify the device: EMFI would be the best candidate.
Side-Channel attacks capture privileged data by using an unprotected or unexpected source. Imagine two people talking in a glass sound-proof room: lip-reading allows us to derive what is being said via the visual prompts - a "side-channel" - as opposed to hearing it, the "protected channel". In hardware, a common example is extracting encryption keys by monitoring micro-fluctuations in the power-consumption when the processor is calculating them.
Side-Channel attacks are not necessarily passive: side-channel extraction can be induced by glitching the target device: briefly spiking power or manipulating the target's clock line can evoke unexpected behaviour, which leads to leaks. In the contect of the glass room: turning off the lights or tapping on the glass may provoke a different behavior from the people talking - they may reveal different or unexpected information.
Electro-magnetic Fault Injection creates faults in a target system without touching it - by directing high-energy electro-magnetic pulses into the chip. These pulses can cause glitches and unexpected behavior. Timing glitches to match important chip processes can allow you to jump or bypass normal behavior - like password verification.
There are two approaches to EMFI: using ultra-precise, ultra-sensitive devices (such as the ChipSHOUTER) to create highly accurate, repeatable experiments. The second approach is to use a simple device designed to send large electrical pulses to cause unexpected behavior.
Key to understanding hardware auditing is the lifecycle. Typically - the end goal is total device control - dumping firmware, bootloaders, or getting a root shell.
If your target device has no protection: you can concentrate on firmware extraction. If the target is locked, you'll need to unlock it, typically via Side-Channel attacks and tools. Likewise, if it's protected, you'll need to use EMFI to bypass protection, and then use Side Channel Attacks to unlock the target, before extracting firmware.
The following table provides a summary of the Hardware Audit Lifecycle.
