Hacking Thought on making the downloads smaller

[demented]

Absolutely fantastic Dack. Top work.

 

[noONE]

Wow, Great. this will save a lot of time for many people, thanks Dack.

 

[MC DUI]

Since the testing seems to be going well do you think you might do a release soon?

I know a guy who does some Wii releases and I'm sure he would be interested in using this program.

Thanks!

 

[Dack]

Just emailed the link through to Thug4Life for release

Current results show a lot of files are getting down to the 1-2Gig mark.

 

[pro2oman]

any chance you could send be the beta for testing i have some free time so why not
but the way great work this will make life some much ezer, thx

 

[tjas]

Great work! next step mutiple game discs!

 

[Dirtie]

Other producers seem to be filling the dead space with random rubbish that doesn't compress.

More likely whatever software they use to generate the ISO does this automatically

I'm curious why the Puzzle Quest devs decided to put their own padding in though - maybe they liked working with a file that compressed better as well

?


Anyway, now that I understand the technical side of this app, I have to say well done. As far as I'm concerned it's still a bit of a 'dirty' method, but anything better would require knowledge of the encryption/signing routine and how to work that to your advantage (it'd be a hell of a lot of work in other words).

Unless...
Let's say a game tried to read a 'scrubbed' sector, and encountered an encryption header that contained just a bunch of FFs - these would obviously be invalid and you'd get a crash of some sort. Wouldn't it be safer to replace these with 'valid' encrypted sectors just like Puzzle Quest, so as long as it doesn't actually use the data (don't ask me why it'd be reading it in the first place, but this is just hypothetical), the game is less likely to crash/complain? The compression would only suffer the teeniest bit as well (assuming every 'trimmed' sector is the same)

Ideally the garbage data isn't random and conforms to some sort of algorithm so a byte-for-byte identical ISO could be built from a trimmed one (once we learn to resign/encrypt) - feel up to the challenge

?

 

[Dack]

I agree it's a really dirty method

I was thinking about that as I got up this morning.

What I am now going to do though is a minor tweak to the code (v1.1) that will replace the data not with 0xFFs but with a valid sector from the ISO being read. That way the sector header will not be so easy to detect in a scrubbed disc.

The other alternative is to keep the sector headers 0x400 bytes and blank the rest 0x7c00.

What I would suggest at the moment is that a difference file is created between the two ISOs (in and out) so that there is always the option of recreating the original ISO if there is a problem (that would be a 2 rar set release though - 1 = scrubbed image, 2 = diff file). The Diff file would effectively contain only the 'garbage' but should compress to 4.5G - whatever the scrubbed one contained as data.

 

[Xandecs]

Great Program, but about that key.BIN: Where could I find that file?

 

[Dack]

Google is your friend:

http://www.google.co.uk/search?hl=en&q=wii...+download&meta=

 

[Flawsdraw]

this program sounds brilliant, but i'm gonna wait until some1 tests a game to completion

otherwise, fucking brilliant Dack

you could be the saviour to my full HDD problem

 

[ninor]

Great Work, Dack!

Do you know if the version released here in GbaTemp is the final one?
(because neither in the readme nor the program specifies what version could be, apart from an 1.0 inside the about)

So, 1.0 it's the final one with the "safe" blank sector filling?

And many thanks, dude!

 

[PSXDupe]

I doubt it's the last as Dack has list a number of improvements he would like to.

Maybe we might see some source code soon. I would like to see that alright.

 

[Dack]

The version number is shown if you do a right hand click on the exe and look at the properties.

The one on here for download at the moment is 1.0.

The version I sent a PM about is version 1.0a - currently up on rapidshare but should be on here soon (if all goes well)

Version 1.0a has the 'safer' scrubbing option.

Source code will be available this weekend sometime.

 

[ganons]

Nice work man thats impressive I wonder if the scene will use your tool. Can the wii read cd's lol? Also I think you should implement Dacked after the image has been patched

 

[stormyuan]

update:

WiiFit(jp version) did work after "wiiscrubber" (1.0 & 1.0a both worked fine)

----
thx for Dack

 

[Flawsdraw]

was waiting for the first failed game, if i had the disks to test the games i got i would try em out and write a list

 

[Dack]

Report:

WiiFit(jp version) didn't work after "wiiscrubber"
Wii showed "can't recognize disc"Â :~~~

Thanks for letting me know - I'll try and get hold of a copy and see what's gone on.

Failing that if you could extract the data from the discs (using wii tools) for both the scrubbed and non scrubbed version and compare their outputs. That would then give some indication of what went wrong.

 

[pelago]

Can the wii read cd's lol?

Not sure if the Wii can read CDs or not, but for now we need to burn a full DVD-sized image, even if the game uses less than 700MB of real data, so we can only burn to DVDs. Maybe later...

 

[Flawsdraw]

i dont think the wii would be able to read data from a CD as good as it does from a DVD, different codings, specially if its a contains a movie file, CDs cant contain them as it dont have the needed information