BMG files
Posted by WiiCrazy
Previously I had examined a bmg file from wiifit channel to make it support other languages. Now while examining the system menu disassembly I needed to find the exact location where my bricked wii throws the error 'The Wii System Memory is damaged. Refer to the Wii Operations Manual\n for help troubleshooting.', returned back to the bmg file examination. Here is a rough description for the bmg file included in the system menu disassembly, it contains only 4 strings one of them empty.... You can use the info on other bmg files with a little more examination...
0000: 4D 45 53 47 MESG
0004: 62 6D 67 31 bmg1 (the last byte may be significant)
0008: 00 00 03 60 size of the message file
000C: 00 00 00 02 ??
0010: 02 00 00 00 ??
0014: 00 00 00 Seems to be the padding for 8 words
0018: 00 00 00 00 "
001C: 00 00 00 00 "
0020: 49 4E 46 31 INF1 (the last byte may be significant)
0024: 00 00 00 20 Size of this header?
0028: 00 04 00 04 Count of the messages?
002C: 00 00 00 00 Padding?
0030: 00 00 00 02 Offset of 1st message (2 words after start of the DAT section)
0034: 00 00 01 46 Offset of 2nd message
0038: 00 00 02 06 Offset of 3rd message
003C: 00 00 02 D0 ... so on
0040: 44 41 54 31 DAT1 (the last byte may be significant)
0044: 00 00 03 20
0048: NULL
004A: N'An error has occured. Press\nthe Eject Button and remove the disc, then turn the Wii console off and refer to the\n Wii Operations Manual for\help troubleshooting.'NULL
018E: N'The Wii System Memory is damaged. Refer to the Wii Operations Manual\n for help troubleshooting.'NULL
0318: N'This channel can't be used.'NULL
0350-0360 : Zero Padding
Add 0x48 (start of the first string) to the specified offset to find the location of the string relative to the file.
NULL's are two zero bytes
Edited 1 time(s). Last edit at 10/24/2008 12:33AM by WiiCrazy.
0000: 4D 45 53 47 MESG
0004: 62 6D 67 31 bmg1 (the last byte may be significant)
0008: 00 00 03 60 size of the message file
000C: 00 00 00 02 ??
0010: 02 00 00 00 ??
0014: 00 00 00 Seems to be the padding for 8 words
0018: 00 00 00 00 "
001C: 00 00 00 00 "
0020: 49 4E 46 31 INF1 (the last byte may be significant)
0024: 00 00 00 20 Size of this header?
0028: 00 04 00 04 Count of the messages?
002C: 00 00 00 00 Padding?
0030: 00 00 00 02 Offset of 1st message (2 words after start of the DAT section)
0034: 00 00 01 46 Offset of 2nd message
0038: 00 00 02 06 Offset of 3rd message
003C: 00 00 02 D0 ... so on
0040: 44 41 54 31 DAT1 (the last byte may be significant)
0044: 00 00 03 20
0048: NULL
004A: N'An error has occured. Press\nthe Eject Button and remove the disc, then turn the Wii console off and refer to the\n Wii Operations Manual for\help troubleshooting.'NULL
018E: N'The Wii System Memory is damaged. Refer to the Wii Operations Manual\n for help troubleshooting.'NULL
0318: N'This channel can't be used.'NULL
0350-0360 : Zero Padding
Add 0x48 (start of the first string) to the specified offset to find the location of the string relative to the file.
NULL's are two zero bytes
Edited 1 time(s). Last edit at 10/24/2008 12:33AM by WiiCrazy.
|
Re: BMG files October 24, 2008 08:37PM | Admin Registered: 14 years ago Posts: 271 |
Hm, really? Which file are you looking at? By my calculation, message/eng/ipl_common.bmg contains almost 400 strings.
Note that the string you are looking for is string 8. Messages are loaded using ipl::message::Message::getMessage(int messageno), but this usually happens indirectly -- there are many helper functions that e.g. create a dialog box and take the messageno as a parameter (so it's not simply enough to look for all xrefs to that function).
String 0 (offset=2): Disc Channel String 1 (offset=1c): Wii Menu String 2 (offset=2e): Start String 3 (offset=3a): String 4 (offset=3c): Please insert a disc. String 5 (offset=68): String 6 (offset=6a): Unable to read the disc. Check the Wii Operations Manual for help troubleshooting. String 7 (offset=112): An error has occurred. Press the Eject Button and remove the disc, then turn the Wii console off and refer to the Wii Operations Manual for help troubleshooting. String 8 (offset=256): The Wii System Memory is damaged. Refer to the Wii Operations Manual for help troubleshooting. String 9 (offset=316): Please connect a Nunchuk to the Wii Remote. String a (offset=36e): Please connect a Classic Controller to the Wii Remote. String b (offset=3dc): Wii Message Board data was corrupted. The data has been repaired, but some messages or addresses may have been lost. String c (offset=4c6): The system files are corrupted. Please refer to the Wii Operations Manual for help troubleshooting.
Note that the string you are looking for is string 8. Messages are loaded using ipl::message::Message::getMessage(int messageno), but this usually happens indirectly -- there are many helper functions that e.g. create a dialog box and take the messageno as a parameter (so it's not simply enough to look for all xrefs to that function).
|
Re: BMG files October 24, 2008 09:34PM | Registered: 14 years ago Posts: 93 |
The one I grabbed from the dol of the system assembly has just 4 strings, it's located in _f_data:81611260 in my 3.2 ntsc disassembly. It's referenced by the error handling routines
here is the code that references it, Yesterday I just tried to decode the bmg file hence I didn't have time to look at the code thoroughly... My understanding, for these critical errors it just uses the above bmg file included in the dol... If it's not a fatal error than it uses the one outside the memory...
here is the code that references it, Yesterday I just tried to decode the bmg file hence I didn't have time to look at the code thoroughly... My understanding, for these critical errors it just uses the above bmg file included in the dol... If it's not a fatal error than it uses the one outside the memory...
... snipped... english is the last option in the available languages in the bmg file in the dol.... seg006:81351FF8 loc_81351FF8: # CODE XREF: ipl::ErrorHandler::check((void))+30j seg006:81351FF8 # DATA XREF: _f_data:8160AE60o seg006:81351FF8 lis %r4, ipl_error_eng_bmg@h # "MESGbmg1" seg006:81351FFC addi %r4, %r4, ipl_error_eng_bmg@l # "MESGbmg1" seg006:81352000 seg006:81352000 loc_81352000: # CODE XREF: ipl::ErrorHandler::check((void))+54j seg006:81352000 # ipl::ErrorHandler::check((void))+60j ... seg006:81352000 addi %r3, %sp, 0x20+var_18 seg006:81352004 bl setResource__Q33ipl7message7MessageFPUc # ipl::message::Message::setResource((uchar *)) seg006:81352008 lwz %r3, 0x20(%r31) seg006:8135200C lis %r4, ((aTextbox_00_0+0x10000)@h) # "TextBox_00" seg006:81352010 addi %r4, %r4, -0x51B1 # aTextbox_00_0 seg006:81352014 li %r5, 1 seg006:81352018 lwz %r3, 0x14(%r3) seg006:8135201C lwz %r12, 0(%r3) seg006:81352020 lwz %r12, 0x3C(%r12) seg006:81352024 mtctr %r12 seg006:81352028 bctrl seg006:8135202C lwz %r4, 8(%r31) seg006:81352030 mr %r31, %r3 seg006:81352034 addi %r3, %sp, 0x20+var_18 seg006:81352038 bl getMessage__Q33ipl7message7MessageCFUl # ipl::message::Message::getMessage(const(ulong)) seg006:8135203C lwz %r12, 0(%r31) seg006:81352040 mr %r4, %r3 seg006:81352044 mr %r3, %r31 seg006:81352048 li %r5, 0 seg006:8135204C lwz %r12, 0x6C(%r12) seg006:81352050 mtctr %r12 seg006:81352054 bctrl seg006:81352058 lis %r3, -0x7EF7 # smArg__Q23ipl6System seg006:8135205C addi %r3, %r3, -0x6FF8 # smArg__Q23ipl6System seg006:81352060 lwz %r3, 0xC4(%r3) seg006:81352064 lwz %r12, 0(%r3) seg006:81352068 lwz %r12, 0x14(%r12) seg006:8135206C mtctr %r12 seg006:81352070 bctrl seg006:81352074 bl err_run__Q23ipl6SystemFv # ipl::System::err_run((void)) seg006:81352078 addi %r3, %sp, 0x20+var_18 seg006:8135207C li %r4, -1 seg006:81352080 bl __dt__Q33ipl7message7MessageFv # ipl::message::Message::~Message((void)) seg006:81352084
|
Re: BMG files October 24, 2008 10:46PM | Registered: 14 years ago Posts: 93 |
It seems error statuses are filled into a memory address (maybe a static variable in the assembly) by an asynchronous process and in the main program cycle it's controlled like
lwz %r3, ((dword_810890A0+0x6FF8)@l)(%r29)
bl check__Q23ipl12ErrorHandlerFv # ipl::ErrorHandler::check((void))
mainly there are 3 run states that this routine is called , ipl:System::run, ipl:System::backup_run, ipl:System::warning_run
so in my case probably it's issued from the warning_run state... there are lots of references to dword_810890A0 mainly after checks from es calls my estimation is in my case it's set in below function since my brick was because of a bad 0.app header. but of course just a guess...
_f_text:81338D60 loadMetaHeaderAsync__Q33ipl7channel7ManagerFii:
What do you think? Since mine is an handled exception in the system and those are set async, will savemii boot me into the recovery menu?
lwz %r3, ((dword_810890A0+0x6FF8)@l)(%r29)
bl check__Q23ipl12ErrorHandlerFv # ipl::ErrorHandler::check((void))
mainly there are 3 run states that this routine is called , ipl:System::run, ipl:System::backup_run, ipl:System::warning_run
so in my case probably it's issued from the warning_run state... there are lots of references to dword_810890A0 mainly after checks from es calls my estimation is in my case it's set in below function since my brick was because of a bad 0.app header. but of course just a guess...
_f_text:81338D60 loadMetaHeaderAsync__Q33ipl7channel7ManagerFii:
What do you think? Since mine is an handled exception in the system and those are set async, will savemii boot me into the recovery menu?
Sorry, only registered users may post in this forum.