PlayStation Unlocked With New Software Hack

The original PlayStation might be pushing 30 years old now, but that doesn’t mean hackers have given up on chipping away at it. A new exploit released by [Marcos Del Sol Vives] allows users to run copied games on all but the earliest hardware revisions of this classic console, and all you need to trigger it is a copy of Tony Hawk’s Pro Skater 2.

Aptly named tonyhax, this exploit uses a classic buffer overflow found in the “Create Skater” mode in Tony Hawk 2, 3, and 4. When the game sees a custom character saved on the memory card it will automatically load the name field to show it on the screen, but it turns out the developers didn’t think to check the length of the name before loading it. Thanks to this oversight, a long and carefully crafted name can be used to load an executable payload into the console’s memory.

The name contains the memory address of the payload.

That payload could be anything, such as a homebrew game, but in this case [Marcos] went all in and developed a simple tool that unlocks the console’s optical drive so it will play games burned to CD-Rs. Once the tonyhax exploit has been loaded, you simply swap the authentic Tony Hawk disc for whatever burned title you want to play. So far every game tested has worked, even those that span across multiple discs.

[Marcos] is providing not only the save files ready to load on your PlayStation memory card (either through a PC tool, or with the help of a hacked PS2), as well as the complete source code for tonyhax. This opens the door to the exploit being used to load other tools, emulators, and indie games, but as the PlayStation homebrew scene is relatively limited when compared to newer consoles, the demand might be limited.

Compared to the traditional physical modifications used to play copied games on the PlayStation, this new software approach is far more accessible. Expect to see memory cards with this exploit preinstalled hit your favorite import site in the very near future.

Continue reading “PlayStation Unlocked With New Software Hack”

Apple Kernel Code Vulnerability Affected All Devices

Another day, another vulnerability. Discovered by [Kevin Backhouse], CVE-2018-4407 is a particularly serious problem because it is present all throughout Apple’s product line, from the Macbook to the Apple Watch. The flaw is in the XNU kernel shared by all of these products.

This is a buffer overflow issue in the error handling for network packets. The kernel is expecting a fixed length of those packets but doesn’t check to prevent writing past the end of the buffer. The fact Apple’s XNU kernel powers all their products is remarkable, but issues like this are a reminder of the potential downside to that approach. Thanks to responsible disclosure, a patch was pushed out in September.

Anatomy of a Buffer Overflow

Buffer overflows aren’t new, but a reminder on what exactly is going on might be in order. In low level languages like C, the software designer is responsible for managing computer memory manually. They allocate memory, tagging a certain number of bytes for a given use. A buffer overflow is when the program writes more bytes into the memory location than are allocated, writing past the intended limit into parts of memory that are likely being used for a different purpose. In short, this overflow is written into memory that can contain other data or even executable code.

With a buffer overflow vulnerability, an attacker can write whatever code they wish to that out-of-bounds memory space, then manipulate the program to jump into that newly written code. This is referred to as arbitrary code execution. [Computerphile] has a great walk-through on buffer overflows and how they lead to code execution.

This Overflow Vulnerabilty Strikes Apple’s XNU Kernel

[Kevin] took the time to explain the issue he found in further depth. The vulnerability stems from the kernel code making an assumption about incoming packets. ICMP error messages are sent automatically in response to various network events. We’re probably most familiar with the “connection refused’ message, indicating a port closed by the firewall. These ICMP packets include the IP header of the packet that triggered the error. The XNU implementation of this process makes the assumption that the incoming packet will always have a header of the correct length, and copies that header into a buffer without first checking the length. A specially crafted packet can have a longer header, and this is the data that overflows the buffer.

Because of the role ICMP plays in communicating network status, a closed firewall isn’t enough to mitigate the attack. Even when sent to a closed port, the vulnerability can still trigger. Aside from updating to a patched OS release, the only mitigation is to run the macOS firewall in what it calls “stealth mode”. This mode doesn’t respond to pings, and more importantly, silently drops packets rather than sending ICMP error responses. This mitigation isn’t possible for watchOS and iOS devices.

The good news about the vulnerability is that a packet, malformed in this way, has little chance of being passed through a router at all. An attacker must be on the same physical network in order to send the malicious packet. The most likely attack vector, then, is the public WiFi at the local coffee shop.

Come back after the break for a demonstration of this attack in action.

Continue reading “Apple Kernel Code Vulnerability Affected All Devices”

MSP430-Based CTF Hardware Hacking Challenge

Hardware 'Flag'

Hacking conferences often feature a Capture the Flag, or CTF event. Typically, this is a software hacking challenge that involves breaking into targets which have been set up for the event, and capturing them. It’s good, legal, hacking fun.

However, some people are starting to build CTFs that involve hardware hacking as well. [Balda]’s most recent hardware hacking challenge was built for the Insomni’hack 2014 CTF. It uses an MSP430 as the target device, and users are allowed to enter commands to the device over UART via a Bus Pirate. Pull off the exploit, and the wheel rotates to display a flag.

For the first challenge, contestants had to decompile the firmware and find an obfuscated password. The second challenge was a bit more complicated. The password check function used memcpy, which made it vulnerable to a buffer overflow attack. By overwriting the program counter, it was possible to take over control of the program and make the flag turn.

The risk of memcpy reminds us of this set of posters. Only abstaining from memcpy can 100% protect you from overflows and memory disclosures!