Hacking Stable Nand Dumper + RedNAND

  • Thread starter Thread starter pwsincd
  • Start date Start date
  • Views Views 116,771
  • Replies Replies 573
  • Likes Likes 52
no, the nand backups are fucking broken, they're not for the end user, haha. the way you pseudo-fixed them is wrong and gross. corrupted backups will still happen even if more rare.
and is that really what you call "heavily locked-down" ? lmao
The nand backups are literally not broken and have error handling built in. It appears that you haven't looked at them, here's the source code. You can continue to say they're broken all you like, but they're not. I also noticed that you didn't comment on the useful new ability provided with vWii hacking.

And... yes. I'd call the Wii U a heavily locked-down console. The user isn't even allowed to browse the filesystem as the owner of the console, nor are they allowed to install anything without it being signed by Nintendo. Anyway, my point still stands even if you remove the word "heavily"; An iPhone isn't being released here, but rather tools to run unauthorized code on a locked-down console.
 
@Mrrraou and you contributed what to the WiiU homebrew scene?

The current public IOSU related stuff (beside the exploit discovery and iosuhax) is done by the people who did like 95% of the current WiiU Homebrew Scence (Including, libs, frameworks, apps, games and util applications)..

It appears that you haven't looked at them
Same applies to much more things. I'm just referring to "HBL have shitty kernel exploits in it and use random different kernel mapping" - arguments.. ~
 
Last edited by Maschell,
The nand backups are literally not broken and have error handling built in. It appears that you haven't looked at them, here's the source code. You can continue to say they're broken all you like, but they're not. I also noticed that you didn't comment on the useful new ability provided with vWii hacking.

And... yes. I'd call the Wii U a heavily locked-down console. The user isn't even allowed to browse the filesystem as the owner of the console, nor are they allowed to install anything without it being signed by Nintendo. Anyway, my point still stands even if you remove the word "heavily"; An iPhone isn't being released here, but rather tools to run unauthorized code on a locked-down console.
i have read the source code. as i said, dumping the same block multiple times and checking if it matches the previous one isn't a solution. i don't need to argue in how that's broken here. also, if i didn't comment about that, it's either because i don't care/i don't have anything to say about it/i didn't bother to check how it was done.

and, as you keep using that device as an example, it's indeed the same for the iPhone. but the wii u isn't heavily locked-down lol, it's broken as fuck.

@Mrrraou and you contributed what to the WiiU homebrew scene?

The current public IOSU related stuff (beside the exploit discovery and iosuhax) is done by the people who did like 95% of the current WiiU Homebrew Scence (Including, libs, frameworks, apps, games and util applications)..


Same applies to much more things. I'm just referring to "HBL have shitty kernel exploits in it and use random different kernel mapping" - arguments.. ~
and how what i contributed to the wii u scene matters ? if i follow your logic, what SALT says would be irrevelant because they didn't take part in the "Wii U homebrew scene" publicly ? that's stupid. that's not how you answer to facts, lol
i don't care about who did this. it's dirty, so i say it. who i am doesn't really matter here, as long as i know what i am talking about. (+ the current Homebrew Scene is pretty gross too. HBL is fucked up.)
 
  • Like
Reactions: Arck
and how what i contributed to the wii u scene matters ?
The only thing I get from your posts is "mimimi everything thats public is bullshit and sucks. But I don't even want try to change it. Complaining is just enoguh. mimimi"
This whole attitude is kinda unsympathetic =/

Don't get me wrong. I look forward to the team SALT stuff. Its not irrevelant what team SALT says. Its just how they're telling and WHAT the are telling. Basicly they are just complaining how much everything sucks other people do (Without even knowing the current homebrew state, devs, apps etc...) .

It just sucks that a lot of people are like "OMG, hahah. wtf are you even doing there. you suck. lmao." without even TRYING to help. Not even giving tips, hints or try to work together. None of the people I know EVER got anything like "hey, I see you're working on iosu thing too, lets works together to make a aweseome wiiu scene", or just "Hey you're doing XY wrong because this will result in problems in the future, try to do XY".
And like I said: The people "releasing" stuff are the people who are the actual devs of this scene and create this whole current scene in the past year.
 
Last edited by Maschell,
i have read the source code. as i said, dumping the same block multiple times and checking if it matches the previous one isn't a solution. i don't need to argue in how that's broken here. also, if i didn't comment about that, it's either because i don't care/i don't have anything to say about it/i didn't bother to check how it was done.
Then you should read it again. You obviously didn't understand it.
 
https://github.com/dimok789/iosuhax/blob/master/ios_fs/source/dumper.c#L141
yeah obviously. whatever, it still tries dumping the same block multiple times.
You are not even close with your assumptions. Dumping the MLC was never an issue. There are no error codes on it and the MLC dump was always clean. I just added that retry when I initially implemented a check for errors and didn't remove it later as it doesn't hurt.

The issue for "unreliable dumps" was actually the SLC dump and you probably didn't even notice it but its not the same method anymore and not even the same function that smea used. You also probably didn't try to understand it or the read mechanism there because you probably don't even know what the problem was. You are just making assumptions. I wonder where you saw a compare of the previous read data in the code. I mean common....its simple C code.

Also was there even one signle report of a not working dump with this method? I didn't see one. All people I know that tested it reported to me it was always working.

So Mr. "i know what i am talking about". I've talked to several people that actually do know what they talk about over the years in Wii and WiiU scene and I can truly say that you are not one of them.
 
You are not even close with your assumptions. Dumping the MLC was never an issue. There are no error codes on it and the MLC dump was always clean. I just added that retry when I initially implemented a check for errors and didn't remove it later as it doesn't hurt.

The issue for "unreliable dumps" was actually the SLC dump and you probably didn't even notice it but its not the same method anymore and not even the same function that smea used. You also probably didn't try to understand it or the read mechanism there because you probably don't even know what the problem was. You are just making assumptions. I wonder where you saw a compare of the previous read data in the code. I mean common....its simple C code.

Also was there even one signle report of a not working dump with this method? I didn't see one. All people I know that tested it reported to me it was always working.

So Mr. "i know what i am talking about". I've talked to several people that actually do know what they talk about over the years in Wii and WiiU scene and I can truly say that you are not one of them.
https://github.com/dimok789/iosuhax/blob/master/ios_fs/source/dumper.c#L65 too you know
i really don't need to argue on that.
 
Right.....Try to actually undestand the full function before making an assumption from the variable name.
also, just a point, reading the slc via the raw fs handle and using the raw reading functions is the same thing.
oh and this isn't just a variable name but a comment too, can't you read C code either?
 
Last edited by Mrrraou,
Usually kinda fun seeing this stuff but when a grown man embarrasses himself to this degree its not all that fun to watch anymore :-/
 
Why should it brick? The worst case that can happen is that the EmuNAND bricks, the SysNAND should be fine because all of the NAND Reads and Writes are Redirected to the SD Card instead of the NAND.

The Only thing is that i cannot Update the RedNAND if an update comes out but all other functions should be fine.
Linked NANDs, uninstalling and installing titles are weird. It'll show up on both NANDs sometimes
 
also, just a point, reading the slc via the raw fs handle and using the raw reading functions is the same thing.
oh and this isn't just a variable name but a comment too, can't you read C code either?
I don't understand people like you.
People invest their time to help the community and all you can do is complain.

Of course we can give our opinion. But if we complain about something, we better offer a solution to keep things moving forward.
 
when you dump your NAND, it wipes your SD card.....do I need to put the FW.IMG file back on the SD card to boot RedNAND? I put my homebrew back on and when I click on CFW booter, it goes to the Wii U Menu loading screen and it's been stuck there for a few minutes
 
when you dump your NAND, it wipes your SD card.....do I need to put the FW.IMG file back on the SD card to boot RedNAND? I put my homebrew back on and when I click on CFW booter, it goes to the Wii U Menu loading screen and it's been stuck there for a few minutes
Yes, put back the fw.img, everything will work!
 

Site & Scene News

Popular threads in this forum