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

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).

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 ?)

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.