Vista Normal

Hay nuevos artículos disponibles. Pincha para refrescar la página.
Ayer — 2 Abril 2025Salida Principal

A Toothbrush Hacked, in Three Parts

Por: Tom Nardi
2 Abril 2025 at 08:00

It’s official, we’re living in the future. Certainly that’s the only explanation for how [wrongbaud] was able to write a three-part series of posts on hacking a cheap electric toothbrush off of AliExpress.

As you might have guessed, this isn’t exactly a hack out of necessity. With a flair for explaining hardware hacking, [wrongbaud] has put this together as a practical “brush-up” (get it?) on the tools and concepts involved in reverse engineering. In this case, the Raspberry Pi is used as a sort of hardware hacking multi-tool, which should make it relatively easy to follow along.

Modified image data on the SPI flash chip.

The first post in the series goes over getting the Pi up and running, which includes setting up OpenOCD. From there, [wrongbaud] actually cracks the toothbrush open and starts identifying interesting components, which pretty quickly leads to the discovery of a debug serial port. The next step is harassing the SPI flash chip on the board to extract its contents. As the toothbrush has a high-res color display (of course it does), it turns out this chip holds the images which indicate the various modes of operation. He’s eventually able to determine how the images are stored, inject new graphics data, and write it back to the chip.

Being able to display the Wrencher logo on our toothbrush would already be a win in our book, but [wrongbaud] isn’t done yet. For the last series in the post, he shows how to extract the actual firmware from the microcontroller using OpenOCD. This includes how to analyze the image, modify it, and eventually flash the new version back to the hardware — using that debug port discovered earlier to confirm the patched code is running as expected.

If you like his work with a toothbrush, you’ll love seeing what [wrongbaud] can do with an SSD or even an Xbox controller.

AnteayerSalida Principal

Hackaday Links: March 16, 2025

16 Marzo 2025 at 23:00
Hackaday Links Column Banner

“The brickings will continue until the printer sales improve!” This whole printer-bricking thing seems to be getting out of hand with the news this week that a firmware update caused certain HP printers to go into permanent paper-saver mode. The update was sent to LaserJet MFP M232-M237 models (opens printer menu; checks print queue name; “Phew!) on March 4, and was listed as covering a few “general improvements and bug fixes,” none of which seem very critical. Still, some users reported not being able to print at all after the update, with an error message suggesting printing was being blocked thanks to non-OEM toner. This sounds somewhat similar to the bricked Brother printers we reported on last week (third paragraph).

The trouble is, some users are reporting the problem even if they had genuine HP toner installed. Disturbingly, HP support seems to be fine with this, saying that older HP toner “may no longer be recognized due to new security measures.” Well, there’s your problem, lady! The fix, of course, is to buy yet more genuine HP toner, even if your current cartridge still has plenty of life left in it. That’s a pretty deplorable attitude on HP’s part, and more than enough reason to disable automatic firmware updates, or better yet, just disconnect your printer from the Internet altogether.

Here’s a pro-tip for all you frustrated coders out there: no matter how hard the job gets, planting a logic bomb in your code is probably not the right way to go. That’s the lesson that one Davis Lu learned after being convicted of “causing intentional damage to protected computers” thanks to malicious code he planted in his employer’s system. Apparently not optimistic about his future prospects with Eaton Corp. back in 2018, Lu started adding code designed to run a series of infinite loops to delete user profiles. He also went for the nuclear option, adding code to shut the whole system down should it fail to find an Active Directory entry for him. That code was apparently triggered on the day he was fired in 2019, causing global problems for his former employer. Look, we’ve all been there; coding is often lonely work, and it’s easy to fantasize about coding up something like this and watching them squirm once they fire you. But if it gets that bad, you should probably put that effort into finding a new gig.

Then again, maybe the reason you’re dissatisfied with your coding job is that you know some smart-ass LLM is out there waiting to tell you that you don’t know how to code. That’s what happened to one newbie Cursor user who tried to get help writing some video game code from the AI code editor. The LLM spat back about 750 lines of code but refused to reveal the rest, and when he asked to explain why, it suggested that he should develop the logic himself so that he’d be able to understand and maintain the code, and that “Generating code for others can lead to dependency and reduced learning opportunities.” True enough, but do we really need our AI tools to cop an attitude?

And finally, if you’re anything like us, you’re really going to love this walking tour of a container ship’s mechanical spaces. The ship isn’t named, but a little sleuthing suggests it’s one of the Gülsün-class ships built for MSC in 2019, possibly the MSC Mina, but that’s just a guess. This 400-meter monster can carry 23,656 twenty-foot equivalent units, and everything about it is big. Mercifully, the tour isn’t narrated, not that it would have been possible, thanks to the screaming equipment in the engine room. There are captions, though, so you’ll at least have some idea of what you’re looking at in the immaculately clean and cavernously huge spaces. Seriously, the main engine room has to have at least a dozen floors; being on the engineering crew must mean getting your steps in every day. The most striking thing about the tour was that not a single other human being was visible during the entire hour. We suppose that’s just a testament to how automated modern vessels have become, but it still had a wonderfully creepy liminal feeling to it. Enjoy!

Hackaday Links: March 9, 2025

9 Marzo 2025 at 23:00
Hackaday Links Column Banner

It’s been a busy week in space news, and very little of it was good. We’ll start with the one winner of the week, Firefly’s Blue Ghost Mission 1, which landed successfully on the Moon’s surface on March 2. The lander is part of NASA’s Commercial Lunar Payload Services program and carries ten scientific payloads, including a GPS/GNSS receiver that successfully tracked signals from Earth-orbiting satellites. All of the scientific payloads have completed their missions, which is good because the lander isn’t designed to withstand the long, cold lunar night only a few days away. The landing makes Firefly the first commercial outfit to successfully soft-land something on the Moon, and being the first at anything is always a big deal.

Slightly less impressive was Intuitive Machines’ attempt at a landing a day later. Their NOVA-C robotic lander Athena managed a somewhat controlled landing, but the spacecraft is lying on its side rather than upright, a surprisingly common failure mode for recent lunar landings. Also in the failure category is the loss of the world’s first private asteroid mining mission, as well as SpaceX Starship test flight 8, which ended in spectacular fashion this week as Starship exploded soon after booster separation. As usual, Scott Manley has the best analysis of the incident, which seemed to involve a fire in the engine bay that led to a rapid loss of thrust from four of its six engines, and sent the spacecraft tumbling before tearing itself apart. The only good news from the flight was the third successful catch of the returning booster by the chopsticks, which just never gets old.

What does get old is stories about printer manufacturers and their anti-consumer hijinks, especially when it involves one of the only manufacturers who wasn’t playing the “buy our consumables or we brick it” game. In addition to just about every other printer maker, Brother now stands accused of sending firmware up to printers that turns off functionality if non-OEM cartridges are used. The accusations come from Louis Rossman, well-known for his right-to-repair advocacy and, ironically, long-time proponent of Brother printers as least likely to be bricked. His accusation that “Brother is now among the rest of them” is based on a pretty small sample of affected users, and a self-selected one at that, so take that with the requisite amount of salt. For their part, Brother denies the claim, stating simply that “Brother firmware updates do not block the use of third-party ink in our machines.” They don’t go much beyond that by way of an explanation of what’s happening to the users reporting problems other than to say that the users may be confused by the fact that “we like to troubleshoot with Brother Genuine supplies.” What the real story is is anyone’s guess at this point, and the best advice we can offer is either to avoid printers altogether, or just buy the cheapest one you can get and harvest it for parts once the starter cartridges are empty.

If like us you’ve accumulated a large collection of physical media films and TV shows to while away the long dark days of a post-apocalyptic nightmare where Netflix and Hulu are but a distant memory, you might want to rethink your strategy. Some DVD aficionados have found a troubling trend with “DVD rot,” especially with discs manufactured by Warner Brothers Discovery between 2006 and 2008. It’s not clear what’s going on, but it looks like the polycarbonate cover is delaminating from the inner Mylar layer, resulting in cloudy areas that obscure the data. Warner is aware of the problem and will replace defective discs with the same title if possible, or exchange it for a title of like value if the original is no longer available. We’re dismayed that this defect probably includes our beloved Looney Tunes collection, but on the upside, now we have an excuse to sit through forty straight hours of cartoons.

And finally, if you were a NASA rocket engineer in the 1960s, skipping leg day wasn’t an option. That’s because the Saturn V full-stack shake test on the Apollo program was a very hands-on feet-on process. The shake test was performed to make sure nothing was loose on the stack, and that it would be able to withstand not only the shaking induced by those five massive F-1 engines, but also the occasional hurricane that Florida is famous for. To get the rocket shaking, engineers sat on the deck of the gantry with their legs bridging the gap and their feet up against the side of the service module and gave it all they had. Other engineers literally backed them up, to provide something to push against, while another team on the uppermost platform used a rope to play tug-of-war with the command module. They were able to get the stack moving pretty good, with a meter or so of deflection at the escape tower. It does raise the question, though: what would they have done if the test failed?

❌
❌