+- EmuNewz Network (https://www.emunewz.net/forum)
+-- Forum: PSP Emulation (https://www.emunewz.net/forum/forumdisplay.php?fid=191)
+--- Forum: JPCSP Official Forum (https://www.emunewz.net/forum/forumdisplay.php?fid=51)
+---- Forum: svn trunk discussion (https://www.emunewz.net/forum/forumdisplay.php?fid=56)
+---- Thread: EBOOT.BIN Decryption (/showthread.php?tid=3425)
RE: EBOOT.BIN Decryption - Kyotoo - 03-14-2011
Some problem when load "K-ON! Houkago Live!!" [ULJM-05709] (fw 6.31) "Critical Error : Index 255, Size 3". With decrypted eboot works fine.
RE: EBOOT.BIN Decryption - Hykem - 03-14-2011
@Kyotoo and tr4nquility:
Looks like those games share a common issue. They're attempting to use the wrong version of PRX decryption. I'll have to look deeper into this, but atleast for Dissidia this should be easy to trace and fix. Unfortunately, K-ON is probably using a new encryption method since it belongs to firmware 6.31. All games after firmware 6.30 are using a new encryption mechanism that still haven't been figured out due to the inability to analize the new firmware modules, which are now ECDSA protected.
RE: EBOOT.BIN Decryption - tr4nquility - 03-17-2011
In r2029, Dissidia decryption error has gone... It can be loaded. But nothing happened when I click "Run". JPCSP freezes. I've tried to use EBOOT.bin produced from this revision to r2016, and yields the same result. Nothing happened upon "Run". Here is DEBUG log
Code:
55866 [root] DEBUG hle.ThreadManForUser - hleKernelDelayThread micros=200, callbacks=falseCode:
062 [GUI] INFO emu - Java version: 1.6.0_24 (1.6.0_24-b07)
4062 [GUI] INFO emu - Jpcsp v0.6 2029
4062 [GUI] INFO emu - UMD param.sfo :
BOOTABLE = 1
CATEGORY = UG
DISC_ID = ULUS10437
DISC_NUMBER = 1
DISC_TOTAL = 1
DISC_VERSION = 1.00
PARENTAL_LEVEL = 5
PSP_SYSTEM_VER = 5.50
REGION = 32768
TITLE = DISSIDIA FINAL FANTASY
probably homebrew? false
4072 [GUI] INFO emu - Loading global compatibility settings
4072 [GUI] INFO ge - Only GE Graphics: false
4072 [GUI] INFO hle.sceMpeg - Media Engine enabled
4102 [GUI] INFO ge - Using Async Vertex Cache
4102 [GUI] INFO hle.sceAudio - Audio ChReserve disabled: false
4102 [GUI] INFO hle.sceAudio - Audio Blocking disabled: false
4102 [GUI] INFO hle.ThreadManForUser - Audio threads disabled: false
4102 [GUI] INFO memory - Ignore invalid memory access: true
4272 [GUI] INFO emu - Unrecognized file format
4272 [GUI] INFO emu - File magic 00 00 00 00
4352 [GUI] WARN emu - Encrypted file detected! (~PSP)
4352 [GUI] INFO emu - Calling crypto engine for PRX.
15432 [GUI] WARN emu - .shstrtab section not found
15472 [GUI] INFO emu - Found ModuleInfo name:' version:0000 attr:00000000 gp:00000000
15472 [GUI] INFO emu - Found 0 imports from 0 modules
15472 [GUI] INFO emu - 0 NIDS mapped
15482 [GUI] INFO hle.sceDisplay - Saving GE to Textures
15560 [GUI] INFO hle - Using the external audio decoder (SonicStage)
15767 [GUI] INFO hle.IoFileMgrForUser - pspiofilemgr - filepath disc0/
15799 [GUI] INFO ge - Using RenderingEngineLwjgl31
15799 [GUI] INFO ge - OpenGL version: 3.3.0
15800 [GUI] INFO ge - Shading Language version: 3.30 NVIDIA via Cg compiler
15800 [GUI] INFO ge - GL_CONTEXT_FLAGS; 0x0
15800 [GUI] INFO ge - GL_CONTEXT_PROFILE_MASK: 0x0
15898 [GUI] INFO ge - Using VBO
15903 [GUI] INFO ge - Using VAO (Vertex Array Object)
15903 [GUI] INFO ge - Using shaders with Skinning
15903 [GUI] INFO ge - Using dynamic shaders
15904 [GUI] INFO ge - Using Geometry Shader for SPRITES
15905 [GUI] INFO ge - Using Uniform Buffer Object (UBO)
15906 [GUI] INFO ge - Using Native Color Lookup Tables (CLUT)
16091 [GUI] INFO ge - Using Geometry Shader shader-150.geomAnd also, KH:BBS return this error upon "Run", though PGD decryption still works...
Code:
java.lang.RuntimeException: Cannot find executable
at jpcsp.Allegrex.compiler.RuntimeContext.jumpCall(RuntimeContext.java:1
13)
at jpcsp.Allegrex.compiler.RuntimeContext.call(RuntimeContext.java:195)
at _S1_3_883A464.s(_S1_3_883A464.java:112)
at _S1_3_883A138.s(_S1_3_883A138.java:72)
at _S1_3_8843B90.s8843c38(_S1_3_8843B90.java:184)
at _S1_3_8843B90.s(_S1_3_8843B90.java:168)
at _S1_3_8843074.s8843370(_S1_3_8843074.java:804)
at _S1_3_8843074.s(_S1_3_8843074.java:764)
at _S1_3_8842344.s(_S1_3_8842344.java:104)
at _S1_3_88D8E64.s(_S1_3_88D8E64.java:68)
at _S1_3_88D8E64.exec(_S1_3_88D8E64.java)
at jpcsp.Allegrex.compiler.RuntimeContext.jumpCall(RuntimeContext.java:1
16)
at jpcsp.Allegrex.compiler.RuntimeContext.call(RuntimeContext.java:195)
at _S1_3_8B15350.s(_S1_3_8B15350.java:88)
at _S1_3_8B15350.exec(_S1_3_8B15350.java)
at jpcsp.Allegrex.compiler.RuntimeContext.jumpCall(RuntimeContext.java:1
16)
at jpcsp.Allegrex.compiler.RuntimeContext.call(RuntimeContext.java:195)
at _S1_3_88EE418.s(_S1_3_88EE418.java:100)
at _S1_3_88EE418.exec(_S1_3_88EE418.java)
at jpcsp.Allegrex.compiler.RuntimeContext.jumpCall(RuntimeContext.java:1
16)
at jpcsp.Allegrex.compiler.RuntimeContext.call(RuntimeContext.java:195)
at _S1_3_88D79FC.s(_S1_3_88D79FC.java:64)
at _S1_3_88D79FC.exec(_S1_3_88D79FC.java)
at jpcsp.Allegrex.compiler.RuntimeContext.jumpCall(RuntimeContext.java:1
16)
at jpcsp.Allegrex.compiler.RuntimeContext.call(RuntimeContext.java:195)
at _S1_3_88340E0.s(_S1_3_88340E0.java:84)
at _S1_3_88340E0.exec(_S1_3_88340E0.java)
at jpcsp.Allegrex.compiler.RuntimeContext.jumpCall(RuntimeContext.java:1
16)
at jpcsp.Allegrex.compiler.RuntimeContext.call(RuntimeContext.java:195)
at _S1_3_88349DC.s(_S1_3_88349DC.java:80)
at _S1_3_88349DC.exec(_S1_3_88349DC.java)
at jpcsp.Allegrex.compiler.RuntimeContext.jumpCall(RuntimeContext.java:1
16)
at jpcsp.Allegrex.compiler.RuntimeContext.jump(RuntimeContext.java:154)
at _S1_3_8833F68.s(_S1_3_8833F68.java:236)
at _S1_3_88341CC.s(_S1_3_88341CC.java:76)
at _S1_3_8808AD0.s(_S1_3_8808AD0.java:28)
at _S1_3_8808AD0.exec(_S1_3_8808AD0.java)
at jpcsp.Allegrex.compiler.RuntimeContext.jumpCall(RuntimeContext.java:1
16)
at jpcsp.Allegrex.compiler.RuntimeContext.jump(RuntimeContext.java:154)
at _S1_3_8833F68.s(_S1_3_8833F68.java:236)
at _S1_3_88341CC.s(_S1_3_88341CC.java:76)
at _S1_3_8A8BB80.s(_S1_3_8A8BB80.java:316)
at _S1_3_8A8BB80.exec(_S1_3_8A8BB80.java)
at jpcsp.Allegrex.compiler.RuntimeContext.jumpCall(RuntimeContext.java:1
16)
at jpcsp.Allegrex.compiler.RuntimeContext.call(RuntimeContext.java:195)
at _S1_3_8834288.s88342f0(_S1_3_8834288.java:144)
at _S1_3_8834288.s(_S1_3_8834288.java:104)
at _S1_3_8834288.exec(_S1_3_8834288.java)
at jpcsp.Allegrex.compiler.RuntimeContext.jumpCall(RuntimeContext.java:1
16)
at jpcsp.Allegrex.compiler.RuntimeContext.call(RuntimeContext.java:195)
at _S1_3_8834950.s(_S1_3_8834950.java:136)
at _S1_3_8808960.s8808ac4(_S1_3_8808960.java:364)
at _S1_3_8808960.s(_S1_3_8808960.java:356)
at _S1_3_8808960.exec(_S1_3_8808960.java)
at jpcsp.Allegrex.compiler.RuntimeContext.jumpCall(RuntimeContext.java:1
16)
at jpcsp.Allegrex.compiler.RuntimeContext.call(RuntimeContext.java:195)
at _S1_3_8834288.s88342f0(_S1_3_8834288.java:144)
at _S1_3_8834288.s(_S1_3_8834288.java:104)
at _S1_3_8834288.exec(_S1_3_8834288.java)
at jpcsp.Allegrex.compiler.RuntimeContext.jumpCall(RuntimeContext.java:1
16)
at jpcsp.Allegrex.compiler.RuntimeContext.call(RuntimeContext.java:195)
at _S1_3_8834950.s(_S1_3_8834950.java:136)
at _S1_3_8835018.s(_S1_3_8835018.java:32)
at _S1_3_88075FC.s(_S1_3_88075FC.java:268)
at _S1_3_8A8BAE4.s(_S1_3_8A8BAE4.java:56)
at _S1_3_8A8BE6C.s(_S1_3_8A8BE6C.java:240)
at _S1_3_8A8BE6C.exec(_S1_3_8A8BE6C.java)
at jpcsp.Allegrex.compiler.RuntimeContext.runThread(RuntimeContext.java:
701)
at jpcsp.Allegrex.compiler.RuntimeThread.run(RuntimeThread.java:51)RE: EBOOT.BIN Decryption - Hykem - 03-18-2011
Ah, yes. It looks like the crypto classes aren't reacting as expected to i30817's code optimizations.
However, the good news is that I found out what was wrong with "Dissidia", but I'll have to temporarily revert all those commits to get the CryptoEngine working again...
RE: EBOOT.BIN Decryption - tr4nquility - 03-19-2011
(03-18-2011, 11:18 PM)Hykem Wrote: However, the good news is that I found out what was wrong with "Dissidia", but I'll have to temporarily revert all those commits to get the CryptoEngine working again...Thanks for the good news
Then, one more question....
After playing for 2 hours, Java.exe *32 consumes a huge amount of memory... about 1.869.540 K ... In the end, it freezes with a log stating that I've run out of memory. Is there any chance of improving JPCSP so that it will take less memory in the long run ?
RE: EBOOT.BIN Decryption - Hykem - 03-19-2011
(03-19-2011, 06:21 AM)tr4nquility Wrote:(03-18-2011, 11:18 PM)Hykem Wrote: However, the good news is that I found out what was wrong with "Dissidia", but I'll have to temporarily revert all those commits to get the CryptoEngine working again...Thanks for the good news
Then, one more question....
After playing for 2 hours, Java.exe *32 consumes a huge amount of memory... about 1.869.540 K ... In the end, it freezes with a log stating that I've run out of memory. Is there any chance of improving JPCSP so that it will take less memory in the long run ?
Hmm, that's odd. A Java application should never consume that much in a long run. I've already managed to get JPCSP running for about 5 hours with a 3D heavy application and it never did that...
Could you please post your PC specs?
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.
RE: EBOOT.BIN Decryption - hyakki - 03-19-2011
(03-19-2011, 06:21 AM)tr4nquility Wrote: After playing for 2 hours, Java.exe *32 consumes a huge amount of memory... about 1.869.540 K ... In the end, it freezes with a log stating that I've run out of memory. Is there any chance of improving JPCSP so that it will take less memory in the long run ?did you mess with the -xmx value? since usually that's what limits java memory usage (ie 1024M = 1 gig ram, so a value like 1800M would be allowed to allocate 1.8 gigs of ram)
also disable vertex cache, that can cause most of the out of memory errors
RE: EBOOT.BIN Decryption - tr4nquility - 03-19-2011
my pc specs :
Code:
Running Win7 64-bit Ultimate with Java 32-bit
Core 2 Quad Q9400 @ 2.66 GHz
Gigabyte 9800GT @1GB
4GB RAM
MB = MSI - 7514I messed with -xmx value only when JPCSP still in its 0.5v .... Now I always used default BAT file.
And, thanks for your tips Hyakki. It does help, though just a little... Memory consumption increases in slower rate than before.. Yet eventually it will hit that "huge" amount if I don't restart the emulator every now and then...
Using option : Only GE + Save GE Screen to Texture while disabling other video options does help a lot for smoother gameplay, though it may have stuttering effects...
RE: EBOOT.BIN Decryption - Itaru - 03-19-2011
(03-19-2011, 07:09 AM)Hykem Wrote: 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.php?tid=3425&pid=9727#pid9727 but I guess people missed it.
Anyway, great work Hykem.
RE: EBOOT.BIN Decryption - skyeyes83 - 03-19-2011
There are also improvement on Dissidia 012,you can get ingame,text now are correct,the video works well ( at the end of the video jpcps stop working) if you jump the video you'll get ingame but crash after the fisrt loading screen (tomorrow i'll post screen and log) anyway great improvement Hykem...