[DESARROLLO] PSGROOVE Payload Custom (V4B)

Wismaster escribió:
Oren_Hishii escribió:Habeis leido lo ultimo de graf_chokolo? yo creo q hermes estara recopilando info sobre este tema pq es muuuuuuuuuuuuy interesante...



que es lo ultimo de graf_chokolo??


Está desencriptando el firmware 3.50 e intentando coger al hypervisor por los cuernos.
Nunca lo hubiese dicho mejor...nos esperan grandes noticias en breve.Ademas mathieuh ha publicado PSID patch para que las consolas baneadas vuelvan a tener vida.

EDIT:Info sobre la publicacion de graf_chokolo

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, and its belived to be the memory space wherre lv1 stores its variables, flags and other data.

lpar2 starts at 0x80000000000 and it's belived 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.
void hash(unsigned long long n1,
unsigned long long n2,
unsigned long long n3,
unsigned long long n4,
unsigned long *h1,
unsigned long *h2)
{
unsigned long long h;
unsigned long hl;

h = ((((n1 ^ n4) >> 32) ^ (n2 ^ n3)) ^ (((n2 ^ n3) >> 32) ^ (n1 ^ n4))) & ~0xC0000000ULL;

*h1 = h & 0xFFFFFFFFULL;

h = ((h & 0x55555555ULL) > 1);

h = ((h & 0x33333333ULL) > 2);

h = ((h & 0xF0F0F0FULL) > 4);

hl = (h > 24);

hl = (hl & ~0xFF000000UL) | ((h & 0xFFULL) 8)) & 0x0000FF00ULL);

hl |= 0x1;

*h2 = hl;
}
Repository nodes from HV 3.15
Dump of all repository nodes from HV 3.15

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)
* 0x00180000 - HTAB PTEs (HTAB size 256 kB)
0x003A8050 (VAS id 3, LPAR 2)
* 0x00500000 - HTAB PTEs (HTAB size 1 MB)
0x003BC510 (VAS id 48, LPAR 2)
* 0x00800000 - HTAB PTEs (HTAB size 1 MB)
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.

SID Name Description
0 - -
1 REQUEST -
2 RESPONSE -
3 COMMAND -
4 EXTERN_EVENT -
5 SET_NEXT_OP -
6 - -
7 - -
8 SET_ATTR -
9 GET_INTER_LPAR_PARAM -
10 SET_INTER_LPAR_PARAM -
11 - -
12 CONTROL_LED -
13 TEMPERATURE -
14 - -
15 - -
16 - -
17 - -
18 - -
19 SET_CONFIG -
20 - -
21 RING_BUZZER -
22 - -
23 - -
24 - -
25 FAN_POLICY -
26 REQUEST_ERROR_LOG -
27 - -
28 REQUEST_BE_COUNT -
29 - -
30 REQUEST_SC_VERSION -
31 - -
32 REQUEST_SYSTEM_EVENT_LOG -
33 - -
34 RTC_ALARM -
35 - -
36 RTC_ALARM -
37 - -
38 RTC_ALARM -
39 SET_SHOP_DEMO_MODE -
40 BOOT_PARAMETER -
41 - -
42 BOOT_PARAMETER -
43 - -
44 FACTORY_PROCESS_COMP -
45 - -
46 FACTORY_PROCESS_COMP -
47 - -
48 FACTORY_PROCESS_COMP -
49 - -
50 FAN_POLICY -
51 - -
52 - -
53 - -
54 - -
55 - -
56 - -
57 - -
58 - -
59 - -
60 - -
61 - -

12 - CONTROL_LED
I have tested this service with PSGroove and GameOS is allowed to use it
Packet Body
struct sysmgr_ctrl_led
{
u8 field0;
u8 field1;
u8 field2;
u8 res1;
u8 field4;
u8 field5;
u8 res2[10];
};
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
struct sysmgr_ring_buzzer
{
u8 res1;
u8 field1;
u8 field2;
u8 res2;
u32 field4;
};
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

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.
struct ss_header
{
uint64_t packet_id;
uint64_t function_id;
uint32_t retval;
uint8_t res[4];
uint64_t laid; /* LPAR authority id */
uint64_t paid; /* Program authority id */
}
SS Service Return Values
Error Code Description
0x00000000 Success
0x00000005 Access Violation
0x00000006

Read more: http://www.ps3news.com/PS3-Dev/ps3-hypervisor-reverse-engineering-progress-is-detailed/#ixzz15WdEVOv0
Hola Hermes.
Se está comentando mucho sobre los posibles avances de graf_chokolo, incluso algún scener cree que es algo grande.
Comentanos tú que opinas de todo esto, si puedes explicarnos a los neófitos con palabras llanas de que va el tema y sus posibilidades sería muy de agradecer. También si estos temas te hacen pensar en otras vias de trabajo distintas a tu payload. Todo lo que tu nos comentas siempre es relevante. Gracias.

PD: Cito lo que parece pensar Waninkoko del asunto:

"Ayer cuando se lo comenté a Waninkoko y le echó un vistazo al Wiki me dijo: "Xtreme, me he quedado acojonado con la cantidad de info que tiene este tio", así que hazte una idea de la dimensión del asunto, jeje."
fuente TKC.
Hermes escribió:Pues.. lo único que tengo que comentar de todo esto, es que me parece perfecto [+risas]

¿Que queréis que os diga? XD

Yo ahora mismo, estoy ocupado desarrollando una librería de sonido para trabajar en PS3 y eso es todo lo que me importa en éstos momentos.

Eso y que la gente de Hackerchannel ha actualizado metiendo soporte 3D a PSL1GHT. Todo lo demás, hablando un poco fuerte "me importa una mierda" ahora mismito (y espero que cojáis el buen sentido de mis palabras) y menos cuando ya hay otra gente mas competente ocupándose de esos otros temas..

Por cierto, del tema de evil sperm, pues me parece bien que haga las cosas a su manera, al igual que yo hago lo mismo. Y sobre que llame a sus modificaciones versión "hermes" creo que en este caso, quiere reflejar que se ha basado en mi versión y es una muestra de cortesía: no es lo mismo que si lo usara para lucrarse o que eliminara todo rastro de quienes puedan haber contribuído y pasarlo como suyo, a que a lo mejor el muchacho quiera hacer ver que está modificando o continuando lo que yo hice y queda claro que lo está haciendo el y no yo XD.

Tampoco se pude coger todo por donde quema siempre (y aunque hubiera otras razones que yo no he visto por que no sigo el tema, ahora mismo, "me importa una mierda")

Sobre el tema de si estoy mirando algo o recopilando información, o si habrá una V5, parece evidente que no y que en principio, no la va a haber, pero no olvidéis que eso también es cosa vuestra: el hilo está aquí para todos, los fuentes están aquí y con ligeras mejoras en github. Y yo no tengo necesidad de modificar nada y menos si puede hacerlo otro por mi y yo estoy con otras cosas XD.

Saludos



Querías decir portar?.....

Saludos
Hermes escribió:
cmhacks escribió:Querías decir portar?.....

Saludos


No, desarrollando: Aunque por fuera tendrá casi el mismo formato que mi SND_Lib, por dentro, el código de SPU, el hilo de apoyo, etc, hay que desarrollarlo, jodío [+risas]


[jaja]

Vale, vale, aceptamos barco!!

A ver que tal te queda el tema!!

Saludos
hola!!!!!el hermes sirve para ps3break 1.2????
alguno que sea compatible
Hermes, crees que sería posible conseguir poder cargar juegos de PSX de otras regiones?

Ojo, no hablo de backups, sino juegos originales NTSC en consolas PAL.
Hermes se que estas ocupado en otros temas mas importantes, pero siempre me pregunte el porque algunos juegos de ubisoft no funcionan como el Assassins Creed 1, Prince Of Persia Forgotten Sands, creo que el Prince Of Persia tampoco funciona...
Ya que de por si dan pantalla negra.... tienes alguna idea... o podrias darle una miradita a ver el que cosa rara hacen esos juegos que no funcionan??
yo probe instalandole el pkg debug pero ni asi arranca el juego....
Hermes mirate esto https://github.com/grafchokolo/psgroove


Hasta Mathieulh le ha dado las gracias
Ya era hora de que saliera algo con lo que hacer dumps,de lo que sea, que tanto toquetear sin copias de seguridad me estaba dando algo de reparo.
¿Que será lo próximo, un mediaplayer? ¿y donde están esos juegos homebrew?
en fin un trabajo genial, gracias.
Hermes
♪ ♫ nadie como tú ,du du va ♫ ♪
A partir de ahora habra que buscar un payload basado en v4b de hermes pero completado por otro scener... esa es la conclusion no?
Oren_Hishii escribió:
J313C escribió:Exelente, funciona perfectamente en fw 3.41, lo probe con el "iPod Video 5.5g Hermes V4B" en un "ps3fat" con "fw 3.40" pero no me funciono entonces empece a dudar y me arriesgue a actualizar al "fw 3.41" manualmente(desde la pc se descarga el "fw 3.41" y por usb o hd-ext se pasa al ps3) y de maravilla! Gracias por el esfuerzo Hermes.


Lo has portado a ipod?


Si, asi es. Instale el Hermes V4B en la instalacion que ya tenia de Rockbox en un iPod Video 5.5g .
Hola, tengo un problema y creo que me lo podeis sulocionar o aclararme lo que le pasa a mi PS3.

El caso es que uso mi PS3 Slim con HDMI 1.3 a resolucion 1080i y con el Hermes v4B original. Al arrancar la consola todo va bien, es decir, aparece lo que deberia en el XMB... Pero tambien derrepente pega unos rapidisimos "flasazos", solo en el XMB. Luego ya cuando arranco el OM y cuando la PS3 "se calienta" ya no pasa otra vez. Con la salida RGB de toda la vida no pasa pero cambia muchisimo la calidad. Tambien, arrancandola en modo "normal" no pasa. Os pasa lo mismo que a mi???

Saludos y gracias
Prueba de cambiar el cable hdmi. Por lo que dices, puede ser que el cable o conector no esten bien. o algo mas chungo que se este estropeando algun pic involucrado en la salida del hdmi.
hermes necesito tu ayuda para un proyecto que estoy empezando, se que estaras muy ocupado con tus miles de hacks pero intento hacer algo bueno para la scene necesito tu ayuda, no te mando un mp para no molestarte pero por favor cuando leas esto ponte en contacto conmigo
-----------------------------------------Hermes, que opinas de esto?-----------------------------------------------------
CAMPAÑA SNS de Sony
por ssssO 06 Dic 2010 01:14

Bueno aqui tenéis información privilegiada de un forero, sobre lo que está haciendo sony, espero que sea veraz
al parecer no estamos solos gente de EOL, todo lo contrario SONY ha lanzado una campaña contra la scene de ps3 en nuestras narices y nadie nos hemos dado cuenta

dicha campaña es llamada: "STEALTH NOT SCEENING" parece ser que su mayor golpe ha sido en EUR y ASIA

no pretendo causar controversias con esto. ni que me señalen, soy colaborador y sirvo para esta compañia =( pero no por eso estoy en contra de la SCENE, al contrario

hoy la apoyo mas que nunca, porque me he dado cuenta de todas las jugadas sucias que ha hecho esta compañia contra los SCEENERS para que tiren la toalla y

abandonen sus proyectos. Hoy llegando a las instalaciones me he encontrado con esta forma tan absurda y cobarde de combatir las SCENE (me fié de los informes porque la direccion de expedicion era directa de Kitashinagawa en Tokio, es decir de las oficinas principales de desarrollo, como titulo membretado decia:

CAMPAÑA SNS: "STEALTH NOT SCEENING"

y paginas despues logre identificar una seccion que me llamo mucho la atencion con el subtitulo de:


"Acciones SNS Realizadas Hasta La Fecha:"

*Acciones legales contra el famoso team "PSJAILBREAK"

*Falsificacion del Dispositivo FDebugSHSUSB con titulo del tan famoso SCEENER: HERMES (fue la jugarreta que le hicieron a nuestro amigo HERMES al poner su nombre en un dongle USB y que de esta forma se retirara de la scene. Lo cual lograron

*"Controversias en jaicrab.blogspot" (esto trataba de hacer que el sceener JAICRAB se decepcionara de su trabajo y lo dejara, debido a una serie de mensajes con palabras antisonantes publicados en su BLOG) (FUERON PERSONAS RESIDENTES EN ESPAÑA Y COLABORADORES DE ESTA CAMPAÑA las que hicieron esto). Lo lograron

*La mas reciente, falsificacion de NICKS en la tan conocida pagina "XORLOSER"; en donde se logro que las personas creyeran que se habia obtenido la MASTER KEY, utilizando cobardemente los nicks DE GRAF_CHOKOLO Y ZAXIS para al final que lo desmintieran los verdaderos SCEENERS y los ususarios se volcaran contra ellos haciendolos pasar como FAKERS, y asi que abandonaran sus proyectos PSGRADE y todos los de GRAF_CHOKOLO.

Es lo mas importante que recuerdo hasta el momento....... (no se permiten camaras ni celulares dentro) y ahora lo mas importante:

¿que pretendo con esto?

No pretendo ni ganar fama ni mucho menos dinero, eso nunca!! Yo sé que estoy arriesgando el pellejo porque sinceramente no se si haya alguien infiltrado en EOL )que es lo mas seguro) y me delate y me comiencen en investigar aun asi mientras escribia todo esto ya tome mis precauciones, no las comentare porque no vienen al caso.

Solo pretendo que las personas se den cuenta de que no estamos solos, asi como comence el mensaje, nos siguen los pasos las 24 horas, Y HAGO UN ATENTO LLAMADO a los sceeners que se han rendido por esta estupida campaña, que hasta el momento para los intereses de esta compañia ha tenido muchos resultados.

Repito no se den por vencidos,como no se pueden realizar acciones legales contra nadie, por eso se implemento esta campaña de ingenieria social para llegar hasta los sceeners y terminar con sus expectativas.

Por el momento les he dicho lo que sabia, arriesgando todo lo que tengo, y que es mi unica fuente de dinero: mi trabajo. Pero creo que es algo que las personas no solo de aqui sino de todo el mundo se merecen, ojala este mensaje se les haga llegar a todos los sceeners que desinteresadamente trabajan para poder accesar a todo el hardware de la consola.

PD.- mi depatamento de trabajo no se vincula con los sistemas de seguridad de la consola, por lo tanto yo no puedo decirles cual es la MASTER KEY ni como accesar al lv1
sé que existe mas no tengo acceso a ello. saludos y seguire posteando aqui mientras se me permita
Fuente: hilo_campa-a-sns-de-sony_1530896
Joder y detras de todo esto, esta tambien el MI7 y el servicio de inteligencia Ruso, es evidente que Sony como cualquier empresa vela por sus intereses, pero a mi me da que quien escribe, nos hace llegar esta informacion por que le interesa a alguien que nos llegue.

Señores, llega la campaña navideña y ahora mas que nunca no interesa que muera la scene de PS3, cuanta mas intencion haya de encontrar una cura para el Firm 3.50 mas consolas se van a vender estas navidades, hay muchisima gente que solo va a comprar estas navidades una PS3 pensando en que va a poder utilizar un dongle ó un CF (como en PSP), sin esta ilusion, esta gente no comprara y a Sony esto igual no le interesa.

Ahora aparece este usuario, facilitando esta "informacion privilegiada"? Pues igual esto es otra estrategia, quien sabe!, pero realmente suena mas a uno que se aburre en casa y esta montando una pelicula para que se hable de algo en los foros (rollo como los e-mail de pasalo o te mueres [sonrisa] ).

Salu2.

Hermes perdon por el Off-Topic, pero me ha salido del alma! [fumando]
cj8082 escribió:Joder y detras de todo esto, esta tambien el MI7 y el servicio de inteligencia Ruso, es evidente que Sony como cualquier empresa vela por sus intereses, pero a mi me da que quien escribe, nos hace llegar esta informacion por que le interesa a alguien que nos llegue.

Señores, llega la campaña navideña y ahora mas que nunca no interesa que muera la scene de PS3, cuanta mas intencion haya de encontrar una cura para el Firm 3.50 mas consolas se van a vender estas navidades, hay muchisima gente que solo va a comprar estas navidades una PS3 pensando en que va a poder utilizar un dongle ó un CF (como en PSP), sin esta ilusion, esta gente no comprara y a Sony esto igual no le interesa.

Ahora aparece este usuario, facilitando esta "informacion privilegiada"? Pues igual esto es otra estrategia, quien sabe!, pero realmente suena mas a uno que se aburre en casa y esta montando una pelicula para que se hable de algo en los foros (rollo como los e-mail de pasalo o te mueres [sonrisa] ).

Salu2.

Hermes perdon por el Off-Topic, pero me ha salido del alma! [fumando]


Tienes toda la razón............ :) :) :) :)
cj8082 escribió:Señores, llega la campaña navideña y ahora mas que nunca no interesa que muera la scene de PS3, cuanta mas intencion haya de encontrar una cura para el Firm 3.50 mas consolas se van a vender estas navidades, hay muchisima gente que solo va a comprar estas navidades una PS3 pensando en que va a poder utilizar un dongle ó un CF (como en PSP), sin esta ilusion, esta gente no comprara y a Sony esto igual no le interesa.
Hermes perdon por el Off-Topic, pero me ha salido del alma! [fumando]


Si, pero lo que parece que todo el mundo se olvida es que el mayor interes de la consola es la venta de juegos (Sony se queda sentada mientras los demas le pagan por poder producir juegos para su consola) y con el tema del jailbreak la venta de juegos seguramente se va a ir por el piso estas navidades y esto no va a dejar ni a Sony ni a sus desarroladoras de soft felices.

Sobre este asunto del supuesto ataque de Sony, seria interesante saber la opinion de Hermes ya que esto lo afecta directamente (desde el punto que se usa su nick en el dongle). Sabemos que esto no se puede considerar mas que una especulacion, pero me parece que todos soñamos en volver a ver los payloads de Hermes que hasta ahora son los mejores del mundo.
Hermes una pregunta; para hacer un payload o para adaptar uno ¿mas o menos que hay que hacer?
Un saludo.
que hex usar para el dongle PS3Speed?? gracias por anticipado
Psmaniaco escribió:Hermes una pregunta; para hacer un payload o para adaptar uno ¿mas o menos que hay que hacer?
Un saludo.


No soy Hermes , pero a esto sí te se responder:
1. Saber programar en C/C++
2.Tener unos mínimos conocimientos de Asm para PPc y conociemientos medios altos en ASM en general.
3. Estudiar y comprender lo que aquí pone : http://ps3wiki.lan.st/index.php?title=PSJailbreak_Exploit_Reverse_Engineering
4. Herraminetas necesarias : Compiladores,depuradores con sus correspondientes plugins(ida). Un dump lo mas limpio posible, almenos de lv2 para investigar. Un dispositivo para meter el payload y hacer pruebas.
5. Muuuuucho tiempo para investigar,leer y probar.

Espero que te sea util.

Salu2.
Calantra escribió:
Psmaniaco escribió:Hermes una pregunta; para hacer un payload o para adaptar uno ¿mas o menos que hay que hacer?
Un saludo.


No soy Hermes , pero a esto sí te se responder:
1. Saber programar en C/C++
2.Tener unos mínimos conocimientos de Asm para PPc y conociemientos medios altos en ASM en general.
3. Estudiar y comprender lo que aquí pone : http://ps3wiki.lan.st/index.php?title=PSJailbreak_Exploit_Reverse_Engineering
4. Herraminetas necesarias : Compiladores,depuradores con sus correspondientes plugins(ida). Un dump lo mas limpio posible, almenos de lv2 para investigar. Un dispositivo para meter el payload y hacer pruebas.
5. Muuuuucho tiempo para investigar,leer y probar.

Espero que te sea util.

Salu2.

O sea que me voy a tener que pringar no solo el C y C++ sino que tambien el ASM mecaaaaa [tomaaa] bueno pues si hay que hacerlo, hay que hacerlo, que remedio nos queda jajajajajja [agggtt] .
Un saludo.
Hermes, siento el Offtopic, pero por ahí están comentando que quieren un Frets On Fire para PS3.

Tienes intención de hacer algo?
Psmaniaco escribió:
Calantra escribió:
Psmaniaco escribió:Hermes una pregunta; para hacer un payload o para adaptar uno ¿mas o menos que hay que hacer?
Un saludo.


No soy Hermes , pero a esto sí te se responder:
1. Saber programar en C/C++
2.Tener unos mínimos conocimientos de Asm para PPc y conociemientos medios altos en ASM en general.
3. Estudiar y comprender lo que aquí pone : http://ps3wiki.lan.st/index.php?title=PSJailbreak_Exploit_Reverse_Engineering
4. Herraminetas necesarias : Compiladores,depuradores con sus correspondientes plugins(ida). Un dump lo mas limpio posible, almenos de lv2 para investigar. Un dispositivo para meter el payload y hacer pruebas.
5. Muuuuucho tiempo para investigar,leer y probar.

Espero que te sea util.

Salu2.

O sea que me voy a tener que pringar no solo el C y C++ sino que tambien el ASM mecaaaaa [tomaaa] bueno pues si hay que hacerlo, hay que hacerlo, que remedio nos queda jajajajajja [agggtt] .
Un saludo.



vas hacer un payload? con q fin?q tienes en mente????

pd: alomejor no tendria q preguntar,pero me pica la curiosidad¡¡¡¡¡¡
hace tiempo q no se hacen payload`s y ni se habla de ellos¡¡¡¡¡¡¡
Pues es para agregar el codigo compilado del AsbestOS (el loader para Linux que hay para las versiones de firm 3.41) y la version que saca marcan solo se puede cargar asi, a menos que haga un loader como el de Hermes.
Un saludo.
hace unos dias Klutsh ha publidado su nuevo recovery para terminales android, en concreto hablo de la nexus one, que da opcion a ejecutar los payload con extension .bin, como puede ser el de kakaroto pl3 y demas, ha añadido la opcion de cargar payload con extension .hex, osea hermes, pero no se que payload v4b puedo usar, hay que compilar uno nuevo o puedo usar alguno ya hecho?
Cardi escribió:hace unos dias Klutsh ha publidado su nuevo recovery para terminales android, en concreto hablo de la nexus one, que da opcion a ejecutar los payload con extension .bin, como puede ser el de kakaroto pl3 y demas, ha añadido la opcion de cargar payload con extension .hex, osea hermes, pero no se que payload v4b puedo usar, hay que compilar uno nuevo o puedo usar alguno ya hecho?


La virgen, o tienes un cacao mental de la leche o un despiste de los guapos :)

De cualquier modo me has hecho reir un rato, gracias :)

Sin acritud, te recomiendo leer las cosas con mas calma, porque sino te vas a liar.
bueno tal vez es una mezcla de todo un poco.

A ver lo que quiero decir es que para nexus one no esta portado el codigo de hermes el v4b y si la PL3, la verdad que la extension del archivo es lo de menos.

Lo que quiero saber si hay en alguna parte dicho payload para nexus por que he probado uno de desire y no funciona.
(mensaje borrado)
Soy nuevo en esto de la Scene de PS3 y no entiendo mucho del tema, para que sirve esta aplicacion?
Pregunta chorra:

Teniendo la USB MK ¿no se podría habilitar el groove sin exploit? Del mismo modo que se usa PSGrade me refiero.
Una pregunta puedo actualizar todos los juegos con hermes v4b, o si actualizo alguno me dara problemas despues?
StormSeeker escribió:que hex usar para el dongle PS3Speed?? gracias por anticipado

Hola, yo lo hice con uno que se llama arduino, lo encontre en google y lo tengo en otro pc si interesa lo busco y lo cuelgo.Debes de tener pulsado el boton de upgrade mantenido hasta que lo pinches en el pc con el programa abierto para que lo reconozca, un saludo
1485 respuestas
126, 27, 28, 29, 30