Hacking Wii backup Manager for Windows

  • Thread starter Thread starter fig2k4
  • Start date Start date
  • Views Views 4,934,467
  • Replies Replies 2,996
  • Likes Likes 20
QUOTE said:
Edit: If it can't read a CISO extracted with PrixM, then the header probably is corrupt. Try extracting to ISO with PrixM too, just in case, but CISO reading should work fine. I haven't changed that since I first implemented it.
Yes, I'll try.
Maybe it's really the game which has a problem.


Edit 2 :
Oh, maybe I found the problem.
Wiifit too has the same transfer problem, I added it to my wbfs from ripping original game on the Wii (with GX)
Could it be that GX didn't put the good header ?

But I'm sure I used that method for Wiisport too, and the header seems correct because I could transfer it to my brother's wbfs with backup manager.
Maybe older GX version had a ripping bug, and only few of my games were concern.


Edit again :
Results :
WingIsland ->PrixM to cISO -> backup manager can't read it
WingIsland ->PrixM to ISO -> backup manager can't read it
WingIsland -> Calimero's gui direct drive to drive successful -> listed on GX, but not working (black screen)
Wiifit ->PrixM to cISO -> backup manager can't read it
Wiifit -> PrixM to cISO -> PrixM Can't read the game ID and game name ..

Ok it seems my wbfs has bad data.

The games not working yesterday have good data and works great with 0.3.2
it was a 0.3.1 issue.

So your detection is good
smile.gif

I will have to re-rip some games.

Could you add a "verify games" function to read header from a wbfs drive ? so I can see which games are corrupted.
 
If the header really is corrupt, I could also try checking the header in the WBFS disc info block. This is a copy of the real Wii disc header. The info must still be OK there, otherwise it would show up as an invalid disc entry in the list.

Edit: Can Prixm or WBFS intelligent GUI read those extracted CISO/ISO?

Edit2: Give me a few minutes and I'll write some code that recovers the header from the disc info block, to see if that helps. There's a good chance that the actual data is corrupt too though, but it's worth a try.

When mounting the drive, the code just now checks the WBFS disc header, not the actual Wii disc header. I can add something to verify the actual Wii disc structure though..

Check your PMs for the test exe. Just extract it to the WBM folder and let me know if it makes any difference. If not, hopefully the re-rips work out.. It's hard to believe the other apps just copy the data without checking if the disc header is actually valid. Obviously Calimero's gui copies the raw WBFS sectors with drive to drive, like my old code, otherwise it would've shown an error too. From your tests, it looks that way anyway.
 
I tried the test version, I didn't see anything new.

I tried to transfer the problematic games (I identify 3 of them), it still doesn't work and I got the "not a wii disc". no 4MB either.
I tried extracting to cISO with PrixM and opening it with WBM and same as before, nothing shown on the file tab.

What should I expected ? games copied anyway with a fixed header ?

if you could add a new color when listing the files (like red) for corrupted games, it will be great, seeing other manager can copy corrupted games it will be helpful.
 
I made changes to Drive to Drive transfers that copies the WBFS disc header to the Wii disc header, if it's valid. The fact that you still get the invalid disc message means that the magic code in that header is invalid too. It's strange that the title and ID are OK in the header.

I'll need to add some more checks for this, so the games show as invalid in the list. It also would've been handy to have a hash function, so you could've verified the data using the hash calculated when you transferred the game originally.
smile.gif


BTW, the hashes calculated in 0.3.2 are finalised. They should now be valid in future versions. I'm coding all the various verification functions just now. You'll be able to recalculate hashes for existing games too.

Edit: Another new feature is optional full blown scrubbing. When enabled, only the used Wii sectors will be copied, the rest is filled with zeros. All the junk data usually still copied because of the WBFS block sizes will be scrubbed as well. It's especially useful for making sparse ISOs use even less space on the drive.
 
nice for the hash calculation.
as they appear only on the games transfered with 0.3.2, were are the hash results stored ? on the wbfs partition in an additional file ?
 
I just noticed on the logs :

QUOTE said:
(WiiDisc.Read) Error reading disc. 6 Descripteur non valide
(WBFSPartition.addDisc) Unused disc sector, error ignored
(in french yes)
I don't know what I did to get that logs.

was it trying to read the DVD drive ? there's no Wii disc in the drive (and I don't have a compatible reader).


edit :
Another question regarding wbfs format : could deleting/adding games corrupt another games already on the partition ? (especially if my disk is almost full)
I readed on another thread wbfs could corrupt titles, that's why fat and ntfs was better.

The wbfs fragments the games to fill into empty area, or does it look for enough consecutive space size to write the file in 1 block ?

because the corrupted games I found were working fine at my home.
I didn't try my usb disc on my brother's wii, I'll try that later (the TV is currently not available)
Could X-ray detector at Airport corrupt harddrives data ?
 
@fig2k4: Maybe it is better to add a number-of-partitions colum too, because games with or without an update partion or non scrubbed/scrubbed games will have different MD5 hashes. This way you can check the MD5 hash against WiiTDB MD5. This would mean WiiTDB should have different MD5 hashes as well. Scrubbed, non scrubbed. With/without update partions etc.
Also keep in mind that wii-scrubber also had the possibility to fill the empty data with 0x00 (Trucha) instead of 0xFF.

And maybe you could add right-click on a game to calculate/verify the MD5 hash by hand.

You are right with WBFS partitions not showing up because of the "Use mounted volumes only" option in the Settings.
(haven't seen any reply to that)

Keep up the great work!
 
@Cyan

That error is only in the new in the version I sent you. It's not really an error, it's part of the fix for the .wbfs to WBFS in 0.3.2. I should really suppress the error, but I'm still coding for the next release.
smile.gif


Edit: WBFS drives will get fragmented if you delete and add a lot of discs.

I just had a thought about your problem. Since you transferred these discs a while ago, maybe GX had the libWBFS deletion bug at the time? (Or whatever you used to delete them) AFAIK, when you deleted a disc, some of the wrong blocks were emptied which meant that the next disc copied to the drive would use these blocks that were already supposed to be allocated to some other disc. WBFS intelligent GUI has an integrity check for that. The bad news is that it might not be just those 3 discs that have the problem, they might've only flagged an error because the header was affected.

@digdug3
Yeah, there should be some kind of indication of what partitions the disc contains. I'll be adding a right click menu at some point to work with individual entries, rather than ticking the box. Ticking the boxes is the best way for multiple selections, but the right click menu would be better for individual entries.

QUOTE said:
Scrubbed, non scrubbed. With/without update partions etc.
Also keep in mind that wii-scrubber also had the possibility to fill the empty data with 0x00 (Trucha) instead of 0xFF.

It doesn't matter if the discs are scrubbed. I'm calculating the hash from used sectors only, which ignores anything else on the disc, scrubbed or not. Anyone with access to the libWBFS source (eg. wbs_file source) and some functions to calculate MD5 can write a something to calculate/verify this hash quite easily.
 
@fig2k4: Ok, I tought scrubbing (like Wiiscrubber did) used the Trunca bug to write the whole disc including the data part...
 
digdug3 said:
@fig2k4: Ok, I tought scrubbing (like Wiiscrubber did) used the Trunca bug to write the whole disc including the data part...
There are 2 mode in Wiiscruber :
- Scrubb (just replace unsued sector with 0x00) : This one doesn't need trucha, the resulted iso is still 4.7GB
- Compress : removed completly the empty sectors, and move the data, so it need trucha. It rewrites completely the data to make a new iso, sized after the game's data.
 
partitioned western digital 1tb into NTFS and FAT32 roughly 450gb each, went into Wiibackup Manager formated the NTFS to WBFS and as soon as i done that manager no longer recognizes the drive, WTF???
it formatted the drive and doesn't reconginezes it???
 
rafb said:
partitioned western digital 1tb into NTFS and FAT32 roughly 450gb each, went into Wiibackup Manager formated the NTFS to WBFS and as soon as i done that manager no longer recognizes the drive, WTF???
it formatted the drive and doesn't reconginezes it???
Go in to the device manager, and administrator tools, and select disc management. Assign a drive letter to the drive.
 
no, it's not a drive letter assignment problem (the letter is already assigned, else it couldn't select it to format).

Go to Wii Backup Manager / option / settings / Drives tab / uncheck the "show only mounted disk"

As windows can't mount a WBFS drive, it's not shown in WBM by default.
 
It depends what you mean by "doesn't recognise it".

One thing that comes to mind is that you're formatting from NTFS. I've only tested this as an administrator, so I'm not sure if it works as a normal user. Most managers etc. can't format directly from NTFS because of new security in Vista/Win7. If that's problem, then the partition will still show as NTFS in disk management, even after formatting to WBFS, and WBM will say it's an unknown filesystem. Because Windows won't let the app write to certain sectors of the drive without the correct privileges, it basically messes things up. Normally this is works OK though.

The solution in this case is to format to FAT32 in Windows first, then format to WBFS.
 
Sorry if this has been asked before but...

In the General tab - what is the difference between Keep Game Partition Only and Remove Update Partition? It sounds like the same net result...
 
Is it possible to transfor to WBFS fil an the name will be the game title or not the titleID??
 
QUOTE said:
In the General tab - what is the difference between Keep Game Partition Only and Remove Update Partition? It sounds like the same net result...
"Remove Update" removes only the update partition. "Game only" keeps only the game partition. A disc can contain multiple partition types like game, update, channel installer. Those options were defined in libWBFS. I might change it sometime so the actual partition types to keep are selectable.

QUOTEIs it possible to transfor to WBFS fil an the name will be the game title or not the titleID??
No. You can easily rename/delete files after the transfer though. I've kept to that standard so it's easy to just use explorer etc. to move the files around, without renaming before it's usable on the Wii.
 
fig2k4 said:
QUOTE said:
Is it possible to transfor to WBFS fil an the name will be the game title or not the titleID??
No. You can easily rename/delete files after the transfer though. I've kept to that standard so it's easy to just use explorer etc. to move the files around, without renaming before it's usable on the Wii.

Could you make it as an options. because i really want it. and i think many others will love to get that feature.
 

Site & Scene News

Popular threads in this forum