PS4 security article follow up | Hacker News Reader

PS4 security article follow up

cturt.github.io

92 pointsFiloSottile27 comments

The reason I didn't mention encryption in my last article is because trying to defeat it would be a complete waste of time. The PS4 probably uses AES (like the PS3 and PS Vita), which is the same type of encryption used by the U.S. government.

Argh! No! Keep at the encryption!

The only exception to this is would be for implementation mistakes such as the PS3's infamous use of the constant 4 instead of what should have been a random number.

Whilst it is unlikely that Sony has made another mistake like this in the core of the PS4's encryption...

Argh! No! Look for other stupid mistakes!

He's saying trying to bruteforce the encryption keys is the wrong way to go about it, instead opting to find an exploit.

The wii hacks were all based on awful implementation of the AES methods, wasn't it?

Wasn't the first main Wii hack (trucha bug) actually a bad implementation of RSA signature verification (strncmp instead of memcmp)?

I don't know about the other ones, but I thought they were all pretty much game-local.

> Wasn't the first main Wii hack (trucha bug) actually a bad implementation of RSA signature verification (strncmp instead of memcmp)?

Yes; with that bug, you could select a signature to collide with that had an early NUL and brute-force a signature that matched up to that NUL.

> I don't know about the other ones, but I thought they were all pretty much game-local.

No, at least two other exploitable issues occurred in the system software: Bannerbomb (http://wiibrew.org/wiki/Bannerbomb) exploited the parsing of banners for data stored on an SD card (running arbitrary code when accessing the SD data management menu), and LetterBomb (http://wiibrew.org/wiki/LetterBomb) exploited the parsing of Wii Message Board "letters".

Am I missing something, or if they use AES for decryption it would be trivial to crack, since it's symmetrical? He says: >It is unlikely that developers directly deal with this encryption; I assume that the libSceSaveData module handles it all.

So decompile that lib, extract the AES vector, and you can decrypt/encrypt all the save files you want. Surely I'm missing something, though :(

Most likely PS4 uses TrustZone implementation to operate with master key. AMD CPU's used in PS4 have smaller ARM CPU inside to support TrustZone. So you won't be able to simply dump keys from library or regular memory.

How exactly you want to decrypt file with vector only?

Also you probably missing fact that browser process don't have access to the keyring; even to one that used for game saves. And there is likely several different key storages for different things just like it's was on PS3.

He is misquoting myself and/or other people who've talked about the encryption before. Sony has their own format they call SELF (secure ELF?) which works as follows: each ELF segment (not section) has a key/iv generated for it and is encrypted with AES-CTR (previously same keys were used for different segments, making it vulnerable to attacks). The keys are placed into the header and encrypted with AES-CBC. The decryption key for this is the important one, which if we obtain, allows the decryption of any* SELF. (So an mis-implemented encryption has happened before and doesn't mean 'oh the military uses AES, so anything that uses AES is unbreakable')

There's also the signatures which prevent modifying the SELFs even if we got the decryption keys. The ECDSA random-fail was what happened to the PS3. This has nothing to do with the encryption though. (There was also no "constant 4" that was just a simplification in the slide deck of the presenters. It was meant as a joke.)

But I do understand all the gross simplification CTurt made because the audience for this article is people who watch the console hacking scene, and in the console hacking scene, almost nobody knows anything about crypto. I frequently have to answer why brute forcing 128-bit AES keys is not possible. Then, inevitably, the asker will declare why we don't just try to guess then. Once I was informed that computers will become faster, so, in the future, we can brute force keys "at the speed of light." I asked them how many meters per second we can crack keys now.

* Okay, technically not any. I haven't gone into NPDRM, which is an additional layer of encryption for purchased games. Different keys are also used for different components (for example, kernel vs. user libraries).

So the whole ELF file is protected by a signature you don't have known flaws in? Because AES-CTR and/or AES-CBC (actually especially CBC) gives me the willies without some kind of MAC.

Yeah, it's unauthenticated encryption, but think about their threat model. It's not about protecting integrity (the code signing takes care of that), it's about protecting the code from prying eyes (aka DRM). And the tradeoff with speed is likely why they choose CTR. That has bitten them in the ass before with key reuse, but by PS4 they've had about 10 years of experience with the SELF format now. While I doubt the format is completely secure, it's likely easier to find a flaw in FreeBSD9 (which is why CTurt tried to say).

It is usually hard to retain confidentiality if you don't also have integrity protection. My suggestion wasn't that people would be able to exploit the lack of a MAC to override settings or code in ELF files; it was that they could use that flaw to decrypt the code.

No, because that breaks the signature.

Right, that's what I thought. Thanks!

IIRC the joke slide was https://www.xkcd.com/221

Edit for the lazy:

    int getRandomNumber()
    {
        return 4; // chosen by fair dice roll.
                  // guaranteed to be random.
    }

Alt text: RFC 1149.5 specifies 4 as the standard IEEE-vetted random number.

I will say that the code and general design behind the PS4 is dramatically superior to that of the Vita and PS3. And I suspect this is in part due to the way they moved things overseas to the west and put Cerny in charge, and probably also due to a desire to avoid past mistakes. So, I do kind of buy the claim that it is less likely they made such obvious mistakes this time.

Still, people should keep at it...

> our process is running in a FreeBSD jail, which I'm not sure is possible for a process running as root

uh... that's, like, the whole point of jails. If you get root in a jail, you get root. In the jail. You only see the jail's root fs, the jail's processes and, usually, a very limited set of devices in /dev.

> As a little side note; with the recent release of LLVM 3.7, if we specify -target x86_64-scei-ps4 to clang, we can compile code with the exact same options that Sony uses to compile official code for the PS4.

I wonder if this will undermine the opensource strategy of Sony's LLVM/SDK team. I hope not.

Reason why Sony open source their version of LLVM is to make it easier (cheaper) to maintain it. So it's commercial interest and it's unlikely to change because it's wouldn't affect how soon it's going to be hacked at that point anyway.

It's just like with previous "Linux on PS3" that was mainly done by Sony to decrease taxes as they could pay less if their system can be considered as general purpose PC and not just gaming console. On the time that feature was removed this trick just didn't make sense anymore.

Essentially this. There was a talk by Sony at the 2013 LLVM Developers' Meeting: http://llvm.org/devmtg/2013-11/#talk8

From the slides:

Initial development hampered by secrecy

- Blanket secrecy policy included compiler project

- No advice/feedback from the group consciousness

- Sitting on features and bugs and fixes applicable upstream

Clear value to working openly with upstream

- File a bug; somebody else might fix it

- Send a patch; people will review/advise

- Bigger features can get better design review

- Putting private changes upstream reduces merge pain

And:

Merging once per upstream release was a nightmare

- We stuck our fingers in everywhere

- The 3.0 merge work took three months

You know that and we know that here. I just feared someone might decide that making engineers miserable to do the constant porting might be a good security tradeoff.

Sony just lost their top LLVM open source proponent to Apple. Read into that what you will.

Who's that?

Alex Rosenberg - https://twitter.com/alexr

His bio reads "day: console OS development, night: home".

Time for wild speculation! Apple are making a game console!

(He probably just hasn't updated the bio.)

Aren't they already the manufacturers of the most popular game console, namely, the iPhone? :)

old bio.

Reply on news.ycombinator.com