wololo.net/talk

No it isn't because it's allocated on RAM, so everytime you do a "hard boot" (which is when you hold the switch more than 3 seconds to power off the psp), or when you're messing with crashes or when you remove your battery, you need to restart the whole process (of triggering the exploit).
But yeah it would help

If you could throw a signed prx in the boot chain then you could do patches to make it a perma cfw. Wouldn't necessarily have to be a vshmain, but you would be better talking to the cfw developers.

kgsws wrote:It is properly signed, but it uses precalculated header from existing demo game(s)

i am a little bit skeptical.
First we don't have any keys for demos.And in my investigation, in order to encrypt and sign code we need to :

1)Encrypt aes_game key and cmac key with kirk key ->ok
2)Xor aes_game_enckey, cmac_enckey, cmac_header_hash and cmac_header_data ->ok
3)Encrypt these datas with kirk7_keydemo -> fail we don't have kirk7_keydemo
...

So i do some test with eboot.bin 2.xx . I can decrypt eboot.bin and encrypt my own code with these keys but sign failed.

Hi.
Long time lurker, first time poster.

After seeing coyotebean's references to Kirk4, Kirk7 and Kirk1 functions calling 0x1e40, 0x1cd0 and 0x24d0 in the SPU disasm, I've been looking for other similar functions that could be calling these handlers. Here're my findings so far: I'm assuming DECRYPT/ENCRYPT_CBC(outbuf, inbuf, insize, key, bits, iv) and HMAC(outbuf, inbuf, insize, key, bits) just for conveniece, as these can mean something completely different.
Most of the params are obtained from the stack and some of them, like unkkey and calcsize, result from several rot and xor operations.

EDIT: By the way, in the posted PSPHEADER struct, is the decryptMode supposed to match the last param passed to sceUtilsBufferCopyWithRange, or is it something else? I've noticed this parameter is mostly 09 in post 2.00 FW, UMD signed EBOOT's, but I've also came across another PSPHEADER struct (with less params), prior to 2.00 FW, that, as decryptMode, can also accept encrypt modes (4 and 6, so far).

is the decryptMode supposed to match the last param passed to sceUtilsBufferCopyWithRange, or is it something else?

That's something else entirely, it's used to determine which file type and where if it can be run depending on where it's located (it's also linked to the mod_attribute field).

chapix wrote: kgsws wrote:It is properly signed, but it uses precalculated header from existing demo game(s)


i am a little bit skeptical.
First we don't have any keys for demos.And in my investigation, in order to encrypt and sign code we need to :

1)Encrypt aes_game key and cmac key with kirk key ->ok
2)Xor aes_game_enckey, cmac_enckey, cmac_header_hash and cmac_header_data ->ok
3)Encrypt these datas with kirk7_keydemo -> fail we don't have kirk7_keydemo
...

So i do some test with eboot.bin 2.xx . I can decrypt eboot.bin and encrypt my own code with these keys but sign failed.

I don't understand either yet but congratulations if you succeeded, i can see how the rest of the header can be re-used but bypassing the data hash doesn't seem to be possible to me as we can't encrypt it so we can't modify it to match our own made data (it's double-checked with a SHA1 but the CMAC hash can be encrypted so is the SHA1's), unless they forgot to check something and there's a hole in the firmware that can be exploited ? But in that case it'll be closed very soon after the exploit is made public. (I didn't check the "locoroco" 2.7 like demos files yet (just noticed they're less tricky to decode), only the newer ones. Did you use one of those ?)

You "just" need to encrypt a "store"/npdrm iso with your homebrew in it as EBOOT.BIN and it'll work.

And because PS3 must decrypt miniS...the npdrm stuff should be in PS3 too...

kgsws wrote:Right now it might not be good idea to release it. I guess sony will do something against it as soon as possible.

Mathieulh wrote:You "just" need to encrypt a "store"/npdrm iso with your homebrew in it as EBOOT.BIN and it'll work.

I don't know how Sony can protect itself from these two issues, they have to maintain compatibility with existing releases. The algorithm & keys cannot be changed.

just Asking But What's About: http://kirk-engine.googlecode.com/svn/trunk/ is that updated?

Well ok, here it comes. Try this one.
tested on fat PSP with OFW 6.35

How?
Simple, notice it contains ~PSP header from demo game (UCES00206), it is exactly same header.
It is easy to craft last 16 bytes of encrypted data block to match header CMAC - yes, that's the trick

There are some strange thigs, it can't run homebrews with bigger executable block (data block does not matter), and because of ~PSP header, it has to match exact size of original game.

This trick might be possible on firmware kernel modules to get permanent HEN on non-pandrorable PSPs, i was not able to do it but i was not trying that much.

PS: i am not only one who found this trick