forums.ps2dev.org

nem · Joined: 13 Jan 2005 Posts: 73

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.

zigzag · Joined: 26 Jan 2005 Posts: 129

Can we theoretically use this to boot Linux now then? Or am I confused?

groepaz · Joined: 01 Sep 2005 Posts: 305

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).
_________________
http://www.hitmen-console.org
http://hitmen.c02.at/files/yapspd/

adresd · Joined: 17 Jan 2004 Posts: 43

very nice nemnem.

IPL mist clears a bit :)

nem · Joined: 13 Jan 2005 Posts: 73

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 · Joined: 28 Mar 2005 Posts: 53

Good job nem!

PspPet · Joined: 30 Mar 2005 Posts: 210

Cool. Will add the IPL decode special case to PsarDumper2A.

dot_blank · Joined: 28 Sep 2005 Posts: 498 Location: Brasil

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

thank you nem!
_________________
10011011 00101010 11010111 10001001 10111010

Chrighton · Joined: 15 Jun 2005 Posts: 58

Excellent work, Nem :)

nem · Joined: 13 Jan 2005 Posts: 73

florinsasu · Joined: 15 Dec 2004 Posts: 47

Very nice one, Nem!

For anyone interested here's the sourcecode for memlmd (1.0 fw):
http://ps2dev.ps2-scene.org/memlmd.c

mrbrown · Joined: 17 Jan 2004 Posts: 1536

florinsasu · Joined: 15 Dec 2004 Posts: 47

mrbrown · Joined: 17 Jan 2004 Posts: 1536

Cool, thanks!

PspPet · Joined: 30 Mar 2005 Posts: 210

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 · Posted: Sun Nov 27, 2005 6:44 am Post subject:

Ok, I am sure some of you smart people have already considered this, but...

AyAn4m1 · Joined: 26 Sep 2005 Posts: 15

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 · Joined: 18 Jan 2004 Posts: 918

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 · Posted: Mon Nov 28, 2005 11:01 am Post subject:

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.

ryoko_no_usagi · Joined: 29 Nov 2005 Posts: 65

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 · Joined: 26 Oct 2005 Posts: 567

ryoko_no_usagi · Joined: 29 Nov 2005 Posts: 65

Dr. Vegetable · Posted: Tue Nov 29, 2005 11:48 pm Post subject:

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.