ISO.BIN.EDAT

ISO.BIN.EDAT

This is an encryted container format, first step to work with it is to decrypt it
After decryption we shoould refer to it as ISO.BIN.DAT (without the "E"... so the EDAT became a DAT)

ISO.BIN.DAT (decrypted)

This can be considered an intermediate container composed by the ISO.BIN + a 40 bytes signature at bottom
For the purpose of this wiki page and the concept of extracting data from layers like an onion we need to delete the last 40 bytes to convert a ISO.BIN.DAT into a ISO.BIN
The signature is intended as a sanity check to the ISO.BIN data. In other words if you are going to modify the ISO.BIN you will need to generate a new signature for it when rebuilding it
Example source-code to generate the 40 byte signature can be found in sign3.py which is part of pop-fe.

ISO.BIN structure

All offsets are in little endian (except in the last table where there are two counters in decimal)

1 block = 1024 bytes (0x400)
1 cluster = 16 blocks = 1024*16 bytes =16384 bytes (0x4000)

disc_starts ----------> 0x000400 (disc1), 0x100400 (disc2), 0x200400 (disc3), 0x300400 (disc4), etc...
disc_tocs -----------> 0x000C00 (disc1), 0x100C00 (disc2), 0x200C00 (disc3), 0x300C00 (disc4), etc...
disc_map_tables ----> 0x004400 (disc1), 0x104400 (disc2), 0x204400 (disc3), 0x304400 (disc4), etc...

Header (optional)

1 block = 1024 bytes (0x400)

Always exists in PS1 classic multidiscs (the example below is from ff8), in the official PS1 classics single disc doesnt exists, but the custom PS1 classics single discs can use it (there are custom tools that adds it in all cases)

Block Nº	Offset	Length	Name	Example	Description
0 common_header	0x0000	0x10 (16 bytes)	magic	PSTITLEIMG000000
	0x0010	0x1F0 (496 bytes)	padding
	0x0200	0x64 (100 bytes)	discs_start_offsets	00 04 00 00	25 chunks of 4 bytes ... each chunk = start position of each disc, in games with only 1 disc only the first 4 bytes are used
	0x0264	0x10 (16 bytes)	game_id	_SLES_12345	common identifyer for all discs
	0x0274	0x18C (396 bytes)	padding

Section

64 clusters, 1024 blocks, 10485576 bytes (0x100000)

This structure is repeated one time for every disc of the game all them joined together consecutivelys (the example below is from ff8), the whole space is reserved even when there is no data used

Cluster Nº	Block Nº	Offset	Length	Name	Example	Notes
0 Disc map header	1	0x0000	0x0C (12 bytes)	magic	PSISOIMG0000	In "PSP Minis" It's NPUMDIMG (NP UMD Image) ..... probably another for "ps2 classics" (speculation)
		0x000C	0x04 (4 bytes)	isosize		Offset from the start of the PSISOIMG section to the next section For uncompressed images this is usually 0x100000 + size of iso-image padded to 0x9300 If the disc contains CD-DA tracks then this number will also include all the ATRACK encoded audio that follows after the disk image.
		0x0010	0x3F0 (1008 bytes)	padding
	2	0x0400	0x10 (16 bytes)	disc_id	_SLES_12345	in games with several discs each disc has a different id
		0x0410	0x3F0 (1008 bytes)	padding
	3	0x0800	0x3FС (1020 bytes)	disc_TOC	variable	Table of content, like CUE sheet, supports upto 99 entries (102 entries total). See Disc toc table below
		0x0BFC	0x4 (4 bytes)	disc_start_offset	0x100000
	4	0x0C00	0x400 (1024 bytes)	audio tracks table		Datas of audio tracks (2-65). offset, size, and more. See Audio tracks table below
	5	0x1000	0x220 (544 bytes)	audio tracks table		Datas of audio tracks (66-99). offset, size, and more. See Audio tracks table below
		0x1220	0xB4 (180 bytes)	game params		See Game Params Table below
		0x12D4	0x04 (4 bytes)	subchannel offset	0x100400	Offset to where subchannel data is stored. This is used with libcrypt.
		0x12D8	0x04 (4 bytes)	subchannel count	0x178	Number of subchannel blocks. Each block is 12 bytes. Content is unknown.
		0x12DC	0x124 (292 bytes)	padding
	6	0x1400	0x400 (1024 bytes)	not used
	7	0x1800	0x400 (1024 bytes)	not used
	8	0x1C00	0x400 (1024 bytes)	not used
	9	0x2000	0x400 (1024 bytes)	not used
	10	0x2400	0x400 (1024 bytes)	not used
	11	0x2800	0x400 (1024 bytes)	not used
	12	0x2C00	0x400 (1024 bytes)	not used
	13	0x3000	0x400 (1024 bytes)	not used
	14	0x3400	0x400 (1024 bytes)	not used
	15	0x3800	0x400 (1024 bytes)	not used
	16	0x3C00	0x10 (16 bytes)	checksum	1CCE0033 60C6E8A6 B36A972D 00EAFDBF	seems to be the checksum of this block, and because this block is always unused... this checksum is always the same
		0x3C10	0x3F0 (1008 bytes)	padding
1 Disc map table	17	0x4000	variable	Disc map table		divided in chunks of 32 bytes. See Disc map table table below
	Up to 32
Up to 64 Disc map table

Disc toc table

Entry structure:

Offset	Length	Name	Example	Notes
0x00	0x01 (1 byte)	TYPE	0x41/0x01	entry flags
0x01	0x01 (1 byte)	TNO	00	always zero
0x02	0x01 (1 byte)	POINT	0xA0/0xA1/0xA2/0x01/0x02/0x03/etc	increases
0x03	0x01 (1 byte)	MIN	varies	decimal
0x04	0x01 (1 byte)	SEC	varies	decimal
0x05	0x01 (1 byte)	FRAME	varies	decimal
0x06	0x01 (1 byte)	ZERO	00	always zero
0x07	0x01 (1 byte)	PMIN	varies	decimal
0x08	0x01 (1 byte)	PSEC	varies	decimal
0x09	0x01 (1 byte)	PFRAME	varies	decimal

Audio tracks table

Entry structure:

Offset	Length	Name	Example	Notes
0x00	0x04 (4 bytes)	offset
0x04	0x04 (4 bytes)	size
0x08	0x04 (4 bytes)	unknown_0		always zeroed
0x0C	0x04 (4 bytes)	and more \o/		encryption key

Game Params Table

There is a setting related with PS1 libcrypt protection in this area (located at relative absolute offset 0x12B0 for single disc or 0x16B0 in the first disc for Multidisc, lenght 0x4 little endian), see: talk

Libcrypt in emulator is supported by supplying ready 16 bit key in little endian format (0xA371 in CTR example). List of keys can be obtained using Libcrypt Magic Word Finder PSX

Disc map table

The table has an area reserved of 1032192 bytes. Divided in 32256 entries, of 32 bytes each entry. The number of used entryes in the file_table can vary (seems to be dependant of the .iso contents). The number of entries availables to store data is affected by a checksum (16 bytes) that is present only in the the last block of each cluster (in block nº16 of every cluster) When this checksum is between used entryes... his length is 32 bytes (it "steals" the area of one entry) Seems to be a checksum of this block... when the block is filled with zeroes the checksum is : 1CCE0033 60C6E8A6 B36A972D 00EAFDBF

The first 4 bytes of each entry (file offset from start of .iso root) increases for each entry in a amount of bytes determined by the previous entryes.... in other words... the second file in the .iso is displaced the number of bytes used by the first file... and the third file is displaced in a amount of bytes used by the addition of the sizes of first and second file

Entry Nº	Offset	Length	Name	Example	Notes
1	0x00	0x04 (4 bytes)	file_offset	0	file offset from start of .iso root (for the first entry is always 0)
	0x04	0x02 (2 bytes)	file_size	variable	this size determines the displacement of the next file (in the next entry)
	0x06	0x02 (2 bytes)	file_type ?	01 00	usually 1... and 0 for the last entry
	0x08	0x10 (16 bytes)	file_checksum	variable	First 16 bytes of the sha1 of the uncompressed data
	0x18	0x08 (8 bytes)	padding
Up to 32256					same structure than the previous entry

Common Disc table

Composed by a variable number of entries (depends of the number of files/folders inside the discs), 12 bytes each entry

Entry Nº	Offset	Length	Name	Example	Notes
1	0x00	0x04 (4 bytes)	file_offset ?	0	always increases
	0x04	0x02 (2 bytes)	file_type ?	01 01	always 01 01
	0x06	0x03 (3 bytes)	counter 1		some kind of counter, in decimal, always increases <-------- related with "sectors" inside the .iso ?
	0x09	0x03 (3 bytes)	counter 2		another counter, in decimal, always increases, its in relationship with the previous counter (this one is always 200 bytes bigger than the previous one)

There are 2 "special" entries to mark the "start of a disc" (FFFFFFFF 00000000 FFFFFFFF), and the "end of a disc" (FFFFFFFF FFFFFFFF FFFFFFFF). Between the start and the end, there are a variable number of entries.

There is also an added string at the end of the last disc (after the last FFFFFFFF FFFFFFFF FFFFFFFF entry)... is a 40 bytes unknown area (in my example my game had 4 discs so maybe this area is divided in chunks of 10 bytes for each disc)

So as an example... for a game with 4 discs this table is:

• first entry of disc 1 ---> FFFFFFFF 00000000 FFFFFFFF (start of disc 1)
• next entries of disc 1 --> data from disc.... the number is variable
• last entry of disc 1 ---> FFFFFFFF FFFFFFFF FFFFFFFF (end of disc 1)
• first entry of disc 2 ---> FFFFFFFF 00000000 FFFFFFFF (start of disc 2)
• next entries of disc 2 --> data from disc.... the number is variable
• last entry of disc 2 ---> FFFFFFFF FFFFFFFF FFFFFFFF (end of disc 2)
• first entry of disc 3 ---> FFFFFFFF 00000000 FFFFFFFF (start of disc 3)
• next entries of disc 3 --> data from disc.... the number is variable
• last entry of disc 3 ---> FFFFFFFF FFFFFFFF FFFFFFFF (end of disc 3)
• first entry of disc 4 ---> FFFFFFFF 00000000 FFFFFFFF (start of disc 4)
• next entries of disc 4 --> data from disc.... the number is variable
• last entry of disc 4 ---> FFFFFFFF FFFFFFFF FFFFFFFF (end of disc 4)
• unknown area of 40 bytes (10 bytes for each disc ?)

Minis ISO.BIN structure

Header

Name	Offset	Size	Example	Remark
Magic!	0x0	0x8	NPUMDIMG
unk1	0x8	0x4	N.A	(be)
Block Size	0xC	0x4	N.A	(be)
ContentID	0x10	0x24	UP4123-NPUZ00119_00-ANGRYBIRDSGAME01
Padding1	0x34	0xC	({0x0}filled)
Common1	0x40	0x4	0x00 0x08 0x00 0xE0
Padding2	0x44	0x4	({0x0}filled)
unk2	0x48	0x4	N.A	(be)
Padding3	0x4c	0x8	({0x0}filled)
LBA Start	0x54	0x4	N.A	(be)
Padding4	0x58	0x4	({0x0}filled)
unk3	0x5C	0x4	N.A	(be)
Padding5	0x60	0x4	({0x0}filled)
LBA End	0x64	0x4	N.A	(be)
unk4	0x68	0x4	N.A	(be)
Np_Table Offset	0x6C	0x4	N.A	(be)
GameID	0x70	0xA	NPUZ-00119
Common2	0x7A	0x26	N.A
Header Key	0xA0	0x10	N.A.
Padding6	0xB0	0x50	N.A({0x0} filled)

Iso Block Table (1st decrypted but compressed block)

Name	Offset	Size	Example	Remark
Block MAC	0x100	0x10	N.A
Block Offset	0x110	0x4	N.A	(be)
Block Size	0x114	0x4	N.A	(be)
Padding	0x118	0x8	00000000

Until X blocks where X is the block number

Minis MINIS.BIN structure

Header

Name	Offset	Size	Example	Remark
Magic!	0x0	0x8	NPUMDIMG
unk1(be)	0x8	0x4	N.A
Block Size(be)	0xC	0x4	N.A
ContentID	0x10	0x24	UP4123-NPUZ00119_00-ANGRYBIRDSGAME01
Padding	0x34	0x8	({0x0} filled)
Encrypted Version Key	0x40	0x10	N.A	AES-CBC Encrypted

Notes

• You can decrypt any eboot.pbp from a mini OR pspremaster OR psn paid eboot(?) with npdpc
• You can use any header on an iso.bin, and the ps3 won't even try to check it
• (be) means that the generated table values will have to be endian swapped when using npdpc (now possible thanks to arnold)
• [arnold's code]
• [kirk lib]

Decrypting owned ISO.BIN.EDATs and MINIS.EDATs

These source codes won't work without further modification!

These examples work with every EDAT type.

Decrypting with SCE SDK

#define PSP_EMULATOR_KLIC {{0x2A, 0x6A, 0xFB, 0xCF, 0x43, 0xD1, 0x57, 0x9F, 0x7D, 0x73, 0x87, 0x41, 0xA1, 0x3B, 0xD4, 0x2E}}
#define BUF_SIZE      (16*1024)
#define NP_POOL_SIZE  (128*1024)

#include <np.h>
#include <np/drm.h>
#include <stdio.h>
#include <cell/cell_fs.h>
#include <cell/sysmodule.h>

int main ()
{
uint8_t np_pool[NP_POOL_SIZE];
uint8_t read_buf[BUF_SIZE];
int ret;
int fd1,fd2;
uint64_t file_size;
uint64_t sw;
char *edata_file,*raw_file; //raw_file will be created if it does not exist
SceNpDrmKey k_licensee = PSP_EMULATOR_KLIC;

ret = cellSysmoduleLoadModule(CELL_SYSMODULE_FS);
ret = cellSysmoduleLoadModule(CELL_SYSMODULE_SYSUTIL_NP);
printf("sceNpInit()\n");
ret = sceNpInit(NP_POOL_SIZE, np_pool);

printf(" Open '%s' as NPDRM file\n", edata_file);
ret = sceNpDrmIsAvailable2(&k_licensee, edata_file);
if (ret != CELL_OK) {
	printf("EDAT not activated\n");
	return ret;
}
SceNpDrmOpenArg arg;
	arg.flag = SCE_NP_DRM_OPEN_FLAG;
	ret = cellFsOpen(edata_file, CELL_FS_O_RDONLY, &fd1, &arg, sizeof(arg));
	if (ret != CELL_FS_OK) {
		printf("Error opening for reading\n");
		return ret;
	}
printf("Opening file to dump to '%s'\n", raw_file);
	ret = cellFsOpen(raw_file, CELL_FS_O_RDWR|CELL_FS_O_CREAT, &fd2, NULL, 0);
	if (ret != CELL_FS_OK) {
		printf("Error opening file\n");
		cellFsClose(fd2);
		return ret;
	}
printf("\n[ dump edata ]\n");
	for (uint64_t r = 0; r < file_size; r += BUF_SIZE) {
		uint64_t rsize;
		uint64_t remain = file_size - r;
		if (remain > BUF_SIZE) { remain = BUF_SIZE; }

		ret = cellFsRead(fd1, read_buf, remain, &rsize);
		if (ret != CELL_OK || rsize != remain) {
			printf("Read error ('%s'): ret = 0x%08x, size = %llx, %llx\n",
					edata_file, ret, remain, rsize);
			if (ret == CELL_OK) { ret = -1; }
			cellFsClose(fd1);
			cellFsClose(fd2);
			return ret;
		}

		printf("dump data: (0x%08llx - 0x%08llx)  ", r, r + remain);
		ret = cellFsWrite(fd2, (const void *)read_buf, (size_t)remain, &sw);
		if (ret != CELL_FS_OK) {
			cellFsClose(fd1);
			cellFsClose(fd2);
			printf("ERROR\n");
			return -1;
		}
		printf("OK\n");
	}

	/* file close */
ret = cellFsClose(fd1);
ret = cellFsClose(fd2);
ret = sceNpTerm();
ret = cellSysmoduleUnloadModule(CELL_SYSMODULE_SYSUTIL_NP);
ret = cellSysmoduleUnloadModule(CELL_SYSMODULE_FS);
return ret;
}

Decrypting with PSL1GHT

• https://github.com/euss/psp_edat_decryptor (not my code, just git'ed it for convenience)
• mirrors: [1], [2], [3]

About PS2 Classics

There are some new formats present in PS2 Classics. The first one is ISO.BIN.ENC, the second one is .dxt, which is inside CONTENT folder and there's also a single file named CONFIG. You can see more about this when you first install a PS2 Classic. There's also a problem with the Data while trying to execute the instalable file. The message Unsupported Data appears on the screen when highliting the file and the error 80028F14 is shown while trying to start.
This was made with the Max Payne game. There could probably be other formats present aswell

ISO.BIN.EDAT

For PSN PS2-Classics Games ISO.BIN.EDAT only contains the Title Id of the disc. Example:

SLES-12345