Editing Drk notes

Varius notes, mostly related to nulldc's development and whatnot. Might be useful for someone wanting to port smth/write dynamic code ! 

=== Intro stuff ===
My assembly pseudo-code will most likely use intel-x86-like syntax, as i find it more descritpive than the cryptic ppc opcode names. Sorry if that makes you unhappy :| 

This page will need some formating love soon, i'l get to it... 

=== PPC64 Emitter ===
PPC 64 emitter and Emitter Helper. This is the complete ppc64 opcode set as found on pem_64bit_v3.0.2005jul15.pdf, generated by my ppc emitter generator. This hasn't been tested, but the wii ppc emitters i did were built the same way, and they did work .. more or less :). The emitter helper doesn't really help much and needs to be worked on. 




This might be useful for runtime patches/stuff, and well dynarecs ! If someone wants a runtime disassembler/etc the emitter generator can be modified to generate that -- just drop me a message .... 




TODO: ppe emitter with the extra opcodes, add in opcode info/etc, and see about spe ! 

=== Getting runtime generated code to run === 
We cannot run code from the heap (malloc, seems like mmu protection) 

We cannot run code from .bss (static array, seems like mmu protection) 

Here's what happens when i try to execute code: 




lv2(2): # Interrupt(exception) Info.

lv2(2): # Type : Instruction Storage

lv2(2): # SRR0 : 0x0000000000020a2c //Code fetch address

lv2(2): # SRR1 : 0x800000001000c032

lv2(2): # DSISR: 0x0000000002200000

lv2(2): # DAR : 0x000000003000000c

lv2(2): # TB : 0x000000003a7db9b6 



We cannot modify existing code (seems like mmu protection) 




So for user mode W^X seems to be implemented properly. More tests pending on this. 

Also, there are probably calls on lv2 to disable W^X   usermode can't generate dynamic code, lv2 seems to be enforcing this,  and there are surely lv1 calls for that. 

We can run code off the lv2 heap. 




=== Misc ABI notes ===
ABI seems to be 32 bit more for ppc64 

in 32 bit mode, 64 bit registers are visible, and 64 bit opcodes are avaiable. However, only the lower 32 bits are used for memory access (top bits ingored). This all needs to be verfied, all i really know is that sizeof(void*)==4. 




Register usage (based off my wii dynarec docs -- might not be 100% correct -- still need to read up the abi docs properly): 

<pre>
Registers:
32 64-bit gprs
r0     volatile, temp
r1     stack pointer, grows down
r2     TOC (what ?) Pointer (who cares)
r3:10  voalitle, first 8 params.r3 is also return value
r11    volatile (used as 'enviroment' pointers for calls by ptr .. what?)
r12    volatie (sed for ming & magic as well as linking)
r13:31 preserved (19 of em)

32 64-bit fprs (f32/f64, stored in f64 format always)
f0     volatile, scratch
f1:4   volatile, params, return
f5:13  volatile, params
f14:31 preserved (18 of em)

32 128-bit vprs (s/u 8/16/32, f32)
LR  Link (preserved)
XER (exception register,preserved?)
VSCR
VRSAVE
FPSCR
CR (CR0:1;CR5:7 volatile, CR2:4 preserved)
CTR

When calling:
Call stack: 
Return is stored on the link register and its saved at a specific location on function entry
lr is stored on sp+4
stack grows towards zero
</pre>


Function pointers: 




Function pointers are actually pointers to a 'function descriptor'. The descriptor holds the address of the function, as well as the rtoc. When a call is made it goes like





struct fnptr_t { void* fun; void* rtoc; }; 

.... 

fnptr_t ptr; 

..... 

mov %rtoc,ptr.rtoc; //set the callee rtoc 

call/jump ptr.fun;    //call to it, have seen it use btctrl and blrl for this 

mov %rtoc,whatever backup; //restore this function's rtoc 




=== Quick PS3 structure intro ===
(Just my notes on my understanding so far) 




lv1: Hypervisor 

lv2: "kernel" 

usermode : our normal code runs here exploit shellcode runs on lv2, via a heap overflow 




=== lv1 ===
Manages page table delegates decryption to an isolated spe pretty much all security passes through this 




=== lv2 ===
Processes, threads, stuff Interfaces usermode with lv1 for stuff like page mappings etc 

Many restrictions are placed here (i believe W^X, among other things) accesses lv1 via ???? 

-> lv1 access is via hvsc / .long 0x44000022 

lv2 has direct access to slb, but not to tlb/htab. It can set/modify htab entries via syscalls 

=== usermode ===
accesses lv2 via syscalls (sc opcode) 

actual app logic, stuff has limited hardware access via lv2 

Interesting: seems to have fairly low level access to rsx (direct FIFO), probably syscalls are used to setup registers and stuff 




=== Interesting Links ===
http://www.linux-kvm.org/page/PowerPC_Hypercall_ABI 

http://xorloser.com 

http://wiki.ps2dev.org/ps3:hypervisor 

Retrieved from "http://ps3wiki.lan.st/index.php/Drk_notes"