firmware

148 Articles

Hacking Your Way To A Custom TV Boot Screen

December 7, 2018 by 45 Comments

More and more companies are offering ways for customers to personalize their products, realizing that the increase in production cost will be more than made up for by the additional sales you’ll net by offering a bespoke product. It’s great for us as consumers, but unfortunately we’ve still got a ways to go before this attitude permeates all corners of the industry.

[Keegan Ryan] recently purchased a TV and wanted to replace its stock boot screen logo with something of his own concoction, but sadly the set offered no official way to make this happen. So naturally he decided to crack the thing open and do it the hard way The resulting write-up is a fascinating step by step account of the trials and tribulations that ultimately got him his coveted custom boot screen, and just might be enough to get you to take a screw driver to your own flat panel at home.

The TV [Keegan] brought was from a brand called SCEPTRE, but as a security researcher for NCC Group he thought it would be a fun spin to change the boot splash to say SPECTRE in honor of the infamous x86 microarchitecture attack. Practically speaking it meant just changing around two letters, but [Keegan] would still need to figure out where the image is stored, how it’s stored, and write a modified version to the TV without letting the magic smoke escape. Luckily the TV wasn’t a “smart” model, so he figured there wouldn’t be much in the way of security to keep him from poking around.

He starts by taking the TV apart and studying the main PCB. After identifying the principle components, he deduces where the device’s firmware must be stored: an 8 MB SPI flash chip from Macronix. He connects a logic analyzer up to the chip, and sure enough sees that the first few kilobytes are being read on startup. Confident in his assessment, he uses his hot air rework station to lift the chip off the board so that he can dive into its contents.

With the help of the trusty Bus Pirate, [Keegan] is able to pull the chip’s contents and verify its integrity by reading a few human-readable strings from it. Using the binwalk tool he’s able to identify a JPEG image within the firmware file, and by feeding its offset to dd, pull it out so he can view it. As hoped, it’s the full screen SCEPTRE logo. A few minutes in GIMP, and he’s ready to merge the modified image with the firmware and write it back to the chip.

He boots the TV back up and finds…nothing changed. A check of the datasheet for the SPI flash chip shows there are some protection bits used to prevent modifying particular regions of the chip. So after some modifications to the Bus Pirate script and another write, he boots the TV and hopes for the best. Finally he sees the object of his affection pop up on the big screen, a subtle change that reminds him every time the TV starts about the power of reverse engineering.

Supercon Badge Hardware Hacking: Here’s What To Bring

October 25, 2018 by 29 Comments

Hackaday Superconference is just a week away (precious few tickets remain), a celebration of all things Hackaday, which naturally includes creative projects making the most of their hardware. Every attendee gets a platform for hacking in the form of the conference badge.

To make the most of your badge hacking fun, plan ahead so you will have the extra components and the tools you need. At the most basic, bring along a serial to USB cable and a PIC programmer. These are common and if you don’t own them, ask around and you will likely be able to borrow them. Now is also the time to put in a parts order for any components you want to use but don’t have on hand!

The badge is hackable without any extras, but it’s designed for adding hardware and hacking the firmware. We’re excited to see what you can do with it. We gave an overview of this retro themed pocket computer a few days ago, today we’re inviting you to exploit its potential for your hardware hacks.

Continue reading “Supercon Badge Hardware Hacking: Here’s What To Bring” →

I2C Bootloader For ATtiny85 Lets Other Micros Push Firmware Updates

October 20, 2018 by 14 Comments

There are a few different ways of getting firmware onto one of AVR’s ATtiny85 microcontrollers, including bootloaders that allow for firmware to be updated without the need to plug the chip into a programmer. However, [casanovg] wasn’t satisfied with those so he sent us a tip letting us know he wrote an I2C bootloader for the ATtiny85 called Timonel. It takes into account a few particulars of the part, such as the fact that it lacks a protected memory area where a bootloader would normally reside, and it doesn’t have a native I2C interface, only the USI (Universal Serial Interface). He’s just released the first functional version for the ATtiny85, but there’s no reason it couldn’t be made to work with the ATtiny45 and ATtiny25 as well.

Timonel is designed for systems where there is a more powerful microcontroller or microprocessor running the show (such as an ESP8266, Arduino, or even a board like a Raspberry Pi.) In designs where the ATtinys are on an I2C bus performing peripheral functions such as running sensors, Timonel allows the firmware for these peripheral MCUs to be updated directly from the I2C bus master. Embedded below is a video demo of [casanovg] sending simple serial commands, showing a successful firmware update of an AVR ATtiny85 over I2C.

Continue reading “I2C Bootloader For ATtiny85 Lets Other Micros Push Firmware Updates” →

ZPB30A1 Electronic Load Gets An Open Firmware

September 6, 2018 by 30 Comments

Importing cheap equipment and test gear is something of a mixed blessing. It allows you to outfit your lab without emptying your bank account, but on the other hand there’s usually a reason it’s cheap. Of course, the retail price of a piece of hardware shouldn’t be the metric by which we measure its quality, but there’s got to be a few corners cut someplace when they are selling this stuff for a fraction of what the name brands are charging.

A perfect example is the ZHIYU ZPB30A1 electronic load, available from various online importers for about $30 USD. While the price is right for an adjustable load that can handle up to 110 W, it’s got some pretty glaring shortcomings. In an effort to address at least some of those issues, [Luca Zimmermann] has been working on an open source replacement firmware for the load’s STM8S microcontroller.

[Luca] quickly discovered that the device’s STM8S005K6 chip is write protected, so unfortunately you can’t just flash a new firmware to it. If you want to unlock additional features, you need to perform a brain transplant. Luckily these chips are quite cheap, and you can probably add a couple of them to your cart when you order he ZPB30A1.

With the new GPLv3 licensed firmware installed, the device gains constant power and resistances modes (stock firmware can only do constant current), serial logging, and support for adjusting the value of the shunt resistor. There’s even a basic menu system to shuffle through the new modes. There’s still a couple features that haven’t been implemented, such as automatic shutdown, but it’s already a considerable upgrade from the stock software. Now we just need some details on the slick custom enclosure that [Luca] has put his upgraded ZPB30A1 into.

If this looks too easy, you can always go the DIY Arduino route for your load testing needs, or build a monster than can sink up to 1 kW.

[Thanks to Benik3 for the tip.]

Resuming Failed 3D Prints Automatically

April 13, 2018 by 25 Comments

What happens to your 3D printer if the power goes out? What happens if there’s a jam in the nozzle? What happens if your filament breaks, runs out, or turns into a plate of spaghetti? For all these situations, the print fails, wasting plastic and time. For his Hackaday Prize entry, [robert] has come up with a tiny device that saves all those failed prints, and it does it without batteries or a UPS.

The idea behind [robert]’s box is to monitor all the G-code being sent to the printer, and allow a print to be resumed after a failure. The design is simple enough — just a USB mini port on one end, a USB A port on the other, and three buttons in between. This box logs the G-code, and if the printer happens to fail, the box will spring into life allowing you to resume a print from any Z position.

Already [robert] has tested this box on a number of printers including the Prusa i3, the Creality CR-10, and the ever-popular, explodey Anet A8. The project has already gone through a few hardware revisions and there is, of course, a fancy 3D printed enclosure for the board. It’s a great project, and one of the more interesting 3D printing tools we’ve seen in this year’s Hackaday Prize.

The HackadayPrize2018 is Sponsored by:

Unbricking A 3D Printer The Hard Way: By Writing A Bootloader

March 13, 2018 by 34 Comments

There’s a sinking feeling when a firmware upgrade to a piece of equipment goes wrong. We’ve all likely had this happen and  bricked a device or two. If we are lucky we can simply reapply the upgrade or revert to a previous version, and if we’re unlucky we have to dive into a serial debug port to save the device from the junk pile. But what happens when both those routes fail? If you are [Arko], you reverse-engineer the device and write your own bootloader for it.

The offending bricked object was a Monoprice MP Mini Delta 3D printer to which he was foolhardy enough to apply new firmware after seeing a friend’s machine taking it without issue. Finding the relevant debug interface on its main PCB he applied the firmware upgrade again, only to realise that in doing so he had overwritten its bootloader. The machine seemed doomed, but he wasn’t ready to give up.

What follows in his write-up is a detailed examination of the boot mechanism and memory map of an ARM Cortex M0 processor as found in the Monoprice’s STM32F070CB. We learn about vector tables for mapping important addresses of interrupts and execution points, and the mechanics of a bootloader in setting up the application it launches. This section is well worth a read on its own, even for those with no interest in bricked 3D printers.

In the end he had a working bootloader to which he appended the application firmware, but sadly when he powered up the printer there was still no joy. The problem was traced to the serial connection between the ARM doing the printer’s business and the ESP8266 running its display. After a brainstorm suggestion with a friend, a piece of code was found which would set the relevant registers to allow it to run at the correct speed.

So after a lot of work that resulted in this fascinating write-up, there was a working 3D printer. He suggests that mere mortals try asking Monoprice for a replacement model if it happens to their printers, but we’re extremely glad he persevered. Without it we would never have had this fascinating write-up, and would be the poorer without the learning experience.

This isn’t the first time we’ve brought you 3D printer bootloader trickery.

We’re Using The Word Firmware Wrong

September 29, 2017 by 123 Comments

I had an interesting discussion the other day about code written for an embedded system. I was speaking with Voja Antonic about ‘firmware’. The conversation continued forward but I noticed that he was calling it ‘software’. We later discussed it and Voja told me he thought only the parts of the code directly interacting with the microcontroller were firmware; the rest falls under the more generic term of software. It really had me wondering where firmware stops being firmware and is merely software?

The topic has remained on my mind and I finally got around to doing some dictionary searches. I’m surprised that I’ve been using the word differently and I think most of the people I’ve heard use it are doing the same — at least as far as dictionary definitions are concerned. My go to sources are generally Merriam-Webster and Oxford English dictionaries and both indicate that firmware is a type of software that is indelible:

Permanent software programmed into a read-only memory.

computer programs contained permanently in a hardware device (such as a read-only memory)

According to this definition, I have never written a single bit of firmware. Everything I have written has been embedded software. But surely this is a term that must change with the times as technology progress so I kept digging.

Continue reading “We’re Using The Word Firmware Wrong” →