Pokémon Super Mystery Dungeon Model Ripping Project

[Lilothestitch]

As lilo said, it doesnt work. even tho it GAVE me a BCH file thats about 230MB, and shows no model or texture data in Ohana.

Right now, I've written one that just extracts CGFX files. However, I'm working on one that extracts BCH files also. Hope I can get that out by tommorow.
Though I'm not exactly sure how it'll do that :/

EDIT:

Code:

idstring "FARC"
get Size asize

for i = 0
    SavePos Position
    if Position == SIZE
        break
    endif
    get PATH basename
    FindLoc Offset string "CGFX"
    goto Offset
    idstring "CGFX"
    get Endianness short
    get Length short
    get Revision long
    get FileLength long
    goto Offset
    goto FileLength 0 SEEK_CUR
    string PATH += i
    string PATH += ".cgfx"
    log PATH Offset fileLength
next i

Are you using the hex editor?
So far this extracts the CGFX files but not BCH. Hopefully I figure that out soon.

[Demonslayerx8]

pretty much the only way to look into the data files Lilo is via HEX editor. Thats how i found out it was an FARC archive with multiple BCH files inside them. I didnt find any with CGFX/BCRES data tho.

[Lilothestitch]

pretty much the only way to look into the data files Lilo is via HEX editor. Thats how i found out it was an FARC archive with multiple BCH files inside them. I didnt find any with CGFX/BCRES data tho.

I understand. I hope we find something soon.

[Struggleton!]

I've actually transitioned into using C# for this. It'll allow me to do this easily. In fact I have my extractor done, but I'm testing it right now. And yeah I use a Hex Editor to look at files. It works for extracting CGFX and BCH files. However this program is a little gimmicky, because I'm not about to get into decoding that SIR0 offset table

[Lilothestitch]

I've actually transitioned into using C# for this. It'll allow me to do this easily. In fact I have my extractor done, but I'm testing it right now. And yeah I use a Hex Editor to look at files. It works for extracting CGFX and BCH files. However this program is a little gimmicky, because I'm not about to get into decoding that SIR0 offset table

That is great. I'm looking forward to trying it out.

[Demonslayerx8]

hah yeah, i saw that SIRO table also, and just like with Chibi Robo! Zip Lash, it also has a table, but not a Siro table, its ASST table

[Struggleton!]

SIR0 does some weird stuff with encoding and stuff
EDIT: Unpacker is done. Didn't test too much with BCH support, but here: https://www.dropbox.com/s/7zcwt53sqepwyy...r.exe?dl=0
It might take a while to unpack some larger files.
Edit 2: Quick update! Unpacker unpacks wayyyyyyy faster now

[gdkchan]

SIR0 does some weird stuff with encoding and stuff
EDIT: Unpacker is done. Didn't test too much with BCH support, but here: https://www.dropbox.com/s/7zcwt53sqepwyy...r.exe?dl=0
It might take a while to unpack some larger files.
Edit 2: Quick update! Unpacker unpacks wayyyyyyy faster now

Someone sended me one of those FARC files some time ago... Not sure if is the same structure of the file you guys are looking, but I already did some research on it, here is the structure:

Code:

0x0 - FARC Signature
0x20 - Number of files
0x24 - SIR0 Offset
0x28 - SIR0 Length
0x2C - Data Offset

SIR0 Table Structure
(All offsets here are relative to the SIR0 offset)
0x0 - SIR0 Signature
0x4 - Offset to Pointers Table
0x8 - Offset to encoded Relocation Table
0xC - Padding only
(String table with file names starts after this, they're UTF16 and Null Terminated)

Pointers Table
0x0 - Offset to the Files Table
0x4 - Total number of files

Files Table
(Each entry have 0x10 bytes)
0x0 - Offset to the Name of the file (relative to the SIR0 offset)
0x4 - Offset to the File Data (relative to Data Offset at 0x2C, see first header)
0x8 - Length of the file in bytes
0xC - Only 0x0 was observed, may be related to compression tho

Just didn't cared to write a unpacker yet.

[Farlavor]

on my personal opinion... the Gateway method has got pretty obsolete... indeed you may use that method if you want. but I had tested the method and honestly, it didn't worked as expected. but fortunately for you, you can rip model files from a CIA file, Give it a shot. just convert your 3DS rom into a CIA and use 3DS explorer. CIA's FS is 100% decrypted so you don't need any *censored* Xorpads.

I have to test it for my 3DS model ripping projects. but I'm kinda busy and have some problems... (Having lower than 10GB of disk space)

[gdkchan]

on my personal opinion... the Gateway method has got pretty obsolete... indeed you may use that method if you want. but I had tested the method and honestly, it didn't worked as expected. but fortunately for you, you can rip model files from a CIA file, Give it a shot. just convert your 3DS rom into a CIA and use 3DS explorer. CIA's FS is 100% decrypted so you don't need any *censored* Xorpads.

I have to test it for my 3DS model ripping projects. but I'm kinda busy and have some problems... (Having lower than 10GB of disk space)

CIAs are encrypted too. BUT you may be lucky enough to find an already decrypted CIA on the webs (I already found a bunch).

[Lilothestitch]

I extracted the pokemon_graphic.bin file but when I open one of the bch in ohana, it gave me no model. Can you update this extractor?

[eureka]

Probably a different variant of BCH then. Extractor wouldnt be the problem i dont think, theres quite a few variants of BCH in 3ds games iirc.

[Lilothestitch]

Probably a different variant of BCH then.  Extractor wouldnt be the problem i dont think, theres quite a few variants of BCH in 3ds games iirc.

Its a possibility.

[Struggleton!]

Some of the BCH files have only textures. Try switching into 'Textures' mode and seeing if that works.

SIR0 does some weird stuff with encoding and stuff
EDIT: Unpacker is done. Didn't test too much with BCH support, but here: https://www.dropbox.com/s/7zcwt53sqepwyy...r.exe?dl=0
It might take a while to unpack some larger files.
Edit 2: Quick update! Unpacker unpacks wayyyyyyy faster now

Someone sended me one of those FARC files some time ago... Not sure if is the same structure of the file you guys are looking, but I already did some research on it, here is the structure:

Code:

0x0 - FARC Signature
0x20 - Number of files
0x24 - SIR0 Offset
0x28 - SIR0 Length
0x2C - Data Offset

SIR0 Table Structure
(All offsets here are relative to the SIR0 offset)
0x0 - SIR0 Signature
0x4 - Offset to Pointers Table
0x8 - Offset to encoded Relocation Table
0xC - Padding only
(String table with file names starts after this, they're UTF16 and Null Terminated)

Pointers Table
0x0 - Offset to the Files Table
0x4 - Total number of files

Files Table
(Each entry have 0x10 bytes)
0x0 - Offset to the Name of the file (relative to the SIR0 offset)
0x4 - Offset to the File Data (relative to Data Offset at 0x2C, see first header)
0x8 - Length of the file in bytes
0xC - Only 0x0 was observed, may be related to compression tho

Just didn't cared to write a unpacker yet.

Yeah, that's the SIR0 format we were talking about. I heard it's offsets were encoded, and to use them they needed to be decoded. Things may have changed, so I don't know but that's what I heard. Thanks GDKChan, this is really helpful

[Lilothestitch]

Some of the BCH files have only textures. Try switching into 'Textures' mode and seeing if that works.

SIR0 does some weird stuff with encoding and stuff
EDIT: Unpacker is done. Didn't test too much with BCH support, but here: https://www.dropbox.com/s/7zcwt53sqepwyy...r.exe?dl=0
It might take a while to unpack some larger files.
Edit 2: Quick update! Unpacker unpacks wayyyyyyy faster now

Someone sended me one of those FARC files some time ago... Not sure if is the same structure of the file you guys are looking, but I already did some research on it, here is the structure:

Code:

0x0 - FARC Signature
0x20 - Number of files
0x24 - SIR0 Offset
0x28 - SIR0 Length
0x2C - Data Offset

SIR0 Table Structure
(All offsets here are relative to the SIR0 offset)
0x0 - SIR0 Signature
0x4 - Offset to Pointers Table
0x8 - Offset to encoded Relocation Table
0xC - Padding only
(String table with file names starts after this, they're UTF16 and Null Terminated)

Pointers Table
0x0 - Offset to the Files Table
0x4 - Total number of files

Files Table
(Each entry have 0x10 bytes)
0x0 - Offset to the Name of the file (relative to the SIR0 offset)
0x4 - Offset to the File Data (relative to Data Offset at 0x2C, see first header)
0x8 - Length of the file in bytes
0xC - Only 0x0 was observed, may be related to compression tho

Just didn't cared to write a unpacker yet.

Yeah, that's the SIR0 format we were talking about. I heard it's offsets were encoded, and to use them they needed to be decoded. Things may have changed, so I don't know but that's what I heard. Thanks GDKChan, this is really helpful

Which BCH Files use models?