Most optical data discs use the ISO 9660 file system standard Volume and file structure of CD-ROM for information interchange, the Universal Disk Format Specification or both (called a UDF bridge).
To find out which, you can execute
mount
on Linux after the disc has been mounted in order to identify the optical disc drive's device file.
Example output:
/dev/sr0 /media/dennis/CDROM iso9660 ro,nosuid,nodev,uid=1000,gid=1000,iocharset=utf8,mode=0400,dmode=0500,uhelper=udisks2 0 0
Here, the device file is /dev/sr0. The command
disktype /dev/sr0
will display the available file systems. If both are present, analyzing the ISO 9660 one should be easier.
ISO 9660
The standard specifies the field Volume Creation Date and Time as a numerical representation of the moment of the volume's creation, written to the 814th through 830th byte of the Primary Volume Descriptor in the following format:
YYYYMMDDHHMMSSCCO
where CC are centiseconds and O is the offset from GMT in 15 minute intervals, stored as an 8-bit integer (two's complement representation).
The first 32 KiB (32,768 bytes) of the disc aren't used by ISO 9660 and the above descriptor immediately follows the unused block, so we're interested 33,582th byte and the 16 that follow.
This information can be analyzed by any tool that can dump/read the raw data on the optical disc. On Linux, you can use dd to dump the relevant part of the image and hexdump to view the last byte properly:
dd if=/dev/sr0 bs=1 skip=33581 count=17 | hexdump -C
For my Ubuntu 12.04 x64 LiveCD, this gives:
00000000 32 30 31 32 30 38 32 33 31 37 31 33 34 37 30 30 |2012082317134700|
00000010 00 |.|
so the image was created on August 23, 2012, at 17:13:47.00 GMT.
UDF
The standard specifies the filed RecordingDateandTime as a binary representation of the moment of the primary volume's creation, written to the 376th to 387th byte of the Primary Volume Descriptor in the following format:
TT tT YY YY MM DD HH MM SS CC BB AA
Here, each pair is an octet (byte), i.e., XX is composed of two hexadecimal numbers.
TT tT is a little-endian 16-bit integer representing the type and time zone of the timestamp.
The 12 least significant bits (TTT) hold the time zone, encoded as the offset from UTC in minutes as a signed integer (two's complement representation).
The four most significant bits (t) hold the type (always 1, meaning local time).
YY YY is the year encoded as a signed little-endian 16-bit integer (two's complement representation).
MM, DD, HH MM, SS, CC, BB and AA are unsigned 8-bit integers representing the month, day, hour minute, second, centisecond, hundreds of microseconds and microsecond of creation.
Again, the first 32 KiB of the disc aren't used by UDF. In addition, the following 32 KiB bytes are reserved for a legacy ISO 9660 file system (which may occupy more space if present).
On a "pure" UDF disc, the command
dd if=/dev/sr0 bs=1 skip=65912 count=12 | hexdump -C
will display the encoded timestamp.
For testing purposes, I've created an UDF image with K3b. The output of the dd command was the following
00000000 4c 1f dd 07 03 01 0f 0b 11 00 00 00 |L...........|
0000000c
Analysis:
0xF4C (hexadecimal) is larger than 0x800 and – therefore – negative. Resting 0x1000 from 0xF4C gives -180 in decimal. This means that the timezone is UTC - 3.
0x07DD is 2013 in decimal (the year of creation).
The remaining octets can be interpreted literally in their hexadecimal representation (0x0F, 0x0B and 0x11 are 15, 11 and 17 in decimal).
This means that the image was created on March 1, 2013, at 15:11:17.000000 UTC - 3.
Caveats
It's straightforward to tamper with this date. All that's required is changing the computer's date before creating the image.
If the image is created before it's actually burned to the disc, the former time will get recorded. Thus, the field is only potential evidence for discs that were created by the owner himself.
Best Answer
Here is what happened: