ABSTRACT
This is a description how the Apple Ipod/Iphone stores the timestamps into their plist
files. After an experiment we tried to order the various ways that Apple Idevices manage
and store these data. We found the timestamps into PlayCounts.plist are in local time
and not in absolute time GMT.
During an experiment on an Apple IPod Touch we found three ways for storing the
timestamps and many documents on the Internet about the HFS/HFS+, Mac OS Date
and timestamps, we found that the IDevice systems have three ways to save dates and
times in a plist file (XML or binary mode) [1]:
1. The most widely used by the plist (e.g. cookies.plist) format is “year-month-
DayTHour: minutes: secondsZ” (yyyy-mm-ddT00: 00:00 Z), and time and the date is
taken directly from the setting on the device.
2. A second system adopted by some plist is the use of offset CFAbsoluteTime Interval
Since 1904 [2] (01/01/1904 00:00:00 GMT), where the dates and times are written to
the plist file in accordance with the wording of 10 (ten) numeric values (1234567890).
3. The third standard is CFAbsoluteTime Interval Since 2001 [3] (01/01/2001 00:00:00
GMT). In this case the value will be 9 (nine) numerical values, and “n” decimal
(123456789, n). If you apply the formula ((VALUE + 978307200) / 86400)+25569,
where VALUE means the whole number, with the offset 978307200 01/01/2001, 86400
with the number of seconds in a day and 25569, the value which counts the dates the
program Excel, you can get a normal date in format DAY / MONTH / YEAR HOUR:
MINUTES: SECONDS, such as 123456789 +978307200 / 86400 +25569 = 11/29/2004
21:33:09.
The HFS+, file system used widely on IPod Touch, saves timestamps in Epoch time
numbers of seconds since 01/01/1904 00:00:00 GMT. [2]
So, if we analyze the content of the file PlayCounts.plist
(/private/var/mobile/Media/iTunes_Control/iTunes ) we can find strings like these:
<dict>
<key>bookmarkTimeInMS</key>
<real>0.0</real>
<key>deleted</key>
<integer>0</integer>
<key>persistentID</key>
<integer>-7480829492115005527</integer>
<key>playCount</key>
<integer>1</integer>
<key>playMacOSDate</key>
<integer>3425616658</integer>
<key>playedState</key>
<integer>1</integer>
<key>skipCount</key>
<integer>0</integer>
<key>skipMacOSDate</key>
<integer>0</integer>
<key>userRating</key>
<integer>0</integer>
</dict>
The question is the number 3425616658 is the number of seconds since 01/01/1904
00:00:00 and then we have to add the timezone and DST timestamp or these two data
are included?
The only way to answer to this question is experimentation, we played a song at 08.10
AM in Italy in DST time, the we dumped the physical image file by UFED Physical
Analyzer and we search inside it the string:
<key>playCount</key>
and we obtained a cluster of strings like this:
<key>playCount</key>
<integer>1</integer>
<key>playMacOSDate</key>
<integer>3425616658</integer>
Now, if we divide this number for 86400 (number of seconds in a day) and convert this
number in an Spreadsheet software like MS Excel or LibCalc in a Date cell format set
starting from 01/01/1904 we got:
20/Jul/2012 08:10:58
So, we did not need to add local timezone and/or DST we have both already included
into the number 3425616658.
We can conclude that the HFS+ saves the timestamps in Absolute time as number of
seconds since 01/01/1904 00:00:00 in GMT+0 (UTC) but the timestamps written inside
the files like PlayCounts.plist are in Absolute time since 01/01/1904 00:00:00 + local
timezone + DST taken from the device settings, indeed we tried to change the device
time settings and we got a different number of seconds those converted we got the
exact timestamps as on the device time settings.
BIBLIOGRAPHY
[1]
http://developer.apple.com/library/mac/#documentation/Cocoa/Conceptual/PropertyLists/Introdu
ction/Introduction.html
http://en.wikipedia.org/wiki/Property_list
[2] http://www.forensicswiki.org/wiki/Mac_OS_Xhttp://en.wikipedia.org/wiki/Epoch_(reference_date)
http://opensource.apple.com/source/CF/CF-550/CFDate.h
[3]http://developer.apple.com/library/mac/#documentation/corefoundation/Reference/CFTimeUtils/
Reference/reference.html
https://developer.apple.com/library/mac/documentation/CoreFoundation/Conceptual/CFDatesAn
dTimes/CFDatesAndTimes.pdf
iPhone consolidated.db location tracking notes
Authors
Nanni Bassetti, Digital Forensics Expert, C.A.IN.E. Linux forensic distro project manager,
founder of CFI – Computer Forensics Italy, mailing list specialized in digital forensics topics, codeveloper
of SFDumper and founder of the web site http://scripts4cf.sf.net.
Personal website: http://www.nannibassetti.com – e-mail: [email protected]
Giuseppe Di Ieva, Scientific State Police. Specialized in Internet Investigations,
Intelligence, Mobile and Computer Forensics, Training.
Expertise in evidences gathering, computer forensics and cyber-crime investigations.
LinkedIn: http://tinyurl.com/9xn423w e-mail: [email protected]
Thanks for sharing this. Time stamps are always a challenge.
http://www.forensicfocus.com/Forums/viewtopic/printertopic=1/t=6964/start=0/postdays=0/postorder=asc/vote=viewresult/
Re: MacOSDate
Posted: Tue Jan 04, 2011 5:34 am
Author: TomP Location: Uk
As AlexC says, the Mac times tend to be from 01/01/2001 or at least with the ‘Mac Absolute Time’ that I have come across this was the case.
To convert the times I used a pretty basic process within excel of converting the 01/01/2001 to an epoc time (3187468800) and added this to the extracted time stamp (also in seconds). I then divided this by 86400 and formatted the cells in the dd/mm/yyyy hh:mm:ss format. The results were manually verified using dcode and the Mac Absolute Time converter however I wanted a formula that would work within excel for multiple extracted time stamps.
http://www.forensicswiki.org/wiki/Mac_OS_X
HFS/HFS+ date and time values
In HFS+ date and time values are stored in an unsigned 32-bit integer containing the number of seconds since January 1, 1904 at 00:00:00 (midnight) UTC (GMT). This is slightly different from HFS where the date and time value are stored using the local time. The maximum representable date is February 6, 2040 at 06:28:15 UTC (GMT). The date values do not account for leap seconds. They do include a leap day in every year that is evenly divisible by four. This is sufficient given that the range of representable dates does not contain 1900 or 2100, neither of which have leap days. Also see: Technical Note TN1150 – HFS Plus Volume Format
Converting HFS/HFS+ date and time values with Python:
import datetime
print datetime.datetime( 1904, 1, 1 ) + datetime.timedelta( seconds=0xCBDAF25B )
Where are the secrets? You mean the old news 🙂
The problem was to understand the timestamp inside the plist…GMT+0 or device localtime ? That was the focus of the article..thanks
Do you mean as in this example?
http://www.forensicfocus.com/Forums/viewtopic/printertopic=1/t=6964/start=14/postdays=0/postorder=asc/vote=viewresult/Forums/
what a coincidence… the same problem, the same number of seconds (-10):
you write today:
>>>>starting from 01/01/1904 we got:
20/Jul/2012 08:10:58
So, we did not need to add local timezone and/or DST we have both already included
into the number 3425616658
he wrote in july 2012:
>>>>>print datetime.datetime( 1904, 1, 1 ) + datetime.timedelta( seconds=3425616668 )
2012-07-20 08:11:08
you: 3425616658 – he: 3425616668
same question – same number – different country.
Can you explain this coincidence? What was your actual and personal contribution?
Smeriglio was me 🙂 I asked on the forum to control our results and to gather more infos…that’s all 🙂
So, you are saying in the article that the only way to answer the question is through experimentation (is that really true? That might be *A* way), you perform your trivial experiment and then you state that “we can conclude” … But you did not really think we can conclude anything but had to verify it on a forum? Also, why is that forum not referenced in the article?
What a piece of work.
Hi Julian, I am not understanding all these kind of comments….we simply did an experiment, we did not find official documentation about this topic, meanwhile we are experimenting we ask to the forum, we search on google and finally we check our results. We put in the bibliography only the documents and not the discussions on the forums, but we appreciate so much ForensicFocus we decided to publish here as our contribution.
Yes, “We can conclude” we can say that! Because, we tried to change timezone on the Ipod and we dump again the PlayCounts.plist, we saw that the timestamps is always converted in the local setting time of the device.
So, this is the sense of the article, HFS+ saves the timestamps in GMT+0 1904 epoch time, the epoch time inside the plist file is 1904 epoch time + time bias set on the device (timezone+DST)….that’s all…I hope this contribute could be help ….
In any case, thank you for your comment 🙂