Sponsored Links

Sponsored Links

PS3 Metldr / Per Console Key0 Update, LV0 Bootloader Decrypted?


Sponsored Links
149w ago - A few weeks back details and payloads for Dumping PS3 Per Console Keys surfaced followed by news of a PS3 Metldr Exploit, and today PlayStation 3 developer xx404xx on IRC has shared his PS3 Metldr / Per Console Key0 findings thus far.

Included below are a [Register or Login to view links] which is loaded through lv2patcher, an [Register or Login to view links], the required EID Static Keys and more, as follows:

[xx404xx] lol wtf you can write to metldr!!!!!!
[xx404xx] 0x17014 - Write eEID/Write metldr Holy crap, it writes passed data to the region of FLASH memory where eEID or metldr data is stored !!! And GameOS is allowed to use this service !!! Do not experiment with this service if you don't know what it does or else your PS3 will not work anymore !!!
[xx404xx] [Register or Login to view links]
[xx404xx] [Register or Login to view links] I highly recommend you all go look at that
[xx404xx] Is anyone taking a look at that paste bin? [Register or Login to view links] (via [Register or Login to view links] from lunuxx)
[xx404xx] Here's a pic from this leaked doc i found
[xx404xx] [Register or Login to view links]
[xx404xx] [Register or Login to view links] there's no per console key 0 in the guide
[xx404xx] and you need this leaked doc
[xx404xx] ill go upload it
[xx404xx] the per console key0 is only for my console......
[xx404xx] but you can obtain your own lv0
[xx404xx] im upploading the doc now
[xx404xx] i was hesitant about leaking this
[xx404xx] but here you go, you will need this info
[xx404xx] [Register or Login to view links]
[xx404xx] it has doc on the spu's
[stronzolo] what do you think about the picture who math posted on the twitter ?
[xx404xx] real
[xx404xx] he already told us how he does it....
[stronzolo] us = who ?
[branan] everybody. His thing about metldr from a couple days ago applies to bootldr just as well
[xx404xx] it's no secret
[stronzolo] so why math can do it... and others can't ? what's wrong ?
[xx404xx] lol if he didnt want other's knowing about it mabye he shouldnt tweet so many hint's.......
[xx404xx] we can do it
[xx404xx] read the docs
[xx404xx] he talk's about how we dump the local storage from the spu's
[stronzolo] 404 when do we know if your key is key 0 ?
[xx404xx] when someone prep's a step by step guide to dump bootldr
[xx404xx] Patent[How to dump lv0 with HW ;] that's all im going to say for know....there will be more later, and this is not a complete guide, but math gave you eveything else you need....
[xx404xx] [Register or Login to view links]
[XX404XX] Ik how math does the bootldr exploit
[antikhris] do tell...
[XX404XX] [Register or Login to view links]

On the PS3 True Blue Dongle:

[xx404xx] True blue is stupid
[xx404xx] it's the fselfs
[eussNL] its more than / just / fself, try unself one and you see what it is
[eussNL] its DRM'ed fself
[xx404xx] ps3 crunch is trying to make money on the new dongles......
[eussNL] well not surprising as GaryOPA is reseller
[xx404xx] where do you think
[xx404xx] it came from
[xx404xx] i dont mean drm
[eussNL] what?
[xx404xx] i mean the fself
[eussNL] there are plural items
[xx404xx] debug servers obv
[eussNL] well, they only have limited titles so there is your clue

From pastebin.com/rFD5ASJa: (img573.imageshack.us/img573/5026/newbitmapimage4z.png)



BootOrder explained (Thank's wiki) VERY IMPORTANT (per_console_key_0 is not the key which will be derived, but is the key which has derived per_console_key_1) We have pck1 using the dumper, in order to obtain pck you need to dump it out of ls. In order to do that with hardware you should look into math's comment's about dumping a shared lsa.

In order to do this with software you should either use math's bootldr exploit or you need to exploit the spe secure runtime.... (Not all that hard with the two recent exploit's)

With Runtime Secure Boot feature, an application can run a check on itself before it is executed to verify that it has not be modified and compromised.Secure Boot is normally done only at power-on time, but the Cell BE processor can Secure Boot an application thread multiple times during runtime. (PS3'S doesn't do this right as you can see in the failoverflow vid)

Passing execution: (img508.imageshack.us/img508/8544/eib.gif)



Spe execution control diagram: (imageshack.us/photo/my-images/835/newbitmapimage3a.png/)



Error Reporting: (imageshack.us/photo/my-images/193/newbitmapimage5us.png/)



A Debug support flag set in SC EEPROM at address 0x48C50. When this flag is set, the token is read from SYSCON and decrypted, this gets passed to various modules to unlock certain functionality.

Debug support flag is tied to EID which is supposed to be hashed and saves in SC EEPROM

[Register or Login to view code]

A FSELF support flag set in SC EEPROM at address 0x48C06. When this flag is set, the token is read from SYSCON and decrypted, this gets passed to various modules to unlock certain functionality.

[Register or Login to view code]

Eid Rootkey(1) Dumper (Load through lv2patcher) (You need this)
[Register or Login to view links]

Decrypt your eid with this (You need this)
[Register or Login to view links]

[Register or Login to view code]

Eid static key's (You need these)

1.00 Debug/DEX - aim_spu_module.self

[Register or Login to view code]

3.15 Retail/CEX - aim_spu_module.self

[Register or Login to view code]

3.41 Retail/CEX - aim_spu_module.self

[Register or Login to view code]

3.55 Retail/CEX - aim_spu_module.self

[Register or Login to view code]

3.56 Retail/CEX - aim_spu_module.self

[Register or Login to view code]

1.00 Debug/DEX - appldr

[Register or Login to view code]

3.15 Retail/CEX - appldr

[Register or Login to view code]

3.41 Retail/CEX - appldr

[Register or Login to view code]

3.55 Retail/CEX - appldr

[Register or Login to view code]

3.56 Retail/CEX - appldr

[Register or Login to view code]

1.00 Debug/DEX - isoldr

[Register or Login to view code]

3.15 Retail/CEX - isoldr

[Register or Login to view code]

3.41 Retail/CEX - isoldr

[Register or Login to view code]

3.55 Retail/CEX - isoldr

[Register or Login to view code]

3.56 Retail/CEX - isoldr

[Register or Login to view code]

1.00 Debug/DEX - lv1ldr

[Register or Login to view code]

3.15 Retail/CEX - lv1ldr

[Register or Login to view code]

3.41 Retail/CEX - lv1ldr

[Register or Login to view code]

3.55 Retail/CEX - lv1ldr

[Register or Login to view code]

3.56 Retail/CEX - lv1ldr

[Register or Login to view code]

1.00 Debug/DEX - lv2ldr

[Register or Login to view code]

1.00 Debug/DEX - spu_pkg_rvk_verifier.self

[Register or Login to view code]

1.00 Debug/DEX - spu_token_processor.self

[Register or Login to view code]

3.15 Retail/CEX - spu_token_processor.self

[Register or Login to view code]

3.41 Retail/CEX - spu_token_processor.self

[Register or Login to view code]

3.55 Retail/CEX - spu_token_processor.self

[Register or Login to view code]

3.56 Retail/CEX - spu_token_processor.self

[Register or Login to view code]

3.15 Retail/CEX - spu_utoken_processor.self

[Register or Login to view code]

3.41 Retail/CEX - spu_utoken_processor.self

[Register or Login to view code]

3.55 Retail/CEX - spu_utoken_processor.self

[Register or Login to view code]

3.56 Retail/CEX - spu_utoken_processor.self

[Register or Login to view code]

In related news, Sony PlayStation 3 hacker Mathieulh [Register or Login to view links] the following comments on what appears to be the PS3 Firmware 3.73 lv0 bootloader decrypted:

Boot Loader SE Version 3.7.3 (Build ID: 4611,48369, Build Date: 2011-10-12_12:31:19) What's taking you so long ? [Register or Login to view links]


Boot Loader SE Version 3.6.6 (Build ID: 4534,47762, Build Date: 2011-06-16_13:24:46) I am bored....

Oh ! that's nothing just a little string from the 3.73 lv0....

By the way, I won't be posting keys, I won't be posting dumps and I won't be saying how it was done, time to work gentlemen.

It's a command prompt because I am using my own tool to decrypt selfs to elf and not the buggy unself. Not like an unself prompt couldn't be faked though.

You can't sign lv0 on a cech-3000 sorry. No, the new bootloader uses a new keyset.

The build number should be proof enough, as long as you can get your hands on a decrypted lv0 that is. Posting keys is not an option, posting hashes of the keys wouldn't bring you any additional proof because you have no way of verifying those, besides Sony's lawyers would claim that I'd be posting encrypted forms of the keys like they did in the fail0verflow trial, and I am not posting screenshots because lv0 contains copyrighted code.

So unless you have any other "proof" in mind that I could post legally without fearing prosecutions, feel free to tell me about these.

I am definitely not releasing it anyway, I've already said how I am not releasing anything anymore, EVER. I am a man of my word.

By the way instead of demanding, people should start looking at my "pwning metldr the "easy" way" post where I gave the first steps into exploiting the bootloader and one of the required exploits and start working from that, there is no point in making demands, asking for "proofs", keys and whatnot, I won't be sharing these, so you'd better start working; I've given you a nice starting point.

I am done talking about lv0 decryption, feel free to resume this talk once it becomes public and people can verify the strings I posted.

Although unconfirmed, [Register or Login to view links] has Tweeted the following: Don't flame ppl!.. lv0 decrypted from my debug console!! [Register or Login to view links]

Posted a little preview of the ps3swu.self from 4.00 - [Register or Login to view links]



Shortly following, he Tweeted (twitter.com/#!/eitjuhh/status/144763029224038400): Found new keys in OFW 4.00 !! doesn't know which keys they are at this moment!.. but i think the new twitter.com/#!/eitjuhh/status/144763029224038400/photo/1


bit i think they are the new klic_dec_key keys sony wrote them twice in other ofw's now 3 times?? [Register or Login to view links]

60 00 00 00 E8 01 00 80 38 21 00 70 7C 08 03 A6 --- Second new key found!

And he Tweeted (twitter.com/#!/eitjuhh/status/145054115750346752): Yesterday I did a second test! CFW is RUNNING ppl!!.. Tonight I will build in Peek&Poke! Video: soon, Release: Before Christmas !

From Sony PS3 hacker xorloser (CitizenX of scene release group PARADOX) via [Register or Login to view links]:

V3.60 and above have the secrets encrypted inside lv0, and the lv0 keys are not publicly available.

lv0ldr loads lv0 direct from flash rather than from memory, plus nothing else is running at this stage. So trickier, but doable.

From zecoxao comes a brief guide: How to Dump BOOTLDR Unencrypted (Decrypted)

Things you'll need:

  • PS3 on 3.55 OTHEROS++ (this was tested on a slim, but phats are probably achievable aswell)
  • Latest linux kernel (or any of the 3.x.x kernels by glevand precompiled)
  • Knowledge of linux ( such as , creating symlinks (ln -s), editing kboot.conf, sudoing, etc)

In case you don't have the latest kernel, but already have one installed distro: gitbrew.org/~glevand/ps3/linux/linux-3/linux-3.3.3-build.tar.bz2

[Register or Login to view code]

And now for the fun part:
[Register or Login to view code]


PS: Lv0 keys are STILL encrypted, so don't complain, you have your precious bootldr there, have fun with it.

Finally, from anonymous (via pastie.org/pastes/5090091/) comes a PS3 dump bootldr how to exploit:

Must have a dex 3.55 real or made dex 3.55 ps3 also duel nand/nor installed chip base. In a 3.55 dex console, prepare a lv0.self with the metadata exploit. reboot. lv0 will hang since lv0.self will not run properly. bootldr will send info to lv0 before it hangs, after it decrypts it, running dex with certain switches set up like boot in dev mode Will allow this hang dump of bootldr to be saved to the local store.

But, essentially you will have a bricked ps3 so recovery of the local store wont happen. This is where the duel nand/nor comes in handy and allows you to recover from this and replace your messed up lv0.self with the original to boot up and recover the local store dump and the decrypted bootldr. This will allow the keys to bootldr these keys cannot be changed with any update.

We can then exploit lv0. The exploit of bootldr/lv0 will allow the ability to change the way private keys are made or give us the ability to reset up the private key fail and resign packages with any new firmwares.

This although is just a "well tested Theory" of course.








Stay tuned for more PS3 Hacks and PS3 CFW news, follow us on Twitter and be sure to drop by the PS3 Hacks and PS3 Custom Firmware Forums for the latest PlayStation 3 scene updates and homebrew releases!

Comments 201 Comments - Go to Forum Thread »

• Please Register at PS3News.com or Login to make comments on Site News articles. Thanks!

enoughbr's Avatar
#176 - enoughbr - 145w ago
I talked with RealPsDev, he says Lv0 can be decrypted, and that he has seen the Lv0 fully decrypted, for those who do not know what it means to Lv0, it is the key "master" keys of all OFW are derived from it.

[Register or Login to view links]
[code]Now before anyone gets to excited this is strings from a hypervision and bootloader dump from the ram it not useless as it tell a lot of events that happen at certain addresses like the lv0 app version is set at 0x10 ect: + It sucks cause a lot of stuff has been cut out due to memory shortage there about 100kb worth of missing info

sys.lv1.emuioif0irq
lv1.ram.tkm
sys.lv1.be
sys.lv1.iosys.errorhandler
sys.lv0.revision
lv1.ram.tkm
be.0.spu.faultbm
sys.platform.mode
sys.cellos.flags
sys.lv1.iosys.pciex
lv1.ram.ioc
quethshld
gglv1.ram.ioc
quethshld
sys.lv0.version
sys.lv1.iosys.pci.retry
lv1.ram.biu
modesetup1
sys.ac.sd
lv1.ram.biu
modesetup2
sys.lc.polling.time
sys.ac.misc2
lv1.ram.spe
lv1.ram.tkm
lv1.ram.tkm
lv1.ram.mic
sys.lv1console.mode
lv1.ram.mic
be.0.fir.mic
be.0.fir.mic
pme.memory.size
@be.0.ioif0.addr
be.0.ioif1.addr
sys.hw.config
sys.sata.param
sys.hw.model
be.0.fir.spu0
be.0.fir.spu1
be.0.fir.spu2
be.0.nclk
be.0.fir.spu0
sys.flash.boot
sys.qaf.qafen
be.0.fir.spu1
@01 2
l7D-!:yP9>
.WPGHshhc
8c
Tc'>hc
8c
I0= 38
p
I0= 58
p
I0= :8
p
xy< yJ A
:axxD"T
/ C@8A
x;ch;!x;
;up9 %p

ordered ID to masking pattern
ordered id %d -> %p

ordered ID to ID

ordered id %d -> %d

0123456789abcdef
0123456789ABCDEF
../../src/UX/selective/secure/certified
file.ccThis is not certified
CF version mismatch

CF category mismatch

incorrect ext
incorrect file
incorrect file
../../src/UX/selective/secure/self64
file: validation of certified
file failed
sys.lv1console.mode
old syscon mode is obsoluted.
ABEND: assertion failed:
????????????????
ABEND: LOG
too many hdec handlers

srr0:
srr1:
dar:
CONFIGURATION ERROR:
logger@:
buffer address:

start pointer:

end pointer:
sys.lv1log.size
loader parameter full
sys.cellos.flags
sys.mmio.map
mu.1.size
be.0.ioif1.addrbe.0.bp
sys.platform.mode
last remainder:
Releasable
allocator@

free list:

free block bitmap:
stockpile@

budget@

residual =

used =

buffer =
sys.lv0.addresssys.lv0.size
sys.lv0.revision
sys.lv0.versionsys.lv1.ahcr
Total memory:

Lv-0 size:

Heap consumption

Peak at:
WARNING: out of memory -
FATAL: no reserved memory...

remaining reserved memory =
lv1.ram.enable
lv1.ram.ppe
lv1.ram.spe
lv1.ram.mic
lv1.ram.mic
lv1.ram.ioc
quethshld
lv1.ram.ioc
quethshld
lv1.ram.tkm
lv1.ram.tkm
lv1.ram.tkm
lv1.ram.tkm
lv1.ram.tkm
lv1.ram.biu
modesetup1
lv1.ram.biu
modesetup2
be.0.spu.faultbm
spurious interrupt: pu
interrupt:
I/O exception: source lv1
runtime.tcl
invalid GOPI number
a conflict is detected
PANIC: conflicting interface number:
revision:
date:
count =
construction
status =

chain =

reversed

link =

rc =
memory leak in heap for thread
is detected.
managed memory:

leak:
memory leak in stockpile for node
is detected.

shortagesegment
association@
, invalidation
count = WARNING: PTE collision
existing=

inserted=
WARNING: PTE collision

existing=
v:
e0:
e1:
ioaddr:
a:
ioid:
sys.pci.share
sys.lv1.iofaultmsg
: write 0x
: read 0x
WARNING: "enable
time" is deprecated

pme.memory.sizepme.memory.size is not a multiple of 4KB
be.0.fir.ras
eebe.0.fir.l2
be.0.fir.l2
be.0.fir.biu
embe.0.fir.biu
eebe.0.fir.ciu
embe.0.fir.ciu
eebe.0.fir.mic
f0be.0.fir.mic
f1be.0.fir.ioc
embe.0.fir.ioc
dump spu
fir regs
unit: spu
DETECT HW Error
unit: global fir, cause: checkstop
DETECT HW Error
unit: global fir, cause: recoverable
recoverable
dump global fir regs
dump biu fir regs
unit: biu
dump l2 fir regs
unit: l2
dump ioc fir regs
unit: ioc
dump mic fir regs
unit: mic
dump ciu fir regs
unit: ciu
sys.lv1.be
sys.hvlog.size
SPE hang is detected: GUID
UNKNOWN, NPC
construction of SPU management VPU failed

pmi
: already called

: wrong gos
sys.lv1.dump
plat.idPANIC: Can't get loader parameter =
sys.flash.fmt
storage.size
spider.gbe0.macaddr.1
spider.gbe0.macaddr.2
spider.gbe0.macaddr.3
sys.debug.device
rsx.rdcy.3
rsx.rdcy.4
rsx.rdcy.5
rsx.rdcy.6
rsx.rdcy.7
rsx.rdcy.8
sys.lv1.iosysenable
ios.net.eurus.lpar
sys.hw.config
sys.hw.model
be.0.nclk
be.0.ioif0.addrlv1.heap.check
The allocation size from the heap
exceeds
bytes: 0x
lc.allow.large
sys.dbgcard.dgbe
sys.lc.polling.time
hypervisor
EIC driver initialization failed
FAIL: construction of a SPU objs
FAIL: Loader parameter 'be.0.spu.faultbm' is required.
sys.cellos.spu.configure
FAIL: Lv-1 does not support system SPEs more than 2.
,normal,system
sys.lv1.iosys.network
sys.hw.config
sys.hw.model
virtual int cellos::iosys::storage::storage
device:ut
cellos::uint64
t, cellos::uint64
t, cellos::uint64
t, cellos::uint64
t, cellos::uint64
t, cellos::uint64
virtual int cellos::iosys::storage::storage
device:ut
cellos::uint64
t, cellos::uint64
t, cellos::uint64
t, cellos::uint64
t, cellos::uint64
t, cellos::uint64
virtual int cellos::iosys::storage::storage
device:ut
cellos::uint64
t, cellos::uint64
t, cellos::uint64
t, cellos::uint64
t, cellos::uint64
t, cellos::uint64
virtual int cellos::iosys::storage::storage
device:ut
cellos::uint64
t, cellos::uint64
t, cellos::uint64
t, cellos::uint64
t, cellos::uint64
t, cellos::uint64
int cellos::iosys::storage::storage
device::confirm
cellos::uint64
XorWithMask
cellos::iosys::storage::storage
initialize
0123456789abcdefghijklmnopqrstuvwxyz
be.0.fir.spu0
be.0.fir.spu0
\\\\ios.net.eurus.lpar

verifier.self
processor.self
processor.self
module.self
verifier.self
module.self
module.self
module.self
module.self
default.spp
kernel.self
init.self
partitions/2
.,/-0.1/2031425364758697:8;9

chr15m's Avatar
#175 - chr15m - 147w ago
sorry boss, in my excitement i should of checked it out more thoroughly, thought waninkoko had come back to life, and would redeem himself. oh well, sigh

grimmmy's Avatar
#174 - grimmmy - 148w ago
Yeah, the 1k is a fake. It even says 'As you should expect from a parody account' in the account description.

Tidusnake666's Avatar
#173 - Tidusnake666 - 148w ago
Great Boss, I almost fell for it Really, the 1k+ account if a fake.

Also, 3.60+ app keys? NONSENSE. What for? What to decrypt? Everything's decrypted with app keys and then encrypted with masterdisk algo. There maybe masterdisk keys, but APP-keys, never

PS3 News's Avatar
#172 - PS3 News - 148w ago
Quote Originally Posted by chr15m View Post
Waninkoko's back.. lol the race to hack 3.6+ f.w is on.

From twitter.com/#!/hackingblack:

hackingblack: Just discovered the 3.60+ app keys on this JB2 dongle IRC user Falcon donated to me.

hackingblack: Isn't releasing things anonymously just great?

hackingblack: My cfw requires no dongle.

I was going to promote this to the main page, but then noticed the Twitter page address and number of followers hehe:

[Register or Login to view links] (fake?) 1,276 followers
[Register or Login to view links] (real) 14,014 followers

Sponsored Links

Sponsored Links
Sponsored Links

Sponsored Links







Advertising - Affiliates - Contact Us - PS3 Downloads - Privacy Statement - Site Rules - Top - © 2014 PlayStation 3 News