PS3 packages and how it leads to PSP signing

[Davee]

There are many PSP executables that are user signed. Typically with a ~PSP header though.

You're implying that this won't be so easy to patch for Sony?

Fail on my end, I meant that there are many ELF PSP executables that are user signed. Unfortunately, I only recall those with a disc0 API encryption.

Advertising

[coyotebean]

Of course. I was trying it on 01g, but i had to reflash FW many times.
I guess it has to be GZipped (or another compression), but i don't know how to GZip it for PSP kernel.

Also, IIRC, pspbtcnfXXX.bin contains the bytes from 0x150-0x15F to validate the file being load.
EDIT: just chcked, it is 0x140-014F, not 0x150-0x15F. So nothing to worry.

Advertising

[jigsaw]

I guess it's possible to sign TN HEN since it's just another user mode homebrew, although vsh exploit and kernel exploit are used.
Actually it starts up and prints log - just one line "start...". But then it fails in different ways, either shutdown or freeze PSP.
Obviously sceUtilityHtmlViewerInitStart and sceKernelDelayThread are executed, but then search for string sceVshHV breaks sth. Looks to be caused by illegal access to some address?

So the question is: will encryption modify the memory layout of prx?


EDITED: I applied -mno-gpopt in my makefile so I think it's not relocation type related.

[bbtgp]

I think it kills its self with a 1MB memory set, looking at the reverses around the net.

[jigsaw]

I think it kills its self with a 1MB memory set, looking at the reverses around the net.

Thanks for reply. I don't quite get it - where is the 1MB memory set? I think I'm the only source of "reverses around the net" - http://code.google.com/p/hen/

[bbtgp]

Sorry, i didn't see your post before i edited..... The kernel loads them around 0x08804000, HBL is much higher in memory.

EDIT: from that link its on line 215. There's also another reverse here viewtopic.php?p=11128#p11128

[Mathieulh]

Just to confirm, you can still "sign" things for 6.37

[m0skit0]

About signed TN HEN: maybe kernel refuses to resolve some imports, like VSH's, since it's not running from VSH mode? This doesn't happen on HBL since it's HBL who resolves the imports.

[JJS]

I can confirm what bbtgp writes above, the TN HEN loader simply overwrites itself with zeros because it assumes to be loaded to 0x08900000 by HBL whereas it is really loaded to 0x08804000 by the firmware. Besides, wouldn't it be better to discuss the HEN in its own topic?

Edit: Corrected the address.

[m0skit0]

the TN HEN loader simply overwrites itself with zeros because it assumes to be loaded to 0x08900000 by HBL whereas it is really loaded to 0x08840000 by the firmware

Such careless programming... And yes, I think TN HEN can be discussed on its own thread/forum.