ISO.BIN.EDAT

iso.bin structure (decrypted)

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)

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

iso.bin Header

1 block = 1024 bytes (0x400)

Block Nº	Offset	Length	Name	Example	Dexcription
0 common_header	0x0000	16 bytes (0x10)	ckecksum	variable	checksum of the header block... or checksum of the whole file ?
	0x0010	496 bytes (0x1F0)	padding
	0x0200	100 bytes (0x64)	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	16 bytes (0x10)	game_id	_SLES_12345	common identifyer for all discs
	0x0274	396 bytes (0x18C)	padding

iso.bin Disc map

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

This structure is repeated one time for every disc of the game all them joined together consecutively, 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	0x0400	16 bytes (0x10)	magic	PSISOIMG0000	In "PSP Minis" It's NPUMDIMG (NP UMD Image) ..... probably another for "ps2 classics" (speculation)
		0x0410	1008 bytes (0x3F0)	padding
	2	0x0800	16 bytes (0x10)	disc_id	_SLES_12345	in games with several discs each disc has a different id
		0x0810	1008 bytes (0x3F0)	padding
	3	0x0C00	32 bytes (0x20)	disc_key ?	variable	<------------------ key to decrypt the disc1.iso ?
		0x0C20	992 bytes (0x3E0)	padding
	4	0x1000	1024 bytes (0x400)	not used
	5	0x1400	724 bytes (0x2D4)	padding
		0x16D4	2 bytes (0x02)	block size ?	1024	<--- this is wrong, but matches for the first disc
		0x16D6	2 bytes (0x02)	number of clusters	64	its always 64 clusters (so seems to be right)
		0x16D8	2 bytes (0x02)	number of blocks ?	1024	<--- this is wrong, but matches for the first disc
		0x16DA	294 bytes (0x126)	padding
	6	0x1800	1024 bytes (0x400)	not used
	7	0x1C00	1024 bytes (0x400)	not used
	8	0x2000	1024 bytes (0x400)	not used
	9	0x2400	1024 bytes (0x400)	not used
	10	0x2800	1024 bytes (0x400)	not used
	11	0x2C00	1024 bytes (0x400)	not used
	12	0x3000	1024 bytes (0x400)	not used
	13	0x3400	1024 bytes (0x400)	not used
	14	0x3800	1024 bytes (0x400)	not used
	15	0x3C00	1024 bytes (0x400)	not used
	16	0x4000	16 bytes (0x10)	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
		0x4010	1008 bytes (0x3F0)	padding
1 Disc map table	17	0x4400	variable	Disc map table		divided in chunks of 32 bytes. See table below
	Up to 32
Up to 64 Disc map table

iso.bin 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	4 bytes (0x04)	file_offset	0	file offset from start of .iso root (for the first entry is always 0)
	0x04	2 bytes (0x02)	file_size	variable	this size determines the displacement of the next file (in the next entry)
	0x06	2 bytes (0x02)	file_type ?	01 00	usually 1... and 0 for the last entry
	0x08	16 bytes (0x10)	file_checksum ?	variable	unknown
	0x18	8 bytes (0x08)	padding
Up to 32256					same structure than the previous entry

iso.bin 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	4 bytes (0x04)	file_offset ?	0	always increases
	0x04	2 bytes (0x02)	file_type ?	01 01	always 01 01
	0x06	3 bytes (0x03)	counter 1		some kind of counter, in decimal, always increases <-------- related with "sectors" inside the .iso ?
	0x09	3 bytes (0x03)	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 ?)

Decrypting owned ISO.BIN.EDATs and MINIS.EDATs

QUESTION: Am I allowed to post binaries compiled with the SCE SDK?
You can use this code snippet, which is based on a sdk sample, in your program to decrypt EDATs you have activated on your system:

#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;
}

Decrypted Content

Please help with your own uploads to better understand the structure.

Links to Samples of Decrypted ISO.BIN.EDATs

Angry Birds(USA)   NPUZ00119      http://www.multiupload.nl/UM81ZBTR8E
Final Fantasy VII  SCES00867(EUR) http://www.multiupload.nl/WBWFB2B8ZX
Final Fantasy VIII SLES02080(EUR) http://www.multiupload.nl/JT8IVA1ZQH

Links to Samples of Decrypted MINIS.EDATs

Angry Birds(USA)   NPUZ00119      http://www.multiupload.nl/6PJP0E6JHH

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.