PS3 Hypervisor RE


This relates to the leaked PS3_Memory_Dump.bin file of 10,485,760 bytes which is thought to have come from is0mick. The Memory Dump is from the lv1 Hypervisor and is only a part of the whole Hypervisor.

What next?


We must try to dump the lv2 Hypervisor. Geohot adviced to use a cold-boot-attack, but didn't want to give the details. We should concentrate on dumping the lv2. -- Has anyone tried to decrypt lvl2 self from firmware update? and then dump it?

Cold-boot-attack(geohot's advise)

tillman from the forum gave a link: Cold-boot-attack . There's a video shows how a cold boot attack could be done to get the encryption keys (=decryption keys). DRAM doesn't erase data instantly(the PS3 XDR-DRAM too), if you hard power off. The "to do"-list below is basicly our "key" to get a lv2 dump. So, we've gotta build a minimalistic linux with a ram dumper included and install it on the PS3. We've gotta start the PS3 in GameOS (lv2 is loaded to RAM), select the OtherOS as the standard OS, quick power off and dump the RAM with the mini Linux. The KeyFinder located here will allow us then to get the Keys out of the Dump. Another good resource for this is here. A Custom Firmware or jailbreak or similar things aren't much far then. Everyone must help to get there !!!Just dumping the RAM will do!!!

UPDATE: Is0mick (special thx!) did that! He failed at dumping the lv2. That's probably because the RAM was hot/warm. Such a RAM will erase its data quickly. The guys herecooled the RAM with liquid air/liquid Nitrogen. Such a RAM will keep its data approx. 2 hours at -180°C. Let's try it again, but now with a cooled RAM. If it doesn't work again, we'll have to use a minimalistic Linux or try to dump the RAM on another PC system, which is actually much simpler, but the RAM of the PS3 has to be exchangeable (don't know, if it is or not)...

It will be great to have following dump for next step

Requires following hardware/tools:
- Hardware modification of PS3 Fat with FW 3.15 to trig the exploit.
- Use of GeoHot (modified by xorloser) exploit kernel module: http://xorloser.com/blog/wp-content/uploads/2010/02/ps3_exploit_fixed.zip
- Use of PS3News developer kakarotoks ps3_hv_mem kernel module http://www.ps3news.com/forums/attachment.php?attachmentid=19867
  • Dump of syscall table(from the start):
    Require modification of ps3_exploit_fixed -> exploit.c file:
    add line hexdump(hv_call_table, 0x20000); after line printk(KERN_ERR "calling hypercall test got %16.16lx\n", v1_peek(0x2401FC00000));
    After rebuild the kernel module.
  • Launch the exploit and Dump the PS3 FW 3.15 with 20MB size just at startup of linux kernel using command dd if=/proc/ps3_hv_mem of=PS3_Memory_Dump.bin bs=1024 count=20K
  • Retrieve the dmesg log using command cp /var/log/dmesg ./dmesg.txt
  • Publish the results (PS3 FW 3.15 dump of 20MB+dmesg.txt) in a zip archive with a link here.
UPDATE: Is0mick has tried that. There was a failure. Very probably a SW-failure. Someone should recode it. And edit the things above.

To do:

A tutorial and a live CD / Live USB key (including petitboot) to start a minimalist kernel 2.6.25-2 + a good shell and all ready to build kernel module with exploit and tools embedded.

Interrupt Vector Table - Thanks to TitanMKD

Address |
Meaning
0x00000100
System Reset Interrupt
0x00000200
Machine Check Interrupt
0x00000300
Data Storage Interrupt
0x00000380
Data Segment Interrupt
0x00000400
Instruction Storage Interrupt
0x00000480
Instruction Segment Interrupt
0x00000500
External Interrupt
0x00000600
Alignment Interrupt
0x00000700
Program Interrupt
0x00000800
Floating Point Unavailable Interrupt
0x00000900
Decrementer Interrupt
0x00000980
Hypervisor Decrementer Interrupt
0x00000C00
System Call Interrupt
0x00000D00
Trace Interrupt
0x00000F20
VXU Unavailable Interrupt
0x00001200
System Error Interrupt
0x00001600
Maintenance Interrupt
0x00001700
???
0x00001800
Thermal Management Interrupt

SELF files contained in the dump:
Thanks to xorloser for his great tool SelfTool.exe v1.0 (maybe some hint why it crash on last 3 files ??, i'm also interested on source code of his selftool ...). [Warning - Avast reports a virus in this download. Proceed at your own risk! (might be a false detection)]

These files are found manually using this basic rule:
SELF identifier offset0:"SCE" and at offset145:"ELF" in that case it is a self file.
Address
File size in Bytes
Filename
Meaning
Finder

0x00011000
59312
metldr
=asecure loader
---> metldr
flo

0x00020000
93616
lv2ldr.self
LV2 Loader --> According to ps2dev forum: it is an elf with sce header --> sce elf.
---> lv2ldr.self

TitanMKD,tusso

0x00037000
77348
isoldr.self
Isolated Loader ?--> According to ps2dev forum: it is an elf with sce header --> sce elf.
---> isoldr.self

TitanMKD,tusso

0x00055000
121572
appldr.self
Application loader ?--> According to ps2dev forum: it is an elf with sce header --> sce elf.
--> appldr.self

TitanMKD,tusso

0x001624BC
????
emer_init.self
SELF (corrupted ??) -> Crash SelfTool v1.0 ???
TitanMKD,flo

0x006C25B4
????
emer_init.self
SELF (corrupted ??) -> Crash SelfTool v1.0 ???
TitanMKD,flo

0x006D5470
????
aim_spu_module.self
SELF (corrupted ??) -> Error loading file ...
TitanMKD,flo

There is still some research to do on other SCE "file ?" without "ELF"...

Unorganised:

Address
Meaning
Example
Finder
0x00002c00 - 0x000043FF
Repos

sapperlott
0x00006000
Partition table

sapperlott
0x00098000 - 0x0009FFFC
Some code

ifcaro
0x000a1d58
An ELF

ifcaro
0x000AC000 - 0x000CEF70
More code

ifcaro
0x000EE000 - 0x000EFFF0
More code

ifcaro
0x000F4000 - 0x000FFFFC
More code

ifcaro
0x00114000 - 0x00123FFF
More code

ifcaro
0x00130000 - 0x0013517C
More code

ifcaro
0x00140000 - 0x00147FFF
More code

ifcaro
0x0014C000 - 0x00157C90
More code

ifcaro
0x00159000 - 0x0015BFFF
More code

ifcaro
0x0015D07C - 0x0015FFFF
More code

ifcaro
0x001624BC
A SELF

ifcaro
0x00165000 - 0x00167FFF
More code

ifcaro
0x0016C000 - 0x0017FD98
More code

ifcaro
0x00203000 - 0x00312270
Main code?

ifcaro
0x00500000 - HTAB_Start
0x005FFFFF - HTAB_End
Each HTAB entry contain16bytes.
(Start of HTAB @ contains 0x1408F92C94401)
Hypervisor Exploit code:
0x00500008 - Real Addr of hypervisor_exploit @0x3B4000.
hypervisor_exploit_lv1_peek:
@0x003B4000
E8 63 00 00 ld r3, 0(r3)
4E 80 00 20 blr
hypervisor_exploit_lv1_poke:
@0x003B4008
F8 83 00 00 std r4, 0(r3)
38 60 00 00 li r3, 0
4E 80 00 20 blr
TitanMKD
0x00646900
HDD serial
Image
CJPC
0x00646940
HDD model
Image
CJPC
0x0075BC00
MAC Address
Image
CJPC
0x0012A2A0
PS2 emulation SW is @ /local_sys0/ps2emu/ps2emu.self
maybe clean SW-based emu

oyashio
IDA.JPG


ju2ef
000D2F30-000D2FD0
Blue-Ray Drive Firmware and Region Flash and e.t.c.
In Hex editor Image
http://img521.yfrog.com/img521/9929/ps3hvcopy.jpg
TUHTA
0012A0A0-0012A0D0
PS3 LPAR
lvl 2 Kernel
Place of PS3 lvl 2 Kernel.self
/flh/os/lv2_kernel.self
TUHTA
0012F3C0-0012F3D0
Debug Level(possible turn to debug unit?)
?
TUHTA
00659E40-0069E50
0065A2C0-0065A2D0
000CF550-000CF560
lvl 1 Enable RSX
lv1 iosys enable
Aim SPU
lv1_enable_rsx
lv1_iosys_enable
aim_spu_module.self
TUHTA
00080010-00080030
GsBoot(its something from bootloader.dat)
gsboot: load_lv2: filename: %s
TUHTA
00084200-00084250
Using of System Bytes
(think you command how much to use)
max system bytes = %10lu
system bytes = %10lu
in use bytes = %10lu
TUHTA
8:00204
¿lv2_kernel.self loader?
load_lv2: filename: %s
gsboot: load_lv2
Melirober
0x00138A90 - 0x00138AA0
magic number
maybe a key???

oyashio
0x00137BE0 - 0x00137C20
sysmgr starts first ps2-SW then linux and then debug level
sysmgr.boot.ps2.1st
sysmgr.boot.linux
sysmgr.debug.level
oyashio
0x00138AE0 - 0x00138AFO
sysmgr can't be read via exploit (yet)

oyashio
0x001373A0 - 0x001373F0
proof that ps2 can be completely emulated via CELL (compare to the Sony patent of ps2 emu via CELL)
SCE_CELLOS_SYSTEM_MGR
_PS2
SCE_CELLOS_SYSTEM_MGR
_ PS2_GX
SCE_CELLOS_SYSTEM_MGR
_PS2_SW
oyashio
0x0073CB30 - 0x0073CD40
Drive checks media HW(?)

oyashio
0x00360188
hv_call_table
Syscall names
flo
0x0034CC48
rtoc value

flo
RAM:00137BE0 aSysmgr_boot_ps:.string "sysmgr.boot.ps2.1st"
RAM:00137BF8 aSysmgr_boot_li:.string "sysmgr.boot.linux.1st"
RAM:00137C10 aSysmgr_debug_l:.string "sysmgr.debug.level"


JU2EF
Note: According to CJPC, the MAC address is riddled through the dump, but that is the most reliable place to find it.