Opening Up CARDBOARD: Crafting an American New 3DS (non-XL)

Last time, I analyzed now update checks worked on the 3DS. That was a straightforward process. CARDBOARD (known colloquially as “System Transfer”) is a bundle of complexity with no less than three separate servers communicating with each other as well as the device. A custom proprietary protocol is used for 3DS to 3DS communication. Finally, we have multiple unique identifiers the console uses to identify itself with Nintendo (serial, certificates, console id, account id, etc). I can’t imagine this will be comprehensive, but I hope that whoever is reading can gain new insight on the complexity of the 3DS ecosystem.

Nintendo Servers

Before we begin, it would be beneficial to have a quick breakdown of the different Nintendo servers and what their uses are with respect to account management.

SOAP Servers

First, we have the SOAP servers which the 3DS communicates with using XML SOAP. The client that speaks to the SOAP servers is the “nim” module.

NetUpdateSOAP (NUS)

This server is used to handle update requests and is detailed in my last post.

ECommerceSOAP (ECS)

This is the gateway to all 3DS communication. Whenever the 3DS needs to speak with any of the SOAP servers, it first makes a request to “GetAccountStatus”, which returns the console’s (legacy) account id, region lock information, and other identifying information. It is also lets the 3DS “sync up” with Nintendo. For example, if the account id changed (off-line transfer, system format, etc) then this request returns error code 903 which forces NIM to obtain the proper account id and token through IVS. The account Country (region lock) ensures that requests are being made to servers in the right country. The AccountStatus returned is usually ‘R’ (no NNID linked) or ‘T’ (NNID linked). However, it can also be ‘U’ (device unregistered) or ‘P’ (account transfer is in process). If any of those responses are read, NIM will try to re-register the device (aka, create a new legacy account or transfer an old one over). Next, a list of the server URLs for all the other SOAP servers is returned. Finally, a list of ticket-ids associated with the account is returned. This is a list of all eShop titles and DLCs that the account is licensed for (which can be very large I assume). If the device sees any ticket ids it does not have currently installed, it will download the tickets. All of this is done during an Initialization request to speak with ECS servers from whatever system title made the request. That means every time any system application wishes to speak with Nintendo SOAP servers (for whatever reason), the device syncs up with Nintendo.

IdentityAuthenticationSOAP (IAS)

This handles what I call “legacy accounts.” Before NNIDs were introduced, the account id is unique per device. When you connect a new 3DS to the internet for the first time, a “Register” request is sent to IAS along with the device serial, unique certificate, and a signature over the entire request using the certificate. Nintendo assigns your console an account id and that is used in the eShop. If you choose to delete your unlinked account from the eShop settings menu, the “Unregister” request is made which delinks your legacy account from your unique console certificate. Then the next time GetAccountStatus is called, it will return ‘U’ for AccountStatus which will force the device to register for a new account.

CatalogingSOAP (CAS)

I think this is used to get information about system-wide parameters like “how often can an account be moved”. It is not used much and I did not look into it because it does not handle any account unique requests.

NNID Server

Next we have the “” server which appears to be REST based. The “act” module is responsible for speaking to it. This was introduced with the update that brought NNID. When you create a NNID, it is linked to your device serial and certificate (until you transfer it). Logging in to the NNID server consists of sending a username and hashed password along with the device serial, certificate, and region information. If everything matches what Nintendo has on file, an OAuth token is returned and used for further communications. It is important to note that NNIDs must be associated with a legacy account in addition to a device id. Upon first linking, titles associated with the legacy account is transfered over to the NNID. This means if you bought a console with a game pre-installed and you transfer your NNID over, that game will now be linked with your NNID. Linking an account also means that it is not possible to use that legacy account without the same NNID. When you link an account and format the system, you are forced to create a new legacy account. (I’m unsure if this means that if you buy content with this new legacy account and re-link your NNID if that will transfer the contents over. I believe that would be the case.)

eShop Servers

The eShop servers are also RESTful and are named “samurai”, “ninja”, “ccif”, and “eou”. Samurai is used for eShop requests (game details, screenshots, etc) and ninja is used for account information. The other two I have not observed yet. If the account is not linked (legacy account), getting an authentication token for ninja involves passing in just the serial number, region, and account token (from IVS). If the account is linked to an NNID, then a “service token” obtained from the NNID server (requested with the OAuth token) is also passed to ninja. This is how ninja is linked to IVS and NNID servers.

System Transfer


When you first launch CARDBOARD (either system), as with any SOAP communication, the initialization requests GetAccountStatus which ensures the console is registered and up to date (account-wise, firmware-wise is done through NUS). If the Country returned here does not match the CARDBOARD title’s region, an error is shown. Next a request for GetCountryAttributes is made to CAS which returns MoveAccountMinDays, MoveAccountMaxTimes, and other information. Following that, an IVS request for GetAccountAttributesByProfile is made to check if the account information adheres the limits set by the CAS response. Finally, a couple of ECS requests are made to query the status of the account (balance, tickets, etc) which are likely cached for later use.

Receiving Console

At this point, you are given the option to send or receive from this console. If you are the receiving console, the console begins to broadcast UDS (Nintendo’s custom encrypted local wireless protocol) packets with the profile name, if the device is a development unit, and a hash of the console’s serial.

Sending Console

On the sending console, if it is NNID linked, the user will be prompted to input their NNID credentials. Once successful, the sender listens for UDS broadcasts and displays the ones it sees on screen. Once a receiver is selected, the two exchange basic information about the protocol version (there are current four versions) and various details on the devices. Because UDS does not guarantee packet integrity or arrival, a CRC is added to each packet header. To possibly prevent replay attacks, a random number is placed in each packet and a MD5 hash of the entire packet is included at the end.

Once both consoles are satisfied with the other’s reliability and status, the sending console disconnects from local wireless and connects back to the internet. Using either the NNID service token or just the IVS account token (for unlinked devices), a session with ninja (eShop) is established. This checks that the account is valid and the session is kept open for a later step. A request is made to IVS for MoveAccount with CheckOnly set to true. It passes the account ids, device ids, and tokens for both devices to check if a transfer is allowed. If, for example, the two devices are in different regions, a transfer is not allowed. If no error is returned, the user is now prompted to confirm the transfer (decide how to move the SD card data, move DSiWare titles, and other housekeeping tasks).

Transferring Data

Now the two consoles connect back using UDS and data transfer takes place over RDT, Nintendo’s reliable data transfer protocol implemented over UDS. The contents of nand:/data/<ID0> is copied from the old console over to the new one. I haven’t looked into the specifics of how it works, but I speculate that the receiving console’s SEED (in memory) is changed temporary to the sending console’s SEED. This allows the receiving console to create extdata and sysdata under the sending console’s ID0. Then it creates the data archives through the usual FSUser APIs and fills them with the data received from the old console. After the transfer is complete but before it is validated with Nintendo, the old SEED is restored so the new data cannot be used until the receiving console is synced up with Nintendo.

In the last step (transferring eShop shows up on screen), on the sending console, another request to IVS MoveAccount is made, this time CheckOnly is not set. This effectively transfers the legacy account over. Now, the NNID is transfered over with a request to the NNID server in order to link the new console serial/certificate with the NNID. At this point the old console’s CTRNAND is formatted (even before the “format” prompt shows up).


I have never reached this step since I was not able to perform a proper system transfer (not having access to two consoles from the same region) however I can speculate what happens next. The receiving console creates an empty shared extdata (0xe0000000) and reboots. Home menu sees this extdata and loads up CARDBOARD. It connects to ECS and sees the account status is ‘P’ and gets the new account details. As part of the GetAccountStatus response, a list of all tickets associated with the account is returned (and all tickets are downloaded). Note that since GetAccountStatus is made any time ECS communication is established, this can also happen the next time you enter eShop (if you interrupt the system transfer after the last step above). That is also how offline (Nintendo Support) transfers work. Then it writes the sending console’s SEED to the NAND and restores its own configuration save (wifi settings, profile name, etc) and reboots.

Faking this Process

I was able to fake a system transfer from my USA 3DS XL to my JAP N3DS by augmenting and substituting each of these steps. While the complete process is more complicated than I have time to describe (plus I haven’t kept notes of everything I did), I can give the basic outline of what I did here.

First, I performed a region swap using the SecureInfo replacement trick (using my old 3DS’s SecureInfo means I did not need to patch signature checks, but it also means I must manually patch my old serial number in memory every time I wish to enter eShop). Next I transfered my NNID by running CARDBOARD with the region checks patched out (one patch to replace GetAccountStatus response Country to be US and another one to ignore the error code from MoveAccount). Although the IVS MoveAccount fails, the NNID transfer seemed to have worked. At this point, my American NNID is associated with my Japanese console and Japanese legacy account. Since my legacy account did not transfer over, the validation step will always fail. So I dumped my NAND and manually imported the movable.sed over. Since the system data was already transfered over, I had to “activate” it by removing the 0xe0000000 extdata and copying over my old configuration save. Then I re-flashed my modified NAND and linked my NNID (after patching my old serial in memory). Finally, I was able to enter eShop and trigger the ticket download. Now my old SD card works and all my saves and games transfered over.

World's first US ambassador N3DS non-XL!

World’s first US ambassador N3DS non-XL!

Some Tools

In this long journey to produce an American 3DS (non-XL) with all my information transferred over, I made a couple of homebrew tools and patches that others may find helpful.

  • 3DSInstallTickets lets you import tickets and CIAs into the system. Not really useful now since FBI has a much nicer interface and more features.
  • 3DSTransferDevice lets you export movable.sed and import SecureInfo and movable.sed. It uses official APIs which does verification checks on the data you’re importing so it is “safer” than manually writing the files to the NAND. Of course, you can still brick your device with this so be careful!
  • CardboardPatches are the patches I wrote to log and analyze CARDBOARD (especially the local communication stuff that disconnects you from NTR debugger). Not useful to anyone except hackers wanting to continue this work.
  • Spider3DSTools (NIM Patcher) patches NIM to use your own servers on the O3DS. This allows you to bypass updates on 9.2 and use CARDBOARD. The code is really hacky and was put together in an hour or so.
  • service-patch (Spider fork) attempts to port archshift’s wonderful ARM11 service patching utility to work with Spider on O3DS and was an attempt to make the code above more beautiful. This currently does not work and I don’t think I’ll ever finish it now that I have no use for my O3DS anymore, but it should be “mostly done” (like spiderninja).
  • Patches for eShop to work are needed every time you wish to connect to eShop on your region-swapped NNID linked console. This is because officially your legacy account is still in another region (and eShop application errors on this) even though your NNID is in the right region and only the NNID account is used for eShop. This also patches the update checks so you can enter eShop on 9.2.

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 0x00000000 (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.


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: 0x4082
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!


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


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 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’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 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).


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.


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!


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.


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.