The Difference between HEN, M33, Devhook, IPL, Pre-IPL, user, and kernel Exploits

[Erland]

Please read this carefully.
Please read this carefully.
Please read this carefully.

Lets answer some well meaning questions here. I don't even come to this board but due to HEN coming out and Davee being on this board i'm here...

I keep seeing people asking some of the stupidest questions here and they need to be answered.

Mods clean up my language as you see fit.

I'm well known on MaxConsole and a Mod on Dark_Alex's Forum if you want my credentials.

Lets start with

OFFICIAL FIRMWARE
=================================================
Official firmware is the firmware or the operating system that is on your PSP that SONY has shipped with the PSP it's self or you have downloaded from them to upgrade your PSP.

Currently the highest PSP Official Firmware is 5.50. This cannot run homebrew or ISO's without the help of an exploit.


Custom Firmware
=================================================
Custom Firmware was given birth to by Dark_Alex. He got the inspiration from Humma Kavula's UMDEmulator and how it saved it's self from sleep mode. (The Thread that started it) I wish I can find the thread where he said it.

Dark_Alex then went on and made a Proof of Concept 1.50 that he made with HEN built in.

Since then he has taken every worthy version of Sony's firmware and made it custom so he added the following to them:

4 Different ISO loaders
HEN-D
Custom "new" firmware downloader
Recovery menu
VSH menu
A NID translator
Popsloader
Ability to change speed of CPU

As far as I know that is all he puts into the custom firmwares. What this does is allow the following:

Playing of Homebrew by using HEN-D
Playing of ISO's with one of the 4 ISO Loaders: OE, M33, Sony's, Original
Playing of Playstation 1 Games using PopsLoader.


HEN
=================================================
What is Hen and what does it do.

HEN stands for "HomeBrew Enabler". What it does is allow the use of homebrew on Official firmware. What it does is it exploits the firmware using a kernel exploit and then runs arbitrary code to allow the use of unsigned EBOOTS. The Current version of HEN is HEN-D

This means anybody that knows how can make a homebrew application to run on the PSP. This homebrew that is now made for this specific exploit can do anything that the PSP can do. Including an ISO loader.

HEN it's self does not allow for the use of ISO's. It allows for the use of unsigned EBOOTs that is all.

For someone to stop the ability to make an ISO loader for that particular version of HEN takes the ability to block calls to the whatever the ISO loader uses, which might also stop some other homebrew as well. I'm not saying it's not possible but it's normally not worth the time. However if "he's" truly against piracy then it's possible.

REMEMBER: ALL HEN DOES IS GIVE THE ABILITY TO RUN UNSIGNED EBOOTS NOTHING MORE NOTHING LESS


Devhook
=================================================
Devhook is a emulator that runs on HEN. Devhook is an unsigned EBOOT.

DevHook is one of the biggest most genius pieces of engenieering the PSP Scene has ever had

What Devhook does is it emulates an official firmware that adds in HEN and an ISO loader. That is all.

Currently the newest version of Devhook is 0.6F which currently only runs on 3.10 OE and only emulates OFW's 2.71 - 3.11. It might be able to emulate up to 3.40 but that is it. Why because the encryption and the nids in 3.50 and up have changed and no one has updated DevHook to work with these changes. Currently Devhook only works on the PSP-100x's AFAIK due to there being no reason to run it since CFW came out.

The reason Devhook has not been updated is because CFW has come out. The reason why Devhook was created is because newer firmwares would come out, as well as games. These games require the newer firmware to run. Well M33 took this requirement out so if the new game requires OFW 10 to run you can still run it on 5.00 M33-6 unless there is something that is physically in 10 that it has to have to run.

The future of Devhook. Mathieulh has the Devhook sources and has provided them to Team C+D and the Prometheus developers on Booster's behalf, if one of them update it, it can be used on the HEN that is coming out for TA-088v3 or PSP-300x. Devhook can then be used to allow these PSP's to run the newer firmware's 5.50+ by using Devhook and still allow for ISO and HEN usage. However I doubt this will happen. Why because 5.00 M33-6 is out and I'm sure 5.50 M33 will be out soon. Also because I don't think Booster will be coming out of retirement anytime soon and I don't think anyone will get the source code.


User Mode Exploit
=================================================
A user mode exploit is an exploit that allows for access to the PSP's firmware that is currently in RAM as well as a few choice NID's in the firmware. However it does not allow for the ability to access the hardware.

Just because a PSP or any other firmware, game, or program doesn't function properly when you screw with it doesn't mean you have found an exploit


Kernal Mode Exploit
=================================================
A kernel mode exploit allows for access to the hardware. Which in turn gives access to the Flash0,1,2,3. This means that a new CFW can be installed. It also means that HEN can be used to allow for the usage of unsigned EBOOTs.

A kernel exploit allows for full access to the PSP. Without the kernel exploit HEN cannot be used.


Pre-IPL
=================================================
What the pre-ipl does is when the PSP is turned on it's the first thing that runs. It's what tells the processor where to look for the program to start loading the firmware. This is built into the PSP it's self. This cannot be updated by a firmware update. It's hard coded into the PSP it's self.

This is the program that allows the PSP to either boot from the NAND or the Memory stick.

Currently the PSP-100x, and PSP-200x, pre-ipl's have been exploited or cracked. The PSP-300x or TA-088v3 is using the same pre-ipl and has not been dumped to be allowed to be examined to be able to be cracked or exploited.


IPL
=================================================
The IPL is called the "Initial Program Loader" What this does is when the PSP turns on. This can be updated with a firmware update. I don't really know how much more information you need on this one so I'll leave it here until someone asks.


Summary
=================================================

I hope this clears up a lot of stuff for a lot of people.

Please read this carefully.

 

[seanix]

Useful information.Thanks to post all these.

 

[january39]

Yes, very useful. I knew most of it all ready but Devhook i have little knowledge about.

Having read the Tiff-Hen thread here i can see why this has been posted though.

+rep

 

[Mathieulh]

Why are only Alex and Booster credited here, what happened to Nem, Tyranid, and lost of other great devs ? have people forgotten them already?

Also about devhook sources, I have them all but I am certainly not about to leak them (sorry about that). I have also distributed those to c+d/Prometheus developers on Booster's behalf, so the sources are not lost so to speak.

Also about custom firmware (at least from 2.71SE to 3.52M33 (the later not included)) the idea had NOTHING to do with umdemulator (despite its code surviving loadexec) it was based on using the fact that 1.50 kernel did not check the elf signatures to replace vshmain (which was executed/bootstrapped by the kernel) with an elf containing our own code, this code was basically based on Devhook and executed reboot.bin allowing to (transparantly for the user) reboot to your own (hacked) kernel, (which unlike devhook, was no longer stored on ms0:/ but directly into flash0:/)

Later on the bootstrapping of our own reboot.bin execution code was "accelerated" by using the "simple prx" exploit (as we called it inside Prometheus), basically old kernels (up to 1.52 if I recall well) allowed loading of unsigned prxs
as long as they had no imports and were loaded after loadcore.prx but before init.prx

Finally starting with 3.52M33, we started using our own forged IPL block to run the custom firmware which rendered the use of the devhook code and the old 1.50 kernel useless.

 

[MiKeY188]

Why are only Alex and Booster credited here, what happened to Nem, Tyranid, and lost of other great devs ? have people forgotten them already?

Tyranid was an epic PSP dev in the days he deserves credit just as much as the rest.

 

[Hardrive]

Why are only Alex and Booster credited here, what happened to Nem, Tyranid, and lost of other great devs ? have people forgotten them already?

Also about devhook sources, I have them all but I am certainly not about to leak them (sorry about that). I have also distributed those to c+d/Prometheus developers on Booster's behalf, so the sources are not lost so to speak.

Also about custom firmware (at least from 2.71SE to 3.52M33 (the later not included)) the idea had NOTHING to do with umdemulator (despite its code surviving loadexec) it was based on using the fact that 1.50 kernel did not check the elf signatures to replace vshmain (which was executed/bootstrapped by the kernel) with an elf containing our own code, this code was basically based on Devhook and executed reboot.bin allowing to (transparantly for the user) reboot to your own (hacked) kernel, (which unlike devhook, was no longer stored on ms0:/ but directly into flash0:/)

Later on the bootstrapping of our own reboot.bin execution code was "accelerated" by using the "simple prx" exploit (as we called it inside Prometheus), basically old kernels (up to 1.52 if I recall well) allowed loading of unsigned prxs
as long as they had no imports and were loaded after loadcore.prx but before init.prx

Finally starting with 3.52M33, we started using our own forged IPL block to run the custom firmware which rendered the use of the devhook code and the old 1.50 kernel useless.

I love reading these tidbits about early PSP development. It's interesting seeing how it was all done, especially when I was just using the exploits without understanding how they work.

 

[MiKeY188]

I love reading these tidbits about early PSP development. It's interesting seeing how it was all done, especially when I was just using the exploits without understanding how they work.

I agree its really interesting to find our what & how they did things back then. Shame i wasnt really around back then

 

[Erland]

@Mathieulh

I know there are a lot of people who deserve credit. I however was not trying to sit here and list everyone's credentials and what they have done. They know who they are and what they have done. I am not trying to give a history of the scene just explain what the differences were between these "things". I do apologize if I have offended you or anyone else.

It was 3 o'clock in the morning when I wrote that thing and most of it came off the top of my head not researching. I have only been in the scene since 3.10 OE so anything before it is a little fuzzy due to me not being there.

As far as the 1.50 POC. There is a thread out there on Maxconsole I believe it's on MaxConsole, it was where Dark_AleX stated that he got the idea of 1.50 POC from Humma.Kuvula's UMDEmulator when he reversed it and the way it survived XXXXXX. I don't exactly remember what X was though. I was looking for that damn thread for 30 minutes last night to back myself up and couldn't find it but, I know it's there. Sorry.

As far as Devhook goes I did not realize that anyone had the source code short of Booster, which you saying that Team C+D, and the Prometheus dev's however I still don't believe a new version will be out unless there is a great need for it a rises. I will correct this above.

=================================================

Hey Mathieulh,

Sorry I got board and I don't mean to offend.

If this makes you feel better I have put together a list of dev's and what they have done. Now This list is not complete by far. Also when It comes to Custom Firmware There is more than D_A that contributed to it, however I do not know exactly who helped. Please feel free to add or edit as needed. Everyone on this list is a known dev and has contributed in one way or another. Weather you like them or not is another subject as well as how much they contributed may be under review as well.

However I'm sure I'm missing people and please don't get pissed if I have. There are just too many to list.

=================================================

UMDEmulator
=======================
Humma.Kuvula

Custom Firmware
Despertar del Cementerio
=======================
Dark_AleX (moonlight)

Pandora
=======================
Prometheus / Team C+D

Adrahil (VoidPointer)
Booster
Cswindle (Caretaker)
Dark_AleX (Malyot)
Ditlew
Fanjita (FullerMonty)
Joek2100 (CosmicOverSoul)
Jim
Mathieulh (WiseFellow)
Nem (h1ckeyph0rce)
Psp250
Skylark
TyRaNiD (bockscar)

Devhook
=======================
Booster

Nand Tool
Open Source Pandora Battery Tool
=======================
cory1492

Elf Menu
PRX.Decrypter
PSPIdent
=======================
jas0nuk

You also have:

0okm
ADePSP
Ahman
Chilly Willy
CoolJ
Davee
Denis
Hellcat
HellDashX
FreePlay
Ketchup
Kratosjohn
MaTiAz
mph
Miriam
N00bz
OldPrisoneR
RainMotorsports
Red_Squirrel
Sanik
SilverSpring
takka
Team N00bz
Torch
Weltall
wololo
Zx-81

 

[Seth]

Why are only Alex and Booster credited here, what happened to Nem, Tyranid, and lost of other great devs ? have people forgotten them already?

Also about devhook sources, I have them all but I am certainly not about to leak them (sorry about that). I have also distributed those to c+d/Prometheus developers on Booster's behalf, so the sources are not lost so to speak.

Also about custom firmware (at least from 2.71SE to 3.52M33 (the later not included)) the idea had NOTHING to do with umdemulator (despite its code surviving loadexec) it was based on using the fact that 1.50 kernel did not check the elf signatures to replace vshmain (which was executed/bootstrapped by the kernel) with an elf containing our own code, this code was basically based on Devhook and executed reboot.bin allowing to (transparantly for the user) reboot to your own (hacked) kernel, (which unlike devhook, was no longer stored on ms0:/ but directly into flash0:/)

Later on the bootstrapping of our own reboot.bin execution code was "accelerated" by using the "simple prx" exploit (as we called it inside Prometheus), basically old kernels (up to 1.52 if I recall well) allowed loading of unsigned prxs
as long as they had no imports and were loaded after loadcore.prx but before init.prx

Finally starting with 3.52M33, we started using our own forged IPL block to run the custom firmware which rendered the use of the devhook code and the old 1.50 kernel useless.

I think everyone forgot about great old Nem otherwise know as the guy who started it all.

 

[zaza]

good use
wonder the tiff exploit is...kernel exploit or user exploit...
im newbie
thanks...

 

[Seth]

good use
wonder the tiff exploit is...kernel exploit or user exploit...
im newbie
thanks...

It a user exploit...

 

[Slasher]

good use
wonder the tiff exploit is...kernel exploit or user exploit...
im newbie
thanks...

The tiff exploit is a usermode exploit, but Davee has furthermore found a Kernel exploit that works with it. We have full kernel mode.

 

[NoEffex]

good use
wonder the tiff exploit is...kernel exploit or user exploit...
im newbie
thanks...

What slasher said^^

Basically, this is how it works. User mode exploits are used to trigger the kernel mode exploit.

This means, say they have a kernel mode exploit and have had it for a while, but don't have any way to use it, because it requires unsigned code in the first place. This is how the user mode exploit comes into effect. It allows the initial unsigned code to be ran, then the kernel mode exploit is used within that and it allows kernel access, and when you have ALL of that, you have pretty much whatever access you want.

All in all, you generally can't have HEN without one of them both.

 

[Zero]

Thanks Erland for this post, it really clears things up and helps people undertsand what's going on. +rep

I love reading these tidbits about early PSP development. It's interesting seeing how it was all done, especially when I was just using the exploits without understanding how they work.

Heh, I do the same thing. I love reading on how these exploits work, and how they found them. I've spent loads of time on HackMii recently for the Wii exploits.

 

Erland, you didn't write that much about IPL, so I will tell you.

IPL boots the firmware (mostly the kernel). It's what "gives life" life to the PSP.

You should read this about IPL. Really good.

Spoiler: IPL Information by SilverSpring

The (New) PSP Technical Docs
Article01: (PSP Boot sequence)
Version: 0.1

Author: SilverSpring
E-mail: silverspringpsp [at] gmail [dot] com

Todo:
- Part3 IPL
- Firmware load sequence
- clean up!! (and stuff)


CONTENTS:

1. Version History

2. Introduction

3. Pre-IPL Boot Sequence
3.1. Part1 Pre-IPL (the loader)
3.2. Part2 Pre-IPL (the payload)

4. IPL Boot Sequence
4.1. Part1 IPL (the loader)
4.2. Part2 IPL (main.bin)
4.3. Part3 IPL (the payload)

5. Firmware Boot Sequence

6. Obligatory Legal Stuff



------------------------------------------------------------------------

1. Version History


0.1 - (05/11/07) first draft



------------------------------------------------------------------------

2. Introduction


When the PSP is the in the default off state, the only hardware running
is the SYSCON chip. SYSCON controls most of the PSP's hardware,
including the power & battery. It runs off the internal cell battery on
the motherboard so even without the main PSP battery inserted, the
SYSCON chip is still running. The SYSCON chip is responsible for
monitoring the power switch, and when this power switch is activated,
SYSCON applies power to the main CPU.

The main CPU is a custom-made Sony CPU with a MIPS32 core and has an
embedded mask rom (like most embedded systems do) which is exactly 4KB
in size. This holds the "preipl" (this is where the routines to boot
into service mode are and loads & decrypts the encrypted IPL from the
nand/MS). This preipl mask rom device is mapped to physical address
0x1FC00000 (this is the address of reset exception vector on MIPS CPUs),
and this is where the CPU starts executing from on coldboot.



------------------------------------------------------------------------

3. Pre-IPL Boot Sequence


3.1. Part1 Pre-IPL (the loader)

The preipl is made up of 2 parts, the "loader", and the "payload".
Because the preipl is stored in non-volatile read-only memory it cannot
use variables, so the Part1 preipl code (the loader) copies the Part2
preipl (the payload) to the CPU's scratchpad RAM (the only RAM available
at this time, along with another 4KB block of RAM and the 2MB EDRAM -
normal DDR SDRAM hasnt been initialised yet). The scratchpad RAM is
mapped to physical address 0x00010000, and after Part1 has finished
copying Part2 to it, it jumps to this new address.


3.2. Part2 Pre-IPL (the payload)

Now the CPU is executing from the scratchpad RAM (the preipl payload).
The preipl payload inits the nand hardware and reads the IPL
nand-block-table (a table with the physical block numbers of the
ecnrypted IPL's location on the nand). The table is located at the
4th physical block of the nand (offset 0x10000), and is repeated for
the next 7 blocks. This is so that if a bad block occurs in any of
these blocks, the table can still be read. Though if all 8 blocks
become bad blocks, its a non-recoverable brick as the preipl can no
longer locate the IPL's location (the only solution to this problem
is to either boot from MS instead, or use a custom IPL to patch the
preipl to remap the table - both of which would still require Pandora).

The entire raw IPL is stored on the nand encrypted. The preipl payload
uses a 4KB RAM (this RAM is mapped to physical address 0x1FD00000, but
will later be remapped to 0x1FC00000 to be used for the ME CPU reset
exception vector) as a temporary location to load & decrypt each
encrypted IPL block. Because this RAM is only 4KB in size, the
encrypted IPL is organised as 4KB blocks on the nand. As the preipl
decrypts each of the 4KB IPL blocks, it loads the decrypted blocks to
the IPL entry address 0x040F0000 (this address is located in the 2MB
EDRAM which is normally used as VRAM, normal DDR RAM still has not been
initialised yet). When the preipl has finished decrypting and loading
all the encrypted IPL blocks it jumps to the IPL entry address.



------------------------------------------------------------------------

4. IPL Boot Sequence


The decrypted IPL is composed of 3 parts:
Part1 - the 'loader', Part2 - 'main.bin', and Part3 - the 'payload'.
Part1 is plaintext MIPS code, Part2 is gzip compressed, and Part3 is
again encrypted (from 2.60 onwards, parts 2 & 3 are further encrypted
again).


4.1. Part1 IPL (the loader)

One of the first things Part1 IPL does is reset the main CPU.
After reset the preipl mask ROM device is no longer mapped to memory at
all (the 0x1FC00000 address range is then remapped to the 4KB RAM
mentioned above to be used for the ME reset vector). This is why the
preipl is no longer accessable once the IPL has booted. The Part1 IPL
does some very basic hardware inits and decompresses the gzipped Part2
IPL (main.bin) to address 0x04000000 (still in EDRAM). Part1 IPL then
jumps to the entry address of main.bin (0x04000000) to initialise the
hardware.


4.2. Part2 IPL (main.bin)

Part2 IPL (main.bin) is responsible for initialising the PSP hardware.
It has copies of it's own driver libraries similar to the drivers found
in the firmware (including: sceNAND_Driver, sceDDR_Driver,
sceIdStorage_Service, sceSYSREG_Driver, sceSYSCON_Driver,
sceGPIO_Driver, sceClockgen_Driver, & sceI2C_Driver). Some of the
initialisation of the hardware depends on data stored in idstorage keys
(for example keys 4,5,6). Note this is where TA082/086 motherboards
'brick' on 1.50 firmware. The clockgen hardware was changed on TA082/086
motherboards so the functions used to initialise it does not recognise
the new hardware. And because part of the initialisation depends on data
stored in key5, simply by invalidating key5 (by corrupting the header),
the initialisation is skipped allowing the firmware to continue to boot.
After initialising the hardware (including the DDR RAM), Part2 IPL
decrypts the Part3 IPL (the payload) and loads it to address 0x08400000
(which is located in normal DDR RAM now that it has been initialised).
It then jumps to the entry address of the Part3 IPL (0x08400000) to boot
the firmware.


4.3. Part3 IPL (the payload) - todo



------------------------------------------------------------------------

5. Firmware Boot Sequence - todo



------------------------------------------------------------------------

6. Obligatory Legal Stuff


I'll keep this short. This document is meant to be free for everybody to
use so feel free to do whatever you wish with it (no need to ask for
permission).

 

[january39]

Erland, you didn't write that much about IPL, so I will tell you.

IPL boots the firmware (mostly the kernel). It's what "gives life" life to the PSP.

You should read this about IPL. Really good.

That is good, i hope he/she finishes it. Very interesting.

if that internal cell battery fails and all power is cut to SYSCON i am assuming that the PSP simply will not load until a 'proper' battery is inserted.

I do know that the cell battery is responsible for remembering time & date settings etc etc and is easily replaced.

Silverspring is very knowledgable about PSP, i would love to know more about the person silverspring. Mind you i spse so would Sony

 

[kenlc]

very useful for newbee,thanks

 

[golemer]

Please read this carefully.
Devhook
=================================================

Currently the newest version of Devhook is 0.6F which currently only runs on 3.10 OE and only emulates OFW's 2.71 - 3.11. It might be able to emulate up to 3.40 but that is it. Why because the encryption and the nids in 3.50 and up have changed and no one has updated DevHook to work with these changes. Currently Devhook only works on the PSP-100x's AFAIK due to there being no reason to run it since M33 came out.

to my understanding, if someone update NID referenced by devhook, does it mean devhook can work on the FW after 3.50??

need any patch to kernel?

 

[LocutusEstBorg]

What slasher said^^

Basically, this is how it works. User mode exploits are used to trigger the kernel mode exploit.

This means, say they have a kernel mode exploit and have had it for a while, but don't have any way to use it, because it requires unsigned code in the first place. This is how the user mode exploit comes into effect. It allows the initial unsigned code to be ran, then the kernel mode exploit is used within that and it allows kernel access, and when you have ALL of that, you have pretty much whatever access you want.

All in all, you generally can't have HEN without one of them both.

Also the kernel exploit should be callable from the context of the user exploit. If you have a function X that is used for a kernel exploit, X should be reachable somehow from the user application you've exploited (either from its imports table or some other way). Just having a random kernel exploit isn't always useful.

 

[Erland]

to my understanding, if someone update NID referenced by devhook, does it mean devhook can work on the FW after 3.50??

need any patch to kernel?

Yes Devhook can be updated to work with even 5.55 if someone wanted to take the time to update it.