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.
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.
Continue reading “HDMI Audio and Video for Neo Geo MVS”
A few years ago, some vastly clever people figured out how to listen in on the LCD display on the classic brick Game Boy from 1989. There have been marked improvements over the years, including a few people developing VGA out for the classic Game Boy. Now, the bar has been raised with an HDMI adapter for the Game Boy, designed in such a way that turns everyone’s favorite battery hog into a portable console.
Your classic beige or cleverly named Color Game Boy is composed of two halves. The rear half contains all the important circuitry – the CPU, cartridge connector, and the rest of the smarts that make the Game Boy game. The front half is fairly simple in comparison, just an LCD and a few buttons. By designing an adapter that goes between these two halves, [Zane] and [Joshua] were able to stuff enough circuitry inside the Game Boy to convert the signals going to the LCD to HDMI. Plug that into your TV, and you have a huge modern version of the Super Game Boy, no SNES required.
The HDMIBoy also breaks out the buttons to the classic NES controller connector. With HDMI out and a controller input, the old-school Game Boy become a portable if somehow even more brick-like console.
Thanks to the worldwide proliferation of smartphones, tiny high-resolution displays are common and cheap. Interfacing these displays with anything besides a phone has been a problem. [twl] has a board that does just that, converting HDMI to something these displays can understand, and providing a framebuffer so these displays can be written to through small microcontrollers.
[twl] is using a rather large FPGA to handle all the conversion from HDMI to the DSI the display understands. He’s using an Xilinx Spartan-6-SLX9, one of the most hobbyist friendly devices that is able to be hand soldered. Also on the board is a little bit of SDRAM for a framebuffer, HDMI input, and a power supply for the LCD and its backlight.
On the things [twl] has in his ‘to-do’ list, porting Doom to run on a cellphone display is obviously right at the top. He also wants to test the drawing commands for the Arduino side of his board, allowing any board with the suffix ~’ino to paint graphics and text on small, cheap, high-resolution displays. That’s a capability that just doesn’t exist with products twice [twl]’s projected BOM, and we can’t wait to see what he comes up with.
You can check out the demo video of [twl]’s board displaying the output of a Raspberry Pi below. If you look very closely, you’ll notice the boot/default screen for the display adapter is the Hackaday Jolly Wrencher.
Continue reading “Using Cell Phone Screens with any HDMI Interface”
The Broadcom SOC in the Raspberry Pi is actually surprisingly powerful, it turns out. It’s actually capable of driving a VGA monitor through the GPIO pins using a handful of resistors.
[Gert van Loo], Raspberry Pi chip architect, wizard, and creator of a number of interesting expansion boards showed off a VGA adapter for the new B+ model at the recent Raspberry Pi Jam in Cambridge this week. Apparently, there is a parallel interface on the SoC that can be used to drive VGA with hardware using a resistor ladder DAC. That’s native VGA at 1080p at 60 fps in addition to HDMI for the Raspberry Pi. Only the new Model B+ has enough pins to do this, but it’s an intriguing little board.
The prospect of having two displays for a Raspberry Pi is very interesting, and the remaining four GPIOs available mean a touch screen could be added to one display, effectively making a gigantic Nintendo DS. Of course there are more practical problems a dual display Raspi solves, like driving a projector for the current crop of DSP/resin 3D printers, while still allowing for a usable interface during a print.
The VGA expansion board, “is likely to have issues with EMC,” which means this probably won’t be a product. Getting a PCB made and soldering SMD resistors isn’t that hard, though, and we’ll post an update when the board files are released.
Thanks [Uhrheber] for sending this one in.