DashLaunch Full Memory Editing patches?

[Dwack]

I'm looking for help on figuring out what part of the DL freeBOOT patches enable the full memory editing feature. I have built myself what I believe is a patched HV/Kernel image and have began the task of searching through the code looking for any signs. The thing is it's a lot of code. So my question is does anyone have any hints on where to look or anything to look for that might aid in my search?

TIA

-Dwack

[cory1492]

Erm... why?  

"HINT!" @ 13599

Code:

.set TLB_RPN, 0x3b5

#;============================================================================
#;   hv tlb_rpn set command location       mtspr   TLB_RPN, %sp          
#;============================================================================
.set PatchAddr, 0x000011BC
.set PatchTlbRpnDone, (PatchAddr + (9f - 0f))

.long PatchAddr
.long (9f - 0f) / 4
0:
ba      PatchTlbRpn
9:

#============================================================================
#   Patch TLB RPN to Remove Protections                                      
#                                                                            
#     - allows code excution anywhere in 0x80000000->0x9FFFFFFF range
#       (xbox restricts exec to this range, not sure if that can be lifted at all)    
#     - allows system thread manipulation of code/read only data without    
#       disabling encryption                                                
#     - 0x0007 clears bits NoExec:DataPage:Readonly of all RPN register sets                  
#============================================================================
.set PatchAddr, 0x0000154C
.set PatchTlbRpn, PatchAddr

.long PatchAddr
.long (9f - 0f) / 4
0:
li      %r4, 0x0007             # removes all page protection
andc    %sp, %sp, %r4
mtspr   TLB_RPN, %sp            # instruction replaced to get here
ba      PatchTlbRpnDone
9:

There are other patches to disable this on demand lumped in with a keyed syscall hook that does a couple other things.

[Dwack]

So I was looking at this again, just trying to get a better understanding of things.

I made myself a HV image so I could save the TLB_RPN before and after.

Code:

0:
mfspr   %r4, TLB_RPN
std     %r4, 0x88(%r0)
std %r1, 0x90(%r0)
li %r4, 7
andc %r1, %r1, %r4
std     %r1, 0x98(%r0)
mtspr TLB_RPN, %r1
ba 0x11C0
9:

The values I got were:

TLB_RPN Orig:
00 00 00 00 1f ff 00 80 -> 0000 0000 0000 0000 0000 0000 0000 0000 0001 1111 1111 1111 0000 0000 1000 0000
GPR_R1
00 00 00 00 1f ff 01 96 -> 0000 0000 0000 0000 0000 0000 0000 0000 0001 1111 1111 1111 0000 0001 1001 0110
TLB_RPN After
00 00 00 00 1f ff 01 90 -> 0000 0000 0000 0000 0000 0000 0000 0000 0001 1111 1111 1111 0000 0001 1001 0000

TLB_RPN After is the result of the

Code:

andc %r1, %r1, %r4

which is equivalent to:

    0000 0000 0000 0000 0000 0000 0000 0000 0001 1111 1111 1111 0000 0001 1001 0110
&
    1111 1111 1111 1111 1111 1111 1111 1111 1111 1111 1111 1111 1111 1111 1111 1000


Now if I am understanding the TLB entries from the PowerISA e-Book. The only bits that is changing are:
61: Base SR -> Supervisor Read
62 SW1 Available for software use

What about this am I not understanding? Would you not want to change the Base Access Permission bits(56:61)?

It also says a lot about how the MSRpr bit has a lot to do with how the data is allowed. I don't have an MSR value so I'm not even sure what that value would be.

[cory1492]

Now if I am understanding the TLB entries from the PowerISA e-Book.

If so you aren't looking at the same book ISA I am, which doesn't describe TLB_RPN in how it's implemented on the xbox 360 at all. The ISA discusses possible implementations, but that is down to the manufacturer how they choose to implement it. 360 is more like cell than it is like the ISA examples with regards to special purpose registers, though a lot of things are identical between cell PPU and ISA PowerPC too.

The bits that are &~0x7 (0x7 = 0b111, bits 61-63) I found to be undocumented but set thus:

Code:

UINT64 NoExecute : 1;
UINT64 ReadOnly : 1;
UINT64 DataPage : 1;

of the bitfield

Code:

typedef struct TLB_RPN{
UINT64 Reserved1 : 22;
UINT64 RealPageNumber : 30;
UINT64 Reserved2 : 2;
UINT64 AddressCompare : 1;
UINT64 Reference : 1;
UINT64 Change : 1;
UINT64 WriteThrough : 1;
UINT64 CacheInhibited : 1;
UINT64 MemoryCoherency : 1;
UINT64 Guarded : 1;
UINT64 NoExecute : 1;
UINT64 ReadOnly : 1;
UINT64 DataPage : 1;
};

after much experimentation (think in terms of months of poking at different things in hv looking for what was enforcing the noexecute and nowrite - the simple answer is that nothing is enforcing it except the CPU itself.) BTW, if you are also wondering why only 0x80000000-9FFFFFFF is the only area that allows execution, look into the instruction exception vector. Also, stripping any other bits (and even just 0x7) on a debug firmware has the net effect of breaking many features that are required for effective debugging.

Typically in hv context the msr is:
0000000000009030
48 External Interrupt Enable
51 Machine Check Interrupt Enable (hv resource)
58 Instruction Relocate
59 Data Relocate
This isn't always true as hv does modify it when it needs to, but tends to put it back to this after anyway.

[Dwack]

After posting this I spent a little more time on Google trying to find a few more answers. I was able to eventually find something that showed the bits you are describing 61:63. It had them labeled as:

Code:

61 - No Execute
62:63 - Page Protection

From that I could pretty much guess as to which bits were being cleared by the DL patch.

I'm still looking into the MSR and everything that it works with.

I do thank you for your very well explained answer. I am having a hard time wrapping my head around all this information coming at me lol.