Syscon Firmware

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(1.30-4.84) 0x0C16(1.81-4.84) 0x0D52 0x0DBF 0x0E69 0x0F29 0x0F38 0x065D 0x0832(4.84) 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)
• 73 XX F0 3D XX 9A F0 92 4D XX 62 DA XX 48 3C DB (section 4/body from DIA-001 patch content/bottomhalf/inverse)
• 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.
• algorithm used is aes 128 cbc on the body (iv is at + 0x30)

Access to Syscon from Linux

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