1

I dumped a wifi firmware of ps3 console but it seems that this firmware is compressed. Here you can have some informations : https://www.psdevwiki.com/ps3/Wifi_Firmware

Header_img

What can I do to decompress it (and to know which algorithm is used here)or just if someone can give me an advice where to check to go further in the analysis because now I don't have any ideas of what to do :/

Thanks !

EDIT :

Entropy analysis: Entropy_img

File is here.

Here is the datsheet of the chip : https://www.macronix.com/Lists/Datasheet/Attachments/7306/MX25L4005A,%203V,%204Mb,%20v2.2.pdf

I just used basic binwalk and that's it. I'm a beginner in this field so i don't know that much :/

There is no binwalk output.except for entropy:

DECIMAL       HEXADECIMAL     ENTROPY
--------------------------------------------------------------------------------
0             0x0             Falling entropy edge (0.334894)
87040         0x15400         Falling entropy edge (0.818296)
181248        0x2C400         Falling entropy edge (0.807684)
215040        0x34800         Falling entropy edge (0.837182)
226304        0x37400         Falling entropy edge (0.833665)
265216        0x40C00         Falling entropy edge (0.819895)
371712        0x5AC00         Falling entropy edge (0.791722)
  • The file does not appear to contain any compressed data. – julian Oct 30 at 16:28
  • So can you please explain to me the data in them there not in plaintext, can you please take a look on the link i gave in my post ? And with strings I have this : – Martin Oct 30 at 16:50
  • ibb.co/VWJjzkz which clearly seems to be compressed or at least encrypted maybe ? – Martin Oct 30 at 16:56
  • 2
    Ian cook's answer below explains what you are seeing. The architecture of the firmware is big-endian ARM. – julian Oct 31 at 11:26
  • good reference for compression differentiating: devttys0.com/2013/06/… – kimstik Nov 4 at 17:47
3

I believe it is not compressed or encrypted. Entropy of 0.8 is pretty poor for any decent encryption or compression. These regions are more likely to be code.

With this in mind, let's look at a hexdump in the region of the first area of higher entropy at offset 0x00001000 -

00001000:  76 86 65 77 01 01 00 24 FF FF FF FF 00 10 FF FF  v.ew...$........
00001010:  00 00 21 26 00 00 00 00 00 00 00 00 00 00 38 10  ..!&..........8.
00001020:  76 9C 07 9D E5 9F 00 28 EE 01 0F 10 E5 9F D0 24  v......(.......$
00001030:  EA 00 00 0B E5 9F 00 20 E5 9F 10 20 E3 A0 20 00  ....... ... .. .
00001040:  E5 80 10 00 E5 80 10 04 E5 80 20 08 E5 80 20 0C  .......... ... .
00001050:  E1 A0 F0 0E 00 00 1F 74 04 00 20 00 90 00 02 00  .......t.. .....
00001060:  00 00 55 55 E2 8F 80 C4 E8 98 00 03 E0 80 00 08  ..UU............
00001070:  E0 81 10 08 E2 40 B0 01 E1 50 00 01 0A 00 00 13  .....@...P......
00001080:  E8 B0 00 70 E1 54 00 05 0A FF FF FA E3 14 00 01  ...p.T..........

The fact that almost every 4th byte has a high nibble of E is strongly indicative of 32-bit ARM code.

That does leave the question of why areas look garbled. e.g.

000128B0:  47 18 BC 08 65 48 20 3A 6D 20 70 61 72 6F 6D 65  G...eH :m parome
000128C0:  6F 63 20 79 70 75 72 72 00 64 65 74 20 74 75 4F  oc ypurr.det tuO
000128D0:  68 20 66 6F 20 70 61 65 6F 6D 65 6D 00 00 79 72  h fo paeomem..yr

What I believe is happening is that there is some endianness mix-up going on, perhaps with how the flash interfaces with the SOC/MCU or maybe with the settings of the program you used to dump the flash.

So, look again at the region at offset 000128B0 but reverse each group of 4 bytes first. This gives you -

000128B0:  08 BC 18 47 3A 20 48 65 61 70 20 6D 65 6D 6F 72  ...G: Heap memor
000128C0:  79 20 63 6F 72 72 75 70 74 65 64 00 4F 75 74 20  y corrupted.Out 
000128D0:  6F 66 20 68 65 61 70 20 6D 65 6D 6F 72 79 00 00  of heap memory..

This makes much more sense. Other apparent strings become readable with this transformation too.

I'd suggest you apply this to the whole file and see what that gives you.

  • For what it's worth, running binwalk -A returns matches with ARMEB function prologues – julian Oct 31 at 11:23
  • It seems to be the thing !! Thank you for this precious help ! Is there a simple way or a simple tool to perform this on the all data (Windows or Linux I don't mind) ? – Martin Oct 31 at 11:55
1

Do you already tried to analyze the dump with a tool like binwalk?
If not I would recommend to do that first. This may already clarify your situation.
You can also check the entropy with binwalk to verify if this is really compressed or encrypted.

Besides of that my I ask you how you dumped the firmware? Ar you sure that the dump itself is correct?
It kind of reminds me of a project that I was working on not that long ago. I had a few mistakes in my script. Those mistakes made the dump look really weird (e.g. it started correctly and after a few bytes I only had 0xFF bytes, that's why I am asking).

At least just by looking at the picture it doesn't look like .zip, .xz, .gzip to me. If I remember correctly the header formats of those three look different (assuming that your picure shows the beginning of the file). But I am not 100% sure about that, I might be wrong about that.

  • Yeah I already tried that too. Not even once information on it. I dumped it by directly put out the flash of the board and dump it with a XGecu TL866A device. Yeah my dump is good it has a structure and padding and everything looks fine. – Martin Oct 30 at 15:10

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.