Latest Posts

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 (1196)

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.

VitaMTP

libVitaMTP is a library based off of libMTP that does low level USB communications with the Vita. It can read and recieve MTP commands that the Vita sends, which are a proprietary set of commands that is based on the MTP open standard.

OpenCMA is a frontend that allows the user to transfer games, saves, and media to and from the PlayStation Vita. It makes use of libVitaMTP to communicate with the device and other libraries to intrepet the data sent and recieved. OpenCMA is a command line tool that aims to be an open source replacement to Sony’s offical Content Management Assistant.

More information can be found on the Github page.

Changes

  • 2013-05-17: Added wireless device support
    Fixed video titles not showing
    Fixed invalid disk space reporting on Linux
  • 2013-05-06: Removed the need for psp2-updatelist.xml
    Added more help information about usage and behavior
    Fixed HUGE memory leak in sending Vita/backup objects
    Fixed HUGE memory leak in receiving PSP saves
    Fixed a minor memory leak in renaming function
    Fixed crash in Linux systems when sending apps
  • 2013-05-04: Initial binary release.

Additional Information

Project Link

Huawei E587 (T-Mobile 4G Sonic Hotspot): Information and rooting

Earlier this year, I got my hands on the T-Mobile 4G Sonic Hotspot and as always, had to tear it apart as soon as I got it. I never wrote about it because I didn’t find anything overly interesting, but now it’s the end of the year, and I need to clear some inventory from my brain. If anyone remembers my post on the (older) T-Mobile 4G Hotspot (sans “Sonic”), the main limitation of that device was that the processor is an obscure one that required some digging to get information on. Thankfully, the Sonic variety is much easier to break into.

Teardown

I don’t usually do this, but as I couldn’t find any good snapshots of the insides of this device, I took it upon myself to produce some amateur shots. One thing I want to say about the insides is that I loved how the main board is broken into three parts and they’re sandwiched together to make the device small (but thick).

Device with faceplate removed.

Device with faceplate removed.

MCIMX283CVM4B

FreeScale MCIMX283CVM4B

Qualcomm MDM8220 modem

Qualcomm MDM8220 modem

Middle layer, containing various chips

Middle layer, containing various chips

The important information is that the device is ARM based (it even uses the same system-on-chip as older Kindles), and having a well documented SoC is always a plus. There isn’t an obvious debug serial port, but I would bet that there is one knowing how the FreeScale SoCs work. However, we don’t need to explore hardware hacking yet as the software is unexplored.

Rooting

This was literally the easiest device I’ve ever rooted. I can honestly say that from opening the package (knowing nothing about the device) to getting a root shell took me about fifteen minutes. There was only one interface to the device and that’s the management webpage. My plan was to explore every location where I could pass input to the device (settings, HTTP POST requests, MicroSD file browser, etc) and basically just try things until I get a crash or something interesting. The first thing I’ve tried was the settings backup/restore feature. Creating a backup of the settings allows you to download a SQLite database containing the settings. A quick SQL dump of the settings showed me some interesting options that can’t be set directly from the web interface, including:

CREATE TABLE telnet
(
TelnetStatus int
);

Yep, setting TelnetStatus to 1 and restoring the backup database showed me that port 23 was now open from the hotspot’s IP. Well, that was extremely lucky, as always the best hacks are the one which doesn’t require hacking at all. Well that was only half the challenge, the next part is getting access to the root account. I’m thinking everything from brute forcing passwords to looking at privilege escalation exploits but all of that disappeared as soon as I typed “root” and enter because there was no password prompt. That’s right, “root” doesn’t require a password. I did a quick inventory of the filesystem and found the block devices, and using the magic of dd, nc, and the old Unix pipe, quickly dumped all the filesystems.

Software

Here’s the thing though, I spent all this time (almost 45 minutes at this point!) rooting the device and I don’t even have a clear goal. I don’t need to unlock the device because I was a T-Mobile customer at that point, and I didn’t really want to make a pocket ARM computer/server (which would be a thing one can do with this), so I just did a quick scan of how the device works (curiosity is the best excuse) and went my way. Here’s some of the things I’ve discovered, use this information how you will.

First of all, the device runs a stripped down build of Android running “Linux version 2.6.31 (e5@e587) (gcc version 4.4.0 (GCC) ) #1 Sun Aug 28 02:25:47 CST 2011.” On startup, most of the vanilla Android processes (including adbd) are not started, but instead the Qualcomm modem driver, some pppd/networking daemons, and a custom software they call “cms” are started. “cms” makes sure stuff like their custom httpd (which is hard coded to allow the HTML portal site to perform functions on the hotspot) and power management and the OLED display are running and in good status. The Huawi device stores all data on its flash MTD device. From a quick analysis (aka, might be errors), block 0 contains the u-boot bootloader (in what I believe is a format dictated by FreeScale), block 3 contains the kernel (gzipped with a custom header, possible also dictated by FreeScale), block 4 contains the rootfs (also gzipped with a custom header) loaded with boot scripts and busybox, block 5 is Android’s /system which also contains the main binaries (like cms, httpd) and the HTML pages, block 6 is Android’s /data which is empty, block 8 maps to /mnt/backup which I believe is, as the name says, just backups, block 12 maps to /mnt/flash which I believe is where ephemeral data like logs are and also where the settings are stored, and block 13 maps to /mnt/cdrom which has Huewai’s software and drivers for connecting to the computer with (and you see it when you plug the device into your computer).

That’s a quick summary of some of the things I’ve found while poking around this device. Nothing interesting (unless you’re a Huawei E587 fanatic I guess), but I’m sure there’s someone, someday, who got here from Google.

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 2 of 1112345...10...Last »