One of largest barrier to native PS Vita homebrew is the lack of an open toolchain and SDK. Essentially, we need something like pspsdk for the Vita. The reason why we don’t have it is because there are people who have an understanding of how the Vita’s executable format works but lack the time to code up the tools and there are people who have the time and ability to create such tools but lack the knowledge of Vita’s internals. The solution, I believe is to publish a comprehensive document detailing how the Vita’s executable format is laid out and the requirements for an open toolchain. Anyone with coding skills can now work on an open SDK; no Vita knowledge required! Continue reading
PlayStation Mobile (PSM) for those unaware is Sony’s platform for indie game developers. They have decided to start shutting down the service after May 31, 2015. Before then, I think it would be wise for everyone (not just game developers) to sign up for an account (it’s free!), set up the developer assistant on their Vita, and run at least one sample application. If you don’t try this platform out and see what it has to offer, you might regret it.
What you should do before June 2015:
- Sign in to the PSM DevPortal with your PSN account
- Click the button to “Apply for PSM Publisher License” and follow the directions
- After you get your license approved, download SDK 1.21.02 (NOT SDK 2.00.00 or Unity for PSM)
- Follow the directions to get the dev assistant for your Vita
- Once everything is installed, play with a demo! For example, BallMazeDemo is pretty fun. Before the demo will run though, you have to generate an app key. Refer to PSM’s documentations for that.
Last time, I analyzed now update checks worked on the 3DS. That was a straightforward process. CARDBOARD (known colloquially as “System Transfer”) is a bundle of complexity with no less than three separate servers communicating with each other as well as the device. A custom proprietary protocol is used for 3DS to 3DS communication. Finally, we have multiple unique identifiers the console uses to identify itself with Nintendo (serial, certificates, console id, account id, etc). I can’t imagine this will be comprehensive, but I hope that whoever is reading can gain new insight on the complexity of the 3DS ecosystem. Continue reading
Since there isn’t much public documentation on how 3DS updater and the NIM module works, I thought I should write something up. Continue reading
First, some background: the 3DS has two main processors. Last time, I went over how Gateway Ultra exploited the ARM11 processor. However, most of the interesting (from a security perspective) functionalities are handled by a separate ARM946 processor. The ARM9 processor is in charge of the initial system bootup, some system services, and most importantly all the cryptographic functions such as encryption/decryption and signature/verification. In this post, we will look at how to run (privileged) code on the ARM9 processor with privileged access to the ARM11 processor. Please note that this writeup is a work in progress as I have not completely figured out how the exploit works (only the main parts of it). Specifically there are a couple of things that I do not know if it is done for the sake of the exploit or if it is done purely for stability or obfuscation. From a developer’s perspective, it doesn’t matter because as long as you perform all the steps, you will achieve code execution. But from a hacker’s perspective, the information is not complete unless all aspects are known and understood. I am posting this now as-is because I do not know when I’ll have time to work on the 3DS again. However, when I do, I will update the post and hopefully clear up all confusion. Continue reading
It’s been a couple of days since my initial analysis of Gateway Ultra, released last week to enable piracy on 3DS. I spent most of this time catching up on the internals of the 3DS. I can’t thank the maintainers of 3dbrew enough (especially yellows8, the master of 3DS reversing) for the amount of detailed and technical knowledge found on the wiki. The first stage was a warmup and did not require any specific 3DS knowledge to reverse. The problem with the second stage is that while it is easy to see the exploit triggered and code to run, the actual exploit itself was not as clear. I looked at all the function calls made and made a couple of hypothesis of where the vulnerability resided, and reversed each function to the end to test my hypothesis. Although there was many dead ends and false leads, the process of reversing all these functions solidified my understanding of the system. Continue reading
When we last left off, we looked at the ROP code that loaded a larger second-part of the payload. Now we will walk through what was loaded and how userland native code execution was achieved. I am still an amateur at 3DS hacking so I am sure to get some things wrong, so please post any corrections you have in the comments and I will update the post as needed. Continue reading