An RGB laser projector opened up on a workbench

Laser Projector Needs Hardware Hack After Software Mod

You probably recognize that dreadful feeling when you reboot a gadget after updating its firmware, only to be greeted by a blank screen and an unresponsive device. This apparently happened to the previous owner of a bricked RGB laser projector that [Buy It Fix It] got his hands on: it briefly flashed its laser on power-up but otherwise remained completely dead.

A thorough inspection of the major components didn’t reveal any physical damage, so the issue had to be in software. [Buy It Fix It] managed to connect his Segger J-link programmer to the STM32 main processor and downloaded the contents of its firmware, only to find the remains of a PDF file which seemed to have been accidentally flashed into the chip’s program space. Fixing the device should then just be a matter of restoring the proper firmware, but [Buy It Fix It] wasn’t able to find a copy of it anywhere.

A PCB with a few mod wires on itWhat he did find was Maximus64’s GitHub repository that contained a software mod for a different projector model, as well as its original firmware. Flashing that version didn’t fix [Buy It Fix It]’s projector either, although it did now start to actuate its galvos.

A bit of reverse engineering revealed that the two projectors were very similar from a hardware point of view, but had their laser drivers hooked up to different I/O pins: simply cutting the board traces and soldering some wires to re-route the signals was enough to bring the projector back into a working state.

Having to modify hardware in order to make it fit a piece of software is unfortunate, but sometimes you just have to make do with what you’ve got. If you’ve got no firmware to begin with, then you might even have to write your own from scratch.

Continue reading “Laser Projector Needs Hardware Hack After Software Mod”

The Meraki AP PCB on a desk, case-less, with three USB-UARTs connected to its pins - one for interacting with the device, and two for monitoring both of the UART data lines.

Flashing Booby-Trapped Cisco AP With OpenWrt, The Hard Way

Certain manufacturers seriously dislike open-source firmware for their devices, and this particular hack deals with quite extreme anti-hobbyist measures. The Meraki MR33, made by Cisco, is a nice access point hardware-wise, and running OpenWrt on it is wonderful – if not for the Cisco’s malicious decision to permanently brick the CPU as soon as you enter Uboot through the serial port. This AP seems to be part of a “hardware as a service” offering, and the booby-trapped Uboot was rolled out by an OTA update some time after the OpenWrt port got published.

There’s an older Uboot version available out there, but you can’t quite roll back to it and up to a certain point, there was only a JTAG downgrade path noted on the wiki – with its full description consisting of a “FIXME: describe the process” tag. Our hacker, an anonymous user from the [SagaciousSuricata] blog, decided to go a different way — lifting, dumping and modifying the onboard flash in order to downgrade the bootloader, and guides us through the entire process. There’s quite a few notable things about this hack, like use of Nix package manager to get Python 2.7 on an OS which long abandoned it, and a tip about a workable lightweight TFTP server for such work, but the flash chip part caught our eye.

The flash chip is in TSOP48 package and uses a parallel interface, and an iMX6.LL devboard was used to read, modify and flash back the image — hotswapping the chip, much like we used to do with old parallel-interface BIOS chips. We especially liked the use of FFC cables and connectors for connecting the flash chip to the devboard in a way that allows hotswapping – now that we can see it, the TSOP 0.5 mm pitch and 0.5 mm FFC hardware are a match made in heaven. This hack, of course, will fit many TSOP48-equipped devices, and it’s nice to have a toolkit for it in case you don’t have a programmer handy.

In the end, the AP got a new lease of life, now governed by its owner as opposed to Cisco’s whims. This is a handy tutorial for anyone facing a parallel-flash-equipped device where the only way appears to be the hard way, and we’re glad to see hackers getting comfortable facing such challenges, whether it’s parallel flash, JTAG or power glitching. After all, it’s great when your devices can run an OS entirely under your control – it’s historically been that you get way more features that way, but it’s also that the manufacturer can’t pull the rug from under your feet like Amazon did with its Fire TV boxes.

We thank [WifiCable] for sharing this with us!

(Ed Note: Changed instances of “OpenWRT” to “OpenWrt”.)

Ethics Whiplash As Sonos Tries Every Possible Wrong Way To Handle IoT Right

We’re trying to figure out whether Sonos was doing the right thing, and it’s getting to the point where we need pins, a corkboard, and string. Sonos had been increasing the functionality of its products and ran into a problem as they hit a technical wall. How would they keep the old speakers working with the new speakers? Their solution was completely bizarre to a lot of people.

First, none of the old speakers would receive updates anymore. Which is sad, but not unheard of. Next they mentioned that if you bought a new speaker and ran it on the same network as an old speaker, neither speaker would get updates. Which came off as a little hostile, punishing users for upgrading to newer products.

The final bit of weirdness was their solution for encouraging users to ditch their old products. They called it, “trading in for a 30% discount”, but it was something else entirely. If a user went into the system menu of an old device and selected to put it in “Recycle Mode” the discount would be activated on their account. Recycle Mode would then, within 30 days, brick the device. There was no way to cancel this, and once the device was bricked it wouldn’t come back. The user was then instructed to take the Sonos to a recycling center where it would be scrapped. Pictures soon began to surface of piles of bricked Sonos’s. There would be no chance to sell, repair, or otherwise keep alive what is still a fully functioning premium speaker system.

Why would a company do this to their customers and to themselves? Join me below for a guided tour of how the downsides of IoT ecosystem may have driven this choice.

Continue reading “Ethics Whiplash As Sonos Tries Every Possible Wrong Way To Handle IoT Right”

Shorting Pins On A Raspberry Pi Is A Bad Idea; PMIC Failures Under Investigation

You may have noticed, we’re fans of the Raspberry Pi here at Hackaday. Hardly a day goes by that we don’t feature a hack that uses a Pi somewhere in the build. As useful as the Pis are, they aren’t entirely without fault. We’ve talked about the problems with the PoE hat, and multiple articles about keeping SD cards alive. But a new failure mode has popped that is sometimes, but not always, caused by shorting the two power rails on the board.

The Pi 3 B+ has a new PMIC (Power Management Integrated Circuit) made by MaxLinear. This chip, the MxL7704, is a big part of how the Raspberry Pi foundation managed to make the upgrades to the Pi 3 without raising the price over $35.

A quick look at the Raspberry Pi forum shows that some users have been experiencing a specific problem with their new Raspberry Pi 3 B+ units, where the power LED will illuminate but the unit will not boot. The giveaway is zero voltage on the 3v3 pin. It’s a common enough problem that it’s even mentioned in the official boot problems thread.

Make sure the probe you are measuring with does not slip, and simultaneously touches any of the other GPIO pins, as that might instantly destroy your PI, especially shorting the 3V3 pin to the 5V pin will prove to be fatal.

Continue reading “Shorting Pins On A Raspberry Pi Is A Bad Idea; PMIC Failures Under Investigation”

IOT Startup Bricks Customers Garage Door Intentionally

Internet of Things startup Garadget remotely bricked an unhappy customer’s WiFi garage door for giving a bad Amazon review and being rude to company reps. Garadget device owner [Robert Martin] found out the hard way how quickly the device can turn a door into a wall. After leaving a negative Amazon review, and starting a thread on Garadget’s support forum complaining the device didn’t work with his iPhone, Martin was banned from the forum until December 27, 2019 for his choice of words and was told his comments and bad Amazon review had convinced Garadget staff to ban his device from their servers.

The response was not what you would expect a community-funded startup. “Technically there is no bricking, though,” the rep replied. “No changes are made to the hardware or the firmware of the device, just denied use of company servers.” Tell that to [Robert] who can’t get into his garage.

This caused some discontent amoung other customers wondering if it was just a matter of time before more paying customers are subjected to this outlandish treatment. The Register asked Garadget’s founder [Denis Grisak] about the situation, his response is quoted below.

 It was a Bad PR Move, Martin has now had his server connection restored, and the IOT upstart has posted a public statement on the matter.– Garadget

This whole debacle brings us to the conclusion that the IoT boom has a lot of issues ahead that need to be straightened out especially when it comes to ethics and security. It’s bad enough to have to deal with the vagaries of IoT Security and companies who shut down their products because they’re just not making enough money. Now we have to worry about using “cloud” services because the people who own the little fluffy computers could just be jerks.

Saving A Bricked Phone With A Pencil Lead

[stompyonos] bricked his Samsung Captivate. Not wanting to be without a phone for a while, he researched a fix online and found shorting a pair of pins on the USB port would put the phone into download mode, saving his phone. The only problem for this plan is [stompy] didn’t have any resistors on hand. Instead, he came up with a wonderful MacGyverism using a piece of paper, a bit of graphite, and a pair of paper clips.

The process of unbricking a Captivate requires a 300 or 330 kΩ resistor across pins 4 and 5 of the mini USB port. This can be done with a few resistors, but [stompy] only had a multimeter lying around. After scribbling a good bit of pencil lead on a piece of paper, he attached two paper clips to make a variable resistor, dialed it in to about 300 kΩ, and cut up an old Nokia charger for its USB plug.

Not bad for a very easy fix that didn’t cost [stompyonos] a dime, and certainly better than a $500 paperweight.

A Tale Of (un)bricking A $10k Microsoft Surface Unit

We’ve all had that sinking feeling as a piece of hardware stops responding and the nasty thought of “did I just brick this thing?” rockets to the front of our minds. [Florian Echtler] recently experienced this in extremis as his hacking on the University of Munich’s Microsoft Surface 2.0 left it unresponsive. He says this is an 8,000 Euro piece of hardware, which translates to around $10,000! Obviously it was his top priority to get the thing working again.

So what’s the first thing you should do if you get your hands on a piece of hardware like this? Try to run Linux on the thing, of course. And [Florian] managed to make that happen pretty easily (there’s a quick proof-of-concept video after the break). He took a Linux kernel drive written for a different purpose and altered it to interface with the MS Surface. After working out a few error message he packaged it and called to good. Some time later the department called him and asked if his Linux kernel work might have anything to do with the display being dead. Yikes.

He dug into the driver and found that a bug may have caused the firmware on the USB interface chip to be overwritten. The big problem being that they don’t just distribute the image for this chip. So he ended up having to dump what was left from the EEPROM and rebuild the header byte by byte.

Continue reading “A Tale Of (un)bricking A $10k Microsoft Surface Unit”