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

 

 

Updates on the Vita Hardware Hacking project

After a week of trying to dump the eMMC (spoilers: didn’t happen yet), I’ve decided to post this update about things I’ve tried to do (and how I tried to do it) and where the money is going to.

Supplies

I had two Vita logic boards. The first one, which I removed the SoC and eMMC to find the trace points (shown previously), came from eBay. The second board came from a Vita with a broken screen generously donated by @Amxomi. I also bought a professional rework station, the X-Tronic 4040 which was paid partially by your donations (I returned the heat gun) and partially thanks to wololo. For wiring, the thinnest wire I could find is enamel-coated magnet wire. For soldering the wires, I got 60/40 Rosin solder and a Rosin flux pen.

Attempt One

The first thing I did was remove the EMI shield base blocking the test point resistors. With the reflow station’s hot air gun, it was much easier than the heat gun I used last time. Next I warmed up my soldering skills by hooking wires up to a microSD to SD card adapter. My plan was to attach the wires to the test point and plug the SD card into a SD card reader. To expose the copper in the enamel-coated wire, I melted a blob of solder and kept it on the tip of the iron at 400C. Then I dipped the tip of the wire into the liquid solder, which both coats the tip of the wire with solder and also removes the coating. It’s a neat trick that I used all the time throughout the rest of the ordeal.

Then I brushed the pins of the microSD adapter with flux and quickly melted a small blob of solder on each pin. Then with a pair of tweezers, I held each wire next to the pin, and as soon as it is heated, the small bit of solder on the wire joins with the blob on the pin and they connect.

It gets much harder connecting the other end. There is very little exposed solder on the tiny resistors, and it is very hard to add more because you might accidentally short circuit two adjacent pads. I made sure there is a bit of solder on the end of the wire using the trick. Then I held the end of the wire steady with the tweezer while tapping it with the iron. It takes many tries for it to stick on, and many times when trying to attach the neighboring pads, the heat from the iron loosens the other wires. In addition, accidentally bumping into the wire causes enough stress to rip the solder off the resistor (because there is so little solder), so I just taped everything to a piece of cardboard. I also can’t test if my joints are correct and not shorted with any other joints because of how small and close everything is.

After a couple of hours, the wires are soldered to the points but there are a couple of problems. First, as mentioned, I couldn’t test the correctness of my connections. Second, I don’t know if in the process of soldering to the tiny resistors, I damaged any resistors and if so, would it still work. Third, I never found a test point for Vdd because for some reason, Vdd shorts to Vss/Ground on my first board. As expected, after plugging the microSD adapter into a reader into the computer, nothing shows up. Because there could be so many problems, I removed all the wires and started over.

Attempt Two

First, I located a test point for Vddf (Vdd is power to the eMMC controller while Vddf is power to the actual NAND chip). My hypothesis is that the same power source that powers Vddf also powers Vdd (although the Samsung documents recommends against this). This point is on top of the tiny resistor to the left of the audio jack.

Next, I decided to remove all of the 150ohm resistors on the test points in order to get more solder surface area. Looking at the eMMC testpoints picture from last time, it’s important to note that the pad on the left of each resistor is the one coming from the eMMC while the pad on the right of each resistor is the one going to the SoC. The resistors themselves may be for current limiting or noise removal. Removing them is as simple as pointing at it with the hot air gun set to 380C for half a minute and then using tweezers to to remove them.

I also found it easier to solder wires directly to the SD card reader instead of to an microSD to SD card adapter. I first verified that the card reader still works and that my wires are not too long by soldering the other end of the wire directly to an old 128MB SD card. After verifying, I removed the wires from the SD card and attached them to the now exposed test points.

Unfortunately, it still didn’t work. The computer sees the SD card reader but believes no card is inserted. Again, there could be any number of problems including (still) bad soldering, Vdd not receiving power, or even read protection in the eMMC.

Attempt Three

Next I made another attempt to find Vdd. The problem is that my multimeter shows a short from Vdd to Vss. This means that Vdd is somehow shorted to ground either because I broke something with all the heat and bad soldering or because that is by design (which I don’t think is true because all documents I read say that you need to power Vdd for the eMMC controller to work). I thought maybe I can experiment by sending test voltages through various locations on the first logic board (the one with the chips removed) and see if I get a voltage drop in the Vdd pad. I used an old broken MP3 player as my voltage source (since it was just laying around and I didn’t want to buy a power supply, rip open any working cable/device, or solder to a battery). I attached the positive end to a pointed screwdriver and the negative end to the Vita’s ground. Then I attached one probe of my voltmeter to the same ground. Then with the screwdriver in one hand and the voltmeter probe in the other hand, I tried to send voltage through every location on the board. Unfortunately, the only response was sparks on capacitors here and there but no response in Vdd.

Back to the second Vita, I tried to attach the battery and charger and turned it on. At first, I got excited and saw a voltage drop on the eMMC’s decoupling capacitor (meaning there’s power going to the eMMC). However, after going back and reattaching the wires, I could no longer reproduce the result. In addition, the power light no longer responds to the power switch. I believe that I shorted something and the first time I powered it on, it destroyed some component; so the next time I attempted to power it on, it fails before even attempting to power the eMMC.

Regardless, I tried to reattach all the wires with better soldering on the assumption that my only problem is still the bad soldering (likely not true). Being the fourth or fifth time doing this, I am getting better at soldering these extremely tiny points. My trick was to first align the wire to the board and then using the tweezer, make a 90 degree bend on the end of the wire. This makes the end of the wire the same length as the original resistors. Then I quickly dip the end in solder, flux the board, and attach the wire to two pads instead of one. This makes a stronger connection. Even though I did a much better job and soldering the test points, I still could not get anything to show up on my computer.

Attempt Four

Now that I have experience in soldering tiny points, I made an attempt at soldering directly to the eMMC removed from the first Vita. However, after a quick test (nothing shows up on the computer), I didn’t look any farther because I believe that the eMMC must be part of a circuit of capacitors and resistors in order for it to work (and not break the chip). All documents I’ve read supports this.

I also made yet another attempt at resoldering to the board again and still no luck. At this point, I believe that either I still am not powering Vdd correctly, or I broke the eMMC at some point. I also suspect that perhaps my SD card reader does not support the Samsung eMMC or that it is not being initialized correctly.

What’s Next

I still haven’t given up. I will continue to try resoldering the points. I still want to find a way to surely power Vdd; I bought another Vita from eBay because I believe the second Vita is now broken. I also ordered a eMMC socket with the last of the usable donations, but it will take at least a month to arrive from China. There’s also the possibility that the eMMC does something unsupported by my SD card to USB adapter and I want to do some raw signal interaction with an Arduino. If you want live updates of progress as I’m working, join #vitadev on EFnet.

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.

Unlimited Backgrounding on iOS

Since iOS4, developers have the ability to perform background tasks with some limitations. Background tasks must fit one of the five different categories for background supported apps. Music and streaming apps can be backgrounded as long as they play music. Newsstand apps can wake once a day to download updates. Location aware apps can wake up once in a while to update their position. VOIP apps can have one socket (I found out the hard way that the one socket does not include listener sockets) connected in the background. General apps can request up to 10 minutes to finish some task. While this is enough for most backgrounding purposes, sometimes we need backgrounding for more advanced tasks. Specifically, I wanted to write a HTTP proxy server that runs on the device (in the future, this proxy server will work as an ad-blocking proxy) in the background. I will show you the steps of making this work. Please note that Apple will certainly reject any app that abuses their backgrounding policy so doing so would only be useful for personal and enterprise uses.

So how are we going to abuse the iOS background policy? We are going to declare our app as a background music player but not play any music. Sounds simple right? Well, in hindsight it is, but there’s some subtle tricks I had to discover to get it all working. Let’s go through this step by step…

First make sure your app has, in “Capabilities”, Background Modes turned on and “Audio and AirPlay” enabled. Also make sure you’re linking with “AVFoundation.framework.”

In our demo app, we will have one button that says “Enable Background” that, when tapped, will keep our app running even if the user switches apps. We also have a NSThread will will keep logging to show that it is running even in the background.

First create your silent music file. I had success with a one-second MP3 file of silence. The audio file does not have to be silent, but why scare the user with a random audio file? Add this to the “Supporting Files” category.

Add a property to the View Controller that will hold the silent audio player.

@property (nonatomic, strong) AVPlayer *player;

Now, you should set up the audio session. I chose to do this in viewDidLoad of my view controller of the single view in the demo app.

NSError *sessionError = nil;
[[AVAudioSession sharedInstance] setCategory:AVAudioSessionCategoryPlayback withOptions:AVAudioSessionCategoryOptionMixWithOthers error:&sessionError];

The category AVAudioSessionCategoryPlayback is one of the few categories that allow for backgrounding. The option AVAudioSessionCategoryOptionMixWithOthers will make sure your silent audio won’t stop any currently playing background audio and also make sure that when the user plays music in the future, it won’t kick off your background task. A good developer will also check the return values and sessionError, but I’m not a good developer.

AVPlayerItem *item = [AVPlayerItem playerItemWithURL:[[NSBundle mainBundle] URLForResource:@”silence” withExtension:@”mp3″]];
[self setPlayer:[[AVPlayer alloc] initWithPlayerItem:item]];

Now create the actual player item for your silent audio file. If you are embedding your audio file a different way, feel free to adapt this to do so. No trickery here.

[[self player] setActionAtItemEnd:AVPlayerActionAtItemEndNone];

Here’s the trick; this makes sure that the audio player is kept active after playing your sound file. The alternative is to keep looping a silent track, but why waste more CPU cycles (and battery)?

Now, whenever you wish to keep the app in the background, just call

[[self player] play];

And your app will keep working even after the user switches the app. In my case, the HTTP proxy server was still working after I left the iPad in sleep mode overnight (with the charger connected of course).

Here is the sample code: Limitless Background (244)

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.

Page 1 of 712345...Last »