Chip Glitching 101 With [Hash]

March 30, 2025 by Dan Maloney 4 Comments

Ever want to get into reverse engineering but don’t know where to start? You’re in luck — [Hash] just dropped a case study in chip glitching that should get you off on the right foot.

The object of this reverse engineering effort in the video below is a Microchip SAM4C32C, removed from one of the many smart electrical meters [Hash] loves to tear into. This microcontroller was supposed to be locked to prevent anyone from sniffing around in the code, but after soldering the chip to a target board and plugging it into a Chip Whisperer, [Hash] was able to find some odd-looking traces on the oscilloscope. Of particular interest was an unusual pattern on the scope while resetting the chip, which led him to an AI-assisted search for potential vulnerabilities. This allowed him to narrow down the target time for a power glitch, and in only a few seconds, the chip was forced to bypass its security bit and drop into its boot loader. With the keys to the kingdom, [Hash] was able to read the firmware and find all sorts of interesting tidbits.

Obviously, chip glitching isn’t always as easy as this, and even when a manufacturer leaves a vector like this in the chip, exploiting it does take some experience and finesse. But, if you’re going to get started glitching, it makes sense to start with the low-hanging fruit, and having [Hash] along for the ride doesn’t hurt either.

Continue reading “Chip Glitching 101 With [Hash]” →

Exploring The Anatomy Of A Linux Kernel Exploit

June 25, 2023 by Bryan Cockfield 21 Comments

A lot of talk and discussion happens anytime a hardware manufacturer releases a new line of faster, more powerful, or more efficient computers. It’s easy to see better and better specifications and assume that’s where all the progress is made. But without improved software and algorithms, often the full potential of the hardware can’t be realized. That’s the reason for the creation of io_uring, an improved system call interface in the Linux kernel. It’s also where [chompie] went to look for exploits.

The reason for looking here, in a part of the kernel [chompie] had only recently learned about, was twofold. First, because it’s a place where user space applications interact with the kernel, and second because it’s relatively new and that means more opportunities to find bugs. The exploit involves taking advantage of a complicated asynchronous buffer system, specifically at a location where the code confuses a memory location being used by the kernel with one which is supposed to be used for user space.

To actually get this to work as an exploit, though, a much more involved process is needed to make sure the manipulation of these memory addresses results in something actually useful, but it is eventually used to gain local privilege escalation. More about it can be found in this bug report as well. Thanks to the fact that Linux is open-source, this bug can quickly be fixed and the patch rolled out to prevent malicious attackers from exploiting it. Open-source software has plenty of other benefits besides being inherently more secure, though.

Dismantling The Storm Worm Botnet

January 16, 2009 by Eliot 26 Comments

malware

Zero Day has an interview with German researchers who have found a way to take down the Storm Worm botnet. Their program, Stormfucker, takes advantage of flaws in Storm’s command network: Nodes that are NAT‘d only use a four-byte XOR challenge. Nodes that aren’t NAT’d are only using a trivial 64bit RSA signature. Their solution can clean infected machines and also distribute to other nodes. Unfortunately, installing software without the user’s consent is the exact same behavior as malware. Don’t expect to see this in any sort of widespread use. The researchers did point out that some ISPs have moved to shutting off service for infected customers until their machines are cleaned.

IBM Sees Influx In Zero-day Exploits

August 26, 2008 by Benjamin Eckel 7 Comments

IBM’s X-Force security team has released a mid-year report(PDF) stating that the number of zero-day exploits is growing at an alarming rate. For those of you unfamiliar with the term, a zero-day exploit is a program that is created and implemented within 24 hours of the disclosure of a security flaw. These exploits usually affect users before they even know the vulnerability exists and long before a patch is made available. The researchers also found that many of these exploits were targeted at browser plug-ins, which most users utilize on a daily basis.

[Kris Lamb], X-Force operations manager, is blaming the problem on a lack of a unified process for disclosing vulnerabilities. He also claims that the long-held practice of publishing example code of vulnerabilities should be frowned upon.

[via Liquidmatrix]