Gods Eater Burst Broken Savegames

[Daykod]

Getting a weird error when loading my saves created on my actual PSP and it won't actually load them. It just goes back to the main menu whenever I try to load a save that wasn't created in ppsspp. They definitely work on my PSP though. Took a screenshot of the log right as it went back into the main menu. It's a bit noisy because of the atrac spam.

[thedax]

IIRC PPSSPP has never loaded saves for this game created by a real PSP. As for why, my money's on missing sceJPEG stuff, but I could be wrong.

[unknownbrackets]

Hmm, it says "hash broken". It might've hashed the save with your PSP's nickname or the PSID.

Does the save in question work on any PSP, e.g. not just yours?

-[Unknown]

[thedax]

@Suleks Could you upload the save to a site like mediafire? I'd like to test something.

[Daykod]

I don't have another PSP on hand to test. It might be worth noting that the DLC didn't load when I copied it to the PPSSPP's memstick either. Something about a character mismatch. I dunno why it loads the saves made in ppsspp though. It's still writing a JPEG for the avatar because the avatar loads on the real PSP. Here's a link to the saves if you'd wanna check them out. https://dl.dropboxusercontent.com/u/38823080/SAVEDATA.zip

EDIT 1 Here's the last part of the log when loading a save game made in PPSSPP sort of successfully with the dlc

[unknownbrackets]

You may have to copy the files from PSP/LICENSE (or whereever, I forget) to the PPSSPP memstick/ directory as well for the DLC.

-[Unknown]

[Daykod]

Copying PSP/LICENSE didn't seem to do much.

[unknownbrackets]

Dunno then, see #1916. Maybe there's DLC files you also need to copy.

-[Unknown]

[Daykod]

I figured it might be related if there's some kind of DRM thing going on. Anyway I just double checked the savegames and the one created on PPSSPP actually doesn't have an avatar loading on my real PSP. So it might be the JPEG breaking it like @thedax mentioned.

[thedax]

Does the save created by PPSSPP actually load and go in-game on your PSP? Also, if you then save the game on your PSP and re-load it in PPSSPP, does it kick you back to the main menu?

[Daykod]

Yeah, the PPSSPP game save loads on the real PSP. Saving after loading it onto the PSP did seem to break it. Now it behaves like the real PSP savegames. The same error message about hash broken appears in the log

[thedax]

I just did a test and yes, savedata are indeed transferable between real PSPs. Is it safe to say then that the game may be hashing the avatar image created by scejpeg?

[mr-chya]

I just tested the save games available on gamefaqs which I assume were made with a real psp and they worked correctly so I am not sure that is it. However with that said one file I noticed that was present inside the gamefaqs saves and not present in any other is a file named C00.bin.

[Daykod]

Well I can't explain this. They did actually load in ppsspp and they have avatars. What's even in these save files?

[Daykod]

Still dunno what's up with this save file. I'm checking out the one with just C00.bin and it seems to be edited. Has stupid amount of money with top end gear without having any missions clear. Removing C00.bin causes the game on ppsspp to read it as corrupted but it "recovers" it and works fine afterwards. It doesn't rewrite C00.bin to the memstick. I tried it with my real PSP and ppsspp. I didn't see the bin get touched in the log though. As for the dlc, it seems it's generating a key and using it to find a file in PSP/LICENSE. It generated a couple and none of them matched the one I have for it. Wonder if the CFW i'm using on my real PSP is doing something with that.

[Daykod]

Just to make sure nothing weird was going on, I loaded up the disc for GEB without CFW and didn't change any of the save files I already head. Created a new one to test it too. Still dunno whats up with those extra bin files.

[Daykod]

What's up with sceJpegGetOutputInfo()? Using the debug bit of code to try and dump the jpeg always breaks at line 196, on fclose(wfp). Buffer overflow exception. Are the checks at the start of the function missing something? I'm trying to figure out what's going on in this save menu. Here's the call stack when you open the continue singleplayer menu.

    msvcr110.dll!6a1d28b7() Unknown
    [Frames below may be incorrect and/or missing, no symbols loaded for msvcr110.dll]  
    msvcr110.dll!6a1cf7fb() Unknown
    KernelBase.dll!7711778a()   Unknown
    kernel32.dll!76a63f46() Unknown
    msvcr110.dll!6a1cc2a2() Unknown
    kernel32.dll!76a614ad() Unknown
    msvcr110.dll!6a13dcc2() Unknown
    msvcr110.dll!6a1cd0a0() Unknown
    msvcr110.dll!6a144c67() Unknown
    msvcr110.dll!6a1cd03a() Unknown
    msvcr110.dll!6a1cd0c1() Unknown
>   PPSSPPWindows.exe!sceJpegGetOutputInfo(unsigned int jpegAddr, int jpegSize, unsigned int colourInfoAddr, int dhtMode) Line 196  C++
    PPSSPPWindows.exe!WrapI_UIUI<&sceJpegGetOutputInfo>() Line 330  C++
    PPSSPPWindows.exe!CallSyscall(Memory::Opcode op) Line 450   C++
    0d01669e()  Unknown

Also I tried setting up JpcspTrace up with my real psp to see what's going on in this menu but the log doesn't catch anything from sceJpeg. Here's a link to the log : https://dl.dropboxusercontent.com/u/38823080/log.txt

[unknownbrackets]

The God Eater games use some complex linking, it's not impossible JpcspTrace is missing it, unfortunately... or maybe it's some module that's already loaded doing the sceJpeg calls. Hmm.

For the debug code, it looks like you need to create a "Jpeg" directory (possibly inside Windows/) or it'll probably crash. Might check wfp != NULL.

-[Unknown]

[Daykod]

Cool. Got it working and it looks like the jpeg isn't too far off of what it should be. Instead of putting it in a specific directory, I just changed sprint off to format "Jpeg%x.jpg" instead. Here's a link to the image https://dl.dropboxusercontent.com/u/38823080/Jpeg7369E829.jpg

[unknownbrackets]

Oh, that's interesting. Is it meant to have a background? It almost seems like there's transparency that's being ignored, but that would be JPEG-2000 or something right? (I do not know much about that stuff at all.)

-[Unknown]

[Daykod]

https://dl.dropboxusercontent.com/u/38823080/pspscreenshot.png Here's what it should look like so there's some kind of transparency somewhere. PPSSPP just draws a black silhouette.

[CPkmn]

@unknownbrackets

Transparency isn't ignored - nothing is actually being decoded because the functions it uses aren't really implemented fully and (I guess) there's a silhouette, and the decoded avatar is drawn over that (but since nothing is decoded, nothing is drawn over it I think). In order to actually decode the avatar, the following functions have to be correctly implemented :

sceJpegDecodeMJpegYCbCr() sceJpegMJpegCsc()

[Daykod]

The silhouette would changed based on the save game though from what I could tell, and I think PPSSPP gets that part right. I'l have to check it again later.

[thedax]

Another thought just occurred to me: @Suleks: What firmware was your PSP on when you created the save, if you can remember? If it doesn't match the firmware the game wanted(say 5.00 or 5.50 for example, and the game wanted 6.xx) that tends to create "corrupted" saves, which might be throwing off PPSSPP. Or was it if you upgraded to a newer firmware after creating the save on the "wrong" one? Hm..either way I seem to remember improper firmware versions causing trouble.

[Daykod]

I use the PSP 3000 model so I was probably using CFW 6.60 when I made it. I created a test save without CFW with the disc though and it had the same issues IIRC. That one was created with the latest firmware.

[Daykod]

https://dl.dropboxusercontent.com/u/38823080/SAVEDATA2.7z here's the zip I posted in the other thread. The second file is the one I'm sure I created on a real PSP since it has avatar data at all and it loads ingame after the MJPEG implementation commit. https://dl.dropboxusercontent.com/u/38823080/SAVEDATA%20-%20TEST.7z is a new set of save files I just tested with that commit. Both real PSP save games still give the hash broken message. Gave them appropriate names this time round so they're easy to identify.

[thedax]

I tested savedata-2.7z and the second save slot with 10 hours goes in-game without the mjpeg commit, so I don't think it's working because of that. The third save slot with 5 hours doesn't go in-game with or without the commit(broken hash).

I got the same results as you with SAVEDATA-TEST.7z.

[Daykod]

Thought I'd add that God Eater 2 still has this issue. It can't load real PSP save games. There aren't any MJPEGs used in the loading screen. Same error code though.

[Daykod]

So I had a dumb realization about that real PSP save game that loaded in PPSSPP. It was run through SED because I was manipulation the version of the save so that it could be imported in JP GEB. So despite being able to be transferred to different PSPs, PPSSPP can't decrypt it? I'm not too familiar with the DRM that PSPs use I just tested this with my GE2 save that I used SED on.

[kurasa25]

same problem here... except my save works perfectly on my psp. only on ppsspp the avatar is kinda buggy and it sends me back to the title screen as soon as i try to load the save.

[Daykod]

I still have no idea what's the problem. I'm guessing namco bandai implemented their own encryption somehow. That or PPSSPP doesn't decrypt saves like I think it does. If a missing key is the issue, I can pull out GEB and GE2's key using SED. I should have them laying around. Otherwise I have no idea what that broken hash means. It can't be JPEG because GE2 doesn't even use any JPEGs in it's loading menu.

[erratic187]

Hi...im also experiencing this issue however, it's on just 1 save file. I have 2 PSP save files w/c i then transfer to PPSSPP, when i load one, it just goes back to the previous menu, when i load the other, it gives me the 'special char unlock key' message but then loads up the save just fine. if anyone wants to check the files just msg me...

[unknownbrackets]

There have been some improvements to savedata loading and etc. Has this improved at all?

-[Unknown]

[Daykod]

Haven't messed with it in a while. I'l try it after my internet is fixed from these storms.

[thedax]

I tested again with Sulek's broken save(s) and it still kicks you back to the main menu, so no.

[super-ninja-tom]

Same issue here

[unknownbrackets]

Are there any tools to hack this savedata? For example, could we compare the raw data from a psp and from ppsspp and see what's different, if anything?

-[Unknown]

[unknownbrackets]

For now, 08888F54 is where it seems to decide whether the savedata is good or not in Gods Eater Burst.

08888F54 1043028B beq v1, v0, pos_08889984

As a workaround, you can force it to load savedata using:

08888F54 1063028B beq v1, v0, pos_08889984

This could theoretically be done as a cheat and work on the PSP as well to allow PPSSPP savedata to load. It seems like 088494C0 is the function that makes the decision but I'm not sure yet.

-[Unknown]

[super-ninja-tom]

Hi @unknownbrackets, can you elaborate on the workaround? Can you show me a diff that I can put on my master please?

[unknownbrackets]

The workaround is a modification to the game, not to ppsspp.

-[Unknown]

[super-ninja-tom]

Ah, thanks for that. I will have to see what I can find on the internet about modding PSP isos. On my PSP though its on OFW so I guess the reciprocal would not be possible for me but its the PC I want to play it on so worth me having a look.

[hrydgard]

Well, @unknownbrackets gave enough info there to easily create a CwCheat code. Leaving it as an exercise to the reader...

[super-ninja-tom]

Ah, OK that helps. Will have a go at that then :)

[unknownbrackets]

The hash is just barely off. Makes me think we are wrong just by a byte or something, but I'm not sure where...

It's a simple sum of the bytes from the savedata (after psp decrypt + rolling xor + byte lookup table translation) afaict. With my savedata, the checksum is 0x200 higher than it ought to be.

-[Unknown]

[super-ninja-tom]

:( the cheat doesn't seem to work for me on ULES01519

I tried: {quote} _C1 Enable PSP Gods Eater save _L 0x08888F54 0x1063028B beq v1, v0, pos_08889984 {quote}

I was using http://forums.ppsspp.org/showthread.php?tid=3590 so it may be out of date. It does appear in the UI and appears selected so it may be different for different region versions?

[unknownbrackets]

It's probably in a different place for the European one, I only have the US one.

-[Unknown]

[super-ninja-tom]

Sure, to find the locations do I have to step through it in the debugger with a good save and bad save? Is there a variable location that shows where the interpretter is and a couple of good breakpoint locations in the source? Thanks!

[unknownbrackets]

What I did was first look at where the savedata is loaded to (via the savedata struct.) Then I set a breakpoint on this memory address and found where it read it in. This is that xor/lut part. There it writes it out somewhere else, so that's the new breakpoint address to look at.

Ultimately, in that func it determines if the sum (t0) matches a hash (t7.) I have not yet figured out where it gets the reference hash (which may be what's wrong) or the lookup table (which maybe could also be wrong.)

Anyway, based on this it returns 1/0 iirc. The v1, v0 check is verifying this result. So you just want to nix it and make it always allow the savedata.

-[Unknown]

[unknownbrackets]

There is floating point involved in the lut calculation. It's some kind of rolling lut.

The reference hash is at data + 0x10 (which it wipes to zero before calculating the hash.)

This implies something may be wrong with the lut, so maybe the savedata is actually invalid (somewhere.) It has my name, various text, etc. in it though and does not look wrong.... interp and jit both don't work.

Altering the savedata on load slightly (even one byte, even the last one since it's a rolling method) after psp decrypt totally corrupts it. So it seems like the savedata itself is decrypted right at least to the point of getting to the game.

It would actually help if anyone can check if their save is also 0x200 off (from their PSP.) I see some 0xFF 0xFF 0x01 0x01 in the savedata which would account perfectly if something was supposed to be zeroing them out.

-[Unknown]

[super-ninja-tom]

Thanks, I will have a go at writing a CwCheat for the EU version then...

[unknownbrackets]

So, I had initially made a mistake when checking this, and thought I'd eliminated the float lut stuff. I was wrong. The lut definitely seems to come up with incorrect data. So this could very well be floating point related.

In both saves I am testing, it's three bytes that are wrong. Probably coincidence, though.

The source data (as read from the file and decrypted by psp savedata) is correct, so at least that part is fine.

So this confirms that the cheat to make the savedata load could result in gameplay problems later.

-[Unknown]