|
March 4th, 2012, 16:05 Posted By: wraggster
via http://wololo.net/wagic/2012/03/04/a...d-the-psp-emu/
In this article I will share a few of the things I’ve found on the vita while working on VHBL, and in particular in the psp emulator part. I’ll also give some details that will be useful to people who want to write PSP homebrews compatible with the Vita, or to people who would like to write an alternate menu for VHBL. There’s probably nothing major or groundbreaking in there, but this is information I didn’t want to share until VHBL was released, as some of the things described here will probably end up being patched in further CMA/Vita firmware updates (I don’t think the explanations given here give away anything that couldn’t be found by an engineer looking at how VHBL works. There’s no magic in the stuff I do with VHBL).
Details about the PSP Emulator on the vita
I developed VHBL mostly on a PSP1000, but made some tests on the Vita once in a while as well. I found three major differences between a regular 6.60 PSP and the emulator.
First, it seems to me that it is impossible, within the PSP emulator, to copy a file named EBOOT.PBP inside a subfolder of the PSP/GAME folder. For example, the Vita prevents the emulator from creating and/or writing in a file named PSP/GAME/Wagic/EBOOT.PBP. This is probably a security for the emulator to avoid erasing a PSP game by mistake? wMenu bypasses this security by changing the EBOOT.PBP filename into wmenu.bin when extracting it from the “install.zip” files. This lack of EBOOT.PBP files is also probably why all those homebrews show up as “corrupt” in your content manager. Note that the PSP/SAVEDATA folder does not have this issue.
Another issue is that normal API calls to “readdir” do not seem to return the “.” and “..” folders. I initially thought that this was a problem with my VHBL port, but this does not happen when running VHBL on a PSP. To the normal user, this means that some emulators will not give you an opportunity to load roms from any place else than where the homebrew itself is located (typical symptom: you can’t “navigate” in the folders from your favorite homebrew). To developers, this means you might need to come up with a different way of “browsing folders”. For wMenu I ended up counting the number of “/” symbols in the path instead of relying on readdir. This limitation is usually not leading to a compatibility problem with homebrews, but some of them might behave strangely because of that.
Finally, and that is probably obvious, it seems only ms0:/ is accessible from the PSP emulator. I wasn’t expecting to see the full content of the PS Vita’s memory card from within the PSP emulator, but it also seems that there is no flash drives… don’t quote me on that, but it seems to be what I’m seeing through PSP Filer. Update on this: some people (namely, yosh) are telling me that for example fonts from the flash0 folder can be read.
CMA and it’s limitations
The Content Manager Assistant is a revolutionary piece of software installed on your Vita that does not only manage to be extremely inconvenient to use, it also appears to be crippled with security holes and limitations.
Copying homebrews and installing exploits on the PSP was relatively easy: the PSP was recognized as a USB drive on your computer, which allowed us to simply copy files in there. The CMA makes this more complicated: CMA allows us to copy images, videos, music, psp savedata, and vita/psp games. I have yet to verify, but it seems any data identified as “corrupted” will not be copied (although, I’m thinking this might not be the case for video/image/music files). The CMA also decides where to copy the files. You cannot choose to copy your mp3s in a way that they will be accessible from the PSP emulator, for example.
This means I had to change the structure of HBL a little bit in order to get it to run on the Vita. I needed something that would be accessible from within the PSP emulator, so the files had to be contained within a PSP Game or a PSP SaveData. Since PSP Games on the Vita are packaged/signed in a specific way that I didn’t try to understand, packaging HBL fully inside a Save data seems like the most obvious way (while in the past, HBL was installed at the root of the memory stick, this couldn’t happen here since CMA decides for us what goes where). In addition to that, CMA will not copy the subfolders inside some savedata, only the files directly in the folder. This means everything needs to be flat, which is in essence the “core” of the changes that were required to get HBL to work on the ps vita.
Since the CMA does not copy subfolders for PSP savedata, and since psp savedata was my only “entry point” to copy stuff inside the PSP emulator (including the exploit, HBL, but also homebrews), this made things not very practical to copy homebrews that often have subfolders. The idea here was simple: let’s pack the homebrew inside a zip file, put that file in the savedata, get CMA to copy the savedata folder on the memory stick, then unpack the zip from within HBL. This is the reason for the somewhat “complex” homebrew installation system that people have to follow with VHBL. Of course, VHBL would still work with a different installation pattern, so if other people want to come up with other ways to install homebrews, they just have to create an alternate menu for VHBL.
wMenu is, for historical reasons, not open source. However, the HBL svn contains the source for a basic menu that could be extended in order to support zip “unpacking” or any other homebrew installation system. I’m looking forward to seeing alternate menus for VHBL.
Network and paranoia
CMA requires you to be constantly connected to the internet while you are copying files. When I first learned about that I really freaked out, on top of being angry at this unneeded requirement. In addition to that, the PS Vita itself is potentially monitoring lots of the things you are doing with it. In my particular case, what annoyed me was the “error log” mechanism. As its name tells you, that thing logs crash reports every time your console runs into problems. I assume these logs are regularly sent to Sony when your console goes online (I have no proof of that, but I’d rather assume it’s the case. If you can prove me wrong, please do so). That system is probably here to improve the customer experience, by helping Sony to quickly find the applications/games that have largely-spread issues. In my case, this was a problem because every time I had a crash in VHBL while developing it, I ran into the risk of letting Sony know which game was involved in the process. This is the main reason I did not distribute the VHBL files even to people who were aware of the game long before the info went largely public: people could have leaked some critical info to Sony without even knowing it.
A log taken on the day VHBL was ran for the first time on a PS Vita. Did Sony know about this since day 1?
To address the CMA network issues, openCMA was the solution I used during VHBL’s development. For the crash log system, I had no option but to connect my console as little as possible to the network… Works being done on the network side, such as SKFU’s proxy are probably going to become necessary in the future for people who want to use their Vita without being constantly monitored.
For more information and downloads, click here!
 There are 0 comments - Join In and Discuss Here
|
|
