[oPolo]

Originally Posted by etertay couldent we find out what time they are being loaded into ram by analyzing 3.55 and then using the same time on 3.56+? or does everything being stored in lv0 change the timing?

A bit more technological matter in regards to this that I have been considering.. I have heard about reading the keys from the RAM multiple times, and I wrote about it myself too at once... But, how do we know, they aren't stored in the registers in the cell? I mean, do we have a proof that the keys leave the cpu and are stored in the RAM? Safety wise, it would seem safer to decrypt the lv0 key with the key inside the cell, and then store the decrypted lv0 key in a CPU register while it is being used to decrypt other stuff. - I guess it would be possible? And considering how much the key would be used while decrypting, and then not used afterwards, it seems to make sense to store it in a register?

[master737373]

Just throwing my 2 cents in there.

The OP was somewhat (and i use somewhat extremely lightly) close when it comes to dumping a decrypted 3.56+ lv0. Yes, you can get it using a 3.55 machine. Well, you NEED a 3.55 machine if you want to get what's necessary to actually use lv0. Lv0 is decrypted and stored in the RAM, but the process of timing everything correctly is the hard part. It needs to be done in less that a second after powering the system if you want lv0. That is, if you want to use the relatively easy method.

[etertay]

Originally Posted by oPolo A bit more technological matter in regards to this that I have been considering.. I have heard about reading the keys from the RAM multiple times, and I wrote about it myself too at once... But, how do we know, they aren't stored in the registers in the cell? I mean, do we have a proof that the keys leave the cpu and are stored in the RAM? Safety wise, it would seem safer to decrypt the lv0 key with the key inside the cell, and then store the decrypted lv0 key in a CPU register while it is being used to decrypt other stuff. - I guess it would be possible? And considering how much the key would be used while decrypting, and then not used afterwards, it seems to make sense to store it in a register?

correct me if im wrong, but if sony can change the security keys with each firmware update, that means they are stored in a re-writable area (aka, not the processor) i dont know if the lv0 keys are updated with the firmware or not.

[master737373]

Originally Posted by etertay correct me if im wrong, but if sony can change the security keys with each firmware update, that means they are stored in a re-writable area (aka, not the processor) i dont know if the lv0 keys are updated with the firmware or not.

lv0, is stored in the flash. but just because it's able to be updated doesn't mean it's in a special area, per se. It's in a somewhat special place. Bootldr can't be updated, but it's also on the flash too.

[oPolo]

Originally Posted by etertay correct me if im wrong, but if sony can change the security keys with each firmware update, that means they are stored in a re-writable area (aka, not the processor) i dont know if the lv0 keys are updated with the firmware or not.

If I understood what you meant correctly, then where it is stored in relation to what you talk of is not of importance. The keys need to be stored somewhere persistent that will not disappear after being powered off. However, you dont operate directly on the data on the persistent storage device (ie. harddisk, flash), as that is waay to slow. Accessing a harddisk takes in the order of miliseconds, so data is only fetched and then stored in RAM, while being operated on as the acces times on RAM is in the order of nanoseconds. That's a very rough description, ofc there is limited RAM so sometimes the harddisk needs to store data anyway, etc. Anyway, if they are stored in the RAM, the theory is we can dump the RAM, when the processor decrypts the bootloader and stores the result in the RAM, and then snatch the keys.
But there is a storage area even closer to the CPU than the RAM. The CPU(a register based CPU atleast -_-), has some internal registers it uses to hold data such as integers that are being accessed many times, operands/results in/of a multiplication, addition, etc.. Those can usually hold stuff like 32/64bit integers(I don't know if the cell is the former or latter.. a bit embarassing actually)... Since the key would be used so much, I just thought it would be natural to store it in a register while it is being used, so it isn't a guarantee that the key would be obtainable via a dump of the RAM?
Ofc, also for matters of security it would be safer to keep the decryption key in a register.

EDIT: Just thought, what we are after aren't keys, but the entire lv0? I guess.. When it decrypts the lv0, they wouldn't have gone that far as to store the whole lv0 in the RAM, except for the ldr keys, which would then be stored in the registers... That would be way too advanced.

[Gonzakpo]

Well, for some time I wanted to try to dump the RAM of the PS3. I have the tools and the knowledge but the truth is, I don't want to put my only PS3 in risk (it is not a foolproof process) and it takes too much time!

If you visit ps3devwiki, in the XDR RAM section, you'll find all the datasheets. There's one that talks about the XDR Clock generator. In it you'll find a PIN called /BYPASS that disables the PLL thus slowing down the processor + XDR ram. Also, you could even slow down the PS3 oscillator. But I have yet to figure it out.

If you slow down the XDR and processor, you would be able to "snoop" on the bus with a relatively cheap hardware (I was thinking in a basic logic analyzer implemented in an FPGA) and dump the memory contents as it get written during boot up.

Of course, if you have access to a logic analyzer that can snoop on the bus without slowing it down, then the it will be much easier. But I bet that logic analyzer would cost above $15K.

I'm not sure about this. But maybe the decrypted lv0 gets copied to RAM during boot up. With that you could be able to get all the needed keys EXCEPT for the lv0 keys and the bootloader keys of course. So, you won't be able to make a CFW but if you have total access to a decrypted lv0, probably a software hacker could find new exploits.

But well, as I said before, I really don't have enough time to through this and also I don't have a spare PS3s to test with. It is not a simple task and I don't even sure if the PS3 will boot up with the clock slowed down.

Only a person fully dedicated to this would have the time to do it.

[fuRh7]

I was thinking some time ago about how could we use MathLDR exploit ( the one that fetches the decrypted metldr - with keys) to fetch the decrypted bootldr ( hopefully with keys ). Since the bootldr can't be updated, it can be achieved on 3.55 and be still used on every new firmware that is released as the chain of trust would be broken on the very beggining . Since the metldr and the bootldr are encrypted with the same key ( per_console_key_0 ) if we could somehow fetch with software or hardware that part of RAM that decrypts the metldr with mathldr exploit, we would have the per_console_key_0 that means--> decrypted bootldr --> decrypted lv0 --> probably new cfw or atleast fully open PS3 ... just my 2 cents... I am no developer, nor do I pretend to be one. I was just looking on ps3devwiki the other day and idea came to me.

[oPolo]

Originally Posted by Gonzakpo Well, for some time I wanted to try to dump the RAM of the PS3. I have the tools and the knowledge but the truth is, I don't want to put my only PS3 in risk (it is not a foolproof process) and it takes too much time! If you visit ps3devwiki, in the XDR RAM section, you'll find all the datasheets. There's one that talks about the XDR Clock generator. In it you'll find a PIN called /BYPASS that disables the PLL thus slowing down the processor + XDR ram. Also, you could even slow down the PS3 oscillator. But I have yet to figure it out. If you slow down the XDR and processor, you would be able to "snoop" on the bus with a relatively cheap hardware (I was thinking in a basic logic analyzer implemented in an FPGA) and dump the memory contents as it get written during boot up. Of course, if you have access to a logic analyzer that can snoop on the bus without slowing it down, then the it will be much easier. But I bet that logic analyzer would cost above $15K. I'm not sure about this. But maybe the decrypted lv0 gets copied to RAM during boot up. With that you could be able to get all the needed keys EXCEPT for the lv0 keys and the bootloader keys of course. So, you won't be able to make a CFW but if you have total access to a decrypted lv0, probably a software hacker could find new exploits. But well, as I said before, I really don't have enough time to through this and also I don't have a spare PS3s to test with. It is not a simple task and I don't even sure if the PS3 will boot up with the clock slowed down. Only a person fully dedicated to this would have the time to do it.

I have thought about sending it a lower clock frequency too thus slowing it and must say, It seems realistic what you are saying, I can't see why it shouldn't work.

I must admit, I understand you when it comes to risking your PS3. Although I'm a bit sad to say it also, as it could be cool if someone skilled worked on it (Not saying skilled people aren't already working on it). I don't have that much hardware engineering knowledge sadly.. My field I would have to say lies a bit higher than those hardware levels you were getting at Although I ironically find the lowest levels as exciting or even more.. And If I had, had the skills I wouldn't have said tools either anyway..
Anyway, my PS3 is my girlfriend's as well, so I understand clearly when you say, you wouldn't want to risk it
************* [ - Post Merged - ] *************

Originally Posted by fuRh7 I was thinking some time ago about how could we use MathLDR exploit ( the one that fetches the decrypted metldr - with keys) to fetch the decrypted bootldr ( hopefully with keys ). Since the bootldr can't be updated, it can be achieved on 3.55 and be still used on every new firmware that is released as the chain of trust would be broken on the very beggining . Since the metldr and the bootldr are encrypted with the same key ( per_console_key_0 ) if we could somehow fetch with software or hardware that part of RAM that decrypts the metldr with mathldr exploit, we would have the per_console_key_0 that means--> decrypted bootldr --> decrypted lv0 --> probably new cfw or atleast fully open PS3 ... just my 2 cents... I am no developer, nor do I pretend to be one. I was just looking on ps3devwiki the other day and idea came to me.

Without really knowing much about what I'm saying now.. It seems the bootloader is loaded into an isolated part of the processor and isn't stored in the RAM, although I might be completely wrong.. Obviously Naerhwert is doing some work with lv0 and bootloaders, so something is possible.

Source on bootloader: http://www.ps3devwiki.com/wiki/Boot_Order

[DjKlown]

Originally Posted by fuRh7 I was thinking some time ago about how could we use MathLDR exploit ( the one that fetches the decrypted metldr - with keys) to fetch the decrypted bootldr ( hopefully with keys ). Since the bootldr can't be updated, it can be achieved on 3.55 and be still used on every new firmware that is released as the chain of trust would be broken on the very beggining . Since the metldr and the bootldr are encrypted with the same key ( per_console_key_0 ) if we could somehow fetch with software or hardware that part of RAM that decrypts the metldr with mathldr exploit, we would have the per_console_key_0 that means--> decrypted bootldr --> decrypted lv0 --> probably new cfw or atleast fully open PS3 ... just my 2 cents... I am no developer, nor do I pretend to be one. I was just looking on ps3devwiki the other day and idea came to me.

Math said him self that this is how it is.... same "exploit" can do the boot loader...
Knock it out

[master737373]

Originally Posted by fuRh7 I was thinking some time ago about how could we use MathLDR exploit ( the one that fetches the decrypted metldr - with keys) to fetch the decrypted bootldr ( hopefully with keys ). Since the bootldr can't be updated, it can be achieved on 3.55 and be still used on every new firmware that is released as the chain of trust would be broken on the very beggining . Since the metldr and the bootldr are encrypted with the same key ( per_console_key_0 ) if we could somehow fetch with software or hardware that part of RAM that decrypts the metldr with mathldr exploit, we would have the per_console_key_0 that means--> decrypted bootldr --> decrypted lv0 --> probably new cfw or atleast fully open PS3 ... just my 2 cents... I am no developer, nor do I pretend to be one. I was just looking on ps3devwiki the other day and idea came to me.

Lol you won't get the PCK_0 without the hardware needed to dump the cell, which costs thousands of dollars. You can find one at IBM, you'll be lucky to get it to your PS3.

Originally Posted by oPolo Without really knowing much about what I'm saying now.. It seems the bootloader is loaded into an isolated part of the processor and isn't stored in the RAM, although I might be completely wrong.. Obviously Naerhwert is doing some work with lv0 and bootloaders, so something is possible. Source on bootloader: http://www.ps3devwiki.com/wiki/Boot_Order

You're right, bootldr is never loaded into the RAM, but an isolated SPU. It's there while encrypted and decrypted.