{Update} OFW v4.40 for PS3: Now Live & Mandatory

Published on 03-20-2013 11:56 PM

78 Comments

Sony has just published a new OFW update v4.40 for the PS3. This update comes as a bit of a surprise as no prior announcement or details where given from Sony. There are no details on the changes to share from this update. It has been confirmed to be Live and Mandatory by multiple sources. CFW Users: Do Not Update .

Stay tuned as we will report the details here when Sony makes them available to the public and/or when Scene Developers get a look at the changes as well. Has Sony re-secured the system? This will be the first real test for the LV0 Keys since being leaked. How will this OFW Update affect the scene going forward? We hope to have those questions and many others answered shortly. In the meantime, discuss below on what you think of this update by Sony.

Sony has released a new firmware update for the PlayStation 3. Applying the download will upgrade your system to version 4.40.

Users will be prompted to update their systems upon booting up the PlayStation Store. Head on over to the Settings > System Update area for the download.

At the moment, it’s unclear what sort of changes the update makes. If we receive any details about the new firmware, we’ll update this post.

--gamingeverything.com

If you happen to boot up your PS3 right now, you’ll be greeted with a prompt to update to firmware 4.40. A required update, there’s no changelog supplied and nothing appears to be different from the previous firmware at first glance. Still, time to comb around and see if there’s any hidden features lurking within.

exophase

Sources:
ps3hax
gamingeverything
exophase

------------------------- Update -------------------------
Comments and Information from around the Scene

It appears that not much was changed at this point. So far no new keys. Its looks like some Blu-Ray patches where made for some of the new models & support was added for RC-S380 (a Sony NFC Reader). As more things are uncovered we will continue to updates this news article of any new findings that may occur. Check below at the various comments and info posted about this update throughout the scene.

Cyberskunk: You know any of you guys can pull this fw apart.. They did not change any keys.. even in the core.

PSN passphrase has not changed either.. So just change the build number and version number in your spoof files and of course the index.dat if you want to connect.

-Source: Post # 29 / 39

eussNL: FW 4.40 adds support for RC-S380 (a Sony NFC reader) and system stability stuff.. its firmware for new drive model 0xC (ps3devwiki.com/wiki/Bluray_Drive_Firmware#Firmware_Revisions), an update for the 0xA - not for the rest no syscon updates, no key changes, nothing that prevents downgrading either

-Source: ps3hax

Code:

    C:\Root>readself ps3swu.self
    SELF header
      elf #1 offset:  00000000_00000090
      header len:     00000000_00000880
      meta offset:    00000000_000003a0
      phdr offset:    00000000_00000040
      shdr offset:    00000000_00567a30
      file size:      00000000_00b82960
      auth id:        10700003_fd000001 (Unknown)
      vendor id:      01000002
      info offset:    00000000_00000070
      sinfo offset:   00000000_00000260
      version offset: 00000000_00000340
      control info:   00000000_00000350 (00000000_00000070 bytes)
      app version:    4.64.0
      SDK type:       Retail
      app type:       application
     
    Control info
      control flags:
         40 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
      file digest:
         72 f9 cb 71 61 57 cb 24 11 59 9c 0b c2 07 9c ad 28 fd 18 7d
     
    Section header
        offset             size              compressed unk1     unk2
        00000000_00000880  00000000_001fc2c0 [YES]      00000000 00000000
        00000000_00208d10  00000000_0001511e [YES]      00000000 00000000
        00000000_0022dc70  00000000_00268d55 [YES]      00000000 00000000
        00000000_004a2150  00000000_000ba152 [YES]      00000000 00000000
        00000000_0055c2b0  00000000_00000000 [NO ]      00000000 00000000
        00000000_00000000  00000000_00000004 [NO ]      00000000 00000000
        00000000_00000000  00000000_00000020 [NO ]      00000000 00000000
     
    Encrypted Metadata
      unable to decrypt metadata
     
    ELF header
      type:                                 Executable file
      machine:                              PowerPC64
      version:                              1
      phdr offset:                          00000000_00000040
      shdr offset:                          00000000_00b82160
      entry:                                00000000_004e8810
      flags:                                00000000
      header size:                          00000040
      program header size:                  00000038
      program headers:                      7
      section header size:                  00000040
      section headers:                      32
      section header string table index:    31
     
    Program headers
        type  offset            vaddr             paddr
              memsize           filesize          PPU  SPE  RSX  align
         LOAD 00000000_00000000 00000000_00010000 00000000_00010000
              00000000_004c3e30 00000000_004c3e30 r-x  ---  ---  00000000_
         LOAD 00000000_004d0000 00000000_004e0000 00000000_004e0000
              00000000_000301c4 00000000_000301c4 rw-  ---  ---  00000000_
         LOAD 00000000_00510000 00000000_10000000 00000000_10000000
              00000000_00514880 00000000_00514880 r--  r--  ---  00000000_
         LOAD 00000000_00a30000 00000000_10520000 00000000_10520000
              00000000_00172fc8 00000000_00146950 rw-  rw-  ---  00000000_
         LOAD 00000000_00b76950 00000000_00000000 00000000_00000000
              00000000_00000000 00000000_00000000 rw-  rw-  rw-  00000000_
        ????? 00000000_005001c0 00000000_005101c0 00000000_005101c0
              00000000_000001b8 00000000_00000004 r--  ---  ---  00000000_
        ????? 00000000_004c3e10 00000000_004d3e10 00000000_004d3e10
              00000000_00000020 00000000_00000020 ---  ---  ---  00000000_
     
    Section headers
      [Nr] Name            Type      Addr              ES Flg Lk Inf Al
           Off                       Size
      [00] <no-name>       NULL      00000000_00000000 00     00 000 00
           00000000_00000000         00000000_00000000
      [01] <no-name>       PROGBITS  00000000_000101c8 00 wa  00 000 04
           00000000_000001c8         00000000_0000002c
      [02] <no-name>       PROGBITS  00000000_000101f8 00 wa  00 000 08
           00000000_000001f8         00000000_004c2314
      [03] <no-name>       PROGBITS  00000000_004d250c 00 wa  00 000 04
           00000000_004c250c         00000000_00000040
      [04] <no-name>       PROGBITS  00000000_004d254c 00 wa  00 000 04
           00000000_004c254c         00000000_00000024
      [05] <no-name>       PROGBITS  00000000_004d2570 00  a  00 000 04
           00000000_004c2570         00000000_0000189c
      [06] <no-name>       PROGBITS  00000000_004d3e10 00  ae 00 000 08
           00000000_004c3e10         00000000_00000020
      [07] <no-name>       PROGBITS  00000000_004e0000 00  ae 00 000 04
           00000000_004d0000         00000000_00000178
      [08] <no-name>       PROGBITS  00000000_004e0178 00  ae 00 000 04
           00000000_004d0178         00000000_00000104
      [09] <no-name>       PROGBITS  00000000_004e027c 00  ae 00 000 04
           00000000_004d027c         00000000_00000004
      [10] <no-name>       PROGBITS  00000000_004e0280 00  ae 00 000 04
           00000000_004d0280         00000000_00004cb4
      [11] <no-name>       PROGBITS  00000000_004e4f38 00  ae 00 000 08
           00000000_004d4f38         00000000_000038c4
      [12] <no-name>       PROGBITS  00000000_004e8800 00  ae 00 000 04
           00000000_004d8800         00000000_0001d768
      [13] <no-name>       PROGBITS  00000000_00505f68 04  ae 00 000 08
           00000000_004f5f68         00000000_0000a258
      [14] <no-name>       PROGBITS  00000000_005101c0 00  ae 00 000 08
           00000000_005001c0         00000000_00000004
      [15] <no-name>       NOBITS    00000000_005101c8 00  ae 00 000 08
           00000000_005001c4         00000000_000001b0
      [16] <no-name>       PROGBITS  00000000_10000000 00  a  00 000 128
           00000000_00510000         00000000_000b6468
      [17] <no-name>       PROGBITS  00000000_100b6468 00  a  00 000 04
           00000000_005c6468         00000000_00000028
      [18] <no-name>       PROGBITS  00000000_100b6490 00  a  00 000 04
           00000000_005c6490         00000000_00000004
      [19] <no-name>       PROGBITS  00000000_100b6494 00  a  00 000 04
           00000000_005c6494         00000000_00000004
      [20] <no-name>       PROGBITS  00000000_100b6498 00  a  00 000 04
           00000000_005c6498         00000000_00000004
      [21] <no-name>       PROGBITS  00000000_100b649c 00  a  00 000 04
           00000000_005c649c         00000000_00000004
      [22] <no-name>       PROGBITS  00000000_100b64a0 00  a  00 000 04
           00000000_005c64a0         00000000_0000002c
      [23] <no-name>       PROGBITS  00000000_100b64cc 00  a  00 000 04
           00000000_005c64cc         00000000_0000001c
      [24] <no-name>       PROGBITS  00000000_100b6500 00  ae 00 000 128
           00000000_005c6500         00000000_0045e380
      [25] <no-name>       PROGBITS  00000000_10520000 00  ae 00 000 128
           00000000_00a30000         00000000_0014694c
      [26] <no-name>       PROGBITS  00000000_10666950 00  ae 00 000 08
           00000000_00b76950         00000000_00000000
      [27] <no-name>       NOBITS    00000000_10666950 00  ae 00 000 01
           00000000_00000000         00000000_00000000
      [28] <no-name>       NOBITS    00000000_10666950 00  ae 00 000 16
           00000000_00b76950         00000000_0002c678
      [29] <no-name>       PROGBITS  00000000_00000000 00     00 000 01
           00000000_00b76950         00000000_0000b6c0
      [30] <no-name>       PROGBITS  00000000_00000000 00     00 000 04
           00000000_00b82010         00000000_00000028
      [31] <no-name>       STRTAB    00000000_00000000 00     00 000 01
           00000000_00b82038         00000000_00000126

--Source

images courtesy of ps3hax.net

PSX-SCENE: The Pinnacle Scene Xenocracy

● Latest News ● Report News ● Search Forums ● Hall of Fame ●
● Facebook.com/PSXScene ● RSS ● Twitter.com/psx_scene ●

Share
- Share this post on
- Digg
- Del.icio.us
- Technorati
- Twitter

Categories:

_{Tags :

official firmware,

ofw update,

ps3}

78 Comments

indirect76 - 03-21-2013, 04:45 PM
- Reply
Originally Posted by deank

The online version of mM is updated to support 4.40CFW. Rogero/Rebug can use it to test their upcoming firmwares.

All the stuff is there: BD Movie region change, DYNAREC, payload, PS1 ISO+BIN backups, PS1 disc-backups, PS3 backups, etc.

mM online version is now fully compatible with 4.40CFW.

¿¿¿

Man, what took you so long? 4.40 has been out for almost a whole day!

deank - 03-21-2013, 04:47 PM
- Reply
I just came back home and read the news... It took 30 min to add support. Using mM's new payload makes it quite simple.

indirect76 - 03-21-2013, 04:51 PM
- Reply
Originally Posted by deank

I just came back home and read the news... It took 30 min to add support. Using mM's new payload makes it quite simple.

HaHa, well I'm sure you know I'm joking. Thanks for the update!

l_oliveira - 03-21-2013, 05:16 PM
- Reply
Originally Posted by cyto

Marcan vehemently disagrees with you: “The first-stage bootloader is in ROM and has a per-console key which is effectively in tamper-resistant silicon. The second-stage bootloader (bootldr) is encrypted with the per-console key, but is not upgradable and is the same for all consoles (other than the encryption wrapper around it). This second-stage bootloader verifies lv0. Sony signed lv0 using the same broken process that they used for everything else, which leaks their private key. This means that the lv0 private key was doomed from the start, ever since we demonstrated the screwup at the Chaos Communication Congress two years ago." -From his blog

Wololo also said on his site: "Q: So bootldr is fixed in hardware?
A: Correct. Like metldr, bootldr cannot be software updated by Sony. It’s hard-coded in hardware. As a reminder, bootldr/metldr themselves can’t be exploited, but because of the keys we have recovered we can make them load anything we want, nullifying whatever security they provide."

I'm gonna side with the experts on this one.

Well I'll link you with one piece of the PS3DEVWIKI here:
Flash:Individual System Data - cISD - PS3 Development Wiki

With a simple read from cISD1 they can retrieve the KIBAN ID (This is the barcode printed on the board) and from that they know EXACTLY which motherboard is that which is connecting to the server. From that they can go through their internal database, retrieve SYSCON and CELLBE keys for encrypting a new bootldr/metldr2 pair for that system. Then they can just overwrite the respective sections of the flash and be done with it.

It's not that hard. The only challenge is access their own internal database and generate the new bootloader and have it flashed.

So don't trust they cannot do it. They can. They just didn't yet. And they might not (it may cost too much to develop a solution to do this).

Edit: Obviously I am saying that about consoles which are hanging on the internet with a live connection to the SEN/PSN.

alivingston - 03-21-2013, 05:20 PM
- Reply
Originally Posted by deank

I just came back home and read the news... It took 30 min to add support. Using mM's new payload makes it quite simple.

Your the man deank.................hopefully Rogero will be able to do the same in a timely fashion. Not great at programing, but let me know if you need help with anything.

cyto - 03-21-2013, 06:54 PM
- Reply
Originally Posted by l_oliveira

Well I'll link you with one piece of the PS3DEVWIKI here:
Flash:Individual System Data - cISD - PS3 Development Wiki

With a simple read from cISD1 they can retrieve the KIBAN ID (This is the barcode printed on the board) and from that they know EXACTLY which motherboard is that which is connecting to the server. From that they can go through their internal database, retrieve SYSCON and CELLBE keys for encrypting a new bootldr/metldr2 pair for that system. Then they can just overwrite the respective sections of the flash and be done with it.

It's not that hard. The only challenge is access their own internal database and generate the new bootloader and have it flashed.

So don't trust they cannot do it. They can. They just didn't yet. And they might not (it may cost too much to develop a solution to do this).

Edit: Obviously I am saying that about consoles which are hanging on the internet with a live connection to the SEN/PSN.

No, you are missing what everyone is saying. The Metldr/bootldr are fixed into hardware and sealed in tamper resistant silicon meaning you would have a difficult time even flashing them with hardware flashers. Sony CANNOT change them and all this stuff you posted has nothing to do with the loader modules. It's all per console stuff.

Again, Wololo says,"Remember how we said bootldr and metldr are fixed in hardware? Sony can create new hardware, and update those modules in the process. By using new hardware in conjunction with new firmware for that hardware, Sony could completely change the keys used to secure the system."

So in other words, only newer hardware can have the updated modules in the fixed bootldr areas, hence the super slim PS3.

Marcan further explains, "The chain of trust is safely rooted in hardware that is near impossible to modify (i.e. the CPU’s ROM and eFuse key). The next link down the chain has been compromised (bootldr), and this link cannot be updated as it is specific to each console, so the chain of trust now has a permanent weak second link. However, the third link, lv0, can be updated as it is located in flash memory and signed using public key crypto."

LV0 is in flash and can be updated just a Wololo said, but it requires new hardware and firmware.

l_oliveira - 03-21-2013, 07:36 PM
- Reply
Please stop wasting your time discussing and read this:
Flash - PS3 Development Wiki

bootldr is at 0xFC0000 of a NOR dump.

It's purpose is initialize the hardware then locate, load unpack and certify a file called "lv0" inside of the active ROS partition, also within the flash.

What is sealed in secure silicon is a ROM which loads bootldr.

Finally read this, please:

Boot Order - PS3 Development Wiki

Mentalist - 03-21-2013, 09:45 PM
- Reply
Just relax people, be patient and wait... I bet up until this very weekend we will be having a 4.40 CFW Rogero or maybe rebug. Keep in mind that sony is now more focused in the PS4. Just sit and wait and you will be updating your current CFW to 4.40 not even needing to downgrade it. Farewell.

andre104623 - 03-21-2013, 11:43 PM
- Reply
Originally Posted by l_oliveira

Please stop wasting your time discussing and read this:
Flash - PS3 Development Wiki

bootldr is at 0xFC0000 of a NOR dump.

It's purpose is initialize the hardware then locate, load unpack and certify a file called "lv0" inside of the active ROS partition, also within the flash.

What is sealed in secure silicon is a ROM which loads bootldr.

Finally read this, please:

Boot Order - PS3 Development Wiki

I was done fighting this subject with you hours ago BUT FOR THE LAST TIME SONY CANNOT CHANGE BOOTLOADER FROM FIRMWARE UPDATES!! ITS HARDCODED!! THEY CANNOT CHANGE LV0 KEYS!!! I dont know why you have a hard time understanding this. 4.31 was out for almost 5 months they had 5 months to try fixing this THEY CAN'T!! If everyone had a super slim then yes they can change LV0 keys but since alot of people have older phat and slims on old hardware they can never change LV0 period

l_oliveira - 03-22-2013, 12:43 AM
- Reply
Originally Posted by andre104623

I was done fighting this subject with you hours ago BUT FOR THE LAST TIME SONY CANNOT CHANGE BOOTLOADER FROM FIRMWARE UPDATES!! ITS HARDCODED!! THEY CANNOT CHANGE LV0 KEYS!!! I dont know why you have a hard time understanding this. 4.31 was out for almost 5 months they had 5 months to try fixing this THEY CAN'T!! If everyone had a super slim then yes they can change LV0 keys but since alot of people have older phat and slims on old hardware they can never change LV0 period

It's obvious they cannot update the bootloader with just a update pup and it's not what I was discussing. You're saying the bootloader is static and set in stone. It is not. And that's the point I am trying to expose.

A lot of people do take their CFW PS3s to the internet. Should SONY decide to act you will see the panic. The only requirement for such a update to be possible for SONY to implement is Internet connectivity.

Anyway, this is only a concern for people using OFW on downgradable consoles. The result of such update is that downgradable consoles would become non downgradable.

As most of us with CFW PS3s have backups of the old bootldr signed for the motherboard on our consoles.

adrenalineforu - 03-22-2013, 02:27 AM
- Reply
Originally Posted by deank

The online version of mM is updated to support 4.40CFW. Rogero/Rebug can use it to test their upcoming firmwares.

All the stuff is there: BD Movie region change, DYNAREC, payload, PS1 ISO+BIN backups, PS1 disc-backups, PS3 backups, etc.

mM online version is now fully compatible with 4.40CFW.

Love ya man!!!! Super-cool. Just one more improvement I seek - the copy speed. As you and me are already aware games with smaller files takes hell long to copy. Can mm not copy/write like windows in MBps in stead of doing file-wise? Thanks.

andre104623 - 03-22-2013, 07:43 AM
- Reply
Originally Posted by l_oliveira

It's obvious they cannot update the bootloader with just a update pup and it's not what I was discussing. You're saying the bootloader is static and set in stone. It is not. And that's the point I am trying to expose.

A lot of people do take their CFW PS3s to the internet. Should SONY decide to act you will see the panic. The only requirement for such a update to be possible for SONY to implement is Internet connectivity.

Anyway, this is only a concern for people using OFW on downgradable consoles. The result of such update is that downgradable consoles would become non downgradable.

As most of us with CFW PS3s have backups of the old bootldr signed for the motherboard on our consoles.

Your problem is bootloader and bootldr are not the same you need to read more about how the ps3 works

l_oliveira - 03-22-2013, 08:04 AM
- Reply
Originally Posted by andre104623

Your problem is bootloader and bootldr are not the same you need to read more about how the ps3 works

I am a IDIOT for wasting my time arguing with you.

DenimSansCoeur - 03-22-2013, 10:47 AM
- Reply
agreed.

ieder-zijn-meis - 03-22-2013, 01:00 PM
- Reply
Originally Posted by andre104623

Your problem is bootloader and bootldr are not the same you need to read more about how the ps3 works

Correct, bootloader/bootldr and lv0ldr (sometimes called bootldr but not actually the same!) are different entities in different hardware locations. For historic reasons that naming misnomer has not been corrected on wiki (instead when referring to the bootldr in flash it is sometimes named lv0ldr as that is its main goal: loading lv0 besides preinitialising and testing hardware).

Also, not all consoles have the same lv0ldr in flash, and also have different perconsolekeys in their CellBE, but the bootldr used before that is the same for all Cell BE revisions (unless there where microcode updates on it, but I even doubt that).

Further, to update lv0ldr (the bootldr in flash), you would need to have code in ps3swu.self that can gain the perconsolekeys and for obvious reasons you would /never/ put that in the wild - only infactory. Having connections to online server and gain them from a centralised database is even further away from the truth, as that would undo all security steps they included in regard to the CEX2DEX releases.

Sony repair actually sometimes replaces lv0ldr for newer revisions, even on older hardware. There is a list of revisions (including their keys) seen per SKU on the Validation page and talk pages of both metldr and bootldr (in flash, aka lv0ldr)

l_oliveira - 03-22-2013, 01:14 PM
- Reply
I find interesting that everyone is overlooking the possibility of them upon identifying unit specific keys by crossing the Motherboard IDs from cISD with their own database, generate a new bootldr/metldr set at some secure server and send it back to the console already encrypted and ready to use, through the Internet. They won't expose anything security critical by doing that. All it takes is them code something to do that and add it to the OS.

While it would prevent off-line updates to the boot loaders, nothing keep them from putting something on the OS to allow them do that with the consoles while being used with the PSN online.

All I was going to suggest is that people keep copies from their bootldr (lv0ldr) and metldr if their console is downgradable (in OFW) or is hacked. :\

ieder-zijn-meis - 03-22-2013, 02:04 PM
- Reply
Originally Posted by l_oliveira

I find interesting that everyone is overlooking the possibility of them upon identifying unit specific keys by crossing the Motherboard IDs from cISD with their own database, generate a new bootldr/metldr set at some secure server and send it back to the console already encrypted and ready to use, through the Internet.

see my remark: "Having connections to online server and gain them from a centralised database is even further away from the truth, as that would undo all security steps they included in regard to the CEX2DEX releases."
Keep in mind also that we currently have no way of gaining CellBE efuses/keys nor its bootloader and that al you need to break that is Sony slipping (as we already can dump lv0ldr decrypted).
The other issue of having lv0ldr and/or metldr updated is the dual bank nature of system files. Normally you have one bootdr (lv0ldr) and one metldr (or metldr.2) and 2 CoreOS and 2 Recovation Program and 2 Recovation Package. Syscon has 2 simular banks in its encrypted hashbank of the userarea. A system that must be capable to boot both your proposed newer revision must also be capable of running its previous revision and that would imply 2 sets of bootldr (lv0ldr) and metldr or compatibility mode that supports both - eitherway a security risk and enhanced update risk (on metldr.2 with its lv0 metasigned lv0.2 added checks they just made it themselves simple and hardcoded a version check that disables the capability of running below its metldr check - thus it only has to have one (lv0ldr/metldr) loader for all revisions it supports)

cISD and eEID are pretty much completely mapped out on ps3devwiki- so far they did not use eEID5 for stopping CEX2DEX like expected but instead chose to add a secundairy check in lv1ldr but they did not change the lv0 crypto nor its embedded loader obfuscation.

Originally Posted by l_oliveira

They won't expose anything security critical by doing that. All it takes is them code something to do that and add it to the OS.

Which we pwn and thus also have the crypto in hands they use.

Originally Posted by l_oliveira

While it would prevent off-line updates to the boot loaders, nothing keep them from putting something on the OS to allow them do that with the consoles while being used with the PSN online.

Basic cryptography disagrees with you about updating crypto in an insecure environment without any possibility to check for secured root.

Originally Posted by l_oliveira

All I was going to suggest is that people keep copies from their bootldr (lv0ldr) and metldr if their console is downgradable (in OFW) or is hacked. :\

Keeping a copy of decrypted lv0ldr and metldr are a lot more interesting, as they reveal how hardware is initialised and how the chain of trust is vulnerable for attacks just after the secured root is initialised.

Speaking of secured root, that is more likely where a final closure would be expected. That is why developers are keeping an eye on updates made to syscon and want to know as much as possible from that hardened environment (basicly it like a seperate ARM computer, with proprietary encrypted and authenticated communication to its subsystems, CellBE, Southbridge (and from there to flash, ATA etc).

Heihachi - 03-22-2013, 04:26 PM
- Reply
Originally Posted by adrenalineforu

PSN store app has a 29MB update. Is it safe to update the app? Anyone tested so far.

yes the psn update is just to prevent people from stealing the PSID from OFW users. As they can't see the id on the computer anymore using ps3 proxy and wireshark.
As people before used to take quite a few id's off of OFW users just to get back online.

As i'm trying to fix my psid myself with another unbanned id i have from a broken ps3.
As for 4.40 ofw it seems the locations of the id's has yet changed again.