ps3 hypervisor security

[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]

further researching i noticed this document seattle.toorcon.org/talks/felixdomke.pdf but i' ve quite problem in replicating the bug

That bug describes a very specific problem in xbox 360 code, which as you know is written by Microsoft. Sony's hypervisor is known to be very similar to the reference hypervisor which has been developed further independently by Toshiba, IBM and Sony but it seems to be impossible to find any real documentation on either the reference HV or any of the variants. It is pretty clear however, that apart from name and some underlying principles they have nothing in common with the xbox or IBM's research hypervisor.

Finally, as jimparis says, without seeing any of your code, it's impossible to know why your module crashed. Most likely, you just made a mistake as shown by the fact the first entry in your call trace is inside your module.

If you had actually found a case where the parameters weren't being correctly validated causing a jump to the wrong address, you'd expect a an exception in most cases anyway. It's up to you as a would be hacker to try work how how to make it execute useful code instead of random code which causes a crash. Chances are if you'd actually caused a hypervisor crash the machine would lock up completely rather than producing a stack trace.

[gigi]

further researching i noticed this document seattle.toorcon.org/talks/felixdomke.pdf but i' ve quite problem in replicating the bug

That bug describes a very specific problem in xbox 360 code, which as you know is written by Microsoft. Sony's hypervisor is known to be very similar to the reference hypervisor which has been developed further independently by Toshiba, IBM and Sony but it seems to be impossible to find any real documentation on either the reference HV or any of the variants. It is pretty clear however, that apart from name and some underlying principles they have nothing in common with the xbox or IBM's research hypervisor.

Finally, as jimparis says, without seeing any of your code, it's impossible to know why your module crashed. Most likely, you just made a mistake as shown by the fact the first entry in your call trace is inside your module.

If you had actually found a case where the parameters weren't being correctly validated causing a jump to the wrong address, you'd expect a an exception in most cases anyway. It's up to you as a would be hacker to try work how how to make it execute useful code instead of random code which causes a crash. Chances are if you'd actually caused a hypervisor crash the machine would lock up completely rather than producing a stack trace.

Yep both of you right , I spent few hour trying to debug the error and I did not asked for the right thing , the address location is inside the module location and i'm asking for a region that i'm not allowed to see that cause the crash of the kernel . I'll post the source as soon as I have something more concrete to show ; hoping it will not take months :-) . Thanks to both of you .

[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 ) :
http://download-prod.online.scea.com/me ... ciao gigi

[jimparis]

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

[gigi]

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

Me too , still I can't understand why they distributed such way the update , anyway good for us we can acquire major knowledge of gameos; after few hours I'm quite thinking that under gameos the hv is called with a different syscall ..... still can't understand why. The syscall does not work in linux ( i tried with a friend changing it in the otheros demo that is on this forum ) , it just hang system completly , also seem that there is a different set of calls ( not sure on this one... just supposing that. ) .

I'm now trying to make a static ppc64 program , using the little "I think" I understood from the objdump .

Sounds also like from strings that the ps3 uses equal/similar functions of the PSP , of course i expect different header , file structure.

[ralferoo]

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?

At 0x400 there's a 20 byte block that seems to be constant in every self file.
At 0x414 there's a 20 byte block that is the SHA-1 hash of the embedded ELF (see below):

Code: Select all

$ dd if=BCAS20015_101.self of=embedded.elf bs=1 skip=2432
$ sha1sum embedded.elf 
7cf91853d67941160eda07976d5755eff62d2e15  embedded.elf
$ hexdump -C BCAS20015_101.self |grep "0004[012]0 "
00000400  62 7c b1 80 8a b9 38 e3  2c 8c 09 17 08 72 6a 57  |b|....8.,....rjW|
00000410  9e 25 86 e4 7c f9 18 53  d6 79 41 16 0e da 07 97  |.%..|..S.yA.....|
00000420  6d 57 55 ef f6 2d 2e 15  00 00 00 00 00 00 00 00  |mWU..-..........|

20 bytes of semi-random data around normal looking data is usually a very good indication of an SHA-1 hash... ;)

[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]

The file is no longer available.

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

same question

[Den_John]

The file is no longer available.

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

same question

[LINK DELETED!]

[jimparis]

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

[StreetskaterFU]

The file is no longer available.

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

same question

[LINK DELETED!]

thanks

[jimparis]

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

Because they're not talking to the hypervisor directly, they're doing a user->kernel system call into GameOS.

Unfortunately it doesn't seem to match the calling convention of any OS that I'm aware of. It looks like they're putting the system call number into r11 (FreeBSD etc would use r0). If you grep through the code there are a lot of unique values that they use in r11:

Code: Select all

8, 43, 44, 45, 47, 48,
100, 101, 102, 104, 105, 106, 107, 108, 109,
120, 122, 125, 128, 129, 130, 133, 134, 135, 136, 137, 138, 141, 142, 144, 145, 147, 169, 181, 182, 190,
341, 342, 351, 402, 403,
802, 803, 804, 805, 806, 807, 808, 809, 810, 811, 812, 813, 814, 817, 818, 820, 831, 832, 834, 872,
8192

[stinkymonkey]

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