DRM has become a four-letter word of late, with even media companies themselves abandoning the practice because of how ineffective it was. DRM wasn’t invented in the early 2000s for music, though. It’s been a practice on virtually everything where software is involved, including arcade cabinets. This is a problem for people who restore arcade machines, and [mon] has taken a swing at unraveling the DRM for a specific type of Konami cabinet.
The game in question, Reflec Beat, is a rhythm-based game released in 2010, and the security is pretty modern. Since the game comes with a HDD, a replacement drive can be ordered with a security dongle which acts to decrypt some of the contents on the HDD, including the game file and some other information. It’s not over yet, though. [mon] still needs to fuss with Windows DLL files and a few levels of decryption and filename obfuscation before getting the cabinet functional again.
The writeup on this cabinet is very detailed, and if you’re used to restoring older games, it’s a bit of a different animal to deal with than the embedded hardware security that older cabinets typically have. If you’ve ever wanted to own one of these more modern games, or you’re interested in security, be sure to check out the documentation on the project page. If your tastes are more Capcom and less Konami, check out an article on their security system in general, or in de-suiciding boards with failing backup batteries.
Believe it or not, there are quite a few people out there who have purchased gun safes that can be remotely unlocked by Bluetooth. Now we can understand why somebody might think this was a good idea: the convenience of being able to hit a button on your phone and have your weapon available in the heat of the moment is arguably a big selling point for people who are purchasing something like this for home defense. But those with a more technical mind will likely wonder if the inherent risks of having your firearm (or other valuables) protected by a protocol that often relies on security by obscurity outweighs the convenience of not needing to enter in a combination on the keypad.
[Two Six Labs] has not publicly released the complete source code of the software demonstrated in their YouTube video for very obvious reasons, but the page on their site does go into fantastic detail on how they uncovered the multiple vulnerabilities that allowed them to write it. Even if you’re not the kind of person who would ever need a gun safe, the information contained in their documentation about analyzing Bluetooth communications is fascinating reading.
It was discovered that the PIN for the safe was actually being transmitted by the accompanying smartphone application in plain-text, which would be bad enough normally. But after further analysis, it became clear that the safe wasn’t even bothering to check the PIN code anyway.
Scripting app interactions with ADB and Python
For extra style points, [Two Six Labs] also show a way to brute force the PIN using the Vaultek Android application by writing a Python script that punches in codes sequentially until it hits on the right one; the developers didn’t even bother to put in limits on failed attempts.
For a device that is ostensibly designed to contain a deadly weapon, the security flaws the team at [Two Six Labs] discovered are absolutely inexcusable. But there is a positive outcome, as the manufacturer has vowed to update the vulnerable safes and make a better effort in the future to more rigorously design and test their Bluetooth implementation. This is the goal of responsible disclosure, and we’re encouraged to see the manufacturer doing the right thing
Over the last decade, Intel has been including a tiny little microcontroller inside their CPUs. This microcontroller is connected to everything, and can shuttle data between your hard drive and your network adapter. It’s always on, even when the rest of your computer is off, and with the right software, you can wake it up over a network connection. Parts of this spy chip were included in the silicon at the behest of the NSA. In short, if you were designing a piece of hardware to spy on everyone using an Intel-branded computer, you would come up with something like the Intel Managment Engine.
Last week, researchers [Mark Ermolov] and [Maxim Goryachy] presented an exploit at BlackHat Europe allowing for arbitrary code execution on the Intel ME platform. This is only a local attack, one that requires physical access to a machine. The cat is out of the bag, though, and this is the exploit we’ve all been expecting. This is the exploit that forces Intel and OEMs to consider the security implications of the Intel Management Engine. What does this actually mean?
All the cool phones now are doing facial recognition. While that sounds like a big job, you can add face detection and recognition easily to your projects if you can support the OpenCV library. [LinuxHint] has a great tutorial that steps you from the basics of OpenCV to actually acquiring and identifying faces. It is aimed at Ubuntu users, but the code would apply to any OpenCV-supported platform. You can also see a less detailed tutorial to learn more about installing OpenCV on the Pi Zero from [DanishMalhotra].
Of course, any facial recognition system is going to need a camera. The nice thing about the first tutorial is that it assumes you know nothing about OpenCV, so it covers the basics on up to using the face-related libraries.
It’s fair to say that fingerprints aren’t necessarily the best idea for device authentication, after all, they’re kind of everywhere. But in some cases, such as a device that never leaves your home, fingerprints are an appealing way to speed up repetitive logins. Unfortunately, fingerprint scanners aren’t exactly ubiquitous pieces of hardware yet. We wouldn’t hold out much hope for seeing a future Raspberry Pi with a fingerprint scanner sitting on top, for example.
After buying the Thinkpad fingerprint scanner, he wanted to make sure it would be detected by his computer as a standard USB device. The connector and pinout on the scanner aren’t standard, so he had to scrape off the plastic coating of the ribbon cable and do some probing with his multimeter to figure out what went where. Luckily, once he found the ground wire, the order of the rest of the connections were unchanged from normal USB.
When connected to up his Ubuntu machine, the Thinkpad scanner came up as a “STMicroelectronics Fingerprint Reader”, and could be configured with libpam-fprintd.
With the pintout and software configuration now known, all that was left was getting it integrated into the USB hub. One of the hub’s ports was removed and filled in with hot glue, and the fingerprint scanner connected in its place. A hole was then cut in the case of the hub for the scanner to peak out of. [Nicholas] mentions his Dremel is on loan to somebody else at the moment, and says he’ll probably try to clean the case and opening up a bit when he gets it back.
Every once in a while you get lucky and a piece of cool gear lands on your bench to tear down and explore. On that measuring stick, Kristin Paget hit the jackpot when she acquired a fascinating piece of current generation cellphone infrastructure. She’s currently researching a carrier-grade LTE eNodeB and walked through some of the findings, along with security findings of two IoT products, during her talk on the Laws of IoT Security at the 2017 Hackaday Superconference.
Evolved Node B (eNodeB) is the meat and potatoes of the LTE cellular network. It connects the antenna to backhaul — this is not something you’d expect to see on the open market but Kristin managed to pick one up from a vendor at DEF CON. Hearing her walk through the process of testing the hardware is a real treat in her talk and we’ll get to that in just a minute. But first, check out our video interview with Kristin the morning after her talk. We get into the progress of her eNodeB research, and touch on the state of IoT security with advice for hardware developers moving forward.
It’s a sad commentary on the state of the world when it becomes a good practice to closely inspect the card reader on every ATM and gas pump for the presence of a skimmer. The trouble is, even physically yanking on the reader may not be enough, as more sophisticated skimmers now reside safely inside the device, sipping on the serial comms output of the reader and caching it for later pickup via Bluetooth. Devilishly clever stuff.
Luckily, there’s an app to detect these devices, and the prudent consumer might take solace when a quick scan of the area reveals no skimmers in operation. But is that enough? After all, how do you know the smartphone app is working? This skimmer scammer scanner — or is that a skimmer scanner scammer? — should help you prove you’re being as safe as possible.
The basic problem that [Ben Kolin] is trying to solve here is: how do you prove a negative? In other words, one could easily write an app with a hard-coded “This Area Certified Zebra-Free” message and market it as a “Zebra Detector,” and 99.999% of the time, it’ll give you the right results. [Ben]’s build provides the zebra, as it were, by posing as an active skimmer to convince the scanner app that a malicious Bluetooth site is nearby. It’s a quick and dirty build with a Nano and a Bluetooth module and a half-dozen lines of code. But it does the trick.
