GBAtemp Exclusive: WiiScrubber

  • Thread starter Thread starter Urza
  • Start date Start date
  • Views Views 232,501
  • Replies Replies 205
Hell yeah... blow me dudez for this great release!

Duh... useful for groups who have the key.bin file as well but useless for me.
hate2.gif
 
Will the groups use it though? They're not 100% accurate releases, if they're "wiped" first...

That's what I'm wondering too. The 'scene' has strict rules and as we know, NDS roms are never released in the pre-trimmed form either.


As already mentioned, it worked fine for Gamecube games.

As for ROM images (not only DS, but GB, GBC, GBA, N64, etc) any empty space at the end unused by the developers is usually filled with the same repeating pattern, usually 00 or FF in hex, which has the same effect once compressed as wiping an iso.

Also, I agree with Djoen, random checking of the garbage data could be included in future games, although this would probably only be a problem with online titles.

Also, there is the possibility for devs to sneakily hide files amongst the garbage data but not have them listed in the file system, and program the game to directly read certain sectors to retrieve the file. This way a tool like this could accidentally wreck the game. I'm probably thinking too far ahead though
smile.gif
 
Great for storage (I delete my Wii ISOs after burning them anyway) but they still take up a DVD. Think there'll ever be a Wii MultiGames app like GCOS for GC?
tongue.gif
 
Nice work!!
Very goood indeed,

but can anyone tell whether this works with PS2 or xbox iso's?

If you are actually serious then
wtf.gif


They most probably have different file structures and different ways of storing garbage data. I highly doubt it'd work with PS2 or XBOX isos.
 
Since the software is just so far ahead, it would probably cost very little to add a "brick-blocker" type of option that, at the same time, will add even a little bit more compression by wiping the update partition.

As you know, check number of partitions (32bits value at 0x40000) and decrease it by one (if there is more than 1 game one, of course). Then jump to the partition table (0x40020 most likely, follow the chain) and wipe out the first 4 bytes (& maybe the next 4 too, not sure).

After that, you'd have 1 less partition to worry about and can wipe that too, efectively "brick blocking" the game too.

Could be cool as an option. And save a bit more space for high-compressible padding.

Here is how to do it from the source code by Waninkoko of the wii update remover:

CODE#include
#include
#define _FILE_OFFSET_BITS 64
#ifdef __WIN32__
#define fseekoÂÂÂÂfseek
#endif
#define VERSION "1.0"

inline void be32(unsigned int *x)
{
ÂÂÂÂ*x = (*x>>24) |
     ((*x8) & 0x0000FF00) |
     (*x
 
Very well done Dack, i was following the other thread in the hacking section with great interest and its great to see your app as a proper news item here on GBAtemp.

I look forward to seeing all the shovelware reduced down to its actual (crappy) size and all the decent stuff made more available for those of us who don't own an LG 8164b drive and have a d/l limit on our Internet connections.

bow.gif
to you my friend, we are indeed not worthy.
 

Site & Scene News

Popular threads in this forum