Hacking WDF = Wii Disc File

[mousex]

He just said you should use .wbfs files instead of .wdf files because the size is nearly the same.

 

[zx3junglist]

He just said you should use .wbfs files instead of .wdf files because the size is nearly the same.

you're right, I guess I misread his post. So if I understand, there's really no advantages to implementing WDF support in loaders since we already have .wbfs file support?

 

[Wiimm]

@wiimm:
Oh and another thing I remembered, a while ago i looked at the .wdf format for the possibility of playing it directly from the usb loader, but unfortunately in it's current form it is not suitable because data is not sector aligned. If I recall, the header is about 64 bytes long and then followed immediately by data. I would suggest to increase the header size to either 512 bytes or maybe even to 4096 bytes since this is becoming a popular sector size...

A first idea for WDF version 2:
An additional variable behind the end of header of version 1 describes the alignment factor. This factor can be any number between 1 and 0xffffffff. This extension is fully compatible with version 1 programs. The second new member 'wdf_compatible_version' describes this down compatibility (V1 tools don't care of this).

A for Wii well designed WDF the factor should be 512 or 4096 or 32768.

A USB loader must read the header V2, test if the version is >=2 and the alignment factor is a multiple of 512 (or other needed values).

CODEtypedef struct WDF_Head_t
{
ÂÂÂÂ// magic and version number
ÂÂÂÂchar magic[WDF_MAGIC_SIZE];ÂÂÂÂÂÂÂÂ// WDF_MAGIC, what else!
ÂÂÂÂu32 wdf_version;ÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂ // WDF_VERSION

ÂÂÂÂ// split file support (not used)
ÂÂÂÂu32 split_file_id;ÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂ // for plausibility checks
ÂÂÂÂu32 split_file_index;ÂÂÂÂÂÂÂÂÂÂÂÂÂÂ// zero based index ot this file
ÂÂÂÂu32 split_file_num_of;ÂÂÂÂÂÂÂÂÂÂÂÂ // number of split files

ÂÂÂÂ// virtual file infos
ÂÂÂÂu64 file_size;ÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂ // the size of the virtual file

ÂÂÂÂ// data size of this file
ÂÂÂÂu64 data_size;ÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂ // the ISO data size in this file
ÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂ // (without header and chunk table)
ÂÂÂÂ// chunks
ÂÂÂÂu32 chunk_split_file;ÂÂÂÂÂÂÂÂÂÂÂÂÂÂ// which spit file contains the chunk table
ÂÂÂÂu32 chunk_n;ÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂ // total number of data chunks
ÂÂÂÂu64 chunk_off;ÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂ // the 'MAGIC + chunk_table' file offset

ÂÂÂÂ//---------- here ends the header of WDF version 1 ----------

ÂÂÂÂu32 wdf_compatible_version;ÂÂÂÂÂÂÂÂ// this file is compatible down to version #
ÂÂÂÂu32 align_factor;ÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂ// all data is aligned with a multiple of #
ÂÂÂÂu8ÂÂbca_data[64];ÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂ// 64 bytes for BCA data

} __attribute__ ((packed)) WDF_Head_t;

 

[fgghjjkll]

I really don't know anything but what about a tiny space to fake a game's barcode one the disk (or whatever. BCA or something). It would stop MANY anti piracy checks...

 

[sonicsleep]

I'm a little confused... Please tell me if I am understanding this right...
So.. WDF is pretty much just the game without any rubbish data. It doesn't compress the entire thing, just the zeros. Because of this it is easy to convert into other formats. It also has the possibility of being used by usb loaders as well.

so a .wdf is pretty much the same as a .wbfs file except it's a much leaner system.

If the above is correct, you would be insane to bother with .wdf unless it was implemented by some usb loaders. Otherwise you could just use .wbfs which is a little bigger but can be used as either storage or to just play the game on the wii.

However if .WDF was picked up for usb loaders then I guess it would be the way to go.

 

[Wiimm]

I have added the member 'bca_data'.

And what's about:
- preferred_ios
- preferred_title
- load_counter

 

[WaRMarinE]

ever heard of cISO ?

Epic WIN. LMAO!!

 

[ChokeD]

PS: I don't feel like using WiiScrubber and then compressing the ISOs because i'll have to unzip them again before adding them to WBFS.

No, you don't wbfs backup manager reads rar files and unpacks scrubs and transfers files to HDD.



So, if I'm reading this stuff correctly the wdf file isn't compressed so to speak but yet trimmed of the data that doesn't need read by the Wii ?? Wouldn't that speed up the read times possibly preventing or helping lag in some games ???


Thanks for all the good stuff your putting out there for us.

 

[Wiimm]

(de-)compressing ÂISOs is waste of time because the the needed data is crypt and have nearly the same size as uncompressed. WDF allows direct (random) access. For example, the tool 'wit' can scan or rename ID and title of a WDF very fast -- try this with a cISO.

I asked many times but nobody can tell me, what cIOS is in technical details. And so I had implemented WDF a half year ago. All my backpus are stored as WDF. I think WDF is better than any compressed format. And now we discuss a new extended version of WDF which is direct usable by usb loaders and store all additionally infos needed (like BCA). Oggzee made the first suggestions.

 

[oggzee]

(de-)compressing ©ISOs is waste of time because the the needed data is crypt and have nearly the same size as uncompressed. WDF allows direct (random) access. For example, the tool 'wit' can scan or rename ID and title of a WDF very fast -- try this with a cISO.

I asked many times but nobody can tell me, what cIOS is in technical details. And so I had implemented WDF a half year ago. All my backpus are stored as WDF. I think WDF is better than any compressed format. And now we discuss a new extended version of WDF which is direct usable by usb loaders and store all additionally infos needed (like BCA). Oggzee made the first suggestions.

To clear the cISO lack of info a little bit, ... I too was confused by it, and the reason is because there are 2 different cISO formats floating around:
- one is by pismo tech: http://www.pismotechnic.com/ciso/
which supports all kinds of compression and encryption and who knows what more
- the other one used by hermes wbfs_win and wii backup manager and I think nubecoder ncWBFS tool (which uses the extension .wbi instead of .ciso exactly because a different .ciso format already exists)
The two formats are not compatible in any way.
The .ciso format by hermes (not sure if he is the original implementator) is very simple, does not support any kind of compression - only skipping of unused blocks (scrubbing), it's more similar to WDF and WBFS but much simpler, so this format too allows random access and is suitable for direct loading (which uLoader also supports)
Basically cISO by hermes looks like this:

4 bytes: CISO
4 bytes: block size (int32) (usually 4MB)
32k-8bytes: byte map of used blocks
DATA BLOCKS

in other words:

struct ciso_header {
char tag[4];
int32 block_size;
char map[32*1024-8];
};

So, data is 32k aligned and scrubbed.
btw, I looked into how .ciso looks like only recently, since the only place where i could find this info is source code of hermes wbfs_win.

 

[Wiimm]

@oggzee
Thanx for info

 

[pokeparadox]

He just said you should use .wbfs files instead of .wdf files because the size is nearly the same.

you're right, I guess I misread his post. So if I understand, there's really no advantages to implementing WDF support in loaders since we already have .wbfs file support?

WDF is a more refined format... it really SHOULD become widely supported by USB loaders, IMO.

 

[WiiUBricker]

Why should I use WDF instead of simply trimming an ISO with WiiScrubber? The file size would be the same without any compression required and speed should also be similar to WDF.

 

[Wiimm]

4 bytes: CISO
4 bytes: block size (int32) (usually 4MB)
32k-8bytes: byte map of used blocks
DATA BLOCKS

I have taken a look into the uloader sources. If extracting from WBFS the block size is the same as "wbfs_sec_sz" (WBFS sector size).

And after analyzing the CISO format I think there is only need for WDF V2 when additional info like BCA should be stored. Without more info CISO is a good container for scrubbed ISOs if the block size is a multiple of 32768 (the wii disc sector size). To keep the mapping table small greater minimal block size or a maximal block number might be required.

 

[forbore]

It's been a while since I last followed what was happening on the scene (at least 6 months) but IMO WDF is a great format for Wii files. It's easy to use, very fast, and does not need any compression. I don't know about the other formats released "recently" but WDF works very well.

 

[wishmasterf]

Is there any USB-loader which is able to use wdf?

 

[Richardarkless]

Is there any USB-loader which is able to use wdf?

wdf is old, wiimms newest creation is wia (wii iso archive) which makes games even smaller, unfortunately both wdf and wia is only used for backup purposes, not for usb game loading and it never will be

 

[wishmasterf]

Is there any USB-loader which is able to use wdf?

wdf is old, wiimms newest creation is wia (wii iso archive) which makes games even smaller, unfortunately both wdf and wia is only used for backup purposes, not for usb game loading and it never will be

I know about that, but wia will never be used to load games in usb-loader because of the compression, but i think wdf could be used to load games.

 

[sorgelig]

We already have WBFS. May be it's worse in saving space (due to 2mb chunks), worse structure, etc... But it was first and already implemented in all loaders. Someone (me for example) is keeping all Wii ISOs in WBFS file format. While WDF looks better, it's not revolutionary better. There is no reason to convert all you library to WDF. You won't get anything noticeable. Even adding new ISO as WDF is not reasonable since it's better to keep all ISOs in the same format.

WDF has been appeared tooo late, sorry.

 

[Wiimm]

I agree mostly.

But WDF was there before WBFS files are used by USB loaders. I developed WDF to save disc space. Since the beginning of wwt/wit I'm using WBFS files instead of WBFS partitions for test purposes. If I remember right some month later oggzees has the idea to use WBFS files with only 1 image for USB loaders.