Wow. [Dmitry Grinberg] just broke into the SROM on Cypress’ PSoC 4 chips. The supervisory read-only memory (SROM) in question is a region of proprietary code that runs when the chip starts up, and in privileged mode. It’s exactly the kind of black box that’s a little bit creepy and a horribly useful target for hackers if the black box can be broken open. What’s inside? In the manual it says “The user has no access to read or modify the SROM code.” Nobody outside of Cypress knows. Until now.
This matters because the PSoC 4000 chips are among the cheapest ARM Cortex-M0 parts out there. Consequently they’re inside countless consumer devices. Among [Dmitry]’s other tricks, he’s figured out how to write into the SROM, which opens the door for creating an undetectable rootkit on the chip that runs out of each reset. That’s the scary part.
The cool parts are scattered throughout [Dmitry]’s long and detailed writeup. He also found that the chips that have 8 K of flash actually have 16 K, and access to the rest of the memory is enabled by setting a single bit. This works because flash is written using routines that live in SROM, rather than the usual hardware-level write-to-register-and-wait procedure that we’re accustomed to with other micros. Of course, because it’s all done in software, you can brick the flash too by writing the wrong checksums. [Dmitry] did that twice. Good thing the chips are inexpensive.
The nitty-gritty on the ROP (return oriented programming) tricks that [Dmitry] had to pull, and a good look into the design of the system itself, are all up on [Dmitry]’s blog. We can’t wait to see what other buried treasure he’s going to find as he continues to play around with these chips. And in case you’re wondering what type of mad genius it takes to pull this off, consider that [Dmitry] runs Linux on AVRs, fools nRF24 chips into transmitting Bluetooth LE beacons, and re-writes his own airplane’s GPS.
[Main image is a PSoC4200 dev kit, and [Dmitry] has only been working with the 4000 and 4100 series. Just so you know.]
At the 2010 Chaos Communication Congress, fail0verflow (that’s a zero, not the letter O) demonstrated their jailbreak of the PS3. At the 2013 CCC, fail0verflow demonstrated console hacking on the Wii U. In the last two years, this has led to an active homebrew scene on the Wii U, and the world is a better place. A few weeks ago, fail0verflow teased something concerning the Playstation 4. While this year’s announcement is just a demonstration of running Linux on the PS4, fail0verflow can again claim their title as the best console hackers on the planet.
Despite being able to run Linux, there are still a few things the PS4 can’t do yet. The current hack does not have 3D acceleration enabled; you won’t be playing video games under Linux with a PS4 any time soon. USB doesn’t work yet, and that means the HDD on the PS4 doesn’t work either. That said, everything to turn the PS4 into a basic computer running Linux – serial port, framebuffer, HDMI encoder, Ethernet, WiFi, Bluetooth, and the PS4 blinkenlights – is working.
Although the five-minute lightning talk didn’t go into much detail, there is enough information on their slides to show what a monumental task this was. fail0verflow changed 7443 lines in the kernel, and discovered the engineers responsible for the southbridge in the PS4 were ‘smoking some real good stuff’.
This is only fail0verflow’s announcement that Linux on the PS4 works, and the patches and bootstrap code are ‘coming soon’. Once this information is released, you’ll need to ‘Bring Your Own Exploit™’ to actually install Linux.
Video of the demo below.
Continue reading “32C3: Running Linux On The PS4”
There are a lot of malware programs in the wild today, but luckily we have methods of detecting and removing them. Antivirus is an old standby, and if that fails you can always just reformat the hard drive and wipe it clean. That is unless the malware installs itself in your hard drive firmware. [MalwareTech] has written his own frightening proof of concept malware that does exactly this.
The core firmware rootkit needs to be very small in order to fit in the limited memory space on the hard drive’s memory chips. It’s only a few KB in size, but that doesn’t stop it from packing a punch. The rootkit can intercept any IO to and from the disk or the disk’s firmware. It uses this to its advantage by modifying data being sent back to the host computer. When the computer requests data from a sector on the disk, that data is first loaded into the disk’s cache. The firmware can modify the data sitting in the cache before notifying the host computer that the data is ready. This allows the firmware to trick the host system into executing arbitrary code.
[MalwareTech] uses this ability to load his own custom Windows XP bootkit called TinyXPB. All of this software is small enough to fit on the hard drive’s firmware. This means that traditional antivirus cannot detect its presence. If the owner of the system does get suspicious and completely reformats the hard drive, the malware will remain unharmed. The owner cannot even re-flash the firmware using traditional methods since the rootkit can detect this and save itself. The only way to properly re-flash the firmware would be to use an SPI programmer, which would be too technical for most users.
There are many more features and details to this project. If you are interested in malware, the PDF presentation is certainly worth a read. It goes much more in-depth into how the malware actually works and includes more details about how [MalwareTech] was able to actually reverse engineer the original firmware. If you’re worried about this malicious firmware getting out into the wild, [MalwareTech] assures us that he does not intend to release the actual code to the public.
While Black Hat and Defcon have both concluded, we’re going to post a few more talks that we think deserve attention. [Sherri Sparks] and [Shawn Embleton] from Clear Hat presented Deeper Door, exploiting the NIC chipset. Windows machines use NDIS, the Network Driver Interface Specification, to communicate between the OS and the actual NIC. NDIS is an API that lets programmers talk to network hardware in a general fashion. Most firewalls and intrusion detection systems monitor packets at the NDIS level. The team took a novel approach to bypassing machine security by hooking directly to the network card, below the NDIS level.
The team targeted the Intel 8255x chipset because of its open documentation and availability of compatible cards like the Intel PRO/100B. They found that sending data was very easy: Write a UDP packet to a specific memory address, check to make sure the card is idle, and then tell it to send. The receive side was slightly more difficult, because you have to intercept all inbound traffic and filter out the replies you want from the legitimate packets. Even though they were writing low level chipset specific code, they said it was much easier to implement than writing an NDIS driver. While a certainly a clever way to implement a covert channel, it will only bypass an IDS or firewall on the same host and not one on the network.
[photo: Big Fat Rat]