Wii Common Key Bin

Common Key Bin Loadstructor DOWNLOAD (Mirror #1) 520aad1ef5 Lowe's,Companies,Inc.,is,a,Fortune,500,American,company,that,operates,a,chain. Hello fellow pirates, a couple days ago i decided to turn my wii u into a mario party machine, housing the ten main mario party games in a folder on the home screen (plus ds), this morning my dream came true, or so i thought, i used the phacox injector to inject mario party 1 and 3 onto my wii u (i bought 2 a few years back) i used mario 64 as. Needs common key (key.bin) to work! (Pro Note: DSi decryption will work with a (dskey.bin), however that doesn't exist now) v1 - April 5, 2009. Initial release; Supports downloading and packing to WAD; Wii/DSi support; Uber-betas. Obtaining your Wii U Common Key: Download and install HxD (or equivalent Hex Editor,) and the NandDumper homebrew application; place it into your SD:wiiuapps folder. Open NandDumper on your Wii U and then dump the OTP.bin to your SD Card.

NUS Downloader
General
Author(s)WB3000
TypePC utility
Versionv1.9
Links
Download
Discussion
Source

NUS Downloader, or NUSD, is a Windows program designed to allow easy access to the resources present on NUS. Using this tool, you can download, pack, and decrypt many system titles into WADs ready to install.

NUSD v1.9 in Windows.
  • 9Update History

WARNING!

Wii common key bin

This tool creates WAD files. If it should happen to have issues during this procedure, installing corrupt WAD files could BRICK your Wii. Don't use this program if you are not sure of what it accomplishes. This program comes without warranty, and the makers of the program (and of this guide) are not responsible for any damage caused by installing a corrupt WAD or installing it incorrectly.

Usage

Load the program, and enter a title ID and optionally a version number. Title IDs can be found in the Title database or IOS History.

Looking below, evaluate whether the checkboxes have the desired values.

  • Keep Encrypted Contents: Leaves the 00000000, 00000001, etc. files present. These are what make up a WAD, but are not necessary to keep if you only want a WAD.
  • Create Decrypted Contents: Uses the Wii/DSi key to create corresponding 00000000.app, 00000001.app, etc. decrypted NUS content files.
  • Pack WAD: This creates a WAD file of the desired NUS title. This is only available for Wii titles.
  • Use Local Files: This skips downloading files that appear to be present in your local title library.
  • Patch IOS: This, in conjunction with Pack WAD, patches NUS IOS titles with various exploit-enabling 'features.'

Press Start NUS Download, and wait for the title download to finish. When completed, you can find the downloaded/created files in titlestitleIdversion*

System WADs can be installed using WadImport and DOP-Mii.

Protips

  • You cannot get free games with NUSD.
  • Title IDs are 16 characters long: no dashes/spaces/symbols.
  • Having a (Mismatch) message is OK. It relates only to the difference between TMD and actual content sizes.
  • Entering no version number will get the latest one. Remember that System Menu's have separate versions for each region, so you may not want the latest one.
  • A failure to download a TMD means either your internet is not connected or you are entering incorrect information.
  • A failure to download cetk (tickets) means that the title can still be downloaded, but not packed or decrypted.
  • This program requires the Microsoft .NET Framework 2.0 to run!

WhyWhat?

There are several reasons to use this program.

  • Avoid unnecessary pirating of System WADs (IOS modules, System Menus, etc.)
  • Obtain a specific version of a System Title (Menu 3.2U, etc.)
  • Simplification of download and packing process.
  • Decrypt contents straight from NUS.

What this does NOT do:

  • Package VC/WiiWare/DSiWare needing an individual ticket.
  • Decrypt WC/WiiWare/DSiWare titles (no tickets!)

Title IDs

Wiibrew has quite the collection of Title IDs for use with NUSD. For most general titles, check out the Title database. For IOS ids specifically, check out the IOS History.

New to v1.2 is a local database of title IDs in the database.xml file. To access this, simply click the database button in NUSD, and select a title based on category.

Database

The NUSD database is stored in the database.xml file, which should be placed in the same directory as the executable. It is a simple, formatted XML document. A separate page has been dedicated to the database, here you can find the latest copy as well as how to format the file.

A lot of information is portrayed in the database icons for each title. Here's what the color codes represent:

Green: The title has a ticket available.Orange: No ticket is available.Red: A notice/danger text is present in the database. These titles are usually crucial to the Wii.

For DSi Users: Versions 1/9 and later support a dsidatabase.xml, which can be found on DSiBrew.

Credits

NUSD was written by WB3000, but much of the code would not have been possible without the help of #WiiDev, in particular Crediar, comex, Galaxy, and SquidMan. The advice and source code provided by them made this program possible.

Releases post-v1.3 had significant contributions by lukegb.

Bugs & Suggestions

Be sure to report any bugs so I can work to fix them!

Todo:

  • Command Line (CLI) Support

Update History

v1.9 - January 19th, 2011

This build is intended to provide updated DSi features to users before the release of v2.0.

The DSi Common Key is NOT embedded into this release. Once it inevitably spreads and becomes common place, I could embed the key. Many sites do not want any trace of it, so this build respects this request.

  • Multiple GUI changes
  • DSi Decryption support fix
  • DSi Database support (dsidatabase.xml)
  • Supported by libWiiSharp framework
  • Improved local scripts support
  • New directory structure (titlestitleidversion*)
  • Script loading from database.xml
  • IOS Patching
  • Reads key.bin, kkey.bin, and dsikey.bin
  • WAD file SaveAs support
  • Whatever else happened in the months between...

CLI Mode did not officially make it to this build. Sorry!

v1.5a Beta (bugfix release) - July 1st, 2010

  • Fixed crash when opening Virtual Console menu

v1.5 Beta - June 29th, 2010

  • Moved update database option to Extras menu, added ability to download database if none exists
  • Added ability to download common key (via HackMii blog) if does not exist
  • Added ability to accept hex STRING versions of the common key
  • Made the database reading multi-threaded, so as not to delay GUI loading.

Unofficial v1.4 (still beta) - April 16, 2010

  • Some bugfixes (Linux-oriented) - lukegb (probably the only changes I'll be committing)
  • Fixes/GUI changes - WB3000

Note: this version is highly untested, and I pushed it out mostly because I wanted the Linux-related path fixes to go out.

v1.3 Beta - October 6, 2009

  • Database updates via the GUI.
  • Simulated Wii Updates for each region.
  • Optimized WAD Packing code.
  • WAD File may be saved to a user-specified location.
  • You can chose to delete the contents after WAD packaging.
  • Support for NUS scripts (used by Wiimpersonator, etc.)
  • Proxy configuration and authentication (Tested by Napo7)
  • Certs collected on the fly (No more cert.sys)
  • Windows 7 taskbar support.
  • WAD naming scheme updates (Suggested by Attila)

v1.2 - August 1, 2009

  • Access a local database (database.xml) of title IDs, along with versions/regions/etc.
  • With database selection, IOS WADs are given Nintendo naming convention (ex: IOS60-64-vXXX.wad)
  • Mismatches are identified as Safe or BAD.
  • Command line arguments can be passed to the GUI.
  • Korean key (kkey.bin) support. Useless as far as I know, nothing on NUS uses the key...
  • Downloading failures are now described in more detail (401 vs 404, etc.)
  • Status Box has a clear button; it is auto-cleared when starting a new download.
  • UserAgent changed (again) to the Wii updating one.
  • A title's required IOS is shown in the download log.
  • Trucha signing titles (Still in Beta/Alpha stages! By default it is disabled, to display the feature, click the progress bar on the main form)
  • Trucha signing features the following:
    • TMD editor (Change IOS needed, title version, title ID)
    • Ticket editor (Change DLC Amount, Common Key needed, Time limit)
    • Contents editor (Add/Remove Contents, Set shared status, Set boot content, Add trucha bug to content [only decrypted contents have support so far!!])

v1.1a - May 17, 2009

Wii Common Key Bin

  • Prevented users from entering nothing...
  • A few little tweaks (About text, etc.)

v1.1 - May 16, 2009

  • Directories are created with the version number when known (ex: 0000000100000002v289)
  • Certificates (cert.sys) no longer hard coded. You will be asked to generated the file on first boot of v1.1. This is done right from NUS.
  • Ability to alter the name of the packed WAD from the GUI.
  • Loading a TMD for info displays more information, such as what IOS a title requires.
  • Textbox output is a bit cleaner.
  • You can now choose to continue the download if a ticket (cetk) 404s. This will allow you to download the content of the titles, however you will not be able to pack them.
  • Decryption of contents now included. Needs common key (key.bin) to work! (Pro Note: DSi decryption will work with a (dskey.bin), however that doesn't exist now)

v1 - April 5, 2009

  • Initial release
  • Supports downloading and packing to WAD
  • Wii/DSi support

Uber-betas

The latest compiled version of the software can be found on the project Subversion repository at Google Code in trunk/NUS Downloader/Latest/NUS Downloader.exe - note: no support will be provided for these releases, any bugs filed should be CLEARLY tagged and many features can and will be broken.

Retrieved from 'https://wiibrew.org/w/index.php?title=NUS_Downloader&oldid=112221'
Wii common key bin download

Wii U Common Key Bin

By popular request, here’s an explanation of the different encryption keys that are used on the Wii.

AES Keys: The Wii uses 128-bit (16-byte) symmetric AES (aka AES-128-CBC) for most encryption.

  • Common key (ebe42a225e8593e448d9c5457381aaf7): This is the “shared secret” that we extracted with the Tweezer Hack. This key is known by all Wiis, but is never used, directly, to encrypt anything. Instead, all titles are encrypted with a random AES key; this key is then encrypted with the Common key and then stored inside a ticket. The ticket is then transmitted along with the content — on discs, it’s part of the “certificates” found before the encrypted data starts. Thus, knowing the common key allows you to decrypt most Wii content, as long as you have the right ticket. This key is stored in the OTP area inside the Starlet ARM core inside the Hollywood package.
  • SD key (ab01b9d8e1622b08afbad84dbfc2a55d): This is another shared secret — also stored on the Hollywood, but also found plenty of other places, including inside the firmware images. This key is used by the System Menu (1-2) to encrypt anything before writing it out to the SD card, and it’s used by 1-2 to decrypt anything read from the SD card. This is done mainly for the purpose of obfuscation, to keep people from examining savegames. It’s worth noting that all Wii games save their data to the internal NAND — no game supports loading or saving data directly to SD. This frees game writers from the requirement of handling this step themselves; they just write the savegame data, unencrypted and unsigned, to their title-data directory inside the NAND filesystem; the system menu then handles everything else. (The real reason for this is probably that it allowed Nintendo to make a system where they didn’t have to expose the details of this encryption — or any encryption — to their licensed game developers.) This key is also stored in OTP, and in several places in IOS (for no apparent reason). If you’re using Segher’s tools, you may also be interested in the SD IV (216712e6aa1f689f95c5a22324dc6a98) and the MD5 blanker (0e65378199be4517ab06ec22451a5793), both of which are stored inside the 1-2 binary.
  • NAND key (varies): This AES key is used to encrypt the filesystem data on the actual NAND chip itself; it is probably randomly generated during manufacturing and is also stored in the OTP area of the Starlet. This key is used to prevent the contents of the NAND filesystem from being read using a flash chip reader. Nintendo may or may not actually record this key anywhere, since they (theoretically) don’t need to ever use it. In fact, in some similar systems, keys like this are generated automatically by the device itself and (theoretically) never leave it — the Wii shares some design prinicples with HSMs, but it certainly doesn’t manage to be one. This is another OTP key.

RSA keys: The Wii uses RSA-based authentication in several different places. This is fundamentally different than the AES encryption used for data-hiding, because RSA is an asymmetric cipher, meaning there are no shared secrets — nothing to be extracted from the Wii. The only RSA keys stored on the Wii are public keys, used to verify authenticity of content.

  • CP: Content Protection? This key is used to sign the TMD associated with every title. The TMD contains a SHA1 hash of the contents of that title, proving that it had not been modified. My 24c3 presentation was done by injecting a new .DOL into a Lego Star Wars disc and then forging the signature on its TMD, using a flaw originally discovered by Segher. After that presentation, people eventually discovered the common key needed to decrypt update partitions, allowing others to analyze / disassemble IOS. xt5 (who I had the pleasure of meeting at 24c3) was then able to find the same flaw and implemented it in his Trucha Signer. In fact, from disassembling his code, the core part of it was almost identical to our never-released code — great minds think alike, eh?
  • XS: “Access”? This is the key that signs tickets, which contain the title keys for individual titles.
  • CA: Certification Authority: This key signs both the XS and CP keys.
  • MS: “Master?” This key is used to sign the certificate that contains a copy of your Wii’s public ECC key. This certificate is then appended to savegames on SD cards, so that any other Wii can verify that the key was issued by Nintendo.
  • Root: This is the “grand master key”, which signs the CA key. The public half of this can be found here.

ECC keys: The Wii uses Elliptic Curve Cryptography in a few select places — primarily, it uses this when it signs savegames before writing them to SD card. ECC is used in ways similar to RSA, but it’s somewhat newer and much faster to run on an embedded system.

Other: For lack of a better place to put it, there is also an HMAC key — a 20-byte value that is used in a SHA1-based HMAC of the NAND flash contents to prevent them from being tampered with. This is a commonly used scheme in embedded systems, where a device wants to “sign” something itself, for itself. There are no public vs private keys here — you need to know this value in order to verify the hash, and you need the same value to generate the hash. This isn’t appropriate for communications between two people, but is perfectly fine for letting the Wii test to see if the chip was pulled, rewritten, and resoldered.

Key storage: The public keys are stored in various places — these aren’t sensitive, so they don’t really need to be concealed (although at least one of them needs to be protected from modification, and it can then sign the others). The rest are stored in two places:

Wii U Common Key Bin

  • Hollywood SEEPROM: After meeting him at 24c3, bunnie was kind enough to decap some chips for me, including a Hollywood. One of those chips is 2kbit serial EEPROM, which stores the MS signature on the the ECC key.
  • One-Time Programmable Area: Inside the Starlet ARM core, there are a bunch of things:
Common
  1. SHA1 hash of boot1
  2. Common key
  3. ECC private key
  4. NAND HMAC
  5. NAND AES key
  6. RNG seed
  7. other stuff we can’t yet decipher
All of that info comes from tmbinc, who recovered it with a method he described here.