forums.ps2dev.org

The ME firmware was only embedded into those prxs upto 2.00. From 2.50 onwards they are stored in /kd/resource/me_xxx.img No one has really documented the ME firmware extensively. It's quite complicated and relies heavily upon some type of MMIO at 0x4000000 (which on the main CPU is mapped to the ED...

All of those things you mentioned are called "Utilities" and yes they are part of the kernel. It was a way for Sony to provide extra functionality for game developers to use. It's also the reason why a huge 8MB of RAM is reserved for the kernel. There are some samples in the PSPSDK to use ...

So basically you're question is how to get the kernel keys from the IPL? The IPL (on 1K and 2K) and can already be decrypted no problem (which ends up exposing the keys in the plain). Regarding cracking the 3K, it depends what you mean by "cracking" it. The 3K can already run unsigned code...

You are going to have to be more specific, I still don't know what you are talking about. Do you have any more information than just a vague "something we could not do"?

Maybe buffer overflow.

In pl2PackageIndexCreate(), you have filename[64] yet you do snprintf(filename, 256, "./add-ons/%s", entry);

What do you want to do exactly?

The IPL can already be decrypted, unless you are talking about IPL's for PSP 3K's and PSP GO's which we cannot decrypt because we are unable to dump the pre-IPL for those models (which the IPL encryption uses as a seed).

You must be doing something seriously wrong. There is no possible way to get a 'partially' decrypted prx, this is not a stream cipher. The crypto hw used for decryption will either work and give you the correct output, or will fail and change nothing. It won't give a 'partial' result. On top of that...

For 2.00 and 2.50 updaters, psardumper will dump and fully decrypt the IPL. From 2.60 onwards the IPL was further encrypted which used the contents of the pre-IPL as a seed so psardumper cannot fully decrypt those IPL's. For these fw, psardumper will dump the IPL and decrypt the block decryption of...

He is saying the button masks above 0x8000 (ie. the volume up/down, note, screen, etc. buttons) can only be read in kernel mode. Only the the normal keypad buttons (of which are masked to values under 0x8000) are readable when under user mode. It has nothing to do with memory addresses.

Torch wrote:How does the flow of control look like when CFW's custom IPL patches the FW IPL? The FW IPL obviously needs to be decrypted first.

Does not need to be decrypted. The ofw IPL is signed code so it can run as is, ie. it can decrypt itself and decrypt the fw itself when run.

Well, it's a bit more complicated than that. But in general, no, not fully anyway (for recent firmware). For 1.50 updater and below, psardumper won't even dump the IPL let alone decrypt it since the IPL didn't exist in the PSAR back then (it was embedded inside another prx embedded into the updater ...

Yes, mesg_led.prx and kernel modules are decrypted with the IPL. User modules and other encrypted files use mesg_led.prx to decrypt.

They both decrypt PSAR's. sceNwman_driver_9555D68D decrypts internal PSAR's (eg. devkit updaters) sceMesgd_driver_102DC8AF decrypts retail PSAR's (from retail fw updaters) (used only after the PSAR header is 'descrambled' into plaintext first) mesg_led.prx in general is used to decrypt pretty much e...

No, they are C++ too. That is why some of the NID's are so difficult to crack, because of name mangling. An example (from paf.prx): 0xDB230BE1 _ZN3paf8PhWidget7SetTextERKNS_12basic_stringIwNS_11char_traitsIwEENS_9allocatorIwEEEEi which demangled becomes: paf::PhWidget::SetText(paf::basic_string<wcha...

Very nice, you worked out the new-style prxs? Good work.

The work size has to be a multiple of 64. That error means the size arg is incorrect, ie. not a multiple of 64 (I just checked the function).

A lot of error codes are not documented so you have to check the function yourself to see what the error means.

One question: is it legal to post the dump of the pre-IPL? Whether it's legal or not doesn't matter (it is not), it's against the rules of this board. I would edit the above posts before it gets deleted (the disassembly). The fact that you dumped the preipl successfully means that the above instruc...

ne0h wrote:Have anyone the sceNandLib documented ?
Expecially I need:

sceNandEraseBlockWithRetry
sceNandReadPagesRawAll
sceNandReadBlockWithRetry
sceNandWriteBlockWithVerify

Did you at least try searching?

http://forums.ps2dev.org/viewtopic.php?t=6898

I think its vshmain.prx that loads first. Back, before the PSP Fat was release, the testing fw was nothing more than a Hello World program(it was more like DC3-5). Now these days, sony use service mode to check for any type of bug, how the psp operates,etc. Even when testing new developed fw, servi...

It would be better if you just asked for particular functions rather than all the NID's. There are simply too many NID's to list them all. Which sceGu functions do you need? I'll post the 5.00 NID's for them (if that particular function is exported that is, not all of the sceGu API is exposed. Thou...

It would be better if you just asked for particular functions rather than all the NID's. There are simply too many NID's to list them all. Which sceGu functions do you need? I'll post the 5.00 NID's for them (if that particular function is exported that is, not all of the sceGu API is exposed. Thoug...

You should only write if you really know what you are talking about. Things only get added to the sdk when the person knows exactly what is going on. The NID is a "modified" Sha-1 hash of the function name, you have to get the hash of the name, write down the first 8 letters and next rever...

http://forums.ps2dev.org/viewtopic.php?t=11294 Here I've found scePowerIsRequest functions that return 1 if you try to shutdown or suspend the PSP in the both cases ( Power switch and scePower* functions )! I've also finded scePowerCancelRequest function, I've tried it but doesn't works, maybe ther...

By any chance are you suspending the "ScePowerMain" thread? That is the thread that controls the power switch suspend/standby operations.

*nvm wrong button*

They are called stubs, you can grab them here http://silverspring.lan.st/ . Generally, use the 1.50 or 3.52 ones. But the one you got was probably custom made because of changed NID's in 3.71. There is no NID resolver in 3.71 cfw so you had to make custom stubs for the changed NID's for homebrew to ...

Post the actual error output. Anyway, the stub looks incomplete, try this instead: .set noreorder #include "pspstub.s" STUB_START "sceSyscon_driver",0x00010011,0x00010005 STUB_FUNC 0x5EE92F3C,sceSysconSetDebugHandlers Or grab full stubs from http://silverspring.lan.st/ either the...

Yes that result is probably correct.

Though the PSID is not an ASCII string, it's just 16 hex values that is meant to be a unique identifier of the PSP. A serial number if you will.

Define gibberish. Post the results of what you get. It gives you random results each time?

The psid is meant to be "random" looking.

Anyway, the prototype cannot be changed in later fw since it would break compatibility with older games that use it.