Author
|
Topic: Need help on possible decompression of a file. (Read 2 times)
|
Babazoz
Guest
|
 |
« Reply #15 on: January 27, 2008, 08:15:45 pm » |
|
Also, as for pointer tables, would this look like one? Found in the main executable.  |
|
|
|
|
Ryusui
Guest
|
|
« Reply #16 on: January 28, 2008, 01:11:53 am » |
|
Actually, the dump might help. Try looking for the string offsets in the dump: if they're in there, you need to find the file they came from.
As for your screenshot...yes, a pointer table would look something like that, but unless it's reading word addresses instead of byte addresses that's probably not it. The biggest distance between pointer values I can see is $20, or 32...times four is 128 bytes, or about 64 characters of SJIS-encoded Japanese text. If there are no strings longer than 64 characters, then you might have something there, but otherwise...
Try multiplying the addresses by 4 and seeing if they correspond with anything in the dump or the original script file.
|
|
|
|
|
Babazoz
Guest
|
|
« Reply #17 on: January 28, 2008, 08:31:02 am » |
|
Actually, the dump might help. Try looking for the string offsets in the dump: if they're in there, you need to find the file they came from.
As for your screenshot...yes, a pointer table would look something like that, but unless it's reading word addresses instead of byte addresses that's probably not it. The biggest distance between pointer values I can see is $20, or 32...times four is 128 bytes, or about 64 characters of SJIS-encoded Japanese text. If there are no strings longer than 64 characters, then you might have something there, but otherwise...
Try multiplying the addresses by 4 and seeing if they correspond with anything in the dump or the original script file.
Ok, now I'm confused. Which addresses should I be multiplying? The strings I've found? Here's what I did to find that section in the screenshot. I looked at the offset of the string I wanted to find in the script file. Then I looked for the text at the script's offset in the memory dump and found three instances. Two of them were the sentence, and then I found the entire script file loaded into memory inside the dump. I noted the offset and subtracted the first offset by that, and got a 3 byte value, like A76180. I dropped the first byte, reversed the last two and got 80 61. Then I searched the executable for that and found 4 instances of it in that section you saw in the screenshot. And I don't know what to do next. Edit the script file, recalcuate the pointer, and then edit the original pointer? :huh: |
|
|
|
|
Ryusui
Guest
|
|
« Reply #18 on: January 28, 2008, 08:17:01 pm » |
|
Change the "8061" you found and see if it affects anything. Maybe increment it by a couple of bytes (like "8461") and see if the string gets truncated.
Also see if any of the other pointers also correspond to string addresses.
|
|
|
|
|
Babazoz
Guest
|
|
« Reply #19 on: January 28, 2008, 08:44:55 pm » |
|
No dice. Crashes altogether at boot.  Maybe the pointers are all contained in the script file. I dunno. I've been at this for days with no real result. It's weird. It seems that the values at the top relating to sizes would point somewhere, but if they are I can't see any correlation. :banghead: Although I do now concede that this file isn't compressed.  |
|
|
|
|
Ryusui
Guest
|
|
« Reply #20 on: January 28, 2008, 08:52:49 pm » |
|
Maybe you could just hand me the script file and let me take a look at it. >_>
|
|
|
|
|
Babazoz
Guest
|
|
« Reply #21 on: January 28, 2008, 08:55:17 pm » |
|
Maybe you could just hand me the script file and let me take a look at it. >_>
I linked to it at the beginning of the thread. http://www.mediafire.com/?53ckjgcsy2d |
|
|
|
|
Ryusui
Guest
|
|
« Reply #22 on: January 28, 2008, 09:27:31 pm » |
|
Apologies. ^_^; Anyway, I'm looking at it again, and I'm still mystified. If I were to hazard a guess, I'd say the whole thing is simply run through beginning to end. Try this. http://theryusui.googlepages.com/s_0000ess0_b.datFirst string has had an ASCII space added; everything else is pushed one byte forward to compensate, and the string length and file size offsets have been updated. This file is precisely one byte larger than the original. Let's see if my theory works. |
|
|
|
|
Babazoz
Guest
|
|
« Reply #23 on: January 28, 2008, 09:54:04 pm » |
|
Apologies. ^_^; Anyway, I'm looking at it again, and I'm still mystified. If I were to hazard a guess, I'd say the whole thing is simply run through beginning to end. Try this. http://theryusui.googlepages.com/s_0000ess0_b.datFirst string has had an ASCII space added; everything else is pushed one byte forward to compensate, and the string length and file size offsets have been updated. This file is precisely one byte larger than the original. Let's see if my theory works. Nope. Crashes, unfortunately. I think that it's looking for a value or a pointer that's been overwritten or "stepped on" as you said, but I can't figure out which one it is. I think what happens is that the 2 bytes at 00000009h is a pointer which moves by that amount to somewhere in the file, but I've changed it accordingly and still got nothing. Changing the value of that gives different results, such as the save screen being triggered, the signal to move on to the next bit of text, or it just plain crashes out. It's pretty rough. |
|
|
|
|
Ryusui
Guest
|
|
« Reply #24 on: January 28, 2008, 11:29:35 pm » |
|
Sucks that we can't trace the routine that does all this black magic. Or has PSP emulation/hacking progressed that far?
|
|
|
|
|
KaioShin
Guest
|
|
« Reply #25 on: January 29, 2008, 05:01:32 am » |
|
Sucks that we can't trace the routine that does all this black magic. Or has PSP emulation/hacking progressed that far?
Gemini told me you can debug on the PSP in realtime with a cable that connects PC and PSP together and a special software. |
|
|
|
|
DaMarsMan
Guest
|
|
« Reply #26 on: January 29, 2008, 10:05:55 am » |
|
Some games like DQ4 have CRC checks on their strings.
|
|
|
|
|
KaioShin
Guest
|
|
« Reply #27 on: January 29, 2008, 10:13:27 am » |
|
Some games like DQ4 have CRC checks on their strings.
Then it would also crash if he just changed a letter - but it only crashes if he goes over the original string's length. |
|
|
|
|
Babazoz
Guest
|
|
« Reply #28 on: January 29, 2008, 11:28:04 am » |
|
Well, I decided to try an idea that came straight out of left field, so I decided to zero out the value at 000000009h, which was E3 0C, and the text displayed with the extra characters. Except the pictures didn't show, nor did the opening movie or the questions to enable/disable auto-skip and whatnot. It just went straight to the text on a black screen and even played the voice. This leads me to believe that the value I zeroed out was pointing somewhere, executing commands, such as displaying pictures, then jumping back to the text. It's not much but I think I might be on the right track. Now I just have to figure out where it's going. |
|
|
|
|
Ryusui
Guest
|
|
« Reply #29 on: January 29, 2008, 02:44:16 pm » |
|
It's not out of left field. Data corruption is a useful tool for figuring out the workings of a game. Just change bytes at random and see if the game breaks in any interesting ways. ^_^
I think you might want to change the 2-byte value at 08 instead: i.e. "13 E3" (E313). 0C77 seems to be a control code: all of the other strings have an 0A77 in between them.
|
|
|
|
|
|
RHDN Forum Archive
