Hacking system update 9/7/2010

  • Thread starter Thread starter mauifrog
  • Start date Start date
  • Views Views 50,731
  • Replies Replies 204
xzxero said:
mike333 said:
Hakoda said:
But wouldn't you just be able to downgrade the IOS back to when it had the bug? What about presence the Korean IOS's is stopping TBR?
Disabled downgrade ability in updated Korean IOSes?
you mean disabled "trucha" in the korean IOS's
No. We have two things:
- trucha bug - ability to install modified IOS thanks to one byte signature verification (8bit cryptography)
- downgrade - ability to install lower version of IOS if already higher is present on that slot (both are unmodified)
In 4.2 days it was possible to perform non hack/clean downgrade of IOS15 and use TB in that ios to install for example 236 or anything You wanted.
 
xzxero said:
mike333 said:
Hakoda said:
But wouldn't you just be able to downgrade the IOS back to when it had the bug? What about presence the Korean IOS's is stopping TBR?
Disabled downgrade ability in updated Korean IOSes?
you mean disabled "es_titlefinish" in the korean IOS's
Yes, ES_AddTitleFinish I was thinking about.
 
I updated to 4.3E everything worked just fine!!!
A friend had a problem......... if i format his system memory he will lose all of his softmodes. Right?
also his system will return to the system menu version that he bought it.... correct????

Please someone answer both question
 
1.) only as a last result should this be done and your game saves will be deleted, channels will be deleted except for system channels(Mii, Weather, News, etc.).

2.) no, if formatted the system menu will stay the same as it is presently.
 
mike333 said:
Slowking said:
But luckily we now have the AHBPROT feature.
http://bugs.hackmii.com/index.php?do=detai...6&project=6
It's like week since bug report was filled.
Damn You PS3. Now anyone who knows about PPC and likes new challenges is sitting on a new PS3 exploit.
This means whole HBC team is gone from wii front.
frown.gif
http://www.dacotaco.com/about-the-priiloader-0-5-removal

that contains more info about the bug
 
Hakoda said:
Slowking said:
Nintendo forgot to include korean IOSs in U/J/E updates. So you could install an old korean IOS and use TBR with it.
Since they now includet the koean IOSs in the updates that's not possible anymore.
But luckily we now have the AHBPROT feature.
But wouldn't you just be able to downgrade the IOS back to when it had the bug? What about presence the Korean IOS's is stopping TBR?
I know people have answered this, but IMO, its not in language easy to understand for less experienced people. Basically, here's a summary:

IOS36 v3351 and below all had a bug, which meant that they could downgrade an IOS without needing the trucha bug i.e. in a completely unpatched form, they could still downgrade IOS.

(This worked because you can reinstall the same revision of an IOS that is installed without any exploit. So TBR would begin to install the latest revision of IOS15, which would always work. The signature of IOS15 was checked, and because it was a legit IOS, it passed. It's contents were then moved to a folder called "/tmp" on the NAND. Here, the contents can be modified, and because the signature check was already completed, the modified contents would be installed. So TBR modified the TMD of IOS15 so that the revision was 0. Then, it would install IOS15 v257, and because the currently installed IOS15 was now "v0", it would install fine. IOS15 v257 had trucha bug officially, and worked on all Wiis, hence it was the IOS that was downgraded. This downgraded IOS15 could then patch IOS36)

In IOS36 v3607, this bug was fixed (this was the revision of IOS36 in the 4.3 update). However, US, EU and Jap Wiis never had the Korean-exclusive IOS added to them. And the oldest revisions of these Korean IOS also had the same bug that IOS36 v3351 and below had, meaning Korean IOS e.g. IOS41v2320 could downgrade IOS15, the way IOS36 could prior to this update. The IOS was also reasonably recent, so worked on all Wiis, including "LU64+" wiis. Because IOS41 was an official IOS, it could be installed without needing any exploit.

On Sept 7, Nintendo pushed the latest revisions of ALL IOS, including the Korean IOS, to all regions. This meant that a fully updated Wii could no longer use the exploit used before to downgrade IOS, because ALL IOS had the bug fixed.

I hope that fully answers your question. Don't worry if you don't understand the big second paragraph in brackets, the rest is the really important stuff.
 
snikerz said:
neotank19 said:
I wonder if nintendo used korea as a testing ground to stop wii hacking before updating j/u/e wiis.
No. They just forgot that Korean IOS existed.
More they forgot that any revision of those IOS could be installed on any J/U/E Wii without any exploit required. They had fixed the bug in the latest revisions of those IOS as well, so clearly didn't forget about those IOS.
 
Still can't get the new Shop Channel to install.
I have successfully installed IOS56 v5662, downloaded Shopping Channel v20 using NUSD, and installed it. But, my Shop Channel version still shows v19. What the heck am I doing wrong??


Somehow, my Mac was screwing with the Shop Channel WAD file. I copied everything to my SD Card using my PC, and everything installed correctly!

yay.gif
 
If I wanted to stay on 4.1E is it safe to install all the other IOS (except the stub IOS60 ofcourse). Do I need to install IOS80 in that case? To download IOS48 from NUSD I just manually type 0000000100000030 v4124 up the top right? Also, is boot2v4 for all wii's or just for wii's that are bootmii boot2 capable? Cheers.
 
SifJar said:
IOS36 v3351 and below all had a bug, which meant that they could downgrade an IOS without needing the trucha bug.

This worked because you can reinstall the same revision of an IOS that is installed without any exploit.

In IOS36 v3607, this bug was fixed

On Sept 7, Nintendo pushed the latest revisions of ALL IOS, including the Korean IOS, to all regions. This meant that a fully updated Wii could no longer use the exploit used before to downgrade IOS, because ALL IOS had the bug fixed.
It still a point I can't understand well !
mellow.gif
(not a noob)

Now, there is the AHBPROT so even if the "downgrade bug" is fixed we don't need it anymore 'cause we don't need to downgrade IOS15 anymore.
When we patch IOS36, there is the "version check patch" which allow the patched IOS to downgrade a high revision IOS. (for exemple, this patch allow us to install cIOS in a stubbed slot without deleting the stub before)

So if TBR use IOS36 v3608 instead of v3351 it will be exactly the same, isn't it ?
unsure.gif


I tested something, I changed the sources from TBR to install IOS36 in slot 236 with revision 65535 (based on IOS36 v3608) then I decide to use the real TBR to replace this IOS236 v65535 by IOS236 v1 and during the install it tell me error -2011 !
The question is, Why can't I downgrade ?
Normally, the AHBPROT + IOS58 can downgrade anything so why this error ?

or Maybe it use the IOS I want install (IOS36 v3608) to try to downgrade the IOS236 v65535, I don't know but :
The IOS is patched with "version check" before installation but the patch is not yet active if the IOS is not installed ?

Can you explain me more please SifJar !
wink.gif
 
NutNut said:
It still a point I can't understand well !
mellow.gif
(not a noob)

Now, there is the AHBPROT so even if the "downgrade bug" is fixed we don't need it anymore 'cause we don't need to downgrade IOS15 anymore.
When we patch IOS36, there is the "version check patch" which allow the patched IOS to downgrade a high revision IOS. (for exemple, this patch allow us to install cIOS in a stubbed slot without deleting the stub before)

So if TBR use IOS36 v3608 instead of v3351 it will be exactly the same, isn't it ?
unsure.gif


I tested something, I changed the sources from TBR to install IOS36 in slot 236 with revision 65535 (based on IOS36 v3608) then I decide to use the real TBR to replace this IOS236 v65535 by IOS236 v1 and during the install it tell me error -2011 !
The question is, Why can't I downgrade ?
Normally, the AHBPROT + IOS58 can downgrade anything so why this error ?

or Maybe it use the IOS I want install (IOS36 v3608) to try to downgrade the IOS236 v65535, I don't know but :
The IOS is patched with "version check" before installation but the patch is not yet active if the IOS is not installed ?

Can you explain me more please SifJar !
wink.gif


The application has to be programmed specifically to make use of IOS58 and AHBPROT. All AHBPROT does is allow full access to hardware. Its up to the app to use that access to patch the currently running IOS e.g. to allow it to downgrade. Simply booting an app with the HW_AHBPORT flags set won't make the app behave any differently to usual unless it is programmed specifically to use the HW_AHBPROT flags. I hope you understand, if not, I'll try to explain more clearly
smile.gif



QUOTE(Cuber @ Sep 12 2010, 12:25 PM) Is there a new shop updater yet? >.>; Will there be... or am I going to have to use NUS..

dop-Mii works, or you can do it manually with NUSD and a WAD installer.
 
SifJar said:
The application has to be programmed specifically to make use of IOS58 and AHBPROT. All AHBPROT does is allow full access to hardware. Its up to the app to use that access to patch the currently running IOS e.g. to allow it to downgrade. Simply booting an app with the HW_AHBPORT flags set won't make the app behave any differently to usual unless it is programmed specifically to use the HW_AHBPROT flags. I hope you understand, if not, I'll try to explain more clearly
smile.gif

I've heard different opinion:
qwertymodo said:
QUOTE(mike333 @ Sep 2 2010, 05:45 AM) New method is covered by libogc or apps uses their own implementation?
I smell bricks coming.
The USB2.0 code via IOS58 is in the current svn libogc. However, it hasn't made it to a stable release yet. The AHBPROT code is basically just checking if the flag is set and then accessing the hardware as usual, so no problems there. It's really no different than DVDX besides the method of checking for it.
Confusion.
 
mike333 said:
SifJar said:
The application has to be programmed specifically to make use of IOS58 and AHBPROT. All AHBPROT does is allow full access to hardware. Its up to the app to use that access to patch the currently running IOS e.g. to allow it to downgrade. Simply booting an app with the HW_AHBPORT flags set won't make the app behave any differently to usual unless it is programmed specifically to use the HW_AHBPROT flags. I hope you understand, if not, I'll try to explain more clearly
smile.gif

I've heard different opinion:
qwertymodo said:
QUOTE(mike333 @ Sep 2 2010, 05:45 AM) New method is covered by libogc or apps uses their own implementation?
I smell bricks coming.
The USB2.0 code via IOS58 is in the current svn libogc. However, it hasn't made it to a stable release yet. The AHBPROT code is basically just checking if the flag is set and then accessing the hardware as usual, so no problems there. It's really no different than DVDX besides the method of checking for it.
Confusion.

I don't see what is different there. As I said, apps need to be rebuilt with latest libOGC to make use of HW_AHBPROT. For DVD access, all that needs done is recompiling. For stuff like downgrading and patching IOS, you need to implement that yourself.
 

Site & Scene News

Popular threads in this forum