Hacking Question Undo trimming = untrimmed?

[NormanBates]

Hi, i wonder if a trimmed xci which i "untrimm" with ie. Xcutter - is absolutly the same as a untrimmed xci. I hope you guys know what i mean. Is trimming fully reversible?

Because if i use xcutter on a trimmed XCI to "fill it up" - it is then labeled as "untrimmed" in the switch backup manager.


Sorry for my english and thank you very much.

 

[mezz0]

Back in the day a trimmed release meant that 'fluff' like intro video's etc were removed to preserve space. Not sure if that is still the case. I would not risk it and simply download an untrimmed one.

 

[FAST6191]

Back in the day a trimmed release meant that 'fluff' like intro video's etc were removed to preserve space. Not sure if that is still the case. I would not risk it and simply download an untrimmed one.

I always associated the term rip with that one. Trimming being arguably a subset of that which removed any extra padding from the dumping process (if you have 64 megs of chip but only 58 of game then copying the entire contents of the chip will likely leave you with 6 megs of nothing interesting).

Anyway I don't know what goes here. For some consoles it is just a matter of pad out to next multiple of 2 size with 00 or FF values and that is that. Others might have lost some data (some of the Wii stuff being a good example, though we can now regenerate it https://gbatemp.net/threads/new-app...isc-images-in-playable-formerly-swiit.533402/ ) and if it is rips as defined above (we have not seen many in recent years make their way to download sites as everybody has unlimited download broadband and lots of storage but they were prolific during the original xbox) then that is actual data gone.

 

[KHANV1CT]

As far as I can tell it's fully reversible. I believe XCI Cutter uses header data to grab the cartridge size that the XCI was ripped from and it checks to make sure that whatever is trimmed off is indeed empty data. When you reverse it, it uses that same data to pad it back out to the original cartridge size.

 

[NormanBates]

... I would not risk it and simply download an untrimmed one.

Yep, but you don't always find untrimmed, working releases - ie. new super mario bros u deluxe, yoshis crafted world, links awakening, mario tennis aces.

As far as I can tell it's fully reversible ... it uses that same data to pad it back out to the original cartridge size.

I understand the process of filling it up again, but i wonder if the filling is really exact what was once trimmed. I'm just asking because i'm a bit monkish . So let's say the filling was all zeros - do they use again zeros to fill it up or do they use ffffffs instead. You know what i mean.

I imagine that programs like xcutter always use the same filling, ie. ffffffffffs because i can't think a way how xcutter could know what was trimmed, since it's gone. How much - yes, but what? I don't think so. Unless every cartridge is filled up the same way.

But i guess just scene people could tell us more about the filling, what the trimmed stuff looks like, if it's always the same ie. 000000 or ffffffff.

 

[badpix11]

https://switchbrew.org/wiki/Gamecard_Format

The entire rest of the Gamecard after the secure partition ends is all FF padding.

The Gamecard Header has stored the "original size":

Gamecard Size (0xFA = 1GB, 0xF8 = 2GB, 0xF0 = 4GB, 0xE0 = 8GB, 0xE1 = 16GB, 0xE2 = 32GB)

So trimming is remove all FFs after the secure partition and untrimming is to fill it with FFs until the "original size" has been restored.

 

[Garou]

yes it's completely reversible as @badpix11 said

here's an example with link's awakening. it's trimmed size is 6660774400 bytes

and if you open the file in hex editor, you'll find that all data after this offset are set to FF

 

[NormanBates]

Oh wow, thank you very much guys, this really helps. Cool to see how it looks. Just out of curiosity, shouldn't the size be 6660774384 because that's the last line with information - 6660774400 is the first line with fffs, or do the always end with on fffff line?

 

[badpix11]

You're welcome.
The trimmed size is correct, but there are no "lines" and you mixed up offset with length:
Offset starts with postion 0 = first byte and ends with position 666077399= last byte (0xB8)
So if you want to calc the length from hex viewer you need to add +15 from the line offset and +1 because the computer-world starts counting from 0 to the offset 6660774384 on the left
6660774384 + 15 + 1 = 6660774400 trimmed size

 

[NormanBates]

Oh man, again, thank you very much for coming back. Ok i get it now - you can also say - the offset number is always the "end" of the line before. So 6660774400 is the end of the offset line befor - which is, as you said befor, 6660774384 + the 16 "pairs" - so B8 is the pair nr. 6660774400. And this is the start of the next "line".

I know it's not the right explanation, but easy to remember.