Unbricking The Da Vinci And Installing Custom Firmware

May 11, 2014 by Brian Benchoff 67 Comments

We’ve seen a lot of projects based around the Da Vinci 3D printer, all deserved, because the Da Vinci is honestly a terrible 3D printer; it has chipped and DRM filament cartridges, a terrible software interface, and completely closed firmware. The first two shortcomings have already been taken care of, and now the door is open for open source firmware on the Da Vinci printer.

[Jason] bricked his Da Vinci when upgrading the firmware, and like any enterprising tinkerer opened up the enclosure and took a look at the electronics board. He found an ATSAM3X8E, a very capable ARM Cortex-M3 microcontroller. This is the same processor in the Arduino Due, making it possible to write code for the Due and upload it to the Da Vinci controller.

After installing Atmel Studio 6, he noticed the printer controller showed up in the device manager, making it a snap to upload updated firmware, unbricking his printer.

With the ability to upload firmware, the problem quickly becomes writing new open source firmware, or at least porting existing firmwares; there are a few people across the internet trying to reverse engineer the board schematic from the PCB. Once that’s done, it should be a trivial matter to make the Da Vinci an open device, and teaching a lesson to every company that thinks they can sell a closed device in what is ultimately an open ecosystem.

Hacking The Linksys WRT120N Part 2

February 21, 2014 by Adam Fabio 12 Comments

linksysjtag

[Craig Heffner] has been busy with his Linksys WRT120N router. When we last checked in on [Craig] he had reverse engineered the obfuscation techniques used in the router’s firmware. Since then, he’s re-enabled JTAG, cracked the “encryption” used for saving configuration backups, and now he’s devised a simple attack to change the admin password. With the firmware unlocked, [Craig] went after the hardware JTAG. His first hurdle was a missing jumper connecting the TDI pin to the processor. With a solder blob making the connection, he then found the router would connect to his JTAG debugger, and immediately reset. TDI had been re-used as a GPIO in software, and assigned to the reset button on the back of the router. [Craig’s] JTAG pod was pulling the pin low and causing the reset. To make matters worse, the bootloader also redefined and checked for the reset button. If the button were pressed it would boot into a recovery mode. [Craig] patched the bootloader with a little help from IDA pro. He then desoldered the router’s flash and programmed it outside the system. The firmware required a similar patch. Rather than desolder the flash chip again, [Craig] created a firmware update the router would accept and flashed it via the router’s web interface.

Since he already was deep into the Linksys Firmware, [Craig] looked for any obvious attack vectors. He found a big one in the /cgi/tmUnBlock.cgi. Inside the firmware, the URL sent to the CGI would be sent through sprintf(). In plain english, it means that no input length checking was happening – so a URL longer than the firmware engineers expected (in this case 256 bytes) would overflow into areas of memory it wasn’t supposed to – in this case, the stack. For an astute attacker, that’s a wide open door. [Craig] was able to use find some Return Oriented Programming (ROP) gadgets and created an input value that would cause the router to reset its own administrator password. After running the exploit, a quick trip to the router’s webpage proved his attack was successful.

If that wasn’t enough, [Craig] also spent some time looking at the patches to the router’s firmware. The release notes of one of the patches mentioned encrypting configuration files. The WRT120N, like many routers, allows the owner to download and save the configuration as a file. It turned out that the “encryption” scheme was nothing more than an exclusive OR with 0xFF. A pretty weak encryption scheme by any standards. To [Craig] we send our congratulations. To the WRT120N software engineers, we’d suggest taking one of [Craig’s] embedded device exploitation classes.

Hacking The Linksys WRT120N

February 7, 2014 by Adam Fabio 27 Comments

[Craig Heffner] recently found himself on the case of the Linksys WRT120N router. The router’s firmware was using some previously unknown form of obfuscation, causing headaches for those wishing to run their own software. The WRT120N, being a 2009 model is somewhat out of date at this point. That didn’t stop [Craig] though, as he dove into reverse engineering the firmware obfuscation.

[Craig] started by running the firmware through his own Binwalk tool. Binwalk analyzes firmware files for known data, be it embedded filesystems, raw compression streams, or binary files. In this case Binwalk only found a small LZMA block which contained the compressed html files for the router’s web interface. The rest of the firmware was unknown data with a high level of entropy. [Craig] couldn’t do anything more with the firmware update file alone, so he ordered a router to attack from the hardware side. Inside he found typical low-end router components: An Atheros AR7240 SoC, a 2MB SPI flash chip, 32MB of RAM. He also found serial and JTAG headers.

[Craig] connected to the serial port and was greeted with a boot menu. This allowed him to run some commands on the router, but didn’t give him any way to dump memory. He had to go straight to the source – connecting directly to the router’s SPI flash with an FTDI C232HM cable. Using libmpsse, another of his open source tools, [Craig] was able to dump the flash. He now had the un-obfuscated bootloader code, albeit in MIPS assembly. [Craig] was then able to go after the bootloader with IDA Pro. After a bit of work, the obfuscation system was exposed. The system was simple – several byte and nibble swaps had been performed between the LZMA header block and the first few bytes of data. [Craig] finished out this part of his hack by writing a simple C program to de-obfuscate and decompress the firmware.

Body Of A Trinket, Soul Of A Digispark

January 22, 2014 by Adam Fabio 12 Comments

TrinketDigispark

Adafruit’s Trinket and digiStump’s Digispark board are rather close cousins. Both use an ATtiny85 microcontroller, both have USB functionality, and both play nice with the Arduino IDE. [Ray] is a fan of both boards, but he likes the Trinket hardware a bit better. He also prefers the Digispark libraries and ecosystem. As such, he did the only logical thing: he turned his Trinket into a Digispark. Step 1 was to get rid of that pesky reset button. Trinket uses Pin 1/PB5 for reset, while Digispark retains it as an I/O pin. [Ray] removed and gutted the reset button, but elected to leave its metal shell on the board.

The next step was where things can get a bit dicey: flashing the Trinket with the Digispark firmware and fuses. [Ray] is quick to note that once flashed to Digispark firmware, the Trinket can’t restore itself back to stock. A high voltage programmer (aka device programmer) will be needed. The flashing process itself is quite a bit easier than a standard Trinket firmware flash. [Ray] uses the firmware upload tool from the Micronucleus project. Micronucleus has a 60 second polling period, which any Trinket veteran will tell you is a wonderful thing. No more pressing the button and hoping you start the download before everything times out! Once the Trinket is running Digispark firmware, it’s now open to a whole new set of libraries and software.

Sucking PIC Firmware Out Of An Old APC Battery Backup

January 18, 2014 by Mike Szczys 30 Comments

reverse-engineering-pic-firmware-of-APC-power-supply

Looking at this huge Uninterruptible Power Supply we are a little envious. It’s meant to hang on the wall of a utility room and power your critical devices. [Radek Hvizdos] has had it in service for quite some time, and when he started thinking of replacing the internal battery he decided to see if he could also extend the functionality. To do so he needed to get at the firmware of the chip controlling the device. And so began his adventure of dumping the firmware from the read-protected PIC 18F452.

The challenge of dumping code from a write-protected chip is in itself a fun project. But [Radek] was actually interested in fixing bugs and adding features. The wishlist feature we’d be most interested in is a kind of triage for shutting down devices as the internal battery starts to run low. Nice! But starting from scratch with the firmware is a no-go. You can see the two places where he connected to the PCB. The upper is for using a PIC programmer. The lower is an I2C connection used to dump the EEPROM with an improvised Bus Pirate.

In the end it was improper lock bit settings that opened the door to grabbing the firmware. The bootloader section of the PIC is not locked, and neither is the ability to read from FLASH at run-time. These two combined allowed him to write his own code which, when flashed to the bootloader section, dumps the rest of the firmware so that it may be combined into a complete file afterward. Since posting this fascinating article he has made a follow-up about disassembling the code.

Reverse Engineering A D-Link Backdoor

October 14, 2013 by Mathieu Stephan 47 Comments

Here’s one true hack (Google cache link) for our dear Hackaday readers. On a Saturday night, as [Craig] didn’t have anything else to do, he decided to download the firmware of an old D-Link DIR-100 router (because who wouldn’t?). His goal was to see what interesting things he could find in it. He fired up binwalk to extract the SquashFS file system, then opened the router webserver on the multi-processor disassembler/debugger IDA. [Craig] discovered that the webserver is actually a modified version of thttpd, providing the administrative interface for the router. As you can see in the picture above, it seems Alphanetworks (a spin-off of D-Link) performed the modifications.

Luckily for [Craig], the guys at Alphanetworks were kind enough to prepend many of their custom function names with the string “alpha”. Looking at the disassembly of the http identification functions revealed that a backdoor is implemented on the firmware. If one malicious user has the string “xmlset_roodkcableoj28840ybtide” as his browser user agent, no authentication is required to gain access to the router. One of the comments on the reddit thread points out that reading that string backwords results in: “edit by (04882) joel backdoor”.

Hacking A Medion WiFi Streaming Radio Found At Aldi

June 21, 2013 by Mike Szczys 20 Comments

hacking-medion-streaming-wifi

On a shopping trip at Aldi [Aaron Christophel] came across this Medion streaming device which connects to your home network via WiFi and works as an Internet radio. He couldn’t resist buying one, and managed to do quite a bit of hacking on the device (translated) once he got it home.

His first order of business was a hardware teardown. An inspection of the board showed what was obviously an unpopulated footprint for a USB mini jack. He added the component, thinking it would allow him to connect it to a computer, but that didn’t work. To investigate the issue further he connected to the device’s serial port using the hard-to-guess credentials root and password. It’s running a Linux kernel and the lsusb command revealed that the USB is enabled as host mode. This mean you can attach mass storage… sweet!

He also did some firmware hacking. Above is the confirmation screen for flashing his altered image file. This resulted in a custom splash screen when it boots up.