Hacking Wii NAND Ghost Pack (RealWnP) ask for beta tester

[pcfree]

Email me [email protected] if you want to beta-test it.

RealWnP 0.5 private beta – A Wii NAND Ghost Pack, provides fast Wii NAND on concole backup/restore. The functionality to Wii NAND is similar with PC Ghost utility to hard drive. With smaller packed image file, you can manage more NAND images of different region setting, firmware version or others in a single SD/SDHC card. Even a 512MB SD card may be able to store 1 to 2 sets of packed NAND image. And with 160 seconds backup/verification time and 100 seconds analysis/restore/verification time, you can quickly switch between the above different configurations.

RealWnP Introduction in wiibrew

== WARNING ==
THIS PROGRAM IS FOR BETA TESTERS ONLY. THE BETA TESTERS SHOULD HAVE BOOTMII INSTALLED AS BOOT2 AND ALREADY BACKUP THEIR NAND BY BOOTMII.

This program pack comes with ABSOLUTELY NO WARRANTY. It is a HIGHLY DANGEROUS program that may brick your Wii. USE AT YOUR OWN RISK. However, if you have BootMii/boot2 installed and NAND.BIN backup by BootMii, you are safe to try this program.

== Introduction ==
RealWnP is a Wii NAND backup/restore utilities pack including RealWnR, RealWnW and other Win32 command line supplementary tools. The functionality to Wii NAND is something similar with Ghost (a hard drive backup/restore utility) in PC.

These tools use a new packed image format to save SD card space. Therefore you can easily manage several NAND packed image sets and restore a selected past state to your Wii console.

== Utilities ==

• RealWnR backups your Wii NAND to a packed image set with date/time as Pack Name. This is a brick free process.
• RealWnW selects a packed image set from SD and restore it to your Wii NAND console. Please note that direct NAND writing/programming is a TOP ONE HIGH RISK operation to your Wii. In the beta stage, it is strongly recommended you have BootMii/boot2 installed with NAND.BIN backup.
• NI2NP.exe is a Win32 command line tool to convert your old NAND Image to NAND packed image set with date/time as Pack Name or user-defined Pack Name. The pack image set should be manually copied to RealWnS directory in SD card for using by RealWnW. The old NAND image may come from +ECC dump of RealWnD, YaWnD, WiiND or even NAND.BIN from BootMii.
• LoadIOS.exe is a Win32 command line tool to patch boot.dol of RealWnR/RealWnW with specific IOS to reload. Patch dol with IOS 0 means using default IOS assigned by loader.

== LU64+ (3.4v2) and IOS ==
These tools rely on IOS to directly access Wii NAND. New IOSes that comes with System Menu 3.4 and later block IOS_Open for /dev/flash to block direct NAND access. I cannot provide direct hack information on how to patch these new IOSes. But you may enquire other IOS hacker about it. It would be a simple work for those who are familiar with ARM code disassemble and IOS patching.

== Performance ==
On my own test, RealWnR took 90 seconds to dump image and 75 seconds to verify it. And RealWnW tooks 48 seconds for analysis, 31 seconds to restore NAND and 22 seconds to verify it. Totally about 100 seconds for RealWnW to restore a image. The packed image set occupies about half size of normal NAND dump. So you may benefit from this pack by faster backup/restore and saving more image sets in one SD card.

== Format of Packed Image Set ==
All of the packed image sets are stored in RealWnS directory of SD card. The image sets are distinguished by filename as PackName prefixed with NP. That is, if a packed image header file are named as “NP3.2U_Backup.bin”, then “3.2U_Backup” is the PackName. The RealWnR always generates date/time code as PackName. The Win32 NI2NP.exe may generate date/time or user-defined PackName.

For each packed image set, you will have one header file with “.bin” extension and several data content files with “.00”, “.01” … extension. The header file consists of 512 bytes header and 8 boot blocks + 32 SFFS meta blocks. All other file data are packed in data content files.

 

[jwcgator]

I'll try this here in a second (once you hit me back up with an email >=3), I won't be able to give quantitative time results, but I will give a general faster than bootmii/slower than bootmii result

 

[ds22]

I send you a E-mail.
I have Bootmii installed as BOOT2 and have a NAND.bin of my wii.
So i can give you the results you want

 

[sirakain]

Sounds cool.
But my SD Card is not working with BootMii so I'll wait.

 

[jwcgator]

It took 109+88 seconds to backup my nand. It felt much faster than bootmii. I haven't timed bootmii so IDK if it actually is.

 

[pcfree]

If you got "Cannot open NAND" message, it means your are using a new IOS. Please note that the System menu verion is not important but IOS is. If you are not LU64+ user (of course not if you can install bootmii/boot2), you can simply downgrade any IOS to old version or use cIOS 249 rev10 or piror. Then patch the boot.dol of RealWnR/RealWnW to using the specified IOS by LoadIOS.exe. LoadIOS.exe is a Win32 command tool that will try to find boot.dol in current directory and patch it with the specified IOS. For example, if you want to use cIOS 249, type "LoadIOS 249" in both RealWnR and RealWnW's directory.

 

[ether2802]

great work fella', hope to see your work released for the masses..!!

 

[pcfree]

It took 109+88 seconds to backup my nand. It felt much faster than bootmii. I haven't timed bootmii so IDK if it actually is.

The backup time might depend on SD card speed and Wii NAND data contents. According to my test, I have 1304 free blocks displayed in Wii data management menu and it took 90+75 secs to backup by RealWnR. For RealWnW to restore, I have 48+31+22 (analysis/programming/verification) secs from 4.0 to 3.2, and 68+20+15 secs from 3.2 to 4.0. The analysis vs programming+verification would be complementary. More analysis time means more same blocks and implies less programming+verification time.

 

[pcfree]

great work fella', hope to see your work released for the masses..!!

Thanks! Hope more results to prove the RealWnW restoring process to be bug free. Then I can release publuc beta.

 

[drmr]

I feel like I should say something here. Or rather have a TT collegue quoted: "It's a really bad idea™ to write to the nand while one of Nintendo's IOSes is running." BootMii overcomes this obstacle by using its own completely controllable "IOS", MINI.

I am not trying to put down any competition. But given that (just like BootMii installed as IOS only) this no way allows you to recover from a brick, my feeling is that your tool's only selling point "it is quicker than BootMii" comes at a steep price.

 

[ether2802]

the great thing about this, is to do a dump of your Wii at 4.0 and one at 3.2, and whenever you want to go from 3.2 to 4.0 it will only take 100 secs. of your time, instead of having to use the updater and then install preloader, hacks, etc etc.....

and with bootmii you still need to change the nand.bin file in your SD and you wouldn't know wich is one in case you have them both without tags, of course it is not mented to be used as a NAND restorer from a brick, but still bootmii is not really going to be used except for the beta-testers fo dangerous apps, the n00bs don't have it installed and they are the ones deleting the IOSes massively, and the ones who have it installed know that you don't have to do stupid thing to your Wii, so really.........to create this type of app is just merely to learn how to do the things, what benefit gives you to create the first back door of a new console..??

 

[pcfree]

I feel like I should say something here. Or rather have a TT collegue quoted: "It's a really bad idea? to write to the nand while one of Nintendo's IOSes is running." BootMii overcomes this obstacle by using its own completely controllable "IOS", MINI.

I am not trying to put down any competition. But given that (just like BootMii installed as IOS only) this no way allows you to recover from a brick, my feeling is that your tool's only selling point "it is quicker than BootMii" comes at a steep price.

Don't be so serious. I think there are no competition or selling point issues. I respect Team Twizzers' efforts on providing a brick free and N free operation environment. I personally also use BootMii/boot2 as my backend safety guard. The RealWnP project was initially developed for fun and hope others might benefit from it.

BTW, I have done some coding efforts on reducing analysis and programming time. But the quicker operation is mainly accomplished by new libogc/libfat svn.

I also want to contribute the BootMii project if I have enough time & knowledge. I have two SDHCs which is incompatible with BootMii. And I know armboot source has been released for a while. If I collect enough information, I might debug it by myself.

 

[drmr]

Don't be so serious.
I prefer being serious to being sarcastic or condescending. Also I believe this is not a point of respect or competition, but rather about pointing out a serious issue. That is, writing to NAND while Nintendo's IOS may be simultaneously accessing it can become a problem. Just consider the possibility that Nintendo's IOS is modifying the NAND while you are reading it into a backup, or even worse, while you are writing an image back to it. I am sure you see the inherent danger.

I personally also use BootMii/boot2 as my backend safety guard.
You are certainly aware of the fact that a considerable amount of users doesn't have this safety net.

QUOTE

I also want to contribute the BootMii project if I have enough time & knowledge.

By all means, you are absolutely welcome to do so and join us on the official channels (i.e., #bootmii on EFNet, and the forums).

 

[carbonyle]

Ok I've just test both hombrews successfully, the project seems great and can be benefic for everyone.
Of course the risk are high but I think pcfree is clear on this
It will not replace bootmii, sure, but I find it very usefull and easy to use.
If I can suggest 2 or 3 things:
- Text is hard to read on my 4/3 crappy cathodic TV, sure a beta doesnt need a great gui but ...
- For the last part (confirmation of the write operation) I couldn't read the text. since I'm not stupid I was aware that operation was THE operation (with the subsequent risk)
- Certainly not but: we can choose IOS ok? could we one day choose MINI from bootmii as firmware for this?

Cheers

 

[pcfree]

I prefer being serious to being sarcastic or condescending.
I didn't have intention to be sarcastic or condescending. I apologize if it make you feel something like that. Please note that English is not my native language. I have to use on-line dictionary to read forum and express in my very plain English. Some wrong wording/phrase may cause wrong intention.

QUOTEThat is, writing to NAND while Nintendo's IOS may be simultaneously accessing it can become a problem. Just consider the possibility that Nintendo's IOS is modifying the NAND while you are reading it into a backup, or even worse, while you are writing an image back to it. I am sure you see the inherent danger.

I haven't yet experienced something IOS interferes with direct NAND access in my test. I don't know details about IOS operations. I guess it should have background routines to access NAND at least for cache management. However, there are still 3 possibilities that it is safe to raw access NAND if cache is the only problem:[*]Dirty cache should always be flushed for such a long time.[*]It's reasonable that ReloadIOS() should also flush cache.[*]Assume N's IOS provides enough integrity to prevent wrong operation. If /dev/flash is opened for writing, it should flush and stop other NAND related background operations. If not, for integrity consideration, N's IOS should have provided some LOCK mechanism that we can use. It is welcomed if anyone can provide such LOCK information.RealWnR should not have problem due to verification stage. Users will know the dump is useless if interfered. But RealWnW may have problem if interfered. Do you have proofs that IOS actually interferes NAND access in other way? IOS version specific? If yes, I may add more checks or exclude some bad IOSes, or even limit the usage only to BootMii/boot2 users by checking the BootMii/boot2 existance. And might not release source code for final version to prevent improper use.

Any suggestions or information are welcomed to be discussed in the forum or email to me.

 

[svpe]

That is, writing to NAND while Nintendo's IOS may be simultaneously accessing it can become a problem. Just consider the possibility that Nintendo's IOS is modifying the NAND while you are reading it into a backup, or even worse, while you are writing an image back to it. I am sure you see the inherent danger.
I haven't yet experienced something IOS interferes with direct NAND access in my test. I don't know details about IOS operations. I guess it should have background routines to access NAND at least for cache management. However, there are still 3 possibilities that it is safe to raw access NAND if cache is the only problem:
Never assume that Nintendo/BroadON wrote failsafe code because they usually don't.
/dev/flash was never intended to be used by programs running on the powerpc. IOS assumes that the only thing writing to the NAND is its nandfs driver. And every single IOS module it allowed to write to the nandfs whenever it wants. If you have e.g. wiiconnect24 turned on and you receive an email while you restore the nand something bad may happen:
1) you restore parts of the filesystem and have not reached the SFFS section yet.
2) wc24 receive an email and adds and modifies files on the nand. it uses the old SFFS section to determine free blocks and overwrites some of the data you just restored
3) you restore the SFFS section and overwrite the changes done by the wc24 module
Some data is now corrupted. You may be lucky to just corrupt some unused IOS or you may be unlucky and corrupt vital parts like the system menu.
And this is just one example of things that can go wrong. You have no way of telling IOS to stop its nandfs driver.
The probability that such things may happen may be small but you have to take the number of possible users into account who are going to use your software. Some bad thing like this is bound to happen once there are enough users using your software often enough.
If you have bootmii/boot2 or a hardware programmer installed you can just restore an old backup now. You're screwed otherwise.

QUOTE

[*]Assume N's IOS provides enough integrity to prevent wrong operation. If /dev/flash is opened for writing, it should flush and stop other NAND related background operations. If not, for integrity consideration, N's IOS should have provided some LOCK mechanism that we can use. It is welcomed if anyone can provide such LOCK information.

Again, don't assume Nintendo or BroadOn writes failsafe code. Even their ES_ImportBoot2 function is horribly broken and sometimes forgets to write ECC data. Whoops.

 

[pcfree]

@svpe
Thanks for your excellent explanations. However, many coding works have been done so I still want to improve my project, for at least my personal use or maybe some limited number of power users if there are really no ways to find perfect solutions to using N’s IOS for restoring. Hope you have patience to answer my questions or kindly help find solutions.

Already known that there are no ways to stop nandfs driver. So even I do a complete verification instead of my current verification with only written blocks, there is still a short period, from verify OK to reboot, exposing to danger. It seems only if IOS provide function to re-initialize itself or at least re-initialize nandfs driver then I can solve the problem. Is there any such command that I can use before verification?

Back to old question, after drmr’s post, I had tried to test if a long wait between dump and verification will cause inconsistence. I modified RealWnR to wait button confirmation before verification, and I waited about 20mins to get OK result. After reading your post, I modified to use wait button and time() to read RTC to extend period to exact 1 hour (of course I have no WC24 enabled) and the result was still OK. It seems IOS does not do periodical maintenance jobs to record something in nandfs and no other non-networking events trigger IOS nandfs access in this 1 hour period. Then is it safe if WC24 is disabled? Or I am still missing some important consideration? For example, some kind of clock triggered events or alarm that IOS handles w/o SysMenu.