Hacking CISO file format

Wiimm

Developer
OP
Member
Joined
Aug 11, 2009
Messages
2,292
Trophies
1
Location
Germany
Website
wiimmfi.de
XP
1,521
Country
Germany
CISO file format

I have analyzed the CISO format by studying the source code of uLoader. Here I will explain the results and hope that anyone can confirm them.

Data Structure

Code:
enum // some constants
{
CISO_HEAD_SIZE	   = 0x8000,			 // total header size
CISO_MAP_SIZE		= CISO_HEAD_SIZE - 8, // map size
CISO_MIN_BLOCK_SIZE  = WII_SECTOR_SIZE,	// minimal allowed block size
};

typedef struct CISO_Head_t
{
u8  magic[4];			// "CISO"
u32 block_size;		  // stored as litte endian (not network byte order)
u8  map[CISO_MAP_SIZE];  // 0=unused, 1=used, others=invalid

} __attribute__ ((packed)) CISO_Head_t;

Each CISO file has a header with 32 KiB (32768 bytes). The first 4 bytes are the magic "CISO". The next 4 bytes are a 4 byte integer stored in little endian (intel format but not network byte order).


The MAP

The map uses the rest of the head (32760 bytes). Each byte represents a ISO block with given block size. A '1' means that the block is stored in the file, a '0' means that it is not stored (and is logical filled with zeros).

If reading from a CISO it is good to transform the map into a other map:

CODE typedef u16 CISO_Map_t;
const CISO_Map_t CISO_UNUSED_BLOCK = (CISO_Map_t)~0;

CISO_Head_t * head = ...
CISO_Map_t ciso_map[CISO_MAP_SIZE];
CISO_Map_t count = 0;
int idx;
for ( idx = 0; idx < CISO_MAP_SIZE; idx++ )
ciso_map[idx] = head->map[idx] ? count++ : CISO_UNUSED_BLOCK;

Reading a byte from the CISO file looks like this:
Code:
u8 ReadByteCISO ( ... file, CISO_Map_t * ciso_map, u32 block_size, off_t iso_off )
{
const u32 block = iso_off/block_size;
if ( block >= CISO_MAP_SIZE || ciso_map[block] == CISO_UNUSED_BLOCK )
return 0;

// calcualte the base address
u32 file_off = ciso_map[block] * (u64)block_size + CISO_UNUSED_BLOCK;

// add the offset inside the block
file_off += iso_off - block * (u64)block_size;

return ReadByte(file,file_off);
}


Good block_size


It seems that block_size must be a multiple of WII_SECTOR_SIZE (= 32 KiB = 32768).

To store a complete Wii disc with 4 699 979 776 bytes the block size must be at least 5*32=160 KiB and for double layer 320 KiB.

When extracting a disc from WBFS the uLoader software uses the WBFS sector size (multiple of 2 MiB) as CISO block size. The 'isotociso' tool (part of uLoader source) uses a fixed block size of 4 MiB. These block sizes are much larger and the ciso files grow a litle bit.

My Questions:
  • Is the block size always a multiple of 32768 (32 KiB)?
  • Must the block size be a power 2?
  • Is there a importand minimal CISO block size?
  • Does a USB loader need a max block limitation to limit the size of the internal mapping table?

wwt + wit


I have implemented CISO support into my WWT tools.

If writing the block size is at least 1 MiB, but the maximum used block number never exceeds 8192.

If reading a CISO plausibility checks are done to verify a valid CISO:
  • The magic must be "CISO".
  • The block size must be a multiple of 32 KiB.
  • No other values than 0 and 1 are allowed for the map.
  • The filesize must be correspondent to the number of used blocks.
My Question:
  • Are other values than 0 and 1 allowed for the map?
 

smf

Well-Known Member
Member
Joined
Feb 23, 2009
Messages
6,774
Trophies
2
XP
6,175
Country
United Kingdom
Wiimm said:
Nobody out there who knows about CISO?

I supported it in ooWii, I used 0 means not used & anything else means used.
No idea why it doesn't just use one bit per block.
 

Wiimm

Developer
OP
Member
Joined
Aug 11, 2009
Messages
2,292
Trophies
1
Location
Germany
Website
wiimmfi.de
XP
1,521
Country
Germany
I have a little discussion with user Satur9. We found out that the block size should be a power of 2. I have changed this in WWT.

btw:
I'm sad that none of the CISO developers will talk with me
frown.gif


I think that CISO with some limitations (block size and maximal used blocks) could be the right format for USB loaders. And handling is better than for sparse files (on non wii systems).
 

Site & Scene News

Popular threads in this forum

General chit-chat
Help Users
  • No one is chatting at the moment.
  • K3Nv2 @ K3Nv2:
    Sounds familiar to some peeps I know tbh
  • kijetesantakalu042 @ kijetesantakalu042:
    Miku is cool and all but you shouldn't let an instrument control your life.
  • kijetesantakalu042 @ kijetesantakalu042:
    Also that article is pretty badly written. Miku isn't just a hologram
  • K3Nv2 @ K3Nv2:
    He said this and I don't like it but other person said the same thing blah blah blah
  • K3Nv2 @ K3Nv2:
    I gotta comment on everything
  • K3Nv2 @ K3Nv2:
    That's not a comment it's question marks
  • kijetesantakalu042 @ kijetesantakalu042:
    It explains what I'm feeling
  • K3Nv2 @ K3Nv2:
    You've been here for like a decade you should know to comment on everything
  • kijetesantakalu042 @ kijetesantakalu042:
    I don't understand what you are saying and I've been here for less than a year
  • K3Nv2 @ K3Nv2:
    O I was talking to myself
  • SylverReZ @ SylverReZ:
    Good morning guys
  • SylverReZ @ SylverReZ:
    @K3Nv2, I've been around for two whole years (nearly three).
  • Veho @ Veho:
    Haven't you had enough?
  • Veho @ Veho:
    Almost three years, aren't you bored of the Temp by now?
  • SylverReZ @ SylverReZ:
    Not necessarily, it hasn't felt like a long time to me. Unless it was ten or twenty years then I'll consider retiring.
  • K3Nv2 @ K3Nv2:
    Make it a porn site again so we can really know each other
    +1
  • Veho @ Veho:
    Biblically.
    +1
  • K3Nv2 @ K3Nv2:
    Make Temp Bust Again
    +1
  • SylverReZ @ SylverReZ:
    Make GBAtemp the biggest cummunity
    +1
  • Veho @ Veho:
    Cum unity.
    +1
    Veho @ Veho: +1