News: 11 March 2016 - Forum Rules

Author Topic: Ps2 games structure?  (Read 666 times)


  • Newbie
  • *
  • Posts: 1
    • View Profile
Ps2 games structure?
« on: July 23, 2021, 01:00:49 pm »
Hi! I'm a 16 years old with too much free time on his hands right now and well, knowing some C and x86 assembly, I thought of getting into reverse engineering, thinking that it would have been a 2 months adventure. Well, turns out I was wrong.

This is my first attempt at reverse engineering something, so I still don't know a lot of stuff. My target is the game Dark Cloud, and at some point I'd like to make some code in C that resembles the source code of the game. After some research, I've downloaded some tools that should help me in my task but I'm still unsure about a lot of stuff.

After opening the ISO, I have an elf32-little file (which i presume is the binary) and a bunch of DATA files. So I opened the SCES_502.95 file with ps2dis and started scrolling through the assembly code to make some sense of it. I saw that there are various addresses for what I think are functions (they have names like StopCamera__7CCamera) stored in registers. When I look for the address of the function, it leads to a nop. Does this mean that the function is loaded from another file?

Also, I wanted to ask you some info on what I should expect to find on this file. For example, what should I expect to find on the .text section? All of the data initialized in headers? And what about the 'main' section? Is there all the data stored in the main function of the original source?

I'm sorry if some of these questions sound dumb, I'm just curious of how these games work


  • Hero Member
  • *****
  • Posts: 3357
    • View Profile
Re: Ps2 games structure?
« Reply #1 on: July 24, 2021, 03:26:45 pm »
"and at some point I'd like to make some code in C that resembles the source code of the game."
That is rather on the ambitious side for someone new to all this. If you are already a bit familiar with C and X86 ASM I don't see why you can't get hands on with some assembly stuff rather than doing the usual path of file analysis, text editing, graphics editing, cheat making and such before finding out that assembly is good stuff and makes a lot of things easier, or opens up certain avenues, but there is jumping in at the deep and and in this case going to swim at night in rough sea conditions.

As far as end users ending up with source code of some form then 3 ways that ever happens
1) The dev releases the source in some fashion or there is a leak, can also be of a substantially similar game (same engine, sequel knocked out for a year later...).
2) Someone does some combination of assembly fun, file analysis and game observation. This, especially if limiting to observation (see clean room reverse engineering), is usually a years long effort even for skilled programmers doing it for simple games. Or indeed pick anything that is not 1)* on and see how glacial the pace is.
3) Decompilation.

*I will note such sites tend to shy away from code leaks and things where the source release was retracted ( , bink/rad tending to be the main thing that sees such things happen or prevents game code from being released in the first place by otherwise willing devs, though video is a problem in general ).

3) Was for quite some time treated as impossible (see halting problem) but owing to the way older C compilers work (don't know if this would be C++ which is probably a bit further out) and with some occasional lucky breaks (see Diablo function names being included in I think it was a Japanese port) then actually it is possible and we have things that compile to the same code as the original for a handful of games (Mario 64 being the most notable at this point, though some might opt for Diablo instead). I don't know what we have for PS2 efforts though; indeed the N64 thing came as a bit of a shock to me as I thought it was mostly still certain noted X86 C compilers that were the main things people looked at.
I am also not sure if anybody. much less anybody around here, has pulled apart enough PS2 games** in this manner to make some kind of what to expect, or what to expect of this vintage game (different years seeing more compiler development, different attitudes to security and devs pushing things further and further).

**there are some dealing in various consoles, or for consoles that were more extensively looked at (be it at the time or for emulation since), that can give you a timeline of when different protections where introduced, when optimisations happened, when compile versions changed, when base libraries were changed. Seen some fairly advanced stuff for the PS2 (mainly as the code was fairly advanced -- once saw a writeup of a PS2 text engine which had all manner of features that would impress even today for a typesetting program) but never the equivalent of that, or even an weird things and oddities list. That said I could easily have missed such a thing as PS2 is far from my main interest.

As far as what you can expect to find. I am somewhat surprised you have what looks like a full function name there; while elsewhere in this I will discount the optimisation done by compilers for the console and era it was still fairly common for such things to be scrubbed for security or optimised away.

On finding a NOP I would consider two main things. 1) Compilers of the day were still not as fancy as today's optimising efforts and a commented out function could well still be compiled but references to it blanked out. 2) NOPs are also used for timing purposes, that might even be their primarily "legitimate" function.
Address being generated at runtime is a possibility (we are well into the era of dynamic allocation by this point) though, as is some kind of external list to spare devs having to recompile every 5 minutes for a small change, though library loaded when needed is a better bet (afraid I don't know much about the PS2 approach here for dynamically loaded code and it is not like the PS2 is running much of an OS or hypervisor underneath it all).
Main functions in games regardless of system tend to be treated on a game by game basis -- some will be absolutely minor stubs that defer to other things almost immediately, others will be a true main function/core loop that the game does.

"which i presume is the binary"
Why not check? Disc based stuff overwhelmingly copies data, especially executed code, to RAM before use. Snatch the code (usually have a nice "currently executing instruction" you can watch for a while to see at least some of the main loops or basic bootup IO stuff) from RAM and other than compression (debatable if useful on a game where you otherwise have a whole DVD of space and 1 second of video or audio probably equals as much space -- force of habit, anti hacker or between disc read speed and whatnot it is still faster to decompress being the reasons to see it on a device like this) it should be the same as the disc. Can also spare you spending time looking at a debug binary the devs left in when packing up the game or link cable effort (not really a thing for the PS2 compared to the PS1, GBA, DS and many other things). Though yeah Sony does tend to trend towards the ELF format for things rather than fully custom (PE -- exe, xex, xbe, dll... being a Microsoft thing and all) so good shout on that one.

"with ps2dis and started scrolling through the assembly code to make some sense of it"
I am not going to say static disassembly and going in cold will gain you nothing but generally nobody does it unless they have to beyond a sanity check to make sure the disassembler's output looks like code. Find some aspect (would have said thread but... yeah) of the game you can use as a jumping off point (infinite health cheat***, main loop, main loop for the menu...).

***a list of notable RAM locations (seen enough of PS2 cheats, and does little to say otherwise, to know we are not yet in the era of all pointers, all the time or fun with ASLR) such that you might find for the average list of cheats can be a very nice thing to have here.


  • Full Member
  • ***
  • Posts: 228
    • View Profile
Re: Ps2 games structure?
« Reply #2 on: July 24, 2021, 06:46:18 pm »
When I look for the address of the function, it leads to a nop. Does this mean that the function is loaded from another file?

Is the entirety of the function at the jal address a nop and then a jr, or does the function just start with a nop and do some stuff before the jr?

I can think of some circumstances where you would put a nop at the start of a function, like if you had a pointer table of damage formulas or something and some of them were identical but had hardcoding that needed to be preserved and the addresses stored in the pointer table had to be sequential for some reason.