Hacking Trucha Bug Restorer release

[Kikoshi]

BTW, once HackMii Installer is working on 4.3, there's apparently a reasonably simple way you can install fake signed content (e.g. patched IOS) on any Wii, regardless of the installed IOS. The Wii just needs DVDx, which when HackMii Installer gets updated to work (as I'm sure it will soon), all Wiis can have.

You run DVDx, which gives you access to ahbprot, allowing you to disable MEM2 protection and patch the sig checking function of ES, which then lets you install fakesigned content e.g. a patched IOS. sven_p mentioned this on #wiidev last night, WiiPower, perhaps you could implement this in a new version of TBR (I'm sure you'll be able to work out how to do all that stuff, I haven't a clue, but apparently its not too hard, and you seem pretty good with that sort of thing

)

Once it's working, you can just install BootMii as IOS and install a cIOS using cBoot2

So this way im able to Access the Boot2 with BootMii when i wasn't able to before? O_ O

No, that won't let you install BootMii/boot2 if you haven't been able to before. cboot2 is a program executed by BootMii, not something that's written to your NAND.

*cough Bootmii/IOS cough*

So then i can?..

 

[Supercool330]

No, but you will be able to start cBoot2 with Bootmii/IOS. cBoot2 is a program just like any other homebrew, except it is run on the arm processor. If you cant install Bootmii Boot2, you will never be able to (unless rsa is broken which won't happen in the near future, and if it does you should be more worried about your bank accounts).

 

[Kikoshi]

No, but you will be able to start cBoot2 with Bootmii/IOS. cBoot2 is a program just like any other homebrew, except it is run on the arm processor. If you cant install Bootmii Boot2, you will never be able to (unless rsa is broken which won't happen in the near future, and if it does you should be more worried about your bank accounts).

Thanks for making it clear, is just that i want to Pass from 3.2 to the new 4.2 or was it 4.3 for the HDSC support and the whole VC games on the SD card too without loosing my homebrew capabilities, so i didnt want to brick the wii :/

 

[Supercool330]

Just use Pimp My Wii or DOP-Mii. Pimp My Wii should update you to 4.1 (the last SysMenu to add any functionality), and install updated versions of ever IOS. You can download it here http://www.mediafire.com/?eztnvizmiaz.

 

[FenrirWolf]

No, that won't let you install BootMii/boot2 if you haven't been able to before. cboot2 is a program executed by BootMii, not something that's written to your NAND.

*cough Bootmii/IOS cough*

BootMii/IOS doesn't have a thing to do with writing to boot2

 

[XFlak]

I think he was just implying that cboot2 works if u can access bootmii/IOS, which is true

 

[BBking83]

Yeah, but it was in relation to this Q:

Once it's working, you can just install BootMii as IOS and install a cIOS using cBoot2

So this way im able to Access the Boot2 with BootMii when i wasn't able to before? O_ O

In which he replied:

No, that won't let you install BootMii/boot2 if you haven't been able to before. cboot2 is a program executed by BootMii, not something that's written to your NAND.

Which is true. And then this was said:

QUOTE(calthephenom @ Jun 24 2010, 01:46 PM) *cough Bootmii/IOS cough*

Which has nothing to do with:

QUOTE(Kikoshi @ Jun 24 2010, 02:39 AM)

So this way im able to Access the Boot2 with BootMii when i wasn't able to before? O_ O

Ha! Glad that's cleared up.

 

[PPSainity]

Piggybacking on the other question, this means we should be able to install the patched IOS36 over the IOS249 stub, right? It sounds like it's time to bring my tutorial back to using TBR instead of TBR Mod too... (turns out I already did that when you released 1.11)

Oh, and would this 'better' question have something to do with checking what's previously been happening to space on the nand if it hasn't been reducing when the IOS is rewritten?

I heard that shared contents are not deleted when deleting a title. If that's true, it would explain why i have few free nand space with only 3-4 VC installed.

They are if the title is actually deleted. If something is just installed over the top... probably not.

QUOTE(giantpune @ May 10 2010, 07:43 PM)

there is a ioctl to delete shared contents. i remember reading about about it on wiibrew but i never looked into it. basically you give this ioctl the hash of the content to be removed and it deletes it. IIRC, it checks to make sure that the content is not needed by "important files" which i assume means that it will not delete contents needed by current IOS and the system menu.

i dont know exactly when this ioctl is designed to be called. probably by the system menu itself after the upgrade process? but it is not called by any homebrew ive seen, so we just let the shared contents pile up even if they arent needed.

EDIT>>
http://www.wiibrew.org/wiki//dev/es#.2Fdev.2Fes_IOS_Ioctlv

0x38

I have a few concerns about unaccountable NAND space and the piling up of shared content. I made a separate thread so as to not pollute this one. Please take a look...

"Shared Content" and NAND Space, Will this become a problem?

-[]D

 

[fogbank]

I don't know if anyone else has noticed this, but setting the revision to 0 in /tmp/title.tmd is not the cause of the -1017 error in TBR when running on a 4.3 IOS. This suggests that either something else in the method of creating the /tmp/title.tmd file is breaking the signature, or that IOS is checking something else when ES_AddTitleFinish is called.

It seems like a good candidate for ES_AddTitleFinish to check would be the ownerID of the new file. If we cannot create the new TMD file with the same owner ID as the original then this check would fail.

I've tried getting the attributes of the original and the new TMD with ISFS_GetAttr but it fails (-101) on both files

Just speculating...

 

[WiiPower]

I don't know if anyone else has noticed this, but setting the revision to 0 in /tmp/title.tmd is not the cause of the -1017 error in TBR. This suggests that either something else in the method of creating the /tmp/title.tmd file is breaking the signature, or that IOS is checking something else when ES_AddTitleFinish is called.

It seems like a good candidate for ES_AddTitleFinish to check would be the ownerID of the new file. If we cannot create the new TMD file with the same owner ID as the original then this check would fail.

I've tried getting the attributes of the original and the new TMD with ISFS_GetAttr but it fails (-101) on both files

Just speculating...

You might want to take a look at the fstoolbox code, it's able to pull the attributes and owner ids. So if you just install the tmd, then the finishing already fails? If only if you write the tmd 1:1 back, but with the wrong attributes? I need to know 101% for sure, there are too many people doing stuff about this, and later they come with, "oh i had IOS15v257 already installed", or "i tried with IOS80...from Waninkoko's updater". You always need to tell exactly what you did and what not.

 

[fogbank]

You might want to take a look at the fstoolbox code, it's able to pull the attributes and owner ids. So if you just install the tmd, then the finishing already fails? If only if you write the tmd 1:1 back, but with the wrong attributes? I need to know 101% for sure, there are too many people doing stuff about this, and later they come with, "oh i had IOS15v257 already installed", or "i tried with IOS80...from Waninkoko's updater". You always need to tell exactly what you did and what not.
I started each test with IOS15v1031 installed.
First I removed the following from Downgrade_TMD_Revision function in IOSPatcher.c:CODEtmd[0x1dc] = 0;
tmd[0x1dd] = 0;

I ran the compiled .dol and chose to load IOS61v5661. I chose the option to downgrade IOS15 and got the -1017 error when it attempted to set the revision to 0.

Then I removed all of the ISFS calls from the Downgrade_TMD_Revision function in IOSPatcher.c.
I ran the compiled .dol and chose to load IOS61v5661. I chose the option to downgrade IOS15. The "change revision" did not return an error (of course the revision was not actually changed).

>>So if you just install the tmd, then the finishing already fails?
No it succeeds if you don't delete it and replace it using ISFS to create a new file.

>>if you write the tmd 1:1 back, but with the wrong attributes?
Not tested.

 

[fogbank]

Here is what I tried next in TBR (see my previous post for what I have already tried):

• Change the path assignment to /tmp/title2.tmd
• Remove the ISFS_Delete(tmd_path) block
• Remove the code to change the bytes to 0 in the new TMD
• Remove the ES_AddTitleFinish() call
• Insert IOS_ReloadIOS(254);
• Perform a NAND backup from BootMii (IOS)

Spoiler

CODEs32 Downgrade_TMD_Revision(void *ptmd, u32 tmd_size, void *certs, u32 certs_size)
{
ÂÂÂÂ// The revison of the tmd used as paramter here has to be >= the revision of the installed tmd
ÂÂÂÂs32 ret;

ÂÂÂÂprintf("Setting the revision to 0...\n");

ÂÂÂÂret = ES_AddTitleStart(ptmd, tmd_size, certs, certs_size, NULL, 0);
ÂÂÂÂif (ret < 0)
ÂÂÂÂ{
ÂÂÂÂÂÂÂÂif (ret == -1035)
ÂÂÂÂÂÂÂÂ{
ÂÂÂÂÂÂÂÂÂÂÂÂprintf("Error: ES_AddTitleStart returned %d, maybe you need an updated Downgrader\n", ret);
ÂÂÂÂÂÂÂÂ} else
ÂÂÂÂÂÂÂÂ{
ÂÂÂÂÂÂÂÂÂÂÂÂprintf("Error: ES_AddTitleStart returned %d\n", ret);
ÂÂÂÂÂÂÂÂ}
ÂÂÂÂÂÂÂÂES_AddTitleCancel();
ÂÂÂÂÂÂÂÂreturn ret;
ÂÂÂÂ}

ÂÂÂÂret = ISFS_Initialize();
ÂÂÂÂif (ret < 0)
ÂÂÂÂ{
ÂÂÂÂÂÂÂÂprintf("Error: ISFS_Initialize returned %d\n", ret);
ÂÂÂÂÂÂÂÂES_AddTitleCancel();
ÂÂÂÂÂÂÂÂreturn ret;
ÂÂÂÂ}

ÂÂÂÂs32 file;
ÂÂÂÂchar *tmd_path = "/tmp/title2.tmd";
ÂÂÂÂ
ÂÂÂÂ/*ret = ISFS_Delete(tmd_path);ÂÂÂÂ
ÂÂÂÂif (ret < 0)
ÂÂÂÂ{
ÂÂÂÂÂÂÂÂprintf("Error: ISFS_Delete returned %d\n", ret);
ÂÂÂÂÂÂÂÂES_AddTitleCancel();
ÂÂÂÂÂÂÂÂISFS_Deinitialize();
ÂÂÂÂÂÂÂÂreturn ret;
ÂÂÂÂ}*/
ÂÂÂÂret = ISFS_CreateFile(tmd_path, 0, 3, 3, 3);
ÂÂÂÂif (ret < 0)
ÂÂÂÂ{
ÂÂÂÂÂÂÂÂprintf("Error: ISFS_CreateFile returned %d\n", ret);
ÂÂÂÂÂÂÂÂES_AddTitleCancel();
ÂÂÂÂÂÂÂÂISFS_Deinitialize();
ÂÂÂÂÂÂÂÂreturn ret;
ÂÂÂÂ}

ÂÂÂÂfile = ISFS_Open(tmd_path, ISFS_OPEN_RW);
ÂÂÂÂif (file < 0)
ÂÂÂÂ{
ÂÂÂÂÂÂÂÂprintf("Error: ISFS_Open returned %d\n", file);
ÂÂÂÂÂÂÂÂES_AddTitleCancel();
ÂÂÂÂÂÂÂÂISFS_Deinitialize();
ÂÂÂÂÂÂÂÂreturn file;
ÂÂÂÂ}
ÂÂÂÂ
ÂÂÂÂ/*u8 *tmd = (u8 *)ptmd;
ÂÂÂÂtmd[0x1dc] = 0;
ÂÂÂÂtmd[0x1dd] = 0;*/
ÂÂÂÂ
ÂÂÂÂret = ISFS_Write(file, (u8 *)ptmd, tmd_size);
ÂÂÂÂif (ret < 0)
ÂÂÂÂ{
ÂÂÂÂÂÂÂÂprintf("Error: ISFS_Write returned %d\n", ret);
ÂÂÂÂÂÂÂÂISFS_Close(file);
ÂÂÂÂÂÂÂÂES_AddTitleCancel();
ÂÂÂÂÂÂÂÂISFS_Deinitialize();
ÂÂÂÂÂÂÂÂreturn ret;
ÂÂÂÂ}

ÂÂÂÂISFS_Close(file);
ÂÂÂÂISFS_Deinitialize();

ÂÂÂÂ/*ret = ES_AddTitleFinish();
ÂÂÂÂif (ret < 0)
ÂÂÂÂ{
ÂÂÂÂÂÂÂÂprintf("Error: ES_AddTitleFinish returned %d\n", ret);
ÂÂÂÂÂÂÂÂreturn ret;
ÂÂÂÂ}*/
ÂÂÂÂIOS_ReloadIOS(254);
ÂÂÂÂ
ÂÂÂÂreturn 1;
}

I ended up with /tmp/title.tmd and /tmp/title2.tmd in my extracted NAND dump

I did a file compare with a hex editor and they matched perfectly.

So I restate my question: Is it possible that the new IOS is NOT checking the signature in ES_AddTitleFinish(), but is actually checking some other property of the /tmp/title.tmd file? Or am I missing something obvious?

 

[WiiPower]

Here is what I tried next in TBR (see my previous post for what I have already tried):

• Change the path assignment to /tmp/title2.tmd
• Remove the ISFS_Delete(tmd_path) block
• Remove the code to change the bytes to 0 in the new TMD
• Remove the ES_AddTitleFinish() call
• Insert IOS_ReloadIOS(254);
• Perform a NAND backup from BootMii (IOS)

Spoiler

CODEs32 Downgrade_TMD_Revision(void *ptmd, u32 tmd_size, void *certs, u32 certs_size)
{
ÂÂÂÂ// The revison of the tmd used as paramter here has to be >= the revision of the installed tmd
ÂÂÂÂs32 ret;

ÂÂÂÂprintf("Setting the revision to 0...\n");

ÂÂÂÂret = ES_AddTitleStart(ptmd, tmd_size, certs, certs_size, NULL, 0);
ÂÂÂÂif (ret < 0)
ÂÂÂÂ{
ÂÂÂÂÂÂÂÂif (ret == -1035)
ÂÂÂÂÂÂÂÂ{
ÂÂÂÂÂÂÂÂÂÂÂÂprintf("Error: ES_AddTitleStart returned %d, maybe you need an updated Downgrader\n", ret);
ÂÂÂÂÂÂÂÂ} else
ÂÂÂÂÂÂÂÂ{
ÂÂÂÂÂÂÂÂÂÂÂÂprintf("Error: ES_AddTitleStart returned %d\n", ret);
ÂÂÂÂÂÂÂÂ}
ÂÂÂÂÂÂÂÂES_AddTitleCancel();
ÂÂÂÂÂÂÂÂreturn ret;
ÂÂÂÂ}

ÂÂÂÂret = ISFS_Initialize();
ÂÂÂÂif (ret < 0)
ÂÂÂÂ{
ÂÂÂÂÂÂÂÂprintf("Error: ISFS_Initialize returned %d\n", ret);
ÂÂÂÂÂÂÂÂES_AddTitleCancel();
ÂÂÂÂÂÂÂÂreturn ret;
ÂÂÂÂ}

ÂÂÂÂs32 file;
ÂÂÂÂchar *tmd_path = "/tmp/title2.tmd";
ÂÂÂÂ
ÂÂÂÂ/*ret = ISFS_Delete(tmd_path);ÂÂÂÂ
ÂÂÂÂif (ret < 0)
ÂÂÂÂ{
ÂÂÂÂÂÂÂÂprintf("Error: ISFS_Delete returned %d\n", ret);
ÂÂÂÂÂÂÂÂES_AddTitleCancel();
ÂÂÂÂÂÂÂÂISFS_Deinitialize();
ÂÂÂÂÂÂÂÂreturn ret;
ÂÂÂÂ}*/
ÂÂÂÂret = ISFS_CreateFile(tmd_path, 0, 3, 3, 3);
ÂÂÂÂif (ret < 0)
ÂÂÂÂ{
ÂÂÂÂÂÂÂÂprintf("Error: ISFS_CreateFile returned %d\n", ret);
ÂÂÂÂÂÂÂÂES_AddTitleCancel();
ÂÂÂÂÂÂÂÂISFS_Deinitialize();
ÂÂÂÂÂÂÂÂreturn ret;
ÂÂÂÂ}

ÂÂÂÂfile = ISFS_Open(tmd_path, ISFS_OPEN_RW);
ÂÂÂÂif (file < 0)
ÂÂÂÂ{
ÂÂÂÂÂÂÂÂprintf("Error: ISFS_Open returned %d\n", file);
ÂÂÂÂÂÂÂÂES_AddTitleCancel();
ÂÂÂÂÂÂÂÂISFS_Deinitialize();
ÂÂÂÂÂÂÂÂreturn file;
ÂÂÂÂ}
ÂÂÂÂ
ÂÂÂÂ/*u8 *tmd = (u8 *)ptmd;
ÂÂÂÂtmd[0x1dc] = 0;
ÂÂÂÂtmd[0x1dd] = 0;*/
ÂÂÂÂ
ÂÂÂÂret = ISFS_Write(file, (u8 *)ptmd, tmd_size);
ÂÂÂÂif (ret < 0)
ÂÂÂÂ{
ÂÂÂÂÂÂÂÂprintf("Error: ISFS_Write returned %d\n", ret);
ÂÂÂÂÂÂÂÂISFS_Close(file);
ÂÂÂÂÂÂÂÂES_AddTitleCancel();
ÂÂÂÂÂÂÂÂISFS_Deinitialize();
ÂÂÂÂÂÂÂÂreturn ret;
ÂÂÂÂ}

ÂÂÂÂISFS_Close(file);
ÂÂÂÂISFS_Deinitialize();

ÂÂÂÂ/*ret = ES_AddTitleFinish();
ÂÂÂÂif (ret < 0)
ÂÂÂÂ{
ÂÂÂÂÂÂÂÂprintf("Error: ES_AddTitleFinish returned %d\n", ret);
ÂÂÂÂÂÂÂÂreturn ret;
ÂÂÂÂ}*/
ÂÂÂÂIOS_ReloadIOS(254);
ÂÂÂÂ
ÂÂÂÂreturn 1;
}

I ended up with /tmp/title.tmd and /tmp/title2.tmd in my extracted NAND dump

I did a file compare with a hex editor and they matched perfectly.

So I restate my question: Is it possible that the new IOS is NOT checking the signature in ES_AddTitleFinish(), but is actually checking some other property of the /tmp/title.tmd file? Or am I missing something obvious?

Why this complicated, i mixed Trucha Bug Restorer and fstoolbox code for similar purposes. The exploit(s) are the same even if use a patched IOS. The owner id and the permissions of the file are wrong. As far as i know the owner id can't be changed by homebrew and you can't select which one is used when creating files. The permissions are something you might be able to change, but if they are restricted, then the system process might not be able to access it when you try to use the same.

 

[tueidj]

What is that meant to test? You patched out all the important stuff.

 

[WiiPower]

What is that meant to test? You patched out all the important stuff.

I think he is still trying to figure out what it actually is that causes the error, as it seems i was wrong with my theory that it saves the signature when adding the tmd and compares it again later.

It would be stupid from nintendo to not fix this exploit completely, but we have seen worse in the past, so it's not a complete waste of time looking into this.

 

[tueidj]

But that test doesn't do anything, all it does is create a new file, dump content in it and then run a nand dump - no surprise the files are identical. It doesn't even call ES_AddTitleFinish(), so his conclusion has no relevance.

 

[WiiPower]

But that test doesn't do anything, all it does is create a new file, dump content in it and then run a nand dump - no surprise the files are identical. It doesn't even call ES_AddTitleFinish(), so his conclusion has no relevance.

There's a chance that the tmd is modified when it's moved to the tmp folder. Well theoretically, it would change the signature...

 

[tueidj]

Tickets yes, TMDs no. And you're not going to find tickets like that in .wad files because pirates don't know how they work and fakesign everything instead.

 

[fogbank]

But that test doesn't do anything, all it does is create a new file, dump content in it and then run a nand dump - no surprise the files are identical. It doesn't even call ES_AddTitleFinish(), so his conclusion has no relevance.
I think the test proves pretty definitevely that it is not a signature check in ES_AddTitleFinish that is causing the existing code in TBR to return the -1017 error. That would be the relevance (to me anyway).

In my previous tests I did call ES_AddTitleFinish without modifying the new TMD and still got the -1017 error. This new test was just to prove that the existing code does create an exact copy of the TMD and that there is something besides a new signature check in ES_AddTitleFinish that is causing the error.

QUOTE(WiiPower @ Jul 15 2010, 06:28 AM) Why this complicated, i mixed Trucha Bug Restorer and fstoolbox code for similar purposes. The exploit(s) are the same even if use a patched IOS. The owner id and the permissions of the file are wrong. As far as i know the owner id can't be changed by homebrew and you can't select which one is used when creating files. The permissions are something you might be able to change, but if they are restricted, then the system process might not be able to access it when you try to use the same.

I took a look at the FSToolbox code and started weaving it into the TBR code but I kept getting -101 errors when trying to read info on the files in /tmp/ (even after identifying as SU etc...). This was a much quicker way for me just to get the contents of the files for comparison.

Thanks for the info on the owner id and permissions...that was exactly my line of thought

 

[fogbank]

Merged...sorry.