Hacking Yet Another BlueDump MOD (YABDM).

[DarkMatterCore]

This is a modification of BlueDump I made in August during my vacation, which fixes a lot of problems present in the original application. This is not the first mod I have done to BlueDump; there was a little one I did back in 2011 here, but I lost its source, so I had to do everything again from scratch (plus some other things that actually help in the WAD dumping process).

It is able to dump any title to a WAD file and saves in their unencrypted form, just like the original BlueDump. The main features that differentiate it from its predecessor are a lower memory usage, ability to dump titles bigger than 47MB (even the "Wii + Internet" Channel!), compatibility with USB storage devices, GCN controllers and Classic Controllers, full hardware access with vWii support (using libruntimeiospatch, so big thanks to both damysteryman and Excelsiior) and the ability to convert content.bin files saved in sd:/private/wii/title to WADs.

I personally want to thank JoostinOnline, because he really did help me out in the latest revisions. Most code optimizations, the new controller input code, the new icon.png and even support for meta.xml arguments were entirely done by him.

Here's the full changelog since BlueDump Alpha 3:

Spoiler

YABDM v1.8 (December 9th, 2014 - DarkMatterCore):

* Fixed a bug where garbled text was being displayed for titles that use 0xFF instead of 0x00 as the preceding byte for each character in their name field (fixes MEGA MAN 9 DLC, possibly others).
* If a given title only has whitespaces on its description field, the application will no longer display them (fixes Dead Space Extraction, possibly others).
* Added compatibility with custom USB 2.0 modules from various cIOS, using a modified version of the usb2storage.c driver from WiiXplorer.
* The USB mounting process now has a 10 seconds timeout, instead of using a retry system.
* The ehcmodule will be loaded into Starlet using mload if the loaded IOS is an Hermes cIOS.
* IOS reload option added to the Settings Menu.
* If the hardware protection is disabled, the current IOS is patched before an IOS reload is performed to keep the access rights.
* Changed the default IOS selection menu value to IOS249.
* License upgraded to GNU-GPL v3.

YABDM v1.7 (November 28th, 2014 - DarkMatterCore):

* The application's code flow was modified to remove the overuse of the exit function and to deal with unhandled memory exceptions. Thanks to this, the goodbye() function has now been removed, and only a single call to Reboot() is performed.
* An additional settings menu has been implemented. It can be entered by pressing button -/L. There, you can either choose to switch storage devices through the Device Menu, or to update the application.
* It is now verified if the console keys collected from the BootMii data are null (zero-filled) or belong to the console the application is being run on before using them.
* Added compatibility with Priiloader. Thanks to this, the application can now generate valid System Menu WADs even if Priiloader has been installed.
* LoadTikFromDevice() is now merged with GetTicket() (it should have been like this from the beginning).
* The IOS selection menu now also skips BootMii IOS and stub IOSes.

YABDM v1.6 (November 16th, 2014 - DarkMatterCore):

* Added support for vWii System Menu versions 608, 609 and 610.
* Added support for mauifrog's System Menu 4.1 modified versions.
* Updated the internal name list to add support for vWii hidden channels.
* The update procedure now checks if you already have the latest YABDM version.
* The logfile now shows if the application is running under vWii.
* The reset_log() function was removed. Now, a line formed by dashes is used to divide each subsequent logging session from another.
* The application is now able to use the BootMii dump data from another Wii in the content.bin conversion process. It'll only look for the files if the content.bin's Console ID doesn't match the one from the console the application is being run on. Please keep in mind that you'll also need to have a copy of the Ticket file on your NAND, or either manually place it under /YABDM/Tickets/ in the selected output device, using the following naming scheme: TITLE_HIGH-TITLE_LOW.tik (e.g. sd:/YABDM/Tickets/00010001-57475345.tik). If you choose not to fakesign the output WAD, it'll retain the signature from its original console.
* Some other minor fixes and corrections.

YABDM v1.5 (October 13th, 2014 - DarkMatterCore):

* Fixed the region change procedure for DLC titles. Their Title IDs will now reflect the selected new region (in order to make them detectable by their corresponding game/channel).
* The region change prompt will now always be displayed. Keep in mind that if you enable this option, the Ticket and/or TMD will be fakesigned automatically, depending on the category of the selected title (even if you choose not to).
* If the application detects that the Common Key Index is different than 0, it will automatically fakesign the Ticket (even if you choose not to), instead of only changing its value.
* Reimplemented the Wii disc light feature as an optional read/write indicator. You can enable it through the use of the "wiilight" argument in the meta.xml file.
* Reimplemented the ability to update the application straight from the Google Code SVN repository, by pressing buttons A and B at the same time. The meta.xml file will also get updated.


YABDM v1.41 (September 21st, 2014 - DarkMatterCore):

* Quick fix for the SHA-1 calculation during the content.bin conversion process.

YABDM v1.4 (September 21st, 2014 - DarkMatterCore):

* Removed the use of strcpy/strncpy to avoid possible buffer overflows.
* Now, argv[0] is also checked when looking for the "debug" argument, since it appears it gets passed here if Wiiload is launched from a batch script.
* Added BC-NAND (1-200) and BC-WFS (1-201) vWii titles to the internal name list, previously listed as IOS 512 and 513, respectively. Thanks to larsenv for noticing this.
* SHA-1 hash verification is now performed during the dumping process for every regular content file.
* Improved the logfile code. Now, the debug file is only opened/closed when absolutely necessary; each consequent debug string is flushed to the file while it is kept open, which greatly reduces the time needed to write info to the output device. Strings longer than 256 characters are now also allowed. Thanks again to JoostinOnline!
* Added compatibility with Wii U Pro Controllers. Thanks to FIX94 for his libwupc library! Also thanks to my good friend Dimitry Valencia for testing.

YABDM v1.3 (June 25th, 2014 - DarkMatterCore):

* Fixed the directory sorting function by doing a string comparison without case sensivity, using stricmp(). I don't know how didn't I notice that before.
* Fixed a bug where the content.bin conversion mode would not be entered, with no error message displayed.
* Directory entries without a content.bin file won't be shown anymore.

YABDM v1.2 (May 16th, 2014 - DarkMatterCore):

* Updated all the debug code to use the Carriage Return + Line Feed combo, in order to make the logfile readable under Windows.
* Unpadded Ticket size is now always set to 0x2A4 bytes. Some PC applications aren't even compatible with bigger Ticket sizes.
* If a DLC content (type 0x4001) for the selected title is not present, it is now skipped and its info struct is removed from the TMD (which is also fakesigned in the process). The output file is also rearranged when all the available contents have been dumped. Thanks to szczuru from GBAtemp for doing **a lot** of testing.

YABDM v1.1 (May 5th, 2014 - DarkMatterCore):

* Fixed the left/right buttons behaviour in the content.bin conversion menu (oops).
* An output device selection menu will now be displayed after pressing -/L, instead of just remounting the storage devices. Device swapping is also allowed, but only in the main menu.
* Compiled with the latest devkitPPC, libOGC (with custom font) and libFAT.

YABDM v1.0 (March 25th, 2014 - DarkMatterCore):

* Eliminated the need for realloc() in pad_data(), since allocate_memory() generates buffers with sizes rounded to a 64-bite boundary; this is most likely safer. The function is now used only to write zeros.
* The IOS buffered list is now freed before reloading to a new IOS.
* Fixed a bug in the directory navigation code where garbled text would be printed if there were no items in the selected directory (after pressing A).
* Fixed left/right buttons functionality for lists with equal to or less than 4 elements.
* The region change prompt now won't be displayed if a system title was selected.
* Button -/L can now be used to remount the storage devices.
* Some minor changes to the AES code.

YABDM v0.93 (March 1st, 2014 - DarkMatterCore) (I already know I'm getting annoying, you don't have to tell me twice):

* The RemoveIllegalCharacters() function now also replaces non-ASCII characters with an underscore (_), since libFAT apparently has problems opening/writing files with names that include them. Thanks to erickmaniche from Emudesc for letting me know.
* The getdir_info() and getdir_device() functions will now end early if no files are detected when reading the directory the first time. This fixes some small problems related to save dumping/restoring.
* Logfile output cleanup (mostly, missing newlines).
* General code cleanup. Fixed some small things I previously overlooked.
* Exit sequence cleanup: instead of calling Unmount_Devices() and Reboot() all over again, now just goodbye() is used.

YABDM v0.92 (February 27th, 2014 - DarkMatterCore):

* Reimplemented the DetectInput() function, now fixed by JoostinOnline.
* Rewrote the GetASCII() function to discard non-valid ASCII characters.
* Button A can no longer be used in the content.bin conversion mode if the selected directory doesn't have a content.bin file inside.

YABDM v0.91 (February 26th, 2014 - DarkMatterCore):

* Fixed a very silly regression bug in the name reading code.
* Fixed GCN Controller compatibility. For some odd reason, the controller input acts erratically using the DetectInput() function, so for now I'm just reverting back to the old waitforbuttonpress(). I swear I received my controller just a moment ago; otherwise, I wouldn't have noticed that.

YABDM v0.9 (February 26th, 2014 - DarkMatterCore):

* Rewrote the title name reading functions from scratch. The application can now read multilingual names and descriptions from contents stored on the NAND filesystem and content.bin files using the IMET and WIBN structs from Wiibrew, and the __convertWiiString() function from AnyTitle Deleter by bushing.
* Improvements to the save dumping/flashing code.
* Minor cleanup to the WAD dumping code. The application will now also check if the Ticket and/or TMD data is already fakesigned before trying to wipe the signature.
* If you choose to fakesign the TMD, the application will now display a prompt asking if you want to change the WAD region. This is done by modifying the value @ 0x19D in the TMD, just like FreeTheWads on PC.
* A "(vWii)" suffix will be displayed along with the System Menu version if the application is running under vWii (thanks to JoostinOnline and crediar for their IsWiiU() check).
* Updated libruntimeiospatch to v1.5.1.
* Updated application headline and meta.xml credits to reference HacksDen.com.

YABDM v0.8 (September 24th, 2013 - DarkMatterCore):

* Added support for title 00010000-HAZA. It is the responsible for controlling the Photo Channel "swap" between versions 1.0 and 1.1. When it is present, v1.1 is displayed in the System Menu; otherwise, v1.0 is used. Since it gets installed to the savedata directory, it was not being treated as a title, thus its dumping was not allowed; now this behaviour is fixed. Thanks to Iwatasan for noticing this!
* Compiled with the latest libogc git revision from 09/04/2013.
* Now using the latest libruntimeiospatch revision. The previous version was not properly patching the hash_old[] pattern because it had the same value as new_hash_old[]. I informed Excelsiior about this and the change has now been made to the GitHub repository.

YABDM v0.7 (September 15th, 2013 - DarkMatterCore):

* Changed application name to YABDM (Yet Another BlueDump MOD).
* Added a proper fix for DetectInput(): now calling VIDEO_WaitVSync() instead of using a while loop (thanks to JoostinOnline!).
* Changed the AES / Rijndael implementation from Mike Scott in favor of a faster one by Vincent Rijmen, Antoon Bosselaers and Paulo Barreto (slightly modified by Jouni Malinen), known as "rijndael-alg-fst". This one uses previously created AES tables instead of generating them everytime an encryption / decryption operation is done, and it also allows the use of a single memory block to be modified 'in-place'. Thus, the dumping process is now faster.
* The OTP memory is now mounted once instead of accessing its data everytime Content_bin_Dump() is called in the application.
* The application now generates a name list for all the entries in a directory everytime the current path is changed. This is mainly done to reduce loading times, and to avoid reading ALL the names again when a D-Pad button is pressed. Because of this, the names for the content.bin files saved in the SD card are now properly displayed on screen; you'll only have to wait a bit after pressing +/R.
* Thanks to the previous point, I noticed a memory leak in getdir_info(), because the *ent pointer was used to allocate memory with malloc() regardless if it already pointed to a memory address. It is now freed before reusing it.
* Some other optimizations.

MOD v0.6 (September 7th, 2013 - DarkMatterCore and JoostinOnline):

* Added compatibility with content.bin files stored in SD:/private/wii/title. You can switch between normal WAD dumping and content.bin conversion modes with +/R.
* Added code to read the OTP contents and copy them to a previously aligned memory block. This is needed to access both the PRNG Key and the Console ID, which are used in the content.bin conversion process.
* Added compatibility with Classic Controllers (thanks to JoostinOnline!).
* Optimized name reading functions. Instead of allocating a memory block and then returning it (which is unsafe), now a single global character string is used, with its current value being updated by using snprintf() (thanks to JoostinOnline!).
* Added meta.xml argument support to enable or disable the logfile creation without having to recompile the entire application (thanks to JoostinOnline!).
* New sexy, smexy icon (thanks to JoostinOnline!).
* Some other changes and simplifications that reduce the overall CPU use (thanks to JoostinOnline!).

MOD v0.5 (August 27th, 2013 - DarkMatterCore):

* read_name_from_banner_app() and read_dlc_name() functions are now merged.
* Fixed a bug in the read_name() function which would return wrong text if the title has contents smaller than the size of the chunk read into memory (e.g. YouTube Channel, it has two 'dummy' contents of 0x40 bytes each).
* Fixed a *possible* buffer overflow in the read_name*() functions, since they were allocating 'length+10' bytes for the name buffer and then the description string was concatenated to it (which is usually longer than 10 bytes). Now, they're just allocating enough space for what they need.
* Fixed left button behaviour.
* More code changes.

MOD v0.4 (August 26th, 2013 - DarkMatterCore):

* Ability to read the internal channel descriptions. Not all channels have this, though, but it still is a nice feature.
* Button 2 / X is now used to change the view mode between hexadecimal IDs and ASCII IDs.
* Added padding to 64-byte boundary for the footer data (I noticed that the official WADs from game discs have this, so why not?).
* Mostly, code optimizations.

MOD v0.3 (August 24th, 2013 - DarkMatterCore):

* Fixed a very silly bug in the GetContent() function that would improperly dump content files smaller than 16KB using a null IV in the encryption process (I used the Mario Kart Channel to test this behaviour, since it has two contents that match this case).
* The WAD backup section of the dump_menu() function was completely revamped to avoid redundancy (it seriously had a lot of unnecessary code). Plus, the name scheme of the dumped WADs was changed to be the same from CustomizeMii and similar applications.
* Now using conditional operators for most checks on the 'isSD' value.
* Some other little corrections.

MOD v0.2 (August 15th, 2013 - DarkMatterCore):

* Now using libruntimeiospatch by Excelsior to apply patches to the current IOS.
* Fixed illegal FAT characters on dumped savegames. They are now replaced with an underscore (_).
* Added full support for contents bigger than 45MB. The GetContent() function was completely rewritten to dump each regular content file in chunks of 16KB, which are read, encrypted and saved to the output WAD. Because of this, the encrypt_buffer() function is not used anymore in GetContent(), since we need to change the Initialization Vector (IV) for each chunk.
* Other minor fixes and corrections.

MOD v0.1 (August 1st, 2013 - DarkMatterCore):

* Full hardware access through the HW_AHBPROT flag (must use HBC v1.1.0 or later!). The IOS patches applied include the "KillAntiSysTitleInstall" set from damysteryman, so the application is also fully compatible with the vWii mode available in Wii U.
* Added an IOS selection screen at startup (you can select whether you want to use the full hardware access, or a patched IOS).
* Full compatibility with USB storage devices and GCN controllers.
* Ability to choose if you want to fakesign the WAD ticket and/or TMD before starting the dumping process (no secondary version needed anymore).
* If you select to fakesign the WAD ticket, the application now wipes the console ID and the ECDH data from it; both of those can prevent a successful WAD installation on another Wii. It is also verified if the Common Key Index value (0x1F1) is set to 0x01 or 0x02; if so, it is changed to 0x00.
* The certificate chain (cert.sys) is now embedded on the code, to avoid reading it every time from the NAND.
* Complete overhaul in the name reading functions for channel banners and banner.bin file from savegames. Plus, the application now can also read names from installed DLCs.
* The WAD footer is now added to every title dumped from the application. Its size is added to the WAD header @ 0x1C, too.
* The content.map file is now read into memory once for every dumping process, instead of accessing it every time the application dumps a shared content.
* Compatibility with content type 0x4001 (which is only present in DLCs, AFAIK).
* Fixed a bug in GetContent() where the application would allocate memory for two different buffers with the same size, which could exceed the console memory limit if the content size was greater than ~22.5 MB. Now, a single memory buffer is used for all the dumping, padding and encrypting operations.
* The pad_data_32() function is now called pad_data(). It uses a bool value to determine if the input buffer will be padded to a 16-byte (0x10) boundary, or a 64-byte boundary (0x40). To avoid memory problems, it now uses realloc() to change the size of the already-allocated input buffer, instead of allocating memory for a new buffer.
* The decrypted memory buffer is now padded to a 16-byte boundary before encrypting. Then, the encrypted memory buffer is padded to a 64-byte boundary. That way, the WAD structure used by NUS Downloader can be easily recreated, with amazing results (just see it by yourself).
* Before reading the internal name of a given title, it is now verified which type of title is it to use the appropiate function for its case. That way, the logfile won't be full of ISFS_Open() -106 errors when trying to read the banner.bin file for everything. lol
* Added a switch case function to properly output the System Menu version in the browser screen (e.g. "v513" is now displayed as "v4.3U").
* Ability to use the LEFT/RIGHT buttons in the browser screen (why didn't nicksasa add that...?).
* Output font replaced with another that has full Unicode support. That way, the title names can be displayed properly if you have set your console in Spanish or a different language.
* Compiled with the latest libogc, devkitPPC and libfat versions (as of August 1st, 2013: v1.8.12, r26 and v1.0.12, respectively).
* Compatibility with the new WiiMote Plus (RVL-CNT-01-TR).

Subversion repository at Google Code: http://code.google.com/p/bluedump-mod/source/list.

You can always get the latest version here (with icon.png and meta.xml). Currently on v1.8.

 

[flamepanther]

I think this is much needed. I could have used this months ago when the unmodified version kept crashing when dumping certain games I bought from the shop. I ended up having to dump my entire NAND and use ShowMiiWads to extract the games from it. Now maybe a few others can avoid the same chore.

 

[DarkMatterCore]

Well, not saying that you should, but you would do me a great favor if you actually tried to dump the titles that made the original BlueDump crash in your Wii, using YABDM of course. Literally, the only people besides me that have tested the application are JoostinOnline and stomp_442; most of the bugs I found were fixed because I actually reproduced them in my countless tests.

There are a few things I'm interested to test in other consoles:

* General application performance VS original BlueDump performance.
* DLC name reading AND dumping.
* Content.bin conversion process to WAD files. In all my tests, the hashes from the converted files matched those from the WADs created through the main title browser, but I haven't had the opportunity to test this in a different Wii.
* Most importantly, actual vWii compatibility! (includes everything mentioned above)

I also want to improve the USB compatibility, though I don't really know where to start. It shouldn't be necessary to try out 45MB+ channel dumping; the mere fact that I was able to dump the "Wii + Internet" channel proves that it works OK.

 

[Maxternal]

Nice work again on this. I'll have to finally test it sometime.

 

[flamepanther]

Well, not saying that you should, but you would do me a great favor if you actually tried to dump the titles that made the original BlueDump crash in your Wii, using YABDM of course. Literally, the only people besides me that have tested the application are JoostinOnline and stomp_442; most of the bugs I found were fixed because I actually reproduced them in my countless tests.

There are a few things I'm interested to test in other consoles:

* General application performance VS original BlueDump performance.
* DLC name reading AND dumping.
* Content.bin conversion process to WAD files. In all my tests, the hashes from the converted files matched those from the WADs created through the main title browser, but I haven't had the opportunity to test this in a different Wii.
* Most importantly, actual vWii compatibility! (includes everything mentioned above)

I also want to improve the USB compatibility, though I don't really know where to start. It shouldn't be necessary to try out 45MB+ channel dumping; the mere fact that I was able to dump the "Wii + Internet" channel proves that it works OK.

I wouldn't object to doing this, in theory. In reality there are three problems:
-I don't remember which they were.
-It wasn't consistent. A title would crash it on one try, but work on the next try. I was dumping a lot of games, so I got tired of it.
-I don't have any games on my real NAND anymore.

Maybe this weekend I can make time to grab some old purchases from the shop channel and just sort of see if it's more reliable in general, and try out the USB support though.

 

[DarkMatterCore]

Yeah, that was probably because the original BlueDump allocated a memory block to copy the whole content file to MEM2. Doing that isn't very safe, considering the small amount of memory the Wii has. If you do test it, please, let me know.

BTW, seeing that a lot people is now using emulated NAND filesystems, I might consider adding support for them; after all, the whole content.bin compatibility was a suggestion, not something I really planned to do from the beginning.

The only question I have is, what do you use nowadays to do NAND emulation? I'm not very familiar with it. If they are *NEEK based modules, do they now allow the use of ISFS commands? If I recall correctly, they were broken under *NEEK.

I want to keep it as simple as possible: just basic title dumping capabilities, not something major like the BlueDump MOD by scooby; I always said that if you want to do a full NAND FS dump, you can use BootMii + nand.bin extractors, FS ToolBox or Simple FS Dumper. No need to reinvent the wheel.

 

[Iwatasan]

DarkMatterCore, just wanted to chime in and say this is a fantastic application. I'm setting up my new Wii U and decommissioning my old Wii, but I wanted backups of the channels I had on it. I tried so freaking many things to make that happen but only YABDM worked reliably. I would say it worked 100% but I have one issue, and since this release is so new, no amount of searching has helped me find an answer.

I'm trying to back up Photo Channel 1.1 as a WAD. I'm on System Menu 4.2U. From DOP-Mii or NUSD I can download Photo Channel 1.0 and Photo Channel 1.1. I can also download Photo Channel 1.1 from the Shop Channel, but Shop Channel doesn't offer 1.0 anymore. Installing different combinations of these three yields different results. The only combination that seems to work as expected is installing Photo Channel 1.1 from both DOP-Mii/NUSD and Shop Channel simultaneously. Installing either one on their own doesn't work.

DOP-Mii/NUSD downloads an 8.13MB WAD, but installing it only makes it so DOP-Mii reports "v3" installed while in fact nothing appears on the System Menu or in Wii Data Management. Shop Channel downloads a file only 3 blocks in size, and installing it creates a Photo Channel-looking channel on the System Menu, except it doesn't have a "Start" button, and when selected, it displays "To continue using the Photo Channel, you will need to perform a Wii system update." So that one's more of a placeholder channel, but at least it shows up in Wii Data Management and can be erased that way.

Using YABDM I was able to discover the 3 block file was a nameless title under "Disc Savedata" with Title ID 48415a41. Dumping this as savedata yields a 520 byte file, "title.tmd." I understand YABDM can restore this file as well as back it up, but it seems that if the Photo Channel 1.1 (downloaded from the Shop Channel) is erased via Wii Data Management>Channels, YABDM has no reference point to restore the TMD to, and therefore can't do it.

Other than updating to System Menu 4.3U, is there a way around this? Is there a homebrew app other than YABDM that can install TMD files where a savedata title doesn't already exist? If not, would there be a simple way to add such a feature to the next release of YABDM?

I'll probably try updating to System Menu 4.3 to see if this issue resolves itself, but this seems like an interesting enough confounder on the part of Nintendo that perhaps it isn't the only time they've used such a thing. If that's true, maybe a "novel savedata 'restore'/install" feature would come in handy for more than Photo Channel 1.1 and for more people than just myself. Of course that's up to you and depends entirely on how simple it would be to code.

 

[DarkMatterCore]

First of all, I'm glad you found this application useful! It really took me weeks to get it to work just the way I wanted; it feels awesome to know it was handy for someone else, too.

Regarding the whole Photo Channel problem, as far as I know, when both versions are available, the second one doesn't entirely replace the first one; instead, just its "placeholder" in the System Menu gets changed. If you delete v1.1 from the Data Management menu, you should be able to use v1.0 again. That's the way it was originally meant to work. Actually, as you may have already noticed, they're installed to different directories, thus having different TIDs.

Just like you're saying, it's completely possible for YABDM to restore the title.tmd file you mention if the title directory already exists, but it would be hard to do that once it gets deleted for two reasons:

1. The "reference point", namely, the directory itself, doesn't exist. YABDM strongly relies on it to do its operations.

2. If a TMD exists, most likely the Ticket file for the title is lying around in /ticket, too. When the title gets removed, usually, the Ticket file is also deleted; why is the title.tmd file sometimes left behind, beats me. In this particular case, the application has no way to get the Ticket and reinstall it. Remember: if a title exists, it HAS to have a Ticket.

It would be "feasible" to do with ES_* calls, but again, I don't want to add title installing functions to YABDM. There are already a lot of applications that excel at doing this.

It's a very weird problem, anyway. I have messed around with this channel in countless opportunities and never had anything like this. I'll look into it and see what can I do for you.
_____________________________________________

EDIT: Here are my findings about this title. Even though it gets installed to /title/00010000 (like any common Wii save data), it DOES have a content file, 00000000.app. I succeeded in creating its WAD file by first copying the "channel" to the SD Card using the Data Management menu, and then converting the content.bin file using YABDM.

It seems that this title is the one responsible for replacing the Photo Channel v1.0 placeholder with the v1.1 data. So yeah, when you delete it, v1.0 becomes usable again (if it's installed, of course). Better yet, it does have an internal name, it is just not being read properly because YABDM treats it as a savedata and thus, tries to open its banner.bin (which doesn't exist).

I'll release a new version as soon as possible.
_____________________________________________

EDIT #2:

YABDM v0.8 (September 24th, 2013 - DarkMatterCore):

* Added support for title 00010000-HAZA. It is the responsible for controlling the Photo Channel "swap" between versions 1.0 and 1.1. When it is present, v1.1 is displayed in the System Menu; otherwise, v1.0 is used. Since it gets installed to the savedata directory, it was not being treated as a title, thus its dumping was not allowed; now this behaviour is fixed. Thanks to Iwatasan for noticing this!
* Compiled with the latest libogc git revision from 09/04/2013.
* Now using the latest libruntimeiospatch revision. The previous version was not properly patching the hash_old[] pattern because it had the same value as new_hash_old[]. I informed Excelsiior about this and the change has now been made to the GitHub repository.

Download: http://www13.zippyshare.com/v/31660912/file.html.

Please, try it out!

 

[Iwatasan]

Even though you came at it from a slightly different angle, you still solved my problem. In your initial response, you focus on the issue of having Photo Channel 1.0 and Photo Channel 1.1 at the same time. Re-reading my first post I realize I did not make clear enough that I was focusing on the issue of having Photo Channel 1.1 from NUSD/DOP-Mii (8.13MB version) and "Photo Channel 1.1" from Shop Channel (520 byte version) installed at the same time, WITHOUT Photo Channel 1.0 being installed (I removed it with DOP-Mii). But, the main issue was just dumping that little 520 byte title to WAD, which was a point that apparently got across!

Furthermore, you solved the problem much more gracefully than the way I suggested. After reading your replies and thinking harder about the problem, it's pretty clear this little 520 byte title is just an unusual answer to the unusual question of, "How should Nintendo update the Photo Channel in a way that allows users to downgrade back to the original version if they try 1.1 but don't like it?" Unusual, and I think, most likely unique. Adding a title installing function to YABDM to solve the problem of restoring a backed-up copy of such a unique title.tmd would most definitely be overkill since it's almost certainly the only example of Nintendo doing things this way. Making an update that specially handles just this unique title may also seem overkill to some, but I think it's awesome that you did it, even though there was already a workaround method I had overlooked!

I could have done exactly what you did by transferring the BIN to SD and converting it to WAD with YABDM, but I didn't think of it. Why didn't I think of doing that? I hadn't tried converting a BIN to WAD via YABDM yet. In fact, I have seen posts on various forums where noobs get flamed for asking the ridiculous question of "Can a BIN be converted to WAD?" I am quite surprised YABDM can do it, and this on top of directly backing up channels as expertly as it does!

Judging by your edits, though, I'm quite certain you're talking about the exact same "Photo Channel 1.1" from Shop Channel (520 byte version) that I was principally addressing in my first post. So it's called "title 00010000-HAZA" is it? Has a nice ring to it don't you think? No? Haha. Perhaps you can send me that WAD since that's really what I've been after and it would save me the trouble of digging my Wii back out of the closet to mess with it? Can we arrange that?

In your second edit, perhaps it should read:

YABDM v0.8 (September 24th, 2013 - DarkMatterCore):

* Added support for title 00010000-HAZA. It is the responsible for controlling the Photo Channel "swap" between versions 1.0 and 1.1. When it is present, v1.1 is displayed in the System Menu; otherwise, v1.0 is used even if v1.1 is installed via NUSD or DOP-Mii. If v1.0 is not installed, NOTHING will be displayed, even if v1.1 is installed via NUSD or DOP-Mii. Essentially, this extra title is required for the proper display of the Photo Channel v1.1. Since it gets installed to the savedata directory, it was not being treated as a title, thus its dumping was not allowed; now this behaviour is fixed.

I'm sorry such a minor gripe required a whole new release just to correct this one little unusual/unique glitch, but I certainly appreciate the effort. And since you had to update a couple other things too I hope I shouldn't feel like I put you out too much! Haha. Anyway, really great fuckin' work man! You rock!!! Love the app. THANK YOU!

 

[DarkMatterCore]

What's so unusual regarding this title is that it gets installed to /title/00010000 (savedata dir)... If it was installed, for example, in /title/00010001 (installed channel dir), an update to YABDM shouldn't have been necessary. The problem was mainly related to the way the application handles each type of title; a proper workaround would be to check the "content" dir for the currently selected savedata and see if there are any APP files on it. But, just like you said, this would be overkill... this is probably the only case of a channel being installed as a savedata, so the whole fix for it was just adding an exception in the dump_menu() function (yep, a hardcoded solution).

I think it is pretty clear now that there actually exist three different titles referred to as "Photo Channel":

• v1.0.
• v1.1.
• "Swap" module installed in the savedata directory.

It was fun to do this fix, I actually didn't know about the existence of this third title.

Re-reading my first post I realize I did not make clear enough that I was focusing on the issue of having Photo Channel 1.1 from NUSD/DOP-Mii (8.13MB version) and "Photo Channel 1.1" from Shop Channel (520 byte version) installed at the same time, WITHOUT Photo Channel 1.0 being installed (I removed it with DOP-Mii).

I wouldn't worry too much, after all my English is not that good and I may have misunderstood some of the information. But after doing my tests, it was pretty clear to me what you wanted to do.

I could have done exactly what you did by transferring the BIN to SD and converting it to WAD with YABDM, but I didn't think of it. Why didn't I think of doing that? I hadn't tried converting a BIN to WAD via YABDM yet. In fact, I have seen posts on various forums where noobs get flamed for asking the ridiculous question of "Can a BIN be converted to WAD?" I am quite surprised YABDM can do it, and this on top of directly backing up channels as expertly as it does!

Lord Coolman was the one who suggested this in the first case. It wasn't really hard, the content.bin format was already documented on Wiibrew; all I had to do was adding a way of reading the console-unique key (PRNG Seed) from the OTP, and of course write new code to handle the contents stored inside the BIN file.

The first version of the code was very ugly, since I was decrypting the part A of the file (which has a fixed length of 0x640 bytes) to get the size of the part B, then I sought the combined length of both parts to get to the part C (which, by the way, also has a fixed length of 0x80 bytes), where I then read the size of the TMD (part D). Once I got to the TMD offset, I was able to actually do the conversion process, since everything else after it (part E) is essentially the encrypted channel contents.

The current code now searches for the "Bk.." magic word, which can be used to identify the offset of the part C.

Judging by your edits, though, I'm quite certain you're talking about the exact same "Photo Channel 1.1" from Shop Channel (520 byte version) that I was principally addressing in my first post. So it's called "title 00010000-HAZA" is it? Has a nice ring to it don't you think? No? Haha. Perhaps you can send me that WAD since that's really what I've been after and it would save me the trouble of digging my Wii back out of the closet to mess with it? Can we arrange that?

Yup, "HAZA" is the ASCII representation of the hexadecimal Title ID you posted earlier, "48415a41". It's easier to remember IDs this way than having to memorize their hex counterpart.

Anyway, check your PMs.

 

[Iwatasan]

I think it is pretty clear now that there actually exist three different titles referred to as "Photo Channel":

• v1.0.
• v1.1.
• "Swap" module installed in the savedata directory.

It was fun to do this fix, I actually didn't know about the existence of this third title.

Yep you've got that straight. I like the name "Photo Channel Swap Module" too, good choice. Has a better ring to it than "00010000 HAZA." Haha. Well, judging by the effort I put into trying to find information about it, I'd say hardly anyone knows about its existence. I wish I could say I knew about it all along, but it was definitely stumbled upon purely by accident. Would have been very easy to miss.

Here's the explanation of what happens under every combination of these three titles:

If Photo Channel 1.1 is installed on its own, a channel will not be displayed for this app on the System Menu; installing the Photo Channel Swap Module is required for it to properly display and function.

If Photo Channel 1.0 is installed on its own or alongside Photo Channel 1.1 without the Photo Channel Swap Module, Photo Channel 1.0 is used, and Photo Channel 1.1 is not.

If the Photo Channel Swap Module is installed on its own or alongside Photo Channel 1.0 without Photo Channel 1.1, Photo Channel 1.0 will not be used; instead, an unusable placeholder channel for Photo Channel 1.1 will be displayed, telling you to update your Wii to the latest version of the System Menu.

If Photo Channel 1.0, Photo Channel 1.1, and the Photo Channel Swap Module are all installed simultaneously, Photo Channel 1.0 will not be used, but Photo 1.1 will be used and properly displayed.

It wasn't really hard, the content.bin format was already...blah blah blah...all I had to do was adding a way of reading the...blah blah blah...and of course write new code to handle the...blah blah blah...etc.

Haha, I get the gist of your technical explanation (thanks for dumbing it down for me too, haha), but yeah the details are over my head. A hacker who winds up here from a Google search is more likely to be able to fully appreciate the details as well as the skill it must have taken to pull off the previously impossible. As for me I just appreciate how approachable you've been.

So, thanks for the app, thanks for the update, thanks for the WAD, and thanks for giving me the time of day. Haha, I think that about covers it. Resume original thread.

Your English is flawless down to the proper usage of semicolons, by the way. No need to even bring that up.

 

[bezem]

I also wanted to chime in and say I found this program mighty useful! Some background - I have a special place in my heart for the Wii; it's the first console I bought on my own on launch day and I played that thing into the ground. So with the Wii U's Wii mode I was ecstatic to finally have my Wii Menu back, as I assumed the Wii U would just have some form of integrated backwards compatibility like the Wii did for Gamecube. I personally prefer having the Wii Menu in its own sandbox. As a sentimental fool, I also wanted my Wii Menu to look exactly as it did on my old Wii. That meant the ability to install and have all the channels that are missing from the Shop Channel on the Wii U. I had successfully installed all but three - the latest versions of Netflix, Amazon, and Youtube. For some reason when I'd use w?dder and ShowmiiNand with my old Bootmii backups, I couldn't repack these as they'd just give me an error. I also couldn't download them from NUSD as they didn't have a ticket. I tried going in with a Hex editor but my lack of hexperience left me unsuccessful. Using this on an actual Wii, I was able to make WADs of all three, and the Netflix and Youtube both installed! The Amazon threw out a -1022 error when I tried it, so I'm still working on it. Otherwise this app has been exactly what I needed and I thank you and anyone who has ever worked on it!

 

[actar]

Thanks vety much! great application!!

 

[DarkMatterCore]

bezem If you send me a copy of the Amazon Channel dump you created with YABDM, I may be able to fix that behaviour. Error -1022 is usually related to the hash of a given content not matching the one saved on the TMD. This might or might not be a bug in the application itself, I can only be sure of that once I get to examine the output file.

I haven't been very active lately because of my university studies, but as soon as I get my holiday vacations, I'll be back into action. Thank you very much for your comments, I really do appreciate them!

And remember, if you have any other suggestions, let me know about them.

 

[bezem]

I'll be sure to send it over to you; I'll just have to make a new one. I actually tried w?dder and showmiinand again and was able to successfully get the latest Amazon wadded and installed on vWii. That said, I'm more than happy to make an Amazon WAD again from my original Wii and send it over to you for testing. It's my wife's birthday today so it won't be today, but I promise I will!

 

[W hat]

If I have Kirby's Adventure (NES Virtual Console), purchased from the store, and so does a friend, and we both dump it using Bluedump, will our WADs be the same? Will they be identical to a scene release WAD for that game?

 

[DarkMatterCore]

I'll be sure to send it over to you; I'll just have to make a new one. I actually tried w?dder and showmiinand again and was able to successfully get the latest Amazon wadded and installed on vWii. That said, I'm more than happy to make an Amazon WAD again from my original Wii and send it over to you for testing. It's my wife's birthday today so it won't be today, but I promise I will!

No problem at all, I can wait.

If I have Kirby's Adventure (NES Virtual Console), purchased from the store, and so does a friend, and we both dump it using Bluedump, will our WADs be the same? Will they be identical to a scene release WAD for that game?

If both of you fakesign the Ticket, the output WADs should be exactly equal (remember that the Ticket has console-specific information that can only be removed by fakesigning it). Though I doubt the file will be the same as the scene release, because they tend to use a slightly different certificate chain; I don't know the reason behind this. Plus, they don't always add the WAD footer; and if they do, sometimes it isn't aligned to a 64-byte boundary. That's enough to make them fairly different to the ones generated by YABDM.

Another problem I have found is that some WAD packers align each individual content file to a 64-byte boundary before encrypting, whilst YABDM first aligns them to a 16-byte boundary, encrypts the data and THEN aligns the output data to a 64-byte boundary. That's what Nintendo does; if you compare any encrypted content generated by the application (e.g. by using a hex editor), they should be the same as the ones stored on NUS. In fact, the original BlueDump was doing this.

I tend to be very picky with this kind of stuff, so it's only natural the application is aimed to properly dump the data in a way that it complies with the currently available WAD format documentation. I never took the scene releases as a starting point; as a reference point, yes, but no more than that.

 

[JoostinOnline]

It's my wife's birthday today so it won't be today, but I promise I will!

Tell her you're doing something important, but that she can just wait for you in the bedroom.

 

[bezem]

Sorry to necro-bump but I thought I'd follow-up on my promise. Amazon Instant Video actually had an update so I tried making a WAD again using YABDM and it worked flawlessly. So whatever caused WAD creation to fail previously for Amazon is no more.

 

[DarkMatterCore]

I have been updating the application in the last few days. The changes aren't really that big deal (since there's nothing much left to do, apart from maybe doing a GUI), but here are them, anyway:

YABDM v0.92 (February 27th, 2014 - DarkMatterCore):

* Reimplemented the DetectInput() function, now fixed by JoostinOnline.
* Rewrote the GetASCII() function to discard non-valid ASCII characters.
* Button A can no longer be used in the content.bin conversion mode if the selected directory doesn't have a content.bin file inside.

YABDM v0.91 (February 26th, 2014 - DarkMatterCore):

* Fixed a very silly regression bug in the name reading code.
* Fixed GCN Controller compatibility. For some odd reason, the controller input acts erratically using the DetectInput() function, so for now I'm just reverting back to the old waitforbuttonpress(). I swear I received my controller just a moment ago; otherwise, I wouldn't have noticed that.

YABDM v0.9 (February 26th, 2014 - DarkMatterCore):

* Rewrote the title name reading functions from scratch. The application can now read multilingual names and descriptions from contents stored on the NAND filesystem and content.bin files using the IMET and WIBN structs from Wiibrew, and the __convertWiiString() function from AnyTitle Deleter by bushing.
* Improvements to the save dumping/flashing code.
* Minor cleanup to the WAD dumping code. The application will now also check if the Ticket and/or TMD data is already fakesigned before trying to wipe the signature.
* If you choose to fakesign the TMD, the application will now display a prompt asking if you want to change the WAD region. This is done by modifying the value @ 0x19D in the TMD, just like FreeTheWads on PC.
* A "(vWii)" suffix will be displayed along with the System Menu version if the application is running under vWii (thanks to JoostinOnline and crediar for their IsWiiU() check).
* Updated libruntimeiospatch to v1.5.1.
* Updated application headline and meta.xml credits to reference HacksDen.com.

You can find the download on the first post.