Hacking VCFE Wip...

  • Thread starter Thread starter HowardC
  • Start date Start date
  • Views Views 140,229
  • Replies Replies 628
  • Likes Likes 2
The only way Howard's tool would cause a brick if the 00.app is compressed with LZ77.

When repacking the Banner or Icon, use the IMD5 Header (I advise you don't compress them).
When repacking the 00.app, use the IMET (Banner Info) Header (DON'T COMPRESS IT!).
 
RadioShadow said:
The only way Howard's tool would cause a brick if the 00.app is compressed with LZ77.

When repacking the Banner or Icon, use the IMD5 Header (I advise you don't compress them).
When repacking the 00.app, use the IMET (Banner Info) Header (DON'T COMPRESS IT!).
but the original banner.bin and icon.bin are already LZ77 compressed with C64 wads but i think if this is the case then repacking it with LZ77 compression can be the issue of the hash problem...

but can't it cause a banner brick when you don't compress the same way?
 
You've been talking to wiicrazy too much. With all due respect to him, he used my tool before he even researched which settings you are supposed to use to pack a 0.app and THAT is why it bricked. I felt so bad about it I actually pulled my tool and put checks in place that'll prevent the app from even packing a 0.app with the wrong settings (assuming it's called 00000000.app and hasn't been renamed, and/or the folder is called 00000000_app_OUT). If you are still worried use the "get settings from file" button. The few bricks that occured were NOT due to bugs, simply user error. People (wrongly) assumed that IMET (banner info) was for the banner.bin because it has banner in the desc, and therefore, by process of elimination, imd5 was for the 0.app itself and I (wrongly) assumed that anybody using my tools already knew the proper settings due to gally's app. Also the new option of lz77 compression seemed to confuse people. Lz77 is only used for the banner.bin and icon.bin and pretty much nothing else. It isn't even necessary to use it, I just included it because people who are hacking discs need the files to be the same size.

That isn't to say there aren't bugs, there are indeed bugs, but afaik none that would brick your wii.

With all that said... USE AT YOUR OWN RISK ect... ect....

For the record I don't show the hash because the user never needs to see it and there's no possible way they could enter it manually. The intention of my tools is to make things easier than gally's, which are quite cumbersome when it comes to re-packing and to improve functionality.

And RS is right, the ONLY possible way you can brick is to put lz77 compression on a 0.app, any other errors can be caught by the wad installer itself.
 
HowardC said:
You've been talking to wiicrazy too much. With all due respect to him, he used my tool before he even researched which settings you are supposed to use to pack a 0.app and THAT is why it bricked. I felt so bad about it I actually pulled my tool and put checks in place that'll prevent the app from even packing a 0.app with the wrong settings (assuming it's called 00000000.app and hasn't been renamed, and/or the folder is called 00000000_app_OUT). If you are still worried use the "get settings from file" button. The few bricks that occured were NOT due to bugs, simply user error. People (wrongly) assumed that IMET (banner info) was for the banner.bin because it has banner in the desc, and therefore, by process of elimination, imd5 was for the 0.app itself and I (wrongly) assumed that anybody using my tools already knew the proper settings due to gally's app. Also the new option of lz77 compression seemed to confuse people. Lz77 is only used for the banner.bin and icon.bin and pretty much nothing else. It isn't even necessary to use it, I just included it because people who are hacking discs need the files to be the same size.

That isn't to say there aren't bugs, there are indeed bugs, but afaik none that would brick your wii.

With all that said... USE AT YOUR OWN RISK ect... ect....

For the record I don't show the hash because the user never needs to see it and there's no possible way they could enter it manually. The intention of my tools is to make things easier than gally's, which are quite cumbersome when it comes to re-packing and to improve functionality.

And RS is right, the ONLY possible way you can brick is to put lz77 compression on a 0.app, any other errors can be caught by the wad installer itself.

so what you are saying is that i should not compress the banner an icon.bin even if the original is compressed wit LZ77? and it won't make a banner brick?

btw, it is not that i talked to much with wiicrazy who had his wii bricked with your tool, but because i had a banner brick with gally's and i want to make sure i don't have a new banner brick... btw, are there any banner bricks that cannot be restored with the recovery menu from starfall?
 
gundalf said:
For me, an uncompressed banner.bin for C64 gives an corrupted banner.

You're probably doing something wrong. In fact, I'm writing a quick guide what you're suppose to do.

EDIT:

Follow the guide:

1 - Unpack the Wad (find out how to do this your self).
1.png


2 - This is what you should have if you have unpacked the wad correctly:
2.png


3 - Open U8 Tool and press the '...' button (see blue circle in image).
3.png


4 - Open up the '00000000.app'.
4.png


5 - Click on 'Extract'.
5.png


6 - Should get a message about a '00000000_app_OUT' folder that has been created.
6.png


7 -Inside that folder is a 'meta' folder. Inside that folder are three files:
7.png


8 - Press the '...' button (blue circle) and open up the 'banner.bin' file. Then press 'Extract'.
8.png


9 - Should get a message about a 'banner_bin_OUT' folder that has been created.
9.png


10 - The folder is created in the same place as the 'banner.bin file'. Modify the files inside as necessary.
10.png


11 - Going back to 'U8 Tool', untick the 'Use LZ77 Compression' and press 'Pack'.
11.png


12 - Should get a message saying file has been packed correctly.
12.png


13 - Press the '...' button (blue circle) and open up the 'icon.bin' file. Then press 'Extract'.
13.png


14 - Should get a message about a 'icon_bin_OUT' folder that has been created.
14.png


15 - The folder is created in the same place as the 'icon.bin file'. Modify the files inside as necessary.
15.png


16 - Going back to 'U8 Tool', untick the 'Use LZ77 Compression' and press 'Pack'.
16.png


17 - Should get a message saying file has been packed correctly.
17.png


18 - Delete the 'banner_bin_OUT' and 'icon_bin_OUT' folders. Replace the 'sound.bin' files with this one (otherwise the music won't play when the channel is selected).
18.png


19 - Going back to the 'U8 Tool', click on the second '...' button (see blue circle).
19.png


20 - Select the '00000000_app_OUT' file and press 'OK'.
20.png


21 - Press the 'IMET(Banner Info) option and enter the 'Titles' for the file. MAKE SURE THE 'USE LZ77 COMPRESSION' IS UNTICKED! OTHERWISE YOUR WII WILL BECOME BRICKED!
21.png


22 - Should get a happy message that it was packed correctly.
22.png


23 - Now repack the necessary files (don't repack the '00000000_app_OUT' folder).
23.png
 
Good tutorial!

I just wanted to give an update.

I've screwed up the u8 tool pretty badly at this point. I changed something to try to fix things, forgot what it was, and now the thing won't even pack as well as it did before! Atm my allergies are killing me and aside from that I'm in full-on halloween mode with the decorating, but I'll try to get it working in my spare time. There are bugs in the last version that need addressed even if I don't get the thing fully fixed I need to get it in the same working state is was before I started messing with it again.
 
FGOD said:
I'm getting confused guys... Gunfalf saying i should compress and you two saying i shouldn't.

While following the guide, you can compress the banner.bin file if you like (from the tests Ive done, the banner displays correctly).

Just compressing the icon.bin using HowardC's tool causes a palette issue (but won't cause a brick). So for now, don't compress the icon.bin file.


The main advantage of using LZ77 is to make the file smaller. The 00.app will still run correctly if the .bin files are uncompressed, providing you use the correct header. Just the size file will be bigger (only by 400KB which isn't that big of an increase).


HowardC, feel free to post the guide on the first page.
 
That is strange, now it worked. But icon.bin was still LZ77(i have unchecked it). Sorry but for me, this App is a little bit random :-/

However, i have done now an new 00.app template and it works fully with gally's tools.
 
gundalf said:
That is strange, now it worked. But icon.bin was still LZ77(i have unchecked it). Sorry but for me, this App is a little bit random :-/

Well you ether:
- Didn't click the 'Pack' button afterwards.
- Or you didn't untick the 'Use LZ77 Compression'.

If the icon.bin file is still compressed, just unpack it again and repack without the compression.

In fact, send me the 00.app you unpacked with U8 Tool and I can see what's going on.
 
Still cant figure out how to pack my sound.bin. Nobody says exactly how to do it!!!! Everytime i try to pack it, it gives me a error and closes U8tool down!

Edit: nevermind, i got it to work.
 
Ok, I have very mixed news to report.... some of it good, some of it bad.

After stugling with the u8tool, I have confirmed that the tool was indeed the cause of the distorted images (yes fgod, since the last version I released was in-flux, this might be your issue as well) and it appears I've fixed that much at least. I didn't try many different lengths, but I tried "Super Mario Bros.", "Super Mario Bros. 12345" and "Super Mario Bros. 123456" (one that didn't work before) and none of them corrupted. Also the stock sound.bin now plays just fine.

The catch? Well it seems to hae screwed up the icon.bin now. The icon.bin shows up undistorted, but the two icons that fade in and out don't appear on screen. It's as if the animation file that controls them is broken.

The good news is, I am 100% certain what the problem is AND it can be fixed, but I don't know how to do it (or at least do it properly.)

Let me explain:

You see, even from the first release of my u8tool I could never get the files my tool packed to properly match official files. The bulk of the file woudl be similar, but the official versions had single line (16 byte) buffers inserted between the individual file data seemingly at random. At the time I simply added a buffer between every file, just to be safe, and it did the trick. Apparently though, these buffers are quite important and they were what was causing the sound.bin not to play, on both my u8tool and gally's tools. It also caused some types of banners (neogeo, tg-16, ect) to corrupt when you re-packed them or changed some of the data inside. I manged to get the banner.bin to work properly, regardless of the circumstances by "fudging" these buffers into their proper places from examining an official banner.bin. I used the same technique on the icon.bin, but apparently it uses a different pattern from the one the banner.bin uses, so it screwed it up. Sound.bin we'll never have to worry about because it isn't a real archive. Now I can go ahead and hardcode the bufer values for icon.bin and banner.bin so that they always work, but that really only ignores the problem. While this would get our banners working, it might cause issues when we start packing up the manuals and more importantly, the 5.app. We need to figure out this pattern.

Here's what I know so far:

0.app doesn't have ANY buffer lines between the three files in the archive.

banner.bin has a buffer line before the first file and before banner.brlyt.
This lead me to believe that the pattern was that the folders themselves (excluding the root folder and last folder) were represented in the archive by a blank line. With the first file in the archive (I beleve it's banner_loop.brlan) being the first file in the "anim" folder, and banner.brlyt being the first file in the "brlyt" folder. This would also explain why 0.app itself doesn't have any buffer lines as there aren't any folders in the archive, aside from the root.

But icon.bin doesn't follow this pattern exactly.... There's one blank line at the beginning, just like banner.bin because they have the same folder structure but there isn't a line before the brlyt, which is the first file in the next folder. There's no blank line before the first file in the tpl folder either, but of course there wasn't a blank line there in the banner.bin.

I hope that is making sense to anyone who can help. We need to find a pattern here. I can tell you ahead of time that filesize has NOTHING to do with it. That I'm certain of. Now filetype and folder configuration, that might have something to do with it.

I will release a "private" beta of the u8 tool tomorrow night that has a special button that decompresses files but doesn't unpack them so you guys can help me look for a pattern. I would really apprecate any help anyone can give. As I said above, I can fudge in the appropriate spacing right now and get everything working, but that might ultimately lead to issues later on with archives that aren't banner related. I think it's a good idea for us to at least try to figure out why those blank lines are there.

Edit:

hmm, the plot thickens.....

It appears that the Sonic the hedgehog 2 wads 0.app (pal version) DOES have spaces between the files. Oddly not the first one though, just a space between banner.bin and icon.bin and one between icon.bin and sound.bin. I'm too tired to do anymore wad installs toinght, but I'll repack this one with my tool tomorrow and see what the results are.

Edit 2:

I was curious so I looked at the 0.apps we used for templates with the old tools. None of them have any blank lines. Makes me think sonic2 is just a fluke (maybe the end of the files actually contained a blank line or something. )
 

Site & Scene News

Popular threads in this forum