Hacking Concerning... /dev/flash...

nitr8

Well-Known Member
OP
Member
Joined
Apr 4, 2007
Messages
375
Trophies
1
Website
vermillion57.wixsite.com
XP
1,548
Country
Gambia, The
A quick writeup...

[UPDATE]:

https://gbatemp.net/threads/realwnd-wii-mini-edition.553349/

So how do i start best... (...as this is my first HACK / PATCH at all).

As a private developer, i like trying new things and i got hold of a NDEV over 1 year ago.
Despite the fact that i almost KILLED one by "...mistake", i decided to get a second one and continue my work on porting stuff to the Wii and DEBUG things.

One day (let's say "like 10 days ago from this writing"), i got myself hold of a Wii Mini and was really interested in it, as it doesn't have Gamecube capabilities like the Wii - seen from the hardware point.
On the other side, it also has way lesser "entry points" if you're going to try and HACK it.

What i came across, was FullMetal5's "bluebomb" exploit, which "installed" fail0verflow's HBC perfectly.
Before testing ANYTHING i decided myself to get a NAND dump in the first place. But Nintendo patched the /dev/flash access with the release of the SystemMenu 3.4, which upgraded all IOSes containing the old - let's say - "BUG" / "FLAW."

Anyway... in order to get a REAL NAND dump in it's BINARY form, i had to use RealWnD, but: FAILED!
I ALWAYS run into the "IOS_Open() returned -6" error upon trying to access "/dev/flash".

I thought myself "how do you get access to the NAND..." and had a perfect idea that i remembered before when i dumped the NAND's filesystem of the NDEV:
Using a slightly modified version of FTPii v0.0.22 by pulling the full source code (including the library code to libseeprom, libotp, libntfs and so on...) off Google Code in a rather "hard-to-get-into" repository, i managed to get access to the Wii Mini's NAND filesystem ("ISFS" or "/dev/fs" called).

So i fired up FTPii after using FullMetal5's "Wii Mini Internet Enabler" in combination with a UGREEN USB-to-RJ45 network adaptor.
There i pulled the whole filesystem. I also used "Yet Another Bluedump MOD v1.85" and pulled EVERY IOS WAD in order to prepare things for investigation.

After that i unpacked all the IOS WAD's and figured out "hey, there's something missing... AND IT'S MISSING IN ALL THE IOSes".
What it looks like to me, Nintendo pulled off the module(s) containing internet-stuff from the Mini in ALL it's IOSes (please correct me if im wrong).
The "Internet" button is not available as seen in the Wii Mini's SystemMenu configuration dialogue.

So I compared the Wii Mini's IOS WAD contents with those from a Wii and it's not only that Nintendo pulled off 1 content from every IOS. They also made changes to some of the other IOS contents (".app"-files).

I didn't know where to start in the first place but then did something easy:
Search ALL the content files of ALL the IOSes of BOTH Wii's at the same time in a row with ONE string: /dev/flash

This is what popped out:

Let's only look at IOS36 as the results are contained in some of the other IOSes as well...

IOS36 of a normal Wii and the Wii Mini has either 1 content only that contains this string:

- On the Wii it's content file "0000000e.app"
- On the Wii Mini it's content file "0000000d.app"

By looking at the files with a standard HEX-editor, i figured out that it contains some kind of a "HEADER" on top of the ELF header.
From what i can say, this special "header's" size is exactly 0x594h.
I removed it by simply deleting it and saved the file in the end and then opened it in IDA as well as GHIDRA for compairing the disassembly contents - which btw. are in ARM code (big-endian style).

In order to get something special to display in IDA, i simply searched the disassembly for "flash" (without the quotes).
IDA's result was a count of 6 from which only 2 where actual calls from a function to strings inside the data section.
The rest of IDA's search results were simply those within the data section.

So i compared the functions "sub_20001808" (which btw. BOTH have the same name in the Wii's and Wii Mini's IOS36 disassembly).
The one from the Wii has a "flaw" / "bug" inside of it - let's say, it's an "if / else" compare which enters function "sub_2000145C" in the end.
AND THIS ONE WAS ONCE IN ALL THE IOSes < IOS40 before Nintendo decided to upgrade to SystemMenu 3.4 whilst removing / fixing it.



...really...?



By looking at the disassembly of the call to the "/dev/flash" string, i very quickly figured out what to do to get the call to function "sub_2000145C" back into function "sub_20001808".
It only needed the change of 1 single bit that is compared against.
Implementing this one into libruntimepatch, i got access to /dev/flash back into IOS AT RUNTIME ONLY.

Though, you still need HW_AHBPROT disabled and MEMPROT disabled as well in order to...:
VOILA: we can do binary ENCRYPTED NAND dumps again - this time, for the Wii Mini as well.

So what is needed to do to be able and flash back a NAND onto the Wii Mini...?

<The next writeup is only very, veeery vague - i can hardly remember...>

BootMii in it's current state doesn't "support" / have USB and may never will.
This might be related because of it not having access to /dev/usb or because implementing an USB stack would make it go past the bounds of a BootMii installed in boot2 size (kind of a buffer overflow in the NAND).
It's up to the guys at fail0verflow if they implement it and IF they are able to implement it.
On the other hand, it would be a question of time if they ever release the BootMii code itself and someone manages to implement USB support into the ARMBOOT core.

</The next writeup is only a very, veeery vague - i can hardly remember...>

Btw.: If you want to know more or even a "proof-of-concept" of a Wii Mini dumping it's NAND in it's binary form, let me know.

IF you ever manage to find the corresponding bit that needs to be changed at runtime and IF you decide to implement a patch to this bit into your own code, please consider giving me a "note" / credit inside your code in form of a simple comment. Thanks.



nitr8,

>>ckickening out<<



Thanks @Fullmetal5 and thanks @marcan from the fail0verflow team for their HBC.

...and thanks to the guys @devkitPro

Not to forget: thanks as well @bushing - you're definitely missed... :sad: ...still have so many questions...






BTW.: You STILL need the NAND AES key in order to extract the binary.
How you do / get this, is part of this writeup. It's JUST not exactly explained - ...but reachable.

 
Last edited by nitr8,

Site & Scene News

Popular threads in this forum

General chit-chat
Help Users
  • No one is chatting at the moment.
    chrisrlink @ chrisrlink: hope this isn't too big