Hacking HW_AHBPROT modification steps or guide?

  • Thread starter Thread starter officialjunk
  • Start date Start date
  • Views Views 10,650
  • Replies Replies 29
  • Likes Likes 1

officialjunk

Well-Known Member
Newcomer
Joined
Oct 4, 2008
Messages
72
Reaction score
20
Trophies
1
XP
234
Country
United States
I'd like to contribute to vwii homebrew. After reading Cyan's post:
Currently, everyone is doing a FS Nand Dump, which, except saving the current files one by one, doesn't really do a real 1:1 NAND dump to flash the full state at a later date.
There are NAND dumpers which are doing 1:1 dumps:
...
RealWnD sources are available, and if it could be updated to support vWii + AHBPROT it would be much better backup solution than the current FS Dumper.

I have decided that I will try to mod RealWndD to use HW_WHBPROT and I have a couple questions:

1) Are there any guides (or can someone provide steps) that cover upgrading current cIOS dependent apps to use HW_AHBPROT instead? In some preliminary research, I've come across a couple code examples: fstoolbox and savegame manager gx as well as this hackmii post on the topic. I'm not sure if these are the best examples, so if you know of any other examples, please share them.

2) Are there any differences between HW_AHBPROT support of vwii vs wii? For example, if I make the change to RealWnD, can I test that HW_AHBPROT support is working on my reglar wii?


I'm adding a couple quotes of people that have done similar modifications or may be knowledgeable on the subject:

...which I had modified to add in support for AHBPROT runtime IOS patching so it would actually work in vWii.

Can you share the diff of your HW_AHBPROT changes, dmm?


... I modded the IOS236 installer so you dont need the IOS36 wad...

Do you help with any info, fix94?
 
  • Like
Reactions: Pattonfiend67
I have always felt that those new guides that are telling people to make a FS dump to backup their wii was completely stupid, but I haven't had the care enough to go out of my way. I'm glad that at least someone is trying something. I'm no coder so I can;t help in that area, I'm just a brick repairman.
 
the tmd access right is used for channel launching. It has the same effect than using the homebrew channel with the <ahb_access/> tag.
They both grants the hardware access to the launched homebrew.

You need to remove the IOS reload (which probably use IOS249) to prevent loosing hardware accesses.
There's a way to reload IOS and keep access rights, but the purpose here is to remove all references to cIOSes.

The sources you linked are used to patch the accesses in memory.
You can use the iospatch v3 (or libruntimeIOSPatch) which include both Wii and vWii patches.

IOSPatch v3
LibruntimeIOSPatch v1.3

FSToolbox 0.4c sources, using libruntimeIOSPatch.
0.4d doesn't have the sources, but reload into IOS36 before patching to prevent error -1029 (there's an example in libruntimeIOSpatch API file)
 
/dev/flash access needs to somehow be brought back too...
Nintendo blocked that in IOS a long time ago, and I do not know how to bring that back...

Would anyone else here be able to do such a thing?
 
Just want to throw out an idea or two (related to the /dev/flash access).

I am just wondering whether you could run MINI (i.e. armboot.bin) in WiiMode of WiiU. Perhaps you could load it using Casper? If that is the case, perhaps one could try to use nand_read_page from MINI (or use ppc-skel version of it)?
 
/dev/flash access needs to somehow be brought back too...
Nintendo blocked that in IOS a long time ago, and I do not know how to bring that back...

Would anyone else here be able to do such a thing?

Does this mean that updating one of these 1:1 NAND dumpers to use HW_AHBPROT, it still cannot access everything on the vwii? :(
 
Does this mean that updating one of these 1:1 NAND dumpers to use HW_AHBPROT, it still cannot access everything on the vwii? :(
"use HW_AHBPROT" is a very vague term. Generally people on this forum mean "use the HW_AHBPROT access given by HBC to apply a set of patches to the current IOS". The typical set of patches used by most apps doing this do not give access to /dev/flash. It is probably "simply" a case of creating an extra patch or two to apply to IOS at runtime. But I don't think there is any such patch, at least in public, so someone would have to reverse engineer IOS and create the patch first.
 
Btw, the source for RealWnD is a giant mess. It's effective, but filled with unnecessary steps and variables.

Not too long ago I cleaned up some of it and added GC controller support so I could get a NAND dump from an "Insert Startup Disc" Wii. It's still messy, but you might consider taking a look at it:
http://www.mediafire.com/?5k25nb7u5syepb5
 
Unless I'm mistaken, there is no real requirement for anything more than the code given here: http://wiibrew.org/wiki//dev/flash#Example_Dump_Code

(Obviously that doesn't have any real options or controls, it'll just dump to the SD card, but it could certainly be used as a basis for a more advanced app)

Seems like a more logical choice than the apparently messy and cluttered source of RealWnD. Unless I'm missing some advantage of RealWnD over this?

[Of course, I should specify that there still needs to be some IOS runtime patching at the start of the code, seeing as the code was originally written for older revisions of IOS where such patches would not have been necessary]

EDIT: OK, I actually bothered to read and found that RealWnD handles a return value of -12 from IOS_Read() differently; I'm sure it couldn't be that hard to fix that part of the above linked example code with reference to the relevant code in RealWnD.
 
  • Like
Reactions: JoostinOnline
And to my second question: can I test this out on a regular wii to confirm its working? Or would the version for vwii differ from that of a normal wii? The sense I am getting is that the patching is different between the two, but I'd like to confirm.
 
And to my second question: can I test this out on a regular wii to confirm its working? Or would the version for vwii differ from that of a normal wii? The sense I am getting is that the patching is different between the two, but I'd like to confirm.
Yes and no. If it doesn't work on a real Wii, then it won't work on a vWii. However, that isn't necessarily true the other way around. The vWii requires extra patches to the IOS.
 
Yes and no. If it doesn't work on a real Wii, then it won't work on a vWii. However, that isn't necessarily true the other way around. The vWii requires extra patches to the IOS.
Not for dumping NAND it won't. The extra patches are only needed if you're trying to install system titles. They are completely unnecessary if you're not doing so. ANd dumping NAND doesn't involve installing any system titles, so the additional patches would be completely useless and redundant.
 
Not for dumping NAND it won't. The extra patches are only needed if you're trying to install system titles. They are completely unnecessary if you're not doing so. ANd dumping NAND doesn't involve installing any system titles, so the additional patches would be completely useless and redundant.
Then why do you need patches for reading files like setting.txt?
 
Then why do you need patches for reading files like setting.txt?
I think he was saying you don't need the EXTRA vWii patches, that using only the original Wii patches would be fine to get that done on vWii as long as no system titles are being installed. (not sure if true but that's what I understood.)
 
  • Like
Reactions: JoostinOnline
@JoostinOnline
The patches you're talking about are in /dev/fs and are required to bypass file access rigths.
The pathes the OP is talking about are in /dev/flash and are for reading raw data from nand, filesystem is not involved at all.
 
  • Like
Reactions: JoostinOnline

Site & Scene News

Popular threads in this forum