A Robust Guide To The Xbox 360 Glitch Hack

The Xbox 360 was a difficult console to jailbreak. Microsoft didn’t want anyone running unsigned code, and darn if they didn’t make it difficult to do so. However, some nifty out of the box thinking and tricky techniques cracked it open like a coconut with a crack in it. For the low down, [15432] has a great in-depth article on how it was achieved. The article is in Russian, so you’ll want to be armed with Google Translate for this one.

The article gets right into the juice of how glitch attacks work—in general, and with regards to the Xbox 360. In the specific case of the console, it was all down to the processor’s RESET line. Flicker it quickly enough, and the processor doesn’t actually reset, but nonetheless its behavior changes. If you time the glitch right, you can get the processor to continue running through the bootloader’s instructions even if a hash check instruction failed. Of course, timing it right was hard, so it helps to temporarily slow down the processor.

From there, the article continues to explore the many and varied ways this hack played out against Microsoft’s copy protection across multiple models and revisions of the Xbox 360. The bit with the BGA ball connections is particularly inspired. [15432] also goes even deeper into a look at how the battle around the Xb0x 360’s DVD-ROM drive got heated.

We seldom talk about the Xbox 360 these days, but they used to grace these pages on the regular. Video after the break.

Continue reading “A Robust Guide To The Xbox 360 Glitch Hack”

Get Your Glitch On With A PicoEMP And A 3D Printer

We’re not sure what [Aaron Christophel] calls his automated chip glitching setup built from a 3D printer, but we’re going to go ahead and dub it the “Glitch-o-Matic 9000.” Has a nice ring to it.

Of course, this isn’t a commercial product, or even a rig that’s necessarily intended for repeated use. It’s more of a tactical build, which is still pretty cool if you ask us. It started with a proof-of-concept exploration, summarized in the first video below. That’s where [Aaron] assembled and tested the major pieces, which included a PicoEMP, the bit that actually generates the high-voltage pulses intended to scramble a running microcontroller temporarily, along with a ChipWhisperer and an oscilloscope.

The trouble with the POC setup was that glitching the target chip, an LPC2388 microcontroller, involved manually scanning the business end of the PicoEMP over the package. That’s a tedious and error-prone process, which is perfect for automation. In the second video below, [Aaron] has affixed the PicoEMP to his 3D printer, giving him three-axis control of the tip position. That let him build up a heat map of potential spots to glitch, which eventually led to a successful fault injection attack and a clean firmware dump.

It’s worth noting that the whole reason [Aaron] had to resort to such extreme measures in the first place was the resilience of the target chip against power supply-induced glitching attacks. You might not need to build something like the Glitch-o-Matic, but it’s good to keep in mind in case you run up against such a hard target. Continue reading “Get Your Glitch On With A PicoEMP And A 3D Printer”

To the left, a breadboard with the ATMega328P being attacked. To the right, the project's display showing multiple ;) smiley faces, indicating that the attack has completed successfully.

Glitching An ATMega328P Has Never Been Simpler

Did you know just how easily you can glitch microcontrollers? It’s so easy, you really have no excuse for not having tried it out yet. Look, [lord feistel] is doing glitching attacks on an ATMega328P! All you need is an Arduino board with its few SMD capacitors removed or a bare 328P chip, a FET, and some sort of MCU to drive it. All of these are extremely generic components, and you can quickly breadboard them, following [lord feistel]’s guide on GitHub.

In the proof-of-concept, you can connect a HD44780 display to the chip, and have the victim MCU output digits onto the display in an infinite loop. Inside of the loop is a command to output a smiley face – but the command is never reachable, because the counter is reset in an if right before it. By glitching the ATMega’s power input, you can skip the if and witness the ;) on your display; it is that simple.

What are you waiting for? Breadboard it up and see for yourself, this might be the method that you hack your next device and make it do your bidding. If the FET-and-MCU glitching starts to fail you at some point, there’s fancier tools you can use, like the ChipWhisperer. As for practical examples, [scanlime]’s elegant glitching-powered firmware hack is hard to forget.

Flipped Bit Could Mark The End Of Voyager 1‘s Interstellar Mission

Sometimes it’s hard to read the tea leaves of what’s going on with high-profile space missions. Weighted down as they are with the need to be careful with taxpayer money and having so much national prestige on the line, space agencies are usually pretty cagey about what’s going on up there. But when project managers talk about needing a “miracle” to continue a project, you know things have gotten serious.

And so things now sit with Voyager 1, humanity’s most distant scientific outpost, currently careening away from Mother Earth at 17 kilometers every second and unable to transmit useful scientific or engineering data back to us across nearly a light-day of space. The problem with the 46-year-old spacecraft cropped up back in November, when Voyager started sending gibberish back to Earth. NASA publicly discussed the problem in December, initially blaming it on the telemetry modulation unit (TMU) that packages data from the remaining operable scientific instruments along with engineering data for transmission back to Earth. It appeared at the time that the TMU was not properly communicating with the flight data system (FDS), the main flight computer aboard the spacecraft.

Since then, flight controllers have determined that the problem lies within the one remaining FDS on board (the backup FDS failed back in 1981), most likely thanks to a single bit of corrupted memory. The Deep Space Network is still receiving carrier signals from Voyager, meaning its 3.7-meter high-gain antenna is still pointing back at Earth, so that’s encouraging. But with the corrupt memory, they’ve got no engineering data from the spacecraft to confirm their hypothesis.

The team has tried rebooting the FDS, to no avail. They’re currently evaluating a plan to send commands to put the spacecraft into a flight mode last used during its planetary fly-bys, in the hope that will yield some clues about where the memory is corrupted, if indeed it is. But without a simulator to test the changes, and with most of the engineers who originally built the spacecraft long gone now, the team is treading very carefully.

Voyager 1 is long past warranty, of course, and with an unparalleled record of discovery, it doesn’t owe us anything at this point. But we’re not quite ready to see it slip into its long interstellar sleep, and we wish the team good luck while it works through the issue.

Hackaday Links Column Banner

Hackaday Links: June 26, 2022

Head for the hills!! We’re all doomed! At least that’s the impression you might get from the headlines about the monster Earth-facing sunspot this week. While any sunspot that doubles in size within a matter of days as AR3038 has done is worth looking at, chances are pretty low that it will cause problems here on Earth. About the best this class of sunspot can manage is an M-class solar flare, which generally cause radio blackouts only at the poles, and may present a radiation problem for the crew of the ISS. So no, this sunspot is probably not going to kill us all. But then again, this is the 2020s, and pretty much everything bad seems like it’s possible.

Speaking of bad outcomes, pity the poor Sonos customers and their ongoing battle with the company’s odd “glitches.” For whatever reason, customers have been getting shipments of Sonos products they never ordered, with at least one customer getting over $15,000 worth of products shipped. The customer reports ordering five Sonos items, but the company saw fit to fill the order six times, stuffing their apartment with goods. Sonos doesn’t appear to be doing much to make it right; while offering the customer free shipping labels to return the goods, they were expected to schlep the packages to a UPS store. And then there’s the money — Sonos charged the customer for all the unordered goods, and won’t issue a refund till it’s all returned.

If you’ve ever wondered exactly what the signals going up and down your cable line look like, you’ll want to check out this video from Double A Labs. Using an RTL-SDR dongle and some spectrum analyzer software they probed the RF signals on the cable, with some fascinating results. The first 11 minutes or so of the video are devoted to setting up the hardware and software, although there is some interesting stuff about broadband network architecture right up at the start. The scans are interesting — you can clearly see the 6-MHz quadrature amplitude modulation (QAM) digital channels. We were surprised to learn that these start at just about the FM broadcast band — about 108 MHz. There were a couple of little surprises hiding in the spectrum, like two unmodulated analog TV carriers in one spot, and the fact that there are over 400 virtual channels jammed into 41 6-MHz QAM channels. Broadband indeed.

Continue reading “Hackaday Links: June 26, 2022”

The Fix Is In: Hubble’s Troubles Appear Over For Now

Good news this morning from low Earth orbit, where the Hubble Space Telescope is back online after a long and worrisome month of inactivity following a glitch with the observatory’s payload computer.

We recently covered the Hubble payload computer in some depth; at the time, NASA was still very much in the diagnosis phase of the recovery, and had yet to determine a root cause. But the investigation was pointing to one of two possible culprits: the Command Unit/Science Data Formatter (CU/SDF), the module that interfaces the various science instruments, or the Power Control Unit (PCU), which provides regulated power for everything in the payload computer, more verbosely known as the SI C&DH, or Scientific Instrument Command and Data Handling Unit.

In the two weeks since that report, NASA made slow but steady progress, methodically testing every aspect of the SI C&DH. It wasn’t until just two days ago, on July 14, that NASA made a solid determination on root cause: the Power Control Unit, or more specifically, the power supply protection circuit on the PCU’s 5-volt rail. The circuit is designed to monitor the rail for undervoltage or overvoltage conditions, and to order the SI C&DH to shut down if the voltage is out of spec. It’s not entirely clear whether the PCU is actually putting out something other than 5 volts, or if the protection circuit has perhaps degraded since the entire SI C&DH was replaced in the last service mission in 2009. But either way, the fix is the same: switch to the backup PCU, a step that was carefully planned out and executed on July 15th.

To their credit, the agency took pains that everyone involved would be free from any sense of pressure to rush a fix — the 30-year-old spacecraft was stable, its instruments were all safely shut down, and so the imperative was to fix the problem without causing any collateral damage, or taking a step that couldn’t be undone. And further kudos go to NASA for transparency — the web page detailing their efforts to save Hubble reads almost like a build log on one of our projects.

There’s still quite a bit of work to be done to get Hubble back into business — the science instruments have to be woken up and checked out, for instance — but if all goes well, we should see science data start flowing back from the space telescope soon. It’s a relief that NASA was able to pull this fix off, but the fact that Hubble is down to its last backup is a reminder Hubble’s days are numbered, and that the best way to honor the feats of engineering derring-do that saved Hubble this time and many times before is to keep doing great science for as long as possible.

ESP32 Vulnerability Affects Older Chips

There is a scene from the movie RED (Retired, Extremely Dangerous) where Bruce Willis encounters a highly-secure door with a constantly changing lock code deep inside the CIA. Knowing the lock would be impossible to break, he simply destroyed the wall next to the door, reached through, and opened the door from the other side. We thought about that when we saw [raelize’s] hack to bypass the ESP32’s security measures.

Before you throw out all your ESP32 spy gadgets, though, be aware that the V3 silicon can be made to prevent the attack. V1 and V2, however, have a flaw that — if you know how to exploit it — renders secure boot and flash encryption almost meaningless.

Continue reading “ESP32 Vulnerability Affects Older Chips”