Quantcast
Channel: mobile forensics – Forensic Focus – Articles
Viewing all 46 articles
Browse latest View live

TomTom GPS Device Forensics

0
0

First published January 2009

Written by Ben LeMere (blemere@gpsforensics.org) & Andy Sayers (asayers@gpsforensics.org)

For more information visit GPSForensics.org

Introduction: The sales of portable navigation devices are at an all time high. Last year, more than forty million portable GPS devices like TomTom’s GO series or Garmin’s Nuvi series were sold worldwide. These devices can be a good source of evidence. With the entrance of hybrid devices into the marketplace, GPS devices now contain much more than navigational information and may contain data commonly found in cell phones as well as audio, video, and text based files like MS Word or PDF documents.The law enforcement community has seen a dramatic increase in the use of GPS devices as an instrument of a crime or as a “witness device” autonomously collecting and logging positional data while the crime is being carried out. TomTom and Garmin units are by far the most popular devices law enforcement have been encountering. The focus of this article will be on TomTom devices but the general process can be extended to other device types.

TomTom Specifics: TomTom provides a range of devices for navigation. Depending on the capabilities of the model, several different kinds of information can be acquired. Most models have an SD card slot or an internal memory and allow pictures, documents, audio and video files to be stored and accessed thru the device. Standard TomTom files found on a device may include:

- Location Information

- Device Info

- Called list

- Callers list

- Text Message Inbox

- Text Message Outbox

- Contacts

- Bluetooth Name and MAC ID

- User Information

All TomTom models will have a locations file which may contain the location the user set as home, a list of any recent destinations and possibly last journey data. It will also have a device information file which contains the device serial number, model number, software version and other general information about the device. Higher end TomTom models like the GO seriescan act as a hands free device for mobile phones and may contain call data, text messages, contacts and a list of paired phones by their MAC address.

Data Acquisition: Data acquisition can be achieved thru different methods depending on the TomTom model. This is specifically related to whether the device has internal memory or stores its data on a removable SD card.

In the cases of devices that use SD cards, the card can be removed and processed like any other removable media. A forensically sound copy of the SD cards should be made and used to analyze the data. An important note, TomTom devices do not support the write protection option built into SD cards and regardless of the write protection tab setting (located on the left of the SD card if looking at the top) will write data to the card.In the cases of devices that have internal memory, the devices will appear in Windows under “My Computer” when plugged in via USB as a removable storage device with the label “TomTom”. Once visible in ‘My Computer’, it is possible to open the TomTom directory and copy the contents. A more sound approach, than ‘clicking and dragging’ the files to the desktop, would be to acquire an image of the device and work from that disk image. AccessData’s FTK Imager is available from their support website and will acquire devices without a license. FTK 1.80 will parse up to five thousand files without a license dongle and is sufficient for devices with 2gb hard drives or less. FTK or Encase will make it easier to decode and view the files.

Note, when powering on the unit to acquire data, if the device establishes a lock from the GPS satellites the device will overwrite the Last GPS Fix information in the CurrentLocation.dat file with its present location. A faraday bag can be used to prevent this from happening or examining the device inside a building away from windows can accomplish the same thing.

Target Files: Once the data has been acquired the following files are good sources of information.

- *.cfg – contains locations. The file name depends on the model but is generally found in a folder with the name of the map. The file name is either ‘Mapsettings.cfg’ or .cfg. There may be more than one map installed on the TomTom. The map currently in use can be found by looking at the ‘currentmap.dat’ file.

- ttgo.bif or ttnavigator.bif – general device information, model number, serial number, user password (encrypted)

- Settings .dat – Paired phone ID and MAC address (max 5) and any user information.

- Called.txt – Name called (if in phonebook), Number called

- Callers.txt – Name of caller (if in phonebook), Number of caller

- Inbox.txt – Name, Number, Message, Date & time

- Outbox.txt – Name, Number, Message

- Contacts.txt – Name of contact, Number of contact. This file only exists if the user has chosen to import their address book from their phone.

Data Analysis: TomTom devices can store information relate to the owner’s home address and a list of their ‘Favorite’ locations. If a user selects to navigate to either their Home, a Favorite or an address entered as a destination then this information is stored in the ‘recent destination’ file that ends with a .cfg extension.

.cfg files contain:

- Home location

- Favorites

- Manually entered addresses

- Details of Last Journey (if entered)

- Last GPS Fix of the device

For each of the locations a Latitude and Longitude is stored along with both an automatically assigned name and a user editable name and a house number. It also stores how the user chose to navigate to the address (entering the latitude and longitude, selecting it from the favorites list, etc…).

TomTom devices can be paired to a mobile phone and used as a handsfree device. If this has happened it is possible to recover information that would normally be found in a mobile phone. These files are text files and can be viewed with any text editor.

‘Contacts’ folder contains: (earlier versions have these files in the root folder)

- The contacts list from the mobile phone previously connected

- A list of numbers called

- A list of calls received

- Sent/Received SMS messages

Unallocated Space – Useful information can be found in the deleted space on a TomTom. If the user has ‘reset’ their device then no live information will be available but the unallocated space will contain the information that was present before the reset. Also in the deleted space will be records of previous journeys plotted and potentially the actual GPS position of the device when the journey was plotted and its last GPS fix for that journey.

Last Journey – When a journey is plotted using a TomTom it takes the current GPS position of the device as the start point of the journey. Until the destination is reached the TomTom stores both the Origin and the Destination. If a wrong turn is taken in the journey the TomTom will initially attempt to make the user turn around or will try to steer the user back on to the route. If this fails then the TomTom will be forced to re-plan the journey. If this happens then the TomTom will again take the current GPS position as the origin, leaving the destination the same. When examined, the Last Journey Origin will be a place where the TomTom has been but it may not be the place the entire journey started from.

Last GPS Fix – A TomTom device always records where it is when it has a GPS fix, this is the ‘Last GPS Fix’ It may be in mid journey if the TomTom was turned off mid journey or it may be a place where the TomTom has been turned on since. Like the ‘Last Journey Origin’, this is a place where the TomTom has been. The last GPS fix can be found in the CurrentLocation.dat file and is only available on newer TomTom device. Older models may store the information in the .cfg file.

Triplog Files – TomTom devices collect anonymous usage data from users who allow it. If a user enables this function while setting up the device, in the device file system there will be a folder titled ‘statdata’ containing files titled ‘triplog-yyyy-mm-dd.dat’. These files are encrypted and there are no known tools that can read the contents.

Recommended Seizure Techniques: Like any other GPS device, TomTom devices are continuously collecting information and writing data to memory whenever they are powered on. When you seize a device, power the unit off and do not turn it on until you are ready to examine it. When you are ready to examine the device you should be inside away from windows so the device does not have a clear view of the sky. A faraday bag can be used to ensure that the TomTom cannot establish a lock from the GPS satellites. If it establishes a satellite lock, the device will overwrite the Last GPS Fix information in the CurrentLocation.dat file.

Until the latest software update, App 8.0.10, released in the July/August 2008 timeframe, turning a TomTom device off that is protected by a pin code would not prevent you from accessing the device with a computer. App 8.0.10 has “fixed” that issue and requires the pin code to be entered before the device will go into disk mode.

Tools Available: Currently the best tool available for examining TomTom devices is TomTology. It was developed by two computer crimes investigators from the UK. It is a forensic tool used exclusively for examining TomTom devices and provides users with the capability to; Decode live data (Home Location, Favorites, Recent Destinations, Last Journey Start and End Point, Stored Phonebook, Called Phone Numbers, and Received Phone Numbers), automatically retrieve deleted journeys from unallocated space, locate deleted phone numbers, export all or selected locations to Google Earth, and produce detailed HTML reports. TomTology will automatically perform a full analysis of a TomTom including unallocated space and can extract data from a disk image created by FTK or EnCase.

There is also a separate EnCase Enscript available to parse files from an image file using EnCase. Email us for information and to request a copy at info@gpsforensics.org.

Definitions:

ENTERED LOCATIONS – These locations have been entered into the TomTom, either as a Home, a Favorite, a Destination or a Point of Interest. They appear at the top of the list when a user chooses to navigate to a new address.

FAVORITES – It is possible for a user to enter a number of addresses or places into their TomTom and save them as a Favorite. It is then possible for a user to quickly access these places to navigate to them.

HOME LOCATION – The Home Location is the address or place that has been entered by a user into the TomTom as the location of their home.

LAST GPS FIX – The TomTom keeps track of where it is. It may be along a journey if one is in progress or just where the device was when it was last turned on.

LAST JOURNEY INFORMATION – TomTom devices can save the details of the last journey. The last journey Origin is the actual position of the TomTom unit. It does not always mean that this is the start of the journey. If the user takes a wrong turn and the TomTom has to recalculate the route it places this point as the Origin of the last journey. It can be said that the TomTom device has physically been at this location.

NAVIGATED BY – How the user selected the location is stored in the TomTom. When a user selects to navigate to a destination they can do so by selecting to navigate to:

- Home

- Favorite

- Recent Destination

- Postal Code

- Entering the address manually

- Selecting the point off a map

- Point of Interest

- Entering the Latitude and Longitude

- Selecting to go to a city centre

ORPHANED LOCATIONS – Orphaned Locations are those addresses found in the deleted space that are no longer part of a file or the header of the file has been overwritten. Because they are no longer part of a file all of the information may not be available. It may not be possible to say what type of entry they are, only that they are present upon the device.

RECENT DESTINATIONS – Recent Destinations are places that the user of the TomTom has selected to navigate to. It does not mean that they have been there, only that the address has been entered.



SonyEricsson Hidden Evidence

0
0

First published February 2009

by Greg Smith
Mobile Telephone Evidence & Forensics
trewmte.blogspot.com

I have discovered that it is possible when manually examining some SonyEricssons (such as “K” range etc) that after a user has deleted the Last Number Dialled (LND) from the call register that it is possible to recover the last ten numbers dialled on the handset using the ‘menu keys’.Here is the routine**:

- Select Menu
- Select Messages
- Select Write New
- Select Text Message: this displays the screen to commence entering text but no need to enter any text leave screen blank
- Select Continue
- Select Addr. book look-up (can also state Contacts look-up): the screen now displays phonebook contacts
- Select More
- Select “Unsaved numbers”: displays dialled numbers for LND that had been deleted

There are some noteworthy points to consider:

a) the recovered numbers cannot have already been saved into either the Phonebook of the handset or *SIM;
b) there are no dates and times when numbers were dialled;
c) the unsaved recovered numbers appear in a random order.

*Checks were also made to ensure the recovered deleted numbers were not stored in 7F10 6F44 (EFLND) in SIM.

In recovering this information I found when conducting tests using handset readers *none* detected what may amount to important evidence. Most importantly, if produced in evidence (by one party against another) that failure to detect such evidence may suggest a systemic failure of practises/practices and/or procedures regarding the examination of this make and its various models.I do not think that the above analogy could be suggested as fair as an overall statement of affairs because:

d) the latest “w” range of SonyEricsson does not appear to have this functionality as far as I can tell, but further research is needed;
e) The English user manual for the K600i and K800i makes no mention of such a function, which I am describing as ‘recovery of data that may have evidential value arising from an undocumented functionality of a particular handset’. Thus, this matter needs to be considered on a case by case (model by model) approach.

Ultimately this finding underpins the principle that examiners cannot solely rely and transfer their responsibility onto so called ‘forensic devices’ to produce reliable findings, that human intervention is paramount when dealing with mobile telephone examination and evidence. My observations therefore do not rule out using forensic devices or software device readers that are used to recover data that are commonly served in evidence. The objective of raising this matter is one of awareness and that the skillsets required for manual examination must be retained.

**Note: I have been informed that the above routine doesn’t work on the SonyEricsson K850.

Discussion of this article can be found here


Malicious Phone Call Legislation in the UK

0
0

First published February 2009

by Greg Smith
Mobile Telephone Evidence & Forensics
trewmte.blogspot.com

It is being noted that there is an exponential growth in harassing and intimidating calls from financial companies, card companies and from outsource debt collection firms chasing payments where people have got behind with payment due as a direct consequence of this recession. Remember no one can plan for a recession, which in the UK was said to be unforeseeable because of the ‘no more boom and bust’ guarantee. For those who are made victims by people who seek to scare and frighten by making telephone calls I thought it would be useful to set out a list of some useful legislation associated with malicious, nuisance, threatening and harassing conduct that includes calls by landline or mobile ‘phone. Also some suggestions about services available from operators to deal with unwanted calls.

Legislation

- The Communications Act 2003
www.opsi.gov.uk/ACTS/acts2003/ukpga_20030021_en_1

- Telecommunications (Lawful Business Practice)(Interception of Communications) Regulations 2000 (“LBP Regulations”)
www.ico.gov.uk/upload/documents/library/data_protection/practical_application/coi_html/english/supplementary_guidance/monitoring_at_work_3.html

- Statutory Instrument 1999 No. 2093 The Telecommunications (Data Protection and Privacy) Regulations 1999
www.opsi.gov.uk/si/si1999/19992093.htm

- Regulation of Investigatory Powers Act 2000
www.opsi.gov.uk/acts/acts2000/ukpga_20000023_en_1

- Human Rights Act 1998
www.opsi.gov.uk/ACTS/acts1998/ukpga_19980042_en_1

- Data Protection Act 1998
www.opsi.gov.uk/Acts/Acts1998/ukpga_19980029_en_1

- The Privacy and Electronic Communications (EC Directive) Regulations 2003
www.opsi.gov.uk/si/si2003/20032426.htm

- Protection from Harassment Act 1997
www.opsi.gov.uk/acts/acts1997/ukpga_19970040_en_1#pb2-l1g8

- There is some useful advice from West Midlands Police, here at this link:
www.west-midlands.police.uk/crime-reduction/crime-victim-malicious.asp

Network Operator – Barring calls

If you have a BT landline, for instance, do remember they do have the service “Choose to Refuse” which can be dialled after an unwanted call. BT may charge a quarterly fee:

Dial ’14258′ followed by ‘*’ ‘*’. This is used where the Call Line Identification Number is displayed.

Where you receive malicious, nuisance, threatening and/or harassing calls from callers withholding their number, BT has the facility ‘Anonymous Call Rejection’:

- To Set Up (active): *227#
- To Cancel (deactivate): #227#
- To Check (whether service active): *#227#

Do check with your landline and mobile operator about services they may have in place to deal with unwanted called and, again, they may charge. For instance, for the mobile operators:

- Vodafone code for call barring is: 1919 (stated at their website)
- T-Mobile say call 150 from your mobile for assistance (stated at their website)
- O2 say call 100 from your mobile for assistance (stated at their website)
- Orange say call 150 from your mobile phone or 07973 100 150 from any phone (stated at their website)


Mobile Phone and GPS Forensics – Some Thoughts

0
0

First published February 2009

by Greg Smith
Mobile Telephone Evidence & Forensics
trewmte.blogspot.com

Mobile telephones are the predominate wireless telecommunications device throughout the world and most certainly in the UK they predominate other technologies, where ownership has reached well over saturation level when compared to the population number and mobile phone usage is embedded in UK culture. Global Positioning Systems (GPS) falls into the category of wireless communications that provides a ‘beacon’ service from which information can be derived, such as a reference clock and location coordinates. GPS is fast becoming an integrated service in mobile telephones and forms part of the forensics and evidence examination process.I have been in talks with Professor David Last, a specialist and expert in GPS forensics and evidence, for some while on the cross-connection between wireless modules that can be integration into mobile telephones and, in particular, GPS being such a module. The discussion has been directed towards interpretation of GPS data and the importance that once data has been extracted and harvested it is vital that interpretation of the GPS data needs to be accurate.

I have similar thoughts regarding mobile telephone evidence and I have raised them, in the past at my webblog, and recently published at my webblog discussion about Cell Site Analysis:

trewmte.blogspot.com/2008/11/csa-from-ockhams-occams-razor-to.html
trewmte.blogspot.com/2008/11/mobile-phones-and-fringe-coverage.html
trewmte.blogspot.com/2009/01/checking-masts-csa.html
trewmte.blogspot.com/2009/01/checking-masts-csa-2.html

There are many other discussions, too, at my webblog about SIM and mobile telephone examination where help and assistance has been given (free of charge and free of advertising I might add) to aid comprehension about mobile telephone evidence. Similarly, GPS must be taken seriously as people can lose their liberty and a whole lot more where evidence like this can add a contributory factor to the case against them. This matter will become more prevalent in the future as GPS modules are increasely being included in mobile telephones.

Market research from ABI indicates that shipments of GPS-enabled mobile phones will hit a speed-bump in 2009, but will still manage to post year-to-year unit growth through the current economic downturn. While global handset shipments are expected to drop by 4—5% in 2009, prior to 2009 GPS-enabled phones will show a climb to 240 million units, an increase of 6.4% for 2008. Moroever, Smartphones are expected to increase at an average 19% from 2009 to 2014 and it is predicted nine of every ten smartphones will contain GPS ICs in 2014, compared with one in three for 2008.Given these latest GPS statistics that have been released it is timely that Professor Last, the immediate past president of the Royal Institute of Navigation (RIN), should have his GPS forensics and evidence article ‘Silent Witness’ published in Navigation News (an RIN publication). I like the way David has woven in the use of computer forensics, which like mobile telephones, provides a complementary service to GPS devices for the data recovery process. Copying data though is simply not enough and the ‘Silent Witness’ article is strong on the importance of accurate interpretation of GPS data. A principle I wholehearted agree and why I have been promoting the importance of Mobile Telephone Forensics and Evidence Degrees.

David has kindly provided a copy of his ‘Silent Witness’ article that can be downloaded from Mobile Telephone Evidence at the link below:

www.filebucket.net/files/10614_ggvgt/pub356_scanned.pdf
Professor David Last ‘Silent Witness’
Navigation News January/February 2009
Pages 10-13

Thanks also to the RIN (www.rin.org.uk)


Recording Telephone Calls

0
0

First published March 2009

by Greg Smith
Mobile Telephone Evidence & Forensics
trewmte.blogspot.com

A question that often gets asked is “Can I record a telephone call?” and the answer to that is that you can (according to publicly available material), but conditions apply dependent upon the circumstances under which the recording is taking place and whether you intend to disclose part or all of the recording to a third party. There is a huge amount of information about recording of telephone calls in the workplace, too much to deal with here, so I have highlighted some reference material of which to be aware:

Recording Calls in the Workplace:

Telecommunications (Lawful Business Practice)(Interception of Communications) Regulations 2000 (“LBP Regulations”)
www.ico.gov.uk/upload/documents/library/data_protection/practical_application/coi_html/english/supplementary_guidance/monitoring_at_work_3.html

Statutory Instrument 1999 No. 2093
The Telecommunications (Data Protection and Privacy) Regulations 1999
www.opsi.gov.uk/si/si1999/19992093.htm

Regulation of Investigatory Powers Act 2000
www.opsi.gov.uk/acts/acts2000/ukpga_20000023_en_1

Human Rights Act 1998
www.opsi.gov.uk/ACTS/acts1998/ukpga_19980042_en_1

Data Protection Act 1998
www.opsi.gov.uk/Acts/Acts1998/ukpga_19980029_en_1

Moreover, a further web document worth obtaining from the OFCOM archive holding OFTEL’s web data is “47/99 19 August 1999 Recording telephone conversations on private networks”. OFTEL produced this document in response to a request from the Home Office to publish new guidance to companies covering their responsibilities about recording phone calls in the workplace for business purposes. Document 47/99 of the 19 August 1999 was published after the Human Rights Act 1998 was introduced and the successful employment case relating to an employee’s rights to privacy at work following the European Court of Human Rights (ECtHR) decision of June 1997 in the case of Halford vs UK.

Recording Calls for Personal Use:

OFCOM’s current general guidance on this matter is available from their website under ‘Recording and monitoring telephone calls or e-mails’. A general overview of interception, recording and monitoring of communications.

Specifically, the guidance poses answers to common questions about telephone calls. What is quite useful about the current OFCOM guidance is that it seems not to have changed from the original guidance OFTEL gave back on the 07/12/2000 in “Frequently Asked Question” that were published following the introduction of RIPA 2000.

Q: Can I record telephone conversations on my home phone?
A: Yes. The relevant law, RIPA, does not prohibit individuals from recording their own communications provided that the recording is for their own use. Recording or monitoring are only prohibited where some of the contents of the communication – which can be a phone conversation or an e-mail – are made available to a third party, ie someone who was neither the caller or sender nor the intended recipient of the original communication. For further information see the Home Office website where RIPA is posted.

Q: Do I have to let people know that I intend to record their telephone conversations with me?
A: No, provided you are not intending to make the contents of the communication available to a third party. If you are you will need the consent of the person you are recording.

www.ofcom.org.uk/static/archive/oftel/consumer/advice/faqs/prvfaq3.htm


Checking Masts – Cell Site Analysis (CSA)

0
0

First published March 2009

by Greg Smith
Mobile Telephone Evidence & Forensics
trewmte.blogspot.com

Since linking with Jamie Morris at Forensic Focus to create a Mobile Forensics Discussion Forumto bring mobile telephone evidence to a wider audience, I have had several discussions with people who are new to mobile telephone evidence and have asked me to provide further discussion on matters concerning Checking Masts. Also from police sections asking me to open up the discussion as to what might happen when Mast checks are not made and how that might impact on a criminal case. Whilst the criminal case discussion is hypothetical, some events happening in the discussion are factual and drawn from a number of criminal cases.The necessity to check with a mobile network operator regarding details of a particular Mast (Cell Site) and the bearing of coverage (azimuth) from it, for a particular Cell ID, at the material time to see whether it has changed prior to conducting cell site analysis is a useful rule to follow. There are, of course, many other matters that need to be checked also, but I have simplified the issues for the purposes of this discussion.

The details of Mast changes are recorded by Operators and recorded in their databases. Single Point of Contact (SPOC) is not prevented from asking an Operator about Mast details and obtaining the relevant information. However, as a SPOC doesn’t decide what evidence should or shouldn’t be required for a criminal investigation, the SPOC should be asked to obtain the Mast information.

The Masts

Below is an image (a) which displays a Mast’s radio coverage for a particular Cell ID illuminating in a westerly direction towards a block of flats.


Image (a)

The next image (b) below displays the same Mast (as above) relating to radio coverage with its associated Cell ID but this time the radio coverage is illuminating in an easterly direction, in the opposite direction towards a house.


Image (b)

For the purposes of this discussion the Mast is shown close to the properties in both images. This was done for artistic purposes and is not intended to mean the Mast is actually that close to both properties. Also an actual Cell ID has not been shown but the inference about Cell ID being relevant is inferred by the presence of radio coverage being displayed.

Criminal Case

Imagine if you will that on a particular date, let us say the 30th March 2008, a dead body is found in the house, shown in image (b). The police have been alerted to the property by a neighbour because of a dreadful smell emanating from the direction of the house. Upon entering the property the police find a decomposing body of a woman on the floor. The Pathologist is called and indicates, following assessment of the decomposing body, that the body had been dead for approximately two weeks. That would generate a time line back to Tuesday 16th March 2008.

The police conduct door-to-door enquiries and one neighbour next door but one mentions that two weeks ago as she passed the house there was shouting emanating from inside the property and cries for help. The neighbour thought nothing more of it because the couple that lived there had regular arguments, which the neighbours and passers-by could overhear.The police asked the neighbours had they noticed anything else? One lady who lived a few doors away replied that she looked out of her window and that she had seen the man that lived there leave the property at about 8.30pm, and that would have been a Tuesday, and funnily enough that was about two weeks ago.

To cut a long story short, the police found the man who lived in the house a month later, seized his mobile telephone and having retrieved his mobile telephone subscriber details, obtained call records and identified the Masts that routed mobile calls to and from his mobile phone. From the records it was noted that two weeks before the body was found his mobile had used a Mast for a call (on Tuesday at 8.00pm) the Mast was sited 2.4Km away from where he lived with his partner. This was also the nearest Mast to the house.

The police called for radio test measurements to be conducted outside the house three weeks later. The time-span from the estimated time of death to radio testing was approximately 9 weeks. The radio tests confirmed that the Cell ID recorded in the call records is the same as detected outside the house.

The man, during questioning, confirmed he had not been back to the house since leaving on the Saturday. That being the Saturday prior to the Tuesday when it is approximated the death took place. He had also been living in a Bedsit because the relationship with his partner had irrevocably broken down and they had agreed to split and go there separate ways.

The police believed from the evidence that they had thus far that it was enough to hold the man, now a suspect, and the death case turned into a murder case. The evidence they relied upon was:

1) The neighbours hearing regular arguments and cries for help on the fateful day
2) The neighbour that says she saw the suspect leaving the house at 8.30pm
3) The call records that shows a call on the Tuesday from the suspect’s mobile telephone using a Cell ID from a Mast that is sited 2.4Km away and is the nearest Mast to the house
4) The radio test measurements that show the Mast’s coverage, thus Cell ID, used by the suspect’s mobile phone illuminated outside the house.

So at minimum there appears to be four good pillars of evidence. However, when the radio test measurements were conducted no checks had been made with the mobile operator whether any changes had been made to the Masts in the area prior to radio test measurements being conducted. It subsequently came to light at trial that the Cell ID illuminating towards the house (image (b)) had only been illuminating eastwards towards the house from Thursday 18th March 2008 after the alleged murder due to changes at the Mast. Prior to that date the Mast had been illuminating westwards, towards a block of flats (image (a)).

Impact on Criminal Case

So when the police had noted from the suspect’s call records that over the last few months they showed the suspect’s mobile phone using a particular Cell ID for mobile calls that the police thought could be made or received from the house, they were mislead and operated under a false assumption. The suspect had, in fact, been having an affair with a married woman in the block of flats (image (a)) and didn’t want to say anything for fear of reprisals from the woman’s husband who was known to have a temper and may take it out on the woman if she was called as a witness. It was this affair that the victim, when she was alive, and been tipped off about some months earlier and the cause of the couple constantly arguing.

The lack of discovery about any changes to a particular Mast prior to conducting radio test measurements impacted on the case by:

- the test results, that should add value to a case, were inaccurate and unhelpful
- introduced delays into an investigation as the test results steered the police investigation in the wrong direction
- operational man-hours increased
- operational costs increased
- worst still, a false allegation of murder was made against an innocent person

As to the other pillars of evidence: 3) and 4) were no longer valid and the woman with whom the suspect was having an affair corroborated the dates and times she was with the suspect. As to 1) and 2)? On the fateful day, 1) the argument that was heard by a neighbour turned out to be the victim’s ex-boyfriend from a previous relationship whom she had given evidence against him for drug dealing, some 5 years earlier, and who had been released from prison 20 days before the murder. He had vowed to seek revenge against the victim. 2) The neighbour who saw the suspect at 8.30pm at night in fact saw a silhouette of the man she thought was the suspect because it was 8.30pm at night and her eyesight wasn’t as good at night. The silhouette leaving the house was the ex-boyfriend leaving after having murdered his ex-girlfriend.

Further Observations

In consequence, by not checking with the operator about their Masts prior to conducting radio test measurement caused lost investigation time to find the real culprit, unnecessary redundant evidence, increased costs, investigation time increased exponentially, apart from wrongly accusing a person. Moreover, as checking the Masts is a well known procedure, not to have checked it during an investigation may amount to act of intent to plant evidence to create incrimination against someone by using an act of deliberate omission during an investigation.

This is only a hypothetical discussion, but if these acts were operated in reality on a regular basis in criminal cases and applied as policy in widespread use across England, it may potentially lead to £20 millions in retrials. Of course that shouldn’t be possible arising from the ‘Golden Rule’ of disclosure, enunciated by Lord Bingham in R -v- C & H (February 2004), when he said that ‘fairness requires that full disclosure should be made of all material held by the prosecution that weakens its case or strengthens that of the defence’. The test is an objective one and is grounded on what is ‘reasonable’. However, the guidance makes it plain that an expert witness is no longer to be trusted to exercise his or her own judgment in deciding what falls within this definition and what is and is not relevant.

It is the influence of the Golden Rule placing affirmative duties on the prosecution from 2004 onwards that safeguards the reliability of evidence in criminal cases. That suggests were Her Majesty’s Inspectorate called upon to require the prosecution tomorrow to provide, from randomly selected 200 cases from across the country by the Inspectorate, documents of enquiry to a particular operator seeking to be notified of any changes to a particular Mast in a particular case and the documented response received from the operator, they could do so.

That doesn’t mean to say if the prosecution mobile telephone case has 50 Masts used for calls that documentation for each of the 50 Masts would be necessary, as rarely are all Masts relevant to an alleged crime, anyway, and a large proportion being used for padding simply to show movement. The relevant Masts are those where the Masts and coverage can illustrate that the mobile telephone or telephones could potentially be at the scene of crime, which on the whole usually relates to the last three to six Masts nearest the scene of crime. Besides I couldn’t see the prosecution being hoodwinked into believing that because there are 50 Masts in a case that the number amounted to far too many enquiries to be made to the operator and so didn’t make any enquiries at all.

As I have mentioned above this is purely hypothetical, but hopefully it illustrates the importance of Checking Masts before conducting radio test measurements.

Discussion of this article can be found here


Experimental Testing Of A Forensic Analysis Method On The Tomtom GPS Navigation Device

0
0

First published June 2009

by Dr. Clara Maria Colombini

INTRODUCTION

The earliest Satellite Navigation Systems were designed for the U.S. military, to locate the position of Polaris submarines. Over the years, satellite detection technology has become extremely widespread, and today most automotive vehicles are fitted with such systems. TomTom, the in-car satellite navigation device, is connected with the U.S. NAVSTAR Global Positioning System (GPS), which utilises 32 satellites in Mid-Earth Orbit (MEO) positioned in six different orbital planes.

The TomTom device itself contains an ARM processor made by Samsung, using Linux to manage the software which – depending on the device – can read either an SD card or the internal memory. A bootloader in the computer searches the hard disk or SD card for the software and map data. It then transfers the software to the 64MB internal RAM memory and starts the software.

The hardware itself starts the GPS and the navigation application. The navigation application then reads whatever settings have been installed, such as the preferred voice and last chosen route.

TomTom internal architecture

The integrated GPS module ensures that the satellite signal translates into coordinates pinpointing the user’s exact position on the map. After start-up, the GPS module calculates the user’s position from the nearest satellite signals it receives; the module works out its position by calculating its distance from at least four different satellites, which send out information such as identity, altitude, position in relation to other satellites, etc.

The latest models feature RDS-TMC technology. The “Radio Data System-Traffic Message Channel” is a service providing real-time traffic information integrated in the device via a special receiver. The service provider encodes the message and sends it to FM radio transmitters which transmit it as a Radio Data System (RDS) signal alongside regular FM radio broadcasts. The TMC decoder inside the TomTom decodes the RDS signal into visual and/or spoken message on the device.

Bluetooth enabled models allow TomTom to communicate with other electronic devices like mobile phones, operate as a hands-free speakerphone, or receive information sent to a mobile phone via a wireless connection such as GPRS (General Packet Radio Service) or UMTS (Universal Mobile Telecommunications System).This work presents research into a forensic analysis procedure on TomTom satellite navigation devices, which are able to detect extremely useful information for investigative purposes. Information such as stored addresses, itineraries, home, points of interest, etc. enable the device user’s travels, favourite itineraries and most frequent destinations to be reconstructed. The main focus of the experiment was to develop a procedure for creating a “repeatable” forensic image of the internal memory, so that an identical forensic image can be produced at any time and can be used for analysis or as exhibits.

DEVICES ANALYSED

The following models were analysed:

1. TomTom One with 1GB internal memory only – 2006 model;
2. TomTom One with 2GB internal memory only – 2008 model;
3. TomTom One with external SD memory card only – 2006 model;
4. TomTom One XL Italy with 512MB internal memory + SD Card – 2008 model;
5. TomTom Go 730 with 1GB internal memory + SD Card – 2008 model.

CREATION OF THE FORENSIC IMAGE

It should be noted that regarding the PC connection, the experiment did not consider the procedure for generating a forensic image of the SD memory card which can be removed from the device and can be treated like any other mass storage unit as per Computer Forensics rules.

The term “forensic image” as used herein refers to the result of a special copying procedure known as “bit by bit”, i.e. a system that scans the entire surface of the master hard drive one bit at a time, producing a clone, i.e. an identical copy, on a destination drive whose contents will be analysed. Whenever possible, forensic analysis is not conducted on the original device but rather on its “clone”, or bitstream image, so as to preserve the integrity of the original evidence for any future analyses. Three forensic images were produced for each of the four models examined (one for each PC), for the following aims:

1. since there was no “original” image available, i.e. one that was “definitely unaltered” against which to compare the images produced using this experimental method, which would have required an invasive procedure physically parallel to the memory chip, the first image generated was used as the starting point, and any changes observed during the tests were checked against the other two;
2. three different PCs were used to simulate different scenarios (e.g. counter-reports, analyses at a later time, etc.)

In order to provide a sufficiently broad overview, forensic images were created using:

Personal Computer running Windows OS;
Personal Computer running Linux OS.

PROCEDURE IN WINDOWS ENVIRONMENT

The procedure for creating the three forensic images was carried out on three different PCs:

1. PC workstation running Microsoft Windows XP PRO SP3;
2. PC notebook running Microsoft Windows Vista Home Edition;
3. Eee PC running Microsoft Windows XP Home Edition.

Software:

Accessdata FTK Imager 2.55 (free download).

Please note that it was not possible to use the hardware write blocker provided (Tableau T8) since when connected the PC does not recognise the device ( TomTom -> T8 -> PC).

PREPARING THE PC

The first step was to ensure that TomTomHOME software was not installed on the PC (for automatically updating TomTom data), or that the registry file did not contain keys or voice files from previous TomTom installations:

SOFTWARE registry file;
SYSTEM registry file: no entries relating to previous installations of TomTom USB drivers must be present in the CONTROL SET sub-key…..\ENUM\USBSTOR.

It is essential to carry out these checks because as soon as TomTom is connected to the PC it will try to update its data, searching for the software and registry keys signalled on the PC, and this will alter its files. Since no hardware write blockers can be used, the USB ports have been configured as read-only, creating a special registry entry to disable the write option command on the peripherals connected to the PC via the USB ports. The PC was disconnected from the Internet so as to prevent accidental attempts to update the device.

Regarding storage of the forensic images obtained, a new 50GB firewall was created on each of the three PCs, then (procedure for permanent deletion of files from memory card by overwriting with spurious data until all traces are eliminated) wiped and formatted in Fat32.

CONNECTING THE DEVICE TO THE PC

Material used: mini USB cable for TomTom
Environment: the analysis was conducted in a closed room to prevent the TomTom device from locating the satellite.

The most sensitive part of the whole experiment was connecting the device to the PC so that the operating system “recognises” the TomTom’s internal memory without modifying the data stored within the memory, including the relevant “metadata”, i.e. other data describing this information, such as dates of creation, modification and access, as well as size, etc.

The connection procedure varies from model to model: each model behaves differently depending on whether or not there is an SD Card slot.

The direct analysis of the model with the SD Card only was performed according to Computer Forensics rules.

The TomTom device has to be connected to the PC’s USB port and turned on, so in order to detect any changes to the data present when the drivers are installed, communication flows via USB between the TomTom and the PC were monitored throughout the connection procedure. The analysis was carried out using a specific tool, SysNucleus USB Trace v. 2.0.

MODELS WITHOUT SD CARD SLOT

MODELS TESTED:

Tomtom One with 1GB internal memory only – 2006 model;
Tomtom One with 2GB internal memory only – 2008 model.

CONNECTION

The PC is turned on and the operating system started up.

Monitoring is started on the data flow via USB on the port chosen for the connection.

Before turning the device on it is connected to the PC using the relevant cable. The TomTom is turned on. The screen illustrated below appears on the device:

Click on “YES”. The image below will now appear on the screen, indicating that the connection has started.

Once the connection has started, the screen below appears.

The computer signals that it has found a new USB device, installs the drivers and assigns a disk drive letter to the new peripheral device.

The same procedure was used for the three different PCs used.

The analysis of the data produced by monitoring the communication flows via USB between the TomTom and PC during the connection and installation of the drivers of the devices evidenced that no changes were made to the data contained in the device.

CREATION OF THE IMAGE

The forensic image was made on the three different test PCs using FTK Imager Accessdata v. 2.55, which calculates the Hash (see note 2) MD5 and SHA1 both of the original (see note 3) and the new image created, and verifies that it is an exact copy.

The new UBS peripheral is selected as the source and the DD image format (not processed) is chosen.

Destination unit: the ad hoc partition created on the PC.

The procedure is the same on all three PCs utilised.

RESULTS

An examination of the Hash MD5 and SHA1( see note 4) files, which are identical, confirms that the three images created for each of the 4 devices are exactly the same and there has been no change to the data in the flow that the TomTom generates when connected to a Windows system.

The comparison was made using MD5summer v. 1.2.0.11.

In any case, as noted above, it is always essential to turn on the device since our intention was to conduct a “non-invasive” analysis, without having to open the device and/or remove the internal memory.

2 “Hash” means the hash calculated on a data flow determined after two intelligent systems (with CPU) have joined on a communications protocol.

3 “Original” means not the original data stored on the device, but the original data flow leaving the device when it connects with a Windows system.

4 Hash algorithms are a kind of “footprint”, that univocally distinguishes all electronic trace of the forensic analysis so as to comply with data integrity requirements. This “digital watermark” is produced by “one-way hashing” (e.g. MD5 and SHA1) which generates unmistakable reference to the original trace but does not allow it to be reconstructed. These algorithms are utilized internationally and ensure a satisfactory level of security/safety.

MODELS WITH INTERNAL MEMORY + SD CARD PORT

MODELS TESTED:

TomTom One XL Italy with 512MB internal memory + SD Card – 2008 model;
TomTom Go 730 with 1GB internal memory + SD Card – 2008 model.

Additional material used: pre-wiped SD memory card5.

CONNECTION

If the TomTom device has an SD memory card slot, a preliminary operation is needed before connecting to create the forensic image, since there are two ways to connect this type of device to a PC.

- without an SD card inserted in the slot:

the device goes into “update” mode and looks for the TomTom Home software on the PC for automatically updating user data on the Internet. When it fails to find the software the device tries to install it (the device software includes a compact self-installing version TomTom Home). The PC recognises it as a navigation device and installs the data update drivers. In this mode, certain files on the device are automatically updated and therefore changed. This is confirmed by analysing the data produced by monitoring communication flows via USB between TomTom and PC, using the SysNucleus USB Trace v. 2.0 tool, during the connection of each device as described here.

- with SD Card inserted:

the device goes into “USB peripheral” mode and as such is recognised by the PC which installs only the USB connection drivers.

No communication is attempted to update the TomTom data and the TomTom Home software is not searched for on the PC, so the files stored within the device are not changed; the machine only reads the contents of the SD Card, which is assigned an external hard drive letter. An analysis of the information generated by monitoring communication flows via a USB between the TomTom and the PC, using SysNucleus USB Trace v. 2.0 during the connection and installation of the device drivers, confirms that the data stored in the device has not been changed.

With the information thus acquired, a connection is made as described below, which turns out to be ideal for enabling the PC to detect the content of the internal memory.

After deleting all traces of the previously installed TomTom drivers from the PC, the device, still off, is connected to the PC via the mini-USB cable.

The new “forensic” SD Card is inserted (see above: additional material used).

 

The device is then turned on. The image below shows the TomTom screen during connection.

 

The TomTom screen shows that the device is connecting: the device is in USB mode and the PC views the content only of the SD Card, to which the operating system assigns an external hard drive letter. Once the USB connection drivers are installed, the device is switched off, the SD Card removed and the device is switched on again. The TomTom screen again shows that the device is connecting.

The computer does not need to recognise the peripheral device again, as it already has the drivers, and views the data contained in the internal memory of the external hard drive previously assigned to the SD Card.

IMAGE CREATION

At this point, the forensic image is created on the three different PCS, using FTK Imager by Accessdata v. 2.55 software.

The physical unit of the new UBS peripheral is selected as the source and the image is chosen in DD format (not processed). The destination drive is the partition created ad hoc on the PC.

The same procedure is run on the three different PCs.

RESULTS

The Hash MD5 and SHA1 (see note 6) files are identical, confirming that the three images generated for each of the 4 devices are exactly the same; the data flow generated by the TomTom when connected to one of the Windows systems has remained unchanged.

The comparison was made using MD5summer v. 1.2.0.11.

In any case, as observed, the device always has to be switched on, since the analysis in question is “non invasive”, and as such does not require the device to be opened and or/ the internal memory removed.

6 Hash algorithms are a kind of “footprint” univocally distinguishing the electronic trace of the forensic analysis, so as to preserve data integrity. The “digital watermark” is created via a one-way hashing operation, (e.g. MD5 and SHA1), which generates a “footprint” that refers exclusively to the original trace, but does not enable it to be reconstructed. These algorithms are used internationally and ensure a satisfactory level of security.

RUNNING THE PROCEDURE UNDER LINUX

Again, the procedure was carried out on three different computers.

1. PC workstation with Linux Fedora v. 10 operating system;
2. PC notebook with Linux Helix v. 1.9 operating system, running live (see note 7) from CD;
3. Eee PC with Linux NBCaine v. 0.5. operating system running live from USB device.

CONNECTION

Under Linux, there was no need to adopt different connection procedures for the various models of the device.

Before switching the device on it is connected to the PC using the mini-USB cable. The device is then switched on.

The Linux operating system recognises the device as a USB memory peripheral.

It is not necessary to “mount” (see note 8) the TomTom, which stays on read-only.

Instead, the image destination device is mounted and set to read-write.

IMAGE CREATION

The forensic images are then created in “DD” format, using the software packages listed below:

1. Linux Fedora v. 10: command line procedure via console (see note 9);
2. CD Helix Live 3: ADEPTO 2.0;
3. USB NBCaine: AIR 1.2.8.

7 Live mode allows an operating system downloaded directly to memory from a CD or USB flash drive to be used, without the need to rely on the hard disk(s) present on the machine.

8 Mounting enables a block peripheral to be initialised to permit read/write access.

9 Console mode is an alternative to graphics mode in which commands are facilitated by a graphical interface with buttons and windows. In consoled mode, commands must be written with no intermediation needed.

COMMAND LINE PROCEDURE

The mount command is used to check that neither of the two drives (the source disk drive, i.e. the TomTom internal memory, or the partition chosen by us to store the image) has been automatically mounted, and then the partition destined to store the forensic image is mounted in read-write; the original disk is NOT mounted because the data is read directly from the device with the copy command.

# mount -o rw /dev/hdb4 /media/hdb4

Before copying, the destination device is wiped to delete any previously stored data. The following command can be used to complete the operation:

# wipe /media/hdb4

The original is hashed using the DD command, specifying only the input file and sending the output of this command in pipe (see note 10) to an md5sum (execution of MD5 hash).

# dd if=/dev/hda1 | md5sum

The image is then created: the simplest form of the DD tool is used for the copy. The command syntax requires an input file and an output file to be specified.

# dd if=/dev/sdb1 of=/media/hdb4/tomtom01.img

At the end of the operation, the command returns the number of read and written records, with a few statistics on bytes copied, total operation time and average transfer rate of the process. The image created using the DD command is hashed, specifying only the input file and sending the output of this command in pipe11 to an md5sum.

# dd if=/media/hdb4/tomtom01.img | md5sum

10 In UNIX the pipe is a mechanism for controlling information flows. In other words, the pipe is a system for using outgoing information flows from one command as input for another command.

PROCEDURE VIA AIR (AUTOMATED IMAGE & RESTORE) TOOL

There are obviously pros and cons with using a command line tool; the main advantage is that there is total control over each individual instruction imparted, including the ability to directly specify which options and parameters to use for each device; conversely, the complexity of the commands and the different number of options may easily generate mistakes.

However, the Helix and Caine distributions overcome these difficulties with a series of graphical interface tools allowing the operator to exploit the usability of the window interfaces.

Below is the procedure made for creating forensic images using the AIR (Automated Image & Restore) tool, included in the Caine distribution.

First select the source device on the left hand side of the template, and the destination device on the right.

Next, select no image compression.

Then select the type of hash to use for verifying the identity of the original and the copy. Here DCFLDD (see note 12) is been selected instead of DD.

This option does not branch the image into different files and does not encrypt the file with a key.

Then check the noerror option on the conv parameter, which continues the image creation operation even in the event of read errors.

Before pressing the start button and beginning the copy process, click on the show status windows button to see how the operation is progressing.

12 DCFLDD is used to perform certain operations; the advantage is that it calculates hashes concurrently with the creation of the copy, eliminating the extra step needed when using DD.

RESULTS

An inspection of the Hash files, which are identical, confirms that the three images generated for each of the four devices are exactly the same and that there has been no change to the data they contain.

In any case, as observed, the device always has to be switched on, since the analysis in question is “non invasive”, and as such does not require the device to be opened and or/ the internal memory removed.

ANALYSIS

The memories on TomTom devices (both the internal memory and the SD Card) behave just like any other digital memory insofar as they can store, conceal and delete files of any kind.

The TomTom memory creates forensic images “bit by bit” so that all the data stored can be analysed; even deleted or fragmented data can be carved (see note 13) out with the use of special forensic software.

The tool used to perform the analysis was AccessData FTK 2.2 running Windows; it can view the contents of all files present, including the relative meta-data, and recover deleted or fragmented files. However, for the purposes of an investigation seeking satellite navigation data using the device, only the relevant files are listed below.

TTGO.BIF Contains information concerning the device, including: model, serial number, language, current map, current base map, voice. Below is an example of file content from which this information can be gleaned.

[TomTomGo]
DeviceName=TomTom ONE XL
DeviceVersionHW=ONE XL
DeviceSerialNumber=L26497J00167
DeviceUniqueID=AK8AG AADSW
RamDiskVersion=20080529
BootLoaderVersion=53026
LinuxVersion=190943
ApplicationVersionVersionNumber=8010
ApplicationVersion=9369
UserLanguage=Italiano
UserName=L26497J00167
LastConnectionTime=Never
GPSFirmwareVersion=
BuiltInColorScheme0=Belgica
BuiltInColorScheme1=Brittanica
BuiltInColorScheme2=America
BuiltInColorScheme3=Germanica
BuiltInColorScheme4=Australia
BuiltInColorScheme5=Deuteranopia
BuiltInColorScheme6=Greys
BuiltInColorScheme7=Antarctica
BuiltInColorScheme8=Africa
BuiltInColorScheme9=Astra
CurrentColorSchemeBuiltIn=1
CurrentVoiceInfo=Roberto
CurrentMap=Italia
CurrentMapVersion=710.1571
CurrentHomeLocation=45.53052,9.03387,Via Francesco Daverio 11, Milano
Traffic=N
13 Data carving is a technique for recovering deleted or de-allocated files.
CurrentFuelpricesType=
CurrentFuelpricesTypeString=
CurrentFuelpricesLastFullUpdate=
ValueRatio=BpHDxKhXmBZzHUCpsA==
Features=PlusDownloadDynamic,PlusDownloadGeneral,PlusDownloadMap,PlusDo
wnloadPOI,PlusDownloadScheme,PlusDownloadUpgrade,PlusDownloadVoice,Plus
DownloadRingTone,PlusMessageNotification,PlusPushChannel,PlusTraffic,PlusWe
ather,PlusEphemeris,PlusBuddies,PlusMobileSafetyCameras,PlusRoadConditions,
PlusFixedSafetyCameras,PlusFuelPrices,HDTraffic,PlusOnlineCamera,PlusTripRep
orting,HomeBackup,PhotoJPGViewer,PhotoBMPViewer,Newyork,Newyork1Dot6,Iti
nerary,Caymann,Durham,PhoneFeatures,CarSymbol,RDSTMC,Prague,Bluetooth,S
DSlot,InternalFlash
SupportedPatchTypes=1F
NrSupportedErrorTypes=132
UserPatchDatVersion=102
CompressedPatchVersion=150
MapServerPatchDatVersion=104
DeletedPoiDatVersion=200
ServerLineIndexDatVersion=102
ServerNameIndexDatVersion=102
MapShareSupportedProviders=203
CharacterSet=Latin-1

CURRENTLOCATION.DAT Contains the latest position of the device
CURRENTMAP.DAT Contains the current map
GPRSETTINGS.DAT Contains the GPRS configuration (if present)
SETTINGS.DAT Contains the name and MAC Address of any telephone connected, wireless settings, provider data, and user telephone data, if entered (GO models only)
GPRS.CONF Contains the GPRS PIN number (if entered) (GO models only)
MAPSETTINGS.CFG Files with a “CFG” extension, such as “mapsettings.cfg” or “name_map.cfg” are all contained in the folders of the relevant maps and contain all the information on “Favourites”, itineraries, addresses , and points of interest stored.
\CONTACTS\CALLED.TXT Contains telephone numbers called from the telephone connected to the TomTom (GO models only)
\CONTACTS\CALLERS.TXT Contains the telephone numbers that have called the telephone connected to the TomTom (GO models only)
\CONTACTS\CONTACTS.TXT Contains the contact list of the telephone connected to the TomTom (GO models only)
\CONTACTS\INBOX.TXT Contains text messages received from the telephone connected to the TomTom (GO models only)
\CONTACTS\OUTBOX.TXT Contains text messages sent from the telephone connected to the TomTom (GO models only)
NOMEFILE.ITI Contains stored itineraries
TEMPORARY.ITI Contains itineraries not stored with a filename

Depending on the model, certain files may be missing from the device.

This table reports some differences among different models.

 

RECENT DESTINATION BIF FILE SETTING FILE CALLED FILE CALLS FILE INBOX FILE OUTBOX FILE
TOMTOM ONE REGIONAL YES YES NO NO NO NO NO
TOMTOM ONE EUROPE YES YES NO NO NO NO NO
TOMTOM GO 510 YES YES YES YES YES YES YES
TOMTOM GO 710/720/730/750/790 YES YES YES YES YES YES YES
TOMTOM GO 910//920/930 YES YES YES YES YES YES YES
TOMTOM NAVIGATOR 6 YES YES NO NO NO NO NO

SPECIFIC TOMTOM ANALYSIS SOFTWARE

There are various software packages on the market for analysing TomTom navigation files. POIedit is a shareware programme that runs under Windows, for reading DAT files.

It is interesting because it can identify and view the exact locations of addresses stored in the “mapsettings.cfg” file on GoogleMaps (an Internet connection is required).

The figure below pinpoints the geographic location of addresses contained in the “mapsettings.cfg” file.

BIBLIOGRAPHY

1. C.M. Colombini, Y. Corio, La corretta gestione di un incidente informatico e alcune ipotesi di linee guida per le operazioni di forensics. La Dead Analysis. White Paper, Corso di Perfezionamento in Computer Forensics e Investigazioni Digitali, AA 2007/2008.

2. B. Nutter , Pinpointing TomTom location records: A forensic analysis. 2008 Elsevier Ltd.

3. Peter Hannay, A Methodology for the forensic acquisition of the TomTom One satellite navigation System – A research in progress, Edith Cowan University, 2007.

4. A.K. Theiss, DD.CC. Yen, C.Y. Ku, Global positioning systems: an analysis of applications, current development and future implementations. Computer Standards & Interfaces, 2005.

5. SEC.AU, Edith Cowan University

6. ACPO (2003). Good Practice Guide for Computer based Electronic Evidence 3.0. Retrieved 16 Oct, 2007.

7. P. Hannay, A Methodology for the Forensic Acquisition of the TomTom One Satellite Navigation System–A Research in Progress. Paper presented at the 5th Australian Digital Forensics Conference, 2007.

8. A. K. Theiss, D. C. Yen, & Ku, Global Positioning Systems: an analysis of applications. 2005.

9. http://www.marcomattiucci.it.

10. http://ww.tomtom.com

11. http://www.GPSforensics.org

12. http://www.forensicswiki.org/wiki/GPS

13. http://www.symbian.com

14. http://www.samsung.com/global/business/semiconductor/productInfo.do?fmly_id=229&part num=S3C2443

15. http://www.maerco.it/index.php/2007/01/03/open-tom-tomtom-opensource/

16. http://www.opentom.org/Main_Page

A special thanks to the Major Marco Mattiucci, Commander of the RTI – Reparto Tecnologie Informatiche – RACIS Roma – Arma dei Carabinieri.

Dr. Clara Maria Colombini
Email: clara.colombini@email.it
LinkedIn: www.linkedin.com/in/claracolombini


Challenges of Smart Phone Forensics

0
0

by Rob Adams ACE, CDIA+
SALIX

Mobile devices have become an essential component of our daily lives. These devices keep us connected and act as so much more than the cell phones and portable music players of the 1990′s. It is common today for a smartphone to act as a mobile office, social tool, and an entertainment center all rolled into one. Many households have one or two computers shared by the inhabitants, but almost everyone over 16 has a cell phone and, since the device is tied more closely to the user, the data is also.Today’s smartphones come with storage capacity that is similar to business laptops of just a few years ago. The combination of functionality and storage space makes smartphones a prime target for forensics investigators.

Data commonly found on Smartphones

Email
Text Messaging
Photos
Video
Audio
Web History
Call History
Application Data
eBooks
Maps

With additional functionality being added almost daily, smartphones are a rapidly changing environment which presents several challenges to a forensic investigator.

OS Changes

Unlike the windows world where major OS (Operating System) changes are rare smartphones receive frequent major OS updates. Windows XP was sold on new computers from 2001 thru the end of 2009 and is still in widespread use in both the home and business markets. As you can see from the table below, the iPhone IOS (iPhone Operating System) has had major releases annually. Major releases for one Smartphone OS or another are happening nearly every quarter.

iPhone IOS Version History

 

Version Release Date Number of Updates
1.x Initial Release June 2007 8 Updates between June 2007 and July 2008
2.x Second Major Release July 2008 6 Updates between July 2008 and January 2009
3.x Third Major Release June 2009 5 Updates between June 2009 and February 2010
4.x Fourth Major Release June 2010 6 Updates between June 2010 and November 2010

Proprietary Hardware

In the windows forensic world, you can connect to most hard drives with a small number of adapters based on the type of hard drive – 3.5″ IDE, 2.5″ IDE, SATA, SCSI. On smartphones you may have to have a special data and/or power cord for each one as well as the drivers for the particular device. I have over 200 power and data cord combinations in my tool kit. Some devices only allow you to access logical information and may block access to the system databases and unallocated space.

Frequent Hardware changes

Another challenge is the speed at which mobile devices are replaced. Most people get a new phone every two years when their plan renews and some people get new phones annually. In addition, cell phones are replaced because of loss or damage at a much higher rate than computers.

Data Volatility

Smartphones add another consideration with regards to the seizure of any given device. It may be necessary to keep a seized device powered up until the analysis is complete in order to prevent loss of important data that may be changed or overwritten when the power shuts off or the device is rebooted. You may also need to keep the device in a faraday bag, (a bag made out of material that blocks cell phone signals) to prevent any deleted evidence from being overwritten on the device.

Other places to look for corroborating data

You may also be able to find relevant data on computers used to sync the devices. Most sync programs create a full or partial back up of the device when updating the OS. These backups can come in handy when items have been deleted and/or overwritten on the device itself.

The most frequent questions I receive from attorneys about retrieving deleted data from smartphones are based around what data may be available from the Carrier or servers and how hard is it to get it.

Email messages are usually passed to the device via a server outside of the Carrier’s control, for example Mobileme, Gmail, Yahoo, or a corporate server.

SMS and MMS text messages are delivered through the carrier’s network, but most networks do not keep records of the contents. They do keep billing, and call records. The call records will contain the date and time of the incoming and outgoing message as well as the other parties phone number.

All of these service providers have a process for obtaining this information. Some require written authorization from the account holder and others require a subpoena, but all of them will have a process you must follow to obtain the relevant data. The best place to start is usually with their legal or security department. Below is the contact information for AT&T Wireless. Other ISP and Wireless Carriers’ subpoena contact may be found at http://www.search.org/programs/hightech/isp/

AT&T Wireless Subpoena Contact Info

AT&T Wireless Subpoena Compliance
Address to: AT&T – Custodian of Records
P.O. Box 24679
West Palm Beach, FL 33416-4679
Phone Number 800-635-6840
Fax: 888-938-4715

Tips for Investigators

· As with any forensic investigation – start with and maintain a strict chain of custody.

· Know the limitations of your forensic software – some software packages work well with one type of phone and not others. For example, with the advent of IOS 4.x for the iPhone, most tools cannot create a physical image without jailbreaking the device.

· Know where to go for research on various phone types and their potential forensic yield. The forums on www.forensicfocus.com are a great place to start.

· Tool Kits – a subscription based kit is a good idea as they will generally keep you current with frequent cord and driver updates, as well as providing you access to technical support. Paraben’s Device Seizure and AccessData’s Mobile Phone Examiner both offer subscription based kits.

Rob Adams ACE, CDIA+
Web: www.salixdata.com
Email: radams@salixdata.com

Rob is a Computer Forensics professional with 16 years of experience in the IT field. SALIX is a leading Litigation Support and Records Management company headquartered in Cincinnati, OH.



Geotags: Friend or Foe?

0
0

by David Benford
Director, Blackstage Forensics

I recently wrote a research paper, “Geotag Data: The Modification of Evidence on the Apple iPhone”, based around the possibility of modifying geotag evidence on the Apple iPhone. A test was performed as part of this project, to find out how easy it is to discover a person’s home location, social and business movements and background information.The process was begun by doing a Google Image search for the criteria “Blog iPhone self taken”. This was to trace an image taken by an iPhone for a personal blog, which would hopefully be of the user, hence “self taken”. In Google “Advanced Image Search” some changes were made, such as “Tall Image” and “JPG” file type being ticked; the theory being that most iPhone images are of portrait type and JPG format. An image appeared that seemed suitable of a woman photographing herself at the hairdresser’s. The image was saved and opened in TAGView which showed the location of the shop to be in a specific street in Oregon. As there is only one hairdresser listed in this street the process of selecting the correct business was straightforward. The image linked through to the woman’s blog and by doing a search, several more images taken on her iPhone were found complete with geotag data. The woman had taken a photograph of a magazine, mentioning that she was reading it at the dentist’s surgery. The surgery could be located within a minute and was found to be around the corner from the hairdresser’s shop. There was an image of a cake, along with its geotag pointing to Walmart. There was an image of her foot, taken in her kitchen, and the geotag gave an approximate location of where she lived. Images on the blog that were taken on her drive had no geotags. With an approximate idea of her home address, these could be used to pinpoint the exact property by viewing Google Street View. There were also non-tagged images of her family, giving further personal information. In the side margin of the blog there was a link to her Twitter page. Twitter displayed her actual name, where she was at any time and gave an even more detailed pattern of her movements, social life, family’s sports and hobbies, dining out preferences and so on. All of this information was derived from the source of just one geotag within a JPG image. This woman was potentially not only putting herself at risk, but also her family.

There appears to be many arguments on the web that the geotag feature being activated as default is not a well known fact amongst users. A very recent article published by the International Computer Science Institute in America supports this argument, along with the theories of the potentially dangerous nature of publishing data with embedded geotags. The authors, Gerald Friedland and Robin Sommer argue that websites such as Flickr having APIs which allow easy researching of specific criteria such as time, place and date can place unsuspecting users in a potentially vulnerable position, (Friedland & Sommer, 2010).

There is a strong possibility that similar search techniques could be adopted by paedophiles to discover the locations of young children. Innocent images, incorporating geotags, of children may have been taken by their family and uploaded to a blog for sharing with friends and family. There are many blogs that link through to social networking accounts that, when used together with the geotags, can assist in presenting a relatively clear picture of where a family lives, goes on holiday, works or socialises away from home, or can provide travelling times and school details. There are many cases of similar details being used by criminals for cybercasing and cyberstalking, as websites such as ICanStalkYou.com (URL no longer active) have highlighted.

There may also be an argument against the geotagging of images of endangered animals and birds. Geotagged online photographs of, for example, a rare bird sitting in its nest, could leave the bird vulnerable to poachers, egg collectors and hunters. With the availability of cameras, such as the Fujifilm Finepix XP30, that have in-built GPS, the proliferation of geotags may increase. With the XP30 being waterproof, it is particularly suitable for outdoor use and therefore for photographing wildlife.

Modification of Geodata

In my recent research I carried out processes proving that geotag data can be modified on the iPhone. These changes can be made either to JPG metadata on the device or to metadata within the iTunes backup files, which are then restored to the device. The benefit of the latter method is that it is less detectable when forensically analysing the iPhone than the method of modifying the images on the device itself. Obviously analysis of the computer where the changes were made in iTunes Backup should present artefacts, although the machine may not be available to the investigator to offer the evidence. This can be used to falsify evidence, such as creating a false alibi or in an attempt to falsely incriminate a third party.

 


Before modification
TAGView screenshot (click to enlarge)

After modification
TAGView screenshot (click to enlarge)

The same methods can be applied to other iDevices, such as the iPod and iPad, and with Apple projecting iPhone sales of 100 million handsets and 48 millions iPads for 2011, there are increasing possibilities that Apple iDevices may be misused for fraudulent or criminal activities. Of course, these modifications could just be done on a computer with no involvement of mobile phones.

Here are some hypothetical examples of modifying geotags for misuse:

· A person with a grudge could upload an image of some precious diamonds to Craigslist. They could convert the geotags to point to the target’s home address, therefore leaving the target and their family vulnerable to possible theft.

· If a victim’s phone could be accessed briefly, a pornographic image, taken by a similar device, could be transferred onto the target device. The image would have geotags pointing to the victim’s house address. The instigator could then anonymously inform the police that the victim is in possession of illegal images. The evidence is present on the device to help convict the victim. He may have often left his iPhone on his desk during the working day, but thought it OK as it was pin-locked.

· An organised crime gang member could download a JPG of a girl from the web. The location could be modified to a disused warehouse, and then, via the wi-fi connection in the local cafe, the image uploaded to the web. The image geodata could be translated to the location by someone who works in ICT, who could decide to visit the address out of curiosity and is attacked and robbed.

In a case where an outcome may rely on geographical evidence, it is crucial that it be taken into consideration that the data may have been tampered with, even if there is no forensic evidence being present.

Due to the speed of users’ uptake of accessing email and the internet, along with the multimedia and geographic capabilities of the latest smart phones, there is an argument that such smart phone devices could easily become subjected to misuse, criminal and fraudulent activities. An example of this already happening is with the introduction of apps that utilise augmented reality. A definition of augmented reality, otherwise known as AR, is “the real-time mixing of computer generated and real-world information” (TheAssurer.com, 2010). An example of AR working in conjunction with an iPhone is Layar utilising a Panoramio layer. Panoramio is a Google-owned app allowing images to be uploaded via a smart phone or internet browser. The images appear, for example, on Google maps where certain criteria are entered into an API. This can then be interlaced with Layar, which is an app allowing the smart phone user to point view media tied to their current location. This AR system can also interlace further with Flickr and Google Earth, which arguably could cause further problems in the case of misuse. Could it be only a matter of time before this technology can be used to create violations of privacy and potentially endanger individuals and property? By creating an image of a person or object that may be likely to attract undesirable attention from criminals or sex offenders and geotagging it to a user’s location could be considered malicious and a violation of the user’s right to privacy and safety.

To summarise, such modifications of evidence on digital handheld devices may not be commonplace at the moment, but could prove to be a problem for victims in the future. Modifications of digital evidence may prove a future challenge for both law enforcement agencies and forensic examiners on a global scale. There is also an inherent naivety, amongst many users, regarding the dangers involved with publishing geotagged images on the internet.

If anyone would like a copy of “Geotag Data: The Modification of Evidence on the Apple iPhone” then PM me ( RedCelica67 on ForensicFocus.com ) or email me via the Blackstage Forensics website.

David Benford is Director of Blackstage Forensics (www.blackstage-forensics.co.uk), Derbyshire, England. He specialises in the forensic analysis of handheld digital devices and possesses an MSc in Forensic Computing & Security. He is also a trustee of the Cystinosis Foundation UK charity – see http://www.cystinosis.org.uk/our-charity/trustees for further details.


Evaluating Mobile Telephone Connection Behaviour – Part 2

0
0

The Basics of Evaluating Connection Records

by Sam Raincock, IT and telecommunications expert witness

Connection RecordsWithin the UK, details of past telephone connections are stored by the network providers. The minimum storage is advised by the Data Retention (EC Directive) Regulations [1][2]. However, each network provider is able to disclose different types of information about past connection activity and this availability also changes over time. As a result, it is important to be familiar with what connection record information may be available to your case so you can make appropriate requests to obtain access to it. Perhaps a useful strategy for companies undertaking connection record evaluation work would be to compile a procedure where your organisation will contact the network providers every 6 months to determine if anything has changed.

It is also important to note that the network providers will provide a ‘standard’ format of connection records if they are not directed regarding the information you require. My philosophy with network records is that if you don’t ask, you won’t get it!

Examining Connection Records

Most often the instructions received in connection charting matters are to compile charts of connection patterns of the telephones of interest in a case. This is generally over a certain time period and may also include a frequency analysis to determine how many connections have occurred with particularly numbers of interest. It may (especially in defence cases) also include questions about the meaning of connections and the possible circumstances of the calls/SMS messages.

Where connection records specialists are lucky, they are provided with the records in electronic format. Where they are ill-fated they obtain a file of 500+ pages in paper format and the electronic records are unavailable (very common in older cases).

With paper records, you have two options: transfer the records into electronic format (however, you are going to have to thoroughly validate that this has occurred correctly) or you will need to examine them by eye. Actually, dealing with paper connection records is a lot easier than it sounds as you become used to looking for patterns over time.

With electronic records, if you are using pivot tables to assist you in performing a frequency analysis of the connection behaviour to establish how many connections have been made with certain telephone number of interest, remember that a telephone number may be provided in the records in various formats. For example, 07777 111111 may also be provided as 447777 111111.

Also with electronic records – make sure you don’t suffer from sorting issues. Firstly, if you haven’t set your data to be the correct type (which can be an annoying activity in itself), sorting can produce unexpected results. And of course, there is also the old Excel sorting problem where you sort by column and don’t expand the selection to the other data values too, resulting in shuffling your original connection records table.

Although all these points may seem very basic, in my experience mistakes do occur in this type of processing. Another area for error is overlooking the obvious – the date being in the wrong format or the wrong number is searched for etc. Hence, the key when performing connection charting/analysis is to validate, validate, validate and assume nothing.

Evaluating Connection Behaviour

So you’ve obtained your connection records…

The following table has been compiled as an illustration of the connection behaviour on 13/2/07 involving the number 07766215520:

Type of Connection Telephone Number contacted Date Time Duration (s)
SMS 07753984793 13/02/2007 09:48 0
Voice 07753984793 13/02/2007 09:49 12
Voice 07753983793 13/02/2007 09:54 3
SMS 0191 567890 13/02/2007 10:05 0
Voice 07971123456 13/02/2007 10:07 67
Voice 07753984793 13/02/2007 10:16 12

What’s in the table?

· Does it contain incoming connection information?

· What are the date and time ranges requested?

· Does it illustrate only certain telephone numbers?

Without an explanation of the content of the table its meaning cannot be established. Hence, when compiling connection behaviour or when receiving information from the network providers it is important to establish the content of the data provided so that appropriate assessments can be made of its meaning.

So let’s assume the request was to receive outgoing connections made by telephone 07766215520 between 9am and 12, on 13th January 2008. Let’s now consider the following questions:

· How many listed connections involve the 07753984793 number?

· How many voice calls were answered by the recipient telephone (and not forwarded to another device)?

· How many calls were made and over what time period?

· Is it possible to send an SMS message to a landline? Is it unusual to do so?

And their answers:

· How many listed connections involve the 07753984793 number?

The answer is 3 – one SMS message and two voice calls. Note that the connection at 09:54 is for the number 07753983793 and not 07753984793.

Attention to detail is key!

· How many voice calls were answered by the recipient telephone (and not forwarded to another device)?

Unknown.

The voice calls range from 3 to 67 seconds in duration. Hence, they could have forwarded to voicemail or answerphone. With the connection records supplied it is not possible to state if any forwarding has occurred. It would also be incorrect to assume the connection lasting 67 seconds was answered by the recipient telephone due to its length. Firstly, it could have been forwarded to another number and hence, the duration would not assist in establishing this. Secondly, it could have forwarded to answerphone – some services in the UK allow rerecording of messages and/or 2-4 minutes message duration. Test it!

· How many calls were made and over what time period?

Good question. The records were request for 13th January 2008. That’s 2008 and not 2007 that features in the records. Hence, we don’t know what time period the records were requested for or why they have been provided as the incorrect year. Also, the phrasing “between 9am and 12” is ambiguous. Is that 12 noon or 12 midnight?

· Is it possible to send an SMS message to a landline? Is it unusual to do so?

Yes (it’s amusing too). The unusual question is a tricky one. If it is a generic question then your ability to answer it will depend on how much connection records data you have analysed previously in order to be able to make your assessment.

You may wish to look at more records to determine if this activity was a one off or is consistent with the user’s ‘normal’ telephone behaviour.

Combining the Handset and Connection Record Evidence

In part 1 of this series and discussed above, I have introduced the process of starting to think about the meaning of connection information stored on mobile telephone equipment and the basics of connection record information.

Next month’s article will deal with the issues and benefits of combining the two sources of evidence. However, for those keen to have a go, download the example exercise and see what questions you can answer (please do not email or comment about your answers in the Columnists forum, though, answers will follow next month.)

References

1. Statutory Instruments. 2009 No. 859 Electronic Communications – The Data Retention (EC Directive) Regulations 2009. Available for download from http://www.legislation.gov.uk/uksi/2009/859/made/data.pdf.

2. Statutory Instruments. 2007 No. 2199 Electronic Communications – The Data Retention (EC Directive) Regulations 2007. Available for download from http://www.legislation.gov.uk/uksi/2007/ 2199/made/data.pdf.

Click here to discuss this article.

Read Sam’s previous columns

Sam Raincock Consultancy operates throughout the UK and Ireland providing IT and telecommunications expert witness services, training and IT security consultancy.

Sam specialises in the evaluation of digital evidence from the analysis of telephones to determining the functionality of software systems (and almost anything in-between). She also provides overview assessments of cases, considering different sources of evidence in the context of a whole incident to highlight inconsistencies particularly due to digital devices. Sam can be contact direct on +44 (0)1429 820131, sam@raincock.co.uk or http://www.raincock.co.uk.


The Challenges Facing Computer Forensics Investigators in Obtaining Information from Mobile Devices for Use in Criminal Investigations

0
0

David W. Bennett

August 20, 2011

The Challenges Facing Computer Forensics Investigators in Obtaining Information from Mobile Devices for Use in Criminal Investigations

There are a number of electronic personal devices that are labeled mobile devices” on the market today. Mobile devices include cellphones; smart phones like the Apple iPhone and Blackberry; personal digital assistants (PDAs); and digital audio players such as iPods and other MP3 type devices. Laptop computers, tablets and iPad products are not typically classified as a mobile device as they are not small enough to be considered handheld. Today, the ever popular smartphone comes with a storage capacity that is similar to a laptop while commonly utilized as a portable office, social network and entertainment center all rolled into a solitary, convenient device. A smartphone is a mobile device that provides advanced computing and offers the ability to run mobile applications with more connectivity options than a cellular phone.

Technological and storage capacity for mobile devices has grown exponentially. Over the last decade, capabilities and features of mobile devices have turned them into data repositories that can store a large amount of both personal and organizational information. Unfortunately, criminals have not missed the mobile device information revolution. Within the past few years, they have increasingly been using mobile phones and other handheld devices in the course of committing criminal acts. For example, a drug dealer may keep a list of customers who owe him money in a file stored on his handheld device or a child pornographer could keep nude images of underage children engaging in sexual activities on a mobile device for the purposes of trading photos or video files with other pedophiles. Indeed, almost every class of crime can involve some type of digital evidence from a device that is essentially a portable data carrier. This increases the potential for incriminating data to be stored on mobile devices and to be utilized as evidence in criminal cases. Can valuable information be obtained from a mobile device to assist in a criminal investigation? What are the challenges a forensics investigator faces in obtaining information from these devices?

Mobile devices cancontain such electronic records information such as electronic mail, word processing files, spreadsheets, text messages, global positioning system (GPS) tracking information and photographic images that can provide law enforcement personnel with essential evidence in a criminal investigation. A mobile phone’s ability to store, view and print electronic documents is easily utilized from a single hand-held device with the processing power and the storage capacity similar to a bulky laptop (Marwan Al-Zarouni, 1).

Need for Mobile Forensics

Mobile device forensics is the process of recovering digital evidence from a mobile device under forensically sound conditions and utilizing acceptable methods. Forensically sound is a term used in the digital forensics community to justify the use of a particular technology or methodology. Many practitioners use the term to describe the capabilities of a piece of software or forensic analysis approach (McKemmish, 3). Mobile devices vary in design and manufacturer. They are continually evolving as existing technologies progress and new technologies are introduced. It is important for forensics investigators to develop an understanding of the working components of a mobile device and the appropriate tasks to perform when they deal with them on a forensic basis. Knowledge of the various types of mobile devices and the features they possess is an important aspect of gathering information for a case since usage logs and other important data can potentially be acquired using forensics toolkits.

Mobile device forensics has expanded significantly over the past few years. Older model mobile phones could store a limited amount of data that could be easily obtained by the forensics investigator. With the development of the smartphone, a significant amount of information can still be retrieved from the device by a forensics expert; however the techniques to gather this information have become increasingly complicated.

The demand for mobile device forensics stems from mobile phones being employed for such functions as to store and transmit both personal and corporate information. The use of mobile phones in online transactions such as stock trading, flight reservations and check-in; mobile banking; and communications regarding illegal activities that are being utilized by criminals has created a need for mobile device forensics. While it took decades to convince legitimate businesses that mobile devices could increase sales, communications, marketing and other improvements to their operation; crime organizations were well aware of the substantial benefits that mobile phones could provide (Mock, 1). Law enforcement and forensics investigators have struggled to effectively manage digital evidence obtained from mobile devices. Some of the reasons include:

  • Mobile devices require specialized interface, storage media and hardware.
  • File systems that are contained in mobile devices operate from volatile memory or computer memory that requires power to maintain stored information versus nonvolatile memory devices like a standalone hard disk drive that does not require a maintained power supply.
  • The diverse variety of operating systems that are embedded in mobile devices.
  • The short product cycles from the manufacturers to provide new mobile devices and their respective operating systems are making it difficult for law enforcement agencies to remain current with new technologies.

Forensics Tools

A few of the more well received commercial off the shelf (COTS) products and open source applications available to the forensics community are reviewed below; however, no recommendations are made or implied.

Of the most emerging commercial products, stands the Cellebrite Universal Forensics Extraction Device (UFED) Forensic System – a standalone mobile forensic device utilized both in the field and in the research lab. The UFED device supports most cellular device interfaces including serial, USB, infrared, and Bluetooth and can provide data extraction of content such as audio, video, phone call history and deleted text messages stored in mobile phones. The Cellebrite product is popular with investigators because it works well with the Apple iPhone and the acquisition methods can recover a significant portion of the data on the iPhone device. The firmware, which is used to run user programs on the device, is updated often enough to support new mobile devices and its functionality for the forensics examiner.

Paraben Corporation’s Device Seizure product is another COTS forensic acquisition and analysis tool for examining over 2,200 handheld devices including cellular phones, PDAs and GPS devices. In addition, Device Seizure is designed to support the full investigation process and can perform physical acquisition through a data dump in its ability to recover deleted files and other information. The Device Seizure product, according to many experts in the forensics area, is considered shelf-ware and often will not perform as marketed (Mislan).

Final Data’s Final Mobile Forensics product is another and is specific to Code Division Multiple Access (CDMA) mobile phones. CDMA phones were first launched commercially in Hong Kong in 1995 and are now currently utilized by major cellular carriers in the United States as an alternative to Global System for Mobile communications (GSM) technology. To help gain perspective, the wireless world is divided into GSM (standard outside of US and used inside US by AT&T and T-Mobile) and CDMA (standard in North America and parts of Asia). While there may never be a single standard technology worldwide, GSM is used in 219 countries and territories serving more than three billion people and providing international travelers the broadest access to mobile services (Moore, 3-5).

Another type of product, a flasher box, is available but not recommended as a substitute for one of the above-mentioned automated COTS products because they are not always reliable. Flasher boxes are not designed for forensic work but can help recover data that is not readily available. Flasher boxes should never be used as a first response as they are considered a dangerously intrusive alternative and should only be utilized by trained or highly experienced investigators for their use in controlled environments as they can be technically challenged and complicated to use. Although flasher boxes do not require any software to be installed as with other forensics toolkits, modifications to the data can occur very easily through incorrect use, thus, leaving the evidence tainted and deemed useless to a criminal investigation. Flasher boxes are not usually documented by any best practices or principles, therefore, there are no simple methods to determine if they do preserve evidence in the mobile device’s memory and no guarantee that flashers will work in a dependable manner.

Some examples of open source products that are freely available for download but limited in features when compared to commercial products include BitPim, a program that allows the user to view and manipulate data on many CDMA phones; Smelter for use on Siemens brand mobile phones; and ChipIt used to explore GSM Subscriber Identity Module (SIM) cards to view and copy a mobile device phone book. Although open source products like the aforementioned ones are heavily adopted and easily available to the forensics investigator, there are many issues that arise such as timely updates to the software, limited functionality and quality assurance testing of the software has been known to be problematic (Moore, 3-5).

Information is stored in the mobile phone’s internal memory. Pertinent data such as call histories are stored in proprietary formats in locations that will alter that data according to phone model. Even the cable used to access the mobile device’s memory will vary according to manufacturer and model. Many examiners look at the SIM cards, which store personally identifiable information (PII), cell phone numbers, phone book information, text messages and other data for valuable information because it is typically stored in a standard format; however, the limited storage capacity of a SIM card forces the majority of the data to be stored on the phone itself.

Unlike traditional computer forensics on a desktop or laptop computer where the investigator would simply remove the hard drive, attach to a write blocker device thus allowing acquisition of information on a computer hard drive without creating the possibility of accidentally damaging the drive contents and image the hard drive in order to fully analyze the data; the process to extract information from a mobile device is more complicated. There are a number of complex mobile forensics software applications to assist in the removal of data that are available to the forensics community. However, the lack of a leading edge tool and decreasing budgets for acquiring the tools are an ongoing problem (Mislan, 1-3). Since no single tool comes highly recommended by the forensics community, it is often desirable to use a range of software tools to acquire the data, thus increasing the budget needed to acquire the appropriate tools. The software tools available are expensive and law enforcement agencies are operating under restricted budgets and fixed resources.

Mobile Devices

ComScore, a marketing research company that provides digital marketing intelligence for Internet businesses, estimate that roughly 63 million smartphone subscribers are in the United States, of which, Research in Motion (RIM)’s Blackberry device lead the pack with 31.6 percent, Google’s Android in the number two spot with 28.7 percent and Apple iPhone at number three with 25 percent of the market. ComScore data states that 234 million Americans ages thirteen and older used some type of mobile device in December 2010; however, the more interesting data are the mobile content usage in December 2010. The data estimate that 68 percent of US mobile subscribers used text messaging on their mobile device, web browsers were used by 36.4 percent and mobile applications usage at 34.4 percent (ComScore Web).

An example of one of the fastest growing smartphone devices is the iPhone from Apple Inc. which debuted in January 2007. There are entire books dedicated to the operating systems for the Apple products as well as the development of applications for them. Like most electronic devices, the iPhone is a collection of modules, computing chips and other electronic components from various manufacturers making it difficult to utilize a “one size fits all” forensics software application as a staple for the forensics process. In fact, this is true for most mobile devices on the market. There does not seem to be a single vendor that is the emerging leader in forensics toolkits and oftentimes, as is the case with the popular iPhone, forensics investigators are relying on the hacker community for assistance in analyzing mobile devices (Mislan).

Today’s mobile phone devices have a large storage capacity and a wide range of applications and connectivity options available to the user with each telecommunications provider. Mobile device forensics applications and toolkits are relatively new and developers are having difficulty in keeping up with the emerging technological advances due to the revolving door of products from market demand. The forensic tools available are often limited to one or more phone manufacturers with a limited number of devices supported (Marwan, 2-3).

Regarding standards, the only evaluation document available for mobile phone forensics toolkits is published by the National Institute of Standards and Technology (NIST) (Ayers NIST Web, 1-2). NIST and various law enforcement staffs help to develop the requirements, assertions and test case documents to evaluate the toolkits and to assist in providing guidance in choosing the correct product to fit their need. The NIST evaluation document contains generic scenarios created to mirror real-life situations that may arise during a forensic examination of a mobile device. The NIST scenarios serve as a baseline for helping the forensics community determine a tool’s capacity to acquire and examine data in order to gain a perspective on the correct tools to invest. The NIST evaluation documents are considered to be an important resource for forensics investigators to maintain quality control and to validate toolkit functionality for mobile device forensics in proper data acquisition and reporting.

Another organization discussing mobile device standards is a forum formerly entitled Open Mobile Terminal Platform (OMTP) and now called the Wholesale Applications Community (WAC) that has been created by mobile network operators to discuss and formulate standards with manufacturers of cell phones and other mobile devices. The goal of the WAC is to encourage open standardized technologies and allow developers to deploy applications across multiple devices and operators through the use of the standard technologies. The WAC has published some requirements for the support of advanced SIM cards and mobile device security but has mostly received broad support from European mobile device operators.

It is no simple task to try and create standards for such a varying group of device manufacturers who utilize proprietary circuits and do not seem to agree on a communications standards so the forum has had limited success in the United States. Apple has already stated they will not join any standards. The outcome of the WAC will likely be a broad set of guidelines that will be adopted inconsistently by manufacturers. It would be prudent for the government to support open standards in order to lower the cost for law enforcement forensics investigators to recover data for investigations and to choose the appropriate tools to utilize.

There are many devices that are cheaply manufactured in China and are very difficult to perform forensics by examiners. The primary reason is that inexpensive Chinese cell phones are unbranded, meaning they have no International Mobile Equipment Identity (IMEI) number and therefore, cannot be traced. The phones are attractive to criminals and terrorists who often utilize the cell phones for activities such as detonating bombs without being detected. A unique IMEI number is required for all GSM phones. This number allows a signal tower to identify individual cellular handheld devices in a service network which in turn helps the military and law enforcement establish the location of the phone (Moore, 5). With an unbranded phone, the absence of the IMEI number makes it impossible to track these mobile devices; thus, making the Chinese-made phones attractive to criminals and terrorist organizations alike.

The United States Armed Forces has found an abundance of the Chinese-made cell phones in theater while in the Middle East. The India government has banned the Chinese-made cell phones from entering the country; however, these low-cost phones have penetrated into Pakistan and other developing markets. This is proving to be a serious security issue for American troops stationed in the Middle East. There is much exploration to be conducted in the area of these devices as China is one of the world’s largest and fastest growing markets for inexpensive and unbranded mobile devices. The investigative world knows little about the design, make, manufacturers and behavior of these mobile devices.

Laws

Forensics evidence is only as valuable as the integrity of the method that the evidence was obtained. The methods applied to obtain evidence are best represented if standards are known and readily established by the digital forensics community. The Fourth Amendment limits the ability of government agents to perform search and seizure evidence tactics without a warrant, including computers.

The Fourth Amendment states: The right of the people to be secure in their persons, houses, papers, and effects, against unreasonable searches and seizures, shall not be violated, and no Warrants shall issue, but upon probable cause, supported by Oath or affirmation, and particularly describing the place to be searched, and the persons or things to be seized.

The Fourth Amendment question that typically comes up in digital evidence cases asks whether an individual has a reasonable expectation of privacy having electronic information stored on electronic devices under that individual’s control. Computer evidence can present a challenge for both prosecutors and defendants alike. A guide to offering mobile device data as evidence is beyond the scope of this research but a few examples of some digital forensics issues in real life situations are described below.

A legal issue in presenting evidence is the “best evidence rule” which states that to prove the contents of a document, recording or photograph, the “original” document, recording or photograph is ordinarily required. For example, in United States v. Bennett, 363 F.3d 947, 953 (9th Cir. 2004), a federal agent testified about information that he viewed on the screen of a GPS on the defendant’s boat in order to prove he had imported drugs across international waters. It was decided the agent’s testimony violated the best evidence rule because he had only observed a graphical representation of data from the GPS instead of actually observing the professed path the boat had been following during the encounter. Since the U.S. sought to prove the contents of the GPS, the best evidence rule was invoked and required the government to present the actual GPS data or printout of the data, rather than the testimony from the federal agent (Open Jurist Web, 1-2).

In 2010, a Japanese sumo wrestling match-fixing scandal was brought to light after investigators analyzed data left on fifty cell phones seized from wrestlers of the Japan Sumo Association (JSA) while probing a baseball scandal in that country. The Japanese police were able to retrieve and restore electronic mail messages previously deleted from the mobile phones including messages exchanged among wrestlers who were being implicated in the wrestling bout-rigging case. The sumo wrestlers refused to turn over their mobile devices to law enforcement claiming their phones were damaged due to water or the battery had died in the phones. The case is still ongoing in Japan but members of the JSA plan to obtain data left on the cell phones utilized by the suspected wrestlers to restore deleted email messages in order to prove the case against the sumo wrestlers. Even if deleted, the cell phone email data remains in binary format on the handheld device’s memory. This is called data remanence or the residual representation of data that remains after attempts have been made to remove or erase the data. Through digital forensics, even mobile devices that have been ruined or immersed in water can still recover data unless the device’s memory chips are destroyed (Daily Yomiuri Online Web).

Like digital evidence from a computer, it is necessary to have proper legal authority in order to perform a forensics investigation of cellular telephones and mobile handheld devices. An exception that is supported by case law (U.S. v. Finley C.A.5 Tex., 2007, & U.S. v. Carroll N.D. Ga. , 2008) allows a search “incident to arrest” and is often connected with searches of arrestees and motor vehicles. For example, in the U.S v. Finley case, it was noted that the defendant in the case “had conceded that a cell phone was analogous to a closed container” for the purpose of Fourth Amendment analysis Cyb3rcrim3 Web). Such searches are allowed by the court to be performed for the preservation of evidence that could easily be altered or damaged. This exception for handheld devices is restricted by a limited period of time and according to law, may be searched without a warrant only if the search is “substantially contemporaneous with the arrest (U.S. v. Curry D Me., 2008) (Lewis, 2).

The authors of the Fourth Amendment could not have envisioned the powerful technology of today’s electronic age and courts have only begun to answer difficult questions that are being introduced through the use of these devices. Current Fourth Amendment doctrine and precedent cases suggest that the United States Supreme Court would consent to invasive searches of a mobile device found on the person of many individuals and has allowed an exception permitting warrantless searches on the grounds that law enforcement should be allowed to look for weapons or other evidence that could be linked to an alleged crime. The Obama administration and many local prosecutors feel that warrantless searches are perfectly constitutional during arrests (McCullagh,2).

Privacy advocates feel that existing legal rules allowing law enforcement to search suspects at the time of an arrest should not apply to mobile devices like the smart phone because the value of information being stored is greater and the threat of an intrusive search is much higher, such as PII. Personally identifiable information (PII) is information connected to an individual including but not limited to education, financial transactions, medical information, and criminal or employment history which can be used to trace that individual’s identity such as name, social security number, or birth date. While technologies have evolved over the years, the search incident principle has remained constant.

The Fourth Amendment applies to mobile electronic devices and digital evidence just as it does any other type of criminal evidence. Legally, when handling computers and mobile devices, it is best for the forensics investigator to treat them as they would a closed container, such as a briefcase or a file cabinet. Generally, the Fourth Amendment prohibits law enforcement personnel from accessing, viewing, or examining information stored on a computer or mobile device if the law enforcer would be prohibited from opening a closed container and examining its contents in the same situation. The forensics investigator should always be aware that laws vary state by state and unopened electronic mail, unread texts, and incoming phone calls of seized devices may present non-consensual eavesdropping issues.

In digital media searches, the media is frequently searched off site and in an enclosed forensics laboratory. Generally, courts have treated the offsite forensics analysis of seized digital media as a continuation of the initial search and thus, the investigator is still bound by the Fourth Amendment. Because this analysis is often treated as part of the initial search, the government bears not only the burden of proving the seizure was reasonable and proper, but also that the search was conducted in a reasonable manner. To ensure that search and seizure forensics analysis meets the burden later at the trial, the forensics investigator should generate a written report with clear documentation of the analysis.

Chain of Custody and Preservation of Evidence

The goal of a forensic investigator is to obtain evidence utilizing the most acceptable methods, so the evidence will be admitted according to law in the trial. Obtaining a judge’s acceptance of evidence is commonly called admission of evidence. Evidence admissibility will require a lawful search and the strict adherence to chain of custody rules including evidence collection, evidence preservation, analysis, and reporting.

According to the International Organization on Computer Evidence, some general principles should be followed in recovering digital evidence for chain of custody:

  1. All of the general forensic and procedural principles should be adhered to when dealing with digital evidence.
  2. Upon seizing digital evidence, any actions taken should not modify the original evidence.
  3. When it is necessary for personnel to access the original digital evidence, the personnel should be appropriately trained for the purpose.
  4. All activities associated to the seizure, access, storage or transfer of digital evidence must be fully and properly documented, preserved and available for review.
  5. An individual is responsible for all actions taken with respect to digital evidence when digital evidence is in that individual’s possession.
  6. Any agency that is responsible for seizing, accessing, storing or transferring digital evidence is responsible for compliance with all six principles (Guidelines for Best Practice in the Forensic Examination of Digital Technology 17-18).

There are several publications, including those from the U.S. Department of Justice, that do not list any doctrine or principles like the ones aforementioned from the International Organization on Computer Evidence; however, many of the points addressed in the above principles are covered and provide a comprehensive explanation of the forensic process as well as related legal issues in the United States.

As a rule, in criminal court proceedings, the process is often more scrutinized than the actual evidence recovered for a criminal investigation. An important part of the preservation of evidence process is in securing and isolating cell phones and other mobile devices found on-site for transport to the forensics lab for evaluation.

While a mobile phone is powered on, it will search for the strongest signal, usually from the nearest active cellular tower, or a tower that enables the device to obtain the best signal. As a mobile device is transported, it will continue to search and adjust to maximize the strength of signal with that tower. The designation of the most recently connected cellular tower is then recorded as a database entry in the file system of the cellular phone; thus, when a mobile device moves to a new area, a new entry will be updated in that database.

The most important step for a first-responder investigator, when arriving at the scene of a crime and identifying a mobile device for possible evidence submission, is to determine how best to preserve that device and its data. Recording and documenting the scene, including photographs of the mobile device in an undisturbed state should be included. It is recommended to power the mobile device off to preserve the data and battery power. If it is not possible to power the device off in a safe manner, the phone should be protected from cellular phone towers. Aside from locking down the mobile device by either disengaging or maintaining the power supply, the investigator should seize any additional accessories to the device such as SIM and media cards, headsets, charger cables and cases that could potentially contain evidence.

When a mobile device has been powered off, text messages and other data may queue for delivery when the phone is powered back on and returned to service. The queued messages and data can overwrite old and deleted messages and/or data once they are delivered to the carrier. Carrier providers may update system files and roaming services when the mobile device is connected to the system. There will also be the potential for corruption of downloaded data as well as the file system of the device during a forensic examination when the system updates are transmitted to the system.

The equipment that works the best is Radio Frequency (RF) shielded test enclosure boxes such as the type from a forensics product vendor like Ramsey Electronics. The Ramsey boxes ensure the mobile device is isolated from a cellular carrier’s network, and other RF signals to prevent any incoming or outgoing communications, including GPS tracking.

Another option to transport a mobile device from the crime scene to the crime lab is a Faraday bag. Faraday bags are specially designed RF plastic coated shielded bags used to shield a mobile device from external contact. The bags are coupled with a conductive mesh to provide secure transportation to the laboratory. One issue with Faraday bags is that, oftentimes a cell phone will continue to search for a signal even while in the protected bag thus zeroing out the register that holds the location data – and making the device useless as an evidence artifact. Yet another issue is the increased activity while in the Faraday bag while the mobile device is powered on that can cause the battery to fail at a faster pace. With the Apple iPhone in particular, it is imperative for the forensic investigator to properly seize the mobile device due to the option of the Remote Wipe feature on the phone. A user can perform this command if the smart phone is connected to the Internet or phone network. If the device is powered off or placed in a Faraday bag, it cannot be remotely wiped; however, once powered back on, the wiping process, if activated, will automatically be invoked.

When choosing a shielding artifact like one of the above-mentioned products, it is important to enable the forensics investigator to utilize the necessary tools to complete the examination and within the shielded area of a forensics laboratory if possible.

Conclusion

Mobile device forensics is an ever-evolving field filled with challenges and opportunities when analyzing a mobile device for forensic evidence in support of a criminal investigation. The process can be more difficult than traditional computer forensics due to the volatile nature of electronic evidence. The software applications for mobile forensic testing are often not 100% “forensically sound”. A well trained, highly skilled digital forensics investigator plays an essential role in the criminal investigation process when performing forensics analysis of mobile devices that belong to suspects, witnesses, victims or through the analysis of network traffic in response to computer security incidents (Curran, K., Robinson, A., Peacocke, S. and Cassidy, S., 1-4).

Although forensics toolkits do exist for the investigator, the majority of the tools are either not fully developed and do not yet provide full functionality for multiple devices. Budget constraints of law enforcement departments prohibit the purchase of quality software packages to use with the varying mobile device manufacturers. The key is for the investigator to use the appropriate toolset that is meant for that particular purpose in performing forensics analysis in an effective manner that will support a criminal case (Mislan).

Even such a pertinent piece of forensics equipment, like the Faraday bag for the first-responder, is not free from issue. Once removed from the Faraday bag, a mobile device can start receiving data if powered on and be able to connect to the network. This may be difficult to control for the first responder if he is instructed by a higher official to leave the mobile device powered on upon discovery at the crime scene. Some devices can be controlled by placing the phone in airplane mode, thus disabling the wireless features, but not all mobile devices possess this functionality. For the most part, Faraday bags are reliable but cannot fully guarantee that a signal will not reach the phone. Successfully blocking the signal depends upon the quality of the bag, the distance to the cell tower, and the power of the transmitter in the mobile device.

Another challenge that faces the forensics investigator is digital evidence that is obtained for a criminal investigation can be preceded by a suppression hearing. A suppression hearing is an opportunity for a judge to look at the evidence and determine whether it will be admissible or violates the suppression of evidence which determines if an unreasonable search or seizure violated a defendant’s constitutional right. The judge will determine whether the Fourth Amendment has been followed in the search and seizure of evidence. A forensics investigator’s knowledge of preservation of evidence rules, chain of custody principles and the overall legal issues in obtaining digital evidence from a mobile device is vital. It is important for the forensics investigator to stay current on the latest technological tools and laws that deal with admissibility of evidence, in order to avoid the evidence carefully obtained being struck down by a proceeding judge. The investigator should always keep up to date on what the latest efforts that criminals are utilizing to combat the forensics process.

Forensic computing continues to play an increasingly important role in civil litigations, especially in electronic discovery, intellectual property (IP) disputes, as well as information security and employment law disputes. Forensics investigators must be aware of certain issues pertaining to data acquisition and the preservation of digital evidence for a criminal investigation. Electronic data is very susceptible to alteration or deletion, whether through an intentional change or from the result of an invoked application in some computing process. As electronic data is created, modified or deleted through the normal operations of a computing system, there lies the possibility of modifications arising from an incorrect or inappropriate digital forensics process. Given that the results of such actions can be treated as critical evidence in a case, it is essential that every measure be taken to ensure the reliability and accuracy of the forensics process. A digital forensics process must be developed and applied with due regard to jurisprudence issues. It is imperative that the digital forensics process is capable of being examined thoroughly to determine the reasonableness and reliability to refrain from being admissible.

Works Cited

Al-Zarouni, Marwan. “Mobile Handset Forensic Evidence: A Challenge for Law Enforcement”.

Australian Digital Forensics Conference. Edith Cowan University. Abstract. December 4, 2006.

Ayers, Richard. “Mobile Device Forensics – Tool Testing”. National Institute of Standards and

Technology (NIST) Web. www.cftt.nist.gov

ComScore Web. February 7, 2011. http://www.comscore.com/Press_Events/Press_Releases/2011/2/comScore_Reports_December_2010_U.S._Mobile_Subscriber_Market_Share/(language)/eng-US

Curran, K., Robinson, A., Peacocke, S. and Cassidy, S. “Mobile Phone Forensics Analysis”, International Journal of Digital Crime and Forensics, Vol. 2, No. 2, April-May 2010

Cyb3rcrim3 Web. “Warrant Needed to Search Cell Phone”. December 16, 2009. http://cyb3rcrim3.blogspot.com/2009/12/warrant-needed-to-search-cell-phone.html

“Guidelines for Best Practice in the Forensic Examination of Digital Technology”. July 2006. pp17-18. December 6, 2006. Print.

Lewis, Don L. “Examining Cellular Phones and Handheld Devices”. Forensics magazine, August/September 2009.

McKemmish, Rodney. “Advances in Digital Forensics IV”. 2008. International Federation for Information Processing.

Mislan, Richard P. Assistant Professor, Department of Computer and Information Technology, Purdue University. Personal Interview. February 11, 2011.

McCullagh, Declan. “Police Push for Warrantless Searches of Cell Phones”. CNet Web. June 26 2010. http://news.cnet.com/8301-13578_3-10455611-38.html

Mislan, Richard P. “Cellphone Crime Solvers”. IEEE Organization. Web. July 2010. http://spectrum.ieee.org/computing/software/cellphone-crime-solvers

Mock, David. “Wireless Advances the Criminal Enterprise”. The Feature Archives Web. June 28, 2002. http://thefeaturearchives.com/topic/Technology/Wireless_Advances_the_Criminal_Enterprise.html

Moore, Tyler. “The Economics of Digital Forensics”. University of Cambridge, June 2006. Print.

Open Jurist Web. April 9 2004. UNITED STATES of America, Plaintiff-Appellee,v. Vincent Franklin BENNETT, Defendant-Appellant. http://openjurist.org/

The Yomiuri Shimbun Online Web. “Data Retrieval Key to Sumo Scandal”. February 9, 2011. http://www.yomiuri.co.jp/dy/sports/T110208005743.htm


iPhone Tracking – from a forensic point of view

0
0

- Introduction -

iPhoneTracking is sexy!!! Every mobile forensic suite, at least the ones dealing with iPhones, are providing it proudly. iPhoneTracking also has been a hot topic in the media all around the globe. People stated, that there is a way to display every step of an iPhone user ever since the device got bought. Hm… Sounds great for all kind of investigations! Let’s see…

Apples Point of View

Apple, on the other hand, stated that: “in no way Apple does tracking movements of iPhone users”. What Apple admits is to provide a well designed CoreLocation Framework.

(Apple Inc)

The goal behind CoreLocationFramework is to provide location based services being:

  • Available instantly everywhere, all the time, but
  • also resource friendly, saving battery life.

The Location sources or maybe the problems to be solved are:

  • GPS (is not available inside buildings, eats up battery-lifetime)
  • Cell towers (have no geo-coordinates available)
  • Wi-Fi hotspots (have no geo-coordinates available either).

The solution would be to provide geo-location information from the built-in GPS sensor when necessary and available and some kind of fall-back location estimation inside buildings or whenever GPS is not (yet) available. Most iPhone users do have mobile service and Wi-Fi enabled all the time. Cell towers and Wi-Fi hotspots can be concerned to be quite stable regarding their geo-location. And: there are several signal-stations availble all around the position of the user that can be used to calculate the actual position on base of triangulation. The problem for Apple is to build up a map, that has to be up-to-date and for best at no additional costs *smile*. How to achive that? I think, it is achieved by a mechanism, I call…

Swarm-Mapping

Swarm-Mapping procedure

Apple has sold milllions of GPS-trackers (they call them iPhone) with additional mobile-/WiFi-chips. They can rely on a lot of iPhone users out there to provide data, even not knowing they do.

In general Swam-Mapping consists of three steps:

    1. Collecting data from enabled (and available) signal sources when CoreLocationFramework is active
      • on the iPhone recording current GPS-position and surrounding Cell Towers and Wi-Fi-hotspots infos
    2. Submitting the collected data to Apple
      • where the data is consolidated with already collected location informations from other iDevices
    3. Providing Data back to the iDevices
      • when requested from different location-based services.

I would like to provide a simple example for the consolidation process:
Lets think of three people on their way home… They do not use the same, but nearly the same way, receiving the same cell towers and Wi-Fi hotspots. With collected GPS data from different positions it is possible for Apple to refine the position for every seen radio source.
Now imagine thousands of people (maybe also the same user on the way to work the next day) providing location data for the same radio transmitter from different GPS-locations again and again.

iPhone Tracker – Pete Warden

http://petewarden.github.com/iPhoneTracker/

One of the first persons, who brought the attention on this topic to the people in the public, was Pete Warden. He and his colleague Alasdair Allan provided a tool called “iPhone Tracker” to display the location informations saved on an iPhone.

(Screenshot: iPhoneTracker, Pete Warden)

What does the tool do?

  1. It searches for the SQLite3-database “consolidated.db” in the mobile backup of iTunes
  2. extract informations from the tables
    • CELLLOCATION and
    • WIFILOCATION
  3. displays the geo-location information on a map in correlation to the timestamp, when the coordinates were received also regarding the amount of coordinates received for one certain timestamp.

My first experiences with iPhone Tracker from Pete Warden were, that

  • the tool isn’t using real GPS-Data from the iPhone
  • so the data are not accurate (why is there a grid?)
  • and the data-sources are not distinguished
  • the tool is not very user-friendly
  • only one timestamp selectable at a time
  • no resize of the window provided

I was quite dissapointed, cause it definitely was not forensic sound in any way! I then had the idea to develop my own framework. I’ve had already a tool displaying maps using the jxMapKit-framework for OpenStreetMap and another tool reading data from sqlite3-dbs. No big step to combine these tools into what I call a forensic suitable iPhoneTracker tool.

- Forensic Investigations -

my iPhoneTracker – first beta

My very first version did provide the following:

  • no grid alignment of the data
  • distinguish different data sources (CELLLOCATION, WIFILOCATION)
  • display specific timestamps

(Screenshot: iPhoneTrackerLE)

But more than that, I got a framework to examine data from a trusted, well known data source; my own iPhone. With this tool, I examined my different consolidated.db’s in correlation to my calendar ;)

I figured out, that there are more than just the consolidated-data provided by Apple used by Pete Warden’s iPhoneTracker. As stated above in the Swarm-Mapping chapter it is obvious, that Apple has to rely on location data of either celltowers or WiFi hotspots in order to provide an assisted GPS feature on the iPhone. They could buy the information from different providers, who have built up their own location-databases, but the problem is, that the location of the antennas or devices are not published by mobile carriers (celltowers) or are not known generally (WiFi hotspots). Beside that, the location informations are not totally static. Provider add celltower antennas and private people change their WiFi-hardware without informing anyone *smile*. So why not collect the data with the help of millions of iPhones all around the world? Brilliant! Ok. I mentioned that already.

From a forensic point of view, both kind of entries (received from Apple / recorded by the iPhone itself) exist within the database and need to be examined towards their forensic relevance. I will go into detail on that just in a minute.

For now, it can be stated, that neither the iPhoneTracker provided by Pete Warden nor actual commercial forensic products are usable in court regarding the forensic reliability of tracking informations!!!! (If you disagree in this; feel free to shoot an email or a comment to me; as long as you provide your product name and a free evaluation copy *cough*)

- Location Data provided by Apple (I) -

CellLocation, WiFiLocation

I further examined the data provided from Apple:

  • CELLLOCATION
  • WIFILOCATION.

At first, I took a closer look at the table data:

Both tables provide nearly the same information:

  • an Individual Representation of the source for later location estimation
    • MCC, MNC, LAC, CI (for celltowers)
    • MAC (for WiFi hotspots)
  • a Timestampin CFAbsoluteTime format
    • when the location information of the device was retrieved,  that is, when location services were used and the location daemon needs to be updated.
  • the Location of the device
    • Latitude, Longitude,
  • the Horizontal- and Vertical- Accuracyof the device
    • to be interpreted as the transmitter range of the device (therefore celltowers do not transmit vertical, so the value is -1.0, many WiFi hotspots do have more than one antenna to provide a more all around transmitting range)
  • the Altitudeof the device
    • the Altitude of celltowers is 0, because the greater divergence resulting of a higher transmitting range
  • Speed / Course
    • not used
  • and the Confidenceof the source
    • to be interpreted as the reliability of the source
    • 50-70 for celltowers, maybe in relation to the consolidation experience from Apple
    • 50, “to be or not to be”, or 50% of reliability

Experiences and Problems

From what were my first experiences and from a forensic point of view, the location entries provided from Apple (CellLocation, WifiLocation) are not usable at court! One main problem is, that the entries in the table are derived from Apple as base information to the actual position estimation process. The data is not retrieved from the built-in GPS-sensor (the device itself).

There are several other problems, which I would like to outline:

There is no exact position of the device or user at one specific timestamp

The result data is not presenting only one location of the device at a specific time, but rather a set of cell towers or Wi-Fi hotspots around the estimated position of the device.

The center point is a rough estimation of the location, but not guaranteed. (The blue arrow describes the route I took with the car, the red cross the location I have been at that time)

The estimation of the actual position can be derived from other available sources

One of my suggestions is, that the iPhone uses the location of the actual used celltower or an estimated location of the IP-address you are using over Wi-Fi, when the GPS-signal is not available inside a building.

The red cross is the location I resided at the selected timestamp.

The result data from Apple might also include unconsolidated data

for instance, when Wi-Fi hotspots got “moved” or because cell tower antennas are not reachable from every direction.

The figure above shows the recorded Wi-Fi hotspots the day I was at the Cebit fair 2011 in Hannover, Germany. There were a lot of exhibitors from all over Europe, who used their own Wi-Fi hotspots which were formerly consolidated to their home-/ business-location. For that reason it is explainable, despite of residing in Hannover without moving to other countries, the iPhone saw MAC-Addresses from devices, all over Europe. Some Wi-Fi hotspots were even reported at locations in India and Asia!!

It would have been interesting to observe, if the hotspots would get consolidated through Apple to show the actual location in Hannover right the day after. But this is not the scope of this article. It is just another example, that it is not possible to get an exact movement profile of an iPhone user with that source of data (CellLocation, WiFiLocation). But maybe, there is more inside the database…

- Location Data collected by the iPhone itself -

Swarm-Mapping how it actually works

As I further examined different consolidated.db files, I came across a table containing 2401 timestamps from only one day with only one location-information for every timestamp. The data shows exactly the route I took, and the timestamps were recorded with an interval from seconds. I used Navigon MobileNavigator to navigate…

So: It is obvious, that Apple (or better: the LocationDaemon) records tracks of its users (*smile*)

The problem with these tracks: the waypoints do not contain any references like cell towers or WiFi hotspots to be consolidated and useful for others. But: There exist the so called “harvesting”-tables containing much less, but more interesting data. According to the timestamps and waypoints recorded in the CellLocation-table, the data in LocationHarvest and WiFiLocationHarvest save cell towers and WiFi hotspots seen from the actual GPS-position.

Harvesting Tables

As stated before, Apple needs to get data from users to build up the consolidated database. In summary, there are three different harvesting tables:

  • LOCATIONHARVEST (GPS-position recorded from GPS-Applications)
  • CELLLOCATIONHARVEST (strongest cell tower seen from the actual GPS-position)
  • WIFILOCATIONHARVEST (strongest WiFi hotspot seen from the actual GPS-position)

These tables usually do not contain any data due to the fact, their content gets deleted right after the data is successfully submitted to Apple. As for iOS 4.3.3 and later, the data gets submitted to Apple, as one of the first actions, when there is a WiFi-connection available. As far as I can say, the data is not transmitted over a mobile service network connection cause it would stress the mobile plan and would definitely mean more bad press for Apple. For safety, one of the first actions when seizuring an iDevice definitely is to put it into “flight mode”!

So: most of the time an investigator examines the harvesting tables, they might be empty. Nevertheless, I had luck to preserve a well populated consolidated.db before the transmission process towards Apple cleaned up the tables.

LocationHarvest

The table records the following information:

  • an individual Timestampfor every location with very short intervals
    • in CFAbsoluteTime format
  • Latitude, Longitude and Altitude values as expected for a location service
  • Horizontal- and Vertical- Accuracyvalues
    • maybe used for describing the exactness of the actual position information
  • navigation information like
    • Speed in m/s and a
    • Coursein degrees of direction meaning
      • 000 = north
      • 090 = east
      • 270 = west and
      • 180 = south
  • Confidence seems to be 90 all the time, which means, that information from the GPS-sensor seems highly valuable for the location service
  • TripId and Context maybe for internal use, though they are not reused in other harvesting tables as far as I can say, don’t know what they describe exactly

Within the tables I investigated, there weren’t more than the maximum of 2 routes recorded due to the fact, that after submitting the data to Apple, the data gets deleted as stated before. But this might be different, for a device seized on a journey with no possibility to transmit the information over WiFi. So put the device in “flight mode” right after seizuring the device!

CellLocationHarvest

The table records the same information as the CellLocation table:

  • an Individual Representation of the source for later location estimation
    • MCC, MNC, LAC and CI
  • a Timestampin CFAbsoluteTime format
    • describing the time, the GPS-position of the device was recorded
  • the Location of the device
    • as Latitude, Longitude and Altitude values
    • determine the location of the iPhone itself, not the celltower
  • Horizontal- and Vertical- Accuracyvalues
    • to be interpreted as the maximum derivation of the GPS-data
  • and the Confidenceof the source
    • to be interpreted as the reliability of the source
    • with 90 as the highest possible information cause of GPS

as well as additional information like:

  • the mobile Operator
    • in my case t-mobile Germany
  • the BundleId
    • naming the application, which is to be the source of the information
  • and navigation information like
    • Speed in m/s and a
  • Coursein degrees of direction meaning
    • 000 = north
    • 090 = east
    • 270 = west and
    • 180 = south

Keep in mind, that the presented geo-location is not the position of the cell tower itself but the location the device resides at the time, when the different cell towers were seen. This is exactly the same with the data recorded within the next table…

WiFiLocationHarvest

The table records the same information as the WiFiLocation table:

  • an Individual Representation of the source for later location estimation
    • the MAC-adress
  • a Timestampin CFAbsoluteTime format
    • describing the time, the GPS-position of the device was recorded
  • the Location of the device
    • as Latitude, Longitude and Altitude values
    • determine the location of the iPhone itself, not the celltower
  • Horizontal- and Vertical- Accuracyvalues
    • to be interpreted as the maximum derivation of the GPS-data
  • and the Confidenceof the source
    • to be interpreted as the reliability of the source
    • with 90 as the highest possible information cause of GPS

as well as additional information like:

  • the transmitting Channel
  • a flag describing the Visibility
    • Hidden: 0 = no, 1 = yes
  • the transmitting power
    • RSSI in decibel (?)
  • an Agevalue
    • (?)
  • the BundleId
    • naming the application, which is to be the source of the information
  • and navigation information like
    • Speed in m/s (in the case above 0) and a
    • Course of -1

CellLocationLocal

Last but not least, I discovered another table called

  • CELLLOCATIONLOCAL.

I invested quite some time to think about the data stored in this table. And I was to release this article with the words: „I don’t know what this table is all about“. The columns of the table look the same as in CellLocationHarvest.

The table contains only one entry most of the time, which is not updated to often.

But there is a major difference to CellLocationHarvest: Obviously, at least one entry preserves the WiFi-transmit of data to Apple. Because of that, I think the stored data might be also used by other applications for getting a faster GPS-fix. But only Apple knows for sure ;)

- Location Data provided by Apple (II) -

Back to the beginning… As I stated before, the main problem with the location data retrieved from Apple is, that there are always several location-entries received from Apple for one single timestamp entry. It would be nice to figure out one single geo-location at one timestamp.

I tried out different techniques:

  • the first entry,
  • the last entry,
  • the average over all points.

It was obvious to me, that it would not be an exact GPS-position, because from the idea of swarm-mapping I have, the actual position is calculated from different sources according to the different signal strength received. But one of the entries has to be at least in the range of the iPhone mobile or WiFi connection.

To figure it out, I combined different sources. As you can see below, there is a gps timestamp quite in the middle of the set of WiFi hotspots. The question is: which one fits best concerning the GPS position?

Is it the first, the average or the last entry for that timestamp… what would you guess?

Well. Long story short: for implementation aspects, it is very easy to take the first entry from every timestamp. After applying the horizontal accuracy value (range in meters) for this hotspot, you even get a better idea of where the iPhone has been.

From my further research, it has to be stated, that there is no general rule, which entry in the set of location-data retrieved from Apple fits best. In most cases the first entry, with horizontal Accuracy applied, gave the best results.

Conclusion

Position estimation helps a lot, but validating every timestamp still is necessary!!!!!!!!

My latest experiences regarding position estimation from consolidated-iPhone-data:

  • WiFi hotspots are very accurate (small transmission range), but may sometimes “move”
  • Cell towers are more stable concerning their positions but have greater transmission ranges

But if there are real GPS-informations from the harvesting-tables, you should prefer to look at them.

Thanks for reading this far and feel free to shoot my an email or leave a comment!

What else??

In the meantime I finished iPhoneTrackerLE v. 1.7 with great features like

  • using GPS-values recorded directly from the iPhone itself with course direction applied (I don’t think anyone else has included that in an iPhoneTrackingTool or Forensic Suite?!)
  • position estimation from Apple provided data (I did not see anyone else featuring this; all the other tools provide is a horrible amount of data to every timestamp)
  • providing the horizontal accuracy (the transmission range), which indicates even better, where the iPhone has been
  • internationalization (english, german) (help me to provide even more languages; all you have to do is to translate about 100 words…)
  • some minor bug-fixes

I will provide iPhoneTrackerLE FREE for LawEnforcement agencies through a download from a restricted website. You may contact me by mail: 4rensics@gmx.de or leave a comment.

See also my post on Android Tracking – from a forensic point of view


Mobile Phone Forensic Challenges

0
0

Introduction

A great number of the mobile phones used worldwide every second require special knowledge and skills from forensic experts.  More often it is not enough to be an experienced expert in computer forensics to understand all the peculiarities and difficulties of the mobile forensics. This article describes technical problems encountered by specialists in mobile forensics.

Operating systems and manufacturers    

Market share of the end user desktop systems is divided between three majors – MS Windows, OS X form Apple Inc and OS Linux variations. That’s the opposite way round for the mobile devices OS systems. Each year brings to life a new major while the previous year leaders can easily lose their positions under a swift thrust. At the moment mobile OS market share shows the following casting: Android OS – 52,5%, Apple iOS – 16,9%, BlackBerry OS – 11%, Symbian – 16,9%, Microsoft – 8,7. We can easily track the fundamental changes in comparison with the market allocation settled two years ago: Android OS – 3,9%, Apple iOS – 14,4%, BlackBerry OS – 19,9%, Symbian – 46,9%, Microsoft – 1,5. Despite the fact that all OS offer (approximately) the same functions and options, they differ considerably in the ways of the data storing and access rights as well as security and other settings and characteristics. For example, Microsoft Company produces two OS – Windows Mobile and Windows Phone. These two operational systems can be even rated separately. Both OS are the work of the one developer, and Windows Phone OS is actually a successor of the first one, but that is where the pattern similarity ends.

Among the above-listed iOS and BlackBerry OS only can be marked as proprietary operational systems, and Apple Company – the only one who uses the same OS for all the produced devices (BlackBerry released their new Playbook based on QNX and is planning to use it in all its brand-new smartphones in the nearest future). That means that mobile phones produced by other manufactures can be based on almost all existing OS. For example, Samsung Company, one of the world market leaders, produced and is still producing mobile devices based on Android, Symbian, Windows Mobile, Windows Phone operational systems as well as on proprietary Bada platform. Another market leader – Nokia – has also produced millions of the devices based on their proprietary operational system in addition to an old favorite – Symbian OS and a new one – Windows Phone. Besides one cannot but pay attention to the unestimated Chinese market with its dozen of operational systems, hundreds of manufactures and thousand of models.

All this turns the world of mobile phones into a huge diverse zoo, where it is really hard to identify its individual representatives. Sometimes you cannot even trust the manufacturer’s name marked on the phone. Devices from the Chinese company Nokla replicate the look and even the name of the models from Nokia, but have nothing to do with the originals in their OS. For Samsung and LG companies it becomes a common practice to produce models that are virtually indistinguishable in appearance, but use different operating systems.

Connection issues

So, to connect the phone an expert has to choose the right model from the long list of thousands names. The most smart software tools are ready to make life easier for the expert and determine the plug-in model type. Alas, this will work for the USB connection only (the most popular though). It is worth noting that most of the popular mobile forensics tools work under Windows OS only, and in this case the effect is smoothed over by the fact that before connecting the phone one must install the appropriate USB-driver. Searching this driver can be a real headache as the expert receives the phone not in a new box with a CD attached. Visiting the manufacture’s site cannot always be a solution, especially when the phone model has been already taken out of production. It is not so hard to connect mobile devices produced by Apple, Nokia or Motorola In most cases to be able to work with all phones manufactured by the company only one driver should be installed. The opposite situation is with phones based on Android OS. On Google site, developer of the operating system, you can download the official driver (also included in the Android SDK). This driver works with phones branded by Google only (Nexus, Nexus S, Nexus 3), as well as made available to developers as a reference (eg, T-Mobile G1). Drivers for all other devices have to be found on the Internet. Fortunately many forensic tools usually include a driver pack for all supported models. If one computer has several mobile forensics products installed, the expert must be careful as the driver packs from different vendors can have older versions of drivers which can interfere with each other. In addition, Windows x64 will most likely need a separate version of the drivers.

Some words should be also said about the software products designed for Mac OS. Despite the fact that there is no Windows-like problems with drivers for Mac OS, almost all products (Lantern, BlackBag) supports Apple devices only and are not of any help with other phones. Therefore, the choice of universal products is limited by Windows software only.

Along with searching for a appropriate driver comes another problem – searching for a appropriate cable. Most modern phones use miniUSB/microUSB connectors for the cable connection. Relatively old models as well as devices without official cable connection require custom cables. Most manufacturers include a set of cables in the package. Usually this cables cover over 90% of the supported phone models. Besides these cables are usually interchangeable and it is possible to use particular software with cables that are included into the other software package.

Most modern phones are also equipped with Bluetooth and WiFi modules, providing a wireless connection. If a USB connection is impossible (connector is damaged, it is impossible to find a cable or a driver) Bluetooth/WiFi connection is the only way to retrieve data from the phone. Unfortunately, no software is able to read data via Bluetooth from devices based on Apple iOS or Android OS. None of the tools uses WiFi as a data transfer.

Logical vs Physical

Nowadays common classification of the data extraction distinguishes two approaches: physical and logical. The physical approach performs data extraction at a low level (often with the help of special hardware equipment). The logical approach uses communication protocols offered by the phone at a higher level. Advantages and disadvantages of each method are quite clear. The physical method allows to obtain the contents of the entire phone memory as is. But usually it is time-consuming and requires complex and expensive equipment. As a result we receive the “raw” image which is encrypted in most cases. Even if you are lucky to decrypt an image (nobody has been able to do this with BlackBerry, f.ex.), further analysis can be made by means of special sophisticated software tools only. Using a logical method allows to obtain data in a human readable form immediately. Unfortunately the amount of acquired data is much lower. This is because the API provided by the phone were not developed for forensic purposes but to operate the phone as a modem, as well as to synchronize data with desktop PIM.

In 2004, Oxygen Software Company introduced a new method which allowed to highly improve the quality of data extracted with the logical method. The method consists of installing a specially designed application (so called Agent) into the device which uses all the possibilities offered by the operating system and returns information not available through standard API, but really forensically important – logs, temporary files, cache, deleted data, etc. Sometimes the Agent helps to simplify as well as to accelerate the process of the device connection and data exchange.

Several years ago this method raises serious doubts about the forensic compliance. Indeed, the main principle the phone data invariability is violated. In fact the user data remains unchanged (with specially designed agent). Actually the phone can’t be “frozen” if the phone is turned on. Modern smartphones are mini PC-like with a fully functional OS with dozens of processes launched at the same time (even if they were not started manually) and all of them use the device’s RAM and file system constantly. For example, the Symbian OS system process is responsible for the calls log, and even if you put the phone based on Symbian OS into a Faraday bag and close all running applications, then after some period of time all the old log entries will be deleted.

Indeed the use of standard logical methods for data retrieval even more dangerous than reading it with an agent. The fact of the matter is that the appropriate process controls the data exchange from the phone – in fact, the same agent. But in contrast to “our” agent, we do not know about its side effects. The source code is usually unavailable, and data reading is often performed through the synchronization process (which potentially threatens major change in the user data). Moreover, the phone may be based on an old OS version which does not allow to read all available information, and the solution will require all software updating in the phone. Forensic agent lacks these drawbacks.

As a result, mobile forensics world has recognized this method as trusted and now it is used by almost all mobile forensic tools developers – Cellebrite, .XRY, Paraben, etc. It should be noted that this approach is only one possibility for the logical data retrieval from Android OS devices. Such applications are widely used for Symbian OS and Windows Mobile devices.

Software assessment. Which tool?

Nowadays market is represented by more than a dozen software and hardware solutions for the mobile devices data extraction and analysis. For data reading many of them combine physical and logical approaches. So, the obvious question – which one to use?

Unfortunately, the analysis of the product descriptions given on the developers’ sites does not give a clear understanding of the software functions and features. First of all, there is a confusion of terms, and “support for more than seven thousand profiles” actually means support for the 3000 models (taking into account the different ways of data extraction from the same model and identical models under different brands). Secondly, the stated support for the certain manufacturers’ products does not imply the support for _all_ the models produced by them. Often, a detailed description of what can be read from a device is not indicated for each model, but for the entire range of models. Investigators must not forget that support for a particular function can be implemented at different levels. For example, MMS messages can be just read as container files. After that an expert must find (it is necessary to know file system specifics of the particular model) and decode them (there are several common as well as proprietary formats for MMS encoding). Usually the support level is not specified in the description.

Reviews and tests conducted by NIST as well as various independent experts (for example, viaforensics.com) come to the experts rescue. It is not hard to find the detailed comparison of the results of the software interaction with Apple devices. But one should be lucky enough to find a review on a specific model while talking about mobile phones produced by Samsung or Nokia companies which released more than a hundred models (compared with ten from Apple).

Which one to choose? Forensic practitioners experience shows that it is impossible to apply just one product for all occasions. Taking into account the budget, experts have to use a set of several means and choose the most appropriate product in each very case according to their own experience and community advices. The image taken from a modern device can measure tens of gigabytes (for example, iPad 64 GB). As a result software features on the analysis of the extracted data become the major priority. Today, all software products use more or less the same methods of data extraction from devices, and no less important are the speed, completeness and depth of analysis of extracted information.

Conclusion

In addition to issues of forensic examination purity, the examiners have to deal with absolutely technical problems starting with identifying the manufacturer and operating system of the specific phone. Great variety of the modern phones makes this a real challenge. When choosing a software for the investigations it is important not only to be fully aware of what data is available and not available for extraction from the device in principle, but also how much of these data can be retrieved and processed by the specific software.


Android Forensics

0
0

 Smartphones are changing the IT and Communication landscape vastly.  A Smartphone can do almost every good thing a computer can do. Today most of the corporate employee access and manage their official emails through the e-mail client installed on their Smartphone.

Right from booking movie tickets to making fund transfers, all e-commerce and online banking transactions can be done using a Smartphone. With high speed of 3G, Smartphones are getting more popular specially among working professionals and students.

As Smartphone market is growing, it is also catching bad guy’s attentions. For bad guys or hackers, it is easy to target mobile users as they are less aware and bother less about the risks associated with the mobile and mobile applications.

There are number of Mobile Operating Systems present in the market. Among these Mobile OS, Android, iOS and RIM are more popular than others. Android is the most widely used Mobile OS present in the market. According to Gartner report, Android had more than 36% share of the market by end of the first quarter of 2011.

It is quite obvious that the widely used platform is likely to be targeted more, as in the case of Microsoft Windows Operating System. A hacker wants to target mass and for doing that he has to target the most commonly used platform. Android is one such commonly used platform. As Android is capturing market, it is becoming favorite target platform of hackers.

It is always a challenge for forensic examiners to discover the evidences from the Android devices. Android   has   a   different   and   newer   file   system, directory structure, runtime environment, kernel and libraries which make Android more complex to forensic examiner. We will discuss detailed forensics steps to examine Android device in later part of this article.

How Android can be used in Cyber Crime

Android can be used in cyber crime in two ways:

•   Android device is targeted by the attacker.

•    Android device is used as a means to carry out cyber crime.

Let us consider some of the real world cases. What if an Android device is discovered from a crime location?? What   all   evidences   can  be   discovered   from   the device?? Where exactly to look for the evidences??

These are some challenges faced while doing forensic analysis on Android device. First we will see what all bad things can be done with the Smartphone (or how a Smartphone can be used in various criminal activities).

Cyber Crimes through Smartphones

Software Theft: Software theft is now a common attack. If codebase of your software is stolen and sold to your rival, he can make a great loss to your company. Your rivals are ready to invest huge money to obtain source code of your key software.

A Smartphone can carry large volume of sensitive data. It can be used in carrying codebase of any key software of any company. There are security guards and other mechanism in place to check the employees and visitors, if they are carrying any business critical information in any form. But still they hardly check for Mobile phones.

In one classic case of Software theft, an unhappy employ of a company used to carry all source code of the key software of the company in her smart phone. She first copied the code in her phone’s external storage and then deleted the same data from the phone. When her phone was observed at security check, nothing was found in her phone. When she reached home, she used a tool to recover the deleted data. This way she took all the data out from her company and latterly she sold the source code to the rival of her employer.

Terrorist Activities: Terrorists also use Smartphones to exchange and store the information. They use Smartphones to communicate with the other member of the terrorist organization. They  also  use  GPS  to find locations. They can store various data in the Smartphone like maps or photos of target locations, encrypted and stagno files, instructions etc. They can use the phone to click photos of target locations.

Pornography/Child      Pornography:      Pornography is fully banned in a number of countries. And child pornography is considered a big offence across the world. Smartphone can be used to store, view, capture and exchange such kind of materials.

Sexual Harassment Cases: Smartphone can play big role in sexual harassment kind of cases. If a Smartphone is discovered from accused, a forensic examiner can get treasures of information from the device.

Financial Crimes: Every other bank is developing banking and other non-financial application to facilitate their  mobile  customers.  These  applications  can  be used for malicious activities by hackers. A Smartphone recovered in financial fraud cases can give many evidences about the case.

Murder Cases: Even in murder or other criminal cases, a Smartphone can provide evidence useful in solving the case. Right from call records and SMSes to facebook records or GPS data can be recovered from the phone.

Let us think about, what all evidences can be recovered from a Smartphone?? Where to look in the Smartphone?? We will discuss in coming section that what all evidences we can discover from a Smartphone:

Interesting locations for Forensics

Investigation

•   Phone Browser Memory

•   Application storage

•   External Card

•   SQLite database files

•   SMS

•   GPS data

•   Call records

•   Contact list

•   Social  networking  application  (Facebook,  Twitter, Orkut) records

•   Messenger (Yahoo, MSN) records

•   Email client data

•   System storage

•   Data stored in external card

How investigation of Android device is different than other   Smartphones??   Does   forensic   investigators really need to learn something special to analyze Android devices?? Can evidences be discovered from the device?? Are they admissible in the court of law??

Next section of the article will answer all the above questions in further detail.

Forensic Process of Android Device

Forensic process of Android phone will comprise of following steps:

Seizing Android device: If an Android device or any Smartphone is discovered from any crime location, first thing a forensic investigator should do is to click the photos of the crime scene including the photo of the device. If phone is ON, take photo of display as well.

If you find mobile to be ON then keep charging the mobile  so  that the battery does  not  drain.  In  case, we don’t charge the phone and the phone goes OFF, we may lose the important data especially regarding current or recent applications. If phone is OFF at the time it was recovered, keep it OFF. Seize all other available accessories i.e. memory card, data cable etc.

As soon as we recover anything, start labeling it. It is required to maintain and present a chain of custody at the court of law. A label should have the following minimum information on it:

•   What is the evidence?

•   How did you obtain it?

•   When was it collected?

•   Who all have handled it?

•   Why did that person handle it?

•    Where has it travelled and where was it ultimately stored?

•   What is Case ID?


C
hain of Custody is a chronological documentation of individuals who had physical possession of the evidence. Maintaining the chain of custody is vital and it guarantee the integrity of the evidence, right from collection to the final test result. Chain of custody is something must to have document in any criminal trial. If proper Chain of custody has not been maintained, court may not consider that evidence in making final verdict.

Creating 1:1 Image

Creating image is the most important task in any forensic analysis. It is the thumb rule in forensic investigation that you cannot work on primary evidences if you want them to take in the court of law. For that we need to create bit-by-bit image of the target device.

What is bit-by-bit image and how it is different from the copy-paste the content of entire disk??

If we copy and paste the content of a disk, this will only copy visible, hidden and system files. Whatever is deleted or not accessible by the OS would not be copied by copy command. So, for a thorough analysis, it is required to create a 1:1 image of the disk. Bit-by- bit image is as good as the original image. Thorough analysis is not the only reason we need to take 1:1 image, it is also required by the court of law. If you have not taken 1:1 image, your evidences are not admissible in the court of law.

How  we  will  take  image  of  an  Android  device?? How I can verify that my image is exact bit-by-bit copy of original disk or device?? How can I establish the authenticity of the image??

There are two locations to be taken image of in case of Android device. One is the device and other is the external card. We will see in following section that how to create a bit-by-bit image of the Android device. But before that we will see how to verify the image.

Before starting the imaging of original disk, calculate the hash value of it and note that down. Now after taking image, calculate the hash value again for the image. If hash values are same for both the image and disk, we can be sure that we have taken exact image of the original disk. Now we can work on image and evidences discovered from the image can be taken to the court along with the hash values calculated. The hash value establishes the authenticity of the image that it has not been tampered.

One more thing we should take care of before creating image is to make the target device in write protected mode. Whenever you connect any device to your computer, there are chances that some data can be written on the devices by any software, application or OS. In that case your evidence (device) is no more genuine. Just to avoid this kind of situation, make the disk or device write protected. To do that, use write protected cables present in the market. In this article, we will  make device write protected  by  software  to explain the technique.

Creating image of external memory card: We will start with simpler part of imaging, which is creating image of the memory card. In most of the cases, file system of the memory card is FAT32 and it is easy to image. There are lots of free and commercial tools available in the market which can help us in creating image of the memory card. We will use free version of Winhex to do that. Winhex is a powerful forensic tool. It is available in both freeware and commercial versions.

Note

Only commercial tools should be used to discover the evidences in case you want to take evidences to the court.

Here are the detailed steps to take the 1:1 image of the memory card:

First remove the SD card and connect the card to the computer with any card reader. Now we will make the device write protected through Winhex. Follow below step to do that: Open the disk in Winhex: Figure 2.

Go to Options then Edit mode and select first option

write protected mode:

Now calculate the hash value for SD card.

To calculate hash, go to Tools then Compute hash and choose any H ashing a lgorithm. We have t o compare this hash value w ith the hash value computed earlier for the image. Now we create the image of the disk. Go to File menu and click on Create Disk Image option for creating an i mage. C hoose Raw image option (.dd) t o create image, as dd image i s interpreted by a lmost a ll commercial and open source forensic tools

Image o f memory card is c reated. W e will use t his image for analysis in later part of the article.

Creating Image of Android device

This  is a   tricky  part. A ndroid  does  not p rovide  any direct w ay t o access o r view i ts i nternal d irectories or system f iles  and d irectories. B ut i nternal o r  system locations may have most critical data stored. Almost all applications write some application data and temporary data in t hese d irectories only. /data/data i s the most interesting location for the forensic investigator which is not accessible to the user. Only application or root users have access to these locations.

How w  e   can   access A ndroid   internal d  irectory structure?? H ow t o create the image o f the Android internal directory structure??

For t his we need t o obtain ROOT permission o n the

Android OS. In Android terminology, we need to ROOT the device t o get t he superuser permission. There are various techniques available in the market that can help you in rooting your Android phone. Among them, Odin3 software is one such popular tool. All you need to do is to check the build number of your phone. You can check it by visiting the following location in any Android phone: Settings-> About Phone-> Build number. Now Google for the rooted kernel for this build number and pass all the files to Odin3 software. This way you can ROOT your phone. There number of good tutorial available in the market on Android Rooting. As per my knowledge ROOTING is legal and it does not void any warranty. Still check local laws before rooting your phone. I have never come across such situations; still it is a general belief that rooting may harm your system or you may lose your entire data stored on the phone.

Note

In the rooting process, something will be written on target device and as I mentioned earlier, we can’t write anything on the phone, if we want to take that into court of law as evidence. The method and technique explained in this example may not be accepted by the court. In this case, one can take approval in advance from the court. That is again subject to local laws. So now we have root access on the phone, what next??

As it is known to all that Android uses Linux kernel

2.6.  By  downloading  Terminal  Emulator  application from the Android Market, we can run almost all Linux commands. So, to create image of device, we will be using dd command. DD stands for Data Description, it does low-level copying of data in Linux. The dd command will help us in creating bit-by-bit image of Android device.

To take backup, insert a fresh SD card in device and copy the target data there. Typical syntax of DD command:

dd if=/dev/fd0 of=tmp.image

Where if is input file and of is output file. Again, output of the dd command is understood by all commercial and open source forensic tools including WinHex, EnCase, Helix, Forensic Toolkit etc.

To take the backup of the Android system folders, go to /proc/mnt file and open the mnt file.

dev:   size  erasesize name mtd0: 000a0000 00020000 „misc” mtd1: 00480000 00020000 „recovery” mtd2: 00300000 00020000 „boot” mtd3: 0fa00000 00020000 „system” mtd4: 02800000 00020000 „cache” mtd5: 093a0000 00020000 „userdata”

Copy one by one location through DD command.

To understand the concept, we will be copying some directories with dd command.

Recovering Data

Now we are done with the imaging part. The image created in above steps can be accepted by any forensic tool. We will be using free version of Winhex to recover and analyze the data as well.

In   most   of   cases,   criminal   deletes   suspicious data or even format the entire disk. Suppose in any pornography related case, we hardly find anything in the device, because all data has been intestinally deleted. So, before starting analysis part, it is recommended to recover all deleted or destroyed data first.

To recover deleted data, open the image file in Winhex. Go to File menu then Open option, select the image file and click ok. Figure 7 show the opened image file.

As  we  can  see  from  the  above  screenshot,  all data is represented in hex form. To make the data understandable, we need to interpret the image as disk. To do that, go to Specialist menu and click on Interpret Image File As Disk.

Folders highlighted in the Figure 9 are the deleted folders.

To recover deleted files or folder, right click on target folder and click on Recover/Copy and select location to save the file.

There are number of tools available to recover deleted or destroyed data. All well known forensic tools

like FTK or EnCase have inbuilt feature of identifying and restoring deleted data.

Analyzing the Data

Analyzing Android data is a bit different; one should know the important locations to be checked out. More manual intelligence is required in this step of forensic analysis of Android device. For example, in case of money laundering related cases; email, browser data and banking application related data must be looked at to discover any clue. Same is true in the case of sexual harassment case; emails, social networking data, SMS will be interesting locations to search for evidences.

For example below file was recovered from Skype application. I have used same dd command to recover this file. The format for this file was .DAT. I have opened this file in a text editor (notepad in this case). You can see email addresses, Skype ids, chat records; everything in plain text. Same way you can get useful information from other applications like Facebook, Yahoo Messenger, Twitter etc. All application related data can be found at the following location:

/data/data/com.application/;

Analyzing SQLite database files

SQLite database files are most interesting files for forensic investigators. One will get most critical information  here, even username  and  passwords  in some cases.

SQLite is a lightweight database (RDBMS) and used by almost all Smartphone OS like Android, iOS and Blackberry. SQLite files can be found at the following location:

/data/data/com.application_name/databases

For example we want to see all SQLite files created and maintained by Facebook. Then we need to look at following location for db files:

/data/data/com.facebook.katana/

databses

All SQLite files stored with .db format.   I   have   copied   a   few sample .db files (from Facebook, email client etc) using dd command to explain analysis of SQLite database files.

To  understand  the  concept,  I will be using free version of Epilog tool. Epilog is a powerful tool for all kind of SQLite files.

Open  a  db  file  in  Epilog  tool, in this example we are opening fb.db (Facebook db file). Check Do Generic Record Extraction checkbox and click on process. You can observe in above screenshot, fb.db file contain some really useful information. In our case, we can see full names, email ids, phone numbers of the friends added in Facebook friendlist of the suspect. By opening the correct db file, we can even find all the chat logs, personal messages and other details. In some cases, you may even find username and password stored in a SQLite files.

viaExtract Tool

There are a number of good forensic tools available in the market, out of them I found viaExtract tool to be very useful and easy to use for Android forensic. This tool is specially meant for Android forensic by viaForensic.

In this tool, you just need to connect the phone to the machine where viaExtract is installed. Phone should be in USB debugging mode. To make phone in USB Debugging mode, go to Settings-> Applications-> Development and select USB Debugging mode. Now you just need to click Next and tool will recover and analyze the device. As an output, you get final reportwith all the useful information like Contacts, SMSes, IM records etc. Figure   12   shows   the   HTML report  from  viaExtract  tool,  we cans see all SMS details here.

Note: Even viaExtract will write something on the device.

Reporting Evidences

Reporting has to be done on case to case basis. There are different ways of reporting evidences in corporate cases and criminal cases. Reported evidences should be clear, give direct or indirect reference to the possible scenarios of crime.

In a criminal case, where we want to present evidences in the court of law, it is also required to map the findings with respective laws. In addition to evidences, it is also required to present Chain of Custody. Again reporting depends on country to country, as the Cyber Laws varies with geography.

Conclusion

To summarize, analyzing Android for  forensic  purpose  employs totally  different  techniques  than the traditional forensics. It involves

heavy manual intelligence and interference. Maintaining integrity of primary evidences is also a challenge. There are tools available in the market for Android Forensics but still there are gaps to be filled and a lot to be done in this direction. After learning about forensic process, it will

by MANISH CHASTA

Analyst, working with Indusface (www.indusface.com) as Principal Consultant. He is having more than 5.5 years of experience  in  Information   and  Application  security.  He  is currently  managing  team  of  security  engineers  and  doing a vast research in Mobile Application Security. He is also handling   prime   customer   accounts   for   the   company.   He has authored numerous security articles for ClubHack and Palisade. He has audited 200+   mobile and web-applications in the areas of Internet Banking, Core Banking (Flexcube), Finance, Healthcare, CRM, telecom  and eCommerce.  He has Security and Ethical Hacking to multiple clients. Email id: chasta.manish@gmail.com


Mobile Device Geotags & Armed Forces

0
0

In recent years it has been noticeable that the amount of people carrying a smart phone has increased exponentially. This is down to their low price and availability; even children as young as 12 have a smart phone. However, most people who own a smart phone are not aware of the data hidden in even the simplest and most innocent things they do on their phones. This includes armed forces staff. This article will look at the issues and possible repercussions of the availability of such easily obtained data.

Let’s consider a scenario:  in this case an armed forces staff member is on patrol. they take a picture of themselves and upload it to a social media. Their personal profile on this site is not secured or has limited access that allows anyone to view their photos. A militant group happens to be doing some research on their “enemy”. They use advanced search on Google then happen use the correct collection of words or phrases, and just happens to find this picture. What could possibly happen?

First off, the basics:

What is a geotag?

The method of geotagging is the addition of geographical data into the meta data of an object, in this case a picture that has been taken by armed services personnel.

A geotag on a photograph from an Iphone, for example, captures the GPS coordinates of the location it was taken using Longitude and Latitude.

Obtaining geotag information

Using free tools that are widely available on the internet it can take seconds to reveal the geotag information. It requires very little effort and absolutely no training. Ideal for militant groups who would want to find this information relatively quickly.

Below is an example and for this example I will be using a picture of the blue ball in snooker, but imagine this photo was a team photo taken in a base on foreign soil.

Here I’m using Evigator’s TAGView software

(available @ http://www.evigator.com/)

1 – Locate the image and open it using the Open Image Icon.

1

2 – Press Open

2

3 – The Image will be analysed and you will have a screen similar to below:

3

4 – Sample data from the analysed picture.

4

As you can see from the above, highlighted is the geotag data & various information about the device the picture was taken on. Also note the mapped location of where it was taken. To get this information was less than 3 seconds once loaded into the program. 

Security Risks & Repercussions

So what are the security risks? Well, as already pointed out the information could reveal any number of things: barracks, bases, patrol points or even patrol patterns. This information not only puts the staff member who uploads the pictures in danger but their entire deployment group.

Potential death is not the only issue, with profiles being insecure it could lead to that one member being profiled by the militant group, this then leading to potential blackmail, kidnap or endangering family members.

What should the armed forces be doing?

There are many things the armed forces could be doing. The key thing to do is offer the training necessary to remind their staff of the issues of geotags and smart phones. They could put a ban on any personal phones completely. However, some service men and woman would still find a way to take them into active duty.

A one hour basic training session that shows the dangers is all that is needed. The session could cover basic security settings of their social networking profiles and turning off the location services on any of their devices.

A one hour session could be the difference between life and death in most cases during deployment.

This article has been geared towards the idea of militant groups, however its not just militant groups, it could be anyone; stalkers, thieves, even an enraged ex could use these techniques.

 

Part 2 will be released soon. 



Geo-tag Forensics

0
0

Introduction

A geo-tagged image is an image which holds geographical identification metadata. This data consists of latitude and longitude co-ordinates (sometimes altitude also). Though there are some extremely powerful tools available for extracting geo-tag information from geo-tagged images but the insight knowledge of how a tool actually works and gets the data for us is always a plus.

We know validation is core of any forensics. One may use other tools and/or manually extract the data at byte level to validate the findings. This article exhibits how to go about parsing geo-tags of the images at byte level.

Collection of Geo-tag images

For the purpose of this experiment we took pictures from multiple devices such as

-          iPhone 3GS

-          iPod 4

-          Nessus 7

-          LG Optimus

-          HTC

We turned on the location service on every device in order to capture geo-tagged pictures.

It was interesting to note that in Nessus 7 did not have local camera application so the application ‘Cameringo’ was installed which has a feature to attach geo-tag in the pictures. Not all camera applications have this feature.

Geo-tag analysis of the images

-          Easiest and quickest way of checking geo location of a picture in Windows OS is to right click on the picture and select properties. Then under the detail tab, you will find the info.

-          One can also use tool to extract geo-tag and other metadata, for instance, exiftool is a free powerful tool.

-          One might have to validate or deal with cases where automatic recovery of geo-tag is not possible and manual parsing of raw image is required. This is what the article focuses on.

Manually parsing raw image

All devices that are used in this experiment found to have EXIF (Exchangeable Image File Format) standard of metadata logging.

Since the length and content of metadata (for example, make and model of camera, software, author, time etc.) vary from device to device, it is not surprising to see different starting offsets of geo-tag data. In other words, we could not find the consistency in the location offset of geo-tag in the image. But we did find a pattern to understand and get closer to the geo-tag offsets.

Scheme

We used following approach in our analysis.

1          Find the two direction letters i.e. N, S, E or W.

2         Then look proceeding offsets values for the pattern 00 00 xx xx  00 00 00 01 00 00 xx xx 00 00 00 01 a00 00 00 xx xx 00 00 64 or 00 00 03 E8. There is no predefined offset location to start with. The values are usually in big endian but we encountered a case involving little endian and reverse reading order.

3         Do your calculation and convert those values to something that makes sense.

Couple of things to keep in mind before jumping to calculation part are

-          Read set of 4 bytes for every value

-          The hex values given could be in big endian or little endian

-          00 00 00 64 = 100 decimal (Don’t convert it every time – a friendly advice J )

-          1 minute = 60 seconds

-          00 00 03 E8 = 1000 decimal

4         Use the direction letter for latitude and longitude respectively in order.

Proceeding sections demonstrate parsing of images from different sources.

Tools used

WinHex (any basic hex editor can be used)

Calculator (native application in Windows OS)

Image from iPhone

Offset          0    1    2   3   4    5   6   7    8    9  10 11 12 13 14 15

00001120   32 30 31 33 3A 30 35 3A  33 30 20 31 34 3A 30 39   2013:05:30 14:09

00001136   3A 31 39 00 32 30 31 33  3A 30 35 3A 33 30 20 31   :19 2013:05:30 1

00001152   34 3A 30 39 3A 31 39 00  00 00 31 8D 00 00 05 B1   4:09:19   1    ±

00001168   00 00 10 B9 00 00 05 A1  00 00 26 0D 00 00 05 26      ¹   ¡  &    &

00001184   00 00 00 4D 00 00 00 14  03 FF 02 FF 02 66 02 66      M     ÿ ÿ f f

00001200   00 0A 00 01 00 02 00 00  00 02 4E 00 00 00 00 02             N

00001216   00 05 00 00 00 03 00 00  02 CE 00 03 00 02 00 00            Î

00001232   00 02 57 00 00 00 00 04  00 05 00 00 00 03 00 00     W

00001248   02 E6 00 05 00 01 00 00  00 01 00 00 00 00 00 06    æ

00001264   00 05 00 00 00 01 00 00  02 FE 00 07 00 05 00 00            þ

00001280   00 03 00 00 03 06 00 10  00 02 00 00 00 02 54 00                 T

00001296   00 00 00 11 00 05 00 00  00 01 00 00 03 1E 00 1D

00001312   00 02 00 00 00 0B 00 00  03 26 00 00 00 00 00 00            &

00001328   00 1C 00 00 00 01 00 00  00 25 00 00 00 01 00 00            %

00001344   0B F4 00 00 00 64 00 00  00 51 00 00 00 01 00 00    ô   d   Q

00001360   00 17 00 00 00 01 00 00  15 53 00 00 00 64 00 00            S   d

00001376   34 E9 00 00 01 12 00 00  00 12 00 00 00 01 00 00   4é

00001392   00 09 00 00 00 01 00 00  00 13 00 00 00 01 00 04

00001408   1D 6F 00 00 03 74 32 30  31 33 3A 30 35 3A 33 30    o   t2013:05:30

00001424   00 00 FF E1 02 B0                                    ÿá °

Step 1

Scroll down till you find direction letter which is usually present near the date/time stamp. We found N and W.

Step 2

Look for the pattern 00 00 00 01 00 00 xx xx 00 00 00 01 … 00 00 00 64. Once the pattern is identified, find 4 bytes before the first set of 00 00 00 01 (highlighted with Turquoise) i.e. byte offset 1326 here.

Step 3

This is the most interesting step of calculation.

a)       Let’s start converting hex to dec from offset 1326.

00 00 00 1C => 28 and next 4 bytes are 00 00 00 01 => 1 (Divisor)

Thus the value of degree is 28/1 = 28.

Go to next 4 byte set whose value corresponds to 00 00 00 25 => 37, followed by another set of 00 00 00 01 => 1 (divisor). Thus 37/1 = 37 is the value of minutes.

Now calculating decimal value of seconds. Convert next 4 byte set 00 00 0B F4 => 3060. This set is followed by 00 00 00 64 => 100 (divisor). This time when you divide, you get, 3060/100 = 30.60 seconds.

This completes the latitude calculation which is 28:37:30.60

b)      We will continue, reading and converting the hex values for longitude and altitude.

00 00 00 51 => 81, next we have, 00 00 00 01 => 1. Degree is 81/1 = 81.

Then we have 00 00 00 17 => 23 and 00 00 00 01 => 1. Minutes comes out to be 23/1 = 23.

For seconds we have, 00 00 15 53 => 5459. Divisor is 00 00 00 64 => 100. Thus seconds is 5459/100 = 54.59.

Thus longitude is 81:23:54.59

c)       Similarly calculate altitude. The value we have in hex is 00 00 34 E9 => 13545. Divisor is 00 00 01 12 => 274. Altitude becomes 13545/274 = 49.4343

Step 4

Finally assigning the direction in order and co-relate the information from what properties is displaying in the below capture.

Latitude: 28:37:30.60 N

Longitude: 81:23:54.59 W

Altitude: 49.4343

iPhone

 

Image from iPod

Offset           0   1   2    3   4   5   6   7    8    9   10 11 12 13 14 15

00000512   00 00 00 05 32 30 31 33  3A 30 38 3A 32 32 20 31       2013:08:22 1

00000528   33 3A 32 37 3A 30 37 00  32 30 31 33 3A 30 38 3A   3:27:07 2013:08:

00000544   32 32 20 31 33 3A 32 37  3A 30 37 00 00 00 E0 FF   22 13:27:07   àÿ

00000560   00 00 30 FC 00 00 12 ED  00 00 07 7E 00 00 07 8E     0ü   í   ~   Ž

00000576   00 00 07 25 00 00 00 4D  00 00 00 14 00 07 00 01      %   M

00000592   00 02 00 00 00 02 4E 00  00 00 00 02 00 05 00 00         N

00000608   00 03 00 00 02 9A 00 03  00 02 00 00 00 02 57 00        š        W

00000624   00 00 00 04 00 05 00 00  00 03 00 00 02 B2 00 05                ²

00000640   00 01 00 00 00 01 00 00  00 00 00 06 00 05 00 00

00000656   00 01 00 00 02 CA 00 07  00 05 00 00 00 03 00 00        Ê

00000672   02 D2 00 00 00 00 00 00  00 1C 00 00 00 01 00 00    Ò

00000688   0D 90 00 00 00 64 00 00  00 00 00 00 00 01 00 00        d

00000704   00 51 00 00 00 01 00 00  04 D5 00 00 00 64 00 00    Q       Õ   d

00000720   00 00 00 00 00 01 00 00  38 FC 00 00 01 B5 00 00           8ü   µ

00000736   00 11 00 00 00 01 00 00  00 1A 00 00 00 01 00 00

00000752   13 3C 00 00 00 64 00 06  01 03 00 03 00 00 00 01    <   d

00000768   00 06 00 00 01 1A 00 05

Step 1

Look for direction letters (yellow highlighted).

Step 2

Identify the pattern (green highlighted).

Step 3

a)       Start with the set of 4 bytes, offset 678-681 (highlighted Turquoise).

00 00 00 1C => 28

Next 4 bytes 00 00 00 01 gives divisor, 28/1= 28 degrees

Count from offset 690-693, 00 00 0D 90 => 3472

Again the next 4 bytes gives divisor 00 00 00 64 => 100 and the value of minute will be 3472/100 = 34.72.

Note that we have minutes in decimal and we know that

I degree = 60 minutes

I minute = 60 seconds.

Therefore converting minutes to seconds as 0.72 * 60 = 43.2 seconds.

Since we have already calculated seconds by minutes here, next 8 bytes are of no use which is 00 00 00 00 00 00 00 01.

That completes our latitude calculation which is 28:34:43.2

b)      Moving forward to longitude bytes located at offset 702.

00 00 00 51 => 81 and 81/1 (next 4 bytes 00 00 00 01) = 81

Next, 00 00 04 D5 => 1237 and 1237/100 (next 4 bytes are 00 00 00 64) = 12.37.

Minutes = 12

Seconds = 0.37*60 = 22.2

Again, since the seconds has been calculated from the minutes, there is no separate 8 bytes for seconds calculation and you will see ‘00 00 00 00  00 00 00 01’ there.

Longitude is 81:12:22.2

c)       For altitude,

00 00 38 FC => 14588

Divisor is 00 00 01 B5 => 437

14588/437 = 33.38215

Step 4

Use the direction letters,

Latitude: 28:34:43.2 N

Longitude: 81:12:22.2 W

Altitude: 33.38215

Finally co-relating the findings from the one we get in picture properties.

iPod

 

Image from Nessus

Offset          0    1   2   3   4    5   6   7      8  9   10 11 12 13 14 15

00000144   00 00 32 30 31 33 3A 30  38 3A 32 32 20 31 33 3A     2013:08:22 13:

00000160   33 34 3A 30 36 00 43 61  6D 65 72 69 6E 67 6F 20   34:06 Cameringo

00000176   44 65 6D 6F 00 00 04 00  01 00 02 00 02 00 00 00   Demo

00000192   4E 00 00 00 04 00 05 00  03 00 00 00 E0 00 00 00   N           à

00000208   03 00 02 00 02 00 00 00  57 00 00 00 02 00 05 00           W

00000224   03 00 00 00 F8 00 00 00  00 00 00 00 51 00 00 00       ø       Q

00000240   01 00 00 00 0C 00 00 00  01 00 00 00 6C 54 00 00               lT

00000256   E8 03 00 00 1C 00 00 00  01 00 00 00 22 00 00 00   è           “

00000272   01 00 00 00 CA A0 00 00  E8 03 00 00 02 00 01 02       Ê   è

00000288   00 04 00 01 00 00 2E 01  00 00 02 02 04 00 01 00         .

00000304   00 00 00 00 00 00 00 00  00 00 FF                            ÿ

Step 1

Look for direction letters (yellow highlighted).

Step 2

Identify the pattern (green highlighted).

Step 3

Reading of bytes is totally reversed here. One may have to read backwards to get the latitude and longitude. In addition, the values are saved in little endian.

a)       Starting with offset 283 and going backwards. Thus from 283 – 280 (4 bytes) we have,

00 00 03 E8 (divisor) => 1000

From offset 279 – 276, 00 00 A0 CA => 41162

41162/1000 => 41.162 seconds

00 00 00 01 (divisor) = 1

00 00 00 22 => 34

34/1 = 34 minutes

Then we have 00 00 00 01 = 1

00 00 00 1C = 28

28/1 = 28 degrees

We got our latitude = 28:34:41.162

b)      Continue going backwards where we left from,

00 00 03 E8 => 1000

00 00 54 6C => 21612

21612/1000 = 21.612 seconds

Then 00 00 00 01 is the divisor

00 00 00 0C => 12

12/1 = minutes

Next we have 00 00 00 01 (divisor) and

00 00 00 51 => 81

81/1 = 81 degrees

Longitude becomes

81:12:21.612

Step 4

With direction,

Latitude: 28:34:41.162 N

Longitude: 81:12:21.612 W

Finally matching the extracted information with the one windows identified locally, as shown below.

Nessus

Image from LG

Offset          0    1   2   3    4   5   6   7    8   9   10 11 12 13 14 15

00001216   00 00 03 00 00 00 01 00  00 00 00 00 00 00 01 00

00001232   00 01 CC 00 00 00 64 00  00 03 E8 00 00 00 01 00     Ì   d   è

00001248   00 00 00 00 00 00 00 00  01 00 00 00 00 FF FF 00                ÿÿ

00001264   08 00 01 00 02 00 00 00  02 4E 00 00 00 00 02 00            N

00001280   05 00 00 00 03 00 00 06  5D 00 03 00 02 00 00 00           ]

00001296   02 57 00 00 00 00 04 00  05 00 00 00 03 00 00 06    W

00001312   75 00 05 00 01 00 00 00  01 00 00 00 00 00 06 00   u

00001328   05 00 00 00 01 00 00 06  8D 00 07 00 05 00 00 00

00001344   03 00 00 06 95 00 1D 00  02 00 00 00 0B 00 00 06       •

00001360   AD 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00   ­

00001376   00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00

00001392   00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00

00001408   00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00

00001424   00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00

00001440   00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00

00001456   00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00

00001472   00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00

00001488   00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00

00001504   00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00

00001520   00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00

00001536   00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00

00001552   00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00

00001568   00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00

00001584   00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00

00001600   00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00

00001616   00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00

00001632   00 00 00 00 00 00 00 00  00 00 00 00 1C 00 00 00

00001648   01 00 00 00 22 00 00 00  01 00 00 A2 21 00 00 03       “      ¢!

00001664   E8 00 00 00 51 00 00 00  01 00 00 00 0C 00 00 00   è   Q

00001680   01 00 00 56 FE 00 00 03  E8 00 00 00 12 00 00 00      Vþ   è

00001696   01 00 00 00 11 00 00 00  01 00 00 00 17 00 00 00

00001712   01 00 00 00 18 00 00 00  01 32 30 31 33 3A 30 38            2013:08

00001728   3A 32 32 00 00 08 01 00  00 04 00 00 00 01 00 00   :22

00001744   00 A0 01 01 00 04 00 00  00 01 00 00 00 78 01 03                x

00001760   00 03 00 00 00 01 00 06  00 00 01 1A 00 05 00 00

00001776   00 01 00 00 08 3E 01 1B  00 05 00 00 00 01 00 00        >

00001792   08 46 01 28 00 03 00 00  00 01 00 02 00 00 02 01    F (

00001808   00 04 00 00 00 01 00 00  08 4E 02 02 00 04 00 00           N

00001824   00 01 00 00 13 A8 00 00  00 00 00 00 00 00 00 00        ¨

00001840   00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00

00001856   00 00 00 00 00 00 00 00  00 00 00 00 00 00 00

Step 1

Look for direction letters (yellow highlighted).

Step 2

Identify the pattern (highlighted green). You must have noticed that in this case, we found the pattern quite farther from the direction letters (at offset 1640) unlike previous examples. 

Step 3

a)       00 00 00 1C => 28

00 00 00 01 => 1 (divisor)

28/1 = 28 degrees

00 00 00 22 => 34

00 00 00 01 = 1

34/1 = 34 minutes

00 00 A2 21 => 41505

00 00 03 E8 => 1000

41505/1000 = 41.505 seconds

Thus latitude is 28:34:41.505

b)      Continue reading hex,

00 00 00 51 => 81

00 00 00 01 => 1 (divisor)

81/1 = 81 degrees

Next 4 bytes are

00    00 00 0C => 12

00 00 00 01 => 1

12/1 = 12 minutes

00 00 56 FE => 22270

00 00 03 E8 => 1000

22270/1000 => 22.27 seconds

Thus longitude = 81:12:22.27

c)       Altitude is 18

Because,

00 00 00 12 => 18

00 00 00 01 => 1

18/1 = 18

Step 4

With direction,

Latitude: 28:34:41.505 N

Longitude: 81:12:22.27 W

Altitude: 18

Finally match the values to verify.

LG

Image from HTC phone

Offset           0   1   2   3    4   5    6   7    8   9   10 11 12 13 14 15

00004528   31 31 3A 30 34 3A 31 32  20 31 31 3A 30 37 3A 31   11:04:12 11:07:1

00004544   39 00 32 30 31 31 3A 30  34 3A 31 32 20 31 31 3A   9 2011:04:12 11:

00004560   30 37 3A 31 39 00 00 00  01 EC 00 00 00 64 00 01   07:19    ì   d

00004576   00 02 00 07 00 00 00 04  30 31 30 30 00 00 00 00           0100

00004592   00 00 00 00 00 0B 00 00  00 01 00 00 00 03 02 02

00004608   00 00 00 01 00 02 00 00  00 02 4E 00 00 00 00 02             N

00004624   00 05 00 00 00 03 00 00  12 72 00 03 00 02 00 00            r

00004640   00 02 57 00 00 00 00 04  00 05 00 00 00 03 00 00     W

00004656   12 8A 00 05 00 01 00 00  00 01 00 00 00 00 00 06    Š

00004672   00 05 00 00 00 01 00 00  12 A2 00 07 00 05 00 00            ¢

00004688   00 03 00 00 12 AA 00 12  00 02 00 00 00 07 00 00        ª

00004704   12 C2 00 1B 00 07 00 00  00 0F 00 00 12 CA 00 1D               Ê

00004720   00 02 00 00 00 0B 00 00  12 DA 00 00 00 00 00 00            Ú

00004736   00 26 00 00 00 01 00 00  00 2A 00 00 00 01 00 00    &       *

00004752   0A 45 00 00 00 64 00 00  00 4D 00 00 00 01 00 00    E   d   M

00004768   00 04 00 00 00 01 00 00  0D 7C 00 00 00 64 00 00            |   d

00004784   00 00 00 00 00 01 00 00  00 0F 00 00 00 01 00 00

00004800   00 07 00 00 00 01 00 00  00 13 00 00 00 01 57 47                 WG

00004816   53 2D 38 34 00 00 41 53  43 49 49 00 00 00 4E 45   S-84  ASCII   NE

00004832   54 57 4F 52 4B 00 32 30  31 31 3A 30 34 3A 31 32   TWORK 2011:04:12

00004848   00 00 00 00 00 06 01 03  00 03 00 00 00

Step 1

Look for direction letters (yellow highlighted).

Step 2

Identify the pattern (highlighted green).

Step 3

a)       For latitude

00 00 00 26 => 38

38/1 (divisor) = 38 degrees

00 00 00 2A => 42

42/1 = 42 minutes

00 00 0A 45 => 2629

2629/100 (divisor) = 26.29 seconds

Latitude is 38:42:26.29

b)      For longitude

00 00 00 4D => 77

77/1 = 77 degrees

00 00 00 04 => 4

4/1 = 4 minutes

00 00 0D 7C => 3452

3452/100 = 34.52 seconds.

Longitude is 77:4:34.52

Step 4

Match the calculated value with the one given by image properties.

HTC

 

References

http://en.wikipedia.org/wiki/Geotagging


Bitcoin Forensics – A Journey into the Dark Web

0
0

There has been a lot of buzz around Tor, Bitcoin, and the so-called “dark web” (or “deep web”) since the FBI shut down the underground website “Silk Road” on Oct 1st.

As many of you already know, Tor is a network of encrypted, virtual tunnels that allows people to use the internet anonymously, hiding their identity and network traffic. Using Tor’s hidden service protocol, people can also host websites anonymously that are only accessible by those on the Tor network. Enter Silk Road.

Bitcoin - Silk Road

Silk Road was an online black market where you could buy virtually anything, including but not limited to drugs, weapons, credit card data, contract killers, and more. One of the key “features” of Silk Road was that it was only accessible via the Tor network, hidden from the mainstream web.

With $1.2 billion in sales and nearly a million customers, business was good. The other key privacy aspect of Silk Road is that all transactions on the site were via Bitcoin, a distributed, peer-to-peer, and anonymous digital currency that is based on cryptography principles.

Silk Road is gone but there are other online black marketplaces that will take its place, like the Sheep Marketplace or Black Market Reloaded:

Bitcoin - BMR

These sites are also only accessible via Tor and use Bitcoin to conduct transactions.

Using Bitcoin is fairly easy. You need a Bitcoin client/digital wallet installed on your computer or mobile device. You then need to obtain bitcoins from a Bitcoin exchange such as Mt. Gox and Bitstamp.

To send someone money, you instruct your Bitcoin client to send an amount of bitcoins to a Bitcoin address which will look something like this: 1N52cffvJp8jZRRamegywrLrD7aLjQbapF.

A transaction message is created and electronically signed by the Bitcoin client using your private key. This transaction is broadcast to the Bitcoin P2P network and is “verified” in a few minutes (sometimes up to 10). Once verified, the transaction is complete.

All Bitcoin transactions are stored publicly and permanently on the Bitcoin network – the balance and transactions of any Bitcoin address are visible to anyone. New addresses can be created for each transaction, however, further increasing the anonymity of Bitcoin transactions.

Support for recovering Bitcoin artifacts was added to IEF in version 6.1 (released this past June). Bitcoin addresses can be recovered from a Bitcoin wallet, as well as queries on the Bitcoin network from log files created by the Bitcoin client software.

Bitcoin - IEF

Here you can see addresses from a Bitcoin wallet, including labels (if applicable) and whether or not the address has been active. When you create a wallet, a number of addresses are automatically created and put in the “thread pool”.

Bitcoin - IEF

In this screenshot you can see queries on the Bitcoin P2P network. These may or may not relate to the local user’s activity.

Bitcoin - IEF

In the IEF Report Viewer, when viewing Bitcoin records, you can right-click on a record and then click “Query Bitcoin Block Chain” to look up more information on that transaction/address on the web.

Bitcoin - IEF

Above is an example of what you might see for a transaction or address. In this example, you can see the amount of Bitcoin (0.005), dates/times, and the recipient of the transfer.

As you can see, Bitcoin is a tough currency to track or investigate. However, knowing which addresses were in a suspect/victim’s Bitcoin wallet and details about transactions can help you piece the puzzle back together.

I hope you found this post useful and wish you luck in investigations involving these technologies.

Are there specific topics you’d like me to blog about? Please feel free to reach out to me directly at jad(at)magnetforensics(dot)com with any ideas you might have. I’m also always open to and appreciative of your feedback, good or bad, regarding our software and how we can make it better for you.

All the best,
Jad and the Magnet team


Bitcoin Forensics Part II: The Secret Web Strikes Back

0
0

In last week’s post, we talked about Bitcoin, Tor and some of the hidden websites only accessible via Tor, such as Silk Road, which was shut down by the FBI on October 1st.

Well, just over a month later and Silk Road is back online:

Bitcoin Forensics - Silk Road

You can reach the new site at this link (again, only via Tor) if you’d like to check it out: http://silkroad6ownowfk.onion

It only took a day and they already had over 20,000+ users on the site:

Bitcoin Forensics - Silk Road

The new admin of the site? “Dread Pirate Roberts”. How’s that possible, he’s been arrested right? Those familiar with the movie “The Princess Bride” will get the joke here – the Dread Pirate Roberts was not one man, but rather a series of individuals who periodically pass the name and reputation on to a chosen successor.

Time will tell how long the new Silk Road lasts, but it’s clear that these secret websites and Tor aren’t going away anytime soon, and neither is the currency that drives these sites, Bitcoin.

We received a lot of positive feedback on the last Bitcoin post and some suggestions for follow-up posts. One of the themes was around identifying Bitcoin wallets, especially on a USB flash drive or other removable media.

First, let’s take a look at the Bitcoin wallet software out there:

Bitcoin Forensics - Wallets

As you can see, there are a few different options. This time I’ll focus on the Bitcoin-Qt client, which is a full Bitcoin client and builds the backbone of the network, the standard client used.

If you’re examining an image with the Bitcoin-Qt client present you’ll see a folder structure and files under the Users\[username]\AppData\Roaming\Bitcoin folder similar to this:

Bitcoin Forensics - Files

Note the “wallet.dat” file and “debug.log”. The wallet.dat file is (you guessed it!) the file containing the wallet data for the user. The debug.log file contains (you guessed it again) debugging information, including communication on the Bitcoin P2P network, including timestamps in some cases.

The wallet.dat file is easy to identify by filename, but backups of the wallet can be made, and can be called whatever the user chooses. If you are examining removable media or other locations where you suspect you are dealing with a Bitcoin wallet file (from the Bitcoin-Qt client), you can check a couple bytes at offset 0×12 for the string “b1” which may identify the file as being a Bitcoin wallet:

Bitcoin Forensics - Wallet Identification

Another easy check is to export the file and rename it to “wallet.dat”. Run IEF on that file by using the “Files/Folders” button on the main screen and then unchecking all the artifacts except for the Bitcoin artifact on the artifact selection screen. Here is a sample of what you’d see recovered from the wallet by IEF:

Bitcoin Forensics - Internet Evidence Finder

I hope this answers some of the questions you may have had after my last post on Bitcoin forensics.

We’ll do our best to continue bringing you interesting topics in future posts, and as always, I’m eager to hear your suggestions for what you’d like to see in future blog posts. Please feel free to email suggestions, feature requests, and feedback on IEF to jad(at)magnetforensics(dot)com.

Have a great week!
Jad and the Magnet team


Webmail Forensics – Digging deeper into Browsers and Mobile Applications

0
0

Almost everyone who uses the Internet has a web-based email account. Many people have two or more, so the likelihood of a forensic investigator coming across a case involving webmail communication is very high. While law enforcement examiners can ask service providers for the email contents through a court order, corporate and non-government examiners have to rely on what evidence is left on the computer or mobile device.

The three largest webmail providers are Google’s Gmail, Microsoft’s Hotmail/Outlook.com, and Yahoo Mail. Together they account for well over one billion users. Each provider offers some unique features but they’re generally all quite similar in implementation from a forensics standpoint. This article will discuss how webmail artifacts are stored and investigated on a PC or laptop, mobile devices, and other applications that support and store webmail evidence.

Browsers

On a PC, most webmail activity is conducted through the browser so it’s no surprise that the majority of your evidence will consist of browser artifacts. Depending on the browser used, the data will be stored differently but typically the cache, history, and cookies are your best sources of evidence. History and cookies will provide dates, times, and sites visited but the data of real evidentiary value is found in the cache. The cache stores web page components to the local disk to speed up future visits. Many emails read by the suspect are found in the cache folders and those locations vary depending on the operating system and browser used.

Internet Explorer

Since Internet Explorer (IE) is installed by default on most Windows installations, it’s likely the most commonly used and should always be searched when looking for webmail—or any browsing artifacts for that matter. Depending on the version of Windows and IE installed, the evidence will be stored in different locations. The locations are listed below:

  • WinXP – %root%/Documents and Settings/%userprofile%/Local Settings/Temporary Internet Files/Content.IE5
  • Win Vista/7 – %root%/Users/%userprofile%/AppData/Local/Microsoft/Windows/Temporary Internet Files/Content.IE5
  • Win Vista/7 – %root%/Users/%userprofile%/AppData/Local/Microsoft/Windows/Temporary Internet
  • Files/Low/Content.IE5
  • Win8/IE10 – %root%/Users/%userprofile%/AppData/Local/Microsoft/Windows/History

Note: Internet Explorer 10 is available on Windows 7 as well. If IE9 was installed and then upgraded to IE10, there will be two sources of evidence (the index.dat file from IE9 and the database within the webcache folder for IE10).

Mozilla Firefox

Firefox is a very popular browser and also stores its cache data in various locations based on the operating system installed. It’s installed as the default browser on many Linux distributions and is available for MacOS-X as well.

  • WinXP – %root%/Documents and Settings/%userprofile%/Local Settings/Application Data/Mozilla/Firefox/Profiles/*.default/Cache
  • Win7/8 – %root%/Users/%userprofile%/AppData/Local/Mozilla/Firefox/Profiles/*.default/Cache
  • Linux – /home/%userprofile%/.mozilla/firefox/$PROFILE.default/Cache
  • MacOS-X – /Users/%userprofile%/Library/Caches/Firefox/Profiles/$PROFILE.default/Cache/

Google Chrome

Google Chrome is also one of the top 3 browsers used today. It is available for Windows, Linux, and MacOS-X. Google also makes the Chromium open source project available to Linux users and runs very similar to the regular Chrome package with some minor differences i.

  • WinXP – %root%/Documents and Settings/%userprofile%/Local Settings/Application Data/Google/Chrome/User Data/Default/Cache
  • Win7/8 – %root%/Users/%userprofile%/AppData/Local/Google/Chrome/User Data/Default/Cache
  • Linux – /home/%userprofile%/.config/google-chrome/Default/Application Cache/Cache/
  • MacOS-X – /Users/%userprofile%/Caches/Google/Chrome/Default/Cache/

While the other browsing artifacts will show evidence of visiting the site, the cache folders will show the actual contents of the page or message, which is significantly more important when dealing with webmail artifacts. One caveat to mention is that typically you won’t find a cached page of any messages sent (only read) by the suspect since the message is typed on screen and then sent by the user without actually viewing the message outside of the text box or script. The only time the sent messages are cached is when the suspect views the HTML message in the “Sent Messages” folder after sending.

It is important to note that these will not be the only places to search for webmail artifacts. System memory/pagefile.sys are sometimes the only place to find webmail artifacts such as Gmail, and volume shadow copies/restore points, and hibernation files, all contain valuable historical data that can be used in conjunction with the evidence found in the areas above.

While the cached pages can be manually parsed and viewed using traditional forensics tools, Magnet Forensics‘ Internet Evidence Finder™ (IEF) will automatically pull the relevant browsing data from all the common browsers that a suspect might have used and sort it into specific categories based on the webmail service provider. They can then be viewed within the report viewer for quick and easy analysis.

In the example below we have found Gmail fragments in memory at physical sector 248188 using EnCase. All the data is there but as memory is typically a sector level search, it is not easily searched or organized.

Once the image or drive is analyzed with IEF, Report Viewer will sort any evidence found by the service provider. IEF then automatically parses the sender/receiver details, the subject, and the date of the message into columns for fast sorting and then displays the contents of the message in the window below. With the same data we used in our EnCase example, IEF has analyzed the evidence and pulled all the relevant data into Report Viewer for easier searching.

Review of the relevant artifacts reveals not only browser artifacts of the messages that were opened by the user but IEF also parses many of the emails that were not opened by the suspect and simply displayed by the inbox or folder view of the webmail in the browser. Many times this type of information can be found in memory, pagefile.sys, or hiberfil.sys. Since the message in this example wasn’t opened by the user during the given browsing session, IEF is unable to show the contents of the message in this circumstance, however it will give a better picture of what resided in the user’s inbox at the time of viewing.

Overall, webmail artifacts are an important part of many investigations. Either as a primary source of information or as corroborating evidence, webmail can be found in the browser artifacts or memory of most PCs or laptops.

What about other sources of webmail evidence?

Forensic investigations have moved beyond just desktop PCs or laptops since most people now access email from their mobile devices as well. What started out as a tool for only the most serious business person has now spread to even the most casual consumer. IEF is able to analyze email found on the two most commonly used platforms, Android and iOS.

There are many forensic tools that specialize in mobile acquisitions. Cellebrite, XRY, and Oxygen are excellent resources to acquire the large variety of mobile devices and connectors. Much like previous versions of IEF, IEF Advanced focuses on the analysis of the acquired data and leaves the imaging to the other tools. Once the image is acquired, IEF will analyze all of the common outputs from the mobile acquisition tools (dd, raw, img, bin, 001, ima, vfd, flp, bif) as well as all the EnCase formats (E01, L01, Ex01, Lx01).

Focusing on the analysis allows IEF to specialize in the artifacts that are found within an image and produce the best results whether the evidence is found on a suspect’s PC or mobile device.

IEF can handle both physical and logical mobile images for iOS and Android, but a physical image is always preferable when possible in order to carve out deleted artifacts stored in unallocated space. If a logical image is acquired, unallocated space is not captured and therefore cannot be searched.

Android/iOS Mailbox, Gmail Application

Emails are handled differently on a mobile device than webmail is on a traditional PC. Typically on a PC, webmail is handled through the browser, and most of the evidence is found in browser artifacts or memory. Howerver, with mobile devices, there is typically a native mailbox application for all of a user’s email accounts, whether they are webmail or server based.

For iOS the native mailbox is stored as a SQLite database here:
/private/var/mobile/Library/Mail/Protected Index and Envelope Index

For Android it is also stored as a SQLite database here:
/data/data/com.google.android.email/databases/EmailProvider.db

IEF is able to parse and carve the native email clients for both iOS and Android devices by accessing the SQLite database that stores the messages and structures the sender/recipients, CC/BCC, date/time, subject, status, message content, and attachment for each message recovered from the native application into the IEF Report Viewer.

Email can also be stored in a dedicated application if one exists, as is the case with Gmail.


Many mobile devices have a dedicated mail application for Gmail or other popular webmail accounts. This provides users with enhanced features available to Gmail based webmail that might not be available if the native mailbox is used.

The Gmail application is stored as a SQLite database for Android devices here:
/data/data/com.google.android.gm/databases/mailstore.%GmailUserID%@gmail.com.db

In addition, make sure to search the mobile browser activity for additional webmail that may have been accessed through the browser and wasn’t setup in either the native or custom mailbox application, such as the Gmail app.

Webmail has extended far beyond the traditional browser and your investigation should as well. With mobile database applications storing messages from multiple webmail accounts and new application artifacts being created regularly, it is difficult for an investigator to know where to look for all potential evidence, let alone have the time to search everywhere for each case. Tools such as IEF expedite that process greatly and help investigators understand the bigger picture when it comes to Internet evidence—and the number applications that store the evidence only continues to grow.

*For more detail on Chromium and its differences, see:
https://code.google.com/p/chromium/wiki/ChromiumBrowserVsGoogleChrome

As always, please let me know if you have any questions, suggestions or requests. I can be reached by email at jamie.mcquaid(at)magnetforensics(dot)com.

Jamie McQuaid
Forensics Consultant, Magnet Forensics


Capturing RAM Dumps and Imaging eMMC Storage on Windows Tablets

0
0

Oleg Afonin, Danil Nikolaev, Yuri Gubanov
© Belkasoft Research 2015

While Windows desktops and laptops are relatively easy to acquire, the same cannot be said about portable Windows devices such as tablets and convertibles (devices with detachable keyboards). Having no FireWire ports and supplied with a limited set of external ports, these devices make attaching acquisition media more complicated in comparison to their full-size counterparts. Equipped with soldered, non-removable eMMC storage, Windows tablets are extremely difficult to image while following the required forensic routine. Finally, the obscure Windows RT does not allow running unsigned desktop applications at all while restricting the ability to boot into a different OS, making forensic acquisition iffy at best.

In this article, we will have a look at how Windows-based portable electronic devices are different from traditional laptops and desktops, review new security measures and energy saving modes presented by Windows tablets and discuss hardware, methods and tools we can use to acquire the content of their RAM and persistent storage.

Security Model of Windows Tablets

Tablets running Windows 8, 8.1 and Windows RT are designed with certain security measures to prevent unauthorized access to their content if a device is lost or stolen. These security measures are similar to those present in desktop devices, and differ significantly from the approach employed by Google and Apple.

In Windows 8 and 8.1 installed on a tablet, security measures include optional whole-disk encryption (with BitLocker) and Secure Boot, an option to prevent booting into a non-recognized (unsigned) OS, effectively preventing the use of Linux-based bootable drives often used for digital forensics.

Note that Secure Boot is optional, but is often activated by default in the system’s UEFI. BitLocker keys can be retrieved from the user’s Microsoft Account (http://windows.microsoft.com/recoverykey) or extracted from a memory dump (if captured while the tablet is running).

Secure Boot

Secure Boot, even if activated in the tablet’s UEFI BIOS, can usually be disabled by booting into UEFI (by using the combination of Volume-DOWN and Power keys). However, if UEFI BIOS is protected with a password, resetting the password could be difficult. Notably, Secure Boot does not prevent booting from external media per se. If you have a bootable recovery image of Windows 8.1 or a bootable Windows PE 5.1 flash drive, these already carry the required signatures and can be used to start the tablet even if Secure Boot is enabled.

It is important to note that Secure Boot is permanently activated on Windows RT devices such as Microsoft Surface RT, Surface 2, Nokia Lumia 2520 and other RT-based tablets. Since these ARM tablets are locked with Secure Boot, and there is no way to disable that option, there is no known method to boot them into anything other than Windows RT or its recovery image. While one can technically use a Windows RT recovery image such as one provided by Microsoft (http://www.microsoft.com/surface/en-us/support/warranty-service-and-recovery/downloadablerecoveryimage), there are no forensic tools available for that OS. However, one can still use a built-in DSIM tool to capture the content of a Windows RT computer but that is out of the focus of this article.

BitLocker

BitLocker is an essential part of Windows security model. On many tablets, BitLocker encryption protects the C: partition. By default, BitLocker is activated on all Windows RT and many Windows 8 and 8.1 tablets. With BitLocker, one cannot access encrypted partitions without either logging in to Windows (by supplying the correct login and password) or providing the correct Recovery Key. This especially concerns situations with booting from an external device.

If the user’s BitLocker Recovery Key is unknown, it can be retrieved from https://onedrive.live.com/recoverykey (providing that the user’s Microsoft Account credentials are known).

Drives protected with BitLocker will be unlocked automatically every time the user logs in. As a result, if you have the user’s local login credentials for the given device, BitLocker does not represent a major problem.

Important note, however : If the Windows tablet you are about to acquire is running, or if it is in the Connected Standby mode, DO NOT TURN IT OFF before trying anything to capture the system’s live memory dump. If the C: partition is protected with BitLocker, capturing a live memory image is your chance to obtain (and retrieve) the binary key used by BitLocker to decrypt information. If you are able to extract that key, you will be able to use a tool such as Passware Kit Forensic to mount BitLocker-protected partitions even if you know neither the user’s login and password, nor Microsoft Account credentials.

Note that BitLocker is frequently disabled by default on cheaper, mass-produced tablets with smaller screens such as those running Windows 8.1 with Bing.

eMMC Storage

Most Windows tablets are equipped with built-in non-removable eMMC storage. Physically, an eMMC module (Embedded Multi Media Card) is a BGA chip that is soldered onto the main board. As such, standard acquisition methods involving the use of a write-blocking SATA imaging device are not applicable.

In order to acquire partitions from eMMC storage, you will need to boot from an external drive containing a bootable recovery image (such as Windows PE) and a set of forensic imaging tools. However, even that may present a problem with Windows tablets.

Compatibility

Some Windows tablets are equipped with 32-bit UEFI ROM, while few other devices come with fully featured 64-bit UEFI. As a result, you may be unable to boot a 64-bit Windows PE image (or 64-bit Linux) even if the tablet is equipped with a 64-bit capable CPU.

UEFI Secure Boot

The majority of Windows tablets come with the Secure Boot option activated in their UEFI BIOS. Contrary to popular belief, you will NOT need to disable Secure Boot in order to start the system from an external device, PROVIDED that the OS you are about to boot is signed. In other words, you will be able to boot into a Windows 8.1 Recovery and Repair Environment (WinRE) or use a custom Windows PE 5.1 image. However, with Secure Boot activated, you may be unable to boot into a Linux-based forensic image.

In order to disable Secure Boot, you will need to access the system’s UEFI by pressing and holding the Power-DOWN key while starting the device. However, access to Secure Boot is not required if you simply want to boot from a USB device containing a Windows PE or WinRE image.

Booting from an External USB Device

In order to boot from an external USB device, you’ll need to have a properly prepared WinRE or Windows PE based bootable media and a USB OTG (On-The-Go) cable. In order to change the boot sequence and make the system start from an external device, follow these steps:

  1. Start the tablet.
  2. At the login prompt, tap the Ease of access icon.
  3. Select On-Screen Keyboard.
  4. Tap the Shift key, the shift key should remain lit.
  5. In the lower right corner, tap the power key and select Restart.
  6. When the unit reboots, select the Troubleshoot option.
  7. From here select Advanced options.
  8. Select UEFI Firmware Settings. You will be transferred into UEFI BIOS.
  9. From there, change the boot order to allow starting from a USB device.
  10. If you are using a non-Windows PE (or WinRE) based image, disable the Secure Boot option. There is no need to touch this option if you are using a Windows PE 5.1 image.
  11. Connect a bootable USB device via a USB OTG adapter.
  12. Save settings and reboot. The system will start from the bootable image on your USB drive.
  13. Follow the acquisition routine of your forensic toolkit.

Capturing a Memory Dump

Capturing a RAM dump of a Windows tablet is essential for digital investigations, and is one of the recommended practices by ACPO Guidelines. Most principles of capturing a live memory dump remain the same as compared to full-size PCs. The goals, tools and the process of capturing volatile memory images are described in Belkasoft whitepaper “Catching the ghost: how to discover ephemeral evidence with Live RAM analysis”.

However, there are minor differences between capturing volatile memory images on a PC and doing the same on a small tablet. One thing to consider is the lack of expansion ports such as FireWire on most tablets, which makes the FireWire attack impossible. Moreover, there is usually no possibility to add a FireWire port via an add-on card.

As such, on Windows tablets (with a notable exception of Windows RT devices) we are limited to using software tools such as Belkasoft Live RAM Capturer.

Since most Windows tablets lack full-size USB ports, you will need to use a USB OTG (USB On-The-Go) adapter in order to connect a flash drive. Since tablets are usually equipped with one or two gigabytes of RAM, even a small USB stick or memory card will suffice.

Analyzing a Memory Dump

Once RAM is acquired, you will need to analyze it with a forensic tool equipped with a Live RAM dump analysis feature, like Belkasoft Evidence Center:

Selection of Live RAM artifacts to search in Belkasoft Evidence Center

There is a high chance of finding various forensically important artifacts. You can see some data found inside RAM dump by Evidence Center:

Live RAM artifacts found by Belkasoft Evidence Center

Conclusion

To conclude, acquiring Windows tablets is similar to dealing with full-size PCs, yet the process has its share of obstacles. We learned how to image partitions saved on soldered eMMC chips and how to deal with BitLocker protection. We figured out the meaning of Secure Boot, when and how to deactivate it if required. Finally, we reviewed steps to access the tablet’s UEFI BIOS and change device boot order in order to allow booting from a USB flash drive containing a set of forensic tools for imaging the device.

About the Authors

Oleg Afonin is Belkasoft sales and marketing director. He is an author, expert, and consultant in computer forensics.
Danil Nikolaev is Belkasoft sales and marketing manager, co-author, and content manager.
Yuri Gubanov is a renowned digital forensics expert. He is a frequent speaker at industry-known conferences such as CEIC, HTCIA, TechnoSecurity, FT-Day, DE-Day and others. Yuri is the Founder and CEO of Belkasoft, the manufacturer of digital forensic software empowering police departments in about 70 countries. With years of experience in digital forensics and security domain, Yuri led forensic training courses for multiple law enforcement departments in several countries. You can add Yuri Gubanov to your LinkedIn network at http://linkedin.com/in/yurigubanov.

Contacting the authors

You can contact the authors via email: research@belkasoft.com
Follow Belkasoft on Twitter: https://twitter.com/Belkasoft
Subscribe to the blog: https://belkasoft.wordpress.com

About Belkasoft Research

Belkasoft Research is based in St. Petersburg State University, performing non-commercial researches and scientific activities. A list of articles by Belkasoft Research can be found at http://belkasoft.com/articles.


Viewing all 46 articles
Browse latest View live


Latest Images