Create an account Home  ·  Topics  ·  Downloads  ·  Your Account  ·  Submit News  ·  Top 10  
Modules
· Home
· Content
· FAQ
· Forensic Downloads
· Forensics Feedback
· Forums
· Members List
· Statistics
· Surveys
· Top 10
· Topics
· Training Reviews
· Web Links
· Your Account

Our Membership

Latest: johan_chen_2000
New Today: 2
New Yesterday: 2
Overall: 29413

Computer Forensics
This is a free and open peer to peer medium for digital and computer forensics professionals and students. Please help us maintain it by contributing and perhaps linking to us from your own website.

Recent Posts

 Hostile work enviornment
 Can anyone suggest me a topic under printers forensics
 Unallocated clustered as court evidence
 Encryption
 I know how to recover ost file 2016

Computer Forensics World Forums


Pages Served
We received
52920562
page views since August 2004

Security Sources

FTC
OnGuard Online
ISO 17799 ISO 27001
ISO 27000 Toolkit
ISO 27001 & 27000
Cryptography
Security Policies

Computer Forensics World: Forums

Computer Forensics World :: View topic - DVD burn change File create timestamp to modified timestamp
 Forum FAQForum FAQ   SearchSearch   UsergroupsUsergroups   ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

DVD burn change File create timestamp to modified timestamp

 
Post new topic   Reply to topic    Computer Forensics World Forum Index -> Technical Issues
View previous topic :: View next topic  
Author Message
Jonno
Newbie
Newbie


Joined: Feb 11, 2014
Posts: 2

PostPosted: Wed Feb 12, 2014 1:20 pm    Post subject: DVD burn change File create timestamp to modified timestamp Reply with quote

Burning a disk to hold raw evidentiary data and noticed that all files have had the creation date modified to mirror the last modified date. e.g file created in March 2007 and last modified in May 2010. When the file is burnt to DVD-ROM (DVD-R), the file creation date is changed to the last modified date.

We have used ImgBurn 2.5.8.0, selected the "Use file dates and time" option, as well as the "Allow Non-Compliant File Creation Dates"

We tried the 2014 version of Nero, selecting the "Use file date and time" option as well.

Disk burns are being conducted on a Windows 7 platform - we are going to test XP (building a machine now)!

For evidentiary purposes, we need to find a fix or a way to explain this anomaly in court!!

HELP -- please
Back to top
View user's profile
PreferredUser
Newbie
Newbie


Joined: Jan 01, 2007
Posts: 1130
Location: USA

PostPosted: Wed Feb 12, 2014 9:43 pm    Post subject: Reply with quote

The following is from the ISO 9660 standard and UDF standard "http://www.pismotechnic.com/cfs/iso9660-1999.html"
"http://www.osta.org/specs/"

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 12-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.
Back to top
View user's profile
Jonno
Newbie
Newbie


Joined: Feb 11, 2014
Posts: 2

PostPosted: Thu Feb 13, 2014 8:07 am    Post subject: Reply with quote

Thanks PreferredUser.

Question is - why is it that when we burn evidence to DVD - the file create date is changed to the LAST MODIFIED date and not the time of burning??? and even though we are using options that allow for the file dates to remain as they are - the creation date is still being changed.

This makes it hard when you are using evidence that relies on the Creation Date as part of the prosecution.

As it stands, we are looking at using ROBOCOPY to get all data to a USB Thumbdrive and then creating an EnCase image of the thumbdrive. We can then index and examine the EnCase image and burn it to DVD - as the image is a sealed container - leaving all dates of the contents unchanged!!
Back to top
View user's profile
athulin
Newbie
Newbie


Joined: Oct 19, 2007
Posts: 239

PostPosted: Fri Feb 14, 2014 5:33 am    Post subject: Re: DVD burn change File create timestamp to modified timest Reply with quote

Jonno wrote:
Burning a disk to hold raw evidentiary data and noticed that all files have had the creation date modified to mirror the last modified date. e.g file created in March 2007 and last modified in May 2010. When the file is burnt to DVD-ROM (DVD-R), the file creation date is changed to the last modified date.


What file system are we talking about here? I'm almost certain that it is ISO-9660, but it just might be UDF.

With ISO-9660, you have only one timestamp: time of recording. That's what the standard says. However, most software does not follow the standard. So you have to look at the software you're using to see what it actually does, and which of the possible timestamps of the original file it converts to the single timestamp that ISO-9660 allows (if any -- some use the current time and date if you encourage it). And if you're using a viewing tool that lies to you about what time stamps are actually present , you can get the most awful assumptions going unless you what is going on.

Add to that the confusion that arises over how to interpret an ISO-9660 timestamp. It is not specified by the standard. It could be a UTC timestamp with a TZ field that says in what timezone it was recorded. Or it could be a local time, with a TZ offset telling you *which* timezone. You have to know what your burning software does, and you also have to know what the software you're using to view the finished DVD with does. If they don't agree about interpretation, things can be very confused.

And add to that the bugs that may be present, and that may throw software off.


IF your burning software supports Extended Attributes, you can get file creation and file modification timestamps (along with file effective date and file expiration date, which are of considerably less use). On the other hand, not all viewing software do the right thing with these, as they are optional features.

With UDF, things are better. Not only should the timestamp state if its local, UTC or 'user defined', there's also multiple timestamps for access time, file modification or attribute modification etc. (Though watch the UDF releases.)

If you export files from a NTFS file system to an NTFS file system, retaining all timestamps from the originial, you do not want to record those to a ISO-9660 medium unless you have researched exactly what timestamp will be put in the single ISO-9660 timestamp, and document it clearly. Better use UDF.

Even so, you also need to verify that your burning software does the right things with UDF ...

In your case, I'd suggest creating a test directory with a single test file in it, and then use timestomp or setMACE (NTFS) to set all timestamps to something different. Then, burn that directory with its file through the same settings that you have already used. And then view the resulting CD through whatever viewer used. That should tell you how file time stamps 'travel'.

Added: Don't set to outrageous timestamps, or you may be hit by additional bugs in timestamp conversion. Stay between 1970 and 2038.
Back to top
View user's profile
Display posts from previous:   
Post new topic   Reply to topic    Computer Forensics World Forum Index -> Technical Issues All times are GMT + 10 Hours
Page 1 of 1

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum

Powered by phpBB 2.0.10 © 2001 phpBB Group
phpBB port v2.1 based on Tom Nitzschner's phpbb2.0.6 upgraded to phpBB 2.0.4 standalone was developed and tested by:
ArtificialIntel, ChatServ, mikem,
sixonetonoffun and Paul Laudanski (aka Zhen-Xjell).

Version 2.1 by Nuke Cops 2003 http://www.nukecops.com

Forums ©

 

TMs property of their respective owner. Comments property of posters. 2007 Computer Forensics Science World.
Digital forensic computing news syndication: Computer Forensics Training News or UM Text
Software is copyrighted phpnuke.org (c)2003, and is free under licence agreement. All Rights Are Reserved.