Gaming does god eater work?

[iban88]

it says its 6.20. im on the last gen d that was made. will god eater run on it or not?

 

[prowler]

no.

 

[iban88]

ima be busting heads if dantes inferno and blazblue come with with that 6.20. -_-

 

[prowler]

well get busting heads

 

[iban88]

wait... they are going to be 6.20 0_0

 

[prowler]

most likely, they don't like people stealing their games..

 

[iban88]

then i guess only getting another psp would help. i dont mind buying games but not if i cant play them

 

[steve-p]

God Eater has 2 Eboot's,
if you decrypt both it may run on other firmware, but the 2nd is over 140meg and it's too big for edecrypt to handle.

 

[iban88]

i was looking forward to it to. is there going to be a new update so cfw can play 6.20 games??

 

[clegion]

we don't know

 

[steve-p]

i just want a decrypter that can handle large eboot's
preferably with the keys in a plaintext config file.

if you get cf6.20 then they will just release games with 6.21 - you know that.
better to decrypt & deprotect them.

God Eater first eboot is interesting,
i decrypted it and it looks like it's packed with debug data.
i can see they compiled it with GCC and it's C++ for example.

 

[dirty_harry]

Some interesting stuff I found from a dude called "coldbird" from another forum - one which I cannot mention here.

This is what he posted yesterday:

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.

I'm not getting my hopes up on this. Let's see how it unfolds.

 

[prowler]

Its bullshit IMO.
Someone who we don't even know claiming that.

Its the DSi SD card hack all over again.

 

[Zeroneo]

Its bullshit IMO.
Someone who we don't even know claiming that.

Its the DSi SD card hack all over again.

You can trust ColdBird. He has been in PSP hacking for a while now.

 

[dirty_harry]

If what he says is true, having to run a plug-in running at high priority constantly during game-play, wouldn't we (theoretically) take a performance hit?

 

[xist]

From that description It seems just to be bumping something into the PSP's RAM which will allow it to check for encrypted data as and when required (AP Checks). As i understand that, it depends how much RAM is allocated to the task, but this seems to be a one time use thing that pushes the OPNSSMP.BIN into RAM (and once active it'll work just like it's intended and remain there). If the game runs fine on OFW from the UMD with that function active, i don't see why it would work any differently with what Coldbird proposes.

...and you can bet GEN TEAM (being the only one active at the moment) will steal this if it works and implement it within the firmware itself so that a plugin is unnecessary. Par for the course really...

 

[dirty_harry]

I absolutely agree that GEN will steal this. I wonder if it will work on M33...

Heck, I wonder if it will work at all!

 

[Genomiks]

Please don't insult GEN team if you know nothing about them. They have never stoled anything, so pick your words carefully...

 

[Jamstruth]

Meh, I'd say its likely that they will take the hack and use it if they see it as the best feasible route. Whether or not they will credit the original maker is soemthing else entirely.

 

[dirty_harry]

Stealing/taking with or without permission. It's all the same. I do not insult or disrespect GEN, nor do I blame them if they do take a possible fix. What is wrong with people, I don't care if GEN is insulted by my words, if they do steal this without permission from the author, that is despicable and I will criticize them for it. You should choose your words wisely, Genomiks. For they may be your last.....




as king.