The Vita’s Content Manager allows you to backup and restore games, saves, and system settings. These backups are encrypted (but not signed!) using a key derived in the F00D processor. While researching into F00D, xyz and Proxima stumbled upon a neat trick (proposed originally by plutoo) that lets you obtain this secret key and that has inspired me to write a set of tools to manipulate CMA backups. The upshot is that with these tools, you can modify backups for any Vita system including 3.63 and likely all future firmware. This does not mean you can run homebrew, but does enable certain tricks like disabling the PSTV whitelist or swapping X/O buttons.
Backup Keys
Because my friends who discovered this are pretty busy with other stuff at the time, I will attempt to document their findings here. The backup encryption process is documented in detail on the wiki, but the short version is that your AID (unique to a PSN account) is used to generate a key seed. This key seed is used by the F00D processor (the security coprocessor) to generate a AES256 key, which is passed directly to the hardware crypto device. The ARM (application) processor can access this crypto hardware but cannot read any keys out of it. This means that ARM can use the hardware as a black-box to encrypt backups without knowing the key. Of course you can try to brute force the key since you know both the plaintext and ciphertext thanks to the HENkaku kernel hack, but that would take \(2^{256}\) time, which is physically impossible. However, since we can hack any Vita on 3.60, it is possible to use the Vita itself as a black box for extracting and modifying backups for other devices on unhackable firmwares, but since the process requires access to a hacked Vita, it is not very useful.
One Weird Trick
But not all hope is lost! As I’ve said, the crypto hardware can be accessed by the ARM processor as well as the F00D processor. For certain other non-critical tasks, the ARM processor sets the key directly for the crypto hardware, so we know how the keys are set. There are a few dozen key slots that both processors can write to. The catch is that once the key is written, it cannot be read back.
Let’s dive deeper into how keys are passed to the crypto hardware. Note that an AES256 key is 256-bits or 32 bytes wide. Since an ARMv7 processor can only write 4 bytes at a time (okay it can do 8 bytes and also the bus width is usually optimized to be the size of a cache line, but for simplicity, we assume it can only write 4 bytes), a 32 byte key is sent with 8 write requests of 4 bytes. Now, the correct way for a crypto device to handle this is to provide a signaling mechanism to the host so it can indicate when a key slot write is about to occur. Then the host sends all parts of the key. Finally, the host indicates that the key transfer is complete and the crypto device locks the key in place and wipes it when another key transfer is requested for that slot. And for completeness, there should be measures in place to only allow one device to do a key transfer at a time in order to prevent races.
The incorrect way to do this is to naively allow anyone to set any part of the key at any time. Why? Because if we can set part of an unknown key to a known value, we can reduce the time to brute force the complete key dramatically. Let’s say we have an unknown 256-bit key that is 22 22 22 22 44 44 44 44 66 66 66 66 88 88 88 88 AA AA AA AA CC CC CC CC EE EE EE EE 11 11 11 11. Now say we can zero out the first 28 bytes of this key so the crypto engine uses 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 11 11 11 11 where we still don’t know the last 4 bytes.
But now, we pass in a chosen plaintext to the crypto device to do an AES256 operation and we get back the ciphertext. We can then brute force every possible key with the first 28 bytes to be zero. That’s \(2^{32} = 4294967296\) keys, which takes about a minute to compute with a single modern Intel core. We now know the last four bytes of the key and can repeat this procedure for the second to last four bytes and so on. This reduces the search time to \(8 \cdot 2^{32} = 2^{35}\), which is not only possible but practical as well. Running this brute force optimized on a four core Intel CPU with hardware AES instructions takes about 300 seconds to find the full 256-bit key. In fact, xyz pointed out that you can even precompute all possible “mostly-zero” keys and the storage would “only” be half a TB.
As you might have guessed, the Vita does it the incorrect way, so anyone can retrieve their backup keys.
psvimg-keyfind
I wrote a tool to do this brute force for you. It is not hyper-optimized but is portable and can find any key on a modern computer in about ten minutes. I have provided a Vita homebrew that generates the chosen ciphertexts on any HENkaku enabled Vita. These “partials”, as I call it, can be passed to psvimg-keyfind to retrieve a backup key for any PSN AID. The AID is not console unique but is tied to your PSN account. This is the hex sequence you see in your CMA backup path. The idea is that if you have a non-hackable Vita, you can easily send your AID to a friend (or stranger) who can generate the partials for you. You can then use psvimg-keyfind to find your backup key and use it to modify settings on your non-hackable Vita. Huge thanks to Proxima for the reference implementation that this is based off of.
UPDATE: You no longer need to use this tool. This site will take care of everything if you pass in your AID.
Hacking Backups
What I did is completely reverse how CMA generates and parses the backup format. I have documented extensively how these formats work. I also wrote tools to dump and repack CMA backups and all this works with backups generated from the latest firmware.
Hacking backups isn’t as fun as having a hacked system. So, don’t update from 3.60 if you have it! You cannot run unsigned code with this, so you are only limited to tricks that can be done on the registry, app.db, and other places. This includes:
- Enabling almost any games to run on the PSTV
- Swap X/O buttons for out-of-region consoles
- Run PSP homebrew with custom bubbles
- and maybe more as people make new discoveries
My hope is that other people will take my tools as building blocks for a user-friendly way of enabling some of the tricks above as currently the processes are pretty involved. This also increases the attack surface for people looking to find Vita exploits as parsing of files that users normally aren’t allowed to modify are common weak points.
Additionally, because of how Sony implemented CMA backups and that the key-erase procedure is a hardware vulnerability, this is pretty much impossible to patch in future firmware updates. Unless Sony decides to break all compatibility with backups generated on all firmware up until the current firmware. And that would mean that any backup people made up until this theoretical update comes out would be unusable. Sony is known for pulling stunts like removing Linux from PS3, but I think this is beyond even what they would do.
Release
I’ve built versions of this tool for Windows x64, Linux x64, and OSX here. Please read the usage notes.
Question: (though the answer is probably no)
As an AID is tied to a PSN account, is it insecure/risky to some degree to share an AID with an stranger, for example? (for partials.bin extracting purposes, of course)
Risky to the extent that sharing you PSN name is risky. It’s not secret but it does let Sony know you’re interested in hacking ;)
Since game save files are also encrypted by CMA, does this mean we could potentially edit game save files?
Hello Can we use this without a Henkaku enabled console. Can we decrypt save game files. Thanks
Hello Can we use this without a Henkaku enabled console. Can we decrypt save game files. Thanks
hi when Will be issued when Hacks 3.63
So each time there is a crypto call and the key is needed it’s re-written to the register that needs it? And you just run a few extra commands after it finishes to zero 28bits of it.
Can i run vpk on this hack for ps vita 3.63?
@jifre ali and anathar: ateast try to read the article before you drop half thought out sentences about 3.63 hax. He very clearly stated the current possibilities, both in technical and layman’s terms.
You got only window 64 exe file on the downloads how about windows 32 exe files?
Very good job Yifan Lu, thanks
Isn’t this the same type of flaw that was in the DSi’s AES hardware?
Yes it is.
I asked a simple question Will this eprk Without henkaku. I mean i cant run the hombrew that makes partials” for the Psn key. @Yifan lu I hope you will respond. And i am me stly interested into Save decrypt tool for pc like Bruteforce data for ps3 . Hope to get answer thanks
would it be possible to backup via CMA a game 3.61+ and decrypt it using this tool? or the eboot would still be encrypted with the 3-61+ keys?
Sorry, I got a bit confused. So, in other words, this will allow me to download and play any Vita games on my 3.63 vita? Or only if I have a PSTV? I did get that some functions, such as downloading homebrews won’t be possible. But will I at least be able to download and play the backups?
Some people need to READ First before asking questions that have already been explained in detail no backup vita games this is a tool to edit full vita system backups etc and allows some editing to registry and files. Great job Yifan Lu keep up the hard work and big respect for everything you have done for the PSV scene so far
I’ll assume the comment above was meant for me. I own a Vita for less than a week, and as I stated, I didn’t fully grasp what exactly was achieved here, nor how big it was. Perhaps you don’t know what “confused” means?
I have nearly NO knowledge on this system, but I am not an idiot. I am well aware that a hack like HENkaku for 3.63 is far from happening. All I wanted to know is if this discovery could potentially lead to something similar in the future. Maybe even a way to downgrade?
That’s what I wanted to know. Try READING it.
I agree with Ryez you should read mate and I think everything was explianed in both technical and layman’s terms as previous comments have said just read that’s all he is saying and don’t ask silly questions it would say 3.63 vita hacked if it was pal
Thanks for the ignorance. No save decrypter tool coming it seems only lame Food Useless hacks
What about offline tool for “random number” generation for using it in automatic scripts or just without internet connection? Is it planned/will be released?
plz help it show me “file too small cannot read IV “ how can i fix it
What prevents the last 4 bytes from being set to a known value as well? A race condition, I’m guessing?
I’m having severe trouble trying to get the PSTV whitelist hack to work. I’ve followed the tutorial to the letter and still I get the standard “cannot be run” message every time. So far I’ve been doing the whole thing directly through my PSTV. Does this process need to be done via my actual Vita? Or does it matter? I’m only trying to run Wipeout and Ridge Racer.
is there a psvitaimgtools for 32bit? pls i need this thanks!!!!
Please, is it possible to rip music and videos with psvimgtools? If yes, what do i need like a mod ps vita or if possible with a pc to rip it.
Please reply me. I really need your help.
Is it possible to take a CMA backup from a friend and use it on your own account? Like you can transfer a whole game to another account? If yes, please reply how to do it.
if ps4 exploit kernel firmware launch 4.05 based on python. When launch kernel exploit for psvita 3.61 to 3.65?
Hey see if this psn network code works: bd68.85nc.6fmr