My guess is that 0x8000000000000000 is only a mapping so that applications can make calls into kernel space (since they see 0x00000000 - 0xffffffff as their own private address space).
If you don't rebase it to 0x8000000000000000 all the interrupt vectors are where they're supposed to be (0x100, 0x200, ...). Take a look at the system reset interrupt vector at 0x100 - that should give away the entry point.
Probably you're right but there are full addresses (not only offsets) in the dump.
For example at 02cff60: there is a string and pointer to this string is stored at at 33f830: as 80 00 00 00 00 00 2c ff 60. It does not seem to be a stack though. As this is a dump of a runnign OS the addresses migth me different if any of it happens to be a stack or heap. BTW: do you have any idea where the stack is? The dump ends with 0s so it's definitely not at the very end.
And at 3000: you can find similar pointers.
Last edited by emsi; 09-25-2010 at 11:44 AMReason: Automerged Doublepost
The hypervisor is definitely mapped in at 0x8000000000000000, although when disassembling, I've found it much easier to assume it's at 0x0 because the addresses are much more manageable.
The gameos lv2 syscall vector is at 0xc00. Looking at that code is quite instructive; it first jumps to 0x8000000000000c2c. It then stores 0x800000000028f9c0 in SRR0, or's the MSR with 0x30 and stores that in SRR1 and does a return from interrupt. The effect of that is to ensure the instruction and data translation is still valid and to jump to the main syscall handler. Start looking from there.
Oh yeah, and there are multiple stacks as there are multiple threads running. They start from 0x8000000010000000.
Currently on jaibroken PS3 do we have access to LV2 memory only or LV1 as well? It would seem to me that if it was possible to add new syscalls and overwrite existing ones we have read/write access to LV1 as well. Is that correct? The payload the overflows heap runs in what context? Is it run as part of LV1 or LV2? I would assume LV1 as that's where I assume (USB and other) devices are handled...
Could you please elaborate a bit? Why LV1 access would not really be of interest?
If you want LV1 access, you can already get it via geohot's hack from otheros. If you can read/write LV1 memory at will, you can't really do anything more than you could if you gain LV1 access from gameos.
And at the end of the day, you'll still need to open up the PS3 and start soldering to do it, which means it's never going to be a mainstream thing like the current LV2 hack is.
With the current hack, we already have potentially full access to the system, so hacking LV1 at this point doesn't gain us anything else.
Personally, now I can write homebrew stuff and have it installable on anyone's PS3 (assuming future firmware versions are hacked too), I've got no real interest in LV1. I guess some people would be interested in it still though!
Only problem otheros isn't running on a jailbroken PS3 yet.. and sony may have removed the kernel hooks to allow otheros running at all as is.
Would not lv1 allow patching of the kernel on the fly allow getting around various checks (e.g. PSN access - which is currently vetted thru gameos) and in fact running of an entire new kernel directly.. e.g. a linux bootloader outside Sony's otheros method ?