EBOOT.BIN Decryption

[tr4nquility]

Oh, by the way, as of r2038, it should now be possible to decrypt Dissidia on the fly. It seems this game uses an unknown MIPS relocation that has been adapted by the internal PSP's processor, Allegrex.
Apparently, index 255/0xFF is actually a stop code.

Yup. It really works.. Thanks
I'll post in its special thread for its problems....

[Hykem]

Oh, by the way, as of r2038, it should now be possible to decrypt Dissidia on the fly. It seems this game uses an unknown MIPS relocation that has been adapted by the internal PSP's processor, Allegrex.
Apparently, index 255/0xFF is actually a stop code.

@Kyotoo: This may also represent a solution for K-ON!, Kyotoo.

Yup, Dissidia and a few other games that suffered the 255 IndexOutOfBoundsException errors are now working after your fix. Now I can finally remove my hack to get those games to work. As a matter of fact, I had to remove my hack since it conflicted with your fix when I updated the source through svn, hehe. I mentioned my hack a while back on this post: http://www.emunewz.net/forum/showthread....27#pid9727 but I guess people missed it.

Anyway, great work Hykem.

I did noticed it, but up until now I couldn't prove it. Fortunately, "Final Fantasy Dissidia" explicitly uses 0xFF as a MIPS relocation, which leaves no other option than accept that the PSP has to interpret this.
What is odd is that manually decrypted files do not have these relocations in them, which suggest that they get automatically removed.
I've traced this down to a correlation with the ~PSP header's struct field comp_mod_attr which, for these games, is 0x00 (0x01 is for PRX and 0x02 for ELF, but 0x00 is just unknown). Could it be some sort of dev level? Maybe an attribute that lets the PSP crash and report compilation errors...

[Shina]

"Savedata decryption"

This will decrypt saves to SSData.bin?

[Hykem]

"Savedata decryption"

This will decrypt saves to SSData.bin?

No, that feature handles the saves as if they were being sent to a real PSP. If you toggle that option, you will be able to use savedata from gamefaqs.com (which are encrypted due to being directly obtained from a PSP), for example.

[LeaT]

As of r1971, a lot of things have been fixed. Could everyone please try testing again your encrypted games? Thanks!
Specially games like Dissidia or Kingdom Hearts which seem to be very prone to security trickery.

I guess I should add some of my experiences here about Dissidia. I've tried two versions, 0.6 r2298 and r1772. Same Dissidia files. I've also written about this in the Dissidia thread, but maybe this will also help out by writing it here.

Decryption of the game seems to work fine, however, I can actually never play the game. I run two different versions, one with the Japanese voice acting with English text (still English voice acting in cinematics though) and one with English voice acting and English text. They work very similar and I can start both just fine, however, once past the first menu screens after account creation, they start to deviate. First of all, none of the games display any visible text. I've tried with various shaders to see if the issue is that the text would be on a different graphics layer (that's how it looks like pretty much) but to no avail. The text does show in rev 1772, which makes it all confusing. None of the installs are tampered with and are fresh.

With the Japanese voice over version, I always see the introduction movie but when the movie ends I get stuck at a white screen with 30 or so FPS in rev 2298. If I use the normal English version, I see no introduction movie and am immediately taken to the main menu selection screen but as soon as I start any kind of game I get stuck at the same white screen.

If I do the same regardless of version in rev 1772 I get to see the cinematic, get to the main play menu and I can make a game but then I get the fake MPEG picture.

I'm running 32 bit on both versions.

I have read most tips suggested regarding the white screen such as installing Xuggle and so on but it doesn't seem to help. This is getting somewhat frustrating Seeing I at least get some progress in rev 1772 I have been thinking whether it is a security issue for rev 2298 if it wasn't for the fact that it behaves the same regardless if the game is decrypted or not :S I should add that I get no error text running the log neither about the text issue nor the white screen.

[takumiong]

As of r1964, a new functionality has been added to JPCSP: the ability to load encrypted EBOOT's.
This comes up as a result from the recent findings about KIRK and the PSP's crypto functionalities.

As you can see, a CryptoEngine has been added to JPCSP, and it's final goal is to act as a KIRK emulator.
Currently, the CryptoEngine is capable of emulating KIRK's commands 1, 4, 7, 10 and 11 (10 still has a few issues to sort out) and it also has a partial implementation of PRXDecrypter's main routine.
Thanks to this, it should now be possible to load ISO/CSO images that previously contained encrypted EBOOT.BIN files.

There're already more additions being worked on, and the task list already counts with:
- PRX decryption version 1 (for firmware 1.00 to 2.80 EBOOTs);
- Savedata decryption;
- PGD decryption.

Please feel free to post any suggestions or test reports as a reply to this post.

how to put the code into it??

[DarcLeo]

As of r1971, a lot of things have been fixed. Could everyone please try testing again your encrypted games? Thanks!
Specially games like Dissidia or Kingdom Hearts which seem to be very prone to security trickery.

file:///C:/Users/DarcLeo/Downloads/log/log.html this is what i get when i open it?

[Zekro]

Dude that rev is outdated,download the newest one from here http://buildbot.orphis.net/jpcsp/

[Hykem]

As of r3404 the PRX decryption has been completely redesigned supporting now all PRX types (game, firmware, update, etc.).
PRX decryption is currently only being used for EBOOT.BIN files and partially for scePauth.
Unfortunately, scePauth still requires an undiscovered KIRK 7 key (seed 0x47).