I have logical images in AD1 format and ISO format of some UDF formatted CD's and am trying to validate the volume serial numbers of the CD's, it's been a while since I've had to CD analysis and can't remember if that information is stored on the disc or not. Based on some google research i'm lead to believe that it isn't, and that the volume serial number (eg. 0000-0000) is generated dynamically by the operating system.
Thanks.
I have logical images in AD1 format and ISO format of some UDF formatted CD's and am trying to validate the volume serial numbers of the CD's, it's been a while since I've had to CD analysis and can't remember if that information is stored on the disc or not. Based on some google research i'm lead to believe that it isn't, and that the volume serial number (eg. 0000-0000) is generated dynamically by the operating system.
Thanks.
Yep, this is "generic" AFAICR, i.e. it applies to CDFS as well, see (only seemingly unrelated)
http//
http//
Windows NT "generates" the serial, but I never found a reliable source explaining the behaviour, though something like a "seed" for the serial displayed by windows is actually written to the CD
http//
jaclaz
I have logical images in AD1 format and ISO format of some UDF formatted CD's and am trying to validate the volume serial numbers of the CD's …
As far as I know, there is no research on that topic. The volume serial number is intended to distinguish volumes in a single session – that is, there is no or little reason for a volume serial number to survive a reboot – and doesn't strictly need not be the same for a very long time.
That said, my CD-ROM collection does produce the same volume serial numbers from Windows XP to Windows 7, so it may be static. But it requires additional testing to say definitely – I've only used client operating systems, for example.
can't remember if that information is stored on the disc or not.
There's no field in the ISO 9660 standard that is contains a Windows volume serial number. I'm almost certain that there is none on a ISO 13346 disk either, but I haven't studied that format extensively.
While it is possible to store it in some 'system usage' area, Windows must be able to cope with media that do not contain it, so it seems needless to store it anywhere.
I believe someone was able to recreate the method used for ISO 9660 discs – based on a hash of the Primary Volume Descriptor, if I remember. I've not seen any description of the method used on ISO 13346-discs.
The best thing you can do is to mount the CD (or the image), and either 'DIR' the disk or use the equivalent system call. But you probably still can't say for certain that it will be the same over multiple platforms or releases unless you test it yourself.
I believe someone was able to recreate the method used for ISO 9660 discs – based on a hash of the Primary Volume Descriptor, if I remember. I've not seen any description of the method used on ISO 13346-discs.
The old experiment linked above links the Secondary (and not the Primary) Volume Descriptor to the output of the VOL command.
jaclaz
As far as I know, there is no research on that topic …
Well, none published. The results have been published as part of the Wine Windows emulator, and particularly in the implementation of the GetFileInformation() system call. The relevant source code is in ./dll/kernel32/volume.c file.
It doesn't seem to be entirely correct, but for what it is worth, I'll try to summarize it.
First, the volume serial number is computed from a 'super block'. Once the 'super block' of the ISO9660/UDF volume has been identified, perform four byte-summations of all bytes of that block (byte[1] is the first byte, and all sums are byte-sized)
sum1 = byte[1] + byte[5] + byte[ 9] + …
sum2 = byte[2] + byte[6] + byte[10] + …
sum3 = byte[3] + byte[7] + byte[11] + …
sum4 = byte[4] + byte[8] + byte[12] + …
Those four bytes (sum1, sum2, sum3, sum4) make up the serial number. But ISO9660 and UDF place them in different orders.
This is not a robust method. If a person has control over one byte in each of the four summation streams, any volume serial number can be created just by putting the correct bias data in those bytes. ISO 9660 makes this easy – there are lots of zero-filled, unspecified bytes that can be used for this.
The selection of which 'super block' to use appears to be as follows.
if the volume is ISO9660, use the 'largest' volume descriptor (but ignore volume descriptor set terminator), where 'largest' means the first descriptor with the highest Volume Descriptor Type.
As Primary Volume Descriptor has Type 1 and Supplementary Volume Descriptor has Type 2, the latter trumps the first, if both are present. If there are multiple descriptors of the same type (which is possible for both types), the first one wins.
The resulting volume serial number is sum1sum2–sum3sum4, each in hexadecimal notation.
WARNING! This probably needs additional verification. As the code is written, a Volume Partition Descriptor (Type 3) would trump either a Primary or a Supplementary. Volume Partition Descriptors are almost unheard of – I've never seen one in real life, not are they reported by the forensic tools I've tested so far. That also goes for the unspecified types (4–254) which are reserved for future standardization.
This means that anyone wanting to fake a particular Volume Serial Number can probably easily do so also by adding a 'larger' descriptor that is likely to go unnoticed.
For UDF, the superblock selection code appears to be wrong. It looks for the first 'BEA01' block in the extended area, immediately after any ISO 9660 volume descriptors that may be present, and uses that. Then, it puts the sum bytes into the other order sum4sum3–sum2sum1.
However, the BEA01 record is 'dead' and doesn't contain anything that changes with a particular volume, so all UDF volume would appear end up with the same hash.
I hope I'm misreading the code in some way. A quick test indicates that it is possible to find a sector on an UDF disc that computes to the same volume serial number that the DIR command produces. However, I don't see how to get to that sector from the anchor points of the volume. Someone who knows ISO 13346 or UDF better needs to take a look at that.
In any way, it seems possible to compute volume serial number from that 'super block' on ISO9660 on the one hand and ISO 13346/IDF on the other, even if there are a few unclear points that needs to be cleared up first.