If you suspend your transcription on amara.org, please add a timestamp below to indicate how far you progressed! This will help others to resume your work!
Please do not press “publish” on amara.org to save your progress, use “save draft” instead. Only press “publish” when you're done with quality control.
Work by a variety of authors has demonstrated the vulnerability of hardware peripherals to fault-injection-driven firmware-disclosure attacks [1]-- or in other words: glitching attacks that cause devices to 'accidentally' disclose their own firmware. A common form of this attack exploits the behavior of hardware peripherals as they send out bits of read-only memory-- by inducing a glitch at the end of a communication, transmitters can often be inticed to transmit memory beyond the end of the scheduled communcation, often leaking firmware and other device secrets.
For glitching attacks to function properly, glitches must be precisely timed relative to communication events-- a requirement that often requires reverse engineers to develop purpose-built glitch-triggering hardware. GitchKit helps to relieve this burden-- providing an easy, context-aware glitching toolkit that can synchronize glitch events to a variety of communications events, including events generated by common protocols such as USB. GlitchKit builds atop existing open-source software and hardware-- including the GreatFET communications multitool, the FaceDancer USB-hacking toolkit, and the ChipWhisperer fault-injection toolkit-- and provides an entirely-open-source stack for easy glitching-- hopefully making it easier for you to get your hands on that elusive piece of firmware!
This talk presents the theory behind firmware-disclosure glitching, and aims to help every hacker start using open-source tools to start opening up closed systems. Accordingly, we discuss the current state of the GlitchKit project, describe in detail how it can be used to 'break open' existing closed systems, and provide live demonstration of GlitchKit features.
[1] e.g, http://scanlime.org/2016/10/scanlime015-glitchy-descriptor-firmware-grab/