This forum uses cookies
This forum makes use of cookies to store your login information if you are registered, and your last visit if you are not. Cookies are small text documents stored on your computer; the cookies set by this forum can only be used on this website and pose no security risk. Cookies on this forum also track the specific topics you have read and when you last read them. Please confirm whether you accept or reject these cookies being set.

A cookie will be stored in your browser regardless of choice to prevent you being asked this question again. You will be able to change your cookie settings at any time using the link in the footer.

Thread Rating:
  • 1 Vote(s) - 5 Average
  • 1
  • 2
  • 3
  • 4
  • 5
Savedata Encryption/Decryption
#91
Hykem doesn't have direct control over the buildbot. Either the buildbot has broken down (in which case someone will need to contact Orphis) or there was an error in building JPCSP with Hykem's latest changes.
Reply
#92
Thank you so much... But as I said before I don't have test environment of jpcsp.
Do savedatas from r3436 are working on real PSP?
Reply
#93
(01-15-2014, 09:22 PM)DragonNeos Wrote: Hykem doesn't have direct control over the buildbot. Either the buildbot has broken down (in which case someone will need to contact Orphis) or there was an error in building JPCSP with Hykem's latest changes.

Sorry about that. I've contacted Orphis and is indeed a SVN issue in the buildbot.
Should be fixed tonight.

(01-16-2014, 09:35 AM)popsdeco Wrote: Thank you so much... But as I said before I don't have test environment of jpcsp.
Do savedatas from r3436 are working on real PSP?

Unfortunately I couldn't test the changes with a real PSP (I currently don't have mine available). But I did compare the hashing algorithm with PPSSPP and the results appear identical (using the same SHA-1 seed, otherwise the results would always be random).
Reply
#94
Loading SoraYume savefile still gives the error message in r3437.
Reply
#95
(01-17-2014, 01:50 AM)akaya Wrote: Loading SoraYume savefile still gives the error message in r3437.

If you try read SoraYume savefile in PSP or PPSSPP, it will ask you : "Do you want to read this save" But the old jpcsp skip this. The new jpcsp, however will try ask you "Do you want to read this save" like psp. That may be what cause this bug.

The another bug is if you try to delete in you psp, it also ask you : "Do you want to delete this save" the new jpcsp will skip asking and delete savedata Without asking.
and you should not try delete game save which jpcsp is already run it, even the game ask you to do that. jpcsp can not delete that save, or jpcsp will stop there. (Endless loop)

I am not good at English, I hope you know what I say.
Reply
#96
(01-16-2014, 03:06 PM)Hykem Wrote:
(01-16-2014, 09:35 AM)popsdeco Wrote: Thank you so much... But as I said before I don't have test environment of jpcsp.
Do savedatas from r3436 are working on real PSP?

Unfortunately I couldn't test the changes with a real PSP (I currently don't have mine available). But I did compare the hashing algorithm with PPSSPP and the results appear identical (using the same SHA-1 seed, otherwise the results would always be random).
Oh oh oh... Should I switch sce functions to this?
https://github.com/hrydgard/ppsspp/blob/...hnnlsv.cpp
Though it seems I still use savedata side functions from jpcsp :p
Reply
#97
(01-17-2014, 11:33 AM)popsdeco Wrote:
(01-16-2014, 03:06 PM)Hykem Wrote:
(01-16-2014, 09:35 AM)popsdeco Wrote: Thank you so much... But as I said before I don't have test environment of jpcsp.
Do savedatas from r3436 are working on real PSP?

Unfortunately I couldn't test the changes with a real PSP (I currently don't have mine available). But I did compare the hashing algorithm with PPSSPP and the results appear identical (using the same SHA-1 seed, otherwise the results would always be random).
Oh oh oh... Should I switch sce functions to this?
https://github.com/hrydgard/ppsspp/blob/...hnnlsv.cpp
Though it seems I still use savedata side functions from jpcsp :p

Right now the algorithm is exactly the same for PPSSPP and JPCSP, but since you're writing the application in C/C++ I strongly recommend using the PPSSPP code because it is much easier to adapt (specially since it was written to use the kirk-engine). The only differences are in the second PARAM.SFO hash, because JPCSP tries to generate it while PPSSPP can't. However, this hash may not be necessary at all and I'm currently only investigating it due to some games having issues with SAVEDATA authentication (e.g.: God Eater 2).
Reply
#98
(01-17-2014, 03:45 PM)Hykem Wrote: The only differences are in the second PARAM.SFO hash, because JPCSP tries to generate it while PPSSPP can't.

Yes. Although https://github.com/cielavenir/psp-saveda...its/master doesn't work well yet, I hope you can win.
Reply
#99
In r3438 the issue with SoraYume's SAVEDATA should now be fixed. Also, deleting the SAVEDATA should no longer cause an infinite loop.
I've also changed the PARAM.SFO hashing to match the one used by PPSSPP (always uses mode 0x21).
Could you all please test these issues again? Thanks!
Reply
(01-18-2014, 05:54 PM)Hykem Wrote: In r3438 the issue with SoraYume's SAVEDATA should now be fixed. Also, deleting the SAVEDATA should no longer cause an infinite loop.
I've also changed the PARAM.SFO hashing to match the one used by PPSSPP (always uses mode 0x21).
Could you all please test these issues again? Thanks!

Yes, it's now fixed. Thank you so much, Hykem.
Reply


Forum Jump:


Users browsing this thread: 2 Guest(s)