Crypto Photography and Custom Firmware

Imagine a camera that took encrypted pictures. If your camera is stolen, the only thing on the memory card would be random data that can only be unlocked with a key. If you hire a photographer, those images cannot be copied without the key. At the very least, it’s an interesting idea made impressive because this actually exists.

[Doug] recently got his hands on a Samsung NX300, a nice camera for the price that conveniently runs Linux and is kinda open-sourced by Samsung. With special firmware, [Doug] created public/private key encryption for this camera, giving only the person with the private key the ability to unlock the pictures taken with this camera.

[Doug] started his build by looking at the firmware for this camera, figuring out how to take everything apart and put it back together. With a few modifications that included encryption for all images taken with this camera, [Doug] repackaged the firmware and upgraded the camera.

The encryption firmware is available on the site, but considering how easily [Doug] was able to make this hack happen, and a great walkthrough of how to actually do it raises some interesting possibilities. The NX300 is a pretty nice camera that’s a little bit above the Canon PowerShot cameras supported by CHDK. It also runs Linux, so if you’re looking for something cool to do with a nice camera, [Doug] has a very good resource.

Amazon Fire TV Update Bricks Hacked Devices

The Amazon Fire TV is Amazon’s answer to all of the other streaming media devices on the market today. Amazon is reportedly selling these devices at cost, making very little off of the hardware sales. Instead, they are relying on the fact that most users will rent or purchase digital content on these boxes, and they can make more money in the long run this way. In fact, the device does not allow users to download content directly from the Google Play store, or even play media via USB disk. This makes it more likely that you will purchase content though Amazon’s own channels.

We’re hackers. We like to make things do what they were never intended to do. We like to add functionality. We want to customize, upgrade, and break our devices. It’s fun for us. It’s no surprise that hackers have been jail breaking these devices to see what else they are capable of. A side effect of these hacks is that content can be downloaded directly from Google Play. USB playback can also be enabled. This makes the device more useful to the consumer, but obviously is not in line with Amazon’s business strategy.

Amazon’s response to these hacks was to release a firmware update that will brick the device if it discovers that it has been rooted. It also will not allow a hacker to downgrade the firmware to an older version, since this would of course remove the root detection features.

This probably doesn’t come as a surprise to most of us. We’ve seen this type of thing for years with mobile phones. The iPhone has been locked to the Apple Store since the first generation, but the first iPhone was jailbroken just days after its initial release. Then there was the PlayStation 3 “downgrade” fiasco that resulted in hacks to restore the functionality. It seems that hackers and corporations are forever destined to disagree on who actually owns the hardware and what ownership really means. We’re locked in an epic game of cat and mouse, but usually the hackers seem to triumph in the end.

Using The Second Microcontroller On An Arduino

While newer Arduinos and Arduino compatibles (including the Hackaday.io Trinket Pro. Superliminal Advertising!) either have a chip capable of USB or rely on a V-USB implementation, the old fogies of the Arduino world, the Uno and Mega, actually have two chips. An ATMega16u2 takes care of the USB connection, while the standard ‘328 or ‘2560 takes care of all ~duino tasks. Wouldn’t it be great is you could also use the ’16u2 on the Uno or Mega for some additional functionality to your Arduino sketch? That’s now a reality. [Nico] has been working on the HoodLoader2 for a while now, and the current version give you the option of reprogramming the ’16u2 with custom sketches, and use seven I/O pins on this previously overlooked chip.

Unlike the previous HoodLoader, this version is a real bootloader for the ’16u2 that replaces the DFU bootloader with a CDC bootloader and USB serial function. This allows for new USB functions like HID keyboard, mouse, media keys, and a gamepad, the addition of extra sensors or LEDs, and anything else you can do with a normal ‘duino.

Setup is simple enough, only requiring a connection between the ‘328 ISP header and the pins on the ’16u2 header. There are already a few samples of what this new firmware for the ’16u2 can do over on [Nico]’s blog, but we’ll expect the number of example projects using this new bootloader to explode over the coming months. If you’re ever in an Arduino Demoscene contest with an Arduino and you’re looking for more pins and code space, now you know where to look.

Improving the T-962 Reflow Oven

The T-962A is a very popular reflow oven available through the usual kinda-shady retail channels. It’s pretty cheap, and therefore popular, and the construction actually isn’t abysmal. The controller for this oven is downright terrible, and [wj] has been working on a replacement firmware for the horribly broken one provided with this oven. It’s open source, and the only thing you need to update your oven is a TTL/UART interface.

[WJ] bought his T-962A even after seeing some of the negative reviews that suggested replacing the existing controller and display. This is not in true hacker fashion – there’s already a microcontroller and display on the board.

The new firmware uses the existing hardware and adds a very necessary modification: stock, the oven makes the assumption that the cold-junction of the thermocouples is at 20°C. The controller sits on top of an oven with two TRIACs nearby, so this isn’t the case, making the temperature calibration of the oven slightly terrible.

After poking around the board, [WJ] found an LPC2000-series microcontroller and a spare GPIO pin for a 1-wire temperature sensor. The temperature sensor is placed right next to the terminal block for the thermocouples for proper temperature sensing.

All the details of updating the firmware appear on a wiki, and the only thing required to update the firmware is a serial/USB/UART converter. A much better solution than ripping out the controller and replacing it with a custom one.

[Sprite_TM]’s Keyboard Plays Snake

Hackaday Prize judge, hacker extraordinaire, and generally awesome dude [Sprite_TM] spends a lot of time at his computer, and that means a lot of time typing on his keyboard. He recently picked up a board with the latest fad in the world of keyboards, a board with individually addressable LEDs. He took this board to work and a colleague jokingly said, ‘You’ve had this keyboard for 24 hours now, and it has a bunch of LEDs and some arrow keys. I’m disappointed you haven’t got Snake running on it yet.” Thus began the quest to put the one game found on all Nokia phones on a keyboard.

The keyboard in question is a Coolermaster Quickfire Rapid-I, a board that’s marketed as having an ARM Cortex CPU. Pulling apart the board, [Sprite] found a bunch of MX Browns, some LEDs, and a 72MHz ARM Cortex-M3 with 127k of Flash and 32k of RAM. That’s an incredible amount of processing power for a keyboard, and after finding the SWD port, [Sprite] attempted to dump the Flash. The security bit was set. There was another way, however.

Coolermaster is actively working on the firmware, killing bugs, adding lighting modes, and putting all these updates on their website. The firmware updater is distributed as an executable with US and EU versions; the EU version has another key. Figuring the only difference between these versions would be the firmware itself, [Sprite] got his hands on both versions, did a binary diff, and found only one 16k block of data at the end of the file was different. There’s the firmware. It was XOR encrypted, but that’s obvious if you know what to look for.

flashdata The firmware wasn’t complete, though; there were jumps to places outside the code [Sprite] had and a large block looked corrupted. There’s another thing you can do with an executable file: run it. With USBPcap running in the background while executing the firmware updater, [Sprite] could read exactly what was happening when the keyboard was updating. With a small executable that gets around the weirdness of the updater, [Sprite] had a backup copy of the keyboard’s firmware. Even if he bricked the keyboard, he could always bring it back to a stock state. It was time to program Snake.

The first part of writing new firmware was finding a place that had some Flash and RAM to store the new code. This wasn’t hard; there was 64k of Flash free and 28K of unused RAM. The calls to the Snake routine were modified from the variables the original firmware had. If, for example, the original keyboard had a call to change the PWM, [Sprite] could change that to the Snake routine.

Snake is fun, but with a huge, powerful ARM in a device that people will just plug into their keyboard, there’s a lot more you can do with a hacked keyboard. Keyloggers and a BadUSB are extremely possible, especially with firmware that can be updated from a computer. To counter that, [Sprite] added the requirement for a physical condition in order to enter Flash mode. Now, the firmware will only update for about 10 seconds after pressing the fn+f key combination.

There’s more to playing Snake on a keyboard; Sprite has also written a new lighting mode, a fluid simulation thingy that will surely annoy anyone who can’t touch type. You can see the videos of that below.

Continue reading “[Sprite_TM]’s Keyboard Plays Snake”

Using the ESP8266 as a Web-enabled sensor

A few months ago, the ESP8266 came onto the scene as a cheap way to add WiFi to just about any project that had a spare UART. Since then, a few people have figured out how to get this neat chip running custom firmware, opening the doors to an Internet of Things based around an ESP8266. [Marc] and [Xavi] just wrote up a quick tutorial on how to turn the ESP8266 into a WiFi sensor platform that will relay the state of a GPIO pin to the Internet.

If you’re going to replicate this project, you won’t be using the stock firmware on the ESP. Instead of the stock firmware, [Marc] and [Xavi] are using the Lua-based firmware that allows for access to a few GPIOs on the device and scripting support to make application development easy. To upload this firmware to the ESP, [Marc] and [Xavi] needed a standard FTDI USB to serial converter, a few AT commands through a terminal program, and a few bits of wire.

The circuit [Marc] and [Xavi] ended up demoing for this tutorial is a simple webpage that’s updated every time a button is pressed. This will be installed in the door of their hackerspace in Barcelona, but already they have a great example of the ESP8266 in use.

How to Backup and Restore Your IP Camera Firmware

[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.