maybe they trusted you, like me...
Trust is a weakness. And we're not above mistakes, as you seem to assume. If you think there's a chance that we might be wrong (and there probably is), go check yourself.
Well It depends how you take it... it's strength and power at the same time... weakness is choosing the wrong party to trust... It's the same with the "dependency"...
And here is part of the code block you depicted...
seg006:81374CB8 cmpwi %r0, 0xF
seg006:81374CBC bne loc_81374CC8
In the above part you see if the register r0 is 0xF then the code gracefully continues on to recovery menu.
Isn't that what reverse engineering is all about? There is a fact right there, there is an extra condition there
leading to recovery menu... well yeah, trust is a weakness as you say it...
seg006:81374C3C loc_81374C3C: # CODE XREF: main+F3Cj
seg006:81374C3C # main+F50j
seg006:81374C3C lwz %r4, 0x130+var_128(%sp)
seg006:81374C40 addi %r3, %r29, 0x4DE
seg006:81374C44 crclr 4*cr1+eq
seg006:81374C48 bl OSReport
seg006:81374C4C
seg006:81374C4C loc_81374C4C: # CODE XREF: main+F64j
seg006:81374C4C addi %r5, %sp, 0x130+var_128
seg006:81374C50 li %r3, 1
seg006:81374C54 li %r4, 0
seg006:81374C58 bl EXIGetIDEx
seg006:81374C5C cmpwi %r3, 0
seg006:81374C60 beq loc_81374C8C
seg006:81374C64 lwz %r0, 0x130+var_128(%sp)
seg006:81374C68 clrrwi %r3, %r0, 8
seg006:81374C6C addis %r0, %r3, -0x702
seg006:81374C70 cmplwi %r0, 0
seg006:81374C74 bne loc_81374C8C
seg006:81374C78 addi %r3, %r29, 0x4EA
seg006:81374C7C crclr 4*cr1+eq
seg006:81374C80 bl OSReport
seg006:81374C84 li %r22, 1
seg006:81374C88 b loc_81374C9C
seg006:81374C8C # ---------------------------------------------------------------------------
seg006:81374C8C
seg006:81374C8C loc_81374C8C: # CODE XREF: main+F8Cj
seg006:81374C8C # main+FA0j
seg006:81374C8C lwz %r4, 0x130+var_128(%sp)
seg006:81374C90 addi %r3, %r29, 0x4F8
seg006:81374C94 crclr 4*cr1+eq
seg006:81374C98 bl OSReport
seg006:81374C9C
seg006:81374C9C loc_81374C9C: # CODE XREF: main+FB4j
seg006:81374C9C cmpwi %r22, 0
seg006:81374CA0 bne loc_81374CC0
seg006:81374CA4 lbz %r0, 0x130+var_7A(%sp)
seg006:81374CA8 extsb. %r0, %r0
seg006:81374CAC bne loc_81374CC8
seg006:81374CB0 lhz %r0, 0x130+var_84(%sp)
seg006:81374CB4 clrlwi %r0, %r0, 28
seg006:81374CB8 cmpwi %r0, 0xF
seg006:81374CBC bne loc_81374CC8 # HERE IT IS, ANOTHER ROUTE FOR THE RECOVERY MENU
seg006:81374CC0
seg006:81374CC0 loc_81374CC0: # CODE XREF: main+FCCj
seg006:81374CC0 bl BS2BootIRD
seg006:81374CC4 b loc_81374CCC
seg006:81374CC8 # ---------------------------------------------------------------------------
seg006:81374CC8
seg006:81374CC8 loc_81374CC8: # CODE XREF: main+FD8j
seg006:81374CC8 # main+FE8j
seg006:81374CC8 bl BS2Entry
seg006:81374CCC
seg006:81374CCC loc_81374CCC: # CODE XREF: main+FF0j
seg006:81374CCC addi %r5, %r29, 0x504
seg006:81374CD0 addi %r3, %r13, -0x7B2C
seg006:81374CD4 li %r4, 0x816
seg006:81374CD8 crclr 4*cr1+eq
seg006:81374CDC bl OSPanic
seg006:81374CE0 addi %r11, %sp, 0x130+arg_0
seg006:81374CE4 bl _restgpr_22
seg006:81374CE8 lwz %r0, 0x130+arg_4(%sp)
seg006:81374CEC mtlr %r0
seg006:81374CF0 addi %sp, %sp, 0x130
seg006:81374CF4 blr
seg006:81374CF4 # End of function main
QUOTE said:
Then you should have thought twice about buying it. And get rid of the software, just in case.
There was no reason for me to think about it twice, savemii was a nice thing as a product and it was what I needed... Still it has value in it, now though very little.... For software, I'll consider stopping usage... for that of course first I need an unbricked wii...
For those 1000pcs on production I suggest you to enhance the design of the fpga chip at least and add more value in it so you can easily sell them off... though I think you should have done that from the start...
QUOTE said:
Any. Unless we've missed something, once you're in recovery mode, there's no way of getting that error code to even run. And I don't think it can happen during initialization, before recovery mode runs. Heck, it doesn't even initialize the normal graphics system. And if I'm wrong, feel free to correct me and help the community. This isn't an exact science.
If you get to the version number screen and inserting a disc causes the error, then we've missed something.
I need to check that thoroughly in my disassembly, I don't remember what functions were called during the init phase, it may well be an issue with my modchip but I doubt it... yet it's now simple to check just patching the BS2IsDiagDisc function... What you are missing in your perceived order of things running in system menu is some functions are async and sets error statuses all around the place...
These error statuses are all checked and acted upon then in various places... For a "system files corrupted" brick, probably this is the case... I am not 100% sure yet it's easy to be proven...
QUOTEWhat? You don't know what you're talking about. I had a TEMPORARY patching system. Really just menuloader with a patch added to make all discs look like autoboot to the system menu. That doesn't help anyone avoid SaveMii, so you're wrong as to the reason why we didn't get around to releasing it. On the other hand, we're working on BootMii which makes SaveMii useless for those who install it, so you're entirely wrong on whether we'd help people avoid the need for SaveMii.
Bootmii is nothing for all those already bricked... right? So you took the same path as me and fiddled with an apploader... If you can patch diag disc check function then you can patch recovery mode check too... right?
QUOTE
Sure, some people have an infectus. And? You expect us to test every possibility? Sorry, that's not an option - there are thousands of ways of bricking a Wii. We tested common configurations, and didn't expect 2.x to have such a different recovery code. Sure, that was a mistake. Big deal. It still works with 2.x. You'd be entitled to some bitching rights if you had a bricked 2.x wii and SaveMii were useless, but sorry, that's not the case because it does work with 2.x.