Originally Posted by DarkNeo
It sets bits 32-47 (note on ppc bits are numbered MSB 0, LSB 63). I'll explain the most common idiom used in the shellcode:
li %r31, 1
rldicr %r31, %r31, 63,0 #r31 = 0x8000 0000 0000 0000
mr %r3, %r31
oris %r3, %r3, 5 # r3 = 0x8000 0000 0005 0000
ori %r3, %r3, 0xB3C # r3 = 0x8000 0000 0005 0b3c
mr %r4, %r31
oris %r4, %r4, 0x70 # r4 = 0x8000 0000 0070 0000
ori %r4, %r4, 0x1AC # r4 = 0x8000 0000 0070 01ac
The shellcode actually looks quite well written (although shows hallmarks of being partially produced with a compiler). I've basically got a good handle now on how it all works, although I've not got an lv2 dump so some of it's guesswork. e.g. at offset 0xc4, there's a call to 0x800000000007c01c which I think is memcpy, but I'm just assuming that for now.
For disassembly tips, 0x12-0x80 is PIC code, entry r3=start of file+0x1000.
0x80-0x1ac add offset 0x8000000000700000 to start of file
0x1ac-0x6f0 add offset 0x8000000000050990 to start of file.
If you can get your head around the various relocations the code undergoes, it's fairly easy code to follow.
Originally Posted by Karl69
This is a standard prologue for a stack frame - it's saving registers on the stack.
But then there is also "absolute" coding like this:
150: 00 04 90 e0 .long 0x490e0
154: e8 82 0f 08 ld r4,3848(r2)
158: 00 04 90 e4 .long 0x490e4
15c: e8 7c 00 20 ld r3,32(r28)
160: 00 04 90 e8 .long 0x490e8
164: f8 64 00 00 std r3,0(r4)
168: 00 04 f0 a8 .long 0x4f0a8
The values after .long are probably addresses which are firmware dependent and would have to be changed depending on the FW version. Again I am guessing here...
Spot on. This table (terminated by .long 0) is a table of addresses to which 0x8000000000000000 is added and then patched by the next 4 bytes (helpfully easily disassembled). You'll see the 3 instructions that get written here are sequential.