How to Disassemble Vita Game Cartridges

A hacker named katsu recently released a method for dumping Vita games. As a developer, I am completely against piracy, but as a reverse engineer I can’t shy away from taking apart perfectly working devices. However, most pictures I see of Vita game carts taken apart show the game cart casing damaged beyond repair or completely destroyed. I managed to take apart a game cart and put it together with no obvious signs of damage, and I thought I would share my (simple) method here.

Photo Feb 16, 7 48 07 PM

 

If you take a look at the top right or left corner of the game cart, you can see a line of where the two halves of the plastic was glued together. Locate the upper left corner and, with a sharp knife, push the blade into the line on the corner until you have a small dent. Then, move the knife downwards and wiggle the knife until you loosen the glue for the entire left side of the cart. Then keep moving the knife down and when you hit the bottom of the cart, turn and lose about half the bottom edge of the cart. Now you can use your fingers to spread the two halves apart (but be careful not to use too much force and tear the glue from the other two edges), and you can either shake the memory chip out or use a pair of tweezers.

Photo Feb 16, 7 42 47 PM

 

If you were to follow katsu’s pinout, you need to solder to the copper pads. A trick for doing so is to first flux up the points and then melt a pea-sized blob of solder in middle of all the points. Then take your iron and spread the blob around until all the pads are soldered up. Then just make the the remaining blob is not on top of any copper and you can easily remove it.

Photo Feb 16, 8 29 57 PM

 

Then you can solder wires onto the points to your heart’s content. After you’re done with everything, you can easily put the memory chip back into the casing and there is enough glue to keep the two halves of the case together (along with the memory chip). You can then continue to play the game.

Pinout for Vita game cart. Credits to katsu.

If you were to follow the pinout, you can see that it appears to be a standard NAND pinout (not eMMC and not Memory Stick Duo). I have not tested this, but I believe this means you can use NANDWay or any other NAND dumping technique (there’s lots for PS3 and Xbox 360) provided you attach to the right pins. I suspect that the Vita communicates with the game cart through the SD protocol with an additional line for a security interface, but that is just speculation. If that were the case, having one-to-one dumps would not allow you to create clone games. Regardless, I will not be looking too much into game carts because they are so closely tied with piracy.

Dumping the Vita NAND

When we last left off, I had spent an excess of 100 hours (I’m not exaggerating since that entire time I was working, I listened to This American Life and went through over a hundred one-hour episodes) soldering and tinkering with the Vita logic board to try to dump the eMMC. I said I was going to buy a eMMC socket from taobao (the socket would have let me clamp a eMMC chip down while pins stick out, allowing the pressure to create a connection) however, I found out that all the sellers of the eMMC socket from taobao don’t ship to the USA and American retailers sell the sockets for $300 (cheapest I could find). So I took another approach.

Packet Sniffing

My first hypothesis on why it is not working is that there’s some special initialization command that the eMMC requires. For example, CMD42 of the MMC protocol allows password protection on the chip. Another possibility was that the chip resets into boot mode, which the SD card reader doesn’t understand. To clear any doubts, I connected CLK, CMD, and DAT0 to my Saleae Logic clone I got from eBay.

Vita eMMC points connected to logic analyzer.

Vita eMMC points connected to logic analyzer.

As you can see from the setup, I had the right controller board attached so I can get a power indicator light (not required, but useful). I also took the power button out of the case and attached it directly. The battery must be attached for the Vita to turn on. Everything is Scotch-taped to the table so it won’t move around. Once all that is done, I captured the Vita’s eMMC traffic on startup.

First command sent to eMMC on startup

First command sent to eMMC on startup

After reading the 200 paged specifications on eMMC, I understood the protocol and knew what I was looking at. The very first command sent to the Vita is CMD0 with argument 0×00000000 (GO_IDLE_STATE). This is significant for two reasons. First, we know that the Vita does NOT use the eMMC’s boot features. The Vita does not have its first stage bootloader on the eMMC, and boots either from (most likely) an on-chip ROM or (much less likely) some other chip (that mystery chip on the other side maybe?). Second, it means that there’s no trickery; the eMMC is placed directly into Idle mode, which is what SD cards go into when they are inserted into a computer. This also means that the first data read from the eMMC is in the user partition (not boot partition), so the second or third stage loader must be in the user partition of the eMMC. For the unfamiliar, the user partition is the “normal” data that you can see at any point while the boot partition is a special partition only exposed in boot mode (and AFAIK, not supported by any USB SD card reader). Because I don’t see the boot partition used, I never bothered to try to dump it.

Dumping

I tried a dozen times last week on two separate Vita logic boards trying to dump the NAND with no luck. Now that I’m on my third (and final) Vita, I decided to try something different. First, I did not remove the resistors sitting between the SoC and eMMC this time. This is because I wanted to capture the traffic (see above) and also because I am much better at soldering now and the tiny points doesn’t scare me anymore. Second, because of my better understanding of the MMC protocol (from the 200 page manual I read), I no longer attempted to solder DAT1-DAT3 because that takes more time and gives more chance of error due to bad connections. I only connected CLK, CMD, and DAT0. I know that on startup, the eMMC is placed automatically into 1-bit read mode and must be switched to 4-bit (DAT0-DAT3) or 8-bit (DAT0-DAT7) read mode after initialization. My hypothesis is that there must be an SD card reader that followed the specification’s recommendation and dynamically choose the bus width based on how many wires can be read correctly (I also guessed that most readers don’t do this because SD cards always have four data pins). To test this, I took a working SD card, and insulated the pins for DAT1-DAT3 with tape. I had three SD card readers and the third one worked! I know that that reader can operate in 1-bit mode, so I took it apart and connected it to the Vita (CLK, CMD, DAT0, and ground).

As you can see, more tape was used to secure the reader.

As you can see, more tape was used to secure the reader.

I plugged it into the computer and… nothing. I also see that the LED read indicator on the reader was not on and a multimeter shows that the reader was not outputting any power either. That’s weird. I then put a working SD card in and the LED light turned on. I had an idea. I took the SD card and insulated every pin except Vdd and Vss/GND (taped over every pin) and inserted the SD card into the reader. The LED light came on. I guess there’s an internal switch that gets turned on when it detects a card is inserted because it tries to draw power (I’m not hooking up Vdd/Vss to the Vita because that’s more wires and I needed a 1.8V source for the controller and it’s just a lot of mess; I’m using the Vita’s own voltage source to power the eMMC). I then turned on the Vita, and from the flashing LED read light, I knew it was successful.

LED is on and eMMC is being read

LED is on and eMMC is being read

Analyzing the NAND

Here’s what OSX has to say about the eMMC:

Product ID: 0×4082
Vendor ID: 0x1e3d (Chipsbrand Technologies (HK) Co., Limited)
Version: 1.00
Serial Number: 013244704081
Speed: Up to 480 Mb/sec
Manufacturer: ChipsBnk
Location ID: 0x1d110000 / 6
Current Available (mA): 500
Current Required (mA): 100
Capacity: 3.78 GB (3,779,067,904 bytes)
Removable Media: Yes
Detachable Drive: Yes
BSD Name: disk2
Partition Map Type: Unknown
S.M.A.R.T. status: Not Supported

I used good-old “dd” to copy the entire /dev/rdisk2 to a file. It took around one and a half hours to read (1-bit mode is very slow) the entire eMMC. I opened it up in a hex editor and as expected the NAND is completely encrypted. To verify, I ran a histogram on the dump and got the following result: 78.683% byte 0xFF and almost exactly 00.084% for every other byte. 0xFF blocks indicate free space and such an even distribution of all the other bytes means that the file system is completely encrypted. For good measure, I also ran “strings” on it and could not find any readable text. If we assume that there’s a 78.600% free space on the NAND (given 0xFF indicates free space and we have an even distribution of encrypted bytes in non-free space), that means that 808.70MB of the NAND is used. That’s a pretty hefty operating system in comparison to PSP’s 21MB flash0.

What’s Next

It wasn’t a surprise that the eMMC is completely encrypted. That’s what everyone suspected for a while. What would have been surprising is if it WASN’T encrypted, and that tiny hope was what fueled this project. We now know for a fact that modifying the NAND is not a viable way to hack the device, and it’s always good to know something for sure. For me, I learned a great deal about hardware and soldering and interfaces, so on my free time, I’ll be looking into other things like the video output, the mystery connector, the memory card, and the game cards. I’ve also sent the SoC and the two eMMC chips I removed to someone for decapping, so we’ll see how that goes once the process is done. Meanwhile, I’ll also work more with software and try some ideas I picked up from the WiiU 30C3 talk. Thanks again to everyone who contributed and helped fund this project!

Accounting

In the sprit of openness, here’s all the money I’ve received and spent in the duration of this hardware hacking project:

Collected: $110 WePay, $327.87 PayPal, and 0.1BTC

Assets

Logic Analyzer: $7.85
Broken Vita logic board: $15.95
VitaTV x 2 (another for a respected hacker): $211.82
Rework station: $80
Broken 3G Vita: $31
Shipping for Chips to be decapped: $1.86

Total: $348.48 (I estimated/asked for $380)

I said I will donate the remaining money to EFF. I exchanged the 0.1BTC to USD and am waiting for mtgox to verify my account so I can withdraw it. $70 of donations will not be given to the EFF by the request of the donor(s). I donated $25 to the EFF on January 10, 2014, 9:52 pm and will donate the 0.1BTC when mtgox verifies my account (this was before I knew that EFF takes BTC directly).

PS Vita NAND Pinout (Updated)

Since the last post on the eMMC pinout, I found the other two important test points. First is VCCQ, which is the power to the eMMC controller. It needs to be pulled at 1.8V. The other point is VCC, which is the power to the actual NAND flash. It needs to be pulled at 3.3V.

Found on the bottom of the board, above the SoC

Found on the bottom of the board, above the SoC

Found on the bottom of the board, near the multi-connector

Found on the bottom of the board, near the multi-connector

For reference, the pad of the removed eMMC on the second Vita

For reference, the pad of the removed eMMC on the second Vita

 

 

Random observations on Vita logic board

While I’m waiting for more tools to arrive, here’s some things I’ve found while playing around with the continuity test on a multimeter. There is no stunning discovery here, just bits and pieces of thoughts that may not be completely accurate.

On Video Out

The unfilled pads next to the eMMC has something to do with video. The direction of the trace goes from the SoC to the video connector. A continuity test shows that all the pads comes from the SoC and leads to some point on the video connector. Could they be pads used for testing video in factory? Looking at the VitaTV teardown from 4gamer.net shows that traces in a similar location coming out of the SoC goes through similar looking components and then into the Op-Amp and to the HDMI connector. This is a stretch, but could these traces output HDMI if connected properly? As a side note, I could not find any direct connection between anything on the video connector to either the mystery port or the multi-connector. If Sony were to ever produce a video-out cable, there needs to be a software update as there doesn’t seem to be hardware support.

On the Mystery Port and USB

The first two pins on the mystery port appear to be ground (or Vdd and Vss). The last pin could be a power source. Pins 3 and 4 goes through a component and directly into the SoC. What’s interesting is that the D+/D- USB line from the multi-connector on the bottom goes through a similar looking component and that they are very close to the pins that handle the mystery port. Looking at 4gamer.net’s VitaTV teardown again, we see that the USB input port has two lines that go through very similar paths (the various components that it goes through) as the Vita’s USB output, but the position of the traces going into the SoC on the VitaTV is the same position of the trace on the Vita coming from the mystery port. Could the mystery port be a common USB host/USB OTG port with a custom plug?

On the Mystery Chip

Also 4gamer.net speculates the SCEI chip on the top of the board has something to do with USB, but I think that’s not true because USB lines go directly into the SoC. Which means that we still don’t know what the SCEI chip does (it is the only chip on the board that has yet been identified by any source). My completely baseless hypothesis is that it’s syscon because it would be reasonable to assume that the syscon is outside of the SoC since it would decide when to power own the SoC.

On the eMMC

This may be public knowledge but the Vita’s eMMC NAND is 4GB (same as VitaTV and Vita Slim). The new Vitas do not have any additional storage chips. This also means that the 1GB internal storage on the new Vitas is just another partition or something on that NAND (no hardware changes).

PS Vita NAND Pinout

Vita NAND Pinout

As promised, here’s the pinout for the Vita’s eMMC (NAND). Don’t be fooled by the picture; the size of the resistors are TINY. Plus, if you noticed, half the traces are almost hugging the shield base (which is pretty hard to remove without disturbing the resistors). I hope I can find a better way to dump the eMMC than soldering to these points. It’s doubtful that they are exposed elsewhere as I’ve checked every unfilled pad on both sides of the board. Wish me luck…

To get an idea of where these resistors are located, check the iFixit picture for reference (black box is where they are).

To get an idea of where these resistors are located, check the iFixit picture for reference (black box is where they are).

Comparsion

To get an idea of the size of the resistors, I’ve placed a 0.7mm pencil lead next to them.

 

Removing the CPU and NAND from PSVita

Thanks again to everyone who helped fund this project! This is the first part of the long journey into hardware land. I bought a non-working Vita logic board from eBay, which arrived yesterday, packaged like a freeze-dried snack.

As delicious as it looks.

As delicious as it looks.

In order to locate the trace from the eMMC (aka the NAND), my plan was to take a broken logic board and remove the eMMC chip and use the exposed pads and trace it to a test point or something. Then take another Vita logic board (this time with the eMMC still attached) and solder wires to the test point and dump it with an SD card reader or something (as eMMC uses the same interface as SD cards). This is a complicated plan, but it’s necessary because I am not professional enough to be able to remount the eMMC (which is a tiny fine-ball-grid-array (FBGA) chip) once the trace is found.

First, you have to remove the EFI shields. The actual shields are fairly easy to remove; they are clicked into the base, and all it takes is a little pry from all sides (careful not to destroy any components near-by). However, the hard part is getting the surface mounted base off. Removing the base is recommend because it allows easier access to the eMMC, and if the test point happens to be close to the chip, it would be impossible to solder with the base in place.

Before starting, make sure the board is completely stable (since a lot of prying will be performed). I chose to tape the board to a unwanted book (which had burnt marks at the end; don’t know if the heat gun reaches the autoignition temperature, so in hindsight that was not a good idea) but having clamps would be a better solution. When using the heat gun, keep it fairly close to the board (about an inch off) and on the low setting.

To remove the base, heat up the board with a heat gun (to prevent too much expansion in one area) and direct the heat at the edge of the base near the eMMC. Wave the heat gun slowly across the entire edge while using the other hand to try to pry the base off with a pointy-metal-apparatus (scientific term; perhaps a flat head screwdriver will do). As the base peels off, move the heat gun to the next position where the base is still attached and repeat until the entire base is off. Be careful not to move the board too much or accidentally touch any of the tiny components all around because even though the board will not be used anymore, you don’t want to destroy a potential path from the eMMC.

Freed from its Faraday cage

Freed from its Faraday cage

To remove the actual eMMC chip, keep the heat gun directed at the chip for a while, then use your pointy device to try to pry it off. Use a bit of force but not extreme force and be slow with the prying. This is because even though the solder below melts fairly quickly, the chip is held in place with some kind of glue (most likely so during the manufacturing process, when surface mounting the other side of the board, the chip doesn’t fall off). If you pry too hard or too quickly, you may rip some unmelted solder off or (as in my case), actually rip off the solder mask below the glue.

Notice the burnt paper underneath. Don't try this at home.

Notice the burnt paper underneath. Don’t try this at home.

You can repeat the process for the SoC if you wish, although more care should be applied here since there are so many tiny components near the chip.

I was a bit better this time and didn't strip any solder mask.

I was a bit better this time and didn’t strip any solder mask.

Congratulations! You have destroyed the Vita beyond the possibility of recovery.

Before the destruction of a great piece of engineering

Before the destruction of a great piece of engineering

Vita with those useless chips removed

Vita with those useless chips removed

In hindsight, I should have used a hot air rework gun instead of a paint-stripping heat gun, as someone in the comments suggested last time. Then, maybe it wouldn’t look so bad. But luckily, it seems that all of the components are still attached to the board, so tracing wasn’t so hard. The bad news is that after tracing, it seems that the only exposed connection I could find from the data pins of the eMMC to the SoC was in the pile of tiny resistors next to the SoC. Tune in next time to see more amateur mistakes and destruction.

I need your help to fund Vita hardware analysis

It’s been a little more than a year since I demonstrated the first Vita running unsigned code, and it’s been dead silent since then. There is a lot of work on the PSP emulator but it’s been pretty quiet on the Vita front. In fact, there hasn’t even been any new userland exploits found (by me or others) for a year. I made a post a while ago saying that progress through hardware was one of the few options we haven’t looked extensively at, and the reason for that is because hardware hacking is an expensive endeavor. All this time I’ve been sitting and waiting for progress to be made by some unknown genius or some Chinese piracy company (sadly, for some scenes *cough* 3DS *cough*, this is the way devices get hacked since these companies have the money to do it); progress that would allow people like me to continue with the software work. Unfortunately, as of today, I have not heard of any ongoing work on Vita hardware hacking (PLEASE tell me if you are so we can collaborate). In fact, one of the simplest thing to do (hardware-wise), dumping the NAND, hasn’t been done (or publicly stated to be done) yet. Meanwhile, the PS4 has gotten its NAND dumped in a couple of weeks. Since nobody else seem to be serious about getting this device unlocked and poked at by hobbyists, I feel like it’s time for me to learn how to stop fearing and love the hardware. And I need your help.

Disclaimer

Before we talk business, I want to be as open and honest as possible. I am not a hardware hacker. I have very minimal experience with hardware (I know how to solder and I know what resistors look like), so by no means am I the best person for this job. In fact, I wish there was someone else doing this. My only qualification is the small amount of knowledge I have running userland Vita code and exploring the USB MTP protocol. It could turn out that I’m completely incompetent and not get anything useful. It could turn out that everything works out but my goals were set in the wrong direction. It could also take a very long time before any results are found (since this is a hobby after all). But, I will always be as open as possible; documenting any small discoveries I make and posting details and guides about what I’m doing. I’ll post any large transaction that takes place within the scope of this project and admit any mistakes I’ll definitely make. I won’t be able to release data I obtain from the device for legal reasons (including any actual dumps made) but I will post instruction for reproducing everything I do. I have seen other “scene” fundraisers and the problems that arises in them (mostly lack of response from the developer(s)) and will try to avoid making such mistakes. If you still believe in me, read on.

Funding the Project

I never ask for donations before I complete a project because I don’t like taking money for just expectations. I believe that the user should only donate once they try something and love it. I turned down many requests to donate money in the past and always asked for unwanted/broken hardware donations instead, however, it seems that there are more people willing to donate money than donate devices. In a perfect world, I would fund this project with my own money, but in a perfect world, I would be rich. Since this is the first time I’m looking seriously at hardware, I’m going to need to buy tools and devices to do research that would benefit the community (hopefully). I hesitantly and sincerely ask for your help. There are two main goals, the first one will let me get a hardware setup working so I have to tools to work with. The second will allow me to get hardware to test using the tools. If I end up going over the estimated amount, I will pay out of my own pocket. Any remaining money after the project is fully funded will be donated to the EFF. All your money will benefit the homebrew community. Also, all of the prices are estimated (with fees calculated in) with simple searches so if you can find a better deal or if you can get me the item directly, please contact me!

Goals

To be honest, there is no clear roadmap at this point. The first thing is to dump the NAND, try to map out signals from the CPU/SoC, and look at the data IO from the memory card, game card, and connectors. From there, I hope to get a better idea of how the hardware works and find where to go from there. I promise that I will not ask for more money once this is funded and any additional venture will come out of my own pockets.

Donate

Thanks to everyone who donated! The goal was met in less than a week. I’m currently in the process of buying the supplies and will post an update as soon as I can. If you have a broken Vita hardware, please consider donating it as more hardware to work with is better and there are other people I’m working with who can benifit also from having a logic board to work with.

Goal 1: Setup and Finding Traces ($80)

Before we can dump the NAND, we need to sacrifice a logic board to remove the NAND and trace the BGA points and find test points to solder. The board has to be sacrificed because realistically, it’s very hard to reflow such a tiny chip. In addition, the SoC would also be removed to see if there’s any interesting test points coming out of the CPU (potentially to see if there’s any JTAG or other debugging ports coming out, which is unlikely). I would need:

  • Vita Logic Board – $20

    Vita Logic BoardIt does not have to be fully working. On eBay, people are selling Vita logic boards with broken connectors for around this price (after shipping).

  • Heat Gun – $21

    Heat GunA heat gun is needed to remove the surface mounted NAND and SoC. It’s also why reattaching it almost impossible because the hot air will blow the components around.

  • Soldering Tools – $20

    Soldering ToolsI do have basic soldering tools, but throughout the project, there will be tasks that require more precision, so I would need a magnifying soldering station (cheapest is $15 on Amazon), soldering flux (about $5 on Amazon), and some small tools.

  • Digital Multimeter – $10

    MultimeterA cheap one will do. I only need it for continuity testing and reading resistor values.

  • Saleae Logic Analyzer (clone) – $10

    Saleae CloneAlthough a real Saleae logic is $150 (for 8 ports) or $300 (for 16 ports), there’s some cheap clones on eBay going for about $10. This would allow me to find signals coming out of a running Vita and, for example, verify that the test points found are indeed data driven.

Goal 2: Dumping the NAND and Testing ($250)

After getting all the tools and finding the traces, the first thing to do is to dump the NAND from a working console. This should be easy once the trace is found since the NAND is eMMC (can be dumped using an SD card reader). Next, I want to explore the signals coming into and out of the Vita (USB, multi-connector, mystery port, memory card, game card). Then depending on what I find, I’ll go from there.

  • PlayStation Vita Console – $100-150

    VitaThis would be the working console that I will test with. First, I will dump the NAND with the test points found. Then I will try to analyze the game card and memory card traffic using the logic analyzer. Although the console should be working, to save money, I may get one with a broken screen, which goes for around $100 on eBay or a used unit for $150 on CowBoom. If you own a broken Vita, and want to donate it instead of money, please contact me.

  • PlayStation VitaTV Console – $120

    VitaTVFirst a NAND dump of the VitaTV would be interesting to see if there’s any differences (assuming it’s not encrypted). Also, I would like to see how the HDMI port is connected (4gamer suspect that HDMI out comes directly from the SoC) and see if I can get a regular Vita to output HDMI (most likely not possible without software and hardware modifications). I also want to do some software tests on the VitaTV as the introduction of USB host may also introduce new bugs into the system (remember how the PS3 was hacked). It seems to be about $120 after shipping from Nippon-Yasan. If you want to donate a VitaTV directly instead of money, please contact me.

  • PlayStation Vita Cradle – $15

    vita_cradleThe Vita cradle is a good pin-out interface for the Vita multi-connector. By soldering to the cradle, it would minimize the risk of damage to the Vita directly. Exploring the multi-connector is a good way to start since there are 16 pins and only a few of them are figured out.

  • (Optional) PlayStation Vita PCH-2000 – $220

    vita_pch-2000This is purely optional and only if someone generous would like to donate the console to me directly. There’s not much I want to do here except dump the NAND and trace the microUSB signals.

Why hacking the Vita is hard (or: a history of first hacks)

It’s been about a year since I revealed the first userland Vita exploit and I still occasionally get messages asking “what happened” (not much) or “when can I play my downloaded games” (hopefully never) or “I want homebrew” (me too). While I don’t have anything new exploitwise (same problems as before: no open SDK, lack of interest in the development community, lack of time on my part), I do want to take the time and go over why it’s taking so long.

Where are the hackers?

A common (and valid) complaint I hear is that there is a lack of hackers (a word I hate) working on the Vita. The fail0verflow team has a great post about console hacking that applies just as well to the Vita. In short, there isn’t as much value to hacking a console now than before. Not too long ago, the PSP and DS were the only portable device people owned that plays games and, for many people, the only portable device they owned period. I had a DS Lite that I carried everywhere long before I had a smartphone. But then I got a smartphone (and so did everyone else). iPhones and Androids (and don’t forget Windows Phone) are the perfect platform for what we used to call homebrew. Indie developers who wanted to write a portable game no longer has to use a hacked PSP and an open SDK. Writing apps is much easier and much more profitable. Meanwhile users can play all the emulators they want on their Android phone or their jailbroken iPhone. The demand for hacked consoles shrunk dramatically with those two audiences gone. Plus with smartphones gaining a larger audience while the Vita barely sells (which by the way is a tragedy since it’s a pretty awesome console), a hacker can get a lot more attention (for for those who seek “donations”, a lot more money) spending time rooting phones that are coming out every month.

But [insert device here] was hacked very quickly, we just need more people working, right?

To some extent, that is true, but even with a large group of talented reverse engineers, I would not bet that the Vita would be hacked any time soon. To be clear here, when I say “hacked,” I refer to completely owning the device to the point that decryption keys are found and unsigned code can be run in kernel mode (or beyond). The problem is that even talented reverse engineers (who can read assembly code and find exploits) are out of luck when they don’t have the code to work with. I mentioned this circular problem before, but to restate it: you need to have access to the code before you can exploit it, and to get access to the code, you need to exploit it. But, if that’s the case, you ask, how would any device ever be hacked? That is why I believe that the first (real) hack of any device is the most important. Let’s look at some examples of “first hacks” and see why it doesn’t work with the Vita.

Insecure First Version

This is the most common situation. Let’s look at the PSP. The 1.00 firmware ran unsigned code out of the box. Someone found a way to access the filesystem, and saw that the kernel modules were unencrypted. They analyzed the kernel modules and found an exploit and owned the system. All it takes is to have an unreleased kernel exploit from one firmware version; then update to the next one; exploit it and dump the new kernel to find more exploits. Rinse and repeat.

Same with the iPhone. The first version(s) allowed you to read from the filesystem through iBoot. It was a matter of dumping the filesystem, analyzing the (unencrypted) binaries, and creating exploits. Plus, the kernel is from the same codebase as OSX, so analyzing it was not as difficult as looking at a new codebase.

The Vita however, has a fairly secure original firmware. No filesystem access (even to the memory card), proper encryption of things that do come out of the device, and very little areas of interaction in general (you have CMA and that’s pretty much it).

Similarities to other Devices

Most Android phones fall into this category. One Android root will most likely work across multiple manufactures. Plus, Android is open source, so it’s a matter of searching for an exploit. Once the device is rooted, someone has to find a way to dump the bootloader (which for many phones is just a matter of reading from a /dev/ endpoint), and analyze the bootloader for a way to root it.

The Kindle Touch (which I was the first to jailbreak), ran essentially the same software as the Kindle 3 and had a debugging console port.

The Vita has similarities to the PSP, but most of the system is different. With multitasking support, the Vita memory model is completely different from PSP and has proper abstraction of virtual memory. The Vita has NetBSD code, but the kernel is completely proprietary. No PSP exploit will work on the Vita.

Hardware Methods

This is usually the “last resort” because it takes the most skill and money to perform. This usually involves physically dumping the RAM with hardware to analyze the code. The most recently hacked console, 3DS had this done. I believe the first Wii hack was developed with a hardware RAM dumper. Many consoles had some kind of hardware analyzing done before the first hack is developed.

It would be very hard to do a hardware hack on the Vita. The system memory is on the same chip as the CPU, so you cannot try to piggyback the RAM. Plus anyone doing a hardware hack would have to have expert electrical engineering skills and access to expensive tools.

 

The story always starts with getting access to the code, then finding an exploit, and then using that exploit to get more code to find more exploits in the future. Most of the jailbreaks, roots, and hacks you see are developed with information gathered from a previous hack. I believe that Sony knows this and really made sure that their device does not suffer any of the flaws I listed. Lots of people make fun of Sony for not handing security well, but after spending countless hours on the Vita, I could honestly say that the Vita is one of the most secure devices I’ve ever seen. So far, they seem to have done everything well; using all the security features in modern computers and not trusting any code. But, as we learned countless times, nothing is completely secure.

EDIT: I’m seeing a lot of comments speculating that Vita slim or Vita TV may help hacking it. In my opinion, this is grasping at straws. There are no evidence that a minor revision of the console will magically create software or hardware holes.

libVitaMTP & OpenCMA: Vita content management on Linux (and more)

More than a year ago, I’ve analyzed how the Vita communicates with the computer. I mentioned at the end that I started a project that will be an open source implementation of the protocol that the Vita uses. This protocol is just MTP (media transfer protocol) with some additional commands that I had to figure out. MTP is used by most Windows supported media players and cameras, so I was able to use a lot of existing code from libmtp and gphoto2. After lots of on and off work, I am happy to announce the first (beta) version of libVitaMTP and OpenCMA.

What is libVitaMTP and OpenCMA?

In anticipation of allowing developers to include Vita support in their media management applications, and for allowing developers to create custom applications that use the Vita (for example, it would be possible to write an application that uses the Vita as a general purpose storage device), I’ve placed all the backend code into libVitaMTP. This includes connecting of the Vita through libusb-1.0, processing various XML data sent from the device with libxml2, and supports an interface that allows the developer to send the various custom MTP commands to the device.

OpenCMA is the first user-level software that uses libVitaMTP. It serves two purposes. First, it’s a stripped down, open source implementation of CMA, that allows the user to send and receive games, backups, and media to and from the Vita. It is stripped down because Sony’s official CMA supports reading the metadata from media files, and I chose not to include this feature because it would complicate things.

More information can be found on the Github page.

Testing

If you are a developer and wish to include libVitaMTP in your projects, please give feedback on any bugs or difficulties/bad documentation/inconsistant documentation.

If you are a user and wish to test OpenCMA, I’ve provided some Debian packages (created and tested on Ubuntu 12.04) for you to try. After installing, just invoke “opencma -h” in the terminal to see how to use it.

A sample run of OpenCMA could be

$ opencma -u /path/to/dir/containing/updatelist -p /path/to/photos -v /path/to/videos -m /path/to/music -a /path/to/apps -l 4

the -l 4 means to show more logging information. This is very important for filing bug reports. If you encounter a crash or bug, please make sure to include the output of the OpenCMA session with -l 4. Note that more logging means slower transfers.

Please be careful not to pass in large directories because OpenCMA tries to create an index of all files (recursively) for each path.

Please submit all bug reports and feature requests to the Github issues page. It would make things easier if you include the -l 4 output.

Downloads

As always, the most up to date packages will be uploaded to the project page.

PlayStation Vita: the progress and the plan

Sorry that it’s been a while since I’ve said anything about the Vita. I was caught by surprise the last time of all the media attention from just a simple call for help. While I still don’t want to say too much right now, I do want to answer some common questions I’ve been getting and also go over what needs to be done.

If this is news to you, please read this interview I’ve done a while ago about it.

Did you hack the Vita? That’s a very vague question. What I have done, is run native code on the Vita with the same permissions as the game being exploited. This means I can load homebrews written and optimized for the Vita’s CPU and take full advantage of the CPU speed and RAM (unlike the PSP emulator or PSM, both impose artificial limits on resources and system functions). What has NOT been done (yet) is unlocking the system completely for tasks like USB interfacing, custom themes/system mods/plugins, and (fortunately) pirating games.

What’s UVLoader and how far along is it? The last I’ve spoken, I was beginning work on UVL and asked for any help I could get. Even though, I did not really get help, I did find people who were interested in what I was doing and we exchanged information. I also want to brag that I finished the main functionalities of UVL in a couple of weeks, and it has been “done” for about three months now. (Quotes around “done” because I decided to not worry about some features yet). That means, I can basically load most (most being the few that I manually built without an open sdk) compiled homebrews. You can run your standard hello worlds and spinning cubes and such, but in theory, it should load any homebrew built.

When’s the release? What’s taking so long? So as I’ve said, the loader was done three months ago. I have a couple of reasons for not releasing yet. The main reason is that currently, there is no open SDK for compiling and linking Vita homebrew like pspsdk did for the PSP. That means, even with the loader, it would be useless for users because there are no homebrew games, emulators, etc to run, and it would be useless for developers because they can’t build homebrews either. So what’s the progress on the open sdk? Zero, as I’m typing this right now. I have an idea of what it should look like and I spoke to a couple of people who are interested in helping, but so far, no code is written. Why is that? Because for me, I am very busy with lots of other unrelated things, and unfortunately, only me and a handful of other people know enough about the device and the executable format and etc to make the open sdk and none of us have the time currently.

The second reason is that having a Vita exploit at this stage (when it is really hard to find exploits) is very rare if not a once in a lifetime thing. Me and others I’ve talked to agree that right now it’s more important to use this exploit to gather more information about the system in order to find more exploits and such than it is to run homebrews right now. We have PSM for homebrew games and PSP emulator for homebrew emulators, so there really isn’t a huge demand for native PSVita homebrews yet. As I’ll expand on below, we’ve only scratched the surface of Vita hacking and there’s so much more to see.

Are you looking for testers/can I test UVLoader? There’s no need to “test” UVLoader right now because, as I’ve stated before, there isn’t any compiled homebrew and nothing to compile them anyways. Yes, UVL works with some of the custom still I’ve built manually, but it is unwise to write complex stuff without a working SDK.

Can help? Depends who you are. If you’re an established reverse engineer, you know how to contact me. If you just want to “beta test,” read above. If you know any other way of helping me, don’t ask, just do it™, since UVL is open source. Even though I don’t accept monetary donations before I release anything, if you have access to broken Vitas, memory cards, games, etc, or any unused hardware reversing tools like logic analyzers; anything you wouldn’t mind parting with, one of the things me and others involved don’t have access to is funds for materials to test some of the more… risky ideas and if you could help with that respect, just use the contact link at the top of the page to get in touch with me.

What needs to be done to “hack” the Vita? Again, that term is very vague, but I know what you mean. This is the perfect time to describe (as far as I know) the Vita’s security structure and what needs to be done at each level.

PSP emulator

I’ll start with the PSP emulator just because that is what’s “hacked” right now. How much control do you have of the Vita when you use vHBL? Almost none. On the PSP itself, games are “sandboxed” (meaning some other process tells it what functions of the PSP can be used by the current game, main thing being that one game can’t load another game). Because the Vita emulates the PSP, it also emulates this structure.

PSP kernel

One level up, we have “kernel exploits” on the PSP, which means that we are no longer limited to what functions of the PSP we can use. Any PSP function that is emulated by the Vita can be used, that’s why you see ISO loading as the main thing. However, all of this, the PSP emulator, sits in the Vita game sandbox. This sandbox is just like the PSP one, in that another Vita process tells the game (in this case, the PSP emulator running some PSP game) what Vita functions can be used in a similar fashion. For example, if a game doesn’t explicitly declare that it’s going to use the camera or bluetooth (and Sony approves), any code that tries to use these functions will crash.

Vita userland

This is where UVLoader works; we exploited some game to run code inside it’s sandbox, meaning that if that game doesn’t have camera functions, no UVLoader Vita homebrew can use the camera either. This also means, of course, we can’t load pirated Vita games and so on. A fun fact here is that, in theory, if someone finds an exploit in Kermit, the system inside the PSP emulator that talks to the Vita through a virtual serial port, they can run UVLoader in the process hosting the emulator (one level higher than a PSP kernel exploit), meaning they may be able to modify the emulator to have more RAM or faster CPU or etc. Another advantage of running UVLoader here is that because the PSP emulator has access to more Vita hardware than most games (bluetooth, camera, etc), homebrews could have more access too.

However, it’s easier said than done. It’s hard to appreciate  how hard it is to get a Vita userland exploit. Let’s work backwards: we want to somehow run native ARM code, how? Well, the classic route is some stack smash. But wait, modern ARM processors have XN (eXecute Never), which is a feature that only allow code in memory to run at specific locations (these locations are determined by the kernel and are read only). Ok, we have some other choices here: heap overflows, ROP (google if you don’t know), and so on (assuming you even know you got a working exploit, which in itself is hard to know without additional information; most “crashes” are useless), but all of these choices require that you know enough about the system to create a payload fitted for the system. That means, you need either a memory sniffer or somehow dump the memory. Well, let’s rule out hardware memory sniffing since the Vita has the RAM on the same system-on-a-chip as the CPU. How do we dump the memory then? Usually, you need to run some code to dump the memory or do some kind of oracle attack on crashes or error messages or something. Option one only works if we hacked the system before, and the second one, AFAIK, won’t work because the Vita doesn’t give any information when it crashes. So how did I get the first userland exploit? I’ll leave that as an exercise to the reader…

Vita kernel (lv2?)

Vita userland is the most we have access right now and PSP kernel mode is the most that is public. What comes after? Remember all information at this point could be wrong and is based off of the little evidence I have currently. We are in the Vita sandbox right now, which means we can run homebrew, but we can’t use functions that the game doesn’t use (camera, bluetooth, USB, etc). We also can’t modify the system (run Linux, change the theme, add plugins, etc). For those to work, we need to go one level up: the Vita kernel, which might be called lv2. Even with complete userland access, we can’t even poke at the kernel. The kernel acts like a black box, providing functions to the system through syscalls. You pass input into these syscalls and it returns some output, without revealing how the output is created. The kernel’s memory is separate from userland obviously, and even guessing what syscalls do (there’s no names in the memory, only numbers) is a challenge. In order to hack the kernel, we have a problem that is very much like the one I’ve stated above about getting Vita userland, except with even more limitations. Again, there’s the circular problem of needing a kernel RAM dump to inspect for exploits and requiring a kernel exploit to dump the RAM. Now, there’s even less “places” to inspect (visually and programmatically). In order of likelihood, one of the following needs to happen before there’s even a CHANCE of a kernel exploit: 1) Sony does something stupid like the PS3 keys leak, 2) we get REALLY lucky and basically stumble upon an exploit by just testing one of the several hundreds of syscalls with one of an infinite amount of different inputs, 3) some information leaks out from Sony HQ.

It’s still unknown how much control we would have if kernel mode is compromised, but me and some others think that we MAY at least be able to do something like a homebrew enabler (HEN) that patches signature checks temporarily until reboot, allowing for homebrews with no sandbox limitations (access to camera, BT, etc) and POSSIBILITY system plugins and themes. It is very unlikely at any keys will be found at this point or being able to create or run a CFW.

Hypervisor? (lv1?)

At this point, it is purely a thought experiment, as we literally have no information beyond what we THINK the kernel does. It is highly possible that there is a hypervisor that makes sure everything running is signed and the kernel isn’t acting up and such. Getting to this would be EVEN HARDER than getting kernel, which I already think is impossible. Even at kernel, it seems to be over my skill limit, but this would definitely be above me, and someone with real skills would have to attack this. I’m thinking at least, decaps will have to be attempted here. If somehow this gets hacked, we may be able to run CFWs, but like the PS3 before the lv0, newer firmwares would not be able to be CFW’d until…

Bootloader? (lv0?)

Again, only conjecture at this point, but this is the holy grail, the final boss. Once this is compromised, the Vita would be “hacked” in every sense of the word. We may never get here (and by never, I mean maybe 5-10 years, but I would most likely not be working on the Vita at this point). Here’s is where I think the keys are stored. With this compromised, CFW of any past, present, or future firmwares could be created, and anything would be possible.

Summary

I guess to summarize, the reason there’s no release in the foreseeable future isn’t just because I don’t have time to make an sdk so there won’t be homebrews to use even if UVL is released. Even if the SDK does get done, at this point, it would be more attractive to use the control we currently have, double down, and try to get more control. If the exploit is revealed prematurely, getting the game pulled, and the firmware patched, sure we may get a fast N64 emulator in a couple of months when somebody has the chance to write it (and at that point, most people might be enticed to upgrade anyways for new firmware features and PSN access), but we will have to start at square one (read above about finding userland exploits) before having another chance at exploring the full potential of the system. Deep down, I am a researcher, and would have more interest in reversing the system than I would at making a release for users just so I could be the “first”. Like all gambles, I may end up with nothing, but that’s a risk I’m willing to take.

Page 1 of 212