Open GoogleCodeExporter opened 9 years ago
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
also gsouders; never considered joining us on irc? :P
Original comment by dac...@gmail.com
on 4 Nov 2010 at 6:12
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
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
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
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
try this
hash=0x4bffe7e5,0x38bd05a8
patch=0x60000000
Original comment by dac...@gmail.com
on 6 Nov 2010 at 10:03
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
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
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
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
Original comment by dac...@gmail.com
on 28 Dec 2010 at 9:46
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
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
Issue 162 has been merged into this issue.
Original comment by dac...@gmail.com
on 19 Jan 2011 at 7:13
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
works fine here...
what system menu is installed?
Original comment by dac...@gmail.com
on 27 Jan 2011 at 6:33
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
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
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
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
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
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
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
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
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
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
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
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
changed locally. ill commit it soon
Original comment by dac...@gmail.com
on 17 Feb 2011 at 5:45
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
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
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
Original issue reported on code.google.com by
gsoud...@cox.net
on 3 Nov 2010 at 5:00