Custom IPL sample (and bit of IPL info)

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

Moderators: cheriff, TyRaNiD

Post Reply
moonlight
Posts: 567
Joined: Wed Oct 26, 2005 7:46 pm

Custom IPL sample (and bit of IPL info)

Post by moonlight »

This is an example (with source) of a very simple custom ipl with only 2 features :)
The custom ipl extends the 1.50 one. The copyrighted material (sony 1.50 original ipl) has to be provided by the user in form of the 1.50 updater.

Download:

http://www.megaupload.com/?d=A0SN4362

Feature for user:

- It bypasses ta-082+ brick, so you can have a ta-082+ without any key patched running 1.50 kernel based firmwares.

Feature for programmer:

- It dumps 0xbfc00000, the psp boot code prior to ipl, to the address 0x883e0000 (which is not touched by 1.50 kernel). To get the boot code in a 1.50 original firmware, just run kdumper, and extract 0x3e0000-0x3effff from the kmem.bin file -> that's the psp boot code. If you are in a cfw, you will have to execute the kdumper as a recovery or autoboot, because the 3.XX kernel overwrites the 0x883e0000 memory.

Note that this ipl is flashed to the nand, not written to the ms.

Some info about the ipl, etc.

- The first instruction executed by the PSP at boot is 0xbfc00000. This memory address is not the same than the 0xbfc00000 that can be accesed when the system has booted.

- The memory is read only, so variables cannot be written. Because of this, the psp boot code copies code from itself to the scratchpad memory (0x80010000).

- There is memory section 0xbfd00000-0xbfd01000. This is the one that will be converted later in the 0xbfc00000 that programmers usually know.

- One of the first things SCE ipl's do is to reset the main cpu. In the 1.50 ipl, this happen at address 0x040f0070-0x040f0084. When the cpu is reseted, what 0xbfc00000 memory was cannot be accesed anymore. The 0xbfd00000 memory gets remapped as 0xbfc00000, and 0xbfd00000 is now an invalid memory address.

- Since 2.60, SCE aproached that fact to encrypt their ipl's: they used as a seed for a prng the 0xbfc00000 memory before the reset, to decrypt main.bin (main.gz), knowing that it would be impossible to dump it after the reset. They also played with the two meanings of 0xbfc00000 to cause confussion.
While it appeared to be an intelligent move to hide their ipl's, it wasn't really that intelligent: they made us to have much curiosity for that memory, and we didn't stop until we dumped it :) That curiosity ended in service mode. If they hadn't hidden their ipl's... maybe Pandora wouldn't exist today, who knows.

- IPL is executed when returning from sleep mode too. Main.bin follows two different branches depending if it is plain boot or sleep mode return, as obviously the kernel is not booted again. The code branch can be seen at address 0x04000490 in main.bin of the 1.50 ipl:

Code: Select all

u32 x;
func04005074(&x);

if (x & 0x80)
   sleep mode return;
else
   plain boot;
The function 0x04005074 is equivalent to the syscon function sceSyscon_driver_F775BC34.

- When not in service mode, the memory stick power is off, and the memory stick routines causes an infinite loop. To use the memory stick in a nand ipl, you have to power on the ms yourself.

- The service mode conditional can be found beginning at address 0x8001004c in the psp boot code:

Code: Select all

if ((*(u32 *)0xbe240004) & 0x10)
{
    use memory stick ipl routines;
}
else
{
   use nand ipl routines;
}
Last edited by moonlight on Sun Aug 26, 2007 4:55 am, edited 1 time in total.
adrahil
Posts: 274
Joined: Thu Mar 16, 2006 1:55 am

Post by adrahil »

nice ;)
KickinAezz
Posts: 328
Joined: Sun Jun 03, 2007 10:05 pm

Post by KickinAezz »

Nothing much to add.. Great job!

---

Some of the (previously) undocumented NIDS are no longer undocumented [we atleast know their names]. Silverspring will be busy :)
crazyc
Posts: 408
Joined: Fri Jun 17, 2005 10:13 am

Post by crazyc »

Very interesting, thanks.
jas0nuk
Posts: 137
Joined: Thu Apr 27, 2006 8:00 am

Post by jas0nuk »

This is a great piece of work and interesting to read. Thanks DAX/C+D
User avatar
dot_blank
Posts: 498
Joined: Wed Sep 28, 2005 8:47 am
Location: Brasil

Post by dot_blank »

i Have already begun toying with the fact :)

now vsh modules do not need unloading as ipl
can just not have them in there :)_

thanx alex for main.S
10011011 00101010 11010111 10001001 10111010
Slash
Posts: 26
Joined: Sun Jan 07, 2007 9:04 pm

Post by Slash »

So that's what you meant by saying retiring from cfw development. :)

As for me, it gets really tiring to do the same thing over and over. Its more fun to do and research something new.
hlide
Posts: 739
Joined: Sun Sep 10, 2006 2:31 am

Post by hlide »

dot_blank wrote:now vsh modules do not need unloading as ipl
can just not have them in there :)_
can you elaborate what you mean with "unloading" ?
KickinAezz
Posts: 328
Joined: Sun Jun 03, 2007 10:05 pm

Post by KickinAezz »

May be patch that lets you turn on the PSP from OFF mode even when the battery is less than 14% would be great!
J.F.
Posts: 2906
Joined: Sun Feb 22, 2004 11:41 am

Post by J.F. »

KickinAezz wrote:May be patch that lets you turn on the PSP from OFF mode even when the battery is less than 14% would be great!
That has nothing to do with the IPL. Your IdStorage is corrupted - probably from how you downgraded. The original 2.71, 2.80, and 3.03 downgraders corrupted some keys in the IdStorage as part of the downgrade for TA-082 and 86 PSPs. They weren't sure which key needed to be changed to allow 1.50 to run on those PSPs, so they changed more than were needed (especially the 2.71 downgrader). It turned out the only one byte of key 5 needed to be changed, and the 3.50 downgrader and the Pandora downgrader now only changes one byte of key 5. If you used one of the older downgraders, you'll need to fix your IdStorage to cure certain issues, one of which is the "can't start the PSP with 12% or less battery" issue.

What you need to do is get KeyCleaner. You'll find it at Chilly Willy's google page here. Run KC and select fix without files. That will correct all but one key corrupted by those early downgraders (2.71, 2.80, and 3.03). You'll find KC now says you have one bad key - either 6 or 0x43. You can get a good key 6 or 0x43 from a good TA-082/86 PSP, or make one with a hex editor and this file. Put just the key you want into a folder inside the KeyCleaner folder and select it as the source of keys for fix with files. KC with then use the file to fix that one bad key. At that point, KC should say "Chilly Willy soft-downed TA-082/86 PSP" for the status. Note - the key file name should be 0x0006.bin or 0x0043.bin, depending on which you need to fix. The name of the folder you put it in inside the keycleaner folder doesn't matter as fix with files allows you to step through all folders inside the KC folder to find the one you want.

At that point, reset your settings to default and you should be good to go. On rare occasions, the settings got so bad, you need to format flash1 to fix the settings. But first you need to make sure your keys are good. Note - if you have a TA-079 or TA-081, none of the above on keys applies as those PSPs didn't need the keys changed to run 1.50. It only applies to TA-082/86s.
vodkkaa
Posts: 10
Joined: Wed Aug 29, 2007 4:43 pm
Location: Adelaide, Australia

Post by vodkkaa »

would redirecting the the firmware to be loaded from the ms be as simple as modifying the the ipl to read from the ms instead of the nand, or would there have to be patching of the the modules (as modules like vshmain specify to load the vsh modules from flash0)
adrahil
Posts: 274
Joined: Thu Mar 16, 2006 1:55 am

Post by adrahil »

It is harder than anything you can do, so forget it. You need to write a MS driver, and a FAT32 overlay as well.
vodkkaa
Posts: 10
Joined: Wed Aug 29, 2007 4:43 pm
Location: Adelaide, Australia

Post by vodkkaa »

adrahil wrote:It is harder than anything you can do, so forget it. You need to write a MS driver, and a FAT32 overlay as well.
i dodnt mean to that it will be easy i meant IF the ipl wa modified to load fw from ms would they still need to be patched to load from ms0:/ instead of flash0:/. like vshmain call on the fonts with the flash0:/ path but if the fw was loaded off the ms would they still look on flash0"/ or wuld they load off the ms
moonlight
Posts: 567
Joined: Wed Oct 26, 2005 7:46 pm

Post by moonlight »

vodkkaa wrote:
adrahil wrote:It is harder than anything you can do, so forget it. You need to write a MS driver, and a FAT32 overlay as well.
i dodnt mean to that it will be easy i meant IF the ipl wa modified to load fw from ms would they still need to be patched to load from ms0:/ instead of flash0:/. like vshmain call on the fonts with the flash0:/ path but if the fw was loaded off the ms would they still look on flash0"/ or wuld they load off the ms
One thing is the driver of the ipl, and other different is the one of the firmware itself.

The recovery ipl/firmware of pandora implements a memory stick raw driver, and a fat driver in the ipl that replace the sony ones, but it also has in the kernel flashemu.prx which redirects flashfat driver accesses to the fatms one, so the answer is: yes, the firmware has to be patched, in this case patched by flashemu.prx, which is specifically for 1.50 kernel.
crazyc
Posts: 408
Joined: Fri Jun 17, 2005 10:13 am

Post by crazyc »

moonlight wrote:The recovery ipl/firmware of pandora implements a memory stick raw driver, and a fat driver in the ipl that replace the sony ones,
You guys know how to access the memory stick directly? The psp linux project could probably use that information.
adrahil
Posts: 274
Joined: Thu Mar 16, 2006 1:55 am

Post by adrahil »

We need to do some cleanup on the driver before release :)
vodkkaa
Posts: 10
Joined: Wed Aug 29, 2007 4:43 pm
Location: Adelaide, Australia

Post by vodkkaa »

adrahil wrote:We need to do some cleanup on the driver before release :)
so you guys are going to release it. I hope m33 or wildc*rd incorporate this into their releases
adrahil
Posts: 274
Joined: Thu Mar 16, 2006 1:55 am

Post by adrahil »

It might be privately released to stop people doing whatever :)
vodkkaa
Posts: 10
Joined: Wed Aug 29, 2007 4:43 pm
Location: Adelaide, Australia

Post by vodkkaa »

adrahil wrote:It might be privately released to stop people doing whatever :)
lol im sure most users would have no idea where to start ;)
crazyc
Posts: 408
Joined: Fri Jun 17, 2005 10:13 am

Post by crazyc »

adrahil wrote:We need to do some cleanup on the driver before release :)
Cool.
so you guys are going to release it. I hope m33 or wildc*rd incorporate this into their releases
I can't imagine how it would be particularly useful for them.
cloudhunter
Posts: 86
Joined: Thu Aug 17, 2006 3:27 am

Post by cloudhunter »

Mainly so that the firmwares can be loaded from the memory stick I imagine.

Still not very useful :)

Cloudy
:)
vodkkaa
Posts: 10
Joined: Wed Aug 29, 2007 4:43 pm
Location: Adelaide, Australia

Post by vodkkaa »

cloudhunter wrote:Mainly so that the firmwares can be loaded from the memory stick I imagine.

Still not very useful :)

Cloudy
also the ablity to load recovery files off the MS in case of a brick and you cant enter recovery menu.
J.F.
Posts: 2906
Joined: Sun Feb 22, 2004 11:41 am

Post by J.F. »

cloudhunter wrote:Mainly so that the firmwares can be loaded from the memory stick I imagine.

Still not very useful :)

Cloudy
It would be most useful for linux. One of the main limitations right now is now mass storage. The current PSP linux sets up a ram disk, then allows you to load (small) stuff from it. This takes memory away from the system that could be used for running things. So a memstick driver is desperately needed for that project.
cloudhunter
Posts: 86
Joined: Thu Aug 17, 2006 3:27 am

Post by cloudhunter »

Yeah, I was just meaning that it'd be practically no use to M33 or WildC*rd :)

Cloudy
:)
KickinAezz
Posts: 328
Joined: Sun Jun 03, 2007 10:05 pm

Post by KickinAezz »

Does act as a "patch" to the original one?

or a totally homebrew one?
SilverSpring
Posts: 110
Joined: Tue Feb 27, 2007 9:43 pm
Contact:

Post by SilverSpring »

KickinAezz wrote:Nothing much to add.. Great job!

---

Some of the (previously) undocumented NIDS are no longer undocumented [we atleast know their names]. Silverspring will be busy :)
Hmm?? Which nids??

Post please :)
KickinAezz
Posts: 328
Joined: Sun Jun 03, 2007 10:05 pm

Post by KickinAezz »

SilverSpring wrote:
KickinAezz wrote:Nothing much to add.. Great job!

---

Some of the (previously) undocumented NIDS are no longer undocumented [we atleast know their names]. Silverspring will be busy :)
Hmm?? Which nids??

Post please :)
I have seen a lot more, you should check personally:

This in 1.5x isn't listed:

sceMesgLed_driver_67A5ECDF = DecryptUpdaterModule

There will sure be lots more...
adrahil
Posts: 274
Joined: Thu Mar 16, 2006 1:55 am

Post by adrahil »

The SHA1 does not correspond :/
Moreover SCE hide the function names, making them obscure ;)
KickinAezz
Posts: 328
Joined: Sun Jun 03, 2007 10:05 pm

Post by KickinAezz »

adrahil wrote:The SHA1 does not correspond :/
Moreover SCE hide the function names, making them obscure ;)

They were in the sample... even more not just 1, that are not named in prx documentation project.

off tpc:
Moonlight = Notbright_Alex ?
adrahil
Posts: 274
Joined: Thu Mar 16, 2006 1:55 am

Post by adrahil »

Yes, moonlight = D_A.

The function names you see used are not the true ones... They are wild guesses. True function names have to have their first 32bits of SHA1 be equal to the NID.
Post Reply