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.
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.
The news was abuzz yesterday with coverage of a study released by Columbia University researchers warning consumers that HP laser printers are wide open to remote tampering and hacking. The researchers claim that the vast majority of printers from HP’s LaserJet line accept firmware updates without checking for any sort of digital authentication, allowing malicious users to abuse the machines remotely. The researchers go so far as to claim that modified firmware can be used to overheat the printer’s fuser, causing fires, to send sensitive documents to criminals, and even force the printers to become part of a botnet.
Officials at HP were quick to counter the claims, stating that all models built in 2009 and beyond require firmware to be digitally signed. Additionally, they say that all of the brand’s laser printers are armed with a thermal cutoff switch which would mitigate the fuser attack vector before any real fire risk would present itself. Despite HP’s statements, the researchers stand by their claims, asserting that vulnerable printers are still available for purchase at major office supply stores.
While most external attacks can easily be prevented with the use of a firewall, the fact that these printers accept unsigned firmware is undoubtedly an interesting one. We are curious to see if these revelations inspire anyone to create their own homebrew LaserJet firmware with advanced capabilities (and low toner warning overrides), or if this all simply fizzles out after a few weeks.
When you think about hacking laptops, it’s highly unlikely that you would ever consider the battery as a viable attack vector. Security researcher [Charlie Miller] however, has been hard at work showing just how big a vulnerability they can be.
As we have been discussing recently, the care and feeding of many batteries, big and small, is handled by some sort of microcontroller. [Charlie] found that a 2009 update issued by Apple to fix some lingering MacBook power issues used one of two passwords to write data to the battery controllers. From what he has seen, it seems these same passwords have been used on all batteries manufactured since that time as well. Using this data, he was subsequently able to gain access to the chips, allowing him to remotely brick the batteries, falsify data sent to the OS, and completely replace the stock firmware with that of his own.
He says that it would be possible for an attacker to inject malware into the battery itself, which would covertly re-infect the machine, despite all traditional removal attempts. Of course, replacing the battery would rectify the issue in these situations, but he says that it would likely be the last thing anyone would suspect as the source of infection. While using the battery to proliferate malware or cause irreversible damage to the computer would take quite a bit of work, [Charlie] claims that either scenario is completely plausible.
He plans on presenting his research at this year’s Black Hat security conference in August, but in the meantime he has created a utility that generates a completely random password for your Mac’s battery. He says that he has already contacted Apple to in order to help them construct a permanent fix for the issue, so an official patch may be available in the near future.
We couldn’t help but poke a little fun in the headline. This is [Alex Miller], a twelve year old who claimed a $3000 bounty from Mozilla. See, [Alex] is a self-taught security guru. When Mozilla upped the reward for discovering and reporting critical security flaws in their software he went to work searching for one. He estimates that he spent an hour and a half a day for ten days to find the hole. Fifteen hours of work for $3000? That’s pretty good!
Is it good or bad to pay for these kind of submissions? The real question: Is the bounty high enough to get blackhats to report vulnerabilities, rather than selling software that exploits them? Let us know what you think in the comments.
[via Zero Day]
Kodak managed to release a product with a big fat security vulnerability. [Casey] figured out that the Kodak W820 WiFi capable digital frame can be hijacked for dubious purposes. The frame can add Internet content as widgets; things like Facebook status, tweets, and pictures. The problem is that the widgets are based on a feed from a website that was publicly accessible. The only difference in the different feed addresses is the last two characters of the frame’s MAC address. Feeds that are already setup can be viewed, but by brute-forcing the RSS link an attacker can take control of the feeds that haven’t been set up yet and preload them with photos you might not want to see when you boot up your factory-fresh frame.
It seems the hole has been closed now, but that doesn’t diminish the delight we get from reading about this foible. There’s a pretty interesting discussion going on in the thread running at Slashdot.
A new open source package called Lightning Rod will help to close security exploits in Adobe’s dirty Flash code. A presentation made at the 26th Chaos Communication Congress showed that the package does its job by reviewing incoming code before the browser executes it. Heise Online is reporting that this method can block over 20 different known attacks and can even be used to filter out malicious JPG attacks. As more vulnerabilities are discovered they can be added to Lightning Rod to close the breach. This amounts to a virus scanner for Flash code. It’s great to have this type of protection but why can’t Adobe handle its security problems?