Hackaday Links: May 18, 2014

May 18, 2014 by Brian Benchoff 9 Comments

Think the original Pong is cool? How about point to point Pong? [v8ltd] did it in three months, soldering all the leads directly to the chip pins. No sockets required. It’s insane, awesome, a masterpiece of craftsmanship, and surprising it works.

[Jeremy Cook] is building a servo-powered light graffiti thing and needed a laser diode. How do you control a laser pointer with a microcontroller? Here’s how. They’re finicky little buggers, but if you get the three-pack from Amazon like [Jeremy] did, you get three chances to get it right.

NFC tags in everything! [Becky] at Adafruit is putting them in everything. Inside 3D printed rings, glued onto rings, and something really clever: glued to your thumbnail with nail polish. Now you can unlock your phone with your thumb instead of your index finger.

Photographs capture still frames, but wouldn’t it be great if a camera could capture moving images? No, we’re not talking about video because this is the Internet where every possible emotion, reaction, and situation can be expressed with an animated GIF. Meet OTTO, the camera that captures animated GIFs! It’s powered by the Raspberry Pi compute module, so that’s interesting.

[Nate] was getting tired of end mills rolling around his bench. That’s a bad thing. He came up with a solution, though: Mill a piece of plywood into a tray to hold end mills.

The Da Vinci printer, a printer that only costs $500 because they’re banking on the Gillette model, has been cracked wide open by resetting the DRM, getting rid of the proprietary host software, and unbricking the device. Now there’s a concerted effort to develop custom firmware for the Da Vinci printer. It’s extraordinarily bare bones right now, but the pins on the microcontroller are mapped, and RepRap firmwares are extremely modular.

Firmware For Cheap Bluetooth Modules

May 18, 2014 by Brian Benchoff 43 Comments

If you’ve ever built anything with a microcontroller, some sort of sensor, and a connection to the outside world, you’re probably wondering how those places in China can pump out cheap electronics for a mere percentage of what it costs you to pull a DIY. It’s not just volume – it’s engineering; if something has Bluetooth, you find a Bluetooth module with a built-in microcontroller so you can write firmware to it.

The BC417 is the System on Chip found in the very popular BlueCore4-Ext Bluetooth module featuring 8Mbits of Flash (75% of which is used for Bluetooth related stuff), somewhere around 12 kB of RAM, with everything run in a virtual machine. [pfalcon] wrote an extremely experimental firmware for this device that allows anyone to create a wireless sensor node for peanuts. These devices are almost as cheap as a bare ATMega, so the possibilities are interesting, to say the least.

At this point, the hardest part of putting custom firmware on these devices is programming them. For that, [Elastic Sheep] comes to the rescue with a parallel port to SPI interface. There’s also a firmware dumper and some breakout boards available. These modules are pretty cheap, and the pitch isn’t too bad, so you might be able to etch your own boards should you want to experiment a little.

Thanks [Peter] for sending this in.

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.