Hacks_hash hacks reports

[GoogleCodeExporter]

What steps will reproduce the problem?
1.Enable Block Disc Updates
2.Boot to System Menu
3.Load any game disc in the DVD slot

What is the expected output? What do you see instead?
Expecting game disc to boot and display graphic in Disc Channel but instead the 
Wii will lockup

What version of priiloader are you using? On what ios/system menu?
Priiloader - V0.6(beta v1)
IOS - 70
System Menu - 4.2U

Do you have any IOS patches installed? (if so which ios and what patch?)
Yes but not applicable to this problem

What are your wii system menu settings
Not applicable to this problem

Daco I have reproduced this problem on two wii's mine and my buddies.  First I 
disabled all hacks to figure out which one was causing the lockup.
Once I isolated the offending hack I reverted back to classic hacks.ini to see 
if the problem still exists. The problem does not occur when using classic 
hacks.ini.  Can you reproduce this?  Thanks...

Original issue reported on code.google.com by gsoud...@cox.net on 3 Nov 2010 at 5:00

[GoogleCodeExporter]

thats weird. i checked the hash/patch and they should result in the same 
addresses :/

enable debug output in the options, enable the hack and tell me what it says 
about applying the patch (the address)

Original comment by dac...@gmail.com on 3 Nov 2010 at 6:25

[GoogleCodeExporter]

Daco I have tried this but it happens to fast for me to read the address.  Is 
there a way to freeze the output so I can read it?

Original comment by gsoud...@cox.net on 3 Nov 2010 at 6:35

[GoogleCodeExporter]

Never mind my last comment. I enabled some more hacks which allowed the output 
to remain on the screen so I could read it.  Two patches are applied for Block 
Disc Updates on my system...

0X8137F4BC hash # 0
0X8137F5BC hash # 1

Original comment by gsoud...@cox.net on 3 Nov 2010 at 6:54

[GoogleCodeExporter]

oooooo

now i see what i did wrong >_<

try this
[Block Disc Updates]
maxversion=511
minversion=288
amount=3
hash=0x3a831580,0x3ac00000,0x3aa00000
patch=0x60000000,0x60000000
hash=0x2c030000,0x40800020,0x7c9cb214
patch=0x60000000,0x60000000
hash=0x2c030000,0x40820020,0x7c9cb214
patch=0x60000000,0x60000000

i know it looks the same but its a huge difference :)

Original comment by dac...@gmail.com on 3 Nov 2010 at 3:55

[GoogleCodeExporter]

Daco I replaced the Block Disc Updates section with what you posted in comment 
4 but the problem still remains.  You say it looks the same but its a huge 
difference?  When I examine the code it is identical.  Am I missing something 
here?

Original comment by gsoud...@cox.net on 3 Nov 2010 at 9:12

[GoogleCodeExporter]

the 3th & the 2nd set of hash are swapped.
this being because the 3th one was ignored since its address is before the 
second one.
please check the addresses again. i checked the 4.2 booting app and the hash is 
1000% there :/

hash 0 should be 0x8137F4BC (and 0x8137F4C0 but thats part of the patch)
hash 1 should be 0x8137F564 (and 0x8137F564  "    "    "    "  "    "  )
hash 2 should be 0x8137F5BC (and 0x8137F5C0  "    "    "    "  "    "  )

the addresses the old hacks used are the same :
0 : 0x8137F4BC,0x8137F4C0
1 : 0x8137F564,0x8137F568
2 : 0x8137F5BC,0x8137F5C0

Original comment by dac...@gmail.com on 3 Nov 2010 at 9:43

[GoogleCodeExporter]

OK I now see that the 2nd and 3rd set of hash are indeed swapped.  I enabled 
Gecko Output again and I am not getting what I should.  As you can see in 
comment 3 I was only getting two patches applied.  With the change you gave me 
I am still only getting two patches applied.  The addresses are the same as 
comment 3 but the hash numbers have now changed.  Here is what I am now 
getting...

0X8137F4BC hash # 1
0X8137F5BC hash # 2

Original comment by gsoud...@cox.net on 3 Nov 2010 at 11:37

[GoogleCodeExporter]

Daco I just figured out that I am infact getting the exact results now as I was 
in comment 3.  I built the latest version of Priiloader R118 which I am now 
using.  This is what has caused a change in the Gecko output hash numbers.  So 
here are the results using the patched hacks_hash.ini for both versions...

Prilloader V0.6(beta v1)
________________________

0X8137F4BC hash # 0
0X8137F5BC hash # 1

Priiloader R118
_______________

0X8137F4BC hash # 1
0X8137F5BC hash # 2

Original comment by gsoud...@cox.net on 4 Nov 2010 at 12:31

[GoogleCodeExporter]

Daco I have figured out what is going on here.  Since I was only getting 2 
patches applied I decided to change the ordering of the Block Disc Updates 
sections.  This corrected the lockup problem.  This is how my file now looks...

[Block Disc Updates]
maxversion=511
minversion=288
amount=3
hash=0x3a831580,0x3ac00000,0x3aa00000
patch=0x60000000,0x60000000
hash=0x2c030000,0x40800020,0x7c9cb214
patch=0x60000000,0x60000000
hash=0x2c030000,0x40820020,0x7c9cb214
patch=0x60000000,0x60000000
[Block Disc Updates]
maxversion=518
minversion=512
amount=2
hash=0x2c030000,0x40800020,0x7C9AEA14
patch=0x60000000,0x60000000
hash=0x2c030000,0x40820020,0x7C9AEA14
patch=0x60000000,0x60000000

As you can see I placed the section that needs to be executed for version 4.2 
with 3 patches before the section for newer versions with only 2 patches.  I 
believe system menu 4.2 equates to version 481.  So the question is why was the 
section with minversion=512 / maxversion=518 being executed on a 4.2 system?  I 
would of thought  this section would of been ignored and the other section with 
minversion=288 / maxversion=511 would be executed.  Can you explain?

Original comment by gsoud...@cox.net on 4 Nov 2010 at 5:55

[GoogleCodeExporter]

it was ignored. the hash of 4.3 (512 - 518) isn't in <4.3 afaik.
if it wasn't ignored it would be on the hacks list as well (aka , having block 
updates twice)

Original comment by dac...@gmail.com on 4 Nov 2010 at 6:44

[GoogleCodeExporter]

OK Daco I just switched the sections back the way they were with the 4.3 
section first.  It seems to work now processing all three patches for 4.2.  I 
tested this several times and before it was only processing two off the patches 
for 4.2.  I can not explain this but I know it was happening according to 
Gecko.  Anyway problem is solved and thanks for your assistance.

I have noticed that the new hacks file processes slower than the old one.  
Returning from HBC to the system menu is about 4-5 seconds with the old hacks 
and 8-9 seconds with the new hacks.  This is with the same hacks enabled for 
both.  Could this be because I removed all unused sections from the old hacks 
file. I only kept the ones for 4.2 or 481?  Would removing unused sections 
decrease the processing time for the new file?

I would also like know why region free Everything is not offered for 4.2 or 
481?  Is it just not possible?

Lastly, I have never liked the fact that the hacks file is located at the root 
of the drive.  Would it be possible to put the hacks file in the 
apps/priiloader folder?  You could still check for the file at the root and if 
not found check the priiloader folder.  I think it would make sense since you 
are now the keeper of the new hacks file and will distribute it with 
Priiloader.  What do you think?

Original comment by gsoud...@cox.net on 4 Nov 2010 at 7:41

[GoogleCodeExporter]

i wouldn't be surprised the hash hacks are infact slower. this is because the 
old method had the addresses in the hacks.ini on where to patch.
the hash method looks for the addresses using a hash. this means the new method 
goes over a few thousand addresses for every hack.
i could increase the boot time in return the above issue doesn't happen 
(hash/patch's not being in the right order)

also, since im changing the whole hacks shit i could indeed make it place it on 
apps/priiloader. this being that it can now process the apps folder as well :P

Original comment by dac...@gmail.com on 4 Nov 2010 at 3:38

[GoogleCodeExporter]

I decided to customize my hacks_hash.ini file and remove any sections not 
applicable to 4.2.  This makes a level playing field since I did the same for 
my hacks.ini.  I then made sure that the same hacks are enabled for both 
methods.  I have 12 hacks enabled for both.  I tested both methods of hacking 
with r118 (faster than 0.6 Beta) by returning from HBC to the system menu.  The 
performance difference is not to bad.  Using the stop watch on my phone here 
are the results...

hacks.ini - ~7.5 seconds
hacks_hash.ini - ~9.5 seconds

Not sure what you mean by "i could increase the boot time in return the above 
issue doesn't happen (hash/patch's not being in the right order)".  Are you 
saying that perhaps some of the other hash/patch's are incorrectly ordered or 
just the one for Block Disc Updates?

Still am wondering about region free everything for 4.2.  Is it possible?  It 
was not offered in my old hacks.ini for 4.2.

I have a hack in hacks.ini but not in hacks_hash.ini.  The hack is called 
[Recovery Mode (D-Pad Up 4th GC)].  I do not have a game controller so I have 
never used this hack.  I am just curious why it was not ported to the new hacks 
hash file?  Here is what I have from hacks.ini...

[Recovery Mode (D-Pad Up 4th GC)]
version=481
offset=0x8137ACCC,0x81379900
value=0x2C000008,0x60000000

Finally I am glad that you are considering moving the hacks file from the root 
to the priiloader folder.  If you do this will you also allow the old hacks.ini 
to be located in the Priiloader folder?  For those that wish to use the old 
method.

Original comment by gsoud...@cox.net on 4 Nov 2010 at 5:10

[GoogleCodeExporter]

2secs more, blaaarg D:

also, there is the force recovery mode hack right? :/
i dont understand why you'd want to enter recovery mode with the gc pad if it 
can be done with a wiimote or that hack...

Original comment by dac...@gmail.com on 4 Nov 2010 at 5:44

[GoogleCodeExporter]

o btw, im still considering if i would make it read hacks from the apps 
folder... if im goign to remove it in 2 versions i dont understand why i should 
change it :/

Original comment by dac...@gmail.com on 4 Nov 2010 at 5:45

[GoogleCodeExporter]

Yes [Force Standard Recovery Mode] is present.  I do not want to enter recovery 
mode with the gc pad as I do not even own one.  I was just mentioning that it 
was no included in the new hacks file.  I agree with you and I would leave it 
out as well.

Not sure what you mean by "if im goign to remove it in 2 versions i dont 
understand why i should change it".  Are you saying that the old hacks method 
will be removed in 2 versions?

Still wondering about region free everything for 4.2.  Does this one only work 
for 4.3?

Original comment by gsoud...@cox.net on 4 Nov 2010 at 6:02

[GoogleCodeExporter]

yes ill remove the old method in 2 versions unless ppl REALLY hate the hash 
method (even after ive went to all the trouble of porting it all ;_; )
0.6 introducing the hash; 0.7 removing the old method.
if i dont remove it ppl will never go forward and use a new method that is so 
much more flexible >_>

as for the region free; if i set it for 4.2 as well then it *should* mean that 
the hash used for the hack is also found in 4.2 meaning it *should* work on 4.2 
as well ye

Original comment by dac...@gmail.com on 4 Nov 2010 at 6:11

[GoogleCodeExporter]

also gsouders; never considered joining us on irc? :P

Original comment by dac...@gmail.com on 4 Nov 2010 at 6:12

[GoogleCodeExporter]

I would vote for removal of the old method.  Especially after all the work you 
put in.  I can not see why people would hate it.  They may complain about the 
performance issue but perhaps you can speed things up a bit.

I decided to try and implement the region free everything hack.  I changed the 
minversion to 481 which allowed the hack to show up on the hacks screen and 
then I enabled the hack.  It does not get picked up according to Gecko output.  
So I guess this means that one or more of the hashes are not found in 4.2.  
Would you agree?

Can you please enlighten me as to what the [Force Standard Recovery Mode] 
accomplishes?  I never know if I should enable this one because I am not sure 
of the implications.

As for irc, I sometimes login to some of them for various apps.  Usually if I 
can not get an answer from a developer.  However I find that reporting issues 
and asking questions here is helpful to others.  I learn allot from reading 
issues on google code.

Original comment by gsoud...@cox.net on 4 Nov 2010 at 8:07

[GoogleCodeExporter]

if the gecko output didn't show the hack being applied then the hash isn't for 
4.2; sadly.

as for the force standard recovery mode; it just forces system menu to boot in 
recovery mode which is just system menu with a disabled mail system (prob to 
debug some bricks :/ ). nothing special

Original comment by dac...@gmail.com on 4 Nov 2010 at 8:33

[GoogleCodeExporter]

More problems with the new hacks file.  Can you please have a look at this.

[Lock System Menu with Black Screen] is not working.  Here is what the old file 
address is and the Gecko output address using the new hack...

hacks.ini - 0x8137ACDC
hacks_hash.ini - 0x8137ACE4

[Force Standard Recovery Mode] is also not working.  This hack when enabled 
acutally executes [Lock System Menu with Black Screen]

hacks.ini - 0x8137ACB4
hacks_hash.ini - 0x8137AC4B

Original comment by gsoud...@cox.net on 4 Nov 2010 at 10:31

[GoogleCodeExporter]

OK I did some testing.  I was wrong about [Force Standard Recovery Mode] it 
works the same for both hacks.ini and hacks_hash.ini.  This hack boots to a 
black screen with the system menu version in the lower right corner.  I have 
never used this hack before so when I saw the black screen I thought it was 
doing a [Lock System Menu with Black Screen].  I also messed up the address in 
my last comment.  Gecko says 0x8137ACB4 which matches the value in hacks.ini.

The [Lock System Menu with Black Screen] is definately not working.  The old 
hacks method works locking down to a completely black screen.  The new method 
just returns to the normal system menu.  I checked the address value again 
using Gecko and it does not match what hacks.ini has.  The values are the same 
as I listed in my last comment.  Here they are again...

hacks.ini - 0x8137ACDC
hacks_hash.ini - 0x8137ACE4

Original comment by gsoud...@cox.net on 5 Nov 2010 at 7:24

[GoogleCodeExporter]

try this

hash=0x4bffe7e5,0x38bd05a8
patch=0x60000000

Original comment by dac...@gmail.com on 6 Nov 2010 at 10:03

[GoogleCodeExporter]

Fixed and working.  Not that I will ever use this hack but it should work.  
Thanks Daco...

Original comment by gsoud...@cox.net on 6 Nov 2010 at 7:50

[GoogleCodeExporter]

ill leave this issue open for any future hashes/patches that aren't right yet

Original comment by dac...@gmail.com on 6 Nov 2010 at 8:04

• Changed title: Broken Hacks_hash hacks

[GoogleCodeExporter]

Does it mean in 0.6 final, there is still the "old" hacks.ini version
so i can use 0.6 without loosing anything...
sorry, io dont see any pro in this cryptical hash stuff

Original comment by yvonne.m...@gmail.com on 25 Dec 2010 at 3:33

[GoogleCodeExporter]

yes you can use the old hacks.ini by changing the settings

its your choice but im dropping the old method eventually :')

Original comment by dac...@gmail.com on 25 Dec 2010 at 3:52

[GoogleCodeExporter]

Original comment by dac...@gmail.com on 28 Dec 2010 at 9:46

• Changed title: Hacks_hash hacks reports
• Changed state: Maintaining
• Added labels: Type-Other
• Removed labels: Type-Defect

[GoogleCodeExporter]

I have a question about the 4.1 U/J/E Region Free Wii Games and Region Free GC 
games hacks. Using 4.1U hacks.ini as an example.(same applies for 
hacks_hash.ini)

[Region Free Wii Games]  [Region Free GC Games (no VM Patch :( )]
version=449              version=449
offset=0x8137D47C        offset=0x8137D47C  
value=0x60000000         value=0x900DA5D8

Both the hacks.ini and hacks_hash.ini try to patch the same offset/hash twice. 
Is there a missing 0x60000000 patch or is it just not needed?

Original comment by kcchie...@gmail.com on 2 Jan 2011 at 4:30

[GoogleCodeExporter]

haha, thats funny to see. didn't see that yet...
the hacks_hash.ini is basically a port of the hacks.ini. i didn't notice that 
while porting actually, so they both have that

does the region free wii games hack work on gc games (0x60000000 = nop. meaning 
its not doing anything at that addresses so it might work for both...) and visa 
versa?

thanks
Daco

Original comment by dac...@gmail.com on 2 Jan 2011 at 10:50

[GoogleCodeExporter]

Issue 162 has been merged into this issue.

Original comment by dac...@gmail.com on 19 Jan 2011 at 7:13

[GoogleCodeExporter]

Hello, The hack.ini and the hash_hacks.ini for [re-enable bannerbomb v2] does 
not work !
It apply the patch but when rebooting the Wii, it block on a black screen just 
after pressing A on the advert !

Original comment by cs-nut...@live.fr on 27 Jan 2011 at 12:24

[GoogleCodeExporter]

works fine here...
what system menu is installed?

Original comment by dac...@gmail.com on 27 Jan 2011 at 6:33

[GoogleCodeExporter]

4.3E ! 
It could be because of the 4.3v2 IOses ?

Original comment by cs-nut...@live.fr on 27 Jan 2011 at 8:33

[GoogleCodeExporter]

no cause my wii is also fully up to date
so also 4.3E :/

can't say i have time to investigate because of the DSi exploit release

also, is the bannerbomb the only hack enabled? (to be sure that its the hack 
causing it)

Original comment by dac...@gmail.com on 27 Jan 2011 at 10:20

[GoogleCodeExporter]

Yes, no other patch, juste the Bannerbomb enabler ! Using prii 134 on 4.3e

Original comment by cs-nut...@live.fr on 28 Jan 2011 at 1:59

[GoogleCodeExporter]

works fine here... (same setup; up to date wii; rev134; 4.3e)
mind posting the bannerbomb hack from hacks_hash.ini here?

also, i think it has something to do with the hack itself since the original 
hacks.ini has it too?

Original comment by dac...@gmail.com on 28 Jan 2011 at 6:11

[GoogleCodeExporter]

Well, finally it works !
I'm sorry, the bug was related to changes on my IOSes ;)
The patch is working in every 4.3 Wii for every "normal" people xD

Original comment by cs-nut...@live.fr on 28 Jan 2011 at 10:33

[GoogleCodeExporter]

Is there any way to delete the Priiloader but keep the patch ?

It looks like the System Menu is not permanently patched...
If it's possible, can you compile it and email me so that you don't have to 
public release this unsafe .dol ^^
This is for personnal research !

Otherwise, I will have to convert the patch for Startpatch then compile it etc 
etc.. and I'm really not able to do that -_-"

Original comment by cs-nut...@live.fr on 29 Jan 2011 at 1:41

[GoogleCodeExporter]

no its not possible cause priiloader patches system menu in memory before it 
loads it. making the hacks temp (unlike starpatch which patches the actual file 
on nand)

also, afaik (but dont quote me on this) the old hacks method = the way 
starpatch patches stuff

Original comment by dac...@gmail.com on 30 Jan 2011 at 12:40

[GoogleCodeExporter]

So you mean old hacks.ini = patches the actual file on nand ?

Original comment by cs-nut...@live.fr on 30 Jan 2011 at 10:34

[GoogleCodeExporter]

no, i mean starpatch parses its hacks the same way but i could be wrong. never 
saw the starpatch source code :P

Original comment by dac...@gmail.com on 30 Jan 2011 at 11:58

[GoogleCodeExporter]

Not the same ^^

        {
        {"Block Online Updates"},
        0x360590,
        {
            0x68, 0x74, 0x74, 0x70
        },
        {
            0x6E, 0x75, 0x6C, 0x6C
        },
        4
    }

Original comment by cs-nut...@live.fr on 30 Jan 2011 at 12:13

[GoogleCodeExporter]

ahahahaha
it works with hashes. not sure what the 0x360590 is about; but the 0x68747470 
is the original code it needs to find in the app; second is the patch.
so if you can figure out what that 0x360590 you can port it yourself using the 
hacks_hash.ini

Original comment by dac...@gmail.com on 30 Jan 2011 at 1:43

[GoogleCodeExporter]

Hi Daco,

I have tested and found a problem of the hacks "re-enable bannerbomb v2".
It only works for SM513 and 514 (4.3U/E) but doesn't work for SM512 and
518 (4.3J/K).

This hacks should be revised to 3 versions like below:

[Re-enable Bannerbomb v2]
maxversion=512
minversion=512
amount=2
hash=0x41800040,0x89029184
patch=0x48000040
hash=0x41800040,0x89029168
patch=0x48000040

[Re-enable Bannerbomb v2]
maxversion=518
minversion=518
amount=2
hash=0x41800040,0x89029194
patch=0x48000040
hash=0x41800040,0x89029178
patch=0x48000040

[Re-enable Bannerbomb v2]
maxversion=514
minversion=513
amount=2
hash=0x41800040,0x8902919C
patch=0x48000040
hash=0x41800040,0x89029180
patch=0x48000040

Original comment by airlin...@gmail.com on 16 Feb 2011 at 11:17

[GoogleCodeExporter]

changed locally. ill commit it soon

Original comment by dac...@gmail.com on 17 Feb 2011 at 5:45

[GoogleCodeExporter]

Daco: The 0x360590 is the offset of the hash (minus the base address, i.e. the 
offset in the file). StartPatch makes doubly sure it is patching the right 
thing by checking the offset AND the hash, seeing as its permanent and all.

Original comment by themanwithnoaddress@gmail.com on 23 Aug 2011 at 10:47

[GoogleCodeExporter]

right, but that makes it only work for 1 SM version then since the offset 
changes for every version/region

Original comment by dac...@gmail.com on 23 Aug 2011 at 10:56

[GoogleCodeExporter]

reminder for myself to try no background music and regionfree hack on SM 4.3(J?)

Original comment by dac...@gmail.com on 5 Mar 2012 at 8:27