Tekken 4 (PS2): a map of what’s known

Every part of the game the project has looked at, how far it’s decoded, and how that was established

A status map of the Tekken 4 (PS2) teardown as of 2026-10-22: what is decoded and proven in game, what is decoded but unproven, what is partly understood and what is still unknown, across the archive, movesets, characters, stages and sound. Also the claims that turned out wrong, and the open problems in order of how much they block.

This is the hub of the Tekken 4 teardown: a snapshot of what’s understood, kept as a reference and revised as the project moves. Each area links to the entry with the detail.

How status is judged

Status	Means
In game	Decoded, and a change built on it worked in PCSX2 as predicted
Verified	Decoded, and independently re-derived from the bytes (or rebuilt byte-identical), but not exercised in game
Decoded	Read from code or data, not independently checked
Partial	Structure known, meaning or a working tool missing
Unknown	Not yet understood

The project’s rule is that “not confirmed in game” means not working, so only the first status counts as usable for modding.

The disc and archive

Detail: Tekken 4’s 2.57 GB archive keeps its index in the executable.

Piece	Status
The executable: plain MIPS, unencrypted, `file offset = address − 0x17F000`	In game
`DATA.BIN` index (1,121 entries in the executable) and the 4 KB header transform	Verified, then in game
Writing a modified disc: append files, repoint entries, keep the game’s CRC	In game
Which files the game loads for what (resolver and kind table)	Verified (2,457 of 2,457 loads across 57 savestates)
Video records, the title images, records 0 and 1120	Unknown
Free space in the executable for new code	Unknown

Movesets

Detail: Tekken 4’s moveset files, decoded and edited in game.

Piece	Status
The LZSS codec, and an encoder the game accepts	In game (a recompressed moveset loads bit-exact)
Character Data layout; rebuilding all 22 stock movesets byte-identical	Verified
Damage, transitions, adding a move, transplanting a whole moveset	In game
Memory limits per player	Verified (addresses); exceeding them untested in versus modes
T1 condition opcodes	Decoded by hand, many partial
Tables T7, T9, T12, T14, T16–T19; hit and hurt boxes; AI data	Unknown
Animation clip encoding and the bone-to-joint map	Partial: no new animation can be made

Characters and models

Detail: Tekken 4’s character models, and editing them in place.

Piece	Status
The row table (112 rows), six files per row, the character index and name tables	In game
Adding a new fighter in the unused ”?” select cell, with name, icon, portrait and HUD name	In game
The CHRTK4 model format, in-place vertex edits, textures inside the model file	In game
Bone table meaning; which bone each palette slot stands for	Partial
Adding vertices, meshes or bones	Unknown (needs the vector-unit microcode)
The versus-screen portrait, the intro and win-pose scripts, growing the select grid	Unknown

Stages

Detail: Tekken 4’s stage format, and building a new stage from scratch, How large can a Tekken 4 stage be? Bigger than predicted, Tekken 4 ignores a wall whose faces wind against their normal.

Piece	Status
The four files per stage and the 15-section stage container	Verified
Geometry, textures in place, walls, floor and start regions	In game (a new stage 17 built from scratch)
Stage size	In game up to 7.7 MB, past a predicted 7.6 MB limit
The crowd budget table	In game
Floor flags other than plain floor; lighting types; hittable objects	Partial
Rebuilding a texture bank from scratch	Fails (hangs the load), cause unknown
Stages 18 to 25	Decoded, not tested

Sound

Detail: Tekken 4’s sound system, from the hidden driver to the music tables.

Piece	Status
The sound driver package in the executable; unpack and repack	In game (repacked driver identical in memory)
ADPCM banks, the sound-memory map, the sound-effect tables	Verified
Music track tables, stage-to-music map; swapping and shortening tracks; replacing banks	In game (judged from memory, not by ear)
Music sample rate (44,086 Hz)	Verified
Replacing an announcer line at the same length	In game
Which moves request which sounds; the announcer clip table; longer clips	Unknown
The ADPCM encoder against real hardware	Decoded, unverified

Claims that turned out wrong

Every desk report was checked by a second, adversarial pass that re-derived its claims from the raw bytes with independent code. The claims it refuted are kept on record, because each would have broken a mod. Among them:

Player 2’s moveset room is 348,416 bytes, not 504,128.
The rule that picks player 2’s memory layout is the reverse of what was reported.
The wall-collision grid is set per file, not a fixed 16×16.
“7.8 MB of headroom” after a stage file is live data.
The music runs at 44,086 Hz, not 48 kHz.
The common sound bank holds 205 samples, not 391.
The second model file (k2) is not the fight model; k3 is.
A moveset transition’s target move is at +0x08, not +0x0C.

Later in-game tests overturned some of the desk model’s predictions too, the stage-size limit most visibly. Earlier still, the first cheats patched the wrong code: The “round timer” patch that was really editing rand() % 60.

Open problems, by how much they block

In the roadmap of 2026-10-21, the top open problem was whether the game would accept a re-encoded moveset at all; E1 answered it the same day. Close behind were a moveset rebuilder (built and proven) and the real stage-size ceiling (pushed to at least 7.7 MB). What remains:

Animation. The clip bitstream and the bone-to-joint map. Without them, a new fighter can only reuse existing animation.
The rest of the moveset. Hit and hurt boxes, the undecoded tables, AI data.
Memory in versus modes. Whether the stock player 2 overruns are harmless, and the true ceilings for larger fighters.
More than one new fighter. Growing the select grid past 20 cells.
New geometry. The vector-unit microcode, needed before models can grow.
New code. A map of space in the executable for new routines.
Presentation. The versus-screen portrait, intro and win-pose scripts.
Media. The video codec, the title images, and the 38.9 MB record 0.

Six research lanes were opened on 2026-10-21 to work through these in parallel: clips, moves, audio, presentation, rendering and media. This map will be revised as they report.

How the work is done

Every in-game result here came from a scripted PCSX2 run with no one at the controller: Testing a PS2 game with no one at the controller.

Open questions

Open

How are animation clips encoded, and which of the 23 animated bones drives which skeleton joint?
Open

Where are hit boxes and hurt boxes defined, and what do the remaining moveset tables hold?
Open

Are the stock fighters’ memory overruns as player 2 harmless in versus and arcade modes?
Open

Can the 20-cell select grid grow, so that more than one new fighter fits?
Open

What does the vector-unit microcode expect, so that models can gain vertices and bones?
Open

Where in the executable is there room for new code?
Open

What codec do the videos and title images use, and what are records 0 and 1120?

Sources and links

ROADMAP.md. Unpublished project notes. The synthesis of five desk reports and their verifications, 2026-10-21, with its in-game test list.
CRACK-BOARD.md. Unpublished project notes. The six research lanes opened on 2026-10-21 for what remains.

QL-0014
Tekken 4’s 2.57 GB archive keeps its index in the executable
Tekken 4 (PS2) stores almost everything in one 2.57 GB file, DATA.BIN, with no index inside it. The index is a 1,121-entry table in the game’s executable, and the archive’s only protection is a reversible flip of each file’s first 4 KB. Both are decoded, every checksum passes, and a modified disc that appends new files to the archive boots and plays.
Investigation RE.4 Reproduced
2026-10-23Rev. B
QL-0015
Tekken 4’s moveset files, decoded and edited in game
How Tekken 4 (PS2) stores each fighter’s moves: an LZSS-compressed “Character Data” file of twenty tables. The format is decoded well enough to rebuild all 22 stock movesets byte for byte, and edits made with it work in game: a move’s damage changed, a button rerouted, a brand-new move added, and one fighter’s whole moveset run on another’s body.
Investigation RE.4 Reproduced
2026-10-23Rev. B
QL-0016
Tekken 4’s stage format, and building a new stage from scratch
Each Tekken 4 (PS2) stage is four archive files, and the biggest is a 15-section container holding the geometry, textures, floor, walls, crowd and start positions. The geometry and wall formats rebuild the stock stages byte for byte, and a new stage 17, with its own geometry, textures, props and collision, loads and plays in PCSX2.
Investigation RE.4 Reproduced
2026-10-23Rev. B
QL-0020
Tekken 4’s sound system, from the hidden driver to the music tables
Tekken 4 (PS2) hides its sound driver inside the executable as a compressed, bit-inverted package; the project unpacks and repacks it, and the repacked driver runs identically. The banks, the sound-effect tables, the music track tables and the stage-to-music map are decoded, and music swaps, shortened tracks and replaced sound banks all work in PCSX2. Every result was read from memory: nothing has been checked by ear.
Investigation RE.4 Reproduced
2026-10-23Rev. B
QL-0019
Tekken 4’s character models, and editing them in place
Tekken 4 (PS2) fighters are CHRTK4 models: VIF packets of skinned vertices and textured strips that the PS2’s vector unit consumes directly. The format is decoded well enough to reshape a head, widen a body and build a 3D beard out of hidden hair meshes, all at the original size, and the results render in PCSX2. Adding new vertices or bones is still out of reach.
Investigation RE.4 Reproduced
2026-10-22Rev. A
QL-0017
How large can a Tekken 4 stage be? Bigger than predicted
A desk model of Tekken 4’s stage memory predicted the game would fail once a stage’s main file passed about 7.6 MB. In PCSX2, stages of 6.0, 6.6, 7.4 and 7.7 MB all loaded and played: the game gave up its pose cache and then shrank a second buffer instead of failing. The same run confirmed the crowd budget and the start-region mechanism.
Experiment RE.3 Observed
2026-10-22Rev. A

Revisions

Rev.	Date	Change
A	2026-10-22	First issue

Cite this entry

Chandler Snively. “Tekken 4 (PS2): a map of what’s known.” Quana Labs QL-0013, rev. A, 2026-10-22. https://quanalabs.com/n/13/

BibTeX

@misc{quanalabs:QL-0013,
  author       = {Chandler Snively},
  title        = {{Tekken 4 (PS2): a map of what’s known}},
  howpublished = {Quana Labs QL-0013, rev.~A},
  year         = {2026},
  month        = oct,
  url          = {https://quanalabs.com/n/13/}
}

Permanent link: https://quanalabs.com/n/13/

Write about this entry