What if a secure device had an attacker-viewable crashdump format?
What if that same device allowed putting arbitrary memory into the crashdump?
Amazingly, the ps4 tempted fate by supporting both of these features!
Let’s see how that turned out…
Plenty of time has passed since we first demonstrated Linux running on the PS4.
Now we will step back a bit and explain how we managed to jump from the browser process into the kernel such that ps4-kexec et al. are usable.
Another year, another console hacking talk! This talk picks off where our lighting talk last year left off, and goes into detail of how we ported Linux to the PS4.
If you haven’t watched it, take a look before reading the rest of this post:
We are deeply saddened by the news that our member, colleague, and friend Ben “bushing” Byer passed away of natural causes on Monday, February 8th.
Many of you knew him as one of the public faces of our group, fail0verflow, and before that, Team Twiizers and the iPhone Dev Team.
Outspoken but never confrontational, he was proof that even in the competitive and oftentimes aggressive hacking scene, there is a place for both a sharp mind and a kind heart.
To us he was, of course, much more. He brought us together, as a group and in spirit. Without him, we as a team would not exist. He was a mentor to many, and an inspiration to us all.
Yet above anything, he was our friend. He will be dearly missed.
Our thoughts go out to his wife and family.
Keep hacking. It’s what bushing would have wanted.
If you’re here, you’ve probably heard about our lightning talk at the 32nd Chaos Communication Congress demoing Linux on a PS4. This post continues where the talk left off and clarifies a few aspects of what we’re doing, and why.
If you haven’t yet, please watch the talk before reading the rest of this post:
pong pwn (30 pts) ------------------- To play it, connect to our server via: socat -,raw,echo=0 TCP:126.96.36.199:2001 Have fun!
safelock Signals (20 pts) ------------------- This is the circuit of a safe lock. Get the key to open it! http://188.8.131.52/safelock/ It's neither about webtronics nor ngspice. Disregard bugs in both. If you want to write spice code directly, use something like this cat test.cir | curl --data-binary '@-' http://184.108.40.206/safelock/contest_spice/spice.cgi
(This is a guest post by tmbinc. You can read the original post here on debugmo.de.)
That’s probably the first word you think of when hearing the word “OpenVizsla”. It all started good in - WTF - 2010 when bushing and pytey thought it would be a good idea to build an open-source USB sniffer.
Scam. That’s what people called the project after unable to provide a working prototype after one year, two years, three years. But let me assure you: this project is not a scam. We just failed. A lot.
I don’t want to swirl up the past - that was done before, but rather present the current state of affairs. TL;DR: It looks good, and OV3 actually a working USB analyzer these days, and it shipped to (almost) all of the original backers. Once all of them shipped, more of them will be sold to the public.
Let’s start with a hardware overview of ov3, the third attempt to get it right. By the way, you can find everything in the openvizsla github repository. Just in case you want to build your own USB analyzer.
reeekeeeeee Web (200 pts) ------------- The Plague seems obsessed with internet memes, though we don't yet know why. Perhaps there is a clue to what he's up to on this server (epilepsy warning). If only you could break in.... Here is some of the source.
rsa Forensics (450 pts) -------------- Our archaeologists recovered a dusty and corrupted old hard drive used by The Plague in his trips into the past. It contains a private key, but this has long since been lost to bitrot. Can you recover the full key from the little information we have recovered?
wheeeee Crypto (375 pts) ---------------- Although it seems like The Plague's messaging service is secure, there are bound to be bugs in any 20th century crypto system. We've recovered a version of the block cipher The Plague implemented. Use their online encryptor tool, at 220.127.116.11:8193, to break the cipher and figure out Plague's secret plans. NOTE: When the service sends you a hex-encoded string, respond with a hex-encoded string.
bbos Forensics (350 pts) ------------------- You have traveled back in time, but look, hunting The Plague is tough. You're really just going back to relax for a while without having to worry about all that nonsense. As you walk in the park you stumble across someone's BlackBerry. Wow, people still use BlackBerry phones (time travel gets so confusing)? You figure you should return it to the owner, but you have a hard time getting inside. Figure out what's on the phone, and maybe we'll be able to return it to the rightful owner.
BlackBerry was this fancy pager thing, right?
This challenge was about breaking a custom public key encryption system.
graphs Cryptography (200 pts) -------------- In this era, block ciphers hadn't even been invented. The Plague created this system based on problems he knew to be NP hard, but there must be something you can do to decode his messages.
We were given a python implementation of the system, the Plague’s public key and an encrypted message. The implementation includes encryption, decryption (given a private key) and key generation.
Although it seems like The Plague's projects are open source, it's not quite so simple to figure out what the source code does. We believe this project is supposed to print out secret information, but the KEY variable in the Makefile has been lost. Find the key, build the project, get us the information.
Oh noes, the key is gone!
The Plague is running a betting service to build up funds for his massive empire. Can you figure out a way to beat the house? The service is running at 18.104.22.168:4321.
zfs Forensics (400 pts) ------------------- The Plague is using state of the art systems for storing his data. Our operatives managed to steal a drive from one of his servers, but it seems like our haste may have led to some uber-corruption. Can you get the data off the drive to track down The Plague?
Sure we can. But where do we start?
bronies Web (800 pts) ------------------- We are trying to break into eXtreme Secure Solutions, where The Plague works as a system adminstrator. We have found that their internal company login page is at http://portal.essolutions.largestctf.com/. Recon has also revealed that The Plague likes to browse this site during work hours: http://22.214.171.124/ using the username ponyboy2004. Remember, our main target is to break into the company portal, *not* the pony site.
This challenge was about extracting a (not very well) hidden message out of an image file:
doge_stege Forensics (100 pts) -------------- You were startled to learn the The Plague has been behind many of the most popular internet memes. We believe he hides information in these funny pictures with steganography in order to broadcast his messages through time without detection. Find the hidden message, stop the signal.
Obvious Stego is Obvious
The first thing to do with every file you get from a CTF challenge is to run the
file command on it:
% file doge_stege.png doge_stege.png: PNG image data, 680 x 510, 8-bit colormap, non-interlaced
This challenge was about establishing a connection to a hidden tor service which is rather picky in accepting connections. We were given the following description:
rendezvous Misc (250 pts) -------------- The Plague has a friend called Alice who has some secrets on a tor service (http://6c4dm56aer6xn2h2.onion/). We think if we can talk to her, we can learn some useful things about The Plague. Unfortunately she will only rendezvous with "chandler" when he brings a cookie with "beef" baked into it. Can you help us find her secret?
The first thing we did was of course trying to connect to the service.
Whether using a tor to web gateway as for example onion.to or a local tor instance, the result was the same: no connection could be established.
curl -v –socks5-hostname localhost:9050 http://6c4dm56aer6xn2h2.onion/ showed that curl didn’t even send the request, confirming that the problem is at the tor layer and not at the HTTP layer.
Thus getting a tor connection to the hidden service is actually part of the challenge.
ezhp Pwnables (200 pts) ------------------- Luckily when you travel back in time, you still get to use all your knowledge from the present. With that knowledge in hand, breaking into this service (at 126.96.36.199:9174) owned by The Plague shouldn't be hard at all.
To set the picture, let’s identify the binary
izsh@box:~$ file ezhp ezhp: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.24, BuildID[sha1]=0x5fa5bd76db306497b549ea3b0466cd9e9afa2705, stripped izsh@box:~$ readelf -l ezhp | grep STACK GNU_STACK 0x000000 0x00000000 0x00000000 0x00000 0x00000 RWE 0x4
tiffany Reversing (300 pts) ------------------- We want to get access to a server used by The Plague. Maybe if you can find out what key is accepted by this binary you can find out where or when The Plague is...
Yay, a Linux x86_64 executable! Let’s run it and see what happens, because what could possibly go wrong when running a random binary off the internet?
$ ./tiffany This may take a while... ....... Please enter a string: TEST .... Sorry, wrong.
Well, that took 3 seconds to initialize and 5 seconds per input string character. Sure seems to be doing a lot of stuff. Let’s load it into IDA to get a general idea.
paris Reversing (300 pts) ------------------- This binary was found on some of our Windows machines. It's got The Plague written all over it. What secrets are contained inside?
We are greeted by a Windows executable. Since I hate Windows and I can’t be arsed to pull up a Windows VM and debugger, I decided to solve this one statically. Time to load it into IDA.
__nightmares__ Pwning (375 pts) ------------------- The Plague is building an army of evil hackers, and they are starting off by teaching them python with this simple service. Maybe if you could get full access to this system, at 188.8.131.52:9990, you would be able to find out more about The Plague's evil plans.
This server simply evaluates any Python expression provided - with an attempt at sandboxing it.
This challenge is part of the misc category:
freya Misc (200 pts) ------------------- We've traveled back far, but this protocol looks familiar... Our reconnaissance team did a great job, they got us a data capture from the currently running systems and a private key from the server (shell.woo.pctf which resolves to 184.108.40.206). Take a look at the traffic our reconnaissance team picked up, and see if you can get access to The Plague's server, at 220.127.116.11.
with the following four files:
The task is pretty simple - somehow get access to shell.woo.pctf, probably by using ssh.
curlcore Forensics (250 pts) ------------------- We managed to grab a memory dump off of The Plague's computer while he was making a secure download. We think he may have been looking for new places to hide the Prime Factorizer. Can you figure out what messages were sent through his computer?
For this challenge, you get 3 files:
- capture (a network capture)
- corefile (a memory dump)
- coremaps (the process’s memory map)
and the shell script which helped generating those files
#/bin/sh sudo rm /tmp/capture 2>/dev/null sudo dumpcap -i eth0 -w /tmp/capture & DUMPCAPPID=$! sleep 1 OUTPUT="`/usr/bin/env -i /bin/dash -c 'ulimit -c unlimited; curl -k https://curlcore.local.plaidctf.com/flag.html & PID=$!; sleep 5; printf "generate-core-file\ninfo proc mappings\ndetach\n" | sudo gdb attach $PID; wait'`" sleep 1 sudo kill -INT $DUMPCAPPID wait sudo chown `whoami` /tmp/capture echo "$OUTPUT" sudo mv "`echo "$OUTPUT" | grep -o 'Saved corefile .*$' | cut -c 16-`" /tmp/corefile sudo chown `whoami` /tmp/corefile echo "$OUTPUT" | awk '/Mapped address spaces/,/(gdb)/' | grep -v '(gdb)' > /tmp/coremaps rm /tmp/curlcore.tgz 2>/dev/null tar czf /tmp/curlcore.tgz `grep -o ' /.*$' /tmp/coremaps | sort -us | tr '\n' ' '` /tmp/corefile /tmp/coremaps /tmp/capture "$0"
Since we have a network capture of the https download, we need to find a way to decrypt the SSL communication…
As you’re likely aware, our team gave a lecture at the 30th Chaos Communication Congress on hacking the Wii U. This blog post is a follow-up to the talk and contains clarifications, corrections, and material that we couldn’t fit in the one-hour time slot.
If you haven’t yet, please watch the talk before reading the rest of this post:
It’s been almost 7 years since the Wii was released. Back in 2006, not many owned a living room PC. PCs were still relatively bulky, and the Chinese offerings were limited to horrible media players. At the time, the prospect of having a game console double as a HTPC and being able to browse the web, play games for older platforms with emulation, and run homebrew games on a device which you already had in the living room was rather appealing.
Fast forward to today. Mobile SoCs have made huge advances - you can get a quad-core chip in a phone these days - and have made the jump to the living room. Spend $25 and you can get a Raspberry Pi, which is about on par with the Wii at 1⁄10 of the launch price and 1/7th of the power consumption (with HD video). Spend $100 and you can get an Ouya, which beats the Wii U’s CPU and doesn’t have too shabby graphics at one third the cost. These mobile-derived devices aren’t quite a replacement for game consoles yet, but they’re catching up fast. They’re cheap enough that they’re almost disposable. The software ecosystem is much larger and wider than any console has ever had. More importantly, they’re open, and the development tools and environments are way better for open development than any game console ever was.
Let’s take a break from Wii U hacking to take a quick look at Mega’s security.
In case you’ve been living under a rock the past few days, Kim Dotcom (of Megaupload infamy) has launched his new cloud storage site, Mega. Mega has an impressive sales pitch, promising secure cloud storage where only the user has the key to decrypt his or her files, and the encryption and decryption happens securely in the browser.
It has come to our attention that nobody seems to have any idea what the past 4 posts have been about. In an attempt to clarify things, we have prepared a handy diagram:
Brought to you by 30 hackers and 3 tables:
We finally have a YouTube channel and we thought we’d kick things off with a little teaser:
Keep in mind that this is purely a demonstration at this stage. Depending on how things progress and what direction development takes, we may or may not release something like this in this form. Please don’t ask for release dates. We’d rather spend time investigating the new system than putting together a release that may or may not end up being the Right Way to do things in the future ;).
It is quite an interesting vulnerability on many aspects. Among them, and thanks to its hardware basis, it impacts many operating systems. For instance, as long as they run on a Intel processor in long mode (obviously), FreeBSD, NetBSD, Solaris, Xen and Microsoft Windows have been reported to be vulnerable. This therefore gives us quite an incentive to develop an exploit ;).
If you haven’t yet read Xen’s blog post The Intel SYSRET privilege escalation please do because we won’t go again into too much details about the vulnerability itself.
Without further delay, let’s dig right into the FreeBSD exploitation!
I’ve always liked the idea of building complex logic systems out of a simple primitive that is just powerful enough to construct all logic - particularly in videogames. For example, in LittleBigPlanet, you can build a Tic-Tac-Toe AI out of physical elements like pistons and magnetic switches. In Minecraft, you can build an ALU out of a primitive construction element that behaves, essentially, as a NOT gate. And, if games aren’t your thing, you can build CMOS logic out of UNIX pipes with a simple “mosfet” program.
Just a few days ago, Notch, the creator of Minecraft, revealed a new game, 0x10c. Instead of giving players a simple logic element, it will include a full-blown 16-bit CPU that can be programmed. I find this intriguing, because it allows for much more complex development yet it doesn’t step right into the boring world of “let’s just throw in a lua scripting engine and call it a day”. You’re still limited by emulation speed and by memory constraints.
One of the things we’ve been playing with recently is the AT&T Microcell. This device is intended to provide a cheap way for AT&T to increase their network coverage at the expense of their customers. The device is essentially a small cell-tower in a box, which shuttles your calls and data back to the AT&T mothership over your home broadband connection.
This kind of device is becoming more and more popular with the various mobile providers. They are commonly known as residential femtocells.
We’re curious. We love gadgets. We love to take gadgets apart and see what makes them tick. So naturally, we’ve taken a look at a number of different femtocells.
We finally got around to looking at this AT&T variant this week, and discovered that it is totally full of fail.
On Friday, the 13th of January 2012, the ACM Queue published an article by Poul-Henning Kamp entitled ‘The CRYPO-CS-SETI challenge: An Un-programmng challenge’. In this post, Kamp challenged his readers to attempt to disassemble a program for an unknown computer. In what we assume was an attempt at increased dramatic impact, he described a scenario where part of an extra-terrestrial computer is discovered, with only a memory storage device intact.
We first heard of the challenge on the morning of Saturday the 14th, and thought it sounded like fun. Within five days we had completely disassembled the program. In addition, we had accidentally identified the oh-so-terrestrial source of the code.
This is the first in a series of posts in which we’ll describe how we went about reverse-engineering the machine architecture using nothing but the binary blob and our wits.