SLB2

Structure

PS4 SLB PUP container format - SKFU

/* SLB2 structure is little endian */
 
struct SceSlb2Entry {
	uint32_t fileStartSector;
	uint32_t fileSizeInByte;
	uint32_t reserved[2]; // padding for alignment
	char     fileName[32];
} __attribute__((packed));
 
struct SceSlb2Header {
	uint32_t magic; // "SLB2"
	uint32_t version; // ex: 1
	uint32_t flags; // ex: 0
	uint32_t entryNum;
	uint32_t sizeInSector;
	uint32_t reserved[3]; // padding for alignment
	struct SceSlb2Entry entryList[0];
} __attribute__((packed));

Unpacking

• pupunpack.py (flatz)
• PS4 PUP Extractor v2 (xerpi)
• PS4 FW Tool v1.0.0 (skfu)
• ps4tools (hykem, based on flatz)
• ps4tools (harlequin, based on flatz and zecoxao)
• ps4tools (nikosradio, based on flatz)
• ps4tools (Keyaku, based on flatz)
• PS4-PUP-Tool (Jakes625)
• PS4_AC1D_Flash-Tool (cfwprpht)
• SLB2 library (cfwprpht)
• blsunpack (zecoxao)
• slb2tools (yifan lu)

Usage

SLB2 files are parsed by many executables:

• PS4 Southbridge EMC IPL to extract C0028001 (EMC IPL) and C0020001 (EMC IPL information) from sflash0s0x32b (inactive partition).

Other notes

It looks like newer (confirmed for OFW 7.55 and above) SLB2 files have some data between 0x200 and 0x270 which doesn't affect any unpacking tool but affects the unpacking on the PS4. The file gets recognised as corrupted if that data isn't there. This data is present in the `recovery` images but not in the `update` images. -Other note Newer updates seems to have New data exactly before the start of the PS4UPDATE.PUP file It has the same effect as the one between 0x200 and 0x270