[aleaksah] got himself a Mi Smart Kettle Pro, a kettle with Bluetooth connectivity, and a smartphone app to go with it. Despite all the smarts, it couldn’t be turned on remotely. Energized with his vision of an ideal smart home where he can turn the kettle on in the morning right as he wakes up, he set out to right this injustice. (Russian, translated) First, he tore the kettle down, intending to dump the firmware, modify it, and flash it back. Sounds simple enough — where’s the catch?
This kettle is built around the QN9022 controller, from the fairly open QN902X family of chips. QN9022 requires an external SPI flash chip for code, as opposed to its siblings QN9020 and QN9021 which have internal flash akin to ESP8285. You’d think dumping the firmware would just be a matter of reading that flash, but the firmware is encrypted at rest, with a key unique to each MCU and stored internally. As microcontroller reads the flash chip contents, they’re decrypted transparently before being executed. So, some other way had to be found, involving the MCU itself as the only entity with access to the decryption key.
Continue reading “Dumping Encrypted-At-Rest Firmware Of Xiaomi Smart Kettle”
DYMO 550 series printer marketing blurb says “The DYMO® LabelWriter® 550 Turbo label printer comes with unique Automatic Label Recognition™”, which, once translated from marketing-ese, means “this printer has DRM in its goshdarn thermal stickers”. Yes, DRM in the stickers that you typically buy in generic rolls. [FREEPDK] didn’t like that, either, and documents a #FreeDMO device to rid us of yet another consumer freedom limitation, the true hacker way.
The generic BluePill board and two resistors are all you need, and a few extra cables make the install clean and reversible – you could definitely solder to the DYMO printer’s PCBs if you needed, too. Essentially, you intercept the RFID reader connections, where the BluePill acts as an I2C peripheral and a controller at the same time, forwarding the data from an RFID reader and modifying it – but it can also absolutely emulate a predetermined label and skip the reader altogether. If you can benefit from this project’s discoveries, you should also take a bit of your time and, with help of your Android NFC-enabled phone, share your cartridge data in a separate repository to make thwarting future DRM improvements easier for all of us. Continue reading “#FreeDMO Gets Rid Of DYMO Label Printer DRM”
It’s amazing when a skilled hacker reverse-engineers a proprietary format and shares the nitty-gritty with everyone. Today is a day when we get one such write-up – about MemoryStick. It is one of those proprietary formats, a staple of Sony equipment, these SD-card-like storage devices were evidently designed to help pad Sony’s pockets, as we can see from the tight lock-in and inflated prices. As such, this format has always remained unapproachable to hackers. No more – [Dmitry Grinberg] is here with an extensive breakdown of MemoryStick protocol and internals.
If you ever want to read about a protocol that is not exactly sanely designed, from physical layer quirks to things like inexplicable large differences between MemoryStick and MemoryStick Pro, this will be an entertaining read for hackers of all calibers. Dmitry doesn’t just describe the bad parts of the design, however, as much as that rant is entertaining to read – most of the page is taken by register summaries, struct descriptions and insights, the substance about MemoryStick that we never got.
One sentence is taken to link to a related side project of [Dmitry] that’s a rabbithole on its own – he has binary patched MemoryStick drivers for PalmOS to add MemoryStick Pro support to some of the Sony Clie handhelds. Given the aforementioned differences between non-Pro and Pro standards, it’s a monumental undertaking for a device older than some of this site’s readers, and we can’t help but be impressed.
To finish the write-up off, [Dmitry] shares with us some MemoryStick bit-banging examples for the STM32. Anyone who ever wanted to approach MemoryStick, be it for making converter adapters to revive old tech, data recovery or preservation purposes, or simply hacker curiosity, now can feel a bit less alone in their efforts.
We are glad to see such great hacking on the MemoryStick front – it’s much needed, to the point where our only article mentioning MemoryStick is about avoiding use of the MemoryStick slot altogether. [Dmitry] is just the right person for reverse-engineering jobs like this, with extensive reverse-engineering history we’ve been keeping track of – his recent reverse-engineering journey of an unknown microcontroller in cheap E-Ink devices is to behold.
Yesterday we reported that Lattice Semiconductor had inserted a clause that restricted the reverse engineering of bitstreams produced by their FPGA toolchains. Although not explicitly stated, it’s assumed that this was directed toward several projects over the past five years that have created fully open source toolchains by reverse engineering the bitstream protocols of the Lattice ICE40 and ECP5 FPGA architectures. Late yesterday Lattice made an announcement reversing course.
To the open source community, thank-you for pointing out a new bitstream usage restriction in the Lattice Propel license. We are excited about the community’s engagement with Lattice devices and our intent is to not hinder the creation of innovative open source FPGA tools.
It’s refreshing then to see this announcement from Lattice Semiconductor. Even more so is the unexpected turn of speed with which they have done so, within a couple of days of it being discovered by the open-source community. We report depressingly often on boneheaded legal moves from corporations intent on curbing open source uses of their products. This announcement from Lattice removes what was an admonition opposing open source toolchains, can we hope that the company will continue yesterday’s gesture and build a more lasting relationship with the open source community?
The underlying point to this story is that in the world of electronics there has long been an understanding that hardware hackers drive product innovation which will later lead to more sales. Texas Instruments would for years supply samples of exotic semiconductors to impecunious students for one example, and maybe you have a base-model Rigol oscilloscope with a tacitly-approved software hack that gives it an extra 50MHz of bandwidth for another.
We can only congratulate Lattice on their recognition that open source use of their products is beneficial for them, and wish that some of the other companies triggering similar stories would see the world in the same way. Try interacting more with your open source fans; they know and love your hardware more than the average user and embracing that could mean a windfall for you down the road.
The topic of reverse engineering is highly contentious at best when it comes to software and hardware development. Ever since the configuration protocol (bitstream) for Lattice Semiconductor’s iCE40 FPGAs was published in 2015 through reverse engineering efforts, there has been a silent war between proponents of open bitstream protocols and FPGA manufacturers, with the Lattice ECP5’s bitstream format having been largely reverse-engineered at this point.
Update: About eight hours after this article was published, Lattice Semiconductor issued a statement retracting the EULA language that banned bitstream reverse engineering. Please check out Hackaday’s article about this reversal.
Most recently, it appears that Lattice has fired a fresh shot across the bow of the open source projects. A recently discovered addition to the Propel SDK, which contains tools to program and debug Lattice devices, specifically references bitstream reverse engineering. When logged in with an account on the company’s website the user must agree to the Lattice Propel License Agreement for Lattice Propel 1.0 prior to download. That document includes the following language:
In particular, no right is granted hereunder […] (3) for reverse engineering a bitstream format or other signaling protocol of any Lattice Semiconductor Corporation programmable logic device.
Continue reading “Lattice Semiconductor Targets Bitstream Reverse Engineering In Latest Propel SDK License”
[Karsten Nohl] has recently joined the team on Flylogic’s blog. You may remember him as part of the team that reverse engineered the crypto in MiFare RFID chips. In his first post, he starts out with the basics of identifying logic cells. By studying the specific layout of the transistors you can reproduce the actual logic functions of the chip. The end of post holds a challenge for next week (pictured above). It has 34 transistors, 3 inputs, 2 outputs, and time variant behavior. Also, check out the Silicon Zoo which catalogs individual logic cells for identification.
[Zach Barth] has released Ruckingenur II, the game of reverse engineering. The latest in his Games for Engineers series, it is a full game with multiple levels and live action cut scenes. Set with a military theme, the goal is to reverse engineer enemy items. Pictured above is a lock to a weapons cache.
The pixelized style is consistent throughout. Even the cut scenes have the effect. The reverse engineering is fun enough to keep you interested while you learn. There is an in game help system that keeps you on track as well. Our only suggestion is that he get some better costumes next time!