Supercon 2024: Joshua Wise Hacks The Bambu X1 Carbon

Bambu Labs have been in the news lately. Not because of the machines themselves, but because they are proposing a firmware change that many in our community find restricts their freedom to use their own devices.

What can be done? [Joshua Wise] gave a standout talk on the Design Lab stage at the 2024 Hackaday Superconference where he told the tale of his custom firmware for the Bambu X1 Carbon. He wasn’t alone here; the X1 Plus tale involves a community of hackers working on opening up the printer, but it’s also a tale that hasn’t ended yet. Bambu is striking back. Continue reading “Supercon 2024: Joshua Wise Hacks The Bambu X1 Carbon”

Networking History Lessons

Do they teach networking history classes yet? Or is it still too soon?

I was reading [Al]’s first installment of the Forgotten Internet series, on UUCP. The short summary is that it was a system for sending files across computers that were connected, intermittently, by point-to-point phone lines. Each computer knew the phone numbers of a few others, but none of them had anything like a global routing map, and IP addresses were still in the future. Still, it enabled file transfer and even limited remote access across the globe. And while some files contained computer programs, others files contained more human messages, which makes UUCP also a precursor to e-mail.

What struck me is how intuitively many of this system’s natural conditions and limitations lead to the way we network today. From phone numbers came the need for IP addresses. And from the annoyance of having know how the computers were connected, and to use the bang notation to route a message from one computer to another through intermediaries, would come our modern routing protocols, simply because computer nerds like to automate hassles wherever possible.

But back to networking history. I guess I learned my networking on the mean streets, by running my own Linux system, and web servers, and mail servers. I knew enough networking to get by, but that mostly focused on the current-day application, and my beard is not quite grey enough to have been around for the UUCP era. So I’m only realizing now that knowing how the system evolved over time helps a lot in understanding why it is the way it is, and thus how it functions. I had a bit of a “eureka” moment reading about UUCP.

In physics or any other science, you learn not just the status quo in the field, but also how it developed over the centuries. It’s important to know something about the theory of the aether to know what special relativity was up against, for instance, or the various historical models of the atom, to see how they inform modern chemistry and physics. But these are old sciences with a lot of obsolete theories. Is computer science old enough that they teach networking history? They should!

This QR Code Leads To Two Websites, But How?

QR codes are designed with alignment and scaling features, not to mention checksums and significant redundancy. They have to be, because you’re taking photos of them with your potato-camera while moving, in the dark, and it’s on a curved sticker on a phone pole.  So it came as a complete surprise to us that [Christian Walther] succeeded in making an ambiguous QR code.

Nerd-sniped by [Guy Dupont], who made them using those lenticular lens overlays, [Christian] made a QR code that resolves to two websites depending on the angle at which it’s viewed. The trick is to identify the cells that are different between the two URLs, for instance, and split them in half vertically and horizontally: making them into a tiny checkerboard. It appears that some QR decoders sample in the center of each target square, and the center will be in one side or the other depending on the tilt of the QR code.

Figuring out the minimal-difference QR code encoding between two arbitrary URLs would make a neat programming exercise. How long before we see these in popular use, like back in the old days when embedding images was fresh? QR codes are fun!

Whether it works is probably phone- and/or algorithm-dependent, so try this out, and let us know in the comments if they work for you.

Thanks [Lacey] for the tip!

 

Shellcode Over MIDI? Bad Apple On A PSR-E433, Kinda

If hacking on consumer hardware is about figuring out what it can do, and pushing it in directions that the manufacturer never dared to dream, then this is a very fine hack indeed. [Portasynthica3] takes on the Yamaha PSR-E433, a cheap beginner keyboard, discovers a shell baked into it, and takes it from there.

[Portasynthinca3] reverse engineered the firmware, wrote shellcode for the device, embedded the escape in a MIDI note stream, and even ended up writing some simple LCD driver software totally decent refresh rate on the dot-matrix display, all to support the lofty goal of displaying arbitrary graphics on the keyboard’s dot-matrix character display.

Now, we want you to be prepared for a low-res video extravaganza here. You might have to squint a bit to make out what’s going on in the video, but keep in mind that it’s being sent over a music data protocol from the 1980s, running at 31.25 kbps, displayed in the custom character RAM of an LCD.

As always, the hack starts with research. Identifying the microcontroller CPU lead to JTAG and OpenOCD. (We love the technique of looking at the draw on a bench power meter to determine if the chip is responding to pause commands.) Dumping the code and tossing it into Ghidra lead to the unexpected discovery that Yamaha had put a live shell in the device that communicates over MIDI, presumably for testing and development purposes. This shell had PEEK and POKE, which meant that OpenOCD could go sit back on the shelf. Poking “Hello World” into some free RAM space over MIDI sysex was the first proof-of-concept.

The final hack to get video up and running was to dig deep into the custom character-generation RAM, write some code to disable the normal character display, and then fool the CPU into calling this code instead of the shell, in order to increase the update rate. All of this for a thin slice of Bad Apple over MIDI, but more importantly, for the glory. And this hack is glorious! Go check it out in full.

MIDI is entirely hacker friendly, and it’s likely you can hack together a musical controller that would wow your audience just with stuff in your junk box. If you’re at all into music, and you’ve never built your own MIDI devices, you have your weekend project.

Continue reading “Shellcode Over MIDI? Bad Apple On A PSR-E433, Kinda”

Bone Filament, For Printing Practice Bones

Of course there is bone-simulation filament on the market. What’s fun about this Reddit thread is all of the semi-macabre concerns of surgeons who are worried about its properties matching the real thing to make practice rigs for difficult surgeries. We were initially creeped out by the idea, but now that we think about it, it’s entirely reassuring that surgeons have the best tools available for them to prepare, so why not 3D prints of the actual patient’s bones?

[PectusSurgeon] says that the important characteristics were that it doesn’t melt under the bone saw and is mechanically similar, but also that it looks right under x-ray, for fluorscopic surgery training. But at $100 per spool, you would be forgiven for looking around for substitutes. [ghostofwinter88] chimes in saying that their lab used a high-wood-content PLA, but couldn’t say much more, and then got into a discussion of how different bones feel under the saw, before concluding that they eventually chose resin.

Of course, Reddit being Reddit, the best part of the thread is the bad jokes. “Plastic surgery” and “my insurance wouldn’t cover gyroid infill” and so on. We won’t spoil it all for you, so enjoy.

When we first read “printing bones”, we didn’t know if they were discussing making replacement bones, or printing using actual bones in the mix. (Of course we’ve covered both before. This is Hackaday.)

Thanks [JohnU] for the tip!

Learn New Tools, Or Hone Your Skill With The Old?

Buried in a talk on AI from an artist who is doing cutting-edge video work was the following nugget that entirely sums up the zeitgeist: “The tools are changing so fast that artists can’t keep up with them, let alone master them, before everyone is on to the next.” And while you might think that this concern is only relevant to those who have to stay on the crest of the hype wave, the deeper question resounds with every hacker.

When was the last time you changed PCB layout software or refreshed your operating system? What other tools do you use in your work or your extra-curricular projects, and how long have you been using them? Are you still designing your analog front-ends with LM358s, or have you looked around to see that technology has moved on since the 1970s? “OMG, you’re still using ST32F103s?”

It’s not a simple question, and there are no good answers. Proficiency with a tool, like for instance the audio editor with which I crank out the podcast every week, only comes through practice. And practice simply takes time and effort. When you put your time in on a tool, it really is an investment in that it helps you get better. But what about that newer, better tool out there?

Some of the reluctance to update is certainly sunk-cost fallacy, after all you put so much sweat and tears into the current tool, but there is also a real cost to overcome to learn the new hotness, and that’s no fallacy. If you’re always trying to learn a new way of doing something, you’re never going to get good at doing something, and that’s the lament of our artist friend. Honing your craft requires focus. You won’t know the odd feature set of that next microcontroller as well as you do the old faithful – without sitting down and reading the datasheet and doing a couple finger-stretching projects first.

Striking the optimal balance here is hard. On a per-project basis, staying with your good old tool or swapping to the new hotness is a binary choice, but across your projects, you can do some of each. Maybe it makes sense to budget some of your hacking time into learning new tools? How about ten percent? What do you think?

All The Attacks On The RP2350

Raspberry Pi’s new microcontroller, the RP2350, has a small section of memory that is meant for storing secrets. It’s protected by anti-glitching and other countermeasures, and the Raspberries wanted to test it. So this summer, they gave them out, pre-programmed with a secret string, as part of the badge for DEFCON attendees. The results of the cracking efforts are in, and it’s fair to say that the hackers have won.

First place went to [Aedan Cullen], who also gave a great talk about how he did it at 38C3. One of the coolest features of the RP2350, from a hacker perspective, is that it has dual ARM and dual RISC-V cores onboard, and they can be swapped out by multiplexers. The security module has a critical register that has disable bits for both of these processors, but it turns out that the ARM disable bits have priority. When [Aedan] glitched the security module just right, it disabled the ARM cores but left the RISC-V cores running in the secure context, with full debug(!), and the game was over. As of yet, there is no mitigation for this one, because it’s baked into the secure boot module’s silicon.

[Marius Muench] managed to pre-load malicious code into RAM and glitch a reboot-out-of-secure-mode on the USB module. This one is possibly fixable by checking other reboot flags. [Kévin Courdesses] has a sweet laser fault-injection rig that’s based on the 3D-printable OpenFlexure Delta Stage, which we’ve seen used for microscopy purposes, but here he’s bypassing the anti-glitching circuitry by exposing the die and hitting it hard with photons.

Finally, [Andrew Zonenberg] and a team from IOActive went at the RP2350 with a focused ion beam and just read the memory, or at least the pairwise-OR of neighboring bits. Pulling this attack off isn’t cheap, and it’s a more general property of all anti-fuse memory cells that they can be read out this way. Chalk this up as a mostly-win for the offense in this case.

If you want to read up on voltage glitching attacks yourself, and we promise we won’t judge, [Matthew Alt] has a great writeup on the topic. And ironically enough, one of his tools of choice is [Colin O’Flynn]’s RP2040-based Chip Shouter EMP glitcher, which he showed us how to make and use in this 2021 Remoticon talk.