Talk:Flash Structure: Difference between revisions
m (Flash:0FACE0FF DEADFACE) |
m (Flash:CELL EXTNOR AREA) |
||
Line 191: | Line 191: | ||
|- | |- | ||
|} | |} | ||
= cell_ext_os_area = | = cell_ext_os_area = |
Revision as of 14:40, 26 November 2012
First Region
Second Region
NOR only: 0x0F00000 - 0x0F00020
This region appears to directly follow the other region (at 0xF0000 = region size + header)
Not much is known about this at this stage.
On NAND consoles without OtherOS the block 0x0F00000 - 0x0F7FFFF is zero filled
On NAND consoles with OtherOS the block 0x0F00000 - 0x0F00FFF is filled with data
00 filled block
example
NOR: 0x0F00030 - 0x0F000BF | NAND: |
---|---|
Offset(h) 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F 00F00030 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ .... (00 filled block) 00F000B0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ |
N.A. |
structure
Address | Length | Value | Description |
---|---|---|---|
0x30 | 0x90 | 0x0 | Blank/Unknown |
Unknown block
example
NOR: 0x0F000C0 - 0x0F000EF | NAND: |
---|---|
Offset(h) 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F 00F000C0 00 00 00 00 00 00 79 00 00 00 00 00 00 00 01 00 ......y......... 00F000D0 10 70 00 00 01 00 00 01 00 00 00 00 00 00 00 03 .p.............. 00F000E0 10 70 00 00 02 00 00 01 00 00 00 00 00 00 00 03 .p.............. |
N.A. |
structure
Address | Length | Value | Description |
---|---|---|---|
0xC0 | 0x8 | 0x7900 | Unknown |
0xC8 | 0x8 | 0x100 | Unknown |
0xD0 | 0x2 | 0x1070 | Unknown |
0xD2 | 0x2 | 0x0 | Blank/Unknown |
0xD4 | 0x2 | 0x100 | Unknown |
0xD6 | 0x2 | 0x1 | Unknown |
0xD8 | 0x8 | 0x3 | Unknown |
0xE0 | 0x2 | 0x1070 | Unknown |
0xE2 | 0x2 | 0x0 | Blank/Unknown |
0xE4 | 0x2 | 0x200 | Unknown |
0xE6 | 0x2 | 0x1 | Unknown |
0xE8 | 0x8 | 0x3 | Unknown |
00 filled block
example
NOR: 0x0F000F0 - 0x0F0014F | NAND: |
---|---|
Offset(h) 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F 00F000F0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ .... (00 filled block) 00F00140 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ |
N.A. |
structure
Address | Length | Value | Description |
---|---|---|---|
0xF0 | 0x60 | 0x0 | Blank/Unknown |
Unknown block
example
NOR: 0x0F00150 - 0x0F0017F | NAND: |
---|---|
Offset(h) 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F 00F00150 00 00 00 00 00 00 7A 00 00 00 00 00 00 00 04 00 ......z......... 00F00160 10 70 00 00 01 00 00 01 00 00 00 00 00 00 00 03 .p.............. 00F00170 10 70 00 00 02 00 00 01 00 00 00 00 00 00 00 03 .p.............. |
N.A. |
structure
Address | Length | Value | Description |
---|---|---|---|
0xC0 | 0x8 | 0x7A00 | Unknown |
0xC8 | 0x8 | 0x400 | Unknown |
0xD0 | 0x2 | 0x1070 | Unknown |
0xD2 | 0x2 | 0x0 | Blank/Unknown |
0xD4 | 0x2 | 0x100 | Unknown |
0xD6 | 0x2 | 0x1 | Unknown |
0xD8 | 0x8 | 0x3 | Unknown |
0xE0 | 0x2 | 0x1070 | Unknown |
0xE2 | 0x2 | 0x0 | Blank/Unknown |
0xE4 | 0x2 | 0x200 | Unknown |
0xE6 | 0x2 | 0x1 | Unknown |
0xE8 | 0x8 | 0x3 | Unknown |
00 filled block
example
NOR: 0x0F00180 - 0x0F00FFF | NAND: |
---|---|
Offset(h) 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F 00F00180 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ .... (00 filled block) 00F00FF0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ |
N.A. |
structure
Address | Length | Value | Description |
---|---|---|---|
0x180 | 0xE80 | 0x0 | Blank/Unknown |
unreferenced area
NOR+NAND : 0x0F01000 - 0x0F1FFFF
example
NOR: 0x0F01000 - 0x0F1FFFF | NAND: 0x0F01000 - 0x0F1FFFF |
---|---|
Offset(h) 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F 00F01000 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ .... 00F1FFF0 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ |
Offset(h) 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F 00F01000 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ .... 00F1FFF0 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ |
structure
Address | Length | Value | Description |
---|---|---|---|
0x1000 | 0x1F000 | 0xFF | Blank/Unknown |
cell_ext_os_area
NAND only
OtherOS
NAND only
00 filled block
Offset(h) 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F 0EA00040 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ .... 0EB7FFF0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
FF filled block
Offset(h) 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F 0EB80000 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ .... 0EFBFFF0 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ
small non-FF sections (inside FF filled block)
Note: not seen in all NAND dumps.
NAND: 1100 | NAND: 0100 | NAND: 7F FF FF 11 00 | NAND: 7F FF FF 21 00 |
---|---|---|---|
Offset(h) 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F 0FF00100 FF FF FF FF 11 00 FF FF FF FF FF FF FF FF FF FF ÿÿÿÿ..ÿÿÿÿÿÿÿÿÿÿ |
Offset(h) 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F 0FF00100 FF FF FF FF 01 00 FF FF FF FF FF FF FF FF FF FF ÿÿÿÿ..ÿÿÿÿÿÿÿÿÿÿ |
Offset(h) 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F 0FF00100 FF 7F FF FF 11 00 FF FF FF FF FF FF FF FF FF FF ÿ.ÿÿ..ÿÿÿÿÿÿÿÿÿÿ |
Offset(h) 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F 0FF00100 FF 7F FF FF 21 00 FF FF FF FF FF FF FF FF FF FF ÿ.ÿÿ!.ÿÿÿÿÿÿÿÿÿÿ |
Offset(h) 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F 0FF00300 FF FF FF FF 11 00 FF FF FF FF FF FF FF FF FF FF ÿÿÿÿ..ÿÿÿÿÿÿÿÿÿÿ |
Offset(h) 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F 0FF00300 FF FF FF FF 01 00 FF FF FF FF FF FF FF FF FF FF ÿÿÿÿ..ÿÿÿÿÿÿÿÿÿÿ |
Offset(h) 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F 0FF00300 FF 7F FF FF 11 00 FF FF FF FF FF FF FF FF FF FF ÿ.ÿÿ..ÿÿÿÿÿÿÿÿÿÿ |
Offset(h) 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F 0FF00300 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ |
[EOF]
Encrypted Files on Flash
Encrypted files on flash appear to have some sort of header
metldr examples
Here are samples of metldr header from 2 different consoles
00000840 00 00 0E 8E 99 87 3B C7 15 F2 80 80 9C 30 22 25 ...Ž™‡;Ç.ò€€œ0"% 00000850 00 00 0E 8E 78 A5 61 E0 17 72 6E F7 A7 1B 41 AB ...Žx¥aà.rn÷§.A«
00000840 00 00 0E 8E 99 87 3B C7 15 F2 80 80 9C 30 22 25 ...Ž™‡;Ç.ò€€œ0"% 00000850 00 00 0E 8E 81 2E 00 A9 59 75 01 CC C1 72 D5 50 ...Ž...©Yu.ÌÁrÕP
bootldr examples
Here are samples of bootldr header from 2 different consoles
00FC0000 00 00 2F 4B 53 92 1C E7 F7 33 41 76 9B 7A 1E D6 ../KS’.ç÷3Av›z.Ö 00FC0010 00 00 2F 4B 78 A5 61 E0 17 72 6E F7 A7 1B 41 AB ../Kx¥aà.rn÷§.A«
00FC0000 00 00 2F 4B CB 9E 15 24 28 B4 4F D2 F9 3F BC 43 ../KËž.$(´OÒù?¼C 00FC0010 00 00 2F 4B 81 2E 00 A9 59 75 01 CC C1 72 D5 50 ../K...©Yu.ÌÁrÕP
Observations / Notes
As you can see, some parts appear static depending on their purpose:
metldr
00000840 00 00 0E 8E 99 87 3B C7 15 F2 80 80 9C 30 22 25 ...Ž™‡;Ç.ò€€œ0"% 00000850 00 00 0E 8E xx xx xx xx xx xx xx xx xx xx xx xx ...Žx...........
bootldr
00FC0000 00 00 2F 4B xx xx xx xx xx xx xx xx xx xx xx xx ../K............ 00FC0010 00 00 2F 4B xx xx xx xx xx xx xx xx xx xx xx xx ../K............
per console in both samples
00000840 xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx ................ 00000850 xx xx xx xx 81 2E 00 A9 59 75 01 CC C1 72 D5 50 .......©Yu.ÌÁrÕP
The first 4 bytes appear to reffer to length. eg:
metldr length: 0xE920 0x00000E8E * 0x10 = 0xE8E0 + 0x40 = 0xE920 bootldr length: 0x2F4F0 0x00002F4B * 0x10 = 0x2F4B0 + 0x40 = 0x2F4F0
Header shown is 0x20 bytes, perhaps this means there is a 0x40 byte header. I was not able to find any correlation of the other 2x12 bytes here, perhaps these are keys of some sort.
new metldr.2
Seen on CECH2504B (JSD-001), with 3.60 from factory - datecode 1B
Offset(h) 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F 00000810 00 00 00 00 00 00 00 40 00 00 00 00 00 00 F9 20 .......@......ù 00000820 6D 65 74 6C 64 72 2E 32 00 00 00 00 00 00 00 00 metldr.2........ 00000830 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
other new metldr
It seems the naming "metldr.2" does not apply to all non downgradeable consoles:
Seen on CECH2504A (JTP-001), with 3.60 from factory - datecode 1B
Offset(h) 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F 00000810 00 00 00 00 00 00 00 40 00 00 00 00 00 00 E9 60 .......@......é` 00000820 6D 65 74 6C 64 72 00 00 00 00 00 00 00 00 00 00 metldr.......... 00000830 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
Seen on CECH2503B (JTP-001), with ?.?? from factory - datecode 1A (dump contained ROS with 3.66 and 3.70) This was downgradable.. sorry, the downgrade.bin was not written correctly.. but this time i wrote it ok, so this was not a new metldr console..
Offset(h) 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F 00000810 00 00 00 00 00 00 00 40 00 00 00 00 00 00 E9 60 .......@......é` 00000820 6D 65 74 6C 64 72 00 00 00 00 00 00 00 00 00 00 metldr.......... 00000830 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
For comparison, a CECH250.B (JSD-001), with factory 3.56 - datecode 1A which was downgradeable (dump contained ROS with 3.56 and 3.70 before downgrading to 3.55):
Offset(h) 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F 00000800 00 00 00 01 00 00 00 01 00 00 00 00 00 02 E8 00 ..............è. 00000810 00 00 00 00 00 00 00 40 00 00 00 00 00 00 E9 60 .......@......é` 00000820 6D 65 74 6C 64 72 00 00 00 00 00 00 00 00 00 00 metldr.......... 00000830 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00000840 00 00 0E 92 C3 26 6E 4B BB 28 2E 76 B7 67 70 95 ...’Ã&nK»(.v·gp•
other new metldr mention : https://twitter.com/#!/Mathieulh/status/110779471199604736
WTF 3.50+ consoles have a new additional root key of 0x30 bytes (3 times the same 0x10 bytes chunk) copied by metldr right to offset 0 O_O
CECH2501B JSD-001 (320GB HDD)without datecode fw 3.66
metldr contains other new value (E9 60), but still downgrades..
Offset(h) 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F 00000800 00 00 00 01 00 00 00 01 00 00 00 00 00 02 E8 00 ..............è. 00000810 00 00 00 00 00 00 00 40 00 00 00 00 00 00 E9 60 .......@......é` 00000820 6D 65 74 6C 64 72 00 00 00 00 00 00 00 00 00 00 metldr.......... 00000830 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00000840 00 00 0E 92 C3 26 6E 4B BB 28 2E 76 B7 67 70 95 ...’Ã&nK»(.v·gp•
another PS3 with CECH2501A wihtout datecode 320 GB HDD and fw 3.66 also contains other new metldr values but still downgrades...
Offset(h) 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F 00000800 00 00 00 01 00 00 00 01 00 00 00 00 00 02 E8 00 ..............è. 00000810 00 00 00 00 00 00 00 40 00 00 00 00 00 00 E9 60 .......@......é` 00000820 6D 65 74 6C 64 72 00 00 00 00 00 00 00 00 00 00 metldr.......... 00000830 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00000840 00 00 0E 92 C3 26 6E 4B BB 28 2E 76 B7 67 70 95 ...’Ã&nK»(.v·gp•
Dumping your flash
There are many ways you can dump your flash you can choose the way that best fits you, there are some persons studing the flash.. If you can help providing a dump (specially if you have a debug console) search for those persons in IRC Efnet #ps3dev
Payload
Uncomment dump_dev_flash() in graf_payloads compile and run the payload
see Graf's_PSGroove_Payload for more info
Linux
Using graf_chokolo kernel with /dev/ps3nflasha access
dd if=/dev/ps3nflasha of=NOR.BIN bs=1024
Hardware
Dump NAND/NOR from GameOS
precompiled : dump_flash.pkg // backup/mirror: dump_flash.pkg (70.48 KB)
source: dump_flash-src.rar (2.33 KB)
Make sure USB stick is FAT32 with enough free space (16MB per NOR dump, 256MB per NAND dump)
remark: NAND dumps are 239MB because HV masks bootldr, see Hardware flashing #Difference between hardware dumps and software dumps
NOR Unpacking // NOR Unpkg
/* # ../norunpkg norflash.bin norflash unpacking asecure_loader (size: 190xxx bytes)... unpacking eEID (size: 65536 bytes)... unpacking cISD (size: 2048 bytes)... unpacking cCSD (size: 2048 bytes)... unpacking trvk_prg0 (size: 131072 bytes)... unpacking trvk_prg1 (size: 131072 bytes)... unpacking trvk_pkg0 (size: 131072 bytes)... unpacking trvk_pkg1 (size: 131072 bytes)... unpacking ros0 (size: 7340032 bytes)... unpacking ros1 (size: 7340032 bytes)... unpacking cvtrm (size: 262144 bytes)... */ // Copyright 2010 Sven Peter // Licensed under the terms of the GNU GPL, version 2 // http://www.gnu.org/licenses/old-licenses/gpl-2.0.txt // nor modifications by rms. #include "tools.h" #include "types.h" #include <stdio.h> #include <string.h> #include <stdlib.h> #include <unistd.h> #include <sys/stat.h> #ifdef WIN32 #define MKDIR(x,y) mkdir(x) #else #define MKDIR(x,y) mkdir(x,y) #endif u8 *pkg = NULL; static void unpack_file(u32 i) { u8 *ptr; u8 name[33]; u64 offset; u64 size; ptr = pkg + 0x10 + 0x30 * i; offset = be64(ptr + 0x00); size = be64(ptr + 0x08); memset(name, 0, sizeof name); strncpy((char *)name, (char *)(ptr + 0x10), 0x20); printf("unpacking %s (size: %d bytes)...\n", name, size); memcpy_to_file((char *)name, pkg + offset, size); } static void unpack_pkg(void) { u32 n_files; u64 size; u32 i; n_files = be32(pkg + 4); size = be64(pkg + 8); for (i = 0; i < n_files; i++) unpack_file(i); } int main(int argc, char *argv[]) { if (argc != 3) fail("usage: norunpkg filename.nor target"); pkg = mmap_file(argv[1]); /* kludge for header, i do not do sanity checks at the moment */ pkg += 1024; MKDIR(argv[2], 0777); if (chdir(argv[2]) != 0) fail("chdir"); unpack_pkg(); return 0; }
Source: http://rms.grafchokolo.com/?p=25
RMS - eEID splitter
#include <stdio.h> #include <stdlib.h> #include <string.h> void DumpEidData (FILE * pFile, int iInputSize, int iEidCount, char *pFilenamePrefix) { FILE *pOutput; char *szFilename; char *szBuf; int iRes, iSize; printf ("dumping EID%d from eEID at %p, size %d (%x)..\n", iEidCount, pFile, iInputSize, iInputSize); szBuf = (char *) malloc (iInputSize + 1); szFilename = (char *) malloc (strlen (pFilenamePrefix) + 2); if (szBuf == NULL) { perror ("malloc"); exit (1); }; iSize = fread (szBuf, iInputSize, 1, pFile); sprintf (szFilename, "%s%d", pFilenamePrefix, iEidCount); pOutput = fopen (szFilename, "wb"); iRes = fwrite (szBuf, iInputSize, 1, pOutput); if (iRes != iSize) { perror ("fwrite"); exit (1); }; free (szBuf); } int main (int argc, char **argv) { FILE *pFile; char *pPrefix; pFile = fopen (argv[1], "rb"); if (pFile == NULL) { usage: printf ("usage: %s <eEID> <EID name prefix>\n", argv[0]); exit (1); } if (argc == 2 && argv[2] != NULL) { pPrefix = argv[2]; goto usage; } fseek (pFile, 0x70, SEEK_SET); if (pPrefix != NULL) { DumpEidData (pFile, 2144, 0, pPrefix); DumpEidData (pFile, 672, 1, pPrefix); DumpEidData (pFile, 1840, 2, pPrefix); DumpEidData (pFile, 256, 3, pPrefix); DumpEidData (pFile, 48, 4, pPrefix); DumpEidData (pFile, 2560, 5, pPrefix); } return 0; }
Source: http://rms.grafchokolo.com/?p=59
Flash Samples
Reference flash dumps
- 3.55 kmeaw, 2.80 backup: http://www.megaupload.com/?d=J5UKO3HX
- 3.66 ofw: http://www.mediafire.com/?m7m4mppro66zib5
User flashdumps
Here are some samples of NOR Flash for your dissection. These are taken from different consoles (because it is useless to dump different firmware versions as ROS/RVK will be the same crossconsole)
SKU | bootldr | metldr | ROS0 | ROS1 | Link | Note |
---|---|---|---|---|---|---|
PS3 Phat: | ||||||
CECHA | ||||||
CECHB | ||||||
CECHC | ||||||
CECHE | ||||||
CECHG | ||||||
CECHH | ||||||
CECHJ | ||||||
CECHK | ||||||
CECHL | [1] | 3.55-Rogero CECHL03 | ||||
CECHL | [2] | 3.56 CECHL03 | ||||
CECHL | [3] | 3.70 CECHL03 | ||||
CECHM | ||||||
CECHP | ||||||
CECHQ | ||||||
PS3 Slim: | ||||||
CECH-20xx | 3.65 | 3.55 | [4] | 3.65 CECH-2008 A | ||
CECH-20xx | 3.56 | 3.56 | [5] | 3.56 CECH-2008 B | ||
CECH-20xx | 3.42 | 3.70 | [6] | 3.70 CECH-2008 B | ||
CECH-20xx | 3.72 | 4.00 | [7] | 4.00 CECH-2008 B | ||
CECH-21xx | ||||||
CECH-25xx | 3.66 | 3.56 | [8] | 3.60 CECH-2508 B | ||
CECH-25xx | 3.66 | 3.72 | [9] | 3.72 CECH-2508 B | ||
CECH-30xx |