forums.ps2dev.org

[gigi]

Sorry to make , some maybe obvious question , but i started from few days to play with new playstation 3 , fantatic device.
Said so i saw that under the hv mode i'm restricted into an lpar partition with user permission and everything called from the linux kernel is interpreted as an hv call , noticed so i started learning a little from both IBM a scei documentations and about the security documentation already in place for other console with similar os ( read 360 - shype ) . I noticed that mostly the xbox 360 , celleb and the rhype ( ps3 ) uses the same base of code for the hv ; further researching i noticed this document seattle.toorcon.org/talks/felixdomke.pdf but i' ve quite problem in replicating the bug , what it seem to me is that the ps3 handle in a very similar way the calls , and i tried with lv1_memory_allocate hv call ;the dump from linux is:

fill_kobj_path: path = '/module/modvram'
****************************************************
PS3TEST KERNEL MODULE LOADING
****************************************************
ps3_test_kernel_mod: PS3 LV1 HV Kernel Module, 0.0.1
****************************************************
Unable to handle kernel paging request for data at address 0x80000200ea001014
Faulting instruction address: 0xd00000000004d04c
Oops: Kernel access of bad area, sig: 11 [#1]
SMP NR_CPUS=2 PS3
Modules linked in: modvram autofs4 evdev usbhid usb_storage sg sys_manager
NIP: d00000000004d04c LR: d00000000004d034 CTR: 0000000000000001
REGS: c0006c0065bb3940 TRAP: 0300 Not tainted (2.6.23-powerpc64-smp-custom-g78ca43dd-dirty)
MSR: 8000000000008032 <EE,IR,DR> CR: 24000224 XER: 00000000
DAR: 80000200ea001014, DSISR: 0000000042000000
TASK = c0006c006423e000[5988] 'insmod' THREAD: c0006c0065bb0000 CPU: 1
GPR00: d00000000004d16c c0006c0065bb3bc0 d000000000056948 0000000021000000
GPR04: 80000200ea000000 0000000000000000 0000000000000000 0000000000000000
GPR08: d00000000004e400 0000000000000028 c0006c006425b800 0000000000000000
GPR12: d00000000004d518 c000000000472e80 0000000000000000 c0006c0065bb3c30
GPR16: 0000000000000007 0000000000000000 0000000000000000 000000000000004a
GPR20: d00000000003e707 d00000000004d9b0 0000000000000000 d000000000030000
GPR24: 0000000000000027 d00000000003e848 d00000000004e400 0000000000000028
GPR28: c0006c006425b800 d00000000004d5f8 d000000000056800 d00000000004e400
NIP [d00000000004d04c] putc+0x14/0x28 [modtest]
LR [d00000000004d034] .syscall+0x34/0x38 [modtest]
Call Trace:
[c0006c0065bb3bc0] [d00000000004d140] ._ps3_test_kernel_init+0x54/0x4ec [modtest] (unreliable)
[c0006c0045bb3c90] [c000000000070da0] .sys_init_module+0x1504/0x16c0
[c0006c0065bb3e30] [c000000000008534] syscall_exit+0x0/0x40
Instruction dump:
e8ef0028 e90f0030 e92f0038 e94f0040 38600021 48000009 4bfffff8 3c808000
60840200 788407c6 6484ea00 5463c00e <90641014> 80641018 5463018d 4182fff8

do someone have some time to help me understand a little better this hv? sounds like that this forum is a very interesting place in order to understand better how the ps3 works , thanks a lot! and sorry for the bad english :-(

[jimparis]

Your module crashed because there is a bug in your code.
This has nothing to do with the hypervisor.
If you post the source maybe someone can help you.

[ralferoo]

[gigi]

[gigi]

Just to share my findings , this week I looked into the gameos , and the boot process of self files.
I found a good way ( i won't discuss that right now it's so early ) to copy thought patches of games ( like the warhawk method ) the EBOOT.BIN file and execute it , at the moment with the latest firmware ( 2.0 of yesterday ) i'm able to execute files ( renaming them to EBOOT.BIN ) ,

The games got launched from the original games following this scheme

/dev_bdvd/PS3_GAME/USRDIR/EBOOT.BIN -launch---->
/dev_hdd0/PS3_GAME/USRDIR/GAMEblablalbla/EBOOT.BIN

I tried to run the following :

- otheros.self , works perfectly
- updater.sce ( the one from UPDATE.PUP ) , just black screen , probably cause it does not find the files he expects
- other EBOOT.BIN of games I own ( mostly hangs )

Searching for the net I found a very interesting self ( which is public like is otheros.self ) :
[url]http://download-prod.online.scea.com/medius-patch/warhawk-prod/warhawk/r014/BCAS20015_101.self[url]

If you look at the file you will notice that it launch a semi - encrypter elf

spu-readelf -a BCAS20015_101.self.elf
ELF Header:
Magic: 7f 45 4c 46 02 02 01 66 00 00 00 00 00 00 00 00
Class: ELF64
Data: 2's complement, big endian
Version: 1 (current)
OS/ABI: <unknown: 66>
ABI Version: 0
Type: EXEC (Executable file)
Machine: PowerPC64
Version: 0x1
Entry point address: 0x6876b0
Start of program headers: 64 (bytes into file)
Start of section headers: 8403800 (bytes into file)
Flags: 0x0
Size of this header: 64 (bytes)
Size of program headers: 56 (bytes)
Number of program headers: 8
Size of section headers: 64 (bytes)
Number of section headers: 32
Section header string table index: 31

and after there is another elf :

ELF Header:
Magic: 7f 45 4c 46 02 02 01 66 00 00 00 00 00 00 00 00
Class: ELF64
Data: 2's complement, big endian
Version: 1 (current)
OS/ABI: <unknown: 66>
ABI Version: 0
Type: EXEC (Executable file)
Machine: PowerPC64
Version: 0x1
Entry point address: 0x6876b0
Start of program headers: 64 (bytes into file)
Start of section headers: 8401512 (bytes into file)
Flags: 0x0
Size of this header: 64 (bytes)
Size of program headers: 56 (bytes)
Number of program headers: 8
Size of section headers: 64 (bytes)
Number of section headers: 32
Section header string table index: 31

Section Headers:
[Nr] Name Type Address Offset
Size EntSize Flags Link Info Align
[ 0] NULL 0000000000000000 00000000
0000000000000000 0000000000000000 0 0 0
[ 1] .init PROGBITS 0000000000010200 00000200
000000000000002c 0000000000000000 AX 0 0 4
[ 2] .text PROGBITS 0000000000010230 00000230
0000000000641ef0 0000000000000000 AX 0 0 16
[ 3] .fini PROGBITS 0000000000652120 00642120
0000000000000024 0000000000000000 AX 0 0 4
[ 4] .sceStub.text PROGBITS 0000000000652144 00642144
0000000000001ec0 0000000000000000 AX 0 0 4
[ 5] .eh_frame PROGBITS 0000000000654004 00644004
0000000000000c54 0000000000000000 A 0 0 4
[ 6] .rodata.sceReside PROGBITS 0000000000654c58 00644c58
0000000000000114 0000000000000000 A 0 0 4
[ 7] .rodata.sceFNID PROGBITS 0000000000654d6c 00644d6c
00000000000003d8 0000000000000000 A 0 0 4
[ 8] .lib.ent.top PROGBITS 0000000000655144 00645144
0000000000000004 0000000000000000 A 0 0 4
[ 9] .lib.ent.btm PROGBITS 0000000000655148 00645148
0000000000000004 0000000000000000 A 0 0 4
[10] .lib.stub.top PROGBITS 000000000065514c 0064514c
0000000000000004 0000000000000000 A 0 0 4
[11] .lib.stub PROGBITS 0000000000655150 00645150
0000000000000318 0000000000000000 A 0 0 4
[12] .lib.stub.btm PROGBITS 0000000000655468 00645468
0000000000000004 0000000000000000 A 0 0 4
[13] .sys_proc_param PROGBITS 0000000000655470 00645470
0000000000000020 0000000000000000 WA 0 0 8
[14] .sys_proc_prx_par PROGBITS 0000000000655490 00645490
0000000000000028 0000000000000000 A 0 0 4
[15] .ctors PROGBITS 0000000000660000 00650000
00000000000006cc 0000000000000000 WA 0 0 4
[16] .dtors PROGBITS 00000000006606cc 006506cc
00000000000000cc 0000000000000000 WA 0 0 4
[17] .jcr PROGBITS 0000000000660798 00650798
0000000000000004 0000000000000000 WA 0 0 4
[18] .data.rel.ro PROGBITS 000000000066079c 0065079c
0000000000000d60 0000000000000000 WA 0 0 4
[19] .data.sceFStub PROGBITS 00000000006614fc 006514fc
00000000000003d8 0000000000000000 WA 0 0 4
[20] .toc1 PROGBITS 00000000006618d8 006518d8
0000000000025dc8 0000000000000000 WA 0 0 8
[21] .opd PROGBITS 00000000006876a0 006776a0
0000000000027818 0000000000000000 WA 0 0 4
[22] .got PROGBITS 00000000006aeeb8 0069eeb8
000000000000686c 0000000000000004 WA 0 0 8
[23] .tdata PROGBITS 00000000006b5728 006a5728
0000000000000008 0000000000000000 WAT 0 0 8
[24] .tbss NOBITS 00000000006b5730 006a5730
0000000000000170 0000000000000000 WAT 0 0 8
[25] .rodata PROGBITS 0000000010000000 006b0000
00000000000558f8 0000000000000000 A 0 0 16
[26] .spu_image PROGBITS 0000000010055900 00705900
0000000000087100 0000000000000000 WA 0 0 128
[27] .data PROGBITS 00000000100e0000 00790000
0000000000065474 0000000000000000 WA 0 0 128
[28] .bss NOBITS 0000000010145480 007f5474
000000000041cdf8 0000000000000000 WA 0 0 128
[29] .comment PROGBITS 0000000000000000 007f5474
000000000000bda0 0000000000000000 0 0 1
[30] .sceversion PROGBITS 0000000000000000 00801214
0000000000001f1e 0000000000000000 0 0 1
[31] .shstrtab STRTAB 0000000000000000 00803132
0000000000000136 0000000000000000 0 0 1
Key to Flags:
W (write), A (alloc), X (execute), M (merge), S (strings)
I (info), L (link order), G (group), x (unknown)
O (extra OS processing required) o (OS specific), p (processor specific)

There are no section groups in this file.

Program Headers:
Type Offset VirtAddr PhysAddr
FileSiz MemSiz Flags Align
LOAD 0x0000000000000000 0x0000000000010000 0x0000000000010000
0x00000000006454b8 0x00000000006454b8 R E 10000
LOAD 0x0000000000650000 0x0000000000660000 0x0000000000660000
0x0000000000055730 0x0000000000055730 RW 10000
LOAD 0x00000000006b0000 0x0000000010000000 0x0000000010000000
0x00000000000dca00 0x00000000000dca00 R 10000
LOAD 0x0000000000790000 0x00000000100e0000 0x00000000100e0000
0x0000000000065474 0x0000000000482278 RW 10000
LOAD 0x00000000007f5474 0x0000000000000000 0x0000000000000000
0x0000000000000000 0x0000000000000000 RW 10000
TLS 0x00000000006a5728 0x00000000006b5728 0x00000000006b5728
0x0000000000000008 0x0000000000000178 R 8
LOOS+1 0x0000000000645470 0x0000000000655470 0x0000000000655470
0x0000000000000020 0x0000000000000020 8
LOOS+2 0x0000000000645490 0x0000000000655490 0x0000000000655490
0x0000000000000028 0x0000000000000028 4

Section to Segment mapping:
Segment Sections...
00 .init .text .fini .sceStub.text .eh_frame .rodata.sceResident .rodata.sceFNID .lib.ent.top .lib.ent.btm .lib.stub.top .lib.stub .lib.stub.btm .sys_proc_param .sys_proc_prx_param
01 .ctors .dtors .jcr .data.rel.ro .data.sceFStub .toc1 .opd .got .tdata
02 .rodata .spu_image
03 .data .bss
04
05 .tdata .tbss
06 .sys_proc_param
07 .sys_proc_prx_param


Apart from the strings ( very cool , suggest you to have a look at it ) a friend of mine notices that the hv call is different from gameos to linux , any idea of why?

ppu-objdump -D newelf.elf |grep sc
114a0: 44 00 00 02 sc
24600: 44 00 00 02 sc
24628: 44 00 00 02 sc
2465c: 44 00 00 02 sc

Secondly I tried to compile a simple hello world ( 64 ppc , system V , different abi :-( ) and attach it at the end of the first elf ( the semi-crypted one ) , a way to use this self as trampoline to launch our elf but with scarse results. I'm at work and i don't remember the error code 80010009 or 80010007 probably which means I think corrupt.

I can't find any reference to a hash in the first elf , i'm missing something?

Any suggestion? I spent few days on this things and i'm a little bit out of ideas an open minded to try out any idea you may suggest also fell free to ask i've spent most of these days trying out so i can share what i already know.

Hope this can lead us to better comprension of how gameos works , and possibly a way to use linux in it's full potential a day ...

Thanks to all
ciao
gigi
[/url]

[jimparis]

Interesting, yes, that .self seems to contain an unencrypted executable at offset 0x980... I don't think I've seen that before.

[gigi]

[ralferoo]

[gotama]

The file is no longer available.

Where can i download it in order to perform tests and analize it?

[gotama]

has been any progress with the unencripted file?

[StreetskaterFU]

[Den_John]

[jimparis]

Please, do not provide links to copyrighted files that Sony has clearly removed for a reason.

[StreetskaterFU]

[jimparis]

[stinkymonkey]

so how can we map these calls?
gigi & jimparis any further progress made? :-)