Sponsored Links

Sponsored Links

Page 4 of 5 FirstFirst ... 2345 LastLast
Results 31 to 40 of 42



  1. #31
    Contributor emsi's Avatar
    Sponsored Links
    Sponsored Links
    Quote Originally Posted by sapperlott View Post
    Don't forget to specify the endianness - you might get unexpected results otherwise.

    The ppu-lv2-objdump supports Cell:PPU as architecture. So this would be the way to disassemble PPE memdumps with ppu-lv2-objdump:
    ppu-lv2-objdump -b binary -m Cell:PPU -EB -D <file.bin> > <file.asm>
    I got it. Thank you. Do you know what is the entry point for the gameOS?

    BTW: adding --adjust-vma=0x8000000000000000 might be helpful.

  2. #32
    Contributor sapperlott's Avatar
    Sponsored Links
    Sponsored Links
    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.

  3. #33
    Contributor emsi's Avatar
    Sponsored Links
    Sponsored Links
    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 AM Reason: Automerged Doublepost

  4. #34
    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.

  5. #35
    Few questions I have (sorry if sound stupid):

    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...

    Anyone care to explain more?

  6. #36
    Quote Originally Posted by RexVF5 View Post
    Currently on jaibroken PS3 do we have access to LV2 memory only or LV1 as well?
    It runs in LV2. In theory, you could use geohot's exploit to hack LV1 from gameos, but there's probably not really any point.

  7. #37
    Quote Originally Posted by tragedy View Post
    It runs in LV2. In theory, you could use geohot's exploit to hack LV1 from gameos, but there's probably not really any point.
    Could you please elaborate a bit? Why LV1 access would not really be of interest?

  8. #38
    Quote Originally Posted by RexVF5 View Post
    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!

  9. #39
    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 ?

  10. #40
    Quote Originally Posted by p666 View Post
    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.
    Every Lv-1 guest uses the same hypercall interface so Linux should run just fine inside the GameOS Lv-2 partition. In fact, marcan42 is working on just that right now.

 
Sponsored Links

Page 4 of 5 FirstFirst ... 2345 LastLast
Advertising - Affiliates - Contact Us - PS3 Downloads - PS3 Forums - Privacy Statement - Site Rules - Top - © 2015 PlayStation 3 News