The number of hours we spend staring at screens is probably best unknown, but how about the technology that makes up the video on the screen? We’ve all seen a reel-to-reel projector on TV or in a movie or maybe you’re old enough to have owned one, surely some of you still have one tucked away real nice. Whether you had the pleasure of operating a projector or just watched it happen in the movies the concept is pretty straight forward. A long piece of film which contains many individual frames pass in front of a high intensity lamp while the shutter hides the film movement from our eyes and our brain draws in the imaginary motion from frame to frame. Staring at a Blu-ray player won’t offer the same intuition, while we won’t get into what must the painful detail of decoding video from a Blu-ray Disc we will look into a few video standards, and how we hack them.
[Danman] was looking for a way to get the HDMI output from a camera to a PC so it could be streamed over the Internet. This is a task usually done with HDMI capture cards, either PCI or even more expensive USB 3.0 HDMI capture boxes. In his searches, [danman] sumbled across an HDMI extender that transmitted HDMI signals over standard Ethernet. Surely there must be a way to capture this data and turn it back.
The extender boxes [danman] found at everyone’s favorite chinese reseller were simple – just an Ethernet port, HDMI jack, and a power connector – and cheap – just $70 USD. After connecting the two boxes to his network and setting up his camera, [danman] listened in to the packets being set with Wireshark. The basic protocol was easy enough to grok, but thanks to the Chinese engineers and an IP header that was the wrong length, [danman] had to listen to the raw socket.
Once everything was figured out, [danman] was able to recover raw frames from the HDMI extenders, recover the audio, and stream everything to his PC with VLC. All the code is available, and if you’re looking for a way to stream HDMI to multiple locations on a network, you won’t find a better solution that’s this cheap.
One of the biggest trends in DIY electronics, both now and fifty years ago, is creating at home what is usually made in a factory. Fifty years ago, this meant radios and amplifiers. Today, this means smartphones. It used to be the case that you could pull out a Heathkit catalog and find kits for every electronic gadget imaginable. There are no kits for DIY smartphones.
For [Gerard]’s entry for The Hackaday Prize, he’s tapping into the spirit of the decades-old DIY movement and building his own cell phone. He’s calling it the libresmartphone, and it’s able to make calls and send emails, just like any other portable, pocketable computer.
The libresmartphone is built around a Raspberry Pi, with a large battery, HDMI display with touchscreen, and a GSM and GPS module rounding out the build. He’s also rolling his own software to make calls, read SMS, and take a peek into some of the phone’s hardware, like the charge state of the battery.
[Gerard]’s libresmartphone is one of the purest examples of modern DIY electronics you’ll find; it’s not about building something from a kit, but instead building something that’s needed out of the parts he has on hand. That’s the purest example of the DIY movement, and a great entry to this year’s Hackaday Prize.
The 2015 Hackaday Prize is sponsored by:
HDMI is implemented on just about every piece of sufficiently advanced consumer electronics. You can find it in low-end cellphones, and a single board Linux computer without HDMI is considered crippled. There’s some interesting stuff lurking around in the HDMI spec, and at DEF CON, [Joshua Smith] laid the Consumer Electronics Control (CEC) part of HDMI out on the line, and exposed a few vulnerabilities in this protocol that’s in everything with an HDMI port.
CEC is designed to control multiple devices over an HDMI connection; it allows your TV to be controlled from your set top box, your DVD player from your TV, and passing text from one device to another for an On Screen Display. It’s a 1-wire bidirectional bus with 500bits/second of bandwidth. There are a few open source implementations like libCEC, Android HDMI-CEC, and even an Arduino implementation. The circuit to interface a microcontroller with the single CEC pin is very simple – just a handful of jellybean parts.
[Joshua]’s work is based off a talk by [Andy Davis] from Blackhat 2012 (PDF), but greatly expands on this work. After looking at a ton of devices, [Joshua] was able to find some very cool vulnerabilities in a specific Panasonic TV and a Samsung Blu-ray player.
A certain CEC command directed towards the Panasonic TV sent a command to upload new firmware from an SD card. This is somewhat odd, as you would think firmware would be automagically downloaded from an SD card, just like thousands of other consumer electronics devices. For the Samsung Blu-Ray player, a few memcpy() calls were found to be accessed by CEC commands, but they’re not easily exploitable yet.
As far as vulnerabilities go, [Joshua] has a few ideas. Game consoles and BluRay players are ubiquitous, and the holy grail – setting up a network connection over HDMI Ethernet Channel (HEC) – are the keys to the castle in a device no one would ever think of taking a close look at.
Future work includes a refactor of the current code, and digging into more devices. There are millions of CEC-capable devices out on the market right now, and the CEC commands themselves are not standardized. The only way for HDMI CEC to be a reliable tool is to figure out commands for these devices. It’s a lot of work, but makes for a great call to action to get more people investigating this very interesting and versatile protocol.
Just about the hardest thing you’ll ever do with a microcontroller is video. The timing must be precise, and even low-resolution video requires relatively large amounts of memory, something microcontrollers don’t generally have a lot of. HDMI? That’s getting into microcontroller wizard territory.
Despite these limitations, [monnoliv] is working on a GPU for microcontrollers. It outputs 1280×720 over HDMI, has a 24 bit palette, and 2D hardware acceleration.
It’s a very interesting project; usually, if you want graphics and a display in a project, you’re looking at a Linux system, and all the binary blobs and closed source drivers that come with that. [monnoliv]’s HOMER video card doesn’t need Linux, and it doesn’t need a very high-powered microcontroller. It’s just a simple SPI device with a bunch of memory and an FPGA that turns the most minimal microcontroller into a machine that can output full HD graphics.
This isn’t the only open source graphics card for microcontrollers in the Hackaday Prize; just a few days ago, we saw VGAtonic, another SPI-controlled video card for microcontrollers, this time outputting VGA instead of HDMI. Both are excellent projects, and if either makes it into production, they’ll both be cheap: under $100 for both of them. Just the thing if you want to play around with high-resolution video without resorting to Linux.
The 2015 Hackaday Prize is sponsored by:
It warms our hearts when the community gets together. [esar] needed to get a decrypted HDMI stream for his home theater system. A tip-off in the comments and a ton of good old-fashioned hacking resulted in a HDMI splitter converted into a full-featured HDMI decrypter. Here’s the story.
His amazing custom Ambilight clone got profiled here, and someone asked him in the comments if it worked when High-bandwidth Digital Content Protection (HDCP) is on. [esar] lamented that it didn’t. Hackaday readers to the rescue. [Alan Hightower] and [RoyTheReaper] pointed [esar] to the fact that HDMI splitters need to decrypt and re-encrypt the signal to pass it on, and pointed him to a trick to knock out the on-board microcontroller. [esar] took off from there.
Unfortunately, taking the micro out of the picture messed with a lot of other HDMI functionality. So [esar] started digging in the datasheets for the HDMI splitter chip, looking for registers relevant to the re-encryption. If he could get in between the microcontroller and the splitter chip on the I2C bus and disable the re-encryption, he’d be set.
If you’re at all interested in I2C hacking or abusing HDMI splitters, you need to read his post because he details all of the tribulations and triumphs. He first tries just brute-forcing the I2C by overwriting a 1 bit with a 0. This (correctly) signals the micro that there’s been a conflict on the bus, so it re-sends the command again. Dead end.
He then found another signal that the receiver could use say that it wasn’t decrypting. He tried sending this continuously to the splitter so that it would stop encrypting. That worked, but only for one channel, some of the time. It turns out that his code was taking too long in his bit-banged I2C code. He fixes this up and all is well? Well, 90% of the way there.
To hammer down the last 10% of the functionality, [esar] buys a couple more splitters, experiments around with another splitter chipset that works with 3D, and solders some more wires to enable the Audio Return Channel. And after a ton of well-documented hard work, he wins in the end.
[Charlie] was killing some time hacking on some cheap FPGA dev boards he bought from eBay. Initially, he intended to use them to create HDMI ports for a different project before new inspiration hit him. Instead, he added an HDMI port to Neo Geo MVS games. The Neo Geo MVS was a 90’s arcade machine that played gems like the Metal Slug and Samurai Showdown series. [Charlie] has a special knack for mods, being featured on Hackaday before for implementing Zork on hardware and making a mini supergun PCB. What’s especially nice about his newest mod is that the HDMI outputs both audio and video.
[Charlie] obtained the best possible video and audio signal by tapping the digital inputs to the Neo Geo’s DACs (digital-to-analog converter). The FPGA was then used to convert the signals to HDMI, maintaining a digital signal path from video generation to display. While this sounds simple enough, there was a lot that had to be done. The JAMMA video standard’s lower resolution was incompatible with the various resolutions offered by the HDMI protocol. [Charlie] solved this problem by implementing scan doubling using the RAM on the Cyclone II dev board. He then had to downsample the audio to 32kHz (from 55.6kHz) in order to meet the HDMI specs. Getting the sound over HDMI required adding data islands to the signal, a feat [Charlie] admits was a frustrating one.
When he tested the HDMI with his monitor, it was out of spec but still worked. His TV, on the other hand, refused to play it at all. This was due to the Neo Geo outputting 59.1 fps – not the standard 60 fps. Using the FPGA, [Charlie] overclocked the NeoGeo by approximately 1% and used the 27Mhz pixel clock to change the FPGA output to a 720 x 480p signal.
For those that love the scan lines of yore, they can be enabled with the push of a button. [Charlie] notes that there are some slight differences in the shadow effects of some graphics, but he has done his best to minimize them. He also admits that the FPGA code contributes only 100 microseconds of delay compared to analog output, which is fast enough for even the most hardcore gamers.
Check out the video after the break to see how the Neo Geo looks in HDMI along with a side-by-side comparison to a CRT TV.