Sponsored Links

Sponsored Links

Page 1 of 2 12 LastLast
Results 1 to 10 of 20



  1. #1
    Forum Moderator PS3 News's Avatar
    Join Date
    Apr 2005
    Posts
    27,852
    Sponsored Links

    PS3 Hypervisor Reverse Engineering Progress is Detailed

    Sponsored Links
    A few days ago we reported on graf_chokolo's progress in decrypting PS3 Firmware 3.50, and today he has made available to the PlayStation 3 Wiki (linked above) his PS3 hypervisor reverse-engineering work to date, as follows:

    HSPRG
    The hypervisor stores a pointer to some structure per LPAR in HSPRG0 register. There are actually 2 HSPRG0 values: one for each thread of Cell CPU !!! There is a HSPRG0 array at 0x8(-0x69A0(HSPRG0)) + 0x20.

    LPAR
    LPAR = Logical Partition

    lpar1 starts at 0x<unknown>, and its believed to be the memory space wherre lv1 stores its variables, flags and other data.
    lpar2 starts at 0x80000000000 and it's believed to be the memory space where lv2 stores its variables, flags and other data.

    The pointer to active LPAR is stored at -0x67E8(HSPRG0).

    vtable
    0x0033CA40 (3.15)

    Member variables
    offset 0x38 - some pointer
    offset 0x50 - LPAR id (8 bytes)
    offset 0x70 - pointer to VAS id bitmap
    offset 0x78 - power of 2 of word size from VAS id bitmap (4 bytes), equal to 6
    offset 0x7C - number of 64-bit words in VAS id bitmap(4 bytes)

    Interrupt handling
    The pointer to the interrupt handler that is called e.g. when an external interrupt occurs is at -0x69F0(HSPRG0).

    0x00001930 (3.15 and 2.60)

    Interrupt vector tables
    There are 2 interrupt vector tables. One for each thread. The pointer to these tables is at -0x6950(HSPRG0).

    offset 0x8 - IIC memory base address (8 bytes)
    offset 0x10 - thread register offset (8 bytes)
    offset 0x18 - start of interrupt vector table (19 entries, each entry 32 bytes)

    Interrupt vector table entry
    offset 0x0 - pointer to interrupt handler
    offset 0x8 - TOC
    offset 0x10 - 0
    offset 0x18 - parameter to interrupt handler

    Interrupt handlers
    Spurious interrupt handler
    0x002BC174 (3.15)

    RSX
    0x00219A44 (3.15)
    0x002176FC (2.60)

    SB bus
    0x002B9CC4 (3.15)

    I/O address translation
    0x002CD7D8 (3.15)
    0x002C9214 (2.60)

    Performance monitor
    0x002F0584 (3.15)
    0x002EB1B0 (2.60)

    Token manager
    0x002BBA9C (3.15)
    0x002B754C (2.60)

    HV call
    The address of HV table is stored at -0x6FC8(HSPRG0).
    The address of HV table size is stored at -0x6FD0(HSPRG0).

    HV call

    Name Description
    lv1_undocumented_function_62 SPE (isolation, it updates a SLB entry, writes to SLB_Index, SLB_VSID, SLB_ESID and SLB_Invalidate_Entry registers)
    lv1_undocumented_function_89 SPE (writes to MFC_TLB_Invalidate_Entry register)
    lv1_undocumented_function_99 SPE (isolation, syscall 0x10043, syscall 0x10042, syscall 0x1004A)
    lv1_undocumented_function_102 Returns current TB ticks
    lv1_undocumented_function_137 SPE
    lv1_undocumented_function_138 SPE
    lv1_undocumented_function_167 SPE (isolation, reads from SPU_Out_Intr_Mbox and MFC_CNTL registers)
    lv1_undocumented_function_168 SPE (isolation, writes to MFC_CNTL register)
    lv1_undocumented_function_195 WLAN Gelic device
    lv1_undocumented_function_196 WLAN Gelic device
    lv1_undocumented_function_200 SPE (isolation)
    lv1_undocumented_function_201 SPE (isolation)
    lv1_undocumented_function_209 SPE (isolation)
    lv1_undocumented_function_250 Storage device
    lv1_undocumented_function_251 Storage device
    lv1_undocumented_function_252 Storage device
    lv1_undocumented_function_253 Storage device
    Memory HV call
    All memory HV calls branch to lv1_mm_call
    lv1_mm_call has it's own function table
    Memory HV call number = HV call number

    Memory HV call table
    Each entry is a pointer to a function TOC entry.
    table size = 256
    0x00364208 (3.15)

    Memory HV calls
    lv1_map_htab - 0x002D595C (3.15)
    lv1_unmap_htab - 0x002D56B8 (3.15)
    lv1_allocate_memory - 0x002D72F0 (3.15)
    lv1_release_memory - 0x002D66A4 (3.15)
    lv1_query_logical_partition_address_region_info - 0x002C9B24 (3.15)
    lv1_create_repository_node - 0x002DD014 (3.15)
    lv1_get_repository_node_value - 0x002DD260 (3.15)
    lv1_undocumented_function_231 - 0x0030B560 (3.15)

    System call
    HV Processes do not use HV calls. They use syscalls only.

    System call handler
    0x002974D8 (3.15)
    0x00292F6C (2.60)

    There are 2 system call tables in HV. The first one stores system calls 0 - 36. The second one stores system calls 0x10000 - 0x100FF.

    System call table 0 - 36
    0x0035FAE8 (3.15)

    0x00358ED0 (2.60)

    System call numbers
    0x1 - getpid(void)
    0x2 - getppid(void)
    0x3 - fork(void)
    0x4 - exit
    0x5 - exec(filename)
    0x6 - wait(status)
    0x7 - open(filename)
    0x8 - close(fd)
    0x9 - read
    0xA - write
    0xB - seek
    0xC - unlink(filename)
    0xD - signal
    0xE - kill(pid, signal type)
    0xF - brk
    0x10 - socket(af, type, protocol) (supports only address family 0x1F, type 0x0 and protocol 0x0)
    0x11 - bind
    0x12 - listen(fd, backlog)
    0x13 - accept
    0x14 - connect
    0x15 - ?
    0x16 - pause(void)
    0x17 - sleep(seconds)
    0x18 - mmap(addr, size, prot, flags, fd, offset)
    0x19 - munmap
    0x1A - some fs func for directories, perhaps readdir
    0x1B - ?
    0x1C - map_pages (used for alloc)
    0x1D - unmap_pages (used for free)
    0x1E - select
    0x1F - getcwd
    0x20 - ?
    0x21 - alarm
    0x22 - ioctl
    0x23 - _map_pages
    0x24 - _unmap_pages

    System call table 0x10000 - 0x100FF
    0x0035DE78 (3.15)
    0x00357260 (2.60)

    System call numbers
    0x10000 - allocate_memory_region(LPAR id, size, log2 of page size, ?, ?)
    0x10001 - lpar_query_address_region_info
    0x10002 - lpar_memory_addr_to_phys_addr(LPAR id, LPAR address, physical addr)
    0x10005 - construct_logical_pu
    0x10007 - activate_logical_pu(LPAR id, PPE id)
    0x10009 - construct_logical_partition(0, LPAR id, outlet)
    0x1000E - release_memory_region(LPAR id, memory region address)
    0x1001A - construct_event_receive_port
    0x10024 - shutdown_logical_partition(LPAR id, shutdown command)
    0x10025 - destruct_logical_partition(LPAR id)
    0x10026 - get_logical_partition_info
    0x1002C - construct_scheduling_table
    0x1002D - set_scheduling_slot
    0x10032 - accesses system console
    0x10036 - accesses system console
    0x10040 - construct_spe_type_1(SPE id, shaddow_addr)
    0x10041 - destruct_spe(SPE id)
    0x10042 - decrypt_lv2_self(spe id, LPAR auth id, SELF file image ptr, LPAR memory address)
    0x10043 - load_spe_module(spe id, SCE module ptr, arg1, arg2, arg3, arg4)
    0x10044 - disable_spe_execution
    0x10045 - set_spe_interrupt_mask
    0x10046 - read_spe_problem_state_register(spe id, register offset, value)
    0x10047 - write_spe_problem_state_register(spe id, register offset, value)
    0x1004B - disable_spe_loading
    0x10053 - pmi_set_guest_os_mode
    0x10081 - accesses system console
    0x10084 - construct_virtual_uart(LPAR id, VUART id, VUART data buffer size)
    0x10085 - destruct_virtual_uart(LPAR id, VUART id)
    0x10088 - RSX_syscall_10088(LPAR id)
    0x10089 - RSX_syscall_10089
    0x1008A - RSX_syscall_1008A
    0x100BE - lv1_ioctl
    0x100C0 - create_repository_node(LPAR id)
    0x100C1 - get_repository_node_value(LPAR id)
    0x100C2 - modify_repository_node_value(LPAR id)
    0x100C3 - remove_repository_node_value(LPAR id)

    Process

    Process table
    HV supports only 32 processes simultaneously. The number of processes currently running in HV is stored at address 0x0035EA54 (3.15) and 0x00357E3C (2.60).

    The process table is an array of 32 process table entries.

    0x0035E850 (3.15)

    0x00357C38 (2.60)

    Process table entry
    offset 0x0 - process status ? (8 bytes)
    offset 0x8 - pointer to Process object

    create_new_proc
    This function creates a new Process object.

    0x00298E2C (3.15)
    0x002948BC (2.60)

    Parameters
    r3 - pointer to parent Process object
    r4 - ?

    copy_user_data
    This function copies data to/from user space.

    0x00299688 (3.15)
    0x00295118 (2.60)

    Parameters
    r3 - pointer to Process object
    r4 - some address in address space of Process
    r5 - pointer to buffer in HV space
    r6 - size to copy
    r7 - ?
    r8 - direction of copy (0 - copy from user space, != 0 - copy to user space)
    r9 - ?

    vtable
    Processes have no vtables. That means they have no virtual functions.

    Member variables
    offset 0x0 - PID (4 bytes)
    offset 0x8 - pointer to parent Process object
    offset 0x10 - pointer to AddressSpace object
    offset 0x30 - pointer to first PThread object of process
    offset 0x38 - array of signal handlers (192 * 8 bytes)
    offset 0x638 - pointer to pointer to ELF image
    offset 0x640 - start of file table (20 * 24 bytes)
    offset 0x820 - exit status (4 bytes)
    offset 0x898 - pointer to Inode object of current directory
    offset 0x8A8 - some pointer

    Signals
    A process can have upto 192 signal handlers. For example, signal 9 is SIGKILL. A signal handler for SIGKILL cannot be installed and it cannot be ignored.

    A process does not have a signal mask. Every thread of a process has it's own signal mask.

    Signal constants
    0x9 - SIGKILL
    0xE - SIGALRM
    0x20 - SIGSPUMB
    0x21 - SIGSPUMB_SL
    0x22 - SIGSPUSTOP
    0x23 - SIGSPUSTOP_SL
    0x24 - SIGSPUDMA
    0x26 - SIGSPUTIMEOUT
    0x27 - SIGSPUERR
    0x41 - SIGSHUTDOWN

    File table
    The file table has 20 entries. So, a process can have at most 20 files opened simultaneously. Each entry is 24 bytes large.

    offset 0x0 - entry valid or invalid (1 byte), 0 - invalid, 1 - valid
    offset 0x8 - pointer to object with File interface
    offset 0x10 - current file position (8 bytes)

    Process_EA_to_RA
    This function translates an effective process address to real address.

    0x00297E08 (3.15)

    Objects
    Here are the addresses of Process objects i could identify in HV dump 3.15:

    0x006BB0D0 (PID 0)
    0x0012C010 (PID 3) - ss_server3.fself
    0x000915D0 (PID 5) - ss_server2.fself
    0x000E4D70 (PID 6) - ss_server1.fself
    0x0012C8D0 (PID 9) - sysmgr_ss.fself

    Here are the addresses of Process objects i could identify in HV dump 2.60:

    0x006B7580 (PID 0)
    0x00135F90 (PID 3)
    0x000862D0 (PID 5)
    0x000A9870 (PID 6)
    0x00084B80 (PID 9)

    PThread
    All PThread objects of the same Process object are linked together in a list.

    vtable
    0x003556D8 (3.15)
    0x0034ECC0 (2.60)
    offset 0x60 - pointer to TOC entry of system call handler

    Member variables
    offset 0x10 - pointer to next PThread object of Process
    offset 0x18 - Thread object
    offset 0x2B8 - ? (4 bytes)
    offset 0x2C0 - pointer to TOC of some function
    offset 0x2C8 - pointer to TOC of some function
    offset 0x348 - some conter (4 bytes)
    offset 0x3C0 - pointer to Process object that owns PThread object
    offset 0x3F8 - signal pending mask (3 * 8 bytes = 192 signals)
    offset 0x440 - ConditionVariable object

    Signals
    A PThread has it's own signal mask, independant of all other PThreads in the same process.

    Methods
    wait_for_my_turn(Pthread ptr, ?, sleep interruptible flag) = wakeup status - 0x00296FB0 (3.15)

    Thread
    get_current_thread
    This function returns the pointer to current running thread.

    0x0028B994 (3.15)
    0x0028744C (2.60)

    vtable
    0x00355750 (3.15)

    Member variables
    offset 0x288 - some pointer
    offset 0x290 - some pointer

    AddressSpace

    vtable
    0x003549A0 (3.15)
    0x0034DF88 (2.60)

    Member variables
    offset 0x8 - Mutex object
    offset 0x40 - AddressProtectionDomain object
    offset 0x50 - some pointer
    offset 0xC0 - some counter (4 bytes)

    AddressSpace_EA_to_RA
    0x002874D0 (3.15)

    AddressProtectionDomain
    vtable
    0x00354980 (3.15)

    Member variables
    offset 0x8 - pointer to previous AddressProtectionDomain object
    offset 0x10 - pointer to next AddressProtectionDomain object
    offset 0x18 - poiinter to pointer to SLB entries
    offset 0x20 - pointer to AddressSpace object that owns this object
    offset 0x34 - pointer to previous ProtectionPage
    offset 0x3C - pointer to next ProtectionPage
    offset 0x48 - Mutex object

    ProtectionPage

    vtable
    none

    Member variables
    offset 0x0 - RA (8 bytes)
    offset 0x8 - EA (4 bytes)
    offset 0x10 - pointer to previous ProtectionPage (4 bytes)
    offset 0x14 - pointer to next ProtectionPage (4 bytes)

    Mutex
    vtable
    0x00354D08 (3.15)
    0x0034E2F0 (2.60)

    Member variables
    offset 0x18 - ? (4 bytes)
    offset 0x1C - ? (4 bytes)

    ConditionVariable
    vtable
    0x003549C0 (3.15)
    offset 0x20 - wait

    Member variables
    offset 0x20 - pointer to Mutex object

    File interface

    vtable
    offset 0x8 - ?
    offset 0x28 - open
    offset 0x30 - close
    offset 0x38 - read
    offset 0x40 - write
    offset 0x50 - mmap
    offset 0x58 - ioctl

    StorageRegionFile
    Flash device file class.

    vtable
    0x003569F8 (3.15)

    VUARTFile
    VUART device file class.

    vtable
    0x00356458 (3.15)

    STDLCFile
    Console device file class.

    vtable
    0x003561F8 (3.15)

    Member variables
    offset 0x20 - reference counter (8 bytes)
    offset 0x28 - free buffer space ? (8 bytes)

    SocketFile

    vtable
    0x00355DB0 (3.15)
    offset 0xB0 - bind

    RegionManager

    vtable
    0x00355F80 (3.15)

    Inode
    DirectoryInode
    vtable
    0x00355788 (3.15)
    offset 0x20 - link
    offset 0x28 - unlink

    get_root_inode
    This function returns the pointer to the Inode object of the root directory.

    0x0029C124 (3.15)
    0x00297BB4 (2.60)

    vtable
    0x00334E50 (3.15)
    offset 0x30 - lookup

    File system
    Console device file objects
    Here is the list of console device file objects i found in HV dump 3.15:

    console
    vtable
    0x003561F8 (3.15)

    Flash device file objects
    Here is the list of flash device file objects i found in HV dump 3.15:

    /dev/eflash0
    /dev/eflash1
    /dev/rflash0
    /dev/rflash1
    /dev/rflash_1x
    /dev/rflash_1xp
    vtable
    0x003569F8 (3.15)

    IOIF device file objects
    Here is the list of IOIF device file objects i found in HV dump 3.15:

    /dev/ioif0
    vtable
    0x00356688 (3.15)

    Member variables
    0x360 = MMIO base address

    SD detector device file objects
    Here is the list of SD detector device file objects i found in HV dump 3.15:

    /dev/sd_detector
    vtable
    0x00356B48 (3.15)

    NET device file objects
    Here is the list of NET device file objects i found in HV dump 3.15:

    /dev/net0
    vtable
    0x00356DE8 (3.15)

    INODES
    INODE OBJECT

    +0x04: previos inode
    +0x08: next inodes
    + 0x38: path
    + 0x358: childer_inode

    MFS_ROOT_INODE

    (2.60) 0x3580B0
    + 0x60 = ROOT_INODE

    SOME ADDRESSES IN 2.60

    0x60C010: "/dev" inode
    0x6AA580: "/proc" inode

    using linked list you can follow all inodes

    Repository
    Each LPAR has it's own node repository
    Repository nodes are stored in a hash table which can have several sub-hash tables.

    RepositoryNode
    vtable
    0x00357F58 (3.15)

    Member variables
    offset 0x30 - pointer to next RepositoryNode obj
    offset 0x38 - 2nd hash value of name (4 bytes)
    offset 0x40 - 1st field name (8 bytes)
    offset 0x48 - 2nd field name (8 bytes)
    offset 0x50 - 3rd field name (8 bytes)
    offset 0x58 - 4th field name (8 bytes)
    offset 0x60 - ? (4 bytes)
    offset 0x68 - 1st field value (8 bytes)
    offset 0x70 - 2nd field value (8 bytes)

    Hash Function
    The name of a repository node is hashed and 2 hash values (2 32bit values) are produced.
    The 1st hash value is used to select a sub-hash table.
    The 2nd hash value is used to find a sub-hash table bucket.
    Repository nodes in a hash bucket are ordered by the 2nd hash value.

    [Register or Login to view code]

    Dump of all repository nodes from HV 3.15

    [Register or Login to view code]

    Buses

    SB bus
    type - 4
    index - 1

    num_devices - 4 (repository node says this but there are more devices !!!)

    Storage bus
    type - 5
    index - 4
    num_devices - 4

    SB bus subsystem
    vtable
    0x00352600 (3.15)

    Member variables
    offset 0x10 - MMIO memory base address

    offset 0x20 - array of 16 pointers to SB devices (0 - Gelic device, 1 - USB device)

    Objects
    0x00349528 - pointer to pointer to SB bus subsystem object

    Memory base address
    0x24000000000

    All SB bus device MMIO addresses are relative to this memory address.

    SB device MMIO/DMA memory region
    vtable
    0x000x352308 (3.15)

    Member variables
    offset 0x18 - pointer to previous bus memory region object
    offset 0x20 - pointer to next bus memory region object
    offset 0x30 - relative bus memory start address
    offset 0x38 - size of bus memory region

    SB bus device
    vtable
    0x00352620 (3.15)

    Member variables
    offset 0x18 - array of pointers to MMIO memory region objects owned by device (8 * 8 bytes)
    offset 0x60 - pointer to first DMA region object
    offset 0x6C - device opened flag (1 byte, 0 - not opened, 1 - already opened)
    offset 0x70 - id of LPAR that opened this device
    offset 0x90 - pointer to an object that contains the address of interrupt handler for this device and SB bus interrupt index

    Gelic device (Network Interface)
    device id = 0
    interrupt index = 8

    MMIO regions
    Index Relative Bus Start Address Absolute Bus Start Address Size
    0 0x2800 0x24000002800 0x200
    1 0x3004000 0x24003004000 0x1000
    2 - - -
    3 - - -
    4 - - -
    5 - - -
    6 - - -
    7 - - -
    DMA regions
    Relative Bus Start Address Absolute Bus Start Address Size
    0xA0000000 - 0x8000
    0xC0000000 - 0x10000000
    SATA Controller 1 device
    device id = 1
    interrupt index = 49

    MMIO regions
    Index Relative Bus Start Address Absolute Bus Start Address Size
    0 0x2000 0x24000002000 0x200
    1 0x3000000 0x24003000000 0x1000
    2 0x3800000 0x24003800000 0x1000
    3 0x3802000 0x24003802000 0x1000
    4 - - -
    5 - - -
    6 - - -
    7 - - -
    DMA regions
    Relative Bus Start Address Absolute Bus Start Address Size
    0xA0000000 - 0x1000
    0xA0001000 - 0x1000
    0xA0002000 - 0x1000
    SATA Controller 2 device
    device id = 2
    interrupt index = 13

    MMIO regions
    Index Relative Bus Start Address Absolute Bus Start Address Size
    0 0x2200 0x24000002200 0x200
    1 0x3001000 0x24003001000 0x1000
    2 0x3801000 0x24003801000 0x1000
    3 0x3803000 0x24003803000 0x1000
    4 - - -
    5 - - -
    6 - - -
    7 - - -
    DMA regions
    Relative Bus Start Address Absolute Bus Start Address Size
    0xA0000000 - 0x1000
    0xA0001000 - 0x1000
    0xA0002000 - 0x1000
    USB Controller 1 device
    device id = 3

    MMIO regions
    Index Relative Bus Start Address Absolute Bus Start Address Size
    0 0x2400 0x24000002400 0x200
    1 0x3010000 0x24003010000 0x10000
    2 0x3810000 0x24003810000 0x10000
    3 - - -
    4 - - -
    5 - - -
    6 - - -
    7 - - -
    DMA regions
    Relative Bus Start Address Absolute Bus Start Address Size
    0xC0000000 - 0x10000000
    0xD0000000 - 0x10000000
    USB Controller 2 device
    device id = 4

    MMIO regions
    Index Relative Bus Start Address Absolute Bus Start Address Size
    0 0x2600 0x24000002600 0x200
    1 0x3020000 0x24003020000 0x10000
    2 0x3820000 0x24003820000 0x10000
    3 - - -
    4 - - -
    5 - - -
    6 - - -
    7 - - -
    DMA regions
    Relative Bus Start Address Absolute Bus Start Address Size
    0xC0000000 - 0x10000000
    0xD0000000 - 0x10000000
    ENCDEC device
    device id = 7
    interrupt index = 5

    MMIO regions
    Index Relative Bus Start Address Absolute Bus Start Address Size
    0 0x2C00 0x24000002C00 0x200
    1 0x3005000 0x24003005000 0x1000
    2 0x3006000 0x24003006000 0x1000
    3 - - -
    4 - - -
    5 - - -
    6 - - -
    7 - - -
    DMA regions
    Relative Bus Start Address Absolute Bus Start Address Size
    0x80010000 - 0x10000
    0x80004000 - 0x4000
    0x80001000 - 0x1000
    0x80003000 - 0x1000
    0x80008000 - 0x1000
    0x80009000 - 0x1000
    0x80040000 - 0x10000
    0x8000A000 - 0x1000
    0x90020000 - 0x20000
    0xC0000000 - 0x10000
    0xC0040000 - 0x40000
    FLASH Controller device (StarShip - SS)
    device id = 9
    interrupt index = 41

    MMIO regions
    FLASH controller doesn't have MMIO regions.

    DMA regions
    Relative Bus Start Address Absolute Bus Start Address Size
    0x80000000 - 0x1000
    0x80020000 - 0x20000
    0x80002000 - 0x1000
    0x90000000 - 0x20000
    SB Bus Interrupt Handling
    There is a table of interrupt handlers for SB devices
    The size of table is 64
    The main SB bus interrupt handler is at 0x002B9CC4 (3.15)
    The main interrupt handler reads interrupt index and dispatches interrupts

    Interrupt Index
    The main SB bus interrupt handler reads 2 32-bit values from addresses 0x24000008100 and 0x0x24000008104
    The interrupt index is calculated from these values

    Interrupt Handler Table

    Interrupt Description Address in HV
    5 ENCDEC device 0x00275C60 (3.15)
    6 EH EPCIC internal 0x0023B6B0 (3.15)
    8 Gelic device 0x00245330 (3.15)
    12 ATA interrupt handler 0x0026B984 (3.15)
    13 ATA interrupt handler 0x0026B984 (3.15)
    14 Spider SC 0x0020A68C (3.15)
    29 SBERR 0x0023AA50 (3.15)
    30 SBERR 0x0023AA50 (3.15)
    41 EBUS (Flash StartShip) 0x002814EC (3.15)
    49 ATA media interrupt handler 0x00268A8C (3.15)
    50 Flash ? 0x00280B24 (3.15)
    55 EH EPCIC SERR 0x0023B67C (3.15)
    Storage bus subsystem
    vtable

    0x00353AC8 (3.15)

    Member variables
    offset 0xEE8 - table of pointers to storage device objects (7 * 8 bytes, max 7 devices)

    Storage device class
    Member variables

    offset 0x8 - device id (8 bytes)
    offset 0xD50 - device id (8 bytes)
    offset 0xD60 - pointer to ENCDEC SB bus device object

    Region
    Each storage device can have at most 8 regions (0-7)
    Each region can have ACL
    Each region has a start sector that is an offset from the physical first sector of the storage device
    and a number of sectors

    The start sector passed to lv1 storage hvcalls is relative to the start sector of the region
    passed to the lv1 storage hvcall

    Region Access Protection
    Before a storage region is accessed, HV checks access rights of the caller.
    Repository node ss.laid (LPAR authentication id) is evaluated for this purpose.
    If LPAR has a repository node ios.ata.region0.access (value doesn't matter) then the access rights check never fails.
    ALL storage accesses from LPAR 1 are allowed
    If (flags & 0x100000002) != 0 then access rights check is skipped !!!.

    I tested on HV 3.41 with flags 0x2 and got access to regions which were denied by policy (LV1_DENIED_BY_POLICY result).

    Storage subsystem device
    device id = -1

    The storage subsystem is a storage device itself.
    It's a psuedo device used to notify a LPAR when storage devices become e.g. ready.
    Linux implements a loop and reads from this device and process notifications (adds new devices dynamically).

    Notification Events
    List of supported notification events:

    Notify Device Ready (0x1)
    Notify Region Probe (0x2)
    Notify Region Update (0x4)

    RBD device
    device id = 0

    block size = 2048

    /dev/rbd0

    The RBD storage device uses ENCDEC device.
    vtable
    0x00354288 (3.15)

    Regions
    Index Start sector Number of sectors
    0 0x0 0x7FFFFFFF
    1 - -
    2 - -
    3 - -
    4 - -
    5 - -
    6 - -
    7 - -
    Supported Device Commands
    Here is the list of commands supported by RBD storage device.

    The commands can be used with HV call lv1_storage_send_device_command.
    However, before a command is executed HV does bit manipulation with it and checks it against the value of repository node ss.laid or also called LPAR authentication ID. If this test fails then the command is NOT executed.
    Command Description
    0x81 EdecKgen1
    0x82 EdecKgen2
    0x83 EdecKset
    0x84 EdecKgenFlash
    0x85 -
    0x86 -
    0x87 -
    /dev/rbd0
    This LPAR 1 device accesses RBD storage device.
    A write to this device sends a device command to RBD storage device.

    FLASH device
    device id = 1

    The FLASH device uses ENCDEC device.

    vtable
    0x00354450 (3.15)

    Regions
    Index Start sector Number of sectors
    0 0x0 0x8000
    1 0x8 0x77F8
    2 0x7900 0x100
    3 0x7A00 0x400
    4 - -
    5 - -
    6 - -
    7 - -
    Supported Device Commands
    Here is the list of commands supported by FLASH StarShip 2 storage device.

    The commands can be used with HV call lv1_storage_send_device_command.
    However, before a command is executed HV does bit manipulation with it and checks it against the value of repository node ss.laid or also called LPAR authentication ID. If this test fails then the command is NOT executed.

    Command Description
    0x31 -
    0xA2 -
    0xA3 -
    0xA6 -
    0xA8 -
    0xAC -
    0xAD -
    /dev/eflash1 and /dev/rflash1
    These LPAR 1 devices access region 0 of FLASH storage device.
    /dev/rflash1 is 16MB large
    There is no file system on /dev/rflash1
    There is some sort of TOC (Table Of Contents) stored in it. It contains file names, offsets and sizes.
    On /dev/rflash1 you will find lv0, lv1ldr, lv2_lernel.self and all the other important SELFs.
    The files are encryted of course.

    Content of /dev/rflash1 (FLASH storage device region 0, size 16 MB)
    There is a main TOC which describes different regions on /dev/rflash1
    It seems that TOC 0xC0000 and TOC 0x7C0000 contain the same files but from different SDK versions.
    TOC 0xC0000 is SDK version 3.41 and TOC 0x7C0000 is SDK version 3.30 (look at the content of files sdk_version).
    I guess it's because when i bought my PS 3 Slim it had Firmware 3.30 and i updated it to 3.41 for PSGroove.
    TOC on /dev/rflash1 is used by HV Processes to locate files and load them into memory, e.g. SPU modules. E.g. Process 6 loads spu_utoken_processor.self to decrypt and verify user tokens or SPL which runs in Process 5 loads spp_verifier.self from there in order to decrypt and verify profile files. And Update Manager stores e.g. there files.

    TOC Entry
    A TOC entry is 0x30 bytes large.

    offset 0x0 - relative offset from this TOC to entry data
    offset 0x8 - entry data size
    offset 0x10 - entry name (max 32 characters)

    Main TOC
    Here is a list of regions/files stored on /dev/rflash1 i found in HV 3.41 and dumped with PSGroove:
    Entry Name TOC Offset Entry TOC Index Entry Relative Offset Entry Absolute Offset Entry Size
    asecure_loader 0x400 0 0x400 0x810 0x2E800
    eEID 0x400 1 0x2EC00 0x2F010 0x10000
    cISD 0x400 2 0x3EC00 0x3F010 0x800
    cCSD 0x400 3 0x3F400 0x3F810 0x800
    trvk_prg0 0x400 4 0x3FC00 0x40010 0x20000
    trvk_prg1 0x400 5 0x5FC00 0x60010 0x20000
    trvk_pkg0 0x400 6 0x7FC00 0x80010 0x20000
    trvk_pkg1 0x400 7 0x9FC00 0xA0010 0x20000
    ros0 0x400 8 0xBFC00 0xC0010 0x700000
    ros1 0x400 9 0x7BFC00 0x7C0010 0x700000
    cvtrm 0x400 10 0xEBFC00 0xEC0010 0x40000
    asecure_loader Region TOC
    Here is a list of files stored on /dev/rflash1 i found in HV 3.41 and dumped with PSGroove:

    Entry Name TOC Offset Entry TOC Index Entry Relative Offset Entry Absolute Offset Entry Size
    metldr 0x800 0 0x40 0x840 0xE920
    ros1 Region TOC
    Here is a list of files stored on /dev/rflash1 i found in HV 3.41 and dumped with PSGroove:

    Entry Name TOC Offset Entry TOC Index Entry Relative Offset Entry Absolute Offset Entry Size
    creserved_0 0xC0000 0 0x460 0xC0470 0x40000
    sdk_version 0xC0000 1 0x40460 0x100470 0x8
    lv1ldr 0xC0000 2 0x40480 0x100490 0x1E948
    lv2ldr 0xC0000 3 0x5EE00 0x11EE10 0x16FF0
    isoldr 0xC0000 4 0x75E00 0x135E10 0x13074
    appldr 0xC0000 5 0x88E80 0x148E90 0x1E254
    spu_pkg_rvk_verifier.self 0xC0000 6 0xA70D4 0x1670E4 0xFACC
    spu_token_processor.self 0xC0000 7 0xB6BA0 0x176BB0 0x5C94
    spu_utoken_processor.self 0xC0000 8 0xBC834 0x17C844 0x65D0
    sc_iso.self 0xC0000 9 0xC2E04 0x182E14 0x1532C
    aim_spu_module.self 0xC0000 10 0xD8130 0x198140 0x4498
    spp_verifier.self 0xC0000 11 0xDC5C8 0x19C5D8 0xD7F0
    mc_iso_spu_module.self 0xC0000 12 0xE9DB8 0x1A9DC8 0x808C
    me_iso_spu_module.self 0xC0000 13 0xF1E44 0x1B1E54 0x88B8
    sv_iso_spu_module.self 0xC0000 14 0xFA6FC 0x1BA70C 0xC078
    sb_iso_spu_module.self 0xC0000 15 0x106774 0x1C6784 0x5DB0
    default.spp 0xC0000 16 0x10C524 0x1CC534 0x22A0
    lv1.self 0xC0000 17 0x10E800 0x1CE810 0x127DF0
    lv0 0xC0000 18 0x236600 0x2F6610 0x3E678
    lv2_kernel.self 0xC0000 19 0x274C78 0x334C88 0x171B88
    eurus_fw.bin 0xC0000 20 0x3E6800 0x4A6810 0x70F94
    emer_init.self 0xC0000 21 0x457794 0x5177A4 0x7CDB8
    hdd_copy.self 0xC0000 22 0x4D454C 0x59455C 0x60D68
    ros2 Region TOC
    Here is a list of files stored on /dev/rflash1 i found in HV 3.41 and dumped with PSGroove:
    Entry Name TOC Offset Entry TOC Index Entry Relative Offset Entry Absolute Offset Entry Size
    creserved_0 0x7C0000 0 0x460 0x7C0470 0x40000
    sdk_version 0x7C0000 1 0x40460 0x800470 0x8
    lv1ldr 0x7C0000 2 0x40480 0x800490 0x1E64C
    lv2ldr 0x7C0000 3 0x5EB00 0x81EB10 0x16E30
    isoldr 0x7C0000 4 0x75980 0x835990 0x12EC4
    appldr 0x7C0000 5 0x88880 0x848890 0x1DB64
    spu_pkg_rvk_verifier.self 0x7C0000 6 0xA63E4 0x8663F4 0xFACC
    spu_token_processor.self 0x7C0000 7 0xB5EB0 0x875EC0 0x5C94
    spu_utoken_processor.self 0x7C0000 8 0xBBB44 0x87BB54 0x65D0
    sc_iso.self 0x7C0000 9 0xC2114 0x882124 0x1532C
    aim_spu_module.self 0x7C0000 10 0xD7440 0x897450 0x4498
    spp_verifier.self 0x7C0000 11 0xDB8D8 0x89B8E8 0xD7F0
    mc_iso_spu_module.self 0x7C0000 12 0xE90C8 0x8A90D8 0x808C
    me_iso_spu_module.self 0x7C0000 13 0xF1154 0x8B1164 0x88B8
    sv_iso_spu_module.self 0x7C0000 14 0xF9A0C 0x8B9A1C 0xC078
    sb_iso_spu_module.self 0x7C0000 15 0x105A84 0x8C5A94 0x5DB0
    default.spp 0x7C0000 16 0x10B834 0x8CB844 0x22A0
    lv1.self 0x7C0000 17 0x10DB00 0x8CDB10 0x129040
    lv0 0x7C0000 18 0x236B80 0x9F6B90 0x3E570
    lv2_kernel.self 0x7C0000 19 0x2750F0 0xA35100 0x1712D0
    eurus_fw.bin 0x7C0000 20 0x3E63C0 0xBA63D0 0x70F94
    emer_init.self 0x7C0000 21 0x457354 0xC17364 0x7FBB8
    hdd_copy.self 0x7C0000 22 0x4D6F0C 0xC96F1C 0x61518
    HDD device
    device id = 2

    block size = 512

    The HDD device uses ENCDEC device.

    vtable
    0x00353F48 (3.15)

    Member variables
    offset 0x1590 - LBA48 capability flag (4 bytes)

    Regions
    Index Start sector Number of sectors
    0 0x0 0x950F8B0
    1 0x8 0x80000
    2 0x80018 0x7C8F898
    3 0x7D0F8B8 0x3FFFF8
    4 0x810F8B8 0x13FFFF8
    5 - -
    6 - -
    7 - -
    Supported Device Commands
    Here is the list of commands supported by HDD storage device.

    The commands can be used with HV call lv1_storage_send_device_command. However, before a command is executed HV does bit manipulation with it and checks it against the value of repository node ss.laid or also called LPAR authentication ID. If this test fails then the command is NOT executed.

    Command Description
    0x2 LV1_STORAGE_SEND_ATA_COMMAND
    0x10 -
    0x1B ATA Set UltraDMA Mode
    0x1C ATA Set Features PIO Flow Control Transfer Mode
    0x21 -
    0x22 ATA Identify Device
    0x23 LV1_STORAGE_ATA_HDDOUT (ATA Flush Cache Ext)
    0x26 ATA Read Alternative Status
    0x27 ATA Read Error
    0x28 -
    0x31 ATA Flush Cache/ATA Flush Cache Ext
    0x32 ATA Stanby Immediate
    0x33 -
    UNKNOWN device (redirected to HDD storage device)
    device id = 3
    block size = 512

    It's a psuedo device.
    This storage device redirects all requests to the region 1 of HDD storage device !!!
    vtable
    0x00353D88 (3.15)

    Member variables
    offset 0xD60 - pointer to a storage device that all requests are redirected to
    offset 0xD68 - region ID of the storage device that all requests are redirected to

    Regions
    Index Start sector Number of sectors
    0 0x0 0x80000
    1 0x8 0x75F8
    2 0x7800 0x63E00
    3 0x6B600 0x8000
    4 0x73600 0x400
    5 0x73A00 0x2000
    6 0x77C00 0x200
    7 - -
    /dev/rflash1_1x and /dev/rflash_1xp
    These LPAR 1 devices access region 5 of UNKNOWN storage device.
    In region 5 of UNKNOWN storage device is e.g. LINUX image stored.

    SATA/ATA/ATAPI

    ATA Interrupt Handler
    0x0026B984 (3.15)

    ATA_SetDMA
    0x00268ADC (3.15)

    ATA_make_PRD_table
    0x00267DB4 (3.15)

    This function initializes a PRD (Physical Region Descriptor) table.

    ClearPATACInterrupt
    0x00267CAC (3.15)

    EnablePATACInterrupt
    0x00267D44 (3.15)

    DisablePATACInterrupt
    0x00267AF0 (3.15)

    ATA_read_AltStatus_reg
    0x00267C40 (3.15)

    This function reads the ATA Alternate Status Register and returns it's value.

    ATA_write_DATA_reg
    0x00268A10 (3.15)

    This function writes a 16-bit value to the ATA Data Register.

    ATA_read_DATA_reg
    0x0026887C (3.15)

    ATA_write_DATA
    0x0026635C (3.15)

    This function writes several 16-bit values to the ATA Data register.

    ATA_write_CMD_reg
    0x002688A0 (3.15)

    ATA_read_Error_reg
    0x00267BD4 (3.15)

    ATA_write_Features_reg
    0x002689F0 (3.15)

    ATA_write_DevCtrl_reg
    0x00267BB4 (3.15)

    ATA_write_TaskFile_regs
    0x00266BC8 (3.15) 0x002665A0 (3.15)

    ATA_send_ATAPI_cmd
    0x002655F4 (3.15)

    ATA_send_cmd
    0x0026580C (3.15)

    ATA_send_ReadSectors_cmd
    This function uses LBA28.

    0x0025D2B4 (3.15)

    ATA_send_WriteSectors_cmd
    This function uses LBA28.

    0x0025CEF4 (3.15)

    ATA_send_ReadDMA_cmd
    This function uses LBA28.

    0x0025D380 (3.15)

    ATA_send_WriteDMA_cmd
    This function uses LBA28.

    0x0025CFB8 (3.15)

    ATA_send_ReadDMAExt_cmd
    This function uses LBA48.

    0x0025D74C (3.15)

    ATA_send_WriteDMAExt_cmd
    This function uses LBA48.

    0x0025D664 (3.15)

    ATA_send_IdentifyDevice_cmd
    0x0025D4D8 (3.15)

    ATA_send_IdentifyPacketDevice_cmd
    0x0025D448 (3.15)

    ATA_send_FlushCache_cmd
    0x0025D5E8 (3.15)

    ATA_send_FlushCacheExt_cmd
    0x0025D568 (3.15)

    ATA_send_StandbyImmediate_cmd
    0x0025D07C (3.15)

    ATA_send_SetFeatures_cmd
    0x0025D208 (3.15)

    ATA_send_SMARTEnable_cmd
    0x0025D0F8 (3.15)

    ATA_send_SMARTSaveAttributeValue_cmd
    0x0025D180 (3.15)

    ATA_SetUDMAMode
    0x00260EE8 (3.15)

    Parameters
    r5 - UltraDMA mode (0-5)

    High precision timers
    These timers are used e.g. in SATA/ATA/ATAPI driver.

    timer_add
    0x002C3F2C (3.15)

    timer_del
    0x002C41AC (3.15)

    timer_run_expired
    This function is called from HDEC interrupt handler.

    0x002C4020 (3.15)

    timer_set_HDEC
    0x002BCF80 (3.15)

    SPE
    There are 3 SPE classes.

    The HV call lv1_construct_logical_spe can create LogicalSPE, SPEType1 and SPEType2 objects.

    The syscall 0x10040 creates only SPEType1 objects.

    The SPEType1 and SPEType2 objects cannot be created when isolation mode is disabled. The right most bit of repository node sys.lv1.iso_enbl is checked and when it's not 1 then the SPEType1 and SPEType2 objects cannot be created. In LPAR 1, this check succeedes always. Only in LPARs different from 1, the repository node sys.lv1.iso_enbl is checked.

    LogicalSPE
    SPE type = 0

    Objects of this class are used e.g. on Linux.

    vtable
    0x00358360 (3.15)

    offset 0x20 - pointer to TOC entry of interrupt handler for SPE

    Member variables
    offset 0x38 - pointer to LPAR obj that owns this SPE obj
    offset 0x78 - table of pointers to Outlet objects (3 * 8 bytes, one for each Class 0-2)
    offset 0xB0 - pointer to VAS object
    offset 0xC8 - pointer to Logical PPE object
    offset 0xE0 - SPE id
    offset 0x1A0 - pointer to MMIO Memory Region object
    offset 0x1A8 - pointer to Shadow Registers Memory Region object

    Objects
    Here is the list of logical SPE objects i found in HV 3.15:

    0x003A82E0 - SPE id 0
    0x003A8660 - SPE id 1
    0x003ABA00 - SPE id 2
    0x003B4010 - SPE id 3
    0x003B4D60 - SPE id 4
    0x003B5970 - SPE id 5
    SPEType1
    SPE type = 1

    vtable
    0x00359750

    Member Variables
    offset 0x198 - pointer to MMIO Memory Region object

    offset 0x1A0 - pointer to Shadow Registers Memory Region object

    SPEType2
    SPE type = 2

    vtable
    0x00359790

    SPE Register Shadow Area
    HV createas a SPE Register Shadow Area for each contstructed SPE.
    The area is 1 4Kb page of physical memory.
    When SPE state changes then HV updates data in this area.
    The value of shadow_addr that is returned by lv1_construct_logical_spe is a LPAR start address of this area and it cannot be accessed until it's mapped in the HTAB.
    The SPE Register Shadow Area may be mapped only with read-only page protection or else HV call lv1_insert_htab_entry fails. I tested it with PSGroove and could map the whole memory range and read it after i constructed SPE of type 1 with lv1_construct_logical_spe.
    The shadow_addr is also returned by syscall_10040 (that creates SPE of type 1) but it returns already mapped Process address so HV Processes do not have to map it in HTAB.
    When an isoated SPU is done, HV Processes checks the value at offset 0x30 to determine if the SPU execution was successfull or not.
    GameOS checks also the value at offset 0x30 in the SPE Shadow Area.
    When GameOS creates SPE of type 1 then it maps only SPE Register Shadow Area into it's address space.

    SPE Register Shadow Area Offsets
    0x30 - SPU_Status register value (4 bytes)
    0xF10 - ?
    0xF18 - ?

    Stop Code
    The high-order 16 bit of SPU_Status register value is a Stop Code.

    Here is the list of Stop Codes i extracted from HV Processes which read the value at offset 0x30 when SPU is done:

    Value Description
    0xA Success
    0xC Access Violation (LPAR auth id error)
    0xE ?
    0xF Revoked
    0x12 Invalid Parameter
    0x13 ?
    0x17 Invalid Parameter
    0x25 ?
    SPU_send_MFC_cmd
    0x002B09B0 (3.15)

    This function programs a MFC.

    SPU_write_MFC_cmd_status_reg
    0x002AEE70 (3.15)

    SPU_write_Sig_Notify1_reg
    0x002AEF4C (3.15)

    SPU_write_Sig_Notify2_reg
    0x002AEF30 (3.15)

    SPU_write_Sig_Notify1_and_Notify2
    0x002B0A78 (3.15)

    SPU_enable_iso_load_request
    0x002AEDE0 (3.15)

    SPU_iso_load_request
    0x002AEED0 (3.15)

    SPU_enable_runcntl
    0x002AEB24 (3.15)

    SPU_stop_request
    0x002AEEF0 (3.15)

    SPU_run_request
    0x002AEF10 (3.15)

    SPU_read_status_reg
    0x002AE978 (3.15)

    SPU_read_Mbox_Stat_reg
    0x002AE998 (3.15)

    lv1_undocumented_function_62
    Updates SLB entry.

    Parameters
    %r3 - SPE id
    %r4 - ? (valid values: 0 - 3)
    %r5 - SLB entry index (valid values: 0 - 7)
    %r6 - ESID
    %r7 - VSID

    spe_type1_interrupt_handler
    0x0030E238 (3.15)

    spe_type2_interrupt_handler
    0x003103F8 (3.15)

    spe_type3_interrupt_handler
    0x002F36F4 (3.15)

    Socket
    The socket supports only one address family 0x1F, one socket type 0 and one protocol 0.

    Socket address
    Socket address is called port ID. Valid port IDs are 0-63. Port ID 0 is reserved.

    Socket state
    2 - LISTEN

    Socket table
    The socket table contains 64 entries, one for each port ID. Each entry is 16 bytes large.

    The socket table is at 0x0035F6E8 (3.15).

    Here is the list of opened sockets i found in HV 3.15:

    0x00091FE0 (port ID 0x23, accepts connections)
    0x00127850 (port ID 0x24, accepts connections)
    0x0012F810 (port ID 0x25, accepts connections)

    Socket table entry
    offset 0x0 - pointer to Socket obj
    offset 0x8 - socket accepts connections or not (0 - does not accept, 1 - accepts, 1 byte)

    vtable
    0x00355DB0 (3.15)

    offset 0xB0 - bind
    offset 0xB8 - listen
    offset 0xC8 - connect

    Member variables
    offset 0x360 - socket state (4 bytes)
    offset 0x368 - port ID (8 bytes)
    offset 0x370 - max backlog queue size (8 bytes)

    Virtual Address Space

    VAS
    vtable
    0x00357958 (3.15)

    Member variables
    offset 0x18 - pointer to LPAR that owns this VAS object
    offset 0x48 - VAS id (8 bytes)
    offset 0x70 - number of page sizes (4 bytes)
    offset 0x74 - log2 of HTAB size
    offset 0x78 - pointer to HTAB object

    Objects
    Here is the list of the VAS objects i found in HV dump 3.15:

    0x001C8050 (VAS id 2, LPAR 1)
    0x003B4910 (VAS id 3, LPAR 2)
    0x003BDB50 (VAS id 48, LPAR 2)

    HTAB
    0x38(-0x69A8(HSPRG0)) - pointer to the currently active HTAB in LPAR

    vtable
    0x003575B0 (3.15)

    Member variables
    offset 0x48 - pointer to first PTE
    offset 0x60 - LPID (4 bytes)
    offset 0x64 - log2 of HTAB size (4 bytes)

    Objects
    Here is the list of the HTAB objects i found in HV dump 3.15:

    0x001C8270 (VAS id 2, LPAR 1)

    [Register or Login to view code]

    0x003A8050 (VAS id 3, LPAR 2)

    [Register or Login to view code]

    0x003BC510 (VAS id 48, LPAR 2)

    [Register or Login to view code]

    LPAR_change_HTAB
    This function changes currently active HTAB. It writes to SDR1 register where HTAB address and size is stored.

    0x002BE5D4 (3.15)

    Process SLB
    Each HV process has 16 SLB entries.

    Each SLB entry is 16 bytes large and is in format expected by opcode slbmte.

    Most of the entries are zero (invalid).

    Each process has 4 valid SLB entries: code, data, heap and stack.

    Process 3

    SLB entries
    0x0012D1F0 (3.15)

    Name ESID VSID
    code 0x8 0x38
    data 0xC 0x3C
    heap 0xA 0x3A
    stack 0xF 0x3F
    Process 5

    SLB entries
    0x00093120 (3.15)

    Name ESID VSID
    code 0x8 0x48
    data 0xC 0x4C
    heap 0xA 0x4A
    stack 0xF 0x4F
    Process 6

    SLB entries
    0x000E6960 (3.15)

    Name ESID VSID
    code 0x8 0x58
    data 0xC 0x5C
    heap 0xA 0x5A
    stack 0xF 0x5F
    Process 9

    SLB entries
    0x00763E20 (3.15)

    Name ESID VSID
    code 0x8 0x8
    data 0xC 0xC
    heap 0xA 0xA
    stack 0xF 0xF
    VUART
    VUART is a bi-directional communication link. A VUART object has a peer VUART object.

    Data written to a VUART object is stored NOT in the data buffer of the VUART object but in the data buffer of the peer VUART object.

    VUART table
    Every LPAR has a VUART table. A VUART table has 256 entries. Each entry is a pointer to a VUART object that implements VUART interface.

    0x00677218 (3.15) - address of VUART table of LPAR 1

    Here is the list of all VUART objects in LPAR 1 i found in HV 3.15:

    0x006ABD90 - VUART 0
    0x006ABEB0 - VUART 1
    0x006A3CB0 - VUART 2
    0x006A3DD0 - VUART 3
    0x000A3410 - VUART 5
    0x000A3250 - VUART 6
    VUART [0-3] are used by /dev/sc[0-3] respectively.

    VUART [0-3] are linked to VUART objects of different type i could not yet identify. These unknown VUART objects use eieio opcode a lot. So i think, they communicate with hardware peripheral.

    A write/read to/from /dev/sc[0-3] is a write/read to/from VUART.

    0x00762AA8 (3.15) - address of VUART table of LPAR 2

    Here is the list of all VUART objects in LPAR 2 i found in HV 3.15:

    0x00126660 - VUART 0
    0x000A3010 - VUART 2
    VUART 0 and VUART 2 of LPAR 2 are created by Process 9 during LPAR construction.

    VUART class

    Member variables
    offset 0x48 - pointer to peer VUART object
    offset 0x58 - write pointer into data ring buffer
    offset 0x60 - read pointer into data ring buffer
    offset 0x68 - pointer to data ring buffer
    offset 0x70 - size of data ring buffer (8 bytes)
    offset 0x78 - size of data stored in data ring buffer currently (8 bytes)
    offset 0x88 - tx trigger (8 bytes)
    offset 0x90 - rx trigger (8 bytes)
    offset 0x98 - interrupt mask (8 bytes)
    offset 0xA8 - port number (4 bytes)

    Methods
    pmpi_read_virtual_uart(port, buf, size, nread) - 0x002EB30C (3.15)
    pmpi_write_virtual_uart(port, buf, size, nwritten) - 0x002EB0EC (3.15)
    VUART_read(pointer to VUART object, buf, size, nread) - 0x002E8654 (3.15)
    VUART_write(pointer to VUART object, buf, size, nwritten) - 0x002E8428 (3.15)

    Guest OS VUART 0 (AV Manager)
    All data sent to VUART 0 in LPAR 2 is written into the data buffer of VUART 5 of LPAR 1.

    VUART 5 of LPAR 1 is accessed by Process 9 in LPAR 1 through the file /proc/partitions/2/vuart/0.

    Process 9 of LPAR 1 uses RSX syscalls to access RSX driver and memory mapped device access (/dev/ioif0).

    Guest OS VUART 2 (System Manager)
    All data sent to VUART 2 in LPAR 2 is written into the data buffer of VUART 6 of LPAR 1.

    VUART 6 of LPAR 1 is accessed by Process 9 in LPAR 1 through the file /proc/partitions/2/vuart/2.

    System manager supports 62 (0-61) service ids.
    Process 9 has a SID table. SID table has 62 entries.
    Each entry is a pointer to a function responsible for processing SID packets.

    System Manager (SM)
    System Manager (SM) is running in Process 9 of HV.

    It communicates with Guest OS through /proc/partitions/2/vuart/2 file.

    System Manager class

    Member variables
    offset 0x10 - LPAR state (8 bytes)
    offset 0x68 - LPAR auth id
    offset 0x70 - LPAR name
    offset 0x90 - LPAR image path
    offset 0x1C0 - LPAR ability (8 bytes)

    Types of System Manager
    There are 6 different SM types
    When Process 9 starts it reads profile file, by default DEFAULT.SPP, by sending requests to SPL (Secure Profile Loader) and constructs System Managers listed in this profile file.
    So, the profile file controls which System Manager types are available later.

    Name LPAR name
    SCE_CELLOS_PME -
    SCE_CELLOS_SYSTEM_MGR PS3_LPAR
    SCE_CELLOS_SYSTEM_MGR_PS2 PS2_LPAR
    SCE_CELLOS_SYSTEM_MGR_PS2_SW PS2_SW_LPAR
    SCE_CELLOS_SYSTEM_MGR_PS2_GX PS2_GX_LPAR
    SCE_CELLOS_SYSTEM_MGR_LINUX LINUX_LPAR
    Ability Bitmask
    Index Name Ability Bitmask (Hex) Ability Bitmask (Binary)
    0 SCE_CELLOS_PME 0x1 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0001
    1 SCE_CELLOS_SYSTEM_MGR 0x3BF7EF 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0011 1011 1111 0111 1110 1111
    2 SCE_CELLOS_SYSTEM_MGR_PS2_SW 0x1226D 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0001 0010 0010 0110 1101
    3 SCE_CELLOS_SYSTEM_MGR_LINUX 0x40012 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0100 0000 0000 0001 0010
    Bit Position (from right) SID Description
    1 5 (SET_NEXT_OP) Shutdown or Reboot LPAR
    2 5 (SET_NEXT_OP) Boot PS3 LPAR
    3 5 (SET_NEXT_OP) Boot PS2_SW LPAR
    4 5 (SET_NEXT_OP) Boot LINUX LPAR
    5 12 (CONTROL_LED) Control LED
    6 21 (RING_BUZZER) Ring Buzzer
    7 19 (SET_CONFIG) Set Config
    10 26 (REQUEST_ERROR_LOG) Request Error Log
    10 28 (REQUEST_BE_COUNT) Request BE Count
    10 32 (REQUEST_SYSTEM_EVENT_LOG) Request System Event Log
    12 30 (REQUEST_SC_VERSION) Request SC Version
    14 39 (SET_SHOP_DEMO_MODE) Set Shop Demo Mode
    Service ID (SID)
    SM supports 62 (0-61) SIDs.

    The value of SM member variable ability controls which SIDs may be used by LPAR.


    [Register or Login to view code]

    12 - CONTROL_LED
    I have tested this service with PSGroove and GameOS is allowed to use it

    Packet Body

    [Register or Login to view code]

    Parameters
    I have tested the following parameters with this service:
    field0 field1 field2 field4 field5 Description
    0x1 0x0 0xFF 0xFF 0xFF Turns off the power button LED
    0x1 0x1 0xFF 0xFF 0xFF Turns on the power button LED
    21 - RING_BUZZER
    I have tested this service with PSGroove and GameOS is allowed to use it

    Packet Body

    [Register or Login to view code]

    Parameters
    I have tested the following parameters with this service:

    field1 field2 field4 Description
    0x29 0x4 0x6 Makes a short single beep
    0x29 0xA 0x1B6 Makes a double beep
    0x29 0x7 0x36 -
    0x29 0xA 0xFFF Makes a continuous beep
    Active System Managers in HV dump 3.15
    There are 4 active SMs in HV dump.
    Index Name LPAR auth id LPAR image pathname Ability Bitmask (Hex)
    0 SCE_CELLOS_PME 0x1070000001000001 /flh/os/this_is_dummy 0x1
    1 SCE_CELLOS_SYSTEM_MGR 0x1070000002000001 /flh/os/lv2_kernel.self 0x3BF7EF
    2 SCE_CELLOS_SYSTEM_MGR_PS2_SW 0x1020000003000001 /local_sys0/ps2emu/ps2_softemu.self 0x1226D
    3 SCE_CELLOS_SYSTEM_MGR_LINUX 0x1080000004000001 /flh/lx/linux 0x40012
    GameOS file image lv2_kernel.self is stored on /dev/rflash1
    Linux file image is stored on /dev/rflash_1x or /dev/rflash_1xp

    Booting Linux LPAR through System Manager
    To boot Linux LPAR from GameOS when Linux support was not removed (Ability Mask of PS3 System Manager needs patching !!!):

    Send SID packet SET_NEXT_OP with operation OP_LPAR_REBOOT and the index of Linux system manager to System Manager (VUART 2)
    Send SID packet REQUEST with type SHUTDOWN to System Manager (VUART 2)
    Execute lv1_panic HV call in GameOS
    It should also work when Linux support was removed but Linux system manager was not removed from Process 9 and also assumed that a Linux kernel image is stored at the right place in /dev/rflash_1x.

    It's just a theory, nothing else, that i gathered during HV reversing. It needs a practical proof. Unfortunately, i don't have access to Hypervisor.

    AV Manager
    All data sent to VUART 0 in LPAR 2 is written into the data buffer of VUART 5 of LPAR 1.

    VUART 5 of LPAR 1 is accessed by Process 9 in LPAR 1 through the file /proc/partitions/2/vuart/0.

    During initialization, AV Manager opens /dev/ioif0 device and maps different address ranges of the device into address space of Process 9
    /dev/ioif0 is NOT opened and mapped if the value of repository node lv1.rsx.enable is less than 1
    /dev/ioif0 is mapped with READ/WRITE protection
    File descriptor of /dev/ioif0 in Process 9 is 4
    AV Manager supports a lot more commands than used on Linux
    Every command is implemented by a class

    Mapped Address Ranges From /dev/ioif0
    The base address of /dev/ioif0 is 0x28000000000. The device supports only mmap system call, it cannot be read or written. It also doesn't support ioctl.

    Index Absolute Address Range Size Mapped Address in Process 9 Address Space
    0 0x28000000000 - 0x28000002000 0x2000 0xA0019000
    1 0x28001800000 - 0x28001801000 0x1000 0xA0004000
    2 0x28000600000 - 0x28000604000 0x4000 0xA001A000
    3 0x28000680000 - 0x28000684000 0x4000 0xA0006000
    4 0x28000080000 - 0x28000088000 0x8000 0xA000A000
    5 0x28000088000 - 0x28000089000 0x1000 0xA000E000
    6 0x2800000C000 - 0x2800000D000 0x1000 0xA0016000
    7 0x2800008A000 - 0x2800008B000 0x1000 0xA0017000
    8 0x2800008C000 - 0x2800008D000 0x1000 0xA0018000
    Process socket services

    Function ID and Packet ID

    Processes 3, 5 and 6 provide services (functions) to other Processes through sockets (something like RPC).
    A service is identified by a function ID.
    Each process has a hash table which maps a function ID to socket port ID.
    Services (functions) can be further differentiated by a packet ID.
    To request a service, a Process sends a packet with specified function and packet ID to the Process that provides the service.
    A process that provides a service (function) has a table of objects which handle different packet IDs.
    Services are synchronous, a client sends a request and waits for a response.
    If a Process requests a service that is located in the same Process then the service is called directly and sockets are not used !!! (e.g. SLL requests from DM creating VUART port during GameOS loading, SLL and DM are in the same Process, so SLL calls DM directly)

    Port ID - Process ID mapping

    Port ID Process ID
    0x23 6
    0x24 5
    0x25 3
    PS3 Hypervisor Reverse Engineering Progress is Detailed

    More PlayStation 3 News...

  2. #2
    Forum Moderator PS3 News's Avatar
    Join Date
    Apr 2005
    Posts
    27,852
    Sponsored Links
    Sponsored Links
    Continued from the first post...
    Function ID - Port ID mapping
    Function ID Port ID Supported Packet IDs Function Description
    0x2000 0x23 0x2001 - 0x2017 Virtual TRM Manager
    0x3000 0x24 0x3001 - 0x3003 Secure RTC
    0x5000 0x23 0x5001 - 0x500A Storage Manager
    0x6000 0x23 0x6001 - 0x6011 Update Manager
    0x9000 0x24 0x9001 - 0x9016 SC Manager
    0x10000 0x23 - -
    0x11000 0x25 0x11001 - 0x11002 SPM (Security Policy Manager)
    0x14000 0x25 0x14004 - 0x14005 SLL (Secure LPAR Loader)
    0x15000 0x24 0x15001, 0x15003, 0x15009 SPL (Secure Profile Loader)
    0x17000 0x24 0x17001 - 0x17017 Indi Info Manager
    0x18000 0x25 0x18001, 0x18002, 0x18004 Dispatcher Manager
    0x19000 0x24 0x19002 - 0x19005 AIM
    0x24000 0x23 0x24001 - 0x24002 USB Dongle Authenticator
    0x25000 0x23 0x25001 - 0x25002 User Token Manager
    SS Packet
    SS means Secure Service ?
    Processes send SS Packets to request a service or to reply to a service request.

    Member variables
    offset 0x8 - packet ID (8 bytes)
    offset 0x10 - function ID (8 bytes)
    offset 0x18 - return value (4 bytes)
    offset 0x20 - subject ID (2 * 8 bytes)

    Header
    All services use a common header.
    The header of a SS Packet is 0x28 bytes large.

    [Register or Login to view code]

    SS Service Return Values
    Error Code Description
    0x00000000 Success
    0x00000005 Access Violation
    0x00000006 No Entry ?
    0x00000009 Invalid Parameter
    0x0000000F ?
    Body
    The body of a SS Packet follows after the header.
    The size of the body depends on a used service.

    0x2000 - Virtual TRM Manager
    Packet ID Description
    0x2001 Init
    0x2002 Status
    0x2003 Store
    0x2004 Store
    0x2005 Retrieve
    0x2006 Free
    0x200A Encrypt
    0x200B Decrypt
    0x200C Encrypt With Portability
    0x200D Decrypt With Portability
    0x200E Decrypt Master
    0x2012 Backup Flash
    0x2013 Restore Flash
    0x2014 Backup SRK SRH
    0x2015 Restore SRK SRH
    0x2016 Flash Address Size
    0x2017 Force Restart
    0x200E - Decrypt Master
    This service is e.g. used in Process 6 by USB Dongle Authenticator to decrypt USB Dongle Master Key
    GameOS uses this service e.g. in syscall SYS_SS_AD_SIGN

    0x3000 - Secure RTC
    [quote]Packet ID Description
    0x3001 Set RTC
    0x3002 Get Time
    0x3003 Set Time
    [quote]
    0x5000 - Storage Manager
    Packet ID Description
    0x5002 Set/Delete ATA (Encdec) Key
    0x5003 Get Random Number
    0x5004 Authenticate Drive
    0x5005 Authenticate PS2 Disc
    0x5006 Get Secure Firmware Version
    0x5003 - Get Random Number
    I have got access to Get Random Number service through DM and tested it with PSGroove
    The service returns 192-bit random numbers
    It has no input parameters except those in SS packet header
    0x6000 - Update Manager
    Packet ID Description
    0x6001 Update Package Tophalf
    0x6002 Inspect Package Tophalf
    0x6003 Get Package Info
    0x6004 Get Fix Instruction
    0x6005 Extract Package Tophalf
    0x6006 Get Extract Package
    0x6009 Get Token Seed
    0x600A Set Token
    0x600B Read EPROM
    0x600C Write EPROM
    0x6010 Check Integrity
    0x6011 Get Applicable Version
    Update Manager service is accessed by GameOS syscall 863
    0x6001 - Update Package Tophalf
    The result of the request can be checked by reading the value of repository node ss.update.request.<Request ID> periodically
    0x6002 - Inspect Package Tophalf
    I have got access to this service through DM and tested it with PSGroove
    This service can tell you if a package can be installed or not, the service just checks a package but does not install it
    Packages can be updated without GameOS !!! I'm using only HV calls and communicate directly with Dispatcher Manager and Update Manager
    I just sent a whole SCE package to GameOS through network, created a LPAR memory region and stored the file there
    It expects a SCE package that can be easily extracted from PUP file
    The data of SCE package can be passed either in SS packet itself or through LPAR memory of requester
    When the data of SCE package is too large for SS packet (SS packets are sent through DM, GameOS and DM communicate through VUART that has only 0x800 bytes buffer) then the data of SCE package has to be passed through GameOS LPAR memory. The requester sends a vector of LPAR memory addresses where the data of SCE package is stored and Update Manager maps it into the address space of Process 6
    E.g. Revoke List packages can be sent in SS packets because they are small (about 0x200 bytes). All other packages are too big to sent them in SS packets
    The service is actually split into 2 halfs: Top-Half and Bottom-Half
    The Top-Half is executed synchronously with service request and it sends a reply to the requester
    In the reply sent by Top-Half a Request ID (8 bytes) is returned to the requester
    Request ID is calculated by using SHA-1
    After the Top-Half is done, a reply is sent to the requester but the service just checked some input parameter upto now and the passed SCE package was not really checked yet
    The Bottom-Half is called asynchronously to the request, it does the real job, it checks the passed SCE package.
    The result of the request can be checked by reading the value of repository node ss.inspect.request.<Request ID> periodically
    I successfully tested this service with RL_FOR_PROGRAM.img from 3.50 PUP file and the service returned Success, so theoretically i could install this package on my PS3. But of course i want to downgrade and NOT to upgrade.

    Inspect Package Tophalf Return Values
    Error Code Description
    0x00000000 Success
    0x00000013 Same Version/Older Version
    0x00000014 -
    0x6003 - Get Package Info
    I have got access to this service through DM and tested it with PSGroove
    The service expects one additional parameter: package type (valid values are 1-9)
    The service returns the version (8 bytes) of a package type installed

    Here are the versions of packages installed on my PS3:
    Package Type Returned Version Description Package Name in PUP File
    1 0x0003004100000000 Core OS Package CORE_OS_PACKAGE.pkg
    2 0x0003004100000000 Revoke List Package for Program RL_FOR_PROGRAM.img
    3 0x0002003000000000 Revoke List Package for Package RL_FOR_PACKAGE.img
    4 0xDEADBEAFFACEBABE - -
    5 0xDEADBEAFFACEBABE - -
    6 0x0003004000000000 BD Firmware Package BDIT_FIRMWARE_PACKAGE.pkg, BDPT_FIRMWARE_PACKAGE_*.pkg
    7 Invalid Parameter Bluetooth Firmware BLUETOOTH_FIRMWARE.pkg
    8 Invalid Parameter - -
    9 Invalid Parameter SC Firmware Package SYS_CON_FIRMWARE_*.pkg
    Decrypting and Extracting Packages with spu_pkg_verifier.self
    I have managed to decrypt and extract Revoke List Packages 3.41 and 3.50 by using SPE HV calls and spu_pkg_verifier.self
    Important: Parameters to SPU module shuold be aligned, i used cache line alignment, don't know exactly alignment requerements. Or else some very strange things could happen. E.g SYSCON firmware was only partially decrypted when i used no cache line alignment.
    I have also managed to decrypt and extract Core OS Packages 1.10, 1.18 Debug, 2.40, 2.80, 3.15, 3.41 and 3.50 by using SPE HV calls and spu_pkg_verifier.self but it's compressed with zlib.Update Manager in Process 6 from 3.15 uses zlib 1.2.3 inflate to decompress it after it was decrypted and then it stores the data to flash memory.
    I decompressed the decrypted Core OS Packages with zlib.
    I am able now to decrypt and decompress all Core OS Packages
    The decrypted and decompressed package CORE_OS_PACKAGE.pkg looks exactly like it's stored on flash.
    I also decrypted BD Firmwares BDIT_FIRMWARE_PACKAGE.pkg and BDPT_FIRMWARE_PACKAGE.pkg successfully. The firmware is not compressed.
    I also decrypted Bluetooth Firmware BLUETOOTH_FIRMWARE.pkg successfully. The firmware is encrypted and compressed.
    I also managed to decrypt System Controller Firmware SYS_CON_FIRMWARE_01050101.pkg from 3.41.
    Core OS Package 3.50 contains a new isolated SPU module that is not contained in older versions. The SPU module is manu_info_spu_module.self.

    RL_FOR_PROGRAM.img 3.41

    [Register or Login to view code]

    RL_FOR_PROGRAM.img 3.50

    [Register or Login to view code]

    RL_FOR_PACKAGE.img 3.41

    [Register or Login to view code]

    RL_FOR_PACKAGE.img 3.50

    [Register or Login to view code]

    CORE_OS_PACKAGE.pkg 3.15
    Here is a piece of data from decrypted and decompressed package.

    [Register or Login to view code]

    BDIT_FIRMWARE_PACKAGE.pkg 3.50
    Here is a piece of data from decrypted package.

    [Register or Login to view code]

    BDPT_FIRMWARE_PACKAGE_301R.pkg 3.50
    Here is a piece of data from decrypted package.

    [Register or Login to view code]

    BLUETOOTH_FIRMWARE.pkg 3.41

    [Register or Login to view code]

    SYS_CON_FIRMWARE_01050101.pkg 3.41

    [Register or Login to view code]

    0x6005 - Extract Package Tophalf
    The result of the request can be checked by reading the value of repository node ss.extract.request.<Request ID> periodically

    0x600B - Read EEPROM
    I have got read access to EEPROM of Update Manager through DM and tested it with PSGroove
    I read PRODUCT_MODE from it successfully, PRODUCT_MODE = 0x000000FF
    The service expects one additional parameter: offset (4 bytes)
    The service accepts only some predefined offsets
    The service returns the specified offset and the value at this offset

    0x600C - Write EEPROM
    Writting to EEPROM of Update Manager is also possible through DM
    Tested this service successfully with QA flag

    0x6010 - Check Integrity
    This service checks integrity of important files stored on /dev/rflash1, e.g. lv0 or lv1
    The service is used e.g. by System Manager
    When product mode is NOT 0xFF then check is skipped !!!

    0x6011 - Get Applicable Version
    I have got access to this service through DM and PSGroove and tested it
    The service expects one additional unknown parameter of size 4 bytes, it has to be 0x00000001 or else the service fails
    Here is the return value:

    [Register or Login to view code]

    0x9000 - SC Manager
    SC Manager cannot be accessed directly by using DM unfortunately (DM discards all requests) but it's used by other services that are accessable through DM

    E.g. Update Manager services "Read EEPROM" and "Write EEPROM" send requests to SC Manager services "Read EEPROM" and "Write EEPROM"
    SC Manager runs sc_iso.self
    Packet ID Description
    0x9001 Get SRH
    0x9002 Set SRH
    0x9003 Encrypt
    0x9004 Decrypt
    0x9005 Init For VTRM
    0x9006 Get Region Data
    0x9007 Set Region Data
    0x9009 Get RTC
    0x900A Set RTC
    0x900B Read EPROM
    0x900C Write EPROM
    0x900D Init For Updater
    0x900E Get SC Status
    0x9011 SC Binary Patch
    0x9012 SC RTC Factory
    0x9013 Correct RTC Factory
    0x9014 Set SC Status
    0x9015 Backup Root Info
    0x9016 Restore Root Info
    0x11000 - SPM (Security Policy Manager)
    Packet ID is mapped to SS id
    SS id value range is 0x0 - 0x84
    Packet ID Description
    0x11001 Request
    0x11002 Load Additional Policy
    0x14000 - SLL (Secure LPAR Loader)
    SLL opens lv2_kernel.self, parses ELF header and determines the size of initial memory region for GameOS LPAR
    SLL creates a memory region for GameOS LPAR by using syscall 0x10000.
    SLL opens /proc/partitions/<LPAR id>/mem file and maps it with mmap syscall into it's address space.
    Then it authenticates, decrypts and copies the SELF file of GameOS to LPAR's memory region by using SPE syscalls 0x10040 and 0x10042.
    Linux is not loaded by SLL, it's loaded in Process 9 by Linux System Manager
    GameOS file image lv2_kernel.self is stored on /dev/rflash1
    Packet ID Description
    0x14004 Load GOS
    0x14005 Unload GOS
    0x15000 - SPL (Secure Profile Loader)
    DEFAULT.SPP file is stored on /dev/rflash1
    Packet ID Description
    0x15001 Get LPAR Parameter Size/Get LPAR Parameter
    0x15003 Get Contents Size/Get Contents
    0x15009 Get Component
    SPP File
    The file is encrypted but can be read by using 0x15003 service of SPL
    SPL reads SPP file, parses SPP header and checks some fields
    SPP file is verified and decrypted by SPU module spp_verifier.self that cab be executed with HV SPE calls
    Even old default.spp from PS3 Firmware 1.10 can be decrypted with spp_verifier.self from PS3 Firmware 3.41
    Header format version should be 5 or else the header check fails
    If (SPP header size % 256 != 0) then header check fails
    Finally i was able to decrypt profile file from 3.41 but by using SPE HV calls only !!! And Linux Manager is still there !!!
    The decrypted file is a binary file

    SPP Header
    offset 0x2 - header format version (2 bytes)
    offset 0x4 - header size (4 bytes)
    offset 0x18 - number of segments (4 bytes)

    Segments
    Segments follow after the header
    SPP file contains several segments.

    Here is the list of profile segments from 3.41:

    SCE_CELLOS_PME
    PS3_LPAR
    PS2_LPAR
    PS2_GX_LPAR
    LINUX_LPAR
    SCE_CELLOS_SYSTEM_MGR
    SCE_CELLOS_SYSTEM_MGR_LINUX
    SCE_CELLOS_SYSTEM_MGR_PS2
    SCE_CELLOS_SYSTEM_MGR_PS2_SW
    SCE_CELLOS_SYSTEM_MGR_PS2_GX
    SCE_CELLOS_SS_SECURE_RTC
    SCE_CELLOS_SS_INDI_INFO_EID
    SCE_CELLOS_SS_INIT_LV1_ACL

    0x15003 - Get Contents Size/Get Contents
    This service provides the contents of a segment specified by a service requester
    I have got access to this service through DM but couldn't get through access policy yet, the service returns error code 0x00000005 that means Access Violation
    But i still could test with this service which segment names are valid
    I need valid laid and paid to get through it

    0x17000 - Indi Info Manager
    Packet ID Description
    0x17001 Read EID0 Size
    0x17002 Read EID0
    0x17007 Read System Data From EEPROM
    0x17001 - Read EID0 Size

    I have got access to this service through DM and tested it
    This service is used e.g. by Update Manager, User Token Manager or Storage Manager
    The service expects 2 additional parameters, each parameter is 8 bytes
    I tested it with values: 0x0, 0x4 and 0x1000 for the 1st parameter. I extracted this values from HV Processes which use this service
    The 2nd parameter is not used in a request but in a response. It contains EID0 size.

    EID0 size for 0x0 - 0x860
    EID0 size for 0x4 - 0x30
    EID0 size for 0x1000 - 0xe960

    0x17002 - Read EID0
    I have got access to this service through DM and tested it
    This service is used e.g. by Update Manager, User Token Manager or Storage Manager
    The service expects 2 additional parameters, each parameter is 8 bytes
    The 1st parameter is same as the 1st parameter of service Read EID0 Size
    The 2nd parameter is EID0 Size that is returned by the service Read EID0 Size
    The returned data is some binary data.
    The data returned by the service with 1st parameter set to 0x0 or 0x4 is from file eEID stored on FLASH storage device region 0.
    The data returned by the service with 1st parameter set to 0x1000 contains string metldr.
    E.g. EID0 data is passed by Update Manager to SPU module spu_token_processor.self when Update Manager loads and executes it with syscall 0x10043.

    0x18000 - DM (Dispatcher Manager)
    Dispatcher Manager runs in Process 3.
    When SLL (Secure LPAR Loader) creates GamesOS LPAR and loads it, it also creates a VUART with port number 10 owned by GameOS using a service provided by Dispatcher Manager (0x18001 - Construct Service Port).
    Dispatcher Manager communicates with GameOS through this VUART. It opens the file /proc/partitions/<LPAR id>/vuart/10. When the file /proc/partitions/<LPAR id>/vuart/10 is opened by Dispatcher Manager, the Hypervisor creates a peer VUART which is connected to the GameOS's VUART 10.
    After that Dispatcher Manager reads requests from this VUART sent by GameOS and dispatches these requests to services (functions) provided by Hypervisor Processes through sockets. Through VUART and Dispatcher Manager, the GameOS LPAR has access to all services provided by Hypervisor Processes.
    However, the services provided by Hypervisor Processes are protected by Security Policy Manager (SPM). Before Dispatcher Manager routes the requests from GameOS to these services, it consults SPM (by using 0x11001 service of SPM) and checks if the GameOS has access rights to the requested service. If not then the request is not routed.
    Linux LPAR doesn't have a VUART communication link to Dispatcher Manager.
    I tested VUART 10 on GameOS with PSGroove and it's there.
    On GamesOS, _ss_multiplexer accesses DM (VUART 10)
    ID Description
    0x18001 Construct Service Port
    0x18002 Destruct Service Port
    Dispatcher Manager Messages

    Dispatcher Manager Header
    Payload follows after header
    Payload is a SS packet

    [Register or Login to view code]

    Packet ID - SS ID Mapping
    Before DM routes a received request to a service provider (HV Process) it consults SPM
    DM sends a request to SPM
    Request contains SS ID and Subject ID (laid and paid)
    DM obtains SS ID by mapping Packet ID
    Here is the mapping table i extracted from HV Process 3 where SPM and DM run:
    Packet ID SS ID
    0x2001 0x34
    0x2002 0x35
    0x2003 0x36
    0x2004 0x37
    0x2005 0x38
    0x2006 0x39
    0x200A 0x3D
    0x200B 0x3E
    0x200C 0x3F
    0x200D 0x40
    0x200E 0x41
    0x2012 0x7B
    0x2013 0x7C
    0x2014 0x7E
    0x2015 0x7F
    0x2016 0x7D
    0x2017 0x80
    0x19000 - AIM
    Executes isolated SPU module aim_spu_module.self
    EID0 data is passed to aim_spu_module.self
    Packet ID Description
    0x19002 Get Device Type
    0x19003 Get Device ID
    0x19004 Get PS Code
    0x19005 Get Open PS ID
    0x24000 - USB Dongle Authenticator
    Packet ID Description
    0x24001 Generate Challenge
    0x24002 Verify Response
    0x24001 - Generate Challenge
    I have got access to this service through DM and tested it
    The service expects no input parameters except those in SS packet header
    It uses 0x5003 service (Generate Random Number) to generate random numbers that are used in challenge body
    The length of a challnge body is always 23 bytes, first 3 bytes are always the same: 0x2E 0x02 0x01
    Here are hexdumps of some challenge bodies i let 0x24001 service generate:

    [Register or Login to view code]


    [Register or Login to view code]


    [Register or Login to view code]

    [/code]
    0x24002 - Verify Response
    I have got access to this service and tested it with PSGroove
    The response body is 25 bytes large
    The first 3 bytes have to be 0x2E 0x02 0x02 or else the check fails
    The 16 bit at offset 3 is a dongle ID
    The dongle ID is checked if it's revoked or not
    When the verification succeedes then product mode is set to 1
    The service calculates USB Dongle Key from USB Dongle ID and USB Dongle Master Key by using HMAC SHA-1
    The service uses HMAC SHA-1 to calculate the correct response body from the challenge body and USB Dongle Key
    After that the service compares the calculated response body with the given one that was sent to the service
    It seems that laid and paid from SS packet header are used in decryption process

    USB Dongle Master Key
    USB Dongle Master Key is stored encrypted in Process 6
    The encrypted key is 64 bytes large
    The decrypted key is 20 bytes large
    The USB Dongle Master Key is decrypted first time the service 0x24002 is used
    The USB Dongle Master Key is decrypted by using the service 0x200E (Decrpyt Master) of Vitual TRM Manager
    The decrypted USB Dongle Master Key is stored in Process 6 in clear text (after first usage of this service)
    When decrpyption of USB Dongle Master Key fails then a dummy key is used
    Unfortunately, in the HV dump 3.15 the USB Dongle Master Key was not decrypted at the moment of dumping

    Here is the encrypted USB Dongle Master Key from HV 3.15:

    [Register or Login to view code]

    Here is the USB Dongle Master Dummy Key from HV 3.15:

    [Register or Login to view code]

    USB Dongle ID Revoke List
    Process 6 contains a revoke list for USB Dongle IDs
    The revoke list is 0x2000 bytes large. It's a bitmap.
    Each bit represents a USB Dongle ID. If bit is 0 then USB Dongle ID is revoked.
    The following USB Dongle IDs are revoked in HV 3.15:

    [Register or Login to view code]

    0x25000 - User Token Manager
    [b]Packet ID Description
    0x25001 Encrypt User Token
    0x25002 Decrypt User Token
    User Token
    Before User Token Manager encrypts a received user token it checks it's format.
    User Tokens are processed by spu_utoken_processor.self
    Before User Token is processed, User Token Manager reads IDPS by sending SS requests to Indi Info Manager (packet ids 0x17001 and 0x17002). Indi Info Manager runs in HV Process 5.
    User Token Format

    [Register or Login to view code]

    LPAR Memory Management

    Memory Region class
    This class is the base class for different memory region types.

    vtable
    0x003578B0 (3.15)

    Member variables
    offset 0x40 - pointer to LPAR object that owns this memory region
    offset 0x48 - type of memory region (8 bytes)
    offset 0x50 - LPAR start address of memory region
    offset 0x58 - size of memory region (8 bytes)
    offset 0x60 - flags (8 bytes)
    offset 0xA0 - log2 of page size

    Physical Memory Region class
    This type of memory region is created e.g. in lv1_allocate_memory HV call or in syscall 0x10000.

    vtable
    0x00357D08 (3.15)

    Member variables
    offset 0xB0 - pointer to object that stores a list of addresses of physical pages owned by this memory region
    offset 0xB8 - pointer to LPAR object that owns this memory region
    offset 0xC0 - reference counter (8 bytes)

    Objects
    Here is the list of physical memory region objects i found in HV 3.15.
    Address in HV dump LPAR id LPAR Start Address Size Flags log2(Page Size) Physical Page Addresses
    0x006B5510 1 0x300000001000 0x1000 0x0 0xC 0x672000
    0x006B5E50 1 0x440000040000 0x20000 0x0 0x11 0x6C0000
    0x006B6980 1 0x440000060000 0x20000 0x0 0x11 0x6E0000
    0x006B7F00 1 0x400000040000 0x10000 0x0 0x10 0x100000
    0x003A80F0 2 0x6C0058000000 0x7000000 0x4 0x18 0x1000000 - 0x7000000
    0x003BE800 2 0x300000047000 0x1000 0x0 0xC 0x1FA000
    0x006BDAA0 2 0x0 0x8000000 0x8 0x1B (single huge page) 0x8000000
    So, Linux kernel should be located at physical address 0x8000000 and Linux syscall handler at 0x8000C00. Too bad that the HV dump is not large enough.

    GameOS Physical Memory Regions
    GameOS allocates nearly all physical memory of PS3 for itself !!! That is why new HV calls lv1_allocate_memory with large memory region sizes will fail.
    So when someone wants a large piece of physical memory, he can borrow it from GameOS's LPAR memory region that starts at 0x700020000000. It can be used for example to send update packages to Update Manager which are very large.
    Here is the list of physical memory regions of GameOS i found in HV 3.41:
    Start Address Size Access Right Max Page Size Flags
    0x0 0x1000000 0x3 0x18 0x8
    0x700020000000 0xE900000 (huge memory region) 0x3 0x14 0x0
    0x500000300000 0xA0000 0x3 0x10 0x8
    HTAB Memory Region class
    This memory region is created when a HTAB is mapped into LPAR's address space. It's created in lv1_map_htab HV call.

    vtable
    0x00357C98 (3.15)

    Member variables
    offset 0xB0 - pointer to VAS object that owns the HTAB

    Objects
    Here is the list of HTAB memory region objects i found in HV 3.15.

    Address in HV dump LPAR id VAS id LPAR Start Address Size Flags log2(Page Size)

    0x001FE0F0 2 3 0x500000C00000 0x100000 0xC000000000000000 0x14
    0x003BD850 2 3 0x500004300000 0x100000 0xC000000000000000 0x14
    0x003BDEA0 2 3 0x500004500000 0x100000 0xC000000000000000 0x14
    GameOS HTAB
    HTAB of GameOS is already mapped into address space of GameOS so that is why HV call lv1_map_htab will fail until you unmap it with lv1_unmap_htab
    Effective address of GameOS HTAB is 0x800000000F000000
    Virtual address of GameOS HTAB is 0xF000000
    Size of GameOS HTAB is 0x40000
    GameOS HTAB supports large pages of size 64K and 1M
    GameOS HTAB can be easily dumped by reading 0x40000 bytes at EA 0x800000000F000000

    GameOS SLB
    Here is the dump of SLB entries from GameOS 3.41:

    [Register or Login to view code]

    SPE MMIO Memory Region class
    This type of memory region represents MMIO memory region of a SPE. It's created e.g. in lv1_construct_logical_spe or in syscall 0x10040.

    vtable
    0x003583F8 (3.15)

    Member variables

    Objects
    Here is the list of SPE memory region objects i found in HV 3.15.
    Address in HV dump LPAR id SPE LPAR Start Address Size Physical Address Flags log2(Page Size)
    0x003ABC20 2 1 0x4C0000880000 0x80000 0x20000080000 0xA000000000000000 0xC
    0x003AAD70 2 2 0x4C0000980000 0x80000 0x20000100000 0xA000000000000000 0xC
    0x003A8880 2 3 0x4C0000780000 0x80000 0x20000180000 0xA000000000000000 0xC
    0x003B4F70 2 4 0x4C0000A80000 0x80000 0x20000200000 0xA000000000000000 0xC
    0x003AB700 2 5 0x4C0000680000 0x80000 0x20000280000 0xA000000000000000 0xC
    0x003B5BE0 2 6 0x4C0000B80000 0x80000 0x20000300000 0xA000000000000000 0xC
    SPE Shadow Registers Memory Region class
    This type of memory region represents shadow registers memory region of a SPE. It's created e.g. in lv1_construct_logical_spe or in syscall 0x10040.

    vtable
    0x00358448 (3.15)

    Objects
    Here is the list of SPE Shadow Registers memory region objects i found in HV 3.15.
    Address in HV dump LPAR id SPE LPAR Start Address Size Physical Address Flags log2(Page Size)
    0x003ABDA0 2 1 0x300000012000 0x1000 - 0xA000000000000000 0xC
    0x003B4290 2 2 0x300000014000 0x1000 - 0xA000000000000000 0xC
    0x003A8A00 2 3 0x300000010000 0x1000 - 0xA000000000000000 0xC
    0x003B50F0 2 4 0x300000016000 0x1000 - 0xA000000000000000 0xC
    0x001FFC90 2 5 0x30000000E000 0x1000 - 0xA000000000000000 0xC
    0x003AE5B0 2 6 0x300000018000 0x1000 - 0xA000000000000000 0xC
    Device MMIO Memory Region class
    This type of memory region is created when a device MMIO region is mapped into LPAR address space, e.g. in lv1_map_device_mmio_region.

    vtable
    0x00352468 (3.15)

    Member variables
    offset 0xA8 - physical address where the device MMIO region is mapped to

    Objects
    Here is the list of Device MMIO memory region objects i found in HV 3.15.
    Address in HV dump LPAR id LPAR Start Address Size Flags log2(Page Size) Physical Address Device
    0x001FDF00 2 0x4000001D0000 0x10000 0x8000000000000000 0xC 0x24003010000 USB controller
    0x003B3850 2 0x400000200000 0x10000 0x8000000000000000 0xC 0x24003020000 USB controller
    0x003B6E50 2 0x4000001E0000 0x10000 0x8000000000000000 0xC 0x24003810000 USB controller
    0x003B9950 2 0x4000001F0000 0x10000 0x8000000000000000 0xC 0x24003820000 USB controller
    GPU Device Memory Region class
    This type of memory region is created e.g. in lv1_gpu_open, lv1_gpu_device_map and lv1_undocumented_function_114.

    vtable
    0x00357C48 (3.15)

    Member variables
    offset 0xA8 - physical address

    Objects
    Here is the list of Device GPU memory region objects i found in HV 3.15.
    Address in HV dump LPAR id LPAR Start Address Size Flags log2(Page Size) Physical Address
    0x003AF380 2 0x700190000000 0xFE00000 0x8000000000000000 0x14 0x28080000000
    0x003AF500 2 0x4000001A0000 0xC000 0x8000000000000000 0xC 0x3C0000
    0x003AF680 2 0x4800006C0000 0x40000 0x8000000000000000 0xC 0x2808FE00000
    0x003AFC30 2 0x440000380000 0x20000 0x8000000000000000 0xC 0x28000C00000
    0x003BB420 2 0x3C0000108000 0x8000 0x8000000000000000 0xC 0x28000080100
    Methods
    LPAR_get_memory_region_by_start_address - 0x002C7C40 (3.15)
    LPAR_get_memory_region_by_address - 0x002C7DA8 (3.15)
    LPAR_mem_addr_to_phys_addr(LPAR id, LPAR address, phys_addr) - 0x002FB8F0 (3.15)

    Network Devices

    Ethernet Gelic Device
    device id = 0

    MAC Address: 00:1F:A7:C6:2A:C5

    device memory base address = 0x24003004000 (size = 0x1000)

    WLAN Gelic Device
    device id = 0

    MAC Address: 02:1F:A7:C6:2A:C5 (locally administered)

    Net Manager
    Net Manager runs in Process 9
    It sends commands to /dev/sc1 to reset WLAN Gelic device
    It opens /dev/net0, sets MAC address and writes device firmware eurus_fw.bin to WLAN device by using ioctl syscall

    /dev/net0
    The device supports 3 ioctl commands:

    0 - 0x002AC10C (3.15)
    1 - 0x002AC250 (3.15)
    2 - EURUS_STAT 0x002AC320 (3.15)

    Methods
    net_control_cmd_GELIC_LV1_POST_WLAN_CMD - 0x0024A55C (3.15)
    net_control_wlan_cmd_GELIC_EURUS_CMD_ASSOC - 0x00246C78 (3.15)
    net_control_wlan_cmd_GELIC_EURUS_CMD_START_SCAN - 0x00248A14 (3.15)
    net_control_wlan_cmd_GELIC_EURUS_CMD_SET_WEP_CFG - 0x00249F24 (3.15)
    net_control_wlan_cmd_GELIC_EURUS_CMD_SET_WPA_CFG - 0x002497B8 (3.15)

    Event Notification
    Event Notfication is used e.g. to notify a LPAR about some event, e.g. device interrupt or notify a LPAR about destruction of another LPAR.
    For example Process 9 is notified through Event Notification when LPAR 2 is destructed.
    During LPAR construction, Process 9 creates an Outlet object with syscall 0x1001A and then passes the outlet ID to the syscall 0x10009 that constructs the LINUX LPAR. In this way Process 9 is notified when LINUX LPAR is destructed.

    Outlet class
    This is the base Outlet class. There are different types of Outlet and they derive from this base class.

    vtable
    0x00357DC0 (3.15)

    Member variables
    offset 0x30 - type (8 bytes)
    offset 0x38 - pointer to LPAR that owns this Outlet object
    offset 0x48 - outlet id (8 bytes)
    offset 0x90 - VIRQ assigned to this Outlet object (4 bytes)

    Event Receive Port class
    This type of Outlet is created e.g. in lv1_construct_event_receive_port and in syscall 0x1001A.
    HV calls lv1_connect_irq_plug and lv1_connect_irq_plug_ext assigns a VIRQ to Event Receive Port object.

    vtable
    0x00357E88

    VUART Outlet
    HV supports only one VUART Outlet per LPAR
    lv1_configure_virtual_uart_irq constructs a VUART Outlet object and passes the address of LPAR's VUART IRQ Bitmap to HV

    vtable
    0x00357DC0

    VUART IRQ Bitmap
    At address 0x38(LPAR ptr) + 0x158 is the VUART IRQ Bitmap owned by HV for LPAR (4 * 8 bytes = 256 bits)
    At address 0x38(LPAR ptr) + 0x150 is stored the physical address of LPAR's VUART IRQ Bitmap that was passed to lv1_configure_virtual_uart_irq
    When a VUART interrupt is generated by HV then first the VUART IRQ Bitmap owned by HV is updated and then this bitmap is copied to LPAR's VUART IRQ Bitmap, so VUART IRQ Bitmap is stored twice, once in HV and once in LPAR, just like IRQ State Bitmap

    Logical PPE
    Logical PPE is used for interrupt management of LPAR.
    A Logical PPE object is created in syscall 0x10005. It' used e.g. in Process 9 during LPAR construction.
    syscall 0x10007 activates a Logical PPE object
    0x67F0(HSPRG0) - pointer to currently active Logical PPE object (in HV dump it points to Linux PPE object naturally because the dump was made on Linux, so Linux LPAR was active at that time)
    E.g. lv1_get_logical_ppe_id, lv1_start_ppe_periodic_tracer and lv1_set_ppe_periodic_tracer_frequency grab the currently active Logical PPE object

    vtable
    0x00357DF0 (3.15)

    Member variables
    offset 0x90 - pointer to an object that contains VIRQ-Outlet mapping table for thread 0
    offset 0x98 - pointer to an object that contains VIRQ-Outlet mapping table for thread 1

    Objects
    Here is the list of Logical PPE objects i found in HV 3.15.

    Address in HV dump LPAR id PPE id
    0x0069C7F0 1 1
    0x007A8900 2 1
    Virtual IRQ - Outlet Mapping
    HV maintains 2 tables per PPE that map a VIRQ to an Outlet object.
    The table has 256 entries and is indexed by VIRQ.
    Each entry is a pointer to Outlet object.
    Each Logical PPE object has 2 tables, one for each thread of Cell CPU.

    LPAR 1 PPE 1 Thread 0
    0x0069C990 (3.15) - address of VIRQ-Outlet table for LPAR 1 PPE 1 Thread 0 (not empty)

    VIRQ Address of Outlet object in HV dump Description
    58 0x00090D10 -
    59 0x006BAC50 -
    60 0x006B3ED0 FLASH storage device / Storage device notification for LPAR 1
    61 0x00697E70 VUART interrupts
    62 0x001C8F20 -
    LPAR 1 PPE 1 Thread 1
    0x0069D9B0 (3.15) - address of VIRQ-Outlet table for LPAR 1 PPE 1 Thread 1 (empty)

    LPAR 2 PPE 1 Thread 0
    0x000A06B0 (3.15) - address of VIRQ-Outlet table for LPAR 2 PPE 1 Thread 0 (not empty)

    VIRQ Address of Outlet object in HV dump Description
    20 0x003AA210 -
    21 0x003AFEC0 -
    22 0x001FC010 -
    23 0x003A8E50 -
    24 0x001FFED0 SPE 0 Class 0 Interrupt
    25 0x003AE160 SPE 0 Class 1 Interrupt
    26 0x003AE350 SPE 0 Class 2 Interrupt
    27 0x003AB100 SPE 1 Class 0 Interrupt
    28 0x003AB2F0 SPE 1 Class 1 Interrupt
    29 0x003AB4E0 SPE 1 Class 2 Interrupt
    30 0x003AA6A0 SPE 2 Class 0 Interrupt
    31 0x003AA890 SPE 2 Class 1 Interrupt
    32 0x003AAA80 SPE 2 Class 2 Interrupt
    33 0x003B44A0 SPE 3 Class 0 Interrupt
    34 0x003B4690 SPE 3 Class 1 Interrupt
    35 0x003B4AD0 SPE 3 Class 2 Interrupt
    36 0x003B5300 SPE 4 Class 0 Interrupt
    37 0x003B54F0 SPE 4 Class 1 Interrupt
    38 0x003B56E0 SPE 4 Class 2 Interrupt
    39 0x003AE7C0 SPE 5 Class 0 Interrupt
    40 0x003AE9B0 SPE 5 Class 1 Interrupt
    41 0x003AEBA0 SPE 5 Class 2 Interrupt
    42 0x003B2040 Storage device notification for LPAR 2
    43 0x003AEE30 VUART interrupts
    44 0x001FEAA0 -
    45 0x001FEED0 HDD storage device
    46 0x003B5E20 -
    47 0x003B7040 -
    48 0x003B9B40 -
    49 0x003B3A40 -
    50 0x003BACA0 Gelic device
    51 0x003BAE10 UNKNOWN storage device
    52 0x003B8350 -
    LPAR 2 PPE 1 Thread 1
    0x007A89E0 (3.15) - address of VIRQ-Outlet table for LPAR 2 PPE 1 Thread 1 (not empty)

    VIRQ Address of Outlet object in HV dump Description
    16 0x003B2480 -
    17 0x003B2590 -
    18 0x003B26A0 -
    19 0x003B27B0 -
    IRQ State Bitmap
    There is one IRQ State Bitmap (256 bits = 32 bytes) per thread of Logical PPE
    HSPRG0 value is per thread, so there are 2 HSPRG0 values in HV dump !!!
    The IRQ State Bitmap of a thread is stored at -0x68E0(HSPRG0)
    When an Event or Interrupt happens then the bitmap at 0x68E0(HSPRG0) is updated
    The physical address of LPAR's IRQ State Bitmap of thread is stored at offset -0x68C0(HSPRG0)
    The address of LPAR's IRQ State Bitmap is passed to Hypervisor through HV call lv1_configure_irq_state_bitmap
    The IRQ State Bitmap is updated if an Outlet object is assigned to VIRQ and when Outlet generates an event
    After IRQ State Bitmap update, it's copied to LPAR's IRQ State Bitmap and a hardware interrupt is generated so that LPAR can read it's IRQ State Bitmap and handle interrupts
    So, IRQ State Bitmap is stored twice, once in HV and once in LPAR, just like VUART IRQ Bitmap

    0x8941FC0 - physical address of LPAR's IRQ State Bitmap for Thread 0 of LINUX LPAR
    0x8948FC0 - physical address of LPAR's IRQ State Bitmap for Thread 1 of LINUX LPAR

    System Controller (SC or SYSCON)
    Data received from SC is sent to a VUART
    VUART Table
    There are 5 VUARTs for SC in HV 3.15
    Here is the SC VUART table from HV 3.15:

    Index Address of VUART object in HV dump Description
    0 0x0060FD20 This VUART is connected with the VUART 0 (/dev/sc0) of LPAR 1
    1 0x0060FE20 This VUART is connected with the VUART 1 (/dev/sc1) of LPAR 1
    2 0x0060FF20 This VUART is not connected to some peer VUART but i guess that it should be connected to VUART 2 (/dev/sc2) of LPAR1
    3 0x006124E0 This VUART is connected with the VUART 3 (/dev/sc3) of LPAR 1
    4 0x00612DF0 This VUART is connected to a VUART that i couldn't identify yet.
    Interrupt Handling
    spider_sc_interrupt_handler - 0x0020A68C (3.15)

    Lv-2 functions

    List of useful functions in LV2 kernel

    string.h
    Function Notes Offset in 3.41 Offset in 3.15
    Offset in 3.10
    Offset in 3.01
    Offset in 2.76

    char *strcpy(char *dest, const char *src)
    0x04D2F0 0x4CDAC
    0X4CDA8
    0x4AAC4
    0x469B8

    int strlen(char *str)
    0x04D318 0X4CDD4
    0X4CDD0
    0x4AAEC
    0x469E0

    char *strcat(char *destination, const char *source)

    0x04D220
    0x04CCDC

    char *strchr(const char* str, char chr)

    0x04D258
    0x04CD14

    char *strrchr(const char* str, char chr)

    0x04CEE4

    int strcmp(const char *s1, const char *s2)

    0x04D29C
    0x04CD58

    int strncmp(const char *s1, const char *s2, size_t n)
    0x04D344 0X4CE00
    0X4CDFC
    0x4AB18
    0x46A0C

    char *strncpy(char *destination, const char *source, size_t num)

    0x04D3B8
    0x04CE74

    int memcmp(void *v1, void *v2, size_t n)
    0x04C454 0x04BF10

    void *memchr(void *s, int c, size_t n)

    0x04BEC0

    void *memcpy(void *dest, const void *src, size_t n)
    0x07C01C 0X7BE9C
    0X7BE98
    0x77E84
    0x7395C

    void *memset(void *s, int c, size_t n)
    0x04D144 0X4CC00
    0X4CBFC
    0x4A95C
    0x46850
    stdio.h
    Function Notes Offset in 3.41 Offset in 3.15

    int snprintf(char *str, size_t size, char *format, ...)
    0x04E4D8 0x04DF94

    int sprintf(char *str, char *format, ...)
    0x04E56C 0x04E028

    int printf(char *format, ...) This prints to the serial debug console. 0x28A654 0x28A11C
    lv2
    Function Notes Offset in 3.41 Offset in 3.15 Offset in 3.10 Offset in 3.01 Offset in 2.76

    void* alloc(size_t size, int unk) unk is possibly pool? PSGroove uses 0x27. 0x62088 0x61CF0 0x61CEC 0x5DF4C 0x59D54

    void dealloc(void* ptr, int unk) unk is possibly pool? Should be the same value of unk given to alloc. 0x624C8 0x62138 0x62134 0x5E38C 0x5A194

    void process_utils::create_initial_system_process() Called to start the first userspace process, which is normally "sys_init_osd.self" but it can also launch recovery mode or update mode. 0x287D50 0x287858

    void Panic(int unk) This function does not return.

    (It seems that the offset point to a location that will cause panic after, not the real panic function, use with caution)
    0x288568

    USBGetDeviceDescriptor
    USB function
    0xd2998
    0xd3474

    0xCCD2C

    USBOpenEndpoint

    0xd29c4
    0xd34ac

    0xCCD58

    USBControlTransfer

    0xd292c
    0xd3408

    0xCCCC0

    USBRegisterDriver

    0xd22d8
    0xd2978

    0xCC6A0
    Lv2 System Table Offset
    FW version
    Offset


    3.41
    0x2EB128

    3.15
    0x2EA820

    3.10
    0x2EA820

    3.01
    0x2CFB40

    2.76
    0x2C4318

    [Register or Login to view code]

    Lv-2 syscalls

    Number Name Notes

    1 sys_process_getpid
    2 sys_process_wait_for_child
    4 sys_process_get_status
    5 sys_process_detach_child
    12 sys_process_get_number_of_object
    13 sys_process_get_id
    14 sys_process_is_spu_lock_line_reservation_address
    18 sys_process_getppid
    19 sys_process_kill
    23 sys_process_wait_for_child2
    25 sys_process_get_sdk_version
    43 sys_ppu_thread_yield
    44 sys_ppu_thread_join
    45 sys_ppu_thread_detach
    46 sys_ppu_thread_get_join_state
    47 sys_ppu_thread_set_priority
    48 sys_ppu_thread_get_priority
    49 sys_ppu_thread_get_stack_information
    56 sys_ppu_thread_rename
    57 sys_ppu_thread_recover_page_fault
    67 sys_trace_allocate_buffer
    68 sys_trace_free_buffer
    69 sys_trace_create2
    70 sys_timer_create
    71 sys_timer_destroy
    72 sys_timer_get_information
    73 sys_timer_start
    74 sys_timer_stop
    75 sys_timer_connect_event_queue
    76 sys_timer_disconnect_event_queue
    80 sys_interrupt_tag_create
    81 sys_interrupt_tag_destroy
    84 sys_interrupt_thread_establish
    88 sys_interrupt_thread_eoi
    89 sys_interrupt_thread_disestablish
    90 sys_semaphore_create
    91 sys_semaphore_destroy
    92 sys_semaphore_wait
    93 sys_semaphore_trywait
    94 sys_semaphore_post
    100 sys_mutex_create
    101 sys_mutex_destroy
    102 sys_mutex_lock
    103 sys_mutex_trylock
    104 sys_mutex_unlock
    105 sys_cond_create
    106 sys_cond_destroy
    107 sys_cond_wait
    108 sys_cond_signal
    109 sys_cond_signal_all
    110 sys_cond_signal_to
    114 sys_semaphore_get_value
    120 sys_rwlock_create
    121 sys_rwlock_destroy
    122 sys_rwlock_rlock
    123 sys_rwlock_tryrlock
    124 sys_rwlock_runlock
    125 sys_rwlock_wlock
    126 sys_rwlock_trywlock
    127 sys_rwlock_wunlock
    128 sys_event_queue_create
    129 sys_event_queue_destroy
    130 sys_event_queue_receive
    131 sys_event_queue_tryreceive
    133 sys_event_queue_drain
    134 sys_event_port_create
    135 sys_event_port_destroy
    136 sys_event_port_connect_local
    137 sys_event_port_disconnect
    138 sys_event_port_send
    140 sys_event_port_connect_ipc
    141 sys_timer_usleep
    142 sys_timer_sleep
    145 sys_time_get_current_time
    147 sys_time_get_timebase_frequency
    150 sys_raw_spu_create_interrupt_tag
    151 sys_raw_spu_set_int_mask
    152 sys_raw_spu_get_int_mask
    153 sys_raw_spu_set_int_stat
    154 sys_raw_spu_get_int_stat
    156 sys_spu_image_open
    160 sys_raw_spu_create
    161 sys_raw_spu_destroy
    163 sys_raw_spu_read_puint_mb
    165 sys_spu_thread_get_exit_status
    166 sys_spu_thread_set_argument
    167 sys_spu_thread_group_start_on_exit
    169 sys_spu_initialize
    170 sys_spu_thread_group_create
    171 sys_spu_thread_group_destroy
    172 sys_spu_thread_initialize
    173 sys_spu_thread_group_start
    174 sys_spu_thread_group_suspend
    175 sys_spu_thread_group_resume
    176 sys_spu_thread_group_yield
    177 sys_spu_thread_group_terminate
    178 sys_spu_thread_group_join
    179 sys_spu_thread_group_set_priority
    180 sys_spu_thread_group_get_priority
    181 sys_spu_thread_write_ls
    182 sys_spu_thread_read_ls
    184 sys_spu_thread_write_snr
    185 sys_spu_thread_group_connect_event
    186 sys_spu_thread_group_disconnect_event
    187 sys_spu_thread_set_spu_cfg
    188 sys_spu_thread_get_spu_cfg
    190 sys_spu_thread_write_spu_mb
    191 sys_spu_thread_connect_event
    192 sys_spu_thread_disconnect_event
    193 sys_spu_thread_bind_queue
    194 sys_spu_thread_unbind_queue
    196 sys_raw_spu_set_spu_cfg
    197 sys_raw_spu_get_spu_cfg
    198 sys_spu_thread_recover_page_fault
    199 sys_raw_spu_recover_page_fault
    244 sys_spu_thread_group_system_set_next_group
    245 sys_spu_thread_group_system_unset_next_group
    246 sys_spu_thread_group_system_set_switch_group
    247 sys_spu_thread_group_system_unset_switch_group
    251 sys_spu_thread_group_connect_event_all_threads
    252 sys_spu_thread_group_disconnect_event_all_threads
    260 sys_spu_image_open_by_fd
    327 sys_mmapper_enable_page_fault_notification
    329 sys_mmapper_free_shared_memory
    330 sys_mmapper_allocate_address
    331 sys_mmapper_free_address
    332 sys_mmapper_allocate_shared_memory
    333 sys_mmapper_set_shared_memory_flag
    334 sys_mmapper_map_shared_memory
    335 sys_mmapper_unmap_shared_memory
    336 sys_mmapper_change_address_access_right
    337 sys_mmapper_search_and_map
    338 sys_mmapper_get_shared_memory_attribute
    341 sys_memory_container_create
    342 sys_memory_container_destroy
    343 sys_memory_container_get_size
    348 sys_memory_allocate
    349 sys_memory_free
    350 sys_memory_allocate_from_container
    351 sys_memory_get_page_attribute
    352 sys_memory_get_user_memory_size
    378 sys_sm_get_ext_event2
    402 sys_tty_read
    403 sys_tty_write
    450 sys_overlay_load_module
    451 sys_overlay_unload_module
    452 sys_overlay_get_module_list
    453 sys_overlay_get_module_info
    454 sys_overlay_load_module_by_fd
    455 sys_overlay_get_module_info2
    456 sys_overlay_get_sdk_version
    457 sys_overlay_get_module_dbg_info
    461 sys_prx_get_module_id_by_address
    463 sys_prx_load_module_by_fd
    464 sys_prx_load_module_on_memcontainer_by_fd
    480 sys_prx_load_module
    481 sys_prx_start_module
    482 sys_prx_stop_module
    483 sys_prx_unload_module
    484 sys_prx_register_module
    485 sys_prx_query_module
    486 sys_prx_register_library
    487 sys_prx_unregister_library
    488 sys_prx_link_library
    489 sys_prx_unlink_library
    490 sys_prx_query_library
    494 sys_prx_get_module_list
    495 sys_prx_get_module_info
    496 sys_prx_get_module_id_by_name
    497 sys_prx_load_module_on_memcontainer
    498 sys_prx_start
    499 sys_prx_stop
    600 sys_storage_open
    601 sys_storage_close
    602 sys_storage_read
    603 sys_storage_write
    604 sys_storage_send_device_command
    605 sys_storage_async_configure
    606 sys_storage_async_read
    607 sys_storage_async_write
    608 sys_storage_async_cancel
    609 sys_storage_get_device_info
    610 sys_storage_get_device_config
    611 sys_storage_report_devices
    612 sys_storage_configure_medium_event
    613 sys_storage_set_medium_polling_interval
    614 sys_storage_create_region
    615 sys_storage_delete_region
    616 sys_storage_execute_device_command
    617 sys_storage_get_region_acl
    618 sys_storage_set_region_acl
    624 sys_io_buffer_create
    625 sys_io_buffer_destroy
    626 sys_io_buffer_allocate
    627 sys_io_buffer_free
    630 sys_gpio_set
    631 sys_gpio_get
    633 sys_fsw_connect_event
    634 sys_fsw_disconnect_event
    666 sys_rsx_device_open
    667 sys_rsx_device_close
    668 sys_rsx_memory_allocate
    669 sys_rsx_memory_free
    670 sys_rsx_context_allocate
    671 sys_rsx_context_free
    672 sys_rsx_context_iomap
    673 sys_rsx_context_iounmap
    674 sys_rsx_context_attribute
    675 sys_rsx_device_map
    676 sys_rsx_device_unmap
    677 sys_rsx_attribute
    871 sys_ss_access_control_engine
    872 sys_ss_get_open_psid
    873 sys_ss_get_cache_of_product_mode
    874 sys_ss_get_cache_of_flash_ext_flag
    875 sys_ss_get_boot_device
    876 sys_ss_disc_access_control
    878 sys_ss_ad_sign
    879 sys_ss_media_id
    880 sys_deci3_open
    881 sys_deci3_create_event_path
    882 sys_deci3_close
    883 sys_deci3_send
    884 sys_deci3_receive
    Network Syscall
    Networking uses syscalls 700-726
    Number Name Notes

    700 sys_net_bnet_accept
    701 sys_net_bnet_bind
    702 sys_net_bnet_connect
    703 sys_net_bnet_getpeername
    704 sys_net_bnet_getsockname
    705 sys_net_bnet_getsockopt
    706 sys_net_bnet_listen
    707 sys_net_bnet_recvfrom
    708 sys_net_bnet_recvmsg
    709 sys_net_bnet_sendmsg
    710 sys_net_bnet_sendto
    711 sys_net_bnet_setsockop
    712 sys_net_bnet_shutdown
    713 sys_net_bnet_socket
    714 sys_net_bnet_close
    715 sys_net_bnet_poll
    716 sys_net_bnet_select
    717 unknown
    718 unknown
    719 unknown
    720 unknown
    721 unknown
    722 unknown
    723 unknown
    724 sys_net_bnet_ioctl
    725 sys_net_bnet_sysctl
    726 unknown
    File Syscalls

    Number Name Notes

    801 lv2FsOpen
    802 lv2FsRead
    803 lv2FsWrite
    804 lv2FsClose
    805 lv2FsOpenDir
    806 lv2FsReadDir
    807 lv2FsCloseDir
    808 lv2FsStat
    809 lv2FsFstat
    810 lv2FsLink
    811 lv2FsMkdir
    812 lv2FsRename
    813 lv2FsRmdir
    814 lv2FsUnlink
    815 lv2FsUtime

    818 lv2FsLSeek

    820 lv2FsFSync

    831 lv2FsTruncate
    832 lv2FsFTruncate

    834 lv2FsChmod

  3. #3
    Contributor lusal's Avatar
    Join Date
    Sep 2010
    Posts
    10
    Sponsored Links
    Sponsored Links
    Got it. Witchcraft and Voodoo. I knew it all along!

  4. #4
    Banned User
    Join Date
    Nov 2009
    Posts
    508
    Oh, now I get it.... NOT!

    Well, its great progress

  5. #5
    Banned User
    Join Date
    Mar 2008
    Posts
    303
    this is a whole bunch of informations.
    'im happy that i know asm, otherwise i only would understand 1% of this o.O

    great work from this guy.
    it's funny that everytime new people gives informations out. before yesterday i never heared of this guy.

    greetings
    Warrorar

  6. #6
    Registered User Sterist's Avatar
    Join Date
    Oct 2010
    Posts
    48
    i know what you meant to say but apparently he's not new lol

  7. #7
    Senior Member BwE's Avatar
    Join Date
    Apr 2010
    Posts
    709
    you can make a novel out of this. geez enough info?

  8. #8
    Junior Member solrac1974's Avatar
    Join Date
    Aug 2010
    Posts
    203
    Great news, now Devs can progress even more towards a CFW or at least a new FW with JB support!

  9. #9
    Junior Member p0tsm0ke's Avatar
    Join Date
    Jul 2005
    Posts
    17
    good info that was shared thanks

  10. #10
    Member SinnerShanky's Avatar
    Join Date
    Oct 2010
    Posts
    172
    i don't understand it but still i know it's a great step towards getting the jb for fw 3.50...

 

Sponsored Links
Page 1 of 2 12 LastLast
Advertising - Affiliates - Contact Us - PS3 Downloads - Privacy Statement - Site Rules - Top - © 2014 PlayStation 3 News