Hacking HBC 1.0.8 Update

[tueidj]

To put it bluntly, sorgelig doesn't know what the hell he's talking about; AHBPROT lets you patch IOS on the fly to make it do whatever you want, there is no need to invent "direct HW access" drivers (which has in fact been done anyway, see the source code for the nand formatter).

 

[sorgelig]

To put it bluntly, sorgelig doesn't know what the hell he's talking about; AHBPROT lets you patch IOS on the fly to make it do whatever you want, there is no need to invent "direct HW access" drivers (which has in fact been done anyway, see the source code for the nand formatter).

to put it bluntly, it's easy to take just part out of context and say something. You didn't understand what i told about. And tell me, mr.blunt how to run AHBPROT application NOT from HBC.
Would be good if you could understand subject better before reply. Having access to originally closed memory area and registers of hardware is what i ment. If you are not satisfied with (brobably some limited) access to HW, inject code into priveleged app (IOS) and then open rest of required access. Surprised?

It's impossible to hide nail in the bag.
Theory is good, but practice shows what you get.
Although i'm not in TT. I've used common hacking tricks many times.

And how about TT's paranoia to make Nintendo think they are not pirates? USB/Wiivare loaders now can insert modules and patch IOS in memory and pirate as much as they want. Such a mis!

So, next, TT will post rules what application with AHBPROT allowed to do and then remove another dosen of apps because they "accidentally" got to much access rights?

 

[bwillb]

go to your bookmarks. delete WiiBrew. Problem solved.
find another site that keeps the files you want

heck, filetrip has most stuff...

 

[tueidj]

Now, with new TT policy, we (developers) HAVE TO use custom drivers for hardware which is pretty much the same set of bugs as cIOS. It's very lame and shame after all...

Can't see how I took this out of context. You said custom drivers are needed, which is false.
I think I understand the subject pretty well, seeing as I wrote Riivolution which uses its own exploit to disable AHBPROT and load a customized IOS.

If you knew what you were talking about, you'd know how easy it is and wouldn't be complaining about it.

 

[Jacobeian]

to put it bluntly, it's easy to take just part out of context and say something. You didn't understand what i told about. And tell me, mr.blunt how to run AHBPROT application NOT from HBC.
Would be good if you could understand subject better before reply. Having access to originally closed memory area and registers of hardware is what i ment. If you are not satisfied with (brobably some limited) access to HW, inject code into priveleged app (IOS) and then open rest of required access. Surprised?

It's impossible to hide nail in the bag.
Theory is good, but practice shows what you get.
Although i'm not in TT. I've used common hacking tricks many times.

No, tuedj is right and you are wrong: you said that AHBPROT allows direct access to NAND which is not true. It only opens doors if you know what you are doing, this is not "more dangerous" than before, people always have and always will create apps than can brick.

And AHBPROT can be run from ANY channels providing you set the proper bits in TMD as bushing explained
Unless you always load your apps using exploits, I don't see how this can bother anybody.
The reason to do that is clear: it's clearly safer than installing patched IOS in the system .. AMEN

And how about TT's paranoia to make Nintendo think they are not pirates? USB/Wiivare loaders now can insert modules and patch IOS in memory and pirate as much as they want. Such a mis!

damn, what with this obsession to know what TT secretly have in their mind. They always said they didn't care what people would do with their apps, I think they are perfectly aware this is used for piracy and guess what ? They probably don't care. It's just that it's not the reason why they are hacking the Wii and this is why they don't support it. Can't you understand the world is not just black or white ? They are not TT lovely pussies on one side and bad thieves on the other side. There are people who choose to focus on one particular aspect of hacking and deliberately choose to ignore and not support other things, for reasons that belongs to them.
.
QUOTE

So, next, TT will post rules what application with AHBPROT allowed to do and then remove another dosen of apps because they "accidentally" got to much access rights?

sorry but you are clearly the paranoiac here

 

[WiiPower]

[...]
what "rule" ? it's THEIR website and THEIR library, they have the right to do what they want and they probably know better than the rest of us what's better for homebrew community. They say that modifying IOS has always been dangerous and clearly lead to potential issues with a lot of things, issuing unexplicable bugs in applications as we all have noticed at least once (black screen issues when loading homebrew anyone ?). They also say that this is now unnecessary so they prefer removing applications that modify IOS from their website to avoid any confusion; is that so hard to understand ?

Black screen on homebrew? I had this issue too. It had 2 reasons: A bug in HBC which was fixed in 1.0.7, and bad libogc IOS Reload code. With HBC 1.0.6 OR with a bad libogc, i get lots of black screens on various apps. And in case of the bad libogc, also crashes after an IOS Reload within the program. A black screen caused by using a patched IOS is something i haven't seen yet. [there's IOS249 while IOS249 is stubbed, but i don't count that: 1. My main app detects stubbed IOS and doesn't load them, and 2. it's fixed by just installing a cIOS]

QUOTE(tueidj @ Aug 16 2010, 12:21 PM) I think I understand the subject pretty well, seeing as I wrote Riivolution which uses its own exploit to disable AHBPROT and load a customized IOS.

If you knew what you were talking about, you'd know how easy it is and wouldn't be complaining about it.

To me the main problem is that no open source project has this "patch IOS in memory" code yet*. If there would be one, all apps that require patched IOS could be updated for this within 5 min. Without such example code, one needs to reinvent the wheel. Also removing apps that require patched IOS from WiiBrew is ok, but why this hurry? Why not wait until some apps are updated before starting the cleaning?

*If there is, don't shout, i just haven't seen any yet

 

[DunkrWunkah]

If only SD cards could run faster.... Looks like I'll be getting a flash drive.

 

[sorgelig]

I think I understand the subject pretty well, seeing as I wrote Riivolution which uses its own exploit to disable AHBPROT and load a customized IOS.
If you knew what you were talking about, you'd know how easy it is and wouldn't be complaining about it.

hmm.. 'looks like you didn't understand or didn't read whole my message.
I didn't complain about complexity at all. I just wanted to tell this move of TT is just a noise and big soap bubble. How they can prevent brick by opening full HW access? There was small hole controlled by IOS, now it's a huge hole without any control. It's like Nintendo's release note for every SM where they tell how homebrew is evil and destructive. TT is laughing on these claims and doing the same?
Why don't give choice to developers and users? Especially, patched IOS is already common and results more or less predicted. Wiibrew becoming more and more HBC-centric. It's very vulnerable way of evolution. Kill that center and whole enemy (homebrew) is dead.

There is good old joke: "What is Internet Explorer? It's application to download Firefox."
I can re-phrase: "What is HBC? It's application to install System Menu-like launcher."
I'm not a fan of HBC. I don't like its philosophy, how it organise applications, button mapping. And i don't need to bother TT because i have choise to choose or develop my own replacement. By help of priiloader/bootmii/sneek i can hide HBC completely and don't use it very long time. Will i have this choice later - i'm not sure already.

 

[sorgelig]

Jacobeian,
let's finish our discussion (i mean between you and me). I have no interest to talk with TT-addict person.
No need to repeat their phrases. I know it.
I can discuss about technical things by technical language. People has to understand subject, not repeat other words without knowledge. You read TT announces very careful as i see, but alas you don't understend consequenses.
You will tell about AHBPROT flag when Nintendo will fix it. It's easy to let such access to only specified titles like BC/MIOS and disable it on other titles besides they request it or not. Because in retail consoles, this feature required solely for Gamecube mode. Believe me it's easy to fix. Much easier than fighting with many different patched and vulnerable IOSes. Nintendo just didn't bother because nobody used it. You will tell developers later how deep in the ass the are.
So, that's last thing i wanted to tell you.
bye.

 

[WiiPower]

Direct hardware access can be more dangerous than patched IOS, but the other way around is also true. If you have a patched IOS with full nand write access, you can very easily overwrite a system menu file with crap.

All in all i would say with direct hardware access instead of patched IOS, nothing is going to be less dangous, and some stuff is getting more dangerous, but that's only because it doesn't require patched IOS and is instantly able to do everything after just installing HBC.

 

[s3phir0th115]

To me the main problem is that no open source project has this "patch IOS in memory" code yet*. If there would be one, all apps that require patched IOS could be updated for this within 5 min. Without such example code, one needs to reinvent the wheel. Also removing apps that require patched IOS from WiiBrew is ok, but why this hurry? Why not wait until some apps are updated before starting the cleaning?

*If there is, don't shout, i just haven't seen any yet

That's what concerns me too. Not enough time was given to developers to update their programs before this move. (At least, in the time the homebrew channel introduced this feature and all.)

Also, if code examples are lacking, that really should be documented more. The more well known this stuff is, the quicker and easier it'll be to upgrade programs that are dependant on the custom IOS.

QUOTE(WiiPower @ Aug 16 2010, 07:04 AM) Direct hardware access can be more dangerous than patched IOS, but the other way around is also true. If you have a patched IOS with full nand write access, you can very easily overwrite a system menu file with crap.

All in all i would say with direct hardware access instead of patched IOS, nothing is going to be less dangous, and some stuff is getting more dangerous, but that's only because it doesn't require patched IOS and is instantly able to do everything after just installing HBC.

The way I see it, as a user at least, is that they are 2 different approaches to the same problem.

Sort of like with Windows tcpip.sys patching for instance. There are programs to patch it in memory, and ones to patch the file itself.

I guess one could say that if a patch went wrong, this new method would be safer since it's done in memory, but I have yet to see anything dangerous caused purely by the custom IOS's method of patching. Wouldn't that be more dependant on the program running on the platform?

Edit:
And also, the custom IOS's typically use slots that aren't normally taken up by anything Nintendo. (Except stubs of course.) So a failure in patching/installing probably wouldn't cause a brick. Darkcorp changes this of course, but by default, it's different.

The way I see it TT is sort of acting like in the example above, the custom IOS is like patching the tcpip.sys. But really it's more comprable to making a whole new copy of the tcpip.sys elsewhere and making applications use that instead.

 

[ChokeD]

I know why they picked 58, because of the usb2 better usb for everything but is 58 vulnerable ?? how does hbc use it if it's not ?? it's pure nintendo ios right ?? where can I read up on how the preocess is working or is this the secret of the devs or what ?? I'm curious. Pleas advise.

 

[sorgelig]

I know why they picked 58, because of the usb2 better usb for everything but is 58 vulnerable ?? how does hbc use it if it's not ?? it's pure nintendo ios right ?? where can I read up on how the preocess is working or is this the secret of the devs or what ?? I'm curious. Pleas advise.

As TT posted some time ago, there is AHBPROT flag in TMD used by HBC. If it's set for title, then this title will have direct hardware access being loaded. Just like Gamecube mode. So, it doesn't matter if IOS vulnerable or not. If you have direct HW access, you will get what you want.

 

[ChokeD]

Thanks for the response, that explains a little, I think I need to go read more about this AHBPROT flag before I go asking more questions.

 

[Jacobeian]

Jacobeian,
let's finish our discussion (i mean between you and me). I have no interest to talk with TT-addict person.
No need to repeat their phrases. I know it.
I can discuss about technical things by technical language. People has to understand subject, not repeat other words without knowledge. You read TT announces very careful as i see, but alas you don't understend consequenses.
You will tell about AHBPROT flag when Nintendo will fix it. It's easy to let such access to only specified titles like BC/MIOS and disable it on other titles besides they request it or not. Because in retail consoles, this feature required solely for Gamecube mode. Believe me it's easy to fix. Much easier than fighting with many different patched and vulnerable IOSes. Nintendo just didn't bother because nobody used it. You will tell developers later how deep in the ass the are.
So, that's last thing i wanted to tell you.
bye.

I understand things perfectly, thanks for worrying

You, on the opposite, have stated multiple things that were just plain wrong or misinformed speculation.
Not my fault if you don't (or don't want) to understand that different people can have different views about what hacking means for them and in contrary, feel the need to classify people as being -addict or anti-, I know it's way more easy to see the world like this though ...

You are clearly disappointed because apps that used cIOS have been kicked out of wiibrew, I answered you that it doesn't matter anyway, you are still free to use them if you want or wait for safer apps to come, that won't require you to install anything.

Lastly, Nintendo has countlessly updated their IOS to fix the bugs that were discovered, AHBPROT will not be the first neither the last to be patched but as long as it exists, patching IOS is clearly not useful anymore. What should they do ? Don't use any discovered feature because Nintendo could patch it ? that would be stupid...

 

[Skizzo]

damn, what with this obsession to know what TT secretly have in their mind.I bet a few people would of liked to have known what secrets tueidj had in his mind before they used his Superdump app, which if it found files tueidj didn't approve of, it went on to sabotage their Wiis.
QUOTEThey always said they didn't care what people would do with their apps, I think they are perfectly aware this is used for piracy and guess what ? They probably don't care.

I'd love to hear how you reconcile this logic with the fact that they tried to 'reach out' to Nintendo to help them secure their system against piracy.

 

[Jacobeian]

damn, what with this obsession to know what TT secretly have in their mind.I bet a few people would of liked to have known what secrets tueidj had in his mind before they used his Superdump app, which if it found files tueidj didn't approve of, it went on to sabotage their Wiis.


I can't speak fo him, I'm not in his mind and he's not part of TT as far as I know; But I have yet to see HBC features that deliberately blocked piracy (loaders, CIOS installer, WAD installer) ... Sure they are against piracy, sure Marcan said multiple time here he thinks people who pirate and brick their wii are stupid, which I agree can make some people feel bad. Guess what, i'm pirating, never bricked any wii but I don't care if other people think that what i am doing is right or wrong. As I said, everybody makes his own choice, this is still true for TT if they don't want to support something because they think it's not worth it.

QUOTE

I'd love to hear how you reconcile this logic with the fact that they tried to 'reach out' to Nintendo to help them secure their system against piracy.

Personally, I always thought this was a bad move, and also a very naive one to think Nintendo would even care about it. Well, they are clearly against piracy for reasons that belong to them and their morale , maybe they thought it would give them a chance to fix the bug and make them looking better at homebrew, I dunno. But my logic still remains, there is absolutely NOTHING in the apps/libs they are releasing that deliberately blocks the use of piracy tools.

 

[megazig]

I think I understand the subject pretty well, seeing as I wrote Riivolution which uses its own exploit to disable AHBPROT and load a customized IOS.
If you knew what you were talking about, you'd know how easy it is and wouldn't be complaining about it.

hmm.. 'looks like you didn't understand or didn't read whole my message.
I didn't complain about complexity at all. I just wanted to tell this move of TT is just a noise and big soap bubble. How they can prevent brick by opening full HW access? There was small hole controlled by IOS, now it's a huge hole without any control. It's like Nintendo's release note for every SM where they tell how homebrew is evil and destructive. TT is laughing on these claims and doing the same?
Why don't give choice to developers and users? Especially, patched IOS is already common and results more or less predicted. Wiibrew becoming more and more HBC-centric. It's very vulnerable way of evolution. Kill that center and whole enemy (homebrew) is dead.

There is good old joke: "What is Internet Explorer? It's application to download Firefox."
I can re-phrase: "What is HBC? It's application to install System Menu-like launcher."
I'm not a fan of HBC. I don't like its philosophy, how it organise applications, button mapping. And i don't need to bother TT because i have choise to choose or develop my own replacement. By help of priiloader/bootmii/sneek i can hide HBC completely and don't use it very long time. Will i have this choice later - i'm not sure already.

of course you have the choice.

step 1. create your own exploits.
step 2. create your own loader.



also, AHBPROT has been used for DVDX for ages. why hasn't Nintendo fixed it yet, as your paranoia has you spouting now?

 

[marcan_troll]

Nintendo uses AHBPROT during manufacturing, testing, and refurbishing. It's not a bug, it's a feature.

 

[ChokeD]

Why doesn't HBC seem to work with SNEEK ??