Question Undo trimming = untrimmed?

Discussion in 'Switch - Exploits, Custom Firmwares & Soft Mods' started by NormanBates, Nov 8, 2019 at 7:35 PM.

  1. NormanBates
    OP

    NormanBates Newbie

    Newcomer
    1
    Friday
    Austria
    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.
     
  2. mezz0

    mezz0 Advanced Member

    Newcomer
    4
    Mar 10, 2009
    Belgium
    ::1
    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.
     
  3. FAST6191

    FAST6191 Techromancer

    pip Reporter
    24
    Nov 21, 2005
    United Kingdom
    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.
     
  4. KHANV1CT

    KHANV1CT GBAtemp Regular

    Member
    3
    May 22, 2013
    United States
    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.
     
  5. NormanBates
    OP

    NormanBates Newbie

    Newcomer
    1
    Friday
    Austria
    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.



    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 :wacko:. 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.
     
    Last edited by NormanBates, Nov 9, 2019 at 9:00 AM
  6. badpix11

    badpix11 Member

    Newcomer
    2
    Mar 14, 2017
    Serbia, Republic of
    Fairy World
    https://switchbrew.org/wiki/Gamecard_Format
    The Gamecard Header has stored the "original size":
    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.
     
  7. Garou

    Garou GBAtemp Maniac

    Member
    7
    Jan 13, 2015
    yes it's completely reversible as @badpix11 said

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

    nsw.

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

    zelda.PNG
     
  8. NormanBates
    OP

    NormanBates Newbie

    Newcomer
    1
    Friday
    Austria
    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?
     
  9. badpix11

    badpix11 Member

    Newcomer
    2
    Mar 14, 2017
    Serbia, Republic of
    Fairy World
    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
     
  10. NormanBates
    OP

    NormanBates Newbie

    Newcomer
    1
    Friday
    Austria
    Oh man, again, thank you very much for coming back. Ok i get it know - 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. :)
     
Quick Reply
Draft saved Draft deleted
Loading...