(11-25-2015, 09:27 PM)ThatTrueStruggle Wrote: [ -> ] (11-25-2015, 08:06 PM)Demonslayerx8 Wrote: [ -> ]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.
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.
(11-26-2015, 01:39 AM)Demonslayerx8 Wrote: [ -> ]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.
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
(11-26-2015, 02:54 AM)ThatTrueStruggle Wrote: [ -> ]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.
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
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
(11-26-2015, 07:07 AM)ThatTrueStruggle Wrote: [ -> ]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.
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)
(11-26-2015, 09:12 AM)Farlavor Wrote: [ -> ]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).
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?
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.
(11-26-2015, 10:56 AM)eureka Wrote: [ -> ]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.
Some of the BCH files have only textures. Try switching into 'Textures' mode and seeing if that works.
(11-26-2015, 08:55 AM)gdkchan Wrote: [ -> ] (11-26-2015, 07:07 AM)ThatTrueStruggle Wrote: [ -> ]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
(11-26-2015, 11:25 AM)ThatTrueStruggle Wrote: [ -> ]Some of the BCH files have only textures. Try switching into 'Textures' mode and seeing if that works.
(11-26-2015, 08:55 AM)gdkchan Wrote: [ -> ] (11-26-2015, 07:07 AM)ThatTrueStruggle Wrote: [ -> ]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?