I made the code kind of generic enough that it should also work with a FET in crowbar mode to do power glitching; I’ll just need to do some work on pulse duration. That’s something that the blank plank might be good for 
5 Likes
What hacking conference exactly?
CypherCon in Milwaukee next April.
1 Like
Ahh. was curious since the 38C3 ( 38th Chaos Communication Congress Infos ) is not far away
1 Like
That’s a lot bigger! Nah, I’m just taking my time putting the materials together. I keep getting distracted by other things 
dont worry mate, i am right behind you building this pico-emp, and my so bought me a chipwhisperer for getting older by one year.
2 Likes
So, it’s not as sexy as using an EMP blast, but…
Have you considered an attack that simply watches the timing from carefully selecting password strings?
I ask because at least some versions of u-boot appear to just do memcmp against the characters that are input:
The problem with memcmp is that it’s neither constant-time nor constant-power. If the first N characters match, then it will return more slowly (and use more power, or use the power for longer) than if the first character is incorrect.
Depending on the memcmp implementation, this might be detectable at 1-3 characters matching, allowing an automated attack to run in somewhat-reasonable timeframes. Whether you look at power usage or RX/TX time just depends on your equipment.
Of course, if the uboot version you’re using hashes the input first, and only compares against a stored hash, this won’t work. Did you request source (since it’s GPL licensed)? If so, that would indicate if they use memcmp or not…
4 Likes
There’s a little more background around all of this that I should’ve explained. It’s all for a talk I’m giving. Originally, I was just going to mention/explain side channel and fault injection attacks and not demo them.
Haha, it’s not so much about being sexy as it is about not modifying the DUT. To do power analysis or power glitching, I’d need to modify the PCB (which I’ve done in other hacks). In both cases, I’d start by removing the bypass caps around the microcontroller until it starts to misbehave, then solder one back on. For power analysis, I’d solder a low resistance shunt resistor in line with VCC to the microcontroller.
For this talk, I wanted to avoid that and keep it a little more approachable. Not everyone has SMD soldering experience, lol.
Absolutely… I do have a Chip Whisperer, and yes, I have used it successfully to do differential power analysis and timing in exactly that way. After the fault injection with the EMP, I plan on writing more code to use a PIO to measure the time between sending the \r and receiving the response to find the password because…
No, I didn’t. The DUT is a knockoff cheapo thing made overseas, and I honestly don’t expect a response from the vendor. What I did do was unsolder the flash chip and read it out using the BP. (BTW, that’s how I found this awesome community - see Bus Pirate 5 resetting itself, causing storage corruption).
Once I had read it out, I dd’d out the bootloader and reverse engineered it in Ghidra. (The vendor did their own really, really bad code for the password*). So I actually know the password, and have gone on the pwn the thing and find other vulns…
That was going to be the main point of the talk, but after being on this forum with @ian, @henrygab, @grymoire, @electronic_eel, and others, I’ve kind of pivoted my talk into more of “Hey Blue Teamers - it doesn’t take a nation-state with unlimited resources and time to perform these attacks! I was able to do them all with a Bus Pirate 5!” (When threat modeling in the ICS and IoT/IIoT world, every project team says “Those are unreasonable attacks, it would take so much resources…” Ugh).
Lol, I think my talk is going to be half what I originally outlined and half love letter to the BP
Thanks again for all of the support and help!
Matt
====
Holy cow, the password code the vendor implemented is bad! Unlimited retries, no penalty (wait time, etc.) for wrong attempts, a stack buffer overflow, and yes; they are using strcpy() to test for correct password (no hashing). When I was a security engineer I would’ve ripped that dev team a new one for all of that. Once I went Red Team, I just drooled over that kind of thing 
3 Likes
Both are great! I was lucky enough to get some classroom training with Colin O’Flynn on using the Chip Whisperer. It’s amazing, but wow, there’s a lot there! Make sure you go through all of the examples and use the Jupyter notebooks they provide.
3 Likes
yeah, once being inside a device its much easier to find crap like that.
got into a device once via a blind command injection over a firmware index file downloaded over http where i pretended to be their server. yoinked a flash dump and sent it ut via wget (abuse of post-file parameter, grabbed result with ncat) and then prodded around more and found a really dumb buffer overflow. app was using GET for CGI but also accepted POST request into a 4KB buffer (useful for stack preparing), then a subfunction had a buffer overflow (main one, too but that was too close to stack top to be useful) and then i ROP’d into the prepared 4KB buffer
4 Likes
Good stuff!
Very few vendors spend the time threat modeling and secure code/design reviews to prevent this kind of thing.
2 Likes
yeah, the S in IOT means security.
thats why i don’t trust IOT at all. Only had the device (was the WIFI updater part of a SENA motorcycle intercom) for some reversing research. found quite a few stupid bugs in their stuff over time. Stupidest one is a USB port that has extra pins hidden that expose a non-disabled SPI debug access
2 Likes
Ugh, “security” through obscurity.
IEC 62443 should be applicable to more stuff besides ICS.
1 Like
yeah. was only a bunch of luck that i found that “feature”. one model had the test points for that port labeled with the pinout. some time later someone in my computerclub noticed that the USB socket had a unusual amount of pins on the board. That one set me off to dig deeper. old micro-usb models used the Samsung MHL plug for hiding the second set of pins. the newer USB-C ones abuse the highspeed lines for that.
Really new ones use a entirely different chipset but i don’t have a sample or tooling for poking around that (can tell that from the firmware files, i got a full archive and automated monitoring on that)
2 Likes
Here’s another low cost device I forgot to mention - the ChipWhisperer Nano ($50 USD)
2 Likes
Not sure if these were mentioned, but I happen to run across a project for voltage glitch tool based on the Pico:
MKesenheimer Blog on PicoGlitcher
https://mkesenheimer.github.io/blog/pico-glitcher-pcb.html
Library used with the PicoGlitcher
There is a subreddit r/hardwarehacking that also mentions this, but can’t post link due to 2 link limit.
2 Likes
Here’s the next step in glitching - power glitching.
I used the blank plank proto board to put together a really dumb simple circuit: BP IO00 goes to the gate of an N-Channel FET. The device’s Vcc/Gnd go across the source and drain:
The voltage across the FET when a glitch pulse is triggered:
The blank plank has pin headers for making the device connections with a couple of extras for hooking up a scope, for example:
In the case of my target, U-Boot is prompting for a password. You get as many tries as you want (bad security), and there is no delay enforced between attempts (more bad security). I know from using a logic analyzer and reverse engineering that part of the code in Ghidra that there is about an 8 microsecond delay between entering the password and U-Boot prompting for the password again (if the password was not accepted).
Triggering a power glitch during that time may result in the microcontroller glitching/skipping over the password verification, which should allow us in without entering the password.
I have been working on a glitch command that works with the UART mode:
The glitch command takes 7 parameters:
- Character than triggers the timing. Here it is ASCII 13, a carriage return
- Initial delay from end of that char transmission to output “ON”
- Variation time - the code will try a pulse at the
delaytime, delay time + 1us, delay + 2us, etc. up to this variation time - output on time - how long output should be on in microseconds
- cycle delay - a little bit of time between attempts so things don’t overheat
- normal response character - something in the response from the DUT to know the glitch didn’t work; basically something in the response that is “normal” for a bad password. In this case, a capital
Pfrom “Please input …” Note - the code only reads up to 20 characters in response from DUT - Finally, how many tries to take.
It’ll run until the device returns something that doesn’t contain the “normal response character” (meaning it glitched), the BP button was pressed, or an exception happened.
The code uses a PIO program to watch the TX line to know when to start the cycle (delay, on, off).
The code is at my fork of the project, I rebase off of the Official project fairly often, so it should be mostly up to date. The code is in the files glitch.h, glitch.c, and glitch.pio in the ./src/commands/uart directory: GitHub - mbrugman67/BusPirate5-firmware at uart-glitching
This same code works equally well for triggering an external device: Any tutorial about glitching - #40 by mbrugman; you just need to set the pulse time long enough to fire the device.
6 Likes
Woah! Bold move just shorting to ground
Have you been successful?
When I read about a glitch hack in the past, they made some effort to keep it at a consistent temperature to make the glitch consistent. However, they were dumping a whole firmware one word at a time with a 1:64 hit rate or something.
Should I pull this into the main firmware?
1 Like
The goal is to just get the micro to flake out just enough to skip an instruction or two. Skip over a jmp or cmp kind of thing.
I haven’t been successful yet, I think I need to remove some more bypass caps and move the high side wire on the DUT so it’s closer to the VCC pin.
My eyes were shot from the SMD work yesterday, I’ll try again today.
If you want it, I can do a PR. It’s your call; it’s kind of a specific, niche thing.
2 Likes
There’s lots of specific niche things , and they make it better and better:)
I actually don’t think it’s too niche. The way you constructed it is useful for various similar things, and the basic concept/framework can be used as a basis for other commands as needed.
3 Likes