Syscon Firmware: Difference between revisions

From PS3 Developer wiki
Jump to navigation Jump to search
Line 240: Line 240:
* 7D C6 3B 3B 69 DF 67 4C 94 D7 D4 A8 E0 F8 5B B2 (section 4/body from DIA-001 patch content/tophalf/forward)
* 7D C6 3B 3B 69 DF 67 4C 94 D7 D4 A8 E0 F8 5B B2 (section 4/body from DIA-001 patch content/tophalf/forward)
* 49 1F 7B 0A 48 BD 79 33 4E 16 89 F6 B0 25 86 48 (section 4/body from DEB-001 patch content/tophalf/forward)
* 49 1F 7B 0A 48 BD 79 33 4E 16 89 F6 B0 25 86 48 (section 4/body from DEB-001 patch content/tophalf/forward)
* 14 4D F1 D3 21 B6 17 46 A9 81 42 E5 02 C9 07 66 (section 4/body from DEB-001 patch content/bottomhalf/inverse)
* 14 4D F1 D3 21 B6 17 46 60 81 42 E5 02 C9 07 66 (section 4/body from DEB-001 patch content/bottomhalf/inverse/PROPER)
* 1st, 5th, 9th and 13th bytes are considered "weak" bytes and should be bruteforced in the eventuality these keys fail
* 1st, 5th, 9th and 13th bytes are considered "weak" bytes and should be bruteforced in the eventuality these keys fail
* another possibility is that both the header and the body are hashed and then decrypted, using for example, cmac and cbc
* another possibility is that both the header and the body are hashed and then decrypted, using for example, cmac and cbc

Revision as of 15:28, 5 August 2019

Syscon Firmware is the firmware stored on the System Controller EEPROM (see Syscon Hardware). Updates are stored in update packages within the Update_files.tar of a Playstation Update Package (PUP). Syscon Packages appear to always be 5KB (5376 bytes) in size.


Syscon update packages

d/l: syscon_fw1.00-4.00.rar (51.74 KB)

Package structure

Sys_con_firmware Packages can be unpacked with unpkg

Overview

Address Length Value Description
0x00 0x4 ASCI:"SCE" SCE magic header
0x04 0x4 0x2 Flags
0x08 0x4 0x3 Type (0x3 = PKG)
0x0C 0x4 0x0 Blank/Unknown
0x10 0x4 0x0 Blank/Unknown
0x10 0x8 0x280 Start Data Offset ('hdr_len')
0x18 0x8 0x1080 Data Size ('dec_size')
0x20 0x260 - Header
0x280 0x40 - 'info0' section (see below)
0x2C0 0x40 - 'info1' section (see below)
0x300 0x1000 - 'content'

'info0'

Address Length Value Description
0x00 0x4 0x3
0x04 0x4 0x8
0x08 0x8 - SC firmware revision (the high word of it is the SC type)
0x0C 0x4 0x0B8E
0x0C16
0x0D52
0x0DBF
0x0E69
0x0F29
0x0F38
0x065D
0x0832
0x08A0
0x08C2
0x0918		 'SoftID'
0x10 0x8 0x0001000000000004
0x0001000000000005
0x0001000000000006
0x0001000100030002
0x0001000100030003
0x0001000200030002
0x0001000300030002
0x0001000400040002
0x0001000500000002
0x0001000500010001
0x00010002083E0832
 'PatchID'
0x18 0x8 0x1000 'Content' Data Size
0x20 0x8 0x1000 'Content' Compressed Data Size
0x28 0x8 0x0
0x30 0x10 0x0

Note: PS3 firmwares cannot deal with compressed syscon firmwares, so they will abort the update process in that case.

'info1'

Address Length Value Description
0x00 0x4 0x0
0x04 0x4 0x3
0x08 0x8 0x40 Offset/size?
0x10 0x4 0x0
0x14 0x4 0x0
0x18 0x8 0x1000 'Content' Data Size?
0x20 0x8 0x1
0x28 0x8 0x1
0x30 0x10 0x0

'content' overview

Address Length Value Description
0x0 0x1000 - 'content'

Known Retail syscon update packages

These are in full Retail/CEX and Debug/DEX firmwares:

Board Syscon Hardware sys_con_firmware package 1.00-1.30 1.30-1.80 1.81-2.80 3.00-3.30 3.40 3.41-4.75 SoftID Notes
COK-001 CXR713120-201GB SYS_CON_FIRMWARE_01000004.pkg No Yes No No No No 0B8E Superseded by SYS_CON_FIRMWARE_01000005.pkg
SYS_CON_FIRMWARE_01000005.pkg No No Yes Yes No No 0B8E Superseded by SYS_CON_FIRMWARE_01000006.pkg
SYS_CON_FIRMWARE_01000006.pkg No No No No Yes Yes 0B8E
COK-002 CXR713120-201GB
CXR713120-202GB 		SYS_CON_FIRMWARE_01010302.pkg No No Yes Yes No No 0C16 Superseded by SYS_CON_FIRMWARE_01010303.pkg
SYS_CON_FIRMWARE_01010303.pkg No No No No Yes Yes 0C16
SEM-001 CXR713120-201GB
CXR713120-202GB
CXR713120-203GB 		SYS_CON_FIRMWARE_01020302.pkg No No No No Yes Yes 0D52
DIA-001 CXR714120-301GB SYS_CON_FIRMWARE_01030302.pkg No No No No Yes Yes 0DBF
DIA-002 / DEB-001 CXR714120-301GB
CXR714120-302GB 		SYS_CON_FIRMWARE_01040402.pkg No No No No Yes Yes 0E69
??? ??? SYS_CON_FIRMWARE_01050002.pkg No No No No Yes Yes 0F29 CXR714120-X0XGB / SW-30x Prototype
??? ??? SYS_CON_FIRMWARE_01050101.pkg No No No No No Yes 0F38
VER-001 SW-30x No No No No No No 065D
DYN-001 SW2-30x SYS_CON_FIRMWARE_S1_00010002083E0832.pkg No No No Yes Yes Yes 0832 ps3 2k series
SUR-001 No No No No No No 08A0
JTP-001
JSD-001 		No No No No No No 08C2 ps3 2k5 series
KTE-001 No No No No No No 0918 ps3 3k series
MSX-001
MPX-001		 SW3-30x No No No No No No 098F ps3 4k series

This means from syscon perspective notible firmware changes where made at 1.30, 1.81, 3.00, 3.40 and 3.41 that affected retail and debug PS3 models

  • Firmware 1.30 (December 6, 2006) added Backup/Restore
  • Firmware 1.81 (June 15, 2007) ?
  • Firmware 3.00 (September 1, 2009) resulted in Class action suit for BluRay reading problems
  • Firmware 3.40 (June 29, 2010) ?
  • Firmware 3.41 (July 26, 2010) ?

NonRetail syscon

Remember, Debug/DEX consoles are normal retail consoles with different TargetID, so only those that have a nonretail board have deviating patches (like the CXR713F120A found on the DECR-1000A TOOL/DECR).

Tool/DECR don't have patches, they flash entire firmwares.

Factory cp comes with 0.8.8 (corresponds to syscon fw size 0x60000)
it is VERY likely that it is not possible to go below this point, so any smaller size would likely cause a brick (see Talk:Communication_Processor for more info on how to downgrade)

DECR samples: [1] mirror:
v0.6.1c8_TMU510_u.bin  | CRC16:FAE0 | CRC32:590D9A21 | SHA1:DC8AEA0DDC6C5B813FE9861C972AAE111DA6FCAB | MD5:50794942BD9FAB7CC04A81BD8D220BA1 | 7379733103B15C07EC051E9B44D90BDF 07AD575D86B3937CFA8B3D331BE958DDB40EDFBE
v0.6.10c4_TMU510_u.bin | CRC16:B58A | CRC32:DB8A00BF | SHA1:5D52289960151E2543EBEAA805963B7B88C35DD8 | MD5:14C288A576690C587E95C8542EDC2A70 | 7379733160AF70F9CF5DF54F30D5C77C 5F360CD146EEC3A7B5026151C396C4A5F7F1EC91
v0.6.11c4_TMU510_u.bin | CRC16:8A51 | CRC32:289B15F3 | SHA1:D45214E907A104BCC6BC91D78B7B471263AB0699 | MD5:B7CFA6536329F0DFF1AAD7905627F15F | 73797331F283602B666562012850612E 3FABA6E4FE1D70724164A23886199F36A02EDB0D
v0.6.12c5_TMU510_u.bin | CRC16:31B2 | CRC32:1A1F141B | SHA1:403BF55314C4E785ED90D03A8F2E90B67CC235EA | MD5:1B19B55924445E4BBB2D970410AD6366 | 737973316E5C037615E4727464B2D929 2D2EB7DADEF6B24C4E959235E5B11917D352F9D5
v0.6.14c4_TMU510_u.bin | CRC16:FB1B | CRC32:079EF389 | SHA1:6EF7067FAD939D0B0DFC0B9418A6F4C7509104E5 | MD5:11E9F6270A5D79D0B76614B1C6FE622B | 73797331DCEAC9FA0F1B2449F332C4A9 1CBFF6FE43BDCA3B0A5AAFCE9A98D7176D951A49
v0.8.4c8_TMU510_u.bin  | CRC16:2949 | CRC32:81EFA508 | SHA1:5963B333361123782848E3639D9FA585A728691A | MD5:564D5479F5B98E244C1EA7B56BACC873 | 73797331E8A9ADD15036B33AB8E8AB17 FDCC981DA58B9F44E9331C9708C01D924D78DB3E
v0.9.9c1_TMU510_u.bin  | CRC16:172A | CRC32:EBB2D78A | SHA1:D5E693D2E22FD99CF3E330AC442CD9B07D01DB66 | MD5:216B258115F25B13C9969AF35BFCAC20 | 7379733116E6DD5F054442FACFA15A5C 5E62E8FC8059F864A91CAD142BC30BDAE77D9464
v0.9.14c1_TMU510_u.bin | CRC16:2A2C | CRC32:330CB685 | SHA1:30B19BB8B78E60D81848E8FDF6C4A79537CFBE66 | MD5:7AA5BFE64D15F8BD61EB80B999FE4343 | 73797331807BAF3D6E1B6A3CA5FDF30D 7CCE3B0E739A19C9C431D4D8C59CF1513DAF25E9
v1.0.1c1_TMU510_u.bin  | CRC16:3FD1 | CRC32:A7C7E313 | SHA1:F0DCA7130074E023FFAF58EBD06A61EE73C94907 | MD5:C95C57DC20D9AC5473C1EC914744352F | 73797331F362AE579EA3D864E27334CC 3EAB05DEC5328E885EED3295954999BD518ABFDF
v1.0.3c1_TMU510_u.bin  | CRC16:636E | CRC32:32942DFD | SHA1:83BE56F92A93B911D2BBE12DD1F6AF9CCD1EC11B | MD5:642C0E6615AACBF180C367F7927D1E30 | 737973312D08051E9F5AA1AAF2647EC0 44EE5DF74D92DDB81B1099430B0B5A243FFDA44E
v1.0.4c1_TMU510_u.bin  | CRC16:528F | CRC32:A0FBA694 | SHA1:1A5E5F97D66A754C2C7436618DC911C1C57B9FEA | MD5:6641B03FC6193E35380D681152226275 | 73797331E40325B060CDE461D250058D 8AF478F0A1C1B4B9DECA01C8770F8A9010F0A513
v1.0.5c1_TMU510_u.bin  | CRC16:59F8 | CRC32:87316EBF | SHA1:8ED74829973F740C1B825FD976F7926A95ACBE8B | MD5:717DC4187A6E446C30DACAC129090656 | 737973316856FC96CA6FA4D4652D4985 F9E998439D4C23DA9C1BA8F5C44611D826DA1CFE

dev/hda

dev_hda.image from DECR-1000A CP: dev_hda.image dev_hda.image.7z

Partitions

device file size type
/dev/loop0p1 51 MB (50577408 bytes) 0x89
/dev/loop0p2 8,7 MB (8650752 bytes) Linux
/dev/loop0p3 32 MB (31981568 bytes) Linux
/dev/loop0p4 35 MB (35127296 bytes) Extended
/dev/loop0 4,9 MB (4883968 bytes) Unassigned

Deviating from Retail

Please note that without info about the SKU the listing of ID's is pretty useless

sys_con_firmware package 1.00-1.30 1.30-1.80 1.81-2.80 3.00-3.30 3.40 3.41-4.11 SoftID Notes
? No No No No No No 0B67 Debug/DEX

Usage

The firmware PUP's contains a collection of patches for all the different hardware revisions of syscon's chips used in different motherboard models.

The ps3swu.self (system updater) decides which applicable Syscon Hardware is present and installs the needed package update(s) accordingly (via updater manager ss service).

Which syscon version and which patches are installed can be seen in More_System_Information

Decryption

Packages can be decrypted with the unpkg tool. Decrypted content of the updates appears to always be 0x1000 bytes (4KB).

Patch/Firmware Body Decryption/Hashing

The following is all theoretical and is intended to discard possibilities about modes of operation used by aes when decrypting body of firmware/patch

We know that:

  • Two key expansions are used before applying crypto on body (could the cipher use two keys? or compiler quirk?or failed implementation?)
  • Encrypt is used when applying crypto on body (forward sbox/ttables?)
  • Authenticated regions uses a form of what seems to be some ECB with tweak xoring (as graf once said about XTS)
  • XTS was introduced in 2007 and SysCon from ps3 exists for far more time than that (2003)
  • XEX is a close relative of XTS that was introduced in 1984
  • PS4 uses XTS for Authenticated Regions or SNVS (with sector size of 0x20 being used. is this even considered safe?)
  • XTS and XEX both use two keys (data and tweak) which would explain to a degree the key expansions
  • 3 regions can be controlled for DPA and they are: 0x2790 (size 0x20) (FFs), patch header (most notably at offset 0x4 of header size 0x10 and 0x30 size 0x10) and patch body
  • here are the DPA bytes for each of the controlable sections:
  • 21 06 23 DC A2 98 99 4D F5 87 F8 40 FC 48 1C BF (section 2/FF's from 0x2790 on DIA-001)
  • 21 06 23 DC A2 98 99 4D FE 87 F8 40 FC 48 1C BF (section 2/FF's from 0x2790 on DEB-001)
  • 16 32 47 79 C3 2C 47 D3 2B 39 CA B5 83 41 0E D5 (section 3/header from DIA-001 patch content)
  • 7B FC 27 CD D5 9A 05 09 3A DF E4 75 BF FD 03 1A (section 3/header from DEB-001 patch content)
  • 7D C6 3B 3B 69 DF 67 4C 94 D7 D4 A8 E0 F8 5B B2 (section 4/body from DIA-001 patch content/tophalf/forward)
  • 49 1F 7B 0A 48 BD 79 33 4E 16 89 F6 B0 25 86 48 (section 4/body from DEB-001 patch content/tophalf/forward)
  • 14 4D F1 D3 21 B6 17 46 60 81 42 E5 02 C9 07 66 (section 4/body from DEB-001 patch content/bottomhalf/inverse/PROPER)
  • 1st, 5th, 9th and 13th bytes are considered "weak" bytes and should be bruteforced in the eventuality these keys fail
  • another possibility is that both the header and the body are hashed and then decrypted, using for example, cmac and cbc
  • since key expansions take 10 "hills" in the analysis, it should be safe to assume that AES-128 is used(because it uses 10 rounds).
  • 6554cff202c3bfdd9740901070b705bf : correct md5 for patch content we are trying keys on (DIA-001)
  • 4875ad06a1499cc516a0d4d92e595794 : correct md5 for patch content we are trying keys on (DEB-001)
  • trying a different header/body patch content from another similar board will result into failure of decrypting body, which means that the header is checked for authenticity and that the header hash is NOT in the header
  • altering the patch header doesn't cause the patch header dpa bytes to change (a test was done with 4 bytes and the result was 16 32 47 79, which matches the other patch dpa recovered bytes)
  • there are in fact not 4 but 5 aes sections. the last one seems to be body related, as changing the body even one bit makes the last aes section disappear.
  • section 2 is divided into two sections, corresponding to TopHalf and BottomHalf of patch area.
  • TopHalf uses forward ttables/sbox. BottomHalf uses inverse ttables/sbox
  • TopHalf is ONLY the very first 0x10 bytes AFTER the header and into the body (corresponding to 0x40 in header size 0x10)
  • BottomHalf is the rest of the body itself.

Header

The header format is partially unknown at this stage. All the Firmwares patches are written in little endian.

Offset Length Notes Related DECR Error
0x0 0x4 Magic FFFFFED2 (Magic Error)
0x4 0x20 ?Hash/MAC of (decrypted) binary? FFFFFED1 (Header Check Error)
0x24 0x4 Padding FFFFFED1 (Header Check Error)
0x28 0x4 Total size FFFFFED1 (Header Check Error)
0x2c 0x4 Size of binary FFFFFED1 (Header Check Error)
0x30 0x10 IV for AES-128 CBC FFFFFED1 (Header Check Error)
0x40 0xfc0 Encrypted binary FFFFFED0 (Data Check Error) / FFFFFECF (Data Size Check Error)
  • Note: For the weird bogus update ONLY: FFFFFF37 (Alignment Error?) (Trying any data size between 0x41 and 0x4C bytes)
  • Note2: v0.6.14c4 is the bogus update (only update with a weird header)
  • Note3: setting data between 0x40 to 0x4C to zero in bogus update yields error FFFFFED0

Samples

00000000  1B 2D 70 0F AB 5E B3 99 68 20 FE 3D E1 80 6A 1D  .-p.«^³™h þ=á€j.
00000010  B8 FD 37 CF CD 45 85 AB 51 F7 05 E3 EA 32 A5 EA  ¸ý7ÏÍE…«Q÷.ãê2¥ê
00000020  67 45 F9 48 00 00 00 00 00 10 00 00 C0 0F 00 00  gEùH........À...
00000030  8B 04 07 F9 9B A2 90 3A 75 89 F1 42 12 59 DA 0D  ‹..ù›¢.:u‰ñB.YÚ.
00000040  21 7C A2 C3 5A E4 78 00 10 8D 4B F7 A2 73 9C 63  !|¢ÃZäx...K÷¢sœc
00000050  5D 8D 5D 49 16 C7 6F 2C AD 33 FE 1F D3 6C A1 CA  ].]I.Ço,.3þ.Ól¡Ê
00000060  BA AD 2B FE 8F 33 71 D7 C5 E6 5C FF BF 77 6C 80  º.+þ.3q×Åæ\ÿ¿wl€
00000070  F2 BE 11 BB 3C 52 52 DC A9 68 E5 24 AD 4F F3 48  ò¾.»<RRÜ©hå$.OóH

-From v1.0.4c2_TMU510_u- 

00000000   73 79 73 31 73 47 59 5D  FB 85 3B 7B 4A 28 10 5D   sys1sGY]û…;{J( ]
00000010   46 EE 8C 01 3C B4 F1 82  1E 18 4F B7 4A 56 FC C7   FîŒ <´ñ‚  O·JVüÇ
00000020   FF 83 0B E0 00 00 00 00  40 00 06 00 00 00 06 00   ÿƒ à    @       
00000030   69 B6 02 69 3A 97 8B 1C  4E 18 D4 E0 63 7D CA 94   i¶ i:—‹ N Ôàc}Ê”
00000040   4B A0 79 34 79 41 BD 09  BB 68 D4 0A A0 B7 05 78   K y4yA½ »hÔ  · x
00000050   D9 8F 8F 28 6C 9A 1B 61  CF A1 E7 49 7D CA C4 A3   Ù  (lš aÏ¡çI}ÊÄ£
00000060   A4 4D 4B E0 AE 48 86 03  B1 43 F2 47 C0 C4 1D 4F   ¤MKà®H† ±CòGÀÄ O
00000070   FA E8 43 A7 1E 6E 79 8C  E5 FF 04 20 E9 44 09 B5   úèC§ nyŒåÿ  éD µ

Observations

  • The first 4 bytes (0x1B2D700F) appear static in each package.
  • The next 0x20 bytes appear to change with each package
  • The following 12 bytes (0x0000000000100000C00F0000) also appear static, but it's the firmware size and fw size - header size; infact if correctly converted to little endian 00000000 00001000 00000fc0, where 00000000 is Unknown, 00001000 is 4096 in dec (file size) and 00000fc0 is 4032 in dec (update size).
  • On the DECH fw, the update works in the same way: 000000004000060000000600 converted will be: 00000000 00060040 00060000, where, 00000000 is probably padding, file size 00060040, 00060000 update size
  • the first 0x40 bytes probably are IV + HASH + update infos. probably the algorithm used is AES.

Access to Syscon from Linux

Access SysCon ROM without needing ps3dm-utils: http://wiki.gitbrew.org/wikibrew/PS3:HvReverseEngineering#SYSCON


PS3UPDAT.PUP
Other Entries
Modifications
Tools
CFW Releases
Retrieved from "http://www.psdevwiki.com/ps3/index.php?title=Syscon_Firmware&oldid=54108"