The New Pxml Format


Vorporeal said:
Recent posts in Aimless_E's emulator frontend thread got me thinking:

Would it be of any use to include the MD5 sum of the ISO in the PXML file? It might be useful, and any PND creator (which I'm sure people will be using instead of creating PXML files by hand) would be able to easily automate the checksum process.

Reason why this might not be possible:
Let's say we have a really really small ISO file (this isn't a real one, don't mount it! :p)that looks like this if opened with a text editor:
CODE
#"FGihou837#"rEOF
Then, we create the MD5 of this and add the PXML to it:
CODE
#"FGihou837#"rEOF<?xml version="1.0" encoding="UTF-8"><PXML> ... <md5>...</md5>


So far so good, BUT there's one problem: when libpnd loads a PND file, it looks for the <PXML> tag. So, to libpnd, everything before the <PXML> still belongs to the ISO. This is:
CODE
#"FGihou837#"rEOF<?xml version="1.0" encoding="UTF-8">

Now, as you know, the PXML file format is an XML file format, which means that the user is allowed to add a good deal of information (including 1MB of spaces) at the beginning of the file, so it's not possible to determine where the PXML starts with the current PND file format. Which means that the MD5 can't be checked, because you need to have the exact same data when hashing as when checking the hash, which is not the case, since a part of the PXML will be included when checking the hash.

Have I made myself clear? ;)
 
Last edited by a moderator:
'dflemstr' said:
'Vorporeal' said:
Recent posts in Aimless_E's emulator frontend thread got me thinking:

Would it be of any use to include the MD5 sum of the ISO in the PXML file? It might be useful, and any PND creator (which I'm sure people will be using instead of creating PXML files by hand) would be able to easily automate the checksum process.

Reason why this might not be possible:
Let's say we have a really really small ISO file (this isn't a real one, don't mount it! :p)that looks like this if opened with a text editor:
CODE
#"FGihou837#"rEOF
Then, we create the MD5 of this and add the PXML to it:
CODE
#"FGihou837#"rEOF<?xml version="1.0" encoding="UTF-8"><PXML> ... <md5>...</md5>


So far so good, BUT there's one problem: when libpnd loads a PND file, it looks for the <PXML> tag. So, to libpnd, everything before the <PXML> still belongs to the ISO. This is:
CODE
#"FGihou837#"rEOF<?xml version="1.0" encoding="UTF-8">

Now, as you know, the PXML file format is an XML file format, which means that the user is allowed to add a good deal of information (including 1MB of spaces) at the beginning of the file, so it's not possible to determine where the PXML starts with the current PND file format. Which means that the MD5 can't be checked, because you need to have the exact same data when hashing as when checking the hash, which is not the case, since a part of the PXML will be included when checking the hash.

Have I made myself clear? ;)

What about reading till EOF? Or including the ISO size in the md5 tag?
 
Last edited by a moderator:
Jan-Nik said:
What about reading till EOF? Or including the ISO size in the md5 tag?

Didn't say it was impossible :p just that the current format doesn't support it without some major extensions. Another problem that might arise if we include the # of bytes of the ISO in the PXML would be that it could lead to exploits (don't know how but a cracker would maybe find a way; out-of-boundary reading? Redirecting to another PXML file? etc). It would be much better if libpnd could determine the end of the ISO file without user interference.

BTW, don't use MD5, use SHA1; much better hashing results.

Interesting find:
Wikipedia said:
The first 32768 bytes of the disk are unused by ISO 9660 data structure, and therefore available for other use. For example, a CD-ROM may contain an alternative file system descriptor in this area, as it is often used by Hybrid CDs to offer Mac OS-specific content.
Can we do some magic with this? When writing ISO files with ISO programs, the 32 kb are mostly filled with zeroes [citation needed, although I believe this is the case, mkisofs does this, 0x0000 until 0x8000 is empty] so we could theoretically have the 'PND maker' fill in the size of the ISO in the first 4 bytes of the image (after the hash has been made) and then skip those 4 bytes when checking the hash...

EDIT: If we want it really nifty, we can just include the whole PXML within that section, although this would be kinda complicated if we want a preview image as well (and would again require huge changes to the format).
 
Last edited by a moderator:
Back
Top