Decrypting IPL

Discuss the development of new homebrew software, tools and libraries.

Moderators: cheriff, TyRaNiD

Post Reply
nem
Posts: 73
Joined: Thu Jan 13, 2005 9:21 pm
Contact:

Decrypting IPL

Post by nem »

I have successed to decrypt IPL. Here is how.
This article is mostly based on my guess, so there could be some errors.

IPL overview

Within the on-board flash ROM, there exist non fat organized area which contains encrypted bootstrap code, or IPL; Initial Program Loader. While booting up CPU reads the area, decrypt it, store to main memory, and run it. IPL itself is located at 0x40000..0x73fff (system1.00) and its flash ROM block numbers at 0x10000..0x13fff. Upon power-up CPU reads 0x10000..0x101ff, then 0x4000..0x73fff.

Code: Select all

00010000..00013fff  block numbers of IPL
00010000  10 00 11 00 12 00 13 00 14 00 15 00 16 00 17 00 
00010010  18 00 19 00 1A 00 1B 00 1C 00 00 00 00 00 00 00 
  remaining is all 00  

Code: Select all

00040000..00073fff  encrypted IPL
every 0x1000 bytes following pattern exists, 
i.e. 0x00040060..0x0004008f, 0x00041060..0x0004108f, 0x00042060..0x0004208f, ... 
 +60  01 00 00 00 00 00 00 00 00 00 00 00 FF FF FF FF 
 +70  60 0F 00 00 10 00 00 00 00 00 00 00 00 00 00 00 
 +80  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
others seems to be random-looking data

How to decrypt IPL

IPL is organized as series of 0x1000 byte blocks, each block contains 0xf60 byte of unencrypted data which includes loading address and so on. Every block can be decrypted by following code;

Code: Select all

//IPL block decryption
unsigned char iplbuf[0x80000] __attribute__((aligned(64)));
unsigned long (*semaphore_2)(void *a0,unsigned long a1, void *a2,
  unsigned long a3, unsigned long a4)
  =(void *)0x880571CC;  //system 1.00, possibly same as PspPet's g_mangleProc

//returns zero if successed
unsigned long decrypt_iplblock(void *iplblock)
{
  _memcpy(iplbuf+0x40,iplblock,0x1000);
  return semaphore_2(iplbuf,0x1040,iplbuf+0x40,0x1000,1);
}
This function returns iplbuf as 0xf60 byte result formatted as;

Code: Select all

offset   size   description
+0x000    4     address to load
+0x004    4     size of data body
+0x008    4     ordinally zero, nonzero for entry point??
+0x00c    4     unknown, check digit??
+0x010   0xf50  unencrypted data body
On system 1.00, encrypted IPL is 212,992byte(0x34000byte). Unencrypted IPL is 203,840byte(0x31c40byte) and loaded to address 0x040f0000, entry point seems to be 0x040f0000.


Organization of unencrypted IPL of system 1.00

Unencrypted IPL consists of three part. (1) plaintext mips code starts from offset +0, (2) gzip'ed loader program named main_led.bin from offset +0xcc0, and (3) again encrypted 'iplpayload' from offset +0x10000. Plaintext mips code initializes the system and unpack main_led.bin to address 0x04000000 and jump to this address. Possiblly main_led.bin decrypt and load the iplpayload, not confirmed yet though. And iplpayload seems to load everything rest.

Iplpayload can be decrypted by following code;

Code: Select all

//iplpayload decryption for 1.00
//uipl should point offset +0 of unencrypted IPL, size is size of unencrypted IPL
//returns zero if successed, you get unencrypted iplpayload in iplbuf
unsigned long decrypt_iplpayload(void *uipl, unsigned long size)
{
  _memcpy(iplbuf+0x40,uipl+0x10000,size-0x10000);
  return semaphore_2(iplbuf,size+0x40,iplbuf+0x40,size,1);
}

Iplpayload have decryption routine of prx, ~PSP format, along with the table which is the base of PspPet's "step1_result".


Discussion

IPL is decrypted by CPU onchip boot ROM, which may have limited function. Theoretically, decryption of IPL enables us to decrypt all files on further versions, until sony thinks out something spechial anti-hack measure. If sony do not have some sort of secret weapon, this could be difficult to achieve.

hanya-n :)
zigzag
Posts: 129
Joined: Wed Jan 26, 2005 2:11 pm

Post by zigzag »

Can we theoretically use this to boot Linux now then? Or am I confused?
User avatar
groepaz
Posts: 305
Joined: Thu Sep 01, 2005 7:44 am
Contact:

Post by groepaz »

very nice :=P i didnt think its that easy :=)

anyway i should ask if this area can be dumped with the lflash driver, do we need to use direct hardware access, or is it completely impossible by software?

@zigzag: booting linux is merely a matter of porting it....you can make a loader that shuts down all active threads (and deinits hardware) then and load it through the vsh like any other homebrew. the porting bit isnt exactly trivial though, since no mmu-less mipslinux exists (yet).
adresd
Posts: 43
Joined: Sat Jan 17, 2004 11:32 am

Post by adresd »

very nice nemnem.

IPL mist clears a bit :)
nem
Posts: 73
Joined: Thu Jan 13, 2005 9:21 pm
Contact:

Post by nem »

There are various way to get the IPL dumped.
For I am out now, explaining briefly.

Direct hardware access, by which I firstly got the dump, is a little annoying to do. You have to peel off the memory chip, or need to interrupt the pattern on the PSP main board.

The more convenient way is to read by means of software, using sceNand API. Some functions of sceNand can be used to read/write all area of the flash mem including non fat organized area. Note that this method can be used only for system version 1.00 and 1.50 at this time.

Another way is to extract the binary image from updater. Updater have IPL image file to write within. For versions 1.50, 1.51, 2.00, and fake updater's.

One more interesting possibility is kbooti.bin, which sometimes can be found in UMD. Though I have not tested yet, the organization of data seems to be same as encrypted IPL, i.e. series of 0x1000 byte blocks. Could be decrypted by same way as IPL.


Regarding CPU on-chip boot ROM. As mentioned lately, CPU reads block number and encrypted IPL from flash ROM upon power up. This suggests that non-trivial software exists within CPU. It is just assumption that the CPU have on-chip boot ROM though. There is no information regarding this, and no known way to access. There could be a way.
placasoft
Posts: 53
Joined: Mon Mar 28, 2005 10:53 am

Post by placasoft »

Good job nem!
PspPet
Posts: 210
Joined: Wed Mar 30, 2005 2:13 am
Contact:

Post by PspPet »

Cool. Will add the IPL decode special case to PsarDumper2A.
User avatar
dot_blank
Posts: 498
Joined: Wed Sep 28, 2005 8:47 am
Location: Brasil

Post by dot_blank »

terrific discovery
tested for kboot.bin files
comparable information ;)

thank you nem!
10011011 00101010 11010111 10001001 10111010
Chrighton
Posts: 58
Joined: Wed Jun 15, 2005 8:24 pm

Post by Chrighton »

Excellent work, Nem :)
nem
Posts: 73
Joined: Thu Jan 13, 2005 9:21 pm
Contact:

Post by nem »

Theoretically, decryption of IPL enables us to decrypt all files on further versions, until sony thinks out something spechial anti-hack measure. If sony do not have some sort of secret weapon, this could be difficult to achieve.
I was so excited that I became insane and wrote like that. Possibly sony already has the secret weapon. Decrypting by this method may be up to current version, not having analyzed in detail, just waiting to see coming versions. Appologies.
florinsasu
Posts: 47
Joined: Wed Dec 15, 2004 4:23 am

Post by florinsasu »

Very nice one, Nem!

For anyone interested here's the sourcecode for memlmd (1.0 fw):
http://ps2dev.ps2-scene.org/memlmd.c
mrbrown
Posts: 1536
Joined: Sat Jan 17, 2004 11:24 am

Post by mrbrown »

florinsasu wrote:For anyone interested here's the sourcecode for memlmd (1.0 fw):
http://ps2dev.ps2-scene.org/memlmd.c
It doesn't compile.
florinsasu
Posts: 47
Joined: Wed Dec 15, 2004 4:23 am

Post by florinsasu »

mrbrown wrote:
florinsasu wrote:For anyone interested here's the sourcecode for memlmd (1.0 fw):
http://ps2dev.ps2-scene.org/memlmd.c
It doesn't compile.
:) then get this: http://ps2dev.ps2-scene.org/pspdecrypt_wip.rar
it uses some of the above code (uses decrypt function, but links with kernel semaphore).
mrbrown
Posts: 1536
Joined: Sat Jan 17, 2004 11:24 am

Post by mrbrown »

Cool, thanks!
PspPet
Posts: 210
Joined: Wed Mar 30, 2005 2:13 am
Contact:

Post by PspPet »

re: source code for decryption parts (stating the obvious)
This has nothing to do with "IPL". The tricky part of the decryption is in the hardware (the 0xBDE000xx memory range). The IPL load steps use the hardware directly with raw unmangled headers.

All the other stuff (with the different keys etc, like most of PSarDumper) is used to setup the decryption process and unmangle the header information before sending it to the hardware.

Analysis of the hardware functionality would be interesting (but OT for this thread). In particular the opcodes 7 and 1 (opcode 11 is SHA1)
Dr. Vegetable
Posts: 171
Joined: Mon Nov 14, 2005 1:32 am
Location: Boston, Massachusetts
Contact:

Post by Dr. Vegetable »

Ok, I am sure some of you smart people have already considered this, but...
Some functions of sceNand can be used to read/write all area of the flash mem including non fat organized area. Note that this method can be used only for system version 1.00 and 1.50 at this time.
Does this mean that it is possible for a homebrew application to re-flash a 1.0 or 1.50 PSP with custom firmware?
AyAn4m1
Posts: 15
Joined: Mon Sep 26, 2005 2:45 am

Post by AyAn4m1 »

Dr. V, to answer your question...

On the flash chip there are several distinct areas of memory. The first of these is the IPL, which is also the first thing loaded by the CPU when the PSP is turned on. After that, flash0 and flash1 are mounted and the OS is loaded. We can write to flash1/flash0 already with sceIo functions, because they are mounted just like ms0. However, the sceNand functions allow us to write to any area of the memory (not just flash1/flash0), because instead of reading and writing files to/from a mounted filesystem, it allows the reading and writing of binary data to/from the flash chip itself. The upside to this is that this allows us to (theoretically) rewrite every bit of firmware on the PSP, but the downside is that the sceNand functions are still fairly mysterious, and because we're not writing to a filesystem, it becomes even more dangerous than overwriting stuff on flash1/flash0. The reason that the sceNand function were included in the API (this is just my guess) is so that Sony could release a total firmware overhaul if they wanted to, but so far they've only needed to change flash1/flash0 files. So basically, once we figure out the sceNand functions, yes, we could write custom firmware, but therein lies a seperate problem. Whatever firmware we flash with sceNand is going to have to allow itself to be upgraded, because unless that code allows the sceNand functions to be called again, you're stuck with an OS that cannot upgrade itself. Long story short... don't hold your breath for a "custom PSP OS," but the foundation is coming together. I'm pretty sure that all of that information is accurate, but someone please correct me if I'm wrong.
TyRaNiD
Posts: 907
Joined: Sun Jan 18, 2004 12:23 am

Post by TyRaNiD »

Well the firmware updates do update the ipl as well and use the nand functions to do it. Version 2 needs is especially because they changed the way that prx files are decoded, if they didn't update the IPL it wouldn't work.
Dr. Vegetable
Posts: 171
Joined: Mon Nov 14, 2005 1:32 am
Location: Boston, Massachusetts
Contact:

Post by Dr. Vegetable »

Well that is encouraging news!

I know how easy it would be to brick a PSP while trying to burn custom firmware into it. After all, one strategically placed bug is all it takes to hang that sucker so it'll never boot again. It would also be very easy to scramble the re-flashing routines such that you could not flash it ever again. And I suppose since one could only re-flash a PSP that already supports homebrew apps, there is very little incentive to take that risk in the first place.

Still, it is nice to know that it might be possible. Perhaps when PSP emulators get sophisticated enough, someone will be able to develop and test new firmware without putting an actual PSP at risk. Another option might be to pull up the flash chip and move it into a socket (if such a socket/POGO fixture exists) so that the NAND chip could be re-flashed outside of the PSP if/when bad firmware strikes during development.

Not that there's really anything wrong with the Sony firmware once you can load homebrew on it, but I am sure there are some creative folks out there who could come up with something a whole lot better if there was a way.
User avatar
ryoko_no_usagi
Posts: 65
Joined: Tue Nov 29, 2005 4:47 pm

Post by ryoko_no_usagi »

Pardon my ignorance but wouldn't one need to know how to encrypt the IPL in order to successfully replace it? And isn't encryption the problem in the first place?
moonlight
Posts: 567
Joined: Wed Oct 26, 2005 7:46 pm

Post by moonlight »

ryoko_no_usagi wrote:Pardon my ignorance but wouldn't one need to know how to encrypt the IPL in order to successfully replace it? And isn't encryption the problem in the first place?
The first part in the IPL is plain mips code that decrypt the other code.
So, no need to be encrypted, maybe i'm wrong.
User avatar
ryoko_no_usagi
Posts: 65
Joined: Tue Nov 29, 2005 4:47 pm

Post by ryoko_no_usagi »

moonlight wrote:
ryoko_no_usagi wrote:Pardon my ignorance but wouldn't one need to know how to encrypt the IPL in order to successfully replace it? And isn't encryption the problem in the first place?
The first part in the IPL is plain mips code that decrypt the other code.
So, no need to be encrypted, maybe i'm wrong.
Nem wrote "IPL is decrypted by CPU onchip boot ROM, which may have limited function" so I take it the entire IPL in flash is encrypted. Otherwise I can't even see the point of encrypting it at all. I'm curious how Nem even managed to figure out how to decrypt it in the first place...
Dr. Vegetable
Posts: 171
Joined: Mon Nov 14, 2005 1:32 am
Location: Boston, Massachusetts
Contact:

Post by Dr. Vegetable »

You are right - nem does say that the IPL is encrypted. So we would need to know Sony's private key in order to encode a new IPL. Drat!

I think nem mentioned prying up the flash and/or cutting traces on the PCB in his initial efforts to decrypt the IPL. Perhaps he got some clues about the public key by watching and decoding activity on the address/data lines. Perhaps the IPL itself contains redundant decryption code that enabled him to find the public key in a copy of IPL that was decoded by the boot ROM?

Someone in another thread suggested reverse-engineering the private keys by brute force - encode a short piece of code, submit it to the system for decryption, then compare it to the original input code. They estimated that this might take "a couple of years" which sounded optimistic to me. This approach would also be much harder to do with the boot ROM, since we'd need to replace the IPL and reboot; not simply iterate trial modules in RAM. But since we know how to decrypt the IPL, it seems like we could write an application to run on a PC that would brute-force re-encrypt the IPL and compare against the original. If the PSP development community then pooled our spare CPU cycles, we might be able to legally discover the initial keys by brute force before our PSPs turn into dust. Kinda like the SETI Screensaver project.

I don't really know how feasible that idea would be. I suppose it would depend on how fast a single combination could be tested and how many volunteer CPUs showed up for the party. We'd probably still be looking at a couple decades of thumb twiddling.

Oh, well. It was a fun delusion while it lasted.

EDIT:
I should learn how to read. It looks like nem is using a firmware routine (semaphore_2) to perform the decryption, so he didn't actually need to know the public key in order to do so.

Sorry, guys. I'm still a pink, squealing newbie when it comes to console hacking.
Post Reply