Editing Hypervisor Reverse Engineering

Jump to navigation Jump to search
Warning: You are not logged in. Your IP address will be publicly visible if you make any edits. If you log in or create an account, your edits will be attributed to your username, along with other benefits.

The edit can be undone. Please check the comparison below to verify that this is what you want to do, and then publish the changes below to finish undoing the edit.

Latest revision Your text
Line 4,772: Line 4,772:
*The size of the body depends on a used service.
*The size of the body depends on a used service.


== 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  ==
{| class="wikitable FCK__ShowTableBorders"
|-
! Packet ID
! Description
|-
| 0x17001
| Read EID Data Size By Index/Read metldr Size
|-
| 0x17002
| Read EID Data By Index/Read metldr
|-
| 0x17003
| Read ID Data
|-
| 0x17004
| Read System Data
|-
| 0x17005
| Write System Data?
|-
| 0x17006
| Write smth?
|-
| 0x17007
| Read System Data From EEPROM
|-
| 0x17008
| not implemented
|-
| 0x17009
| unknown
|-
| 0x1700A
| not implemented
|-
| 0x1700B
| not implemented
|-
| 0x1700C
| not implemented
|-
| 0x1700D
| not implemented
|-
| 0x1700E
| not implemented
|-
| 0x1700F
| not implemented
|-
| 0x17010
| unknown
|-
| 0x17011
| unknown
|-
| 0x17012
| unknown
|-
| 0x17013
| Read eEID Size
|-
| 0x17014
| Write eEID/Write metldr
|-
| 0x17015
| Read cISD Size
|-
| 0x17016
| Read cISD
|-
| 0x17017
| Write cISD
|}
*Indi Info Manager is accessed e.g. in '''syscall 868''' on GameOS
=== 0x17001 - Read EID Data Size By Index  ===
*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 EID size.
{| class="wikitable FCK__ShowTableBorders"
|-
! Index
! Size Of Data
! Description
|-
| 0
| 0x860
| EID0
|-
| 1
| 0x2A0
| EID1
|-
| 2
| 0x730
| EID2
|-
| 3
| 0x100
| EID3
|-
| 4
| 0x030
| EID4
|-
| 5
| 0xA00
| EID5
|-
| 6
| 0x020
| cISD0
|-
| 7
| 0x200
| cISD1
|-
| 8
| 0x010
| cISD2
|-
| 9
| 0x030
| cCSD0
|-
| 0x1000
| 0xe960
| metldr - size is version dependand
|}
=== 0x17002 - Read EID Data By Index  ===
*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 EID Data Size By Index'''
*The 2nd parameter is '''EID Data Size''' that is returned by the service '''Read EID Data Size By Index'''
*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'''.
*E.g. EID4 data is passed by Storage Manager to SPU module '''sb_iso_spu_module.self'''.
=== 0x17004 - Read System Data  ===
*Reads data from '''cISD''' or '''cCSD''' files stored on '''/dev/rflash1'''.
*E.g. Gelic MAC address is stored in file '''cISD'''.
=== 0x17007 - Read System Data From EEPROM  ===
*Reads data from SC EEPROM
*An index is passed to the service. The index is mapped to a specific SC EEPROM offset.
Here is the list of possible EEPROM offsets from HV 3.15:
{| class="wikitable FCK__ShowTableBorders"
|-
! Index
! SC EEPROM Offset
! Size Of Data
|-
| 0
| 0x48D20
| 6
|-
| 1
| 0x48D28
| 6
|-
| 2
| 0x48D30
| 6
|-
| 3
| 0x48D38
| 6
|-
| 4
| 0x48D00
| 4
|-
| 5
| 0x48D04
| 4
|-
| 6
| 0x48D08
| 4
|}
=== 0x17014 - Write eEID/Write metldr  ===
*'''Holy crap, it writes passed data to the region of FLASH memory where eEID or metldr data is stored !!!'''
*'''And GameOS is allowed to use this service !!!'''
*'''Do not experiment with this service if you don't know what it does or else your PS3 will not work anymore !!!'''
=== 0x17015 - Read cISD Size  ===
*Returns size of data '''cISD''' that is stored on '''FLASH storage device region 0'''
=== 0x17016 - Read cISD  ===
*Returns data '''cISD''' that is stored on '''FLASH storage device region 0'''
=== 0x17017 - Write cISD  ===
*'''Writes passed data to the region of FLASH memory where cISD data is stored !!!'''
== 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.
*DM overwrites the LAID sent in SS packet header with the LAID of the LPAR that sent the request. So, no matter what LAID you send in SS packet header, it will be always overwritten with the correct one by DM. That is the reason why e.g. USB Dongle Master Key cannot be decrypted by GameOS without patching DM. But with HV access rights, DM can be easily patched and access to SYSCON can be gained.
*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)
{| class="wikitable FCK__ShowTableBorders"
|-
! Packet 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
<pre>struct dispmgr_header
{
    uint32_t request_id;
    uint32_t function_id;
    uint32_t request_size;        /* payload size of request */
    uint32_t response_size;        /* payload size of response */
}
</pre>
=== 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:
{| class="wikitable FCK__ShowTableBorders"
|-
! 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
|}
== 0x25000 - User Token Manager  ==
{| class="wikitable FCK__ShowTableBorders"
|-
! 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  ====
<pre>stuct user_token_attr
{
    uint32_t type;                                /* 0x00000001, value&nbsp;!= 0x00000001 means attribute list ends here */
    uint32_t size;                                /* 8 + sizeof(data) */
    /* data follows here, size of data may be 0 */
}
struct user_token
{
    uint32_t magic;                                /* 0x73757400 = "sut\0" */
    uint32_t format_version;                      /* 0x00000001 */
    uint64_t size;
    uint8_t idps[16];
    uint64_t expire_date;
    uint64_t capability;
    union
    {
        stuct user_token_attr attrs[0];
        uint8_t dummy[3072];
    } attrs;
    /* 0xC30 */
    uint8_t digest[20];
}
</pre>
= LPAR Memory Management  =
= LPAR Memory Management  =


Please note that all contributions to PS3 Developer wiki are considered to be released under the GNU Free Documentation License 1.2 (see PS3 Developer wiki:Copyrights for details). If you do not want your writing to be edited mercilessly and redistributed at will, then do not submit it here.
You are also promising us that you wrote this yourself, or copied it from a public domain or similar free resource. Do not submit copyrighted work without permission!

To protect the wiki against automated edit spam, we kindly ask you to solve the following hCaptcha:

Cancel Editing help (opens in new window)

Templates used on this page:

Retrieved from "http://www.psdevwiki.com/ps3/Hypervisor_Reverse_Engineering"