Viewing Game Code

A forum for all general Suikoden related topics.
Post Reply
User avatar
wataru14
Guide Writer
Posts: 716
Joined: Thu Aug 05, 2010 10:37 am
Location: Las Vegas

Viewing Game Code

Post by wataru14 »

I've been thinking about people who can look into the game's code and find things and I wonder how they do it. I have been wanting to learn how to do that, myself, but I've been wanting to ask a few things.

What program do you use? Is there a "Source Code Viewer" program?

Can you use an .iso or do you need the discs?

Once you're in, I've seen hacking sites display what game Code looks like. How do you know where certain pieces of data are? Which lines are Rune info and which are equipment data, for example?

There are a few things in the games that we don't have hard numbers for that I'd love to dig up, but I'd rather try to find it on my own instead of constantly begging our tech people for help.
User avatar
Pyriel
Webmaster
Posts: 1227
Joined: Wed Aug 18, 2004 1:20 pm

Re: Viewing Game Code

Post by Pyriel »

What program do you use? Is there a "Source Code Viewer" program?
I use IDA Pro, but there are freeware programs (PS2Dis was popular at one time) that can do the job. What you use can be a matter of preference, but I don't think anyone would argue that most of the freeware, including PS2Dis, is better than IDA. However, it's difficult to get a legit license for IDA, or it was at one time.

The term is "disassembler". A disassembler will take a binary (executable, dump, DLL, etc.) and decode it to yield more human-readable op codes. Viewing the source code would require you to have access to the actual source code from the developers. There is such a thing as decompilation, which will give you source code, but not necessarily the source code. That's a thorny topic, though, and decompiling binaries for most systems is or at least was generally regarded as so impractical that it had might as well be impossible. Disassembling code is workable because the machine instructions in the binary typically have a 1 to 1 relationship to their text op codes, aside from some helpful merges that are often called "macros". For instance, in the PS1/2 world, loading an entire 32-bit address takes two machine instructions: LUI (load upper immediate) to load the upper 16-bits and an ADD or OR instruction to load the lower 16. Most disassemblers will merge that into a single LI (load immediate) or LA (load address) macro.

Decompiling requires a lot of knowledge about the development tools that were used (programming language, library code that was used, etc.), and it's far from a trivial task to sort it all out. It's gotten more doable recently, but I still don't see it used much. What I've seen in the last ten years, the decompilers would still spit out obscure looking code, and just straight up disassemblies at times.

Can you use an .iso or do you need the discs?
Either works. You'll be disassembling files copied from the disc or a disc image. It's only in the cartridge world that you're likely to get a game as a single file that you can work with as a unit.

Once you're in, I've seen hacking sites display what game Code looks like. How do you know where certain pieces of data are? Which lines are Rune info and which are equipment data, for example?
That's an investigation, or something like a trouble-shooting exercise without an intent to fix anything, and you use every technique you can think of. It's the sort of the thing that experience will make a big difference in.

Have you ever seen "House"? Same sort of principle. You take the information you can get from looking at the game, synthesize that with what you know from past experience, and what you can get from looking around. Then you try to imagine possibilities and how to rule them out. In the end, you break stuff if you have to.

For instance, I know the character set for the game, so if I want to find where the rune list is loaded in memory, I can search for a name or a description, and then compare what I find to what the game says about the rune. If I don't know exactly what I'm looking at, I might change it and see what happens. For example, there's a value on the runes that determines what slots they can be equipped in. If don't remember if it's bit flags, or what, but if I had a random byte with the value 1, I might change it 2, and if I'm paying attention or I'm lucky enough, I might notice I can suddenly only put the Pale Gate Rune on somebody's right hand.

You can also work backwards from the programming, which is something I had to do a lot in the early PS2 days, and it's still kind of habitual for me. For instance, games will often impose limits on different stats, and they're often hard-coded. So a common first probe was to search the code for occurrences of a limit value, make a change so the game will always replace the value with the limit, and then see if anything desirable was affected. From there, you can use different techniques to figure out where the stat is stored. If you're lucky enough to have a debugging emulator or something, you can just use a breakpoint. If all you have is a disassembler and cheat device, you might be able to interpret the address from the code, if it's static. Or you can do what I often did in Suikoden III back in the day, and change the game to overwrite string values in menus with addresses I was having trouble sorting out.
User avatar
wataru14
Guide Writer
Posts: 716
Joined: Thu Aug 05, 2010 10:37 am
Location: Las Vegas

Re: Viewing Game Code

Post by wataru14 »

Thanks for the info! It seems like a lot more than I'd be capable of doing, I'm afraid. I figured it would be complicated, but it sounds like it's years ahead of my technical know-how. Still, I might try banging around if I have the time.

I'm really only looking for a few specific numbers, mostly for little things that the site doesn't fully quantify. Things like:

* What is the base % chance of Sleep to go off for Wind of Sleep and Beauty Attack. The site just says "Chance of sleep."
* How the Merchants' unit works. Success chance? Modifiers to success?
* What is the chance for Thieves to successfully spy vs. their chance to steal money?
* What, mechanically, the Phero Rune and Fog of Deception actually do?
* How much does Bucket status reduce your accuracy?

Little things like that. Nothing that there is a tremendous demand for quantifying, but that my OCD completionist mind wants to know.

Still, I'll see what I can find out.

Thanks again!
Julian
Posts: 73
Joined: Wed Jan 29, 2014 9:17 pm

Re: Viewing Game Code

Post by Julian »

I was in a similar position last year thinking "there's no way I could do this kind of work", until I decided to just try it. I found it logical and pretty easy, but that's just because of the way my brain is wired, I guess.

I use Ghidra for disassembly, it's similar to IDA, but free. I can't speak for PS1 hacking, but PPSSPP has wonderful debugging tools for PSP games.

Generally, you disassemble the game's main executable, but you may also need to disassemble relevant overlays. (Meaning, if the game loads a file into memory that has executable code that it jumps to.) You can do quite a bit with just static analysis of code, and there are various strategies you can employ to find what you're looking for. But at the end of the day, there's a crapton of code, and if you have no idea where to start, it's not going to help.

Emulators with debuggers and memory maps are also great. Again, lots of different strategies you can employ, but you have the game running and can do dynamic analysis of the code that the game runs.

Using both side by side is also very powerful.

The two main skills here are:
1. Reading and understanding the assembly code
2. Coming up with strategies to find what you're looking for

For example, with the success % scenarios, disassemblers can usually identify standard libraries, so you can use static analysis to find the address of the game's rand() function. (Or you could use other methods to find it.) You can then set a breakpoint on the emulator to see when it gets called. Turn breakpoint on, do action that has a % chance, and analyze.

Another example, for finding stats, you can use a memory map or something like Cheat Engine to do searches and treat it like that - find a stat you can increase, search for the value, increase it, search for the new one. Keep doing that until you get a short list, then try live editing memory - if you edit and it updates, you found the right one. From there, identify the stat that increases accuracy, set a read breakpoint on that address, and do an attack. You'll identify code that reads your accuracy stat, and you can analyze from there.

Alternatively, you could identify the address that stores the status effect. I did this a while ago when fiddling with the main menu, since it draws an icon for the status if you have one. Found code that was writing text, found the checks for status effects to write something other than the HP icon (or whichever icon it writes over), and that gave the address. Manually editing it cycled through things like poison and balloons. You could then set it to bucket, do a read breakpoint, and attack - you will find code that checks for statuses while attacking, and can analyze from there.

There is no "right" way to do something here. You try stuff until you find something that works, and you obviously get better with practice.
JiN88
Posts: 90
Joined: Tue Dec 20, 2016 11:40 pm

Re: Viewing Game Code

Post by JiN88 »

What's the best way to look for the game's sprite? The only method I know of is using save state and PSX-vram, but that has limitations.
User avatar
Pyriel
Webmaster
Posts: 1227
Joined: Wed Aug 18, 2004 1:20 pm

Re: Viewing Game Code

Post by Pyriel »

From the "using what information you have" department:

What is the base % chance of Sleep to go off for Wind of Sleep and Beauty Attack. The site just says "Chance of sleep."

I would recommend finding the in-battle code (which in Suikoden 1 is in the main executable, iirc), and searching for immediate values that match one of those spell IDs. The Suikoden team had a tendency to embed those values in code more than I'm used to seeing, at least early on in the series.

How the Merchants' unit works. Success chance? Modifiers to success?
What is the chance for Thieves to successfully spy vs. their chance to steal money?

On these, I'd start with the assumption that this gets passed in as an action id greater than 2 (having just seen that 0-2 are the RPS actions), and look at how the game decides to call the code for attack/bow/magic to see if there's another path I might want to investigate, or throw a breakpoint on. Failing that, I think Thieves are reusable like Ninjas, right? That implies a value is decremented, and most likely the character IDs are in an array to simplify displaying the portraits, so one is likely removed or flagged as used. One of my favorite techniques, when I'm just trying to figure out where to start, is to grep a memory dump or an executable file based on how I think an array of values will be structured, e.g., character id 1 - 0-10 arbitrary bytes, then character id 2 followed by 0-10 arbitrary bytes, then character id 3. It pays off a fair bit of the time, and can narrow your search really quickly if you think you know more than about 5-8 values in sequence.

If none of that bears fruit, you could try investigating rand(). I try to avoid it because it's called everywhere, and trying to trace it is tedious and brute-force.

What, mechanically, the Phero Rune and Fog of Deception actually do?

I'd probably try the same thing as the first option here, at least to start.

How much does Bucket status reduce your accuracy?

This one, I'd look for the in-battle data, and try to work out what pretty much everything is (health, attack, strength, mdef, etc.). A lot of the work may already be done in existing cheat codes. Then just ignore the known variables, try to get bucket applied, see what the value is, and then look for where it gets read and acted upon.
JiN88 wrote: Sun Apr 17, 2022 11:57 pm What's the best way to look for the game's sprite? The only method I know of is using save state and PSX-vram, but that has limitations.
Frankly, I'd probably stick with that. They didn't structure anything in a way that's convenient, and all the sprites have their pixel data compressed in the files. The color tables are uncompressed, and stored separately. As far as I'm aware, there's nothing that obviously links the pixel data to the appropriate color table, apart from purpose-written code.

You might get lucky and the PSP version is structured in a more modern way. Any of the older versions are kind of a mess, though. Even the Chinese PC version does things in weird ways, like broke-ass DLLs for the character portraits (or maybe it was the ending cards).
Julian
Posts: 73
Joined: Wed Jan 29, 2014 9:17 pm

Re: Viewing Game Code

Post by Julian »

For extracting sprites, you can use PPSSPP's GE debugger to step through textures on the screen, like this: (and you can right click -> save image)

Image

Graphics aren't compressed, but I think all the sprites a module uses are embedded in the module file (uncompressed), so if you were to reverse engineer the file format (I think I have this sorta figured out, but I'd have to go back to my notes. Linking the CLUT can be kinda awkward, too, but I think for module files the CLUT index is stored in a table along with the texture pointer, or in another table with shared indices, don't recall) you could find a way to programmatically extract them all, but for the average user extracting them outta the GE is probably simple enough.
You do not have the required permissions to view the files attached to this post.
User avatar
Raww Le Klueze
Global Admin
Posts: 1915
Joined: Sat Jun 26, 2004 1:38 am

Re: Viewing Game Code

Post by Raww Le Klueze »

wataru14 wrote: Sat Apr 16, 2022 1:52 pm * What, mechanically, the Phero Rune and Fog of Deception actually do?
Julian found this out recently, but it appears Fog of Deception is broken in the same way that Clay/Earth Guardian are and it's trying to apply a bonus % to a stat that is always 0 which means it will remain 0.

What it should do however is lower the Skill stat of the enemy party by 20%, because there's no evasion stat in S1 it's all handled by skill and kind of explains why that spell is effecting the enemies rather than your own party. Effectively making the enemy less likely to hit you is the same as making you harder to hit.
Doctorum Non Urina Singulus.
Post Reply