Memory protection?

[Mathew_Wi]

I'm trying to hack toy story 3 (NTSC), but it freezes when it dumps certain blocks.
I can only dump blocks 1-9 in the 80 mem range. In the 90 mem range it's much smaller.

I've tried almost everything, it's all blocked off with freezing if you try and dump it.
Tested with Gecko dot NET and WiiRd GUI. (Used OSSleep and GXFlush, both did same thing.)

[cajon]

I have the same problem here with the PAL version of the game.
It hangs after block 10
Has anyone of the more experience hackers an idea ??

[Anarion]

oh wow. what a coincidence. At the moment, I am having the same problem. just with another game.
WiiRD freezes on me after dumping block 52, rather, it doesn't load the addresses :(
Strange thing is that I can search anywhere else just fine, just in this one location I do the search, it hangs up -__-


I don't think that the actual RAM is protected. Especially for Toy Story 3 in your case.

[Anarion]

Well, I do search in the safe range. The thing is that I did one search for player 1 in the game, and it worked fine. For player 2, its not.
Anyways, I'll just have to try searching 92000000 to 93000000 since the address I want lies there. If it freezes then I'm all out of ideas  :|

[dcx2]

I wonder if the game is somehow hitting a Breakpoint.

1) Can you look at the allegedly protected memory areas with Memory Viewer?

2) Can you switch to the Breakpoint tab with WiiRDGUI and hit Get BP Data?  If so, copy/paste the registers/disassembly into a reply.  If not, then I'm assuming that WiiRDGUI is frozen because of the dump.  In that case, can you shut WiiRDGUI down and restart it and then go to the Breakpoint tab?

3) Try setting a dummy breakpoint, in case they somehow set up a read breakpoint.  Something like an execute on 80000000 - it would never happen.  Then cancel the breakpoint.  This would interrupt any pending breakpoints.

[Thomas83Lin]

I wonder if the game is somehow hitting a Breakpoint.

1) Can you look at the allegedly protected memory areas with Memory Viewer?

2) Can you switch to the Breakpoint tab with WiiRDGUI and hit Get BP Data?  If so, copy/paste the registers/disassembly into a reply.  If not, then I'm assuming that WiiRDGUI is frozen because of the dump.  In that case, can you shut WiiRDGUI down and restart it and then go to the Breakpoint tab?

3) Try setting a dummy breakpoint, in case they somehow set up a read breakpoint.  Something like an execute on 80000000 - it would never happen.  Then cancel the breakpoint.  This would interrupt any pending breakpoints.

I decided to take alook at it, found some interesting and strange things. That may be helpful or mean absolutely nothing I'm unsure


1. yes and no, sometimes you can, and sometimes you can't thats why i'm almost sure its not protected memory but it does act like protected memory. I've narrowed the first freeze down to a address 809A9000 heres a pic, almost seems like a new protection, i could only view this address location before the intro after that it freezes also. Also Putting in 809A8FC0 in the disassembler so that DEADBABE isn't showing in the disassembler. the freeze never occurs only when deadbabe is being viewed it freezes

2.No i couldn't

3. done nothing, i also set a Bp on the first line of the code handler to make sure the game was completely frozen. but still froze at the same spot when dumping.

Also i was able to dump 14blocks instead of 9 if dumping at the controller intro screen. that in itself almost proves its not protected memory at least i believe so. Well Hopefully this info helps alittle and i hope this doesn't become a trend
[spoiler]

[dcx2]

DEADBABE is the kind of thing I usually see when there is stack or heap protection.  What you do is fill a bunch of memory with a particular value, like DEADBABE, and then later you can go look over the memory and if anything isn't DEADBABE then you know someone wrote something that they shouldn't have.

This is interesting.  There's not much that should cause a trap on a read...

Can you read the end of memory?  That is, is it a "protected hole"?  Or is everything after 809A9000 off limits?

Can you poke 809A9000 to 0?  If the poke is successful, does it still freeze back in the disassembler?

[Thomas83Lin]

DEADBABE is the kind of thing I usually see when there is stack or heap protection.  What you do is fill a bunch of memory with a particular value, like DEADBABE, and then later you can go look over the memory and if anything isn't DEADBABE then you know someone wrote something that they shouldn't have.

This is interesting.  There's not much that should cause a trap on a read...

Can you read the end of memory?  That is, is it a "protected hole"?  Or is everything after 809A9000 off limits?

Can you poke 809A9000 to 0?  If the poke is successful, does it still freeze back in the disassembler?

sorry for the typos, its 1:10am here.

1. Partially haven't find exactly were but between 80B00000-80D00000 is fine doesn't freeze then between 80E-818 freezes again

2. yes still freezes, also applying it with sd cheats, the game doesn't even boot Green Screen

[dcx2]

Okay, this next test is somewhat exotic...

Make a code that writes 0 to the DEADBABE address.  Pause the game.  Apply the code.  Note that because the game is paused, the memory has not been written to yet.

Go looking for the code data in memory.  It's prefixed with C0DE, around 80002xxx.  Once you find your code, set a Read breakpoint on it.  You should end up in the Code Handler.  Follow along by stepping and you should eventually land on a stw (after maybe 20-30 instructions) that writes 0 to the DEADBABE address.  What happens when you press Step while the active instruction is that write?

[Thomas83Lin]

Okay, this next test is somewhat exotic...

Make a code that writes 0 to the DEADBABE address.  Pause the game.  Apply the code.  Note that because the game is paused, the memory has not been written to yet.

Go looking for the code data in memory.  It's prefixed with C0DE, around 80002xxx.  Once you find your code, set a Read breakpoint on it.  You should end up in the Code Handler.  Follow along by stepping and you should eventually land on a stw (after maybe 20-30 instructions) that writes 0 to the DEADBABE address.  What happens when you press Step while the active instruction is that write?

If i followed your last instruction correctly i ended up on a  b 0x80001fa0 right after the stw r4,0(r12)

[dcx2]

That sounds right; r4 would have the second code word, which is a 0.  r12 is I think where the ba + address ends up; it should be 809A9000

If you stepped over that stw successfully, then that's very, very interesting...

After you step over stw r4,0(r12), hit Run.  Is the game frozen?  If the game freezes, press Get BP Data and post the registers/disassembly.

[Thomas83Lin]

That sounds right; r4 would have the second code word, which is a 0.  r12 is I think where the ba + address ends up; it should be 809A9000

If you stepped over that stw successfully, then that's very, very interesting...

After you step over stw r4,0(r12), hit Run.  Is the game frozen?  If the game freezes, press Get BP Data and post the registers/disassembly.

Stepped over stw, then hit run, the game didn't freeze still want the bp

edit: But it will freeze if i let the game get past the intro

[dcx2]

Wait, so you applied the code before the intro screen?  What about after?

[Thomas83Lin]

Wait, so you applied the code before the intro screen?  What about after?

Ok after the intro is quite different, after putting a read break on the code it took me instantly to the stw which was strange,  can't step past it, or hit run frozen
another time doing the same thing i got stuff like r0 :11111111 r1 :11111111 in every reg

CR  : 82004402  XER : 20000000  CTR : 00000000  DSIS: 42000000
DAR : 809A9000  SRR0: 80002054  SRR1: 00002032  LR  : 80001904
r0  : 20000000  r1  : 80002938  r2  : 80785000  r3  : 009A9000
r4  : 00000000  r5  : 00000002  r6  : 80000000  r7  : 80001808
r8  : 00000000  r9  : 00000000  r10 : 00000000  r11 : 00000000
r12 : 809A9000  r13 : 808E1000  r14 : 80000000  r15 : 800028C8
r16 : 80000000  r17 : 800028C5  r18 : 0000004D  r19 : 00000001
r20 : CC000000  r21 : 000000FF  r22 : 00000019  r23 : 000000D0
r24 : CD000000  r25 : 00002032  r26 : 00002032  r27 : 000003E8
r28 : 000000FF  r29 : 80001904  r30 : 80001C38  r31 : 80000000

f0  : 3F05616E  f1  : 3F800000  f2  : 00000000  f3  : 3F400000
f4  : BF400000  f5  : 3F800000  f6  : BF800000  f7  : 3F76AB57
f8  : 3D448BE4  f9  : BE9256CF  f10 : BF755215  f11 : 00000000
f12 : 00000000  f13 : 00000000  f14 : 00000000  f15 : 00000000
f16 : 00000000  f17 : 00000000  f18 : 00000000  f19 : 00000000
f20 : 00000000  f21 : 00000000  f22 : 80002938  f23 : 00000000
f24 : 20000000  f25 : 42004402  f26 : 00000000  f27 : 20000000
f28 : 00000001  f29 : 80002774  f30 : 00000000  f31 : 80000000

80002054:  908C0000   stw   r4,0(r12)
80002058:  4BFFFF48   b   0x80001fa0
8000205C:  7C892378   mr   r9,r4
80002060:  409E04C8   bne-   cr7,0x80002528
80002064:  3529FFFF   subic.   r9,r9,1
80002068:  418004C0   blt-   0x80002528
8000206C:  7CA978AE   lbzx   r5,r9,r15
80002070:  7CA961AE   stbx   r5,r9,r12
80002074:  4BFFFFF0   b   0x80002064
80002078:  39EF0008   addi   r15,r15,8
8000207C:  40BEFF24   bne-   cr7,0x80001fa0
80002080:  80AFFFF8   lwz   r5,-8(r15)
80002084:  816FFFFC   lwz   r11,-4(r15)
80002088:  54B1043E   rlwinm   r17,r5,0,16,31
8000208C:  54AA853E   rlwinm   r10,r5,16,20,31
80002090:  54A5273E   rlwinm   r5,r5,4,28,31


edit:
I also tried the address directly below 809a9000 which its value is always 00000000 i made the code 049a9004 00000000 keeping its original value done exactly the same thing as above, and got the same results.

[dcx2]

That's very freaky..it's frozen on stw r4,0(r12), but r12 is a valid pointer.

And if r1 had a corrupted value like all 1's, then I wonder if Gecko OS is getting screwed up.  brkirch might have some insights...but I think I'm all out of suggestions.