Tweet
.
-
Last edited by xibalba; 11-22-2015, 05:33:49 AM. -
I'm assuming the data you're looking for is byte-swapped. The debugger displays data in big endian whereas data in the executable is little endian.
Example:
Little Endian: 01000624
Big Endian : 24060001
If you still can't find it after swapping, the data may be compressed. Sorry but that's all I could think of.Last edited by 47iscool; 09-03-2014, 10:30:52 PM. -
If that's not it, your other weak link is that the code is writing one byte. It's not replacing 4240, it's only replacing 40, so the result would be 30420000 or "andi $v0, $v0, 0" ($v0, also known as $r2). Your interpretation leaves $v0 with whatever junk happens to be on it, instead of setting it to zero at all times.
Edit: Oh, and to answer your question, what you did is probably the easiest way. Especially on the PSX, you'll find that files are often accessed by their logical addresses on the disc. Beyond that all file access can be pretty well obscured, as in you won't find strings or labels somewhere that tells you this is the function for loading modules, and these are the files it works with. If you're lucky, and the data you need is uncompressed in a file on disc, just searching for it is simple enough. I frequently do the same thing, but with grep to go hunting through the actual file system. If the data is compressed or encrypted, it's a longer slog. You'll most likely have to figure out what compression is used before you can do much of anything with the files.Last edited by Pyriel; 09-03-2014, 11:30:36 PM.Comment
-
-
Loading from a memory card almost certainly won't have any effect on what you're doing. And I only say "almost" because there's a vanishingly small chance the entire development studio was insane.
You're at the point now where I'd start looking for how I was screwing up. If you're loading from a save-state made with the original disc, that might be the culprit, although using a different image will generally result in the emulator crashing. You might be loading the original image by accident. There could be any number of reasons, and you'd might as well eliminate user error before you drive yourself mad or start hunting for hidden data on the disc.Comment
-
-
-
It's weird that they would do that, but not unheard of. Sometimes files are just on the disc to pad the data out to some boundary that makes seeking other files more efficient. No idea if that's why the .OUT file is there when the .ARC file is what's actually used after it's decompressed, but that's as good a wild guess as any.
If the tools decompress it properly, I hope it comes out to the same size or smaller when you re-compress it, or inserting it into the image gets a whole lot harder.Comment
-
-
-
Comment