Cracking Xenosaga III's iso Using the Lybac Toolkit

Almost 4 years ago I uploaded a very old collection of files that had been archived and passed around throughout the years to create Xenosaga alternative language packs. Since then, I have gotten many questions about how I extracted images out of the discs and how to use the pack for a variety of alternative uses. Today, I finally took the time to remember how to do all of this and to create a thread. So without further ado, let’s get cracking.

What you’ll need

Crack Kit: https://lifehold.godsibb.net/f/1c1cc164194d418f9365/
Xenosaga 3 ISOs: <placeholder they’re uploading>
7Zip: https://www.7-zip.org/

Getting Started and Understanding Files

  • Ensure you have installed 7 zip. Use “extract to” on .iso file to get the files

  • Xenosaga III’s data is divided into three bundles of multiple files for different categories of data. These represented data tables in the Playstation 2’s file system and told the console where the different assets were stored. In order to convert them to a readable format, we will need to identify the files and combine them.
  • The first bundle is X3.00, X3.01 and X3.02 it is on both discs. It contains all base assets that are not the cutscenes or message sound events. For example, static images and text content of message boxes. We’ll call this Bundle 0.
  • The next two are for cutscenes and sounds. The first is on disc 1 and consists of files X3.10 X3.11 X3.12 and X3.13. Let’s call this Bundle 1.
  • Finally on disk 2, you’ll find the remaining files - X3.20 X3.21 X3.22 X3.23. Bundle 2 will represent this set.
  • To get started, copy the contents of both disc 1 and 2 into a single folder so you can work in a clean space. Combined, it should look like the below

Combine the bundles

To get started with the extraction process, we’ll first need to combine the files in each respective bundle. File 0 in each bundle, e.g; those labeled ‘X3._0’ contain the tablelisting of every file in the bundle so the disc knows where to find the content at runtime. Do not combine ‘File 0’ into the .big file, it needs to remain separate.

To get started, first let’s combine the disc1 cutscene bundle, Bundle 1.

  • In Windows, open a Command Prompt session As Administrator and navigate to the folder where you’re keeping the files. For example, on my local machine:

  • Now run: copy /b X3.11 + X3.12 + X3.13 X31.big

  • This will produce a file called X31.big

  • Repeat the process for Bundle 2: copy /b X3.21 + X3.22 + X3.23 X32.big

  • You’ll now have X32.big

  • Repeat the process for Bundle 0, only two files this time. copy /b X3.01 + X3.02 X30.big

  • This creates X30.big

Staging

  • Create a new folder e.g; extract and copy the three .big files you generated into the folder.

  • Copy their File 0. E.g - X3.10, etc.

  • Copy over the Xenosaga II and III Extraction Kit:

  • Xeno23Lbae.exe extracts the munge file table from the .x0 file. Works with both Xenosaga 2 and 3.

  • Xenounpack.exe unpacks the munge file to a UNPACKED rep. You need an extracted table to make it work. It works with all three Xenosaga games.

  • xenorepack.exe repack the munge file and build a new table file (that you will need to repack with the last program). You still need the old extracted table for this program.

  • XenoLbar.exe repacks the table file given by xenoreapack.exe to a standard .x0 file. Needed if you’d like to rebuild the disc.

  • Create two folders bundle0, bundle1 and bundle2

  • Move the files from Bundle 1 to the bundle1 folder and Bundle 2 to the bundle2 folder

  • Copy the Extraction Kit files both folders - do not delete or move the files

Staging will look like the below:

Now we’re ready to decrypt each bundle.

Decryption and Extraction

The process for decryption is the same for Bundle 1 and 2 and very similar for Bundle 0. You’ll first use Xeno23lbae to decrypt the table of files, then you will use Xenounpack to view the contents. There will be quite a bit of noise to wade through in each bundle, but the above staging will help us keep it all sorted.

For example, for Bundle 1, navigate to its folder on Command Prompt and run:

  • Xeno23lbae X3.10 Lba1.txt This decrypts the table into a usable format so we can extract the .big file.

  • Xenounpack Lba1.txt X31.big This takes a little while. It will extract the bundle to a folder called UNPACKED using the decrypted table we created above


UNPACKED is where The Goodies are housed so to speak. We’ll talk more about the contents of these folders in a bit.

Do the same with Bundle 2 and Bundle 0

E.g;

  • Navigate to bundle0 and run: Xeno23lbae X3.00 Lba0.txt and Xenounpack Lba0.txt X30.big

Congratulations! We’re done extracting, now let’s see what we have.

File Contents

I’ll start in Bundle 0 since this has the greatest variety of stuff and is the least documented online, here we can find a lot of clearly labeled assets such as menu items and images, as well as some more mysterious items.

Clicking into some of these will reveal a lot of cool stuff off the bat, and I definitely encourage everyone to see what they can find and mine out of the data.



If you don’t know the right tool for a file format, try notepad, it works for a lot. I’ve found character lines, menu texts, supporting graphics, etc. Lots of modding potential in here!

But, you will also run into files that look like random characters when you open them. Don’t be alarmed. This just means we don’t have access to the right software to open that file format yet.

Finally, let’s wrap up this session by looking into one of those formats you can fix. In Bundle 1 and 2, you will find a folder called mov. This is where the cutscenes for the game live.

.sfd is a rather mysterious file type… Lybac’s previous instructions never told us how to convert these into something workable. Thankfully, if you google it, it is not a completely unknown file type. It was commonly used on the Sega Dreamcast and members of that modding community have given us tools intended to be used with games like SEGA Dreamcast Movie Creator and an old version of FIFA. If you google around, there seems to be some interesting overlap between Xenosaga and the RE2 port for as being standouts for having used this format for cutscenes in a PS2 game.

Previously I had used a script called SFD2MPG, which is hosted here. However, since I last took on this project, a better tool has come out.

https://github.com/alex-free/video2dreamcastdisc

This one looks like it’ll let us convert to better formats for upscaling. I’ll update the thread when I have a chance to use it.

In the meantime, please feel free to experiment and see what you find. Please post here if you have questions.

Thanks!

1 Like

I am trying to work on a Python script to replace this process and I’ll update everyone if I am successful. To help with that I have been feeding some files to CGPT5o from the Lybac set as well as Xenosaga’s rip and stuff I have pulled out of Ghidra. I thought this analysis was interesting. Sharing in case it’s helpful for anyone, although I’m aware some folks at other venues are ahead of me on some of this.

[quote]

1) Disc-level layout (what’s physically on the ISO)

Filesystem (ISO-9660/Joliet) — the root you listed via 7-Zip:

  • Code & overlays: SLUS_213.89, OV01.OVL, OV02.OVL, OV04.OVL

  • IOP modules: IOP\CRI_ADXI.IRX, IOP\LIBSD.IRX, IOP\IOPSUB.IRX, etc.

  • Master catalogs & data pools (the core of the game data):

  • Catalogs / small control files

  • X3.00 — name/group catalog (magic “mg1”), contains lots of canonical asset names (*.adx, *.tm2, *.xtx, *.sfd, *.dat, etc.)

  • X3.10, X3.20 — event catalogs (magic “evt”), enumerate event/script packs (sNNNNNN.xev/.xep, etc.) and embed CRI diagnostics

  • Large data pools (chunk families)

  • X3.01, X3.02 → Family A

  • X3.11, X3.12, X3.13 → Family B

  • These are 1 GB-class files (plus a ~573 MB and ~101 MB one) that actually store all the bytes for audio, video, textures, models, scripts, etc.

Key inference: the disc uses a catalog + pooled-data design:

  • Catalogs (X3.00/10/20) define what exists (names, event lists, groupings).
  • Each pool (X3.01…X3.13) stores the raw bytes.
  • A table of contents at the start of each big pool maps entry index → (offset, size, type/flags).

[HR][/HR]

2) Pool table evidence (what’s in X3.01_head_4MB.bin)

From the 4 MB header slice of X3.01:

  • The header begins with pointer tables → offsets to several small sub-tables.
  • One sub-table is a long list of aligned offsets (e.g., 0x05AC0000, 0x05D80000, 0x06000000, …), aligned to 0x10000 (64 KB) and 2048-byte sector boundaries. These offsets jump far beyond the header window (tens of MB), consistent with entry start positions for assets inside the pool.
  • Nearby sub-tables carry small, steadily increasing integers—likely sizes, counts, or type/flag fields.

Conclusion: each big X3.* file has a TOC in its head. Decoding one pool’s TOC format will let us list every entry’s (offset, size, maybe type) in that pool.

[HR][/HR]

3) Asset types confirmed so far (and how to handle them)

Type Where referenced What it is Runtime use How to extract / convert
ADX SLUS strings (snd/adx/%s.adx), CRI_ADXI.IRX CRI ADX audio IOP ADX driver streams/decodes to SPU2 Extract raw → vgmstream or ffmpeg to WAV; keep original ADX
SFD X3.00 names (e.g., titlebg1.sfd), SFD sample s060300.sfd CRI Sofdec movie (MPEG-PS with ADX audio) EE video playback + IOP audio via CRI ffmpeg: -c copy to MPG; -map to extract M2V/WAV; keep original SFD
TM2 (TIM2) X3.00 names (e.g., *.tm2) PS2 texture container Game textures Noesis, Tim2View → PNG; or parse header to dump
XTX Sample abel01_nol.xtx (magic XTX\0) Monolith texture wrapper over PS2 raster Textures, icons, UI Noesis (if plugin knows this flavor) or small custom converter → PNG
TXY Seen in SLUS strings; common in XS Game texture bundle (PS2-friendly) Textures Noesis first; else custom paletted/unswizzle script → PNG
XEV Sample s000100.xev (magic XEV ) Event/scene data (camera, lights, tracks) Cutscenes / scripted sequences Index and label; optional JSON dumper; not a standard media format
XEP Sample s000100.xep (magic Xc 01 03) Compiled event “program” Drives .xev scenes Index and label; later: structural dump for research
SME Sample asher_sp01a.sme (magic Xc 01 00) Mesh/model sectioned binary Models/geometry Index and label; future: export via custom script to OBJ/FBX
JPG/PNG/WAV/OGG General assets Standard images/audio UI, SFX Direct copy; optional normalization
AFS (possible) CRI strings in X3.10 mention AFS CRI archive Packs of ADX/TM2/etc. Table-accurate unpack → contained files

We also saw *.dat, *.map, *.bin in names. These are typically game-specific containers or tables (e.g., world/map data).

[HR][/HR]

4) Runtime flow (how the game uses all this)

  1. Boot: EE loads SLUS_213.89 → initializes IOP with LIBSD.IRX (sound), CRI_ADXI.IRX (ADX), others.
  2. Catalog load:
    1. X3.00 (mg1) name/group catalog provides canonical names and/or IDs.
  1. X3.10 / X3.20 (evt) enumerate event packs .xev/.xep.
  • Resource resolve:

  • Code maps requested name/ID → (pool family, entry index) using the catalogs.

  • Reads pool TOC (in X3.01/02/11/12/13 heads) to get (offset, size).

  • Streaming:

  • EE issues sceCdRead (via its file wrappers) against the pool file at computed absolute disc LBA.

  • For media: SFD video feeds Sofdec demux; ADX feeds the CRI ADX IOP decoder; textures/models go through in-engine decoders (TIM2/XTX/TXY/SME).

Address math you can rely on:

  • Disc absolute byte offset of a filesystem file start = LBA_file * 2048.
  • Disc absolute offset of an entry inside a pool = (LBA_pool * 2048) + pool_entry_offset.
  • Pool entry offsets are aligned (≥ 2048; often 64 KB), which matches your header findings.

[HR][/HR]

5) How to build a precise map (without guessing)

We already have enough to outline deterministic mapping:

  1. Get each pool file’s starting LBA (from ISO directory records or 7-Zip / your LBA lists).
    Save: pool_name, start_lba, start_abs = start_lba*2048.
  2. Parse each pool’s TOC (from its head region):
    Identify record count and per-record fields. Based on your X3.01_head:
    1. EntryStart*: aligned offset (e.g., 0x05AC0000)
  1. EntrySize[i]: likely a second table matching index i
  2. (Optional) Type/Flags: if present, helps auto-label media vs binary*[/i]
    *[i][i]
  • Join with catalogs for names:

  • X3.00 (mg1) provides canonical names for many IDs/groups.

  • X3.10/20 (evt) assign event pack names/IDs (sNNNNNN.xev/.xep) to entries.

  • For entries without names, infer from signatures (SFD/ADX/TM2/etc.) or leave as entry_####.bin.*[/i][/i]
    *[i][i]
    Compute absolute disc offsets for every entry:
    abs = pool_start_abs + EntryStart[i] — write these to a master CSV:

name, pool, entry_index, pool_offset, size, abs_disc_offset, type, notes

  1. Extraction & post-conversion:
    1. Copy each entry’s bytes out to files by type.
  1. Media: SFD → MPG(+WAV) (ffmpeg); ADX → WAV (vgmstream or ffmpeg).
  2. Textures: TM2/XTX/TXY → PNG (Noesis or custom).
  3. Models/scripts: keep raw; optional structure dumps for research.

This reproduces the kind of LBA map you mined before—but fully programmatic and name-aware.

6) Where each file you shared fits in this picture

  • SLUS_213.89: confirms extensions and path patterns (snd/adx/%s.adx, *.txy, *.tm2, *.xev/.xep); shows the engine expects assets by name/ID that the catalogs enumerate.
  • Overlays (OV*.OVL): additional code; not directly part of the asset layout, but contain callsites to the resource manager (useful for reverse-engineering).
  • CRI_ADXI.IRX / LIBSD.IRX / IOPSUB.IRX: confirm audio stack; ADX is decoded on IOP; the game’s ADX files may be standalone or packed—our pool tables will tell us where.
  • X3.00 (mg1): names/groups for almost all asset classes (ADX/SFD/TM2/XTX/etc.). This is the label source.
  • X3.10 & X3.20 (evt): event pack indexes; also carry CRI diagnostic strings (SFD/PS2EE v1.966), corroborating our SFD handling.
  • X3.01_head_4MB.bin: shows the TOC pattern (aligned offsets list + companion tables). This is the key to addresses.
  • s060300.sfd: a clean Sofdec clip (E0 video + C0 audio); validates that ffmpeg remux and audio extract paths work.
  • s000100.xev/s000100.xep: concrete samples of event/scene (XEV) and compiled program (XEP) formats—will be labeled and extracted by the pool map; later we can add structure dumps.
  • abel01_nol.xtx: confirms the XTX texture container, convertible to PNG with existing tools or a small parser.
  • Old LBA tables (Lba0/1/2): useful cross-checks; their LBA→file mappings will match our computed pool_start_abs + entry_offset math.

7) What’s still unknown (and how we’ll resolve it)

  • Exact pool TOC field layout (counts, record stride, location of sizes/types):

We’ve seen the offset list; we’ll confirm the size/flags table by comparing two pool heads (X3.01 vs X3.11) and correlating with carved signatures (SFD/ADX/TM2) from a few entries.

  • Name ↔ index binding granularity:

X3.00 looks comprehensive, but some indices may be grouped; we’ll correlate by counts and by checking extension signatures at the mapped offsets.

XTX/TXY internal fields:

Easy to finish once width/height/format bits are read off a few samples; Noesis can validate.[/i][/i][/i][/quote]*