Hacking Hijill 0.2 release

[damysteryman]

Now this is quite interesting... just compiled it and gave it a go. Now all I have to do is figure out what patches I want to use.....

Awesome work yet again giantpune!

@xfcrowman:
The method for applying the patches seems to be the same, but the 0x8132FAE0 value is used for the system menu, since that is where the system menu executable sits in memory when preloader patches it. For this however, it appears that it could be 0x8132FF80 instead.

At least the patches "looked" correct when I patched them using this offset value, but I did not have any way to test it, seeing as the dumped raw hbc_1.0.8.elf refused to boot for me at all, neither before or after patching (HBC gave "Error: This is not a valid Wii application" with both patched and unpatched while trying to load via wiiload)

Now I have not tried the following idea yet, but maybe instead of that, maybe try to "insert" the wrapper.dol into the HBC wad, similar to how priiloader "inserts" itself into the system menu (that is, rename the executable 000000xx.app inside HBC to 100000xx.app, then rename wrapper.dol to 000000xx.app)?

I am going to try this method out later, when I have some more time.

 

[SifJar]

Another option is dump the HBC elf with the HBC dumper version of Hijill, manually apply the patches you want, put it in a channel and install it - this way you wouldn't need the official HBC installed at all.

I'm currently trying to do this, and I have been reading SifJar's guide for porting preloader patches to help me figure out how to manually apply the patches with a hex editor.

I think that for each patch, I need to find the correct offset by subtracting 0x8132FAE0 from each address, and then replace the existing values with the ones provided in the source.

For instance:

Spoiler

For the following patch:

// ticketview check
write32( 0x81331818, 0x38600001 );

0x81331818-0x8132FAE0 = 1D38 (that's the offset)

Go to offset 1D38 in HBC.elf with a hex editor, and you find: 48 02 AC B9

Replace this with: 38 60 00 01 and then you have manually applied the patch.

SifJar - is my understanding of this correct? If so I will try manually adding the RemoveAntiHaxx patches manually and then see if this modified hbc.elf works.

Only if the base address is 0x8132FAE0. I haven't dumped the elf, nor do I know much about it, so it may or may not be so. I would have expected the original value to be closer to the patched value though, so I'm thinking that may not be the correct base address in this case.

I think in this case the base address is 0x80004000 because this is where the first copy of HBC is put in memory (mem1), which giantpune said is the copy that is patched. So I would think you would replace 0x8132FAE0 with 0x80004000, but otherwise your method looks correct to me.

EDIT: damysteryman's base address is probably right, he knows more about this sort of thing than me.

 

[person66]

At least the patches "looked" correct when I patched them using this offset value, but I did not have any way to test it, seeing as the dumped raw hbc_1.0.8.elf refused to boot for me at all, neither before or after patching (HBC gave "Error: This is not a valid Wii application" with both patched and unpatched while trying to load via wiiload)

It refuses to boot with the HBC, but when starting it from bannerbomb, it seems to work (haven't tried letterbomb). Although all you get is the scam warning screen.

EDIT: Yeah, damysteryman is right, 0x8132FF80 is correct, at least that is what I found.

EDIT 2: After applying patches, I still get the scam warning screen.

EDIT 3: If you don't want to manually add the patches, you can just add this to the main function of the worker, after the lines that apply the patches you want:

Init_Console();		
printf("Dumping HBC...");
if (!fatInitDefault()) {
printf("Unable to initialise FAT subsystem, exiting.\n");
exit(0);
}	
FILE * f;
f = fopen("hbc.elf", "wb");
if (f == NULL) {
printf("\n\n[ERROR] Could not open/create hbc.elf file for writing.\n");
sleep(3);
}
else{
fwrite ((void*)0x8132FF80 ,1 ,0x102560 ,f);
fclose(f);
printf("Done!");
sleep(1);
}

And then use a hex editor to replace the first 80 bytes of that file with the first 80 bytes from the hbc elf dumped with pune's dumper (should end right before the "H.. _arg")

 

[JoostinOnline]

At least the patches "looked" correct when I patched them using this offset value, but I did not have any way to test it, seeing as the dumped raw hbc_1.0.8.elf refused to boot for me at all, neither before or after patching (HBC gave "Error: This is not a valid Wii application" with both patched and unpatched while trying to load via wiiload)

It refuses to boot with the HBC, but when starting it from bannerbomb, it seems to work (haven't tried letterbomb). Although all you get is the scam warning screen.

I tried changing the title id for the HBC (this was like a year ago) and I got the same thing.

 

[SifJar]

I reckon this could be important:

	// patch that [censored] to let us patch it without bitching
NOP( 0x800045B0 );
NOP( 0x800049EC );
write32( 0x8000488C, 0x7F80E378 );

NOP is essentially patching the address given to 0x60000000, so work out the correct offsets for those and change them to 0x60000000, then add the last patch. Perhaps that will make it start.

 

[person66]

I reckon this could be important:

	// patch that [censored] to let us patch it without bitching
NOP( 0x800045B0 );
NOP( 0x800049EC );
write32( 0x8000488C, 0x7F80E378 );

NOP is essentially patching the address given to 0x60000000, so work out the correct offsets for those and change them to 0x60000000, then add the last patch. Perhaps that will make it start.

Didn't help for me, although maybe I got the offset wrong, they are different for this one. I believe it starts at 0x80004000 (0x80003F80 after compensating for the 80 bytes at the beginning of the elf, which I would assume are the header or something), as opposed to the other one which starts at 0x81330000 (0x8132FF80 after compensating for the header)

 

[JoostinOnline]

Hijill, Hijill GUI, and HBC_dumper don't work with the latest HBC.

 

[WiiUBricker]

Well, you can still hijack HBC 1.0.8 or use an alternative like Homebrew Filter or postLoader

 

[JoostinOnline]

Well, you can still hijack HBC 1.0.8 or use an alternative like Homebrew Filter or postLoader

I'd rather not put up with the update warning everytime (lol, we need Priiloader for the HBC), and I like Hijill.

I don't know if this was on purpose or an accident, but my guess it that it was intentional. They really don't like their hacks getting hacked.

 

[Luigi2012SM64DS]

p.s. the web in the first post is long gone

 

[giantpune]

hijill used the sha1 of hbc to make sure it got the right file. new hbc = new sha1 = hijill wont find it. you can still use it with the old hbc. and you can patch out whatever you dont want. so that prompt to update is only a 4 byte patch away from stopping. get your disassembler out and whip up something.

 

[SifJar]

hijill used the sha1 of hbc to make sure it got the right file. new hbc = new sha1 = hijill wont find it. you can still use it with the old hbc. and you can patch out whatever you dont want. so that prompt to update is only a 4 byte patch away from stopping. get your disassembler out and whip up something.

Heck, you probably don't even need to disassemble. Search the dumped HBC in a hex editor and find the update URL, patch it to change the http at the start to something else (I believe that is how the update check patch in priiloader works), then it won't be able to connect so won't find an update.

And I guess it wouldn't be all that hard to update Hijill with the new SHA1 anyway?

 

[giantpune]

i havent looked at the new hbc at all other than to actually use it to start dols. but even assuming they used the exact same encryption stuff, you would still need to disassemble it and get all the keys, offsets, and lengths for the different encrypted segments. then you would need to forget about all the existing patches. they are all completely specific to that 1 binary. they would need to be re-written or ported to the new binary.

 

[SifJar]

Hmm, yeah that'd be more work than I imagined then...