PowerPC 64-bit API :)

[sectroyer]

Hi there was some suggestion about creating API (puts,gets) and other stuff. So it would be possible to just create programs in pure C and then compile them to PowerPC 64-bit format. I think this is something that some of as (those who doesn't have an access to vulnerable hardware (me i.e.)) could do. I would
like to open discussion about this issue. What emulator would be best for doing this? Or maybe we should just use gcc and dissassemble our files without trying to run them in any way?

[tinkerer15khz]

if someone did this they could include an ethernet and tcp/ip driver as an easier way to send programs over. though the linux will be out soon and supposed to have ethernet driver among other things. Im curious how the linux distro will map the ram in the 360.

[sectroyer]

I am in the process of creating c implentations of basic functions for serial port comuncation. My proposal is to implement functions: getchar,putchar,puts,gets and write/read (for binary transfer). I would like to everyone to make their requests in this topic.

[aholmes187]

hey that sounds like it  handy tool sectroyer, nice idea. props, i was feeling the same w/o having a box with the correct kernel yet.

[sectroyer]

I tried contacting TheSpecialist about this idea we'll see what he thinks about it. I don't have vulnerable box myself so I would be grateful if someone that has one would contact me so it would be possible to test some functions before realeassing it

[zillionare]

post it up....the test file. I'm sure everyone that has an E360 will gladly download it and test it for you then reply back. 

peace,
zil

[Takires]

I would suggest using the libgcc and modifying it rather than trying to create a library from scratch.

[sectroyer]

I have first problem
How to force gcc not to assume that r2 points to toc section

[sectroyer]

We cannot use "libgcc" (I think you mean libstd ) beacuse it uses linux kernel and we don't have linux kernel in xbox 360 by default

Look at this code:

Code:

void foo(char *p)
{
unsigned long *a;
a=0x112233445566;
*a=0x778899aabbccddeeff;
}
void bar()
{
unsigned long *p;
p=0x8000000000000000;
*p=0x123456;
ala(p);
}

[sectroyer]

GCC compiles it to this:
   .file   "test1.c"
   .section   ".toc","aw"
   .section   ".text"
   .section   ".toc","aw"
.LC0:
   .tc ID_1122_33445566[TC],0x112233445566
.LC1:
   .tc ID_8899aabb_ccddeeff[TC],0x8899aabbccddeeff
   .section   ".text"
   .align 2
   .globl foo
   .section   ".opd","aw"
   .align 3

[sectroyer]

foo:
   .quad   .L.foo,.TOC.@tocbase,0
   .previous
   .type   foo, @function
.L.foo:
   std 31,-8(1)
   stdu 1,-80(1)
   mr 31,1
   std 3,128(31)
   ld 0,.LC0@toc(2)
   std 0,48(31)
   ld 9,48(31)
   ld 0,.LC1@toc(2)
   std 0,0(9)
   ld 1,0(1)
   ld 31,-8(1)
   blr
   .long 0
   .byte 0,0,0,0,128,1,0,1
   .size   foo,.-.L.foo
   .align 2
   .globl bar
   .section   ".opd","aw"
   .align 3

[sectroyer]

bar:
   .quad   .L.bar,.TOC.@tocbase,0
   .previous
   .type   bar, @function
.L.bar:
   mflr 0
   std 31,-8(1)
   std 0,16(1)
   stdu 1,-144(1)
   mr 31,1
   li 0,-1
   rldicr 0,0,0,0
   std 0,112(31)
   ld 9,112(31)
   lis 0,0x12
   ori 0,0,13398
   std 0,0(9)
   ld 3,112(31)
   bl ala
   nop
   ld 1,0(1)
   ld 0,16(1)
   mtlr 0
   ld 31,-8(1)
   blr

[sectroyer]

as we can see for instance line    ld 0,.LC0@toc(2) loads to r0 value 0x112233445566 from toc section. When we upload the blob the r2 points to uknow memory location so there are two solutions. First force gcc in some way to not use toc section at all. Second manualy find correct value for r2 at the begining of code (some init function) and then continue the execution. I waiting for suggestions about this matter. Sorry for putting it in so many posts but I had problem with posting wich even resulted in ip banning

[Takires]

The reason for having a toc section is to avoid absolute addressing. Its the job of the loader to set r2 to the correct value. You should be able to use the linkcmds file to generate a symbol at the start of the toc section which can be referenced by an init function.

[sectroyer]

Okay so I would like to hear more info about this linkcmds file
Please take a look at this dissassembly of my example:
ld      %r0,-0x8000(%r2)
ld      %r0,-0x7FF8(%r2)
This to instructions load LC0 and LC1 from previous posts.
So if I understand correctly This load to r0 the 64bit value from address r2-0x8000.
Since L0 is first thing in toc section does this mean that r2 points to the end of toc section of size 0x8000?

[Takires]

The powerpc abi defines r2 as start of toc section + 0x8000. Then r2 with a 16 bit displacement can address 64k of memory.
Source: http://www.linux-foundation.org/spec/ELF/ppc64/PPC-elf64abi-1.9.html

The linkcmds file (or also known as linker script) is a text file that specifies how the segments are to be laid out.
Example: http://www.davehylands.com/avi/linker_scripts.htm

The example is for a m68k cpu, it shows a startup code that clears the uninitialised data section (.bss).

[sectroyer]

Thanks for the info about toc section, it really clears few things. About linkcmds since it is linker script than again we may not be able to use it When we hexdump blob we are able to see that toc section is just after text one so We can use code like this:

call 1
1:
pop eax
2:
inc eax
cmp eax,som value (i.e. 0x1234556789ABCDEF)
jne 2
mov r2,eax

Of course this is pseudo code and uses x86 instructions. I wanted only to explain the idea But there is another problem with using toc section. At the end of the blob file we have to put 16*x. This is the way in which loader recognises the enf of transfer. Of course we could compile the blob and then do something like this: echo "16*x" >> ./blob but I wanted to find a way to compile this into the blob. Any suggestions about it?

[sectroyer]

I analized your information about this script clearing the bss section. It seems not helpful since this script is part of executable and it's run just before main function. We can use to put some value at the begining of the toc section and then use it to find correct value for r2 but it will not help with 16*x problem At this moment adding some instruction at the begining of the code:

unsigned long *unused
unused=0x1122334455667788;

and then doing echo "16*x" >> ./blob seems the best and easiest way but feel free to suggest another aproach

[sectroyer]

Here is my first version of init function. I am sure it is full of bugs, so feel free to fix
It's basic task is to find the location of 0x1122334455667788 in the memory(which is the begining of toc section) by using call/pop trick used in exploits. This is my first PowerPC64 code and I don't want anyone to test it unless someone with correct knowledge will fix it

void init()
{
    unsigned long *toc;
    asm(
        "bl get_r2;"
        "get_r2:;"
        "lis %r12,0x1122;"
        "li %r12,0x3344;"
        "rldicr %r12,%r12,32,31;"
        "lis %r12,0x5566;"
        "li %r12,0x7788;"
        "ld %r10,-64(%r31);"
        "subi %r31,%r31,64;"
        "find_r2:;"
        "addi %r10,%r10,1;"
        "ld %r11,0(%r10);"
        "cmpd %r11,%r12;"
        "bne find_r2;"
        "addi %r10,%r10,0x7000;"
        "addi %r10,%r10,0x1000;"
        "mr %r2,%r10;"
    );
    toc=(unsigned long *)0x1122334455667788;
}

[sectroyer]

First bug spotted

"ld %r10,-64(%r31);"
"subi %r31,%r31,64;"

Of course it should be:

"ld %r10,-8(%r31);"
"subi %r31,%r31,8;"