PS3 Some eurus firmware, gift courtesy of oct0xor

Interesting, i think this is one of the few times where it can be decompiled 100%
The wifi/BT module is made by ALPS, i never took a look at it but i guess they are distributing the source code of the firmwares of his wifi/BT modules, together with an SDK to compile them
What sony did is to take that source code (public), modify it a bit and compile it

So we could take the public source code from a wifi/BT module made by ALPS (from the same familly and chronologically similar), compile it and compare it with the dump made by oct0xor
In the first attempt there are going to be some notable differences (that indicates the changes made by sony)... so is posible to dissassemble that parts of the code to try to "write" the original source code written by sony... then compile again and compare to see if there are less differences
Is a tedious process, but after repeating that tenths of times (in theory) is posible to generate the original sony source code

I cant imagine any useful hack related with the wifi/BT firmware though... but it would be handy anyway because it would allow full freedom to modify it
Unleash all the gigabit !!!
images
 
In theory, you might use a WiFi/BT or a BD updatable firmware hack to jailbreak a console, such a hack might also be leveraged for instance to apply an automatic jailbreak on boot.

On the PS3 in particular, I would assume that communication with the eurus fw layer is done at lv1 level so hacking the firmware might allow, in turn, to hack lv1, in other words you may obtain a full jailbreak on boot with any console, including the metldr.2 models.
 
Last edited:
Is C++ compiled code btw, is mentioned in a string
Code:
Offset(h) 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F

00001D20  43 2B 2B 20 6C 69 62 72 61 72 79 20 65 78 63 65  C++ library exce
00001D30  70 74 69 6F 6E                                   ption
 
On the PS3 in particular, I would assume that communication with the eurus fw layer is done at lv1 level so hacking the firmware might allow, in turn, to hack lv1, in other words you may obtain a full jailbreak on boot with any console, including the metldr.2 models.

Can you imagine this kind of jailbreak to finally break metldr.2?. A tear is going down my cheek by the thought.
 
Can you imagine this kind of jailbreak to finally break metldr.2?. A tear is going down my cheek by the thought.
I can imagine lots of things, implementing them however is something else..

If I am not mistaken, I dunno much about this, the eurus bin file contains an open source goahead web server running inside ecos (embedded OS layer running in the hardware module).
I would assume that the web server (eurus bin file) gets loaded (by lv1?) into the ecos layer at boot time (?), if so & if we control the bin file contents, we might be able to load a customised version of the web server.
I say "might" because I dunno whether there are obstacles like encryption or checksum verifications in play, it is quite likely, hard to imagine that s#ny would leave this loading process unprotected, one or more exploit might be needed to hack this process.
After that, one would need to investigate the comms between lv1 & the web server, it is quite likely that an overflow in lv1 or similar is achievable by modifying the web server responses to lv1 requests, in turn an overflow may lead to custom code execution at lv1 level (at boot time?).

There are many strategies & targets that could be used to jailbreak a ps3 console.
Syscon, BD, eurus, loaders, Flash memory, lv2 syscalls & lv1 system calls etc..etc...
They are all relevant & very interesting to research but I cannot investigate them all, I already have a long term exploitation project going, I am sticking to it.
 
Last edited:
I can imagine lots of things, implementing them however is something else..

If I am not mistaken, the eurus bin file contains an open source goahead web server running inside ecos (embedded OS layer running in the hardware module).
I would assume that the web server (eurus bin file) gets loaded (by lv1?) into the ecos layer at boot time (?), if so & if we control the bin file contents, we might be able to load a customised version of the web server. I say "might" because I dunno whether there are obstacles like encryption or checksum verifications in play that also need defeated.
After that, one would need to investigate the comms between lv1 & the web server, it is quite likely that an overflow in lv1 or similar is achievable by modifying the web server responses to lv1 requests, in turn an overflow may lead to custom code execution at lv1 level at boot time.

There are many strategies & targets that could be used to jailbreak a ps3 console.
Syscon, BD, eurus, loaders, Flash memory, lv2 syscalls & lv1 system calls etc..etc...
They are all relevant & very interesting to research but I cannot investigate them all, I already have a long term exploitation project going, I am sticking to it.

Indeed, one can only dream at the moment and start doing the proper research (whatever is possible in my hands).

I do believe that encryption and checksums could be in place, but the encryption might be made with a common key as opposed to the per console keys. My evidence is sustained in that you can replace the whole BT/WiFi module and the console boots up as usual, as this piece of hardware is not married to the console. So, if Sony engineers implemented this thing properly (50% chance) then a decryption and checksum should be done, but I'm optimistic in that we can replicate it.
 
I remember the Wii Mini as one of the only instances where a jailbreak via BT had to be implemented because of Nin10doh taking away the SD card slot as well as the GC memcard slots, leaving only 1 little USB port on the back which due to patches on some level could not be easily bypassed and jailbroken until some kind of payload was ran from the Wiimote first... Would be awesome to see something like this come out for PS3 in the near future :)
 
Indeed, one can only dream at the moment and start doing the proper research (whatever is possible in my hands).

I do believe that encryption and checksums could be in place, but the encryption might be made with a common key as opposed to the per console keys. My evidence is sustained in that you can replace the whole BT/WiFi module and the console boots up as usual, as this piece of hardware is not married to the console. So, if Sony engineers implemented this thing properly (50% chance) then a decryption and checksum should be done, but I'm optimistic in that we can replicate it.
You can replace the module because it's not tied to anything, there is no need for that to secure the system, the encryption/signature/checksum checks would most likely be applied to the bin file itself, thus controlling whether or not the web server can be launched in the embedded OS in the module & the comms with lv1 be set up. Without the eurus bin file being loaded into its embedded OS, I assume the module would be useless for lv1, like an "empty shell"..
But like I said I am not familiar with the ins & outs of that process, however if ever the bin file gets decrypted through the usual isolated SPU loader system just like the system binaries, another exploit would be needed in order to attack eurus on metldr.2.
 
Last edited:
I may be wrong, but can we create an HFW noBT with this?
no. the reason is that installation of the BT/WiFi firmware files would still fail. even if we could change the files, they still will not install because of the broken hardware. a normal NoBT CFW just skips the installation...but we have no method of doing that in HFW.
 
Back
Top