News: 11 March 2016 - Forum Rules, Mobile Version
Current Moderators - DarkSol, KingMike, MathOnNapkins, Azkadellia

Author Topic: [PSX - Tekken 3 MOD] Anyone with hex editing experience?  (Read 261 times)


  • Newbie
  • *
  • Posts: 1
    • View Profile
[PSX - Tekken 3 MOD] Anyone with hex editing experience?
« on: February 08, 2018, 10:07:40 am »
Hi guys, I was doing some random reverse-engineering on Tekken 3 for the PSX. I found out what the addresses of movesets and select screen names are, and how to edit/swap them. For example, I can make Jin kicking the opponent before the battle starts, or I can give him Ogre's moveset without using cheats.
Everything okay so far, but I need some help to understand the structure of the records. I post some photos of what I actually got so far. (There are many explainations on the images, so please open both to get a clear idea).
Screenshot 1:
Screenshot 2:
Now what I'm asking you is just a little help to understand better the structure of the records and maybe how to find/edit the names in the actual battle.
Thank you so much, and I'm glad to share my work with such a great community.
« Last Edit: February 08, 2018, 11:51:32 am by Vins98 »


  • Jr. Member
  • **
  • Posts: 30
    • View Profile
Re: [PSX - Tekken 3 MOD] Anyone with hex editing experience?
« Reply #1 on: February 15, 2018, 03:38:18 pm »
Nice choice to take on Tekken 3.Shows good taste. I did notice that those data structures have a variable length string of text. This usually means that the name is the last thing in the structure you already noticed those names are zero filled to a four byte alignment. Nulls like these are used to mark the end of text. Now you have a note that indicates that the structure begins four bytes later.I would question that.
Not sure if it helps but have you tried to count up all the names and search for that number. You will likely find a descriptor in the header.

Keep fuzzing those bytes


  • Sr. Member
  • ****
  • Posts: 311
  • Good news! An anomaly solved the enigma.
    • View Profile
Re: [PSX - Tekken 3 MOD] Anyone with hex editing experience?
« Reply #2 on: February 15, 2018, 05:22:33 pm »
Nice stuff! Here's what little I know:
PS1 data is almost always aligned to 32bit chinks. Because of that, if you use HxD hex editor, and set the view to 'byte group size=4', you'll be able to spot patterns easier.

Like Valendian said, the 00s after the names are 'end-text' markers, filled to the next 32bit boundary. You can usually write over these 00s with more text, as long as you leave at least one 00 at the end. Other than the names and their fill, there are three 4byte chunks left. Keep in mind, the PS1 is little endian, meaning byte order is reversed.

If the variable length names are at the end of the structure (like Valendian says), the entries would look like this:

F4210280 044A 0404 0404 020B.....594F5348 494D4954 53550000..YOSHIMITSU
0C220280 051E 0505 0505 090C.....4E494E41 00000000...............NINA
20220280 0647 0606 0606 040D.....48574F41 52414E47 00000000..HWOARANG

The PS1 memory addresses usually end in 0x80 (aka have the highest bit set), so the first 4 bytes are a RAM address. The converter tool HERE should help you locate where these addresses are pointing to. EDIT: I checked, and they are pointers to the character names. That verifies that the names are listed at the END of each structure.

That leaves 8 bytes. They are likely NOT full memory addresses, but maybe 'relative' addresses to look up combat moves in a table. They are probably 1 or 2 bytes long (not 4) but I have seen such tables use 1bit tags. There's an obvious pattern counting up by 1 for each new character (04 > 05 > 06 etc)- perhaps progressing through a table list of moves. I would try to edit them, 1byte or 2bytes at a time and see what changes.
« Last Edit: February 15, 2018, 07:29:26 pm by weissvulf »


  • Jr. Member
  • **
  • Posts: 30
    • View Profile
Re: [PSX - Tekken 3 MOD] Anyone with hex editing experience?
« Reply #3 on: February 15, 2018, 09:03:25 pm »
The PS1 memory addresses usually end in 0x80

Just to expand this a little:
pointers which refer to cached memory are in the 2 MB range:
    0x80000000 (00 00 00 80) - 0x801FFFFF (FF FF 1F 80)
Tune you eye to see 80 in the third column of a 4 byte word, it's and important signature for a pointer.

The MIPS CPU strictly enforces alignment of data. The instruction set requires that 4 bytes words lie on a 4 byte boundary, likewise for halfs (2 bytes). However small data like a byte may just happen to be 4 byte aligned. You can use a debugger to verify the size of data once you know where it lives in RAM. Place a Break-Point on read/write. You will see one of the following assembly instructions:
  4 byte word ... LW/SW (load/store)
  2 byte half ... LH/LHU/SH
  1 byte ... LB/SB
(Just be mindful that memory transfers will use word copies for byte arrays).

If you are using a debugger then the bytes are right their ready to be fuzzed, you can save/reload state and the turn around time is instant. You can lean on the hex editor for searching the save state. There is a fixed difference between the save state offset and RAM address, for pSX at least (doesn't compress the save states).