Now I'm 100%ly sure! Yes - this is the key to 6.20 gaming.
This is what I've figured out so far by doing some live-debugging...
6.20+ FW psps launch OPNSSMP.BIN BEFORE (in addition to) EBOOT.BIN.
OPNSSMP.BIN is a self-extracting executeable. Very much like the Code-Protectors we know from PC, like Themida, etc...
That pack the actual code... and only provide a minimal readable code that REALLY unpacks the code and then launches it...
This is a similiar case here...
The fully decrypted OPNSSMP.BIN is made up of 2 parts...
72 bytes of code - uncompressed - unencrypted - this code makes up the module_load function i've reversed...
At first I thought I made a mistake with the second firmware call argument 320...
But I didnt - I was right...
Now I will tell you guys what this code really does... the first function call - im not too sure about yet... I guess it setups some place in memory to use as buffer for the kirk engine. (the stuff the psp uses to crypt and decrypt ****...)
The second function called - ONLY IF 18 IS PASSED TO module_load as the first unsigned integer of argp - will call the kirk engine itself and now's the clue as to what the 320 means...
320 is a RELATIVE address to the beginning of the .text segment of OPNSSMP.BIN... so the only fault was that i didn't add the base addr to it...
This pointer points to 120 bytes of ENCRYPTED MEMORY! inside of OPNSSMP.BIN - yes - its encrypted - in case you guys are interested you can decrypt OPNSSMP.BIN yourself and disassemble it... its at the relative address - you guessed it - 320!
Anyway, the call to the second function (kirk engine) - decrypts this 120 bytes of encrypted memory - and thus makes the unencrypted memory readable to EBOOT.BIN for various "checks".
This is possible because the PSP has no MMU (memory management unit) built in... this means every usermode module can access every other usermode modules memory... which Sony uses to read the now-decrypted kirk memory inside OPNSSMP.BIN for its various checks...
Due to us not loading OPNSSMP.BIN EVER! This memory spot stays unitialized with unproper values... and well... EBOOT.BIN gives you the nice bsod.
Again - to sum it up for those that still didnt get it...
OPNSSMP.BIN = 1 function + 120 bytes encrypted shared memory
this function (ive reversed it for you guys a few posts above this one) - executes the psp kirk crypt engine and decrypts the memory.
because opnssmp.bin has the "stay in memory" flag in its module settings... it wont get unloaded either... as long as the game is running... so the eboot.bin - on 6.20 fws... has full access to those 120 decrypted bytes for its checks.
and last but not least... now that the 6.20 mystery has been solved...
Someone wants to take over?
Interesting, isn't it?
What do you guys think, smack or legit?
EDIT:
He just posted this:
QUOTETo tell the truth I'm writing this message here from my workstation os (linux).
So yeah. I'm trying to build a OPNSSMP.BIN loader.
If my theory about the new protection is right then this should solve all the problems at hand.