Showing posts with label PS Vita. Show all posts
Showing posts with label PS Vita. Show all posts

Friday, July 10, 2015

PSM+ is now publicly available

By Wololo

PSM+ is now available for all registered members on our /talk forum. you can access psmplus here.

What is PSM+

PSM+ allows you to access PSM and PSM Unity (coming soon) without a license from Sony. This means you can develop and test with the PSM SDK and PSM for Unity without a publisher license–even after Sony shuts down developer access. Additionally, it allows for hacks such as Rejuvenate to work on any device with PSM DevAssistant installed for unrestricted native homebrew.

You must be running firmware 3.51 or lower and have PSM DevAssistant installed on your PS Vita.

PSM+ is compatible with the PSM Unity Assistant app, but the rejuvenate hack has not been ported to this yet. You should be able to try PSM+ if you have the PSM App for unity, though, in order to confirm you can run PSM apps with it.
rejuvenate

How to use PSM+

PSM+ works in two steps.

In the first step, you receive a special license by email that needs to be installed on your Vita , + matching files for your computer.

The second step is something you need to do on a daily basis: you need to update your license to prevent it from expiring. This is also done through an email sent by our servers.

PSM Plus pages

You can access PSM+ here. Remember that you need to be signed in to your /talk account in order to access the tool.

Wednesday, April 8, 2015

Package Installer through WebKit


Do you remember the last time you heard about the WebKit exploit of Vita? Was it the Pong? It seems our good friend SMOKE is baking something.

It has been sometime since the WebKit on Vita has been exploited. This WebKit exploit works up to 3.20 firmware. Even though the progress continues, we rarely hear about it.

If you are following SMOKE on twitter, you must have noticed he is into Vita hacking lately. He posted a video where he manages to open Package Installer through WebKit.

I can already hear you saying we can run Package Installer through the e-mail application. That is true, but the e-mail application was introduced in Vita Firmware 2.00, and this is confirmed to work on 1.80. Without further ado, I present you the video:



You can contact SMOKE through his twitter account, he says he can share the script if you have a 1.80 Vita.

PackageInstaller

For more info about the WebKit exploit, visit the thread on /talk or go to the github page of Vitasploit.

Wednesday, January 21, 2015

Top 10 PSP/PS Vita Homebrews of 2014

By Joel16

2015? And we’re still talking PSP's? Heck yeah! I mean why not? After all this site started as PSP Homebrew site. Anyways, today I will present to you 10 homebrews that are worth looking forward to from the year of 2014.

The production of PSP homebrews has drastically decreased compared to years of 2010-2012. Although this hasn’t stopped some developers from injecting their softwares into the PSP scene! Take note that this is entirely based on my opinion, feel free to state yours in the comments. Anyways without further ado:
Number 10: One Installer – Developer Davis9278
Thanks to the new lua interpreter by gdljjrod, this homebrew has made its way onto the PSP scene. One Installer is an application designed for downloading and managing PSP applications homebrew, plugins and themes, directly from the PSP, similar to PSP Installer by  spike_132000. The application has the option to install all contents directly into your memory stick.

Number 9: CyanogenMod PSP Beta – Developer Joel16
Not really a fan of putting my own projects in the front page, but from the very few homebrews released this year, I believe this deserves a spot. This homebrew’s aim is to be equivalent to iRshell (without its ir functions), designed similarly to the modern look of android’s custom rom, CyanogenMod. However it’s still in beta and only offers a few features as of now. These features include:  File Manager, Music Player, Gallery viewer, browser (PSP’s default netfront browser), and some recovery menu functions, all designed exactly like Android.

Number 8: Flappy Bird PSP – Developer Sandoron
flappy_bird
The frustrating yet popular mobile game has been bought to the PSP thanks to developer Sandoron. You know the code! Avoid them green pipes and beat your highscore!

Number 7: ME/LME CFW – Developer RahimUS and Neuron
How would we play our homebrews and backups without this? I mean, well yeah we have other sources like Pro CFW, TN Hen and signed homebrews using OFW, but this CFW has proved its standards and is still being updated today. This CFW is the most updated, and includes almost all must-have CFW features.  This includes the time machine (for PSP’s with hack-able mobos only), leda for 1.50 homebrew support and also PRO Online! The one thing this CFW is missing is the permanent patch that allows permanent CFW access on PSP’s with firmwares over 6.20 and unhackable motherboards. Let’s hope Davee can achieve this, because with that this guy is complete!

Number 6: Nibbler PSP – Developer Insoft
Wish I could post more of Insoft’s homebrews for the year, but we needed more room for others J Nibbler is a remake of an old arcade game, where you navigate a snake through a maze, while collecting apples before making progress to the next level. It consists of a neat retro look and feel to it.

Number 5: Alice in: Pasta Crocket – Developer 240-185
This game was coded during “AC” party which was held near Paris at the month of April 2014.
You must destroy a lemon pie by smashing a ball into it. The lemon pie will send you lots of surprises and traps. It’s a pretty cool arcade-like game, definitely worth giving a try if you ask me.

Number 4: Zelda Navi’s Quest PSP Port – Developer Vincent Jouillat and suloku
Zelda – Navi’s Quest is a PSP port of the fourth game in the french homebrew tetralogy which was created by Vincent Jouillat. The current version is based on the 1.3 PC version and can be completed 100% on the PSP. Do note that his homebrew won’t be compatible with the old PSP 1000 (phat) due to memory problems.

Number 3: Minecraft PSP Edition – Developer woolio
This is the most recently updated Lamecraft mod which offers a plethora of features! This mod is only based on survival mode. Some of fascinating features it includes are: seed generating option, new terrain generator, biomes, crafting, shadows, fogs, and much more! Happy Crafting ;)

Number 2: RetroArch PSP – Developer aliaspider and RetroArch team
RetroArch is an open source, multi-platform frontend designed to be a fast, lightweight, and portable multi-system emulator. The emulator currently contains the following cores: gambatte, tempGBA, fceumm, fmsx, beetle-pce-fast, nxengine, prboom

Number 1: Nazi Zombis Portable – Developer Jukki and Ju[s]tice
NZP is a “remake” of call of duty’s game mode (zombie mode) aimed for PSP. This game lets you fight endless amount undead in a closed and limited area. You gain points from killing them, which you can then spend on purchasing weapons, and advancing further on the map. You can get some things to help you out, but eventually you will die. Your goal is to get to as further as you can through each round.

Sunday, November 2, 2014

Vita hack: the webkit exploit fully explained (+ more code for you to look at!)


This was kind of out of the blue: Developer acez  just posted an article on his blog explaining all the details of the Webkit exploit that was recently revealed for the Vita, including how he and a group of friends leveraged it.

The read is extremely interesting, and I won’t pretend I’m able to summarize it in a way that would do it any justice, so I suggest you just read it.

A cynical summary for people like me who have been in the PSP hacking scene previously would be: “ha, the security on the PSP was a joke, now we’re talking”. The article truly shows that the exploit was not only about digging for CVE's and quickly and dirtily implement them on the Vita.

Between the absence of a debugger, ASLR, sandboxing, no JIT, and other bumps in the road, acez’s post clearly explains this was not easy. At all.

From the scene’s perspective, it’s interesting to see that the main people behind this work (freebot, acez, and John The Ropper) are – as far as I know – not people from the PSP or PS3 scene. They seem to be, however, very, very well seasoned hackers (at least acez seems to be a regular CTF – The hacking ones, not the Quake ones – contestant). The things they pulled off, which I understand where very helpful, behind the scene, to some of the releases we’ve seen over the past few days, were not an easy thing.

Credits

Johntheropper and freebot worked with acez directly on the exploit. In addition, he credits Yifanlu and Josh_Axey for their help on the Vita, as well as Acid_Snake and Codelion, and everyone else who “made this possible”.

Downloads

The exploit and all related work can be found on acez’s github. At this point I assume this is more or less the same work that has been released in CodeLion’s recent memtools_vita, but it is worth checking it.

What’s next?

Let’s hope that the interest of acez, JhonTheRopper, and freebot for the Vita will stay for a while. As mentioned in the blog article, there’s still a lot to do: Webkit is sandboxed, and without additional exploits, the scene will not be able to gain “full” native access to the Vita. From a personal point of view though, I would surely be happy to start seeing a simple SDK, and some simple homebrew, in the sandboxed Webkit exploit. Just for the sake of it.

Source: acez.re

Sunday, December 30, 2012

SKFU teases us with what could be a native PlayStation Vita hack

By Jd8531

Just recently developer SKFU has made progress on what could be a native hack of the Vita, giving us our first visual glimpse!

It seems hacking progress is regularly attempted outside of the PSPemu (which is the typical eCFW and VHBL) by SKFU. Awhile back you may remember our reporting on news that the developer SKFU was able to get a developer PS Vita and had slowly started to peal back the veil of his own Vita exploit by releasing common app paths in the Vitas filesystem.

Now, SKFU has revealed a picture of what could be a native Vita exploit, confirming that he has made progress with that Dev unit. SKFU posted the picture below and playfully teasing us by saying “VHBL is not the only thing working on 2.02 :-P
It seems that if this photo is correct, SKFU has been able to do a very in depth analysis (something we saw with his reveal of the Vitas common app eboot paths) of the Vita and has made some progress in his investigations. What’s shown in the picture is a custom icon and naming of said application.

But don’t get too excited yet. Showing icons of homebrews in the XMB has always been possible on the PSP, it didn’t mean the PSP would accept to run them if they weren’t signed. The PS Vita however is known to prevent you from even copying homebrews to the memory stick, so SKFU has at least figured out how to do that… or is this just a feature of the dev units?

This could be a false lead, but as of now this is the only known one outside the pspemu, besides Yifanlu’s UVL. This is likely to be a huge and developing story so stay tuned for more information, we’ll try to reach out to SKFU for more details on this.

Wednesday, December 26, 2012

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.