13
2
Is there a way/tool to determine the date and time when a disc has been written/burned with high certainty? This is about data forensics and should be a solid proof. I already tried IsoBuster, but it didn't show me the date/time at which the track has been written.
woerndl
Posted 2013-02-28T22:07:02.510
Reputation: 475
18
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.
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.
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.
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.
Dennis
Posted 2013-02-28T22:07:02.510
Reputation: 42 934
I tried running dd if=/dev/disk4 | tail -c +33144 | head -c 17 | hexdump -C. But I only get zero's. Is my calculation 32,768 + 376 correct or has the unused block of UDF a different size? I googled it, but didn't find something. – woerndl – 2013-03-01T14:10:51.287
Disktype returns the following:
`--- /dev/disk4
Block device, size 4.383 GiB (4706074624 bytes)
disktype: Data read failed at position 4706070528: Input/output error
UDF file system
Sector size 2048 bytes
Volume name "Alenander"
UDF version 1.02
disktype: Data read failed at position 4706009088: Input/output error`
– woerndl – 2013-03-01T14:30:21.587Is it supposed to work with audio discs? (doesn't seem to me) – Franck Dernoncourt – 2014-04-05T03:37:40.637
@FranckDernoncourt: No. ISO 9660 and UDF are file systems of optical data discs. – Dennis – 2014-04-05T03:56:37.387
@Dennis Thanks! Any idea for: How to find out when an audio disc (CD) has been written/burned?
– Franck Dernoncourt – 2014-04-05T03:58:38.560@FranckDernoncourt: Audio DVDs use UDF as well, but audio CDs require a different approach. It's midnight where I live; I'll take a look at it tomorrow. – Dennis – 2014-04-05T04:06:53.773
-1
Yes, there is: date and time attributes is what you are looking for. Just change view of the folder and check Properties of the file.
Checked a minute ago one disk on both W7 and Mac OS X. See screenshots below..
Volodymyr M.
Posted 2013-02-28T22:07:02.510
Reputation: 1 428
1File modification times don't likely have anything to do with when the files were burned onto a disk... and what if it's an audio disc or something like that, which does not have a filesystem? – Celada – 2013-02-28T22:40:42.940
OP doesn't mention what kind of CD\DVD is used, for the 2nd, once written to CD\DVD attributes cannot be changed, so why these cannot be used as a source of info, even if it doesn't give 100% guarantee? – Volodymyr M. – 2013-02-28T22:44:39.310
@Volodymyr file change dates are everything I have right now. They are kind of a proof, but don't offer the certainty I'm looking for. Thank you for your effort though. – woerndl – 2013-02-28T22:46:21.553
@Celada Did you find an answer to your question about audio disc? I am having the same issue. – Franck Dernoncourt – 2014-04-05T03:22:13.497
1Carbon dating? :) That's only half a joke: it really does seem like you should be looking to physics for the answer, not computer science. – Celada – 2013-02-28T22:33:33.557
1I'd have to agree with @Celada Any date burned to the disk would be easily faked. For solid proof you'd probably need to be conducting physical tests on the disk itself. – Dracs – 2013-02-28T22:35:47.930
@Celada, well that's a good input for sure, thanks. But I hope that there is a good way to determine it with common software/hardware since resources play a role and are a bottleneck in this particular case. – woerndl – 2013-02-28T22:40:58.937
@Dracs thank you too. Well I basically take everything as 'solid proof' that's better than file change dates. – woerndl – 2013-02-28T22:42:51.763
There are several (often hidden) dates associated with each file and directory, and I think one reflects when it was last written, even if an exact copy of an older file. But they are poorly documented and it's hard to say how reliable, plus it's quite easy to set a computer forward or backwards in time to do the writing, so just about anything can be faked. – Daniel R Hicks – 2013-02-28T22:46:55.803
@DanielRHicks exactly as you say, Daniel. There are files with different dates written on the disc, two files proof that the disc has been written after a certain time (that's what I'm looking to prove). But there are also files with a timestamp dating back a year, that could confuse some people who need to trust the evidence. – woerndl – 2013-02-28T22:51:51.173
2If you find a CD that claims to have been written prior to 1980 it's probably a fake. – Daniel R Hicks – 2013-02-28T22:54:09.320
I changed 'a long time' into 'a year'. I think we had different measures in this case. The point is to prove that the disc was written after the 1. February 2013. – woerndl – 2013-02-28T22:59:18.580
A big question is what you're trying to prove. Proving the negative -- that the disk is a fake -- is a lot easier than proving that it isn't, because you only need one piece of contradictory evidence vs having to prove everything's legit. And there are different strategies one would take trying to prove it was written before some date vs trying to prove it was written after. So it would help to know which quadrant you're sitting in. – Daniel R Hicks – 2013-02-28T23:04:47.497