How To Backup And Restore Your IP Camera Firmware

November 11, 2014 by Rick Osgood 8 Comments

[Filipe] has been playing around with custom firmware for inexpensive IP cameras. Specifically, he has been using cameras based on a common HI3815 chip. When you are playing around with firmware like this, a major concern is that you may end up bricking the device and rendering it useless. [Filipe] has documented a relatively simple way to backup and restore the firmware on these cameras so you can hack to your heart’s content.

The first part of this hack is hardware oriented. [Filipe] cracked open the camera to reveal the PCB. The board has labeled serial TX and RX pads. After soldering a couple of wires to these pads, [Filipe] used a USB to serial dongle to hook his computer up to the camera’s serial port.

Any terminal program should now be able to connect to the camera at 115200 baud while the camera is booting up. The trick is to press “enter” during the boot phase. This allows you to log in as root with no password. Next you can reset the root password and reboot the camera. From now on you can simply connect to the phone via telnet and log in as root.

From here, [Filipe] copies all of the camera’s partitions over to an NFS share using the dd command. He mentions that you can also use FTP for this if you prefer. At this point, the firmware backup is completed.

Knowing how to restore the backup is just as important as knowing how to create it. [Filipe] built a simple TFTP server and copied the firmware image to it in two chunks, each less than 5MB. The final step is to tell the camera how to find the image. First you need to use the serial port to get the camera back to the U-Boot prompt. Then you configure the camera’s IP address and the TFTP server’s IP address. Finally, you copy each partition into RAM via TFTP and then copy that into flash memory. Once all five partitions are copied, your backup is safely restored and your camera can live to be hacked another day.

EFF Launches Open Router Firmware

July 21, 2014 by Eric Evenchick 20 Comments

The Electronic Frontier Foundation have released an alpha of their own Open Wireless Router Firmware as part of the Open Wireless Movement. This project aims to make it easier to share your wireless network with others, while maintaining security and prioritization of traffic.

We’ve seen a lot of hacks based on alternative router firmware, such as this standalone web radio. The EFF have based their router firmware off of CeroWRT, one of the many open source firmware options out there. At this time, the firmware package only targets the Netgear WNDR3800.

Many routers out there have guest modes, but they are quite limited and often have serious vulnerabilities. If you’re interested in sharing your wireless network, this firmware will help out by letting you share a specified amount of bandwidth. It also aims to have a secure web interface, and secure auto-update using Tor.

The EFF has announced this “pre-alpha hacker release” as a call for hackers who want to join in the fun. Development is happening over on Github, where you’ll find all of the source and issues.

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.