10 Days of Hacking, Day 5: The PSP, Part 2


Lets dive directly into what I consider some of the best hacks in the modern Scene of the PSP.

With the creation of the PSP 2000 V3, PSP 3000 and later PSP Go, a fully permanent Custom Firmware became apparently impossible on these devices, leaving developers to focus on other, more volatile, methods to hack the system without touching flash0. This lead to two things: kernel exploits with LCFW and usermode exploits with HBL.

LAZY GAME DEVELOPERS

I’ve already explained more or less how usermode exploits, specially buffer overflows, work. But it is interesting to note that buffer overflows are the result of bad memory management on the developer’s side, and are one of the simplest and easiest to avoid hacks out there. You can sometimes make a mistake and allow for a buffer overflow to happen, but when a lot of games have simple buffer overflows, most of the time in the same place, is a sign of developers going lazy.
Going back to the topic at hand, as I said, back then usermode exploits was an area left untouched, why would you develop there? we had permanent Custom Firmwares appearing almost as fast as Sony’s Official Firmwares. But then as I said, CFW became impossible on newer PSP revisions, and with Dark_Alex’s retirement, a new CFW did not seem like a possibility. Then we got what appeared to be the savior of those people stuck with unhackable devices: the Gripshift exploit.

The Gripshift exploit promised a way of running unsigned code, mainly homebrews and emulators, on any device up to date, but it fell into obscurity due to the lack of a proper tool a la Noobz’ eLoader that would allow to play homebrews, or a kernel exploit that would allow to downgrade, Sony quickly patched the exploit and everybody’s hope went down to the floor again.

A few after that, a developer and part of the PC Gaming Master Race going by the name m0skit0, using an exploit (found by kgsws) in the game Medal Of Honor Heroes, or Heroes 2, or both, I donno, ask him, and started working on his own homebrew loader with the help of ab5000, cause you know, he’s that awesome. m0skit0 (the developer, not the malaria-spreading insect) was contacted by another developer who we call wololo because he can make you switch teams by chanting his name over and over again, who proposed to port his project into another exploit, Patapon 2, that later on got leaked to the public by some asshole looking for 5 minutes of internet fame. Since the site m0skito was using to maintain the project got down, they moved development over to wololo.net/talk and create public SVN repositories of the project in googlecode, and thus Half Byte Loader was born.

Patapon 2 was a great exploit and Half Byte Loader was a great tool to use it, not only did it allow to run homebrews on the latest firmware at the time (6.20), it was also the first tool to do so on the PSP Go. Since the Patapon 2 exploit existed in the demo version of the game, everyone could freely download that onto their PSP’s, copy HBL’s installation files and have some homebrew magic on their previously unhackable device.

Half Byte Loader set the grounds for many more usermode exploits to come and has been actively maintained by the community over all these years, being ported over to the Vita and a lot of other usermode exploits.
HBL is a great piece of software if you consider the greatly limited environment it is running in, so big props to all devs that has made it what it is today.

FOOLING THE KERNEL

I kinda skipped the 5.03 kernel exploit and checkHEN by davee, but that’s because I mostly wanted to separate them into two categories. It’s true that later PSP models prevented the use of permanent custom firmwares, but the PSP 3000 was greeted with a kernel exploit and HEN (later LCFW). But after that, kernel exploits remained hidden by developers, until 6.20 when PSP developer Total_Noob released a kernel exploit that existed all the way up to 6.35, although his HEN originally only worked on 6.20. There’s a lot I can talk about the 6.XX era, Total_Noob, Neur0n, Team PRO, HBL, etc, but I wanna focus on explaining all the kernel exploits that most caught my attention as they all shared something in common: a stupid mistake by Sony, aka a missing check on one of the arguments.

The first one we have is the 5.03 kernel exploit (I don’t remember who the author was, I only know davee only coded the HEN). This kernel exploit existed in the module psheet.prx, most specifically in the function sceDRMInstallGetFileInfo.
Let’s take a quick look at the code:
sceDRMInstallGetFileInfo:
...
0x000000E0: 0xAFB40010 '....' - sw $s4, 16($sp)
0x000000E4: 0x34620108 '..b4' - ori $v0, $v1, 0x108
0x000000E8: 0x00C0A021 '!...' - move $s4, $a2
0x000000EC: 0xAFB3000C '....' - sw $s3, 12($sp)
0x000000F0: 0x00A09821 '!...' - move $s3, $a1
0x000000F4: 0xAFB10004 '....' - sw $s1, 4($sp)
0x000000F8: 0x00E08821 '!...' - move $s1, $a3
...
0x00000140: 0x02602821 '!(`.' - move $a1, $s3
0x00000144: 0x02402021 '! @.' - move $a0, $s2
0x00000148: 0x02803021 '!0..' - move $a2, $s4
0x0000014C: 0x0C0001E8 '....' - jal sub_000007A0
0x00000150: 0x02203821 '!8 .' - move $a3, $s1

I have omitted a lot of code on purpose. So the function pretty much grabs your arguments, calls sceIoOpen, calls another subroutine and then calls sub_000007A0 with argument 0 being the return value of the call to sceIoOpen, argument 1 being the argument 1 we passed to the function and argument 2 being the argument 2 we passed to the function and arg3 being the arg3 we passed. Now we take a look at sub_000007A0:
; Subroutine sub_000007A0 - Address 0x000007A0
sub_000007A0: ; Refs: 0x0000014C
...
0x000007C0: 0x00E09821 '!...' - move $s3, $a3
...
0x000007EC: 0x24060108 '...$' - li $a2, 264
0x000007F0: 0x02602021 '! `.' - move $a0, $s3
0x000007F4: 0x0C000928 '(...' - jal memset
0x000007F8: 0x00002821 '!(..' - move $a1, $zr

This subroutine makes two calls to memset, on the second one, arg0, the destination of the write, comes from the third argument passed to the subroutine, which we know from the previous function that is the arg3 we passed to sceDRMInstallGetFileInfo, which is not at all checked, so we can memset to 0 about 66 instructions in any part of RAM, including kernel RAM.

Next comes the 6.20 kernel exploit released by Total_Noob, this one is explained more in-depth by davee here: http://lolhax.org/2010/12/23/arcanum/
but this is more or less how it works:
The vulnerability exists in sceUtility_private_764F5A3C, here’s interesting part of the code:
sceUtility_private_764F5A3C:
...
0x00002800: 0x0C002229 ')"..' - jal scePower_driver_1A41E0ED
0x00002804: 0x001BDAC0 '....' - sll $k1, $k1, 11
...

It shifts k1 to the left by 11 bits, this is a normal procedure done by Sony to filter out unwanted pointers to kernel RAM. Kernel RAM always start with 0×8, which in binary is 1000, when we call a kernel function from user space interrupt manager sets k1 to 0×100000, so when the function shifts it 11 bits to the left, it becomes 0×80000000. If you were to pass a pointer to kernel RAM the pointer would look something like this 0x8XXXXXXX, when you do the logic operation AND with this pointer and the k1 value 0×80000000, then the result will be 0×80000000, if the pointer would not start with 8 or bigger, then the result would be 0. The PSP checks this value for negativity, in two’s complement (a method of representing signed numbers in binary) anything starting with 0 is positive, starting with 1 is negative. If we pass a kernel pointer then the result will be negative and the kernel will return an error, that is at least the theory, Sony has to do all these checks manually and sometimes they forget something. In this case not only they forget to do any check (they just shift k1 but do nothing to it), if we check the function being called right after the k1 shift (scePower_driver_1A41E0ED), we see this:
scePowerRegisterCallback:
...
0x00000800: 0x001BDAC0 '....' - sll $k1, $k1, 11
...

This function shifts k1 again, if k1 was previously shifted into 0×80000000 and is shifted again then it becomes 0×40000000000, but the PSP is a 32bit machine, and k1 is a 32 bit register, you can’t hold that number, so it overflows into 0, allowing it to pass all k1 checks and eventually reaching this piece of code:
loc_000008D8: ; Refs: 0x000008A4
0x000008D8: 0xAC710000 '..q.' - sw $s1, 0($v1)
0x000008DC: 0x02202021 '! .' - move $a0, $s1
0x000008E0: 0x00008021 '!...' - move $s0, $zr
0x000008E4: 0xAC600004 '..`.' - sw $zr, 4($v1)
0x000008E8: 0x8CB10204 '....' - lw $s1, 516($a1)
0x000008EC: 0xAC60000C '..`.' - sw $zr, 12($v1)
0x000008F0: 0xAC710008 '..q.' - sw $s1, 8($v1)
0x000008F4: 0x8CA50204 '....' - lw $a1, 516($a1)

this code stores a bunch of values at the address pointer by $v1, address that we control, so we can overwrite whatever we want in kernel RAM.

Now onto the last one. This one was found by some1 and existed in httpstorage, in the function sceHttpStorageOpen.
This function doesn’t do any k1 checks, but it does check for the only arg in the function, and if a value other than 0 or 1, the function should return an error, or does it? This is the code that should return an error:
loc_0000005C: ; Refs: 0x00000034 0x000000D4
; Data ref 0x000009F0 ... 0xFFFFFFFF 0xFFFFFFFF 0x00000000 0x00000000
0x0000005C: 0x267409F0 '..t&' - addiu $s4, $s3, 2544
0x00000060: 0x02348821 '!.4.' - addu $s1, $s1, $s4
0x00000064: 0x8E240000 '..$.' - lw $a0, 0($s1)
0x00000068: 0x04820005 '....' - bltzl $a0, loc_00000080
0x0000006C: 0x0240D821 '!.@.' - move $k1, $s2
0x00000070: 0x0C0001B3 '....' - jal IoFileMgrForKernel_810C4BC3
0x00000074: 0x2413FFFF '...$' - li $s3, -1
0x00000078: 0xAE330000 '..3.' - sw $s3, 0($s1)
0x0000007C: 0x0240D821 '!.@.' - move $k1, $s2

it loads a global value and adds it into $s1, then stores -1 on that address. The kernel exploit works by modifying this global value so that $s1 ends up pointing to the area in kernel RAM we wish to modify, and then enable the VFPU to be able to use -1 (0xFFFFFFFF in binary) as an instruction (vsync 0xFFFF). Why the hell do they do some code if they know the argument is not what they wanted? beats me, but we thanks to them we got a kernel exploit and downgrader for 6.39.

There are many other stupid mistakes that granted us with full kernel access, the entire kermit_wlan module was full of them and they were even easier, they never did any arg or k1 check on the arguments we passed and they directly copied stuff there. It’s like they fired the entire PSP staff and contracted people who had no idea how the PSP security works.
But I’m not gonna go into great details about those as they are still Vita specific tasks, and this is mostly a PSP section.

OBTAINING THE KEYS

Another mayor development that happened in this era of PSP hacking is the discovery of the PSP ECDSA keys that allowed us not only to sign homebrews so we could run it on Official Firmware, but also sign our own Kernel prx’s.
This lead to an interesting discovery by kgsws, which eventually lead to the creation of the permapatch.
The permapatch works by faking one of the kernel modules so that the PSP loads it instead of the normal one, once the module is loaded, we can take over control of the entire PSP’s kernel and load a Custom Firmware instantly, since this faked prx is in flash0 and is loaded on boot, this hack becomes the first permanent hack after the IPL and Pandora hacks, allowing many PSP’s to have full CFW where they were previously thought impossible.
The sad part is that Sony themselves discovered this method way before the scene could, and they changed the way flash0 was encrypted in firmwares above 6.20. For some reason some people believe the permapatch is overrated, but from both a user perspective and a hacker perspective, the permapatch is awesome, if you think otherwise, get the hell out of this programming and hacking forum you n00b.

CONCLUSION
Overall the PSP scene has moved away to the new Vita scene, specially the ePSP, which, when hacked, offers all the homebrew possibilities the PSP offered back then.
With this ends the two-part episode of PSP hacking, we watched what were the hacks that allowed us to be were we are at now and we have watched some of the modern hacks that are still valuable and used today. Stay tuned for the next episode, and I promise there will be less technical stuff and much less text.

  1. L2SSnake’s avatar

    Genious, this is genious, so much fun man, ty for this article

    Reply

    1. L2SSnake’s avatar

      btw checkHEN was my first exploit on psp 3000 that i got, it brings smile on my face

      Reply

  2. wololo’s avatar

    It’s difficult to summarize almost 10 years of history of the PSP hacking scene without forgetting a bunch of names. Among names I didn’t see in your article but that deserve some credit, I can think of:

    nem, ookm, fanjita (and the rest of noobz), tyranid, mathieulh, silverspring, coldbird, virtuous_flame.

    Would also like to give additional credit to JJS and Davee for their key contributions in the early days of HBL.

    You also completely ignored the pandora batteries in your articles (and I know you stated that’s because you didn’t have enough documentation about it), but wanted to point that out since it was by far the biggest hack/discovery of the PSP scene.

    There were many others who contributed to that extremely lively scene, I hope they won’t take it personally if I forgot other key people in here

    Reply

    1. Caio’s avatar

      I wonder what those people’s majors are/were

      Reply

      1. Hudavendigar’s avatar

        Computer Science.

        Reply

      2. Davee’s avatar

        Electrical engineering here.

        Reply

      3. hermes’s avatar

        College dropouts

        Reply

      4. wololo’s avatar

        Software engineering for me. But I like hermes’s reply.

        Reply

    2. fate6’s avatar

      Shout out to freddy! cause everyone forgot he existed :3

      Reply

      1. wololo’s avatar

        Damn, forgot to mention him!

        Reply

    3. NNNRT’s avatar

      I like plum, he was an amazing developer. And Mediumgauge, without him & PSP Filer almost everything would be hard to do on eCFW.

      Reply

  3. dboyz’s avatar

    thanks for the articles & tech stuff details, I like your words here =)

    Reply

  4. zxz’s avatar

    thanks for the article. I just wanna point out one small typo though :D
    Name of HEN for 5.03 is chickHEN not checkHEN.

    Reply

  5. something x3 dark side’s avatar

    Gen firmware was my favourite so much you could do, to bad that they never released a firmware for the pspgo, oh well, thanks to the devs that did

    Reply

    1. fate6’s avatar

      GEN is terrible and you should feel terrible for liking it >__<

      Reply

      1. The Z’s avatar

        The only “semi-decent” CFW from the GEN Team was the 5.03 GEN-C, everything else was low quality.

        Reply

        1. fate6’s avatar

          GEN is what would have happen if DaX stopped straightening the M33 backend and instead added plugins into the CFW which only added more bugs

          the plugins also could not be updated sepretly from the CFW

          GG to bubbletune BTW

          Reply

          1. Acid_Snake’s avatar

            You and The Z are looking at Gen CFW from a user perspective, but if you look at it from a dev perspective, it isn’t nearly as bad it you two make it look like. Take into consideration that upon that time NOBODY quite knew how the M33 CFW worked other than the core M33 members, it was a closed source project and most hacks were undisclosed until Dark_Alex left. Team GEN had to not only learn most of the inner workings of M33, but also port it to a firmware that had changed a lot from the one it was last ported to, so it’s very natural that the initial versions of such CFW were so buggy, so was TN-A on 6.20, extremely buggy, but GEN managed to pull it off and by GEN-D3 they had managed to deliver a robust CFW experience, just like TN eventually managed get his HEN stable.

  6. Jun DeJane’s avatar

    Again, nice article and a great read. Keep it up!

    Reply

  7. The Z’s avatar

    Minor mistake:

    TNs 6.20 kernel mode exploit worked up to FW 6.36, not 6.35 :) (/Nitpicking)

    It is also worth to mention that the perma patch, despite being very awesome and a “nearly” permanent solution”, has a very minor chance of failing, which thus renders the device unuseable/bricked.

    The perma patch is technically also not a “full CFW”, since a few things are missing and those things were important for the cIPL CFWs, which are kind of the only full CFWs.

    Just my 2 cents.

    Reply

  8. ambrosjb’s avatar

    A good set of articles. Only one major omission for PSP was PANDORA BATTERY! By far one of the coolest hacks found for PSP. Also talking about the DAX/M33. Wasn’t M33 originally something about March 33nd which is actually April Fools Day?

    Reply

    1. The Z’s avatar

      March 33rd = 2nd April

      The theory is, Dark_AleX woke up to his alarm (clock) showing the 33rd march at 3:33 o’clock. But this is just a legend, haha.

      Reply

  9. Hudavendigar’s avatar

    One thing to add is that the PSP keys were discovered thanks to work done in the PS3 scene.

    Reply

  10. PspJunkie’s avatar

    What? No shout out to Freeplay? Lol!!!

    Reply

  11. SwoRNLeaDejZ’s avatar

    I am thoroughly enjoying this hacking series. Keep up the great work! Couple things that weren’t really touched on in either PSP article were the importance of 5.03 GEN firmware, and I would have also liked a quick breakdown of what the cIPL is and how it works.. Otherwise, awesome post, awesome series, awesome blog, as always. Love reading new posts here ;)

    Reply

  12. poop34244’s avatar

    The ps vita as the same security as the ps3 good like hacking that. psp was easy to hack

    Reply

  13. poop34244’s avatar

    I mean The ps vita as the same security as the ps3 good luck hacking that.

    Reply

  14. Peter Chavéz’s avatar

    Hey great story, but do you remember the Undiluted Platinum Modchip? It helped me unbrick my PSP several times :-)

    Reply

  15. ivo’s avatar

    hi, im still missing something for psp specially on vita :)
    a psplink plugin tutorial with nethostfs and specially a tutorial for the vita

    thanks and cheers :)

    Reply

  16. ivo’s avatar

    or a remotejoy lite with nethostfs tut
    thanks

    Reply

  17. ivo’s avatar

    psplink wifi
    http://forums.qj.net/psp-development-forum/52589-psplink-wifi-working-install-tutorial.html
    or more precise
    howto load psplink wifi in 660 mode as eboot or as plugin

    how do i compile for 660 ? ALLREADY RUN psptoolchain666 with ebootsign by op

    but cant figure out the compile for 660 :/

    Reply

  18. ivo’s avatar

    BUT WHAT ABOUT NETHOSTFS … is this nethostfs just the same and how does psplink vs wifihost vs nethostfs vs remotejoy behave in 660 mode if all at once as plugins ?
    i guess eboot eight right ?

    Reply

  19. osumaniac’s avatar

    I joined this site when 5.55 firmware came out, a year later patapon exploit was made, which allowed me to finally start playing games. Fun times :)

    Reply

  20. Davee’s avatar

    Also, for clarification I also found the psheet exploit for ChickHEN. Still think you’re missing out on pandora a little hah.

    Reply

  21. G0l3m’s avatar

    I have to second that. Davee found the exploit, gave it to some1 and he made the downgrader.

    Still have the screenshot when HEN got released and the big drama when it failed the first day :-D Good old times

    Reply

  22. Frezzno’s avatar

    Oh man I’m crying… This article is so great. Total_Noob forever. I remember how I sat with my PSP3000 every day waiting for a good CFW. How I every time need to boot patapon to do some fun. Today my PSP3000 still run on PRO-B10. Without Total_Noob it wouldn’t even be a PRO. I am so relived that Total_Noob and Coldbird can shake hands today.

    Reply

    1. Frezzno’s avatar

      Forgot to mention it’s 6.20 PRO-B10.

      Reply

  23. DS_Marine’s avatar

    My two cents about Pandora:
    Sony’s designers added a way to boot up the PSP even if flash0 was messed up, so the service dudes could repair the psp in case a firmware update somehow falied.
    The PSP’s battery has a small microcontroller inside it.(as most notebook’s batteries do)
    When you place the battery in your PSP, the logic inside the psp will instantly communicate with it, and request the serial number of your battery (and maybe some other stuff, since the battery’s dump was 256 bytes long).
    IF your battery returns the magic number (0xFFFFFF) then the PSP would load its operating system from the memory stick instead (and it would also auto-power on without you using the power switch).
    Of course, your memory stick had to have the right files in order to boot, and also it needed a modification in its partition table/boot record in order to work (there was an mspformat utility for doing that)
    I suppose some really clever guys figured out this system was in place by reverse engineering the kernel PRXs, or the information leaked out from some Sony employee that went rich by selling batteries and memcards.
    There were some cool utilies made by hellcat for mangling your battery and recover some other vital stuff (like some usb idstorage stuff)
    Cool stuff: your psp could be used to write to the battery and convert any battery to pandora. They removed the ability to write to battery somewhere in psp 2000 models (but still they reacted to pandora batteries). PSP3000 doesn’t even react to pandora batteries, which makes me think that if that they closed this door for psp3000 then maybe they put another system in place to boot from MS, and it’s there waiting for us to discover… maybe communication over the audio remote serial interface? who knows…
    Oh and in theory you could connect that battery pin to the parallel port of a pc and emulate the pandora battery, but I never heard of someone doing that.

    Reply

Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>