iPhone Video Metadata

(This is also available on the CSITech website at http://www.csitech.co.uk/iphone-video-metadata/)http://www.csitech.co.uk/iphone-video-metadata/

First question, if you start a sentence with the word iPhone should you captialise the ‘I’, answers on a postcard please.

Second question came from a law firm that I often assist with digital forensics cases.  When an iPhone is used to take a video and then distributed does it contain any device ID information that can be used to trace it back to the original phone?

The answer, somewhat surprisingly knowing Apple, appears to be no, I cannot find any reference to the serial number, IMEI or ICCID numbers within the file although it is possible that the data is there but obfuscated in some way.

Whether there or not, looking at iPhone movie data is very interesting.  We are all used to the vast amount of metadata embedded within a photo but movies are a bit more of a dark area with not much written about it.  The movies are based around the QuickTime file type that is well documented by Apple which can be found here - http://developer.apple.com/library/mac/documentation/quicktime/qtff/qtff.pdf

The filetype is awash with metadata, some which are used by default in the iPhone and many that are not.  Although there does not appear to be anything to specifically identify the iPhone which shot the video there are some useful bits of data which could help.  I have focused on a video shot by an iPhone 5 and then emailed out of the device. 

The QuickTime structure is based around Atoms and Keys.  Atoms are small 4 character tags such as ‘prfl’ for profile, ‘tkhd’ for the track header and many, many more.  There are also keys that are of specific interest to us as they contain the primary metadata that we may want.  The keys are in the ‘mdta’ atom and take the form of ‘com.apple.quicktime.author’, for example.

At offset 0x04 you come across the ‘ftyp’ atom which identifies the type of video to follow.  The iPhone uses QuickTime and so the tag which follows is ‘qt’.

Next is the ‘mdat’ atom which I guess stands for movie data and contains the data related to the movie itself.

Next is the ‘moov’ atom which partly indicates that the movie came from a Mac platform, ie the iPhone.  The ‘moov’ atom has a number of sub-atoms which brings us to the area we are interested in.

Once we pass all the obvious movie data we pick up a ‘keys’ atom which is then followed by metadata identified by the atom ‘mtda’.  The entire section can be seen in the image below.

There are several interesting tags here.

©mak«Apple - This identifies that the movie came from an Apple manufactured device.  Although this might sound obvious we might have a series of videos from a suspects computer that we think he may have taken.  However, if he is an Android and PC user then this would reduce the likelihood that he created them.

©swr«6.1.4 - This is rather useful as it tells us the IOS software version that was installed at the time that the video was taken.  Again, a scenario could be that a suspect accuses his co-defendant of shooting a video but we not that the co-defendants iPhone is running an earlier IOS version.

©day«2013-05-27T21:38:21+0100 – This provides us with the time and date that the video was shot.  Helpfully this date does NOT change when the file is moved, emailed or uploaded.  This provides a solid line in the sand as to when the video was made.  The time is also adjusted from UTC so we see the real world time it was created.

©xyz«+52.5461-002.6371+115.546 – This tag ‘@xyz’ provides GPS location data provided by the GPS chip in the phone.  Although not delimited we can divide it up to provide:-

x - +52.5461

y - -002.6371

z - +115.546 – This appears to be the direction taken from the onboard compass.

This data depends on location data being turned on for Photos in the Privacy tab in Settings.

©mod«iPhone 5 - This is great, it doesn’t just tag the device as an iPhone but as an iPhone 5.  Again this may help us to identify the phone in a case that shot a video.  So we know the video was taken by an Apple iPhone 5 with firmware 6.1.4 on the 27/5/13 at 21:38:21 at a specific location.  That’s not bad information.

All the information is then repeated using different tags as follows:-

mdtacom.apple.quicktime.make

mdtacom.apple.quicktime.creationdate

mdtacom.apple.quicktime.location.ISO6709

mdtacom.apple.quicktime.software

mdtacom.apple.quicktime.model

So can we identify a specific device that shot a video?  Not definitively no, however we may have a case where a number of phones are seized, perhaps a couple of Androids, an iPhone 3 and an iPhone 5.  They may all have the same video on their phones showing illegal activity and be accusing one another of shooting it.  In this case we may have sufficient metadata to pinpoint the culprit.

When I first started looking at this I assumed that it was a purely academic exercise as our normal forensic tools probably report this data but it seems not.  A quick look in FTK with my test video only showed the Operating System dating, created, modified etc and not the embedded video created date.  There was also no extraction of ANY of the metadata we have discussed, no model, firmware, GPS data, anything!  Obviously you can manually work through the Hex to find the tags but it could easily be missed if we don’t know it’s there.

Hope that’s helpful to you? 

Skype Chat Carver from RAM - Skypeex

Well I was going to keep testing but it just seems to keep working, so here it is in version 0.5.

Download

I’ve been teaching my RAM analysis course for about a year now and enjoy working with Volatility and some other open source tools. I’ve been making use of Jeff Bryners cool little Python script (http://www.jeffbryner.com/code/pdgmail) to extract Gmail artifacts and was motivated to do the same for Skype chat and any other Skype stuff that might be hanging around in a RAM dump.

The only problem was that, although I’ve done a bit of programming in the past, Python was a long hissy thing you wouldn’t want to meet on a dark night. Having gone through the pain of programming ‘Hello, world’, simple Pokemon text games for my lad and tedious maths exercises, I’ve actually managed to produce something meaningful.

The idea is to extract Skype chat lines with their associated meta-data, which includes timestamps, the Skype names in the conversation and the author etc.

The complete Skype line in RAM starts with the magic value ‘INTO Messages” followed by column headers then the values of the chat line including the chat body.

This is very much work in progress but will simply do the following:-

1. Run Strings against your RAM dump
2. Run the Skypeex tool against the resulting Strings file
3. It will carve out all the Skype chat lines it can see as well as trying to find and extract all the Skype sessions and ‘orphan’ chats that have been created.

It’s interesting to note that the latter process even seems to find the ‘spam’ message sessions that you sometimes receive.

This has been tested on dump files from Windows XP2 and XP3 with Skype 3.8 through 4.2.
I don't currently have a Windows 7 box up and running, if anyone has one available please let me know.

Please do not hesitate to get in touch with ideas and improvements.

Usage:

There are 2 versions in the zip file.

skypeex.py is designed for use under Python 3.1.1 and above

skypeex26 is designed for use under Python 2.6

Due to changes with several commands between 2.6 and 3 they are not interchangeable, although the differences in this code are only in the input and print lines.
For best testing results, have several Skype IM chats with friends and then image your RAM. On a windows box, use any tool to grab RAM (tested on Win XP SP2/3):

I recommend Win32dd (or Win64dd) from Matthieu Suiche - http://windd.msuiche.net/

Run strings against the RAM image (e.g. Windows version can be found in Helix distro)
example: strings c:\ramdump.dd > c:\stringsout.txt

On linux box do:
strings ramdump.dd > stringsout.txt

Script usage -
from command shell - python skypeex.py - then, when prompted, simply provide the path to the strings output file.

The output files will be written to the folder where the script is run from. The output is a CSV file with chats (incl headers) and a txt file with extracted skype sessions and carved orphan chats. Please expect many duplicates and some false positives.

In the CSV file the 'Timestamp' column is the date and time of the message in UNIX time. Sorting on this column gives you a timeline of messages. I'm writing a UNIX time decoder but it doesn't work yet.

The primary message content is in the 'body_xml' column.

Code:

The key elements of the code are:-

if "INTO Messages" in line:
def extract(text, sub1):
return text.split(sub1)[-1]
str2 = extract(line, 'VALUES (')

This searches for the magic value, strips out the rubbish and returns the comma delimited values we are interested in. This includes:-

Chatname – the initiator and recipient of the session
Timestamp – The time and data the message was sent in UNIX time
Author – the sender of the message
From_dispname – the screen name being used by the sender
Body_xml – the body of the message, can slip into the chat_msg column
GUID – session identifier

Next:

if "#" and "/$" in line:
outfile.write(line)
nxt = next(data)
outfile.write(nxt)

This time we look for the existence of the # and /$ characters in the same line. This refers to the pattern written to RAM of each Skype session, which looks like this:

#nfurneaux/$bennyboy1982;810b0fd9ef04db08

This shows the 2 persons in the Skype session with the first name being the initiator of the conversation. I’m still trying to figure out the hex value at the end, but it seems to be a GUID session number, any ideas let me know.

Sometimes we recover session line like the following:

#bennyboy/$nfurneaux;9fa7c85b71354392Jd1bbennyboy1982Ben Brown
#andyw/$nfurneaux;9fa7c85b71354392Jd1TnfurneauxNick Furneaux

We are able to see the actual Skype name as well as the screen name being used during the session. The cool thing is that we also grab the next line with often includes actual chat associated with the recovered session. Hence we capture:-

#bennyboy/$nfurneaux;8f915423c984767aJ[VonfurneauxNick Furneaux
ok quite close
# bennyboy /$nfurneaux;8f915423c984767aJ[bennyboy Ben Brown
Aug 23
# bennyboy /$nfurneaux;8f915423c984767aJ[VQnfurneauxNick Furneaux
when are you presenting at HTCIA
# bennyboy /$nfurneaux;8f915423c984767aJ[bennyboy Ben Brown

Interestingly this conversation is carved in reverse. We can ascertain that bennyboy started the conversation but see the sender in the second part of the session line, followed by the chat.

I've never released a tool to the community before so be kind! Let me know how you get on.
Nick Furneaux

Download

'Super' Computing!

It's been a big day! My supercomputer arrived in a rather large box, much to the obvious annoyance of the delivery man who had to drag the thing 30 yards as he couldn't get the van up the lane near the office.

Unwrapped and connected up to a suitably large screen the beasty purred into life and promptly crashed. No Apple technology here. Side off, found a couple of loose cards,tighten up, reboot and we are away.

The machine is based on AMD motherboard technology with 2 uber ATI 4870X2 boards providing 800 parallel processing cores per board giving a total of 1600 processing cores. With the right software designed for GPU parallel processing it will chug along at 2.4 terraflops or 2.4 trillion floating point calculations per second.

The definition of a supercomputer is 1 trillion terraflops and the first one was built by Intel just 11 years ago, it took up 2000 sq ft of space. 11 years on I have a machine 2 1/2 times more powerful under my desk, the lights dim when I fire it up but you can't have everything!

I've bought it to carry out super fast password cracking, I can chew through 60,000 passwords per second or 5.1 billion per day which is some work rate especially when using intelligent varying dictionary based attacks. Instead of pure brute forcing which is all down to key space (password length * all possible combinations), an intelligent varying dictionary attack takes a word such as 'password' and attempts all likely variations such as :-

pa55word
pa55wOrd
6a55w0rd
password1
password123 etc etc

Using this process a 3 million word dictionary can quickly be turned into a 150 million word table or much more. When done 60,000 times per second you can try an awful lot of variations and the success rate becomes very high indeed. A completely, pattern free, randomized password/phrase will still require brute forcing and we will all probably retire before a guaranteed success.

The new software I'm using focuses on WPA 4 way handshake attacks, you can check it out here. Other software allows the GPU accelerated attacks against Office files and loads of others.

My first job arrived from a Police Department yesterday so we shall see how it goes.

Link to the NIST research on dd isues

I've written a couple of simple overviews of the issues surrounding dd and the seeming lost sectors when bad blocks are encountered. I neglected in my previous posts to include a link to the research by NIST at http://dfrws.org/2007/proceedings/p13-lyle.pdf.

Speaking to both Drew Fahey and Barry Grundy the feeling is that there is no reason to overreact, virtually every tool we use has some flaw or another, however further research is needed to be clear about the issue and how to circumvent it.

I'm off to present at the ACPO conference tomorrow and I'm sure the subject will come up, I'll post any interesting comments.