Once upon a time, arcades were all the rage. You could head down to your local arcade with a pocket full of quarters and try many different games. These days, video arcades are less popular. As a result, many old arcade games are becoming increasingly difficult to find. They are almost like the artifacts of an ancient age. They are slowly left to rot and are often lost or forgotten with time. Enter, MAME.
MAME (Multiple Arcade Machine Emulator) is a software project, the goal of which is to protect gaming history by preventing these arcade machines from being lost or forgotten. The MAME emulator currently supports over 7000 titles, but there are still more out there that require preservation. The hackers who work on preserving these games are like the digital Indiana Jones of the world. They learn about lost games and seek them out for preservation. In some cases, they must circumvent security measures in order to accurately preserve content. Nothing as scary as giant rolling boulders or poison darts, but security nonetheless.
Many of the arcade cabinets produced by a publisher called NMK used a particular sound processor labeled, “NMK004”. This chip contains both a protected internal code ROM and an unprotected external ROM that controls the sound hardware. The actual music data is stored on a separate unprotected EEPROM and is different for each game. The system reads the music data from the EEPROM and then processes it using the secret data inside the NMK004.
The security in place around the internal ROM has prevented hackers from dumping its contents for all this time. The result is that NMK games using this chip have poorly emulated sound when played using MAME, since no one knows exactly how the original chip processed audio. [trap15] found it ridiculous that after 20 years, no one had attempted to circumvent the security and dump the ROM. He took matters into his own hands.
The full story is a bit long and contains several twists and turns, but its well worth the read. The condensed version is that after a lot of trial and error and after writing many custom tools, [trap15] was able to finally dump the ROM. He was able to accomplish this using a very clever trick, speculated by others but never before attempted on this hardware. [trap15] exploited a vulnerability found in the unprotected external ROM in order to trick the system into playing back the protected internal ROM as though it were the sound data stored on the EEPROM. The system would read through the internal ROM as though it were a song and play it out through the speakers. [trap15] recorded the resulting audio back into his PC as a WAV file. He then had to write a custom tool to decode the WAV file back into usable data.
[trap15] has released all of his tools with documentation so other hackers can use them for their own adventures into hardware hacking. The project was a long time in the making and it’s a great example of reverse engineering and perseverance.
The D-Link DSP-W215 Smart Plug, a wireless home automation device for monitoring and controlling electrical outlets has just been hacked. Even though it isn’t readily available from Amazon or Best Buy yet, the firmware is already up on D-Link’s web site. The very well detailed write-up explains all the steps that led to this exploit creation.
First, the firmware was unpacked to examine the file system contents. It was found that the smart plug doesn’t have a normal web-based interface as users are expected to configure it using D-Link’s Android/iOS app. The apps however, appear to use the Home Network Administration Protocol (HNAP) to talk to the smart plug running a lighthttpd server. A look at the latter’s configuration file revealed the functions that could be called without any authentication. Another revealed that the firmware could accept an unlimited amount of POST request bytes which were copied in a fix length buffer without any performed checks. We’ll let our readers head to the original article to see where the author went from this point.
A team of researchers from Georgia Tech unveiled their findings yesterday at the Blackhat conference. Their topic is a power charger exploit that installs malware on iOS devices. Who would have thought that there’d be a security hole associated with the charging port on a device? Oh wait, after seeing hotel room locks exploited through their power jack this is an avenue that should be examined with all device security.
The demonstration used a charger and an BeagleBoard. Plugging in the charger is not enough to trigger the exploit, the user must unlock the screen while charging for it to go into action. But once that’s done the game is over. Their demo removes the Facebook app and replaces it with an infected impostor while leaving the icon in the same place on your home screen. They notified Apple of their findings and a patch will roll out with iOS7. So when would you plug your device into an untrusted charger? Their research includes a photo from an airport where an iPad is connected to the USB port of a public charging station.
The summary on the Blackhat site has download icons for the white paper and presentation slides. At the time of writing we had a hard time getting them to download but succeeded after several tries.
Well that didn’t take long. The team over at GTVHacker have worked their magic on Chromecast. The HDMI dongle announced by Google last week was so popular they had to cancel their 3-free-months of Netflix perk. We think the thing is worth $35 without it, especially if we end up seeing some awesome hacks from the community.
So far this is just getting your foot in the door by rooting the device. In addition to walking through the exploit the wiki instructions give us a lot more pictures of the internals than we saw from the teardown in yesterday’s links post. There’s an unpopulated pad with seventeen connections on the PCB. You can patch into the serial connections this way, running at a 115200 8n1. But you won’t have terminal access out of the box. The exploit uses a vulnerability in the bootloader to flash a hacked system folder which provides root. After wiping the cache it reboots like normal but now you can access a root shell on port 23.
Continue reading “Chromecast bootloader exploit”
A crack has been found in the armor of Windows RT. This subset of Windows 8 is designed to run on ARM processors. The payload listed in the image above allows you to run unsigned desktop applications on the OS.
We haven’t seen very much about the Windows RT package, so it’s nice to hear [Clrokr’s] thoughts on it. As far as he can tell the system has not been watered down from its Intel-aimed (x86) counterpart. Rather, RT seems to be a direct port with what is called “Code Integrity” mechanisms switched on. There is a kernel-level setting, barricaded behind UEFI’s Secure Boot, which determines the minimum software signing level allowed to run on the device. This is set to zero on a Windows 8 machine, but defaults to 8 on an ARM device. [Clrokr] uses a debugger to insert the code seen above into a DLL file in order to reset that minimum signing value to 0.
Do you have a project in mind for which this is useful? We’d love to hear about it in the comments!
Can anyone argue against this being the least-secure hotel room lock on the market? Regular readers will recognize it as an Onity key card lock. A few months back a glaring flaw in the security was exposed that allows these locks to be opened electronically in less than a second. So we are not surprised to hear that a series of hotel room robberies in Houston are suspected to have been performed using this technique.
The image above is from a demonstration video we saw back in October. That hack used an Arduino-compatible chip inside of a dry erase marker as an end-run around the lock’s electronics. It reinforced the warning sound by [Cody Brocious] when he presented the exploit at this year’s Blackhat conference. The barrel jack on the outside of the door lock doubles as a 1-wire communications port and that is how an attacker can gain access. Investigators can find no other means of entry for these thefts.
We applaud one of the victims in this story. At the end of the article she is asked if the information about the Onity flaw should have been kept secret. She said that if there’s a vulnerability that’s not being fixed people have a right to know about it. Bravo [Janet Wolf]!
iClass is an RFID standard that is aimed at better security through encryption and authentication. While it is more secure than some other RFID implementations, it is still possible to hack the system. But initial iClass exploits were quite invasive. [Brad Antoniewicz] published a post which talks about early attacks on the system, and then demonstrates a better way to exploit iClass readers.
We remember seeing the talk on iClass from 27C3 about a year and a half ago. While the technique was interesting, it was incredibly invasive. An attacker needed multiple iClass readers at his disposal as the method involved overwriting part of the firmware in order to get a partial dump, then patching those image pieces back together. [Brad] makes the point that this is fine with an off-the-shelf system, but high-security installations will be using custom images. This means you would need to get multiple readers off the wall of the building you’re trying to sneak into.
But his method is different. He managed to get a dump of the EEPROM from a reader using an FTDI cable and external power source. If you wan to see how he’s circumventing the PIC read protection you’ll have to dig into the source code linked in his article.