The idiosyncrasies of mobile phone network providers

All mobile phone network providers have to, by law, hold call data records for at least one year. Problems arise, however, because they all present the records in very different formats and some of the data can seem irrelevant and confusing, giving rise to the risk of information being misinterpreted.

Call data records?

CDRs are similar to itemised phone bills – but they hold much more information. As well as the dates, times and numbers called, CDRs also include IMEI numbers, cell site data and locations.

What do you mean by idiosyncrasies?

Here’s an example: some networks will record the cell ID (the sector of the phone mast) for phone calls which were made, but didn’t connect – others won’t. And some will give the other party’s cell ID if they’re on the same network. This provides a number of opportunities, but these idiosyncrasies also present significant risks if the person analysing them isn’t aware of all these nuances.

As mentioned in a previous blog, the key is to get the call data records into a workable format. This is a massive data manipulation exercise, compounded by the fact that the networks can record locations differently – they may use the postcode, BNG (British National Grid) or latitude and longitude co-ordinates – plus the other idiosyncrasies mentioned above.

Another major issue is that CDRs from some networks’ CDRs can apparently attribute the cell site data from the person at the other end of the call to the subject phone. An unwary analyst may misinterpret this data as coming from the person receiving the call by inadvertently associating the outgoing data with incoming calls and vice versa. This is something I have even seen in court.

Shown below is an example of part of a call data record for phone 07875 477828 for part of 03/12/2010.

Note that the call at 20:54 appears to show cell site information for the phone number 07772 000987 even though this number was not the target of the call data records. An amateur assessment of the call data records – simply looking at all the cell IDs – might conclude that the target phone 07875 477828 had been in the service area for cell
03010 52339 at this time. Such a conclusion would be totally false.

This cell was many kilometres from a particular location of interest in a criminal investigation in one case. Had this issue not been picked up in court, it could easily have led to a miscarriage of justice.

Call data record

Example call data record

What other oddities are thrown up by CDRs?

There are a couple of fairly common issues that can cause problems for even the most experienced analyst.

Text messages may appear on the CDR that the user isn’t aware of. They do exist – but are likely to have been network messages which the user doesn’t actually see. They are “codes” sent by the network under a number of different circumstances to update software, and user details – amongst others. These texts can also be indicative of the user taking the SIM card and/or battery out of the device.

They are not a particularly common occurrence, but can provide additional useful evidence especially if a suspect has deliberately not used their phone in order to stay off the network. For example: a suspect may put a new SIM card into a device at their home, unaware that the phone is then communicating with the network, and therefore leaving location data on the CDR.

As mobile phones become more complex, and smartphones begin to dominate the market, this also provides a useful opportunity for cell site analysts. Not only are calls, texts and network messages registered on the CDR, so is data packet transmission. Every time the phone connects to the internet, whether browsing the web, social networking or being used by apps, this is also recorded. However, unlike a phone call, which records the start and end cell, this data will show the cell ID for where a user started browsing, but not necessarily where they finished.

It gives rise to another question: how long is a browsing session? Some networks record browsing sessions in blocks of time – for example, the cell ID of a session begun at the start of an hour will be recorded – and that will also include a second session begun at the end of that hour. Both locations may not necessarily be separately recorded. This issue again is shown on the call data above at 22:00 and 23:00.

How can the problems caused by these idiosyncrasies be avoided?

There’s no substitute for experience. Cell site analysts with substantial knowledge of these idiosyncrasies can easily circumvent any problems – by spotting them up front.

In addition, converting and sorting the vast amount of data into a properly formatted call sequence table (CST) makes the data uniform and easy to work with.

The CST means that investigators can filter and delete unwanted data easily and without the risk that something will be missed.

CCL-Forensics has developed a tool which takes raw data from the network providers, and converts it into a consistent, workable form – removing the need for extensive manual manipulation. For more information please feel free to get in touch on 01789 261200.

Most importantly, analysts really need to know the individual networks well in order to understand their various oddities and work around them.

Dunk your cookies in our software

Cookies are often seen as the poor cousin of digital evidence, but they can provide a wealth of information for digital investigators – including how often, from where and how a user visited a certain site – as well as the search terms used to find it.

So how can we access this treasure trove of knowledge?

By using a piece of software called dunk! which covers all the main PC internet browsers (Chrome, Firefox, Safari, IE, etc.) and a wide range of mobile browsers.

The inspiration for dunk! came after conducting an examination of an iPhone during which we found that evidence for the web history and cache was thin on the ground – although we were getting some interesting key word hits in the cookies.

Previously, analysts had been dumping cookies into a straightforward table view, but not looking at the structure of the cookies’ values. However, in this case all the interesting key words fell inside what were found to be Google Analytics cookies. The nice thing about these cookies was that, unlike many cookies where the structure is proprietorial, these were consistent between all sites and contained really interesting insights into a user’s web activity.

We wrote a program enabling us to view all the cookies at once, and where known structures (such as Google Analytics) were found, automatically parse them – and we designed it to support as many browsers as possible.

But that’s not all it does; dunk! can detect session cookies which may contain usernames, email addresses, and sometimes even passwords, allowing investigators to build the fullest picture possible of browsing habits.

The interface allows the data to be filtered, searched and exported. In a nutshell, the software does the following:

  • Processes cookies from PCs and mobile devices
    • Internet Explorer 5+
    • Mozilla Firefox 3.x
    • Mozilla Firefox 4.0
    • Google Chrome
    • Safari browser
    • Opera 5+
    • Apple “binarycookies” format
    • Android browser
    • Flash cookies
    • Nokia 40 browser
  • Parses Google Analytics cookies
  • Parses Adobe Flash cookies
  • Enables investigators to search and filter evidence
  • Detects session cookies which may contain usernames, email addresses, etc.
  • Outputs to TSV and XML file formats

Open the cookie jar and take a detailed look at what’s inside.

Alex Caithness

Dunk! Developer

Updated signature files for epilog

CCL-Forensics’ developers are constantly adding new files to increase the capability of epilog, and the latest signature files are now available for download, free of charge.

These new signature files now contain support for Apple iOS5.

We also welcome suggestions for additions to future signature file releases. Please email us at epilog@ccl-forensics.com.

What is epilog?

For those who don’t know, epilog is a software tool which allows investigators to recover deleted data from the widely-used database format, SQLite. Take a look at the first of our epilog videos:

It was developed by CCL-Forensics and – put simply – it gives investigators access to more data which could prove crucial in an investigation.

Many devices (whether mobile phones, computers, satnavs or other devices) store data in the SQLite database format.

Data stored in this type of database can provide a huge evidential opportunity for investigators. Many “off-the-shelf” tools can be used to view the live records in the database, but epilog  extracts deleted and de-referenced data from the database files or across a disc image or hex dump.

epilog’s three recovery algorithms can be used on any SQLite database, regardless of the type of data stored. However, epilog signatures can be used to tailor its behaviour to a particular database.

Included with the initial release of epilog were signatures including:

  • Android (SMS, call logs, calendars, address book and others)
  • iPhone (SMS, emails, calendar, and others)
  • Smartphone third party applications (including Yahoo Messenger, eBuddy chat and others)
  • Safari (internet history and cache and others)
  • Mozilla (cookies, internet history, form data and others)
  • Chrome (internet history)

Parsing XML and Plist files the cool way

You probably know that XML is a common format for storing data. It’s found on a wide range of devices and platforms, including PCs, smartphones and sat navs. XML is text-based, but not often user-friendly when served raw, as you can see:

Not so user friendly...

Because of its non-user-friendly nature, analysts or investigators often have to manually manipulate large amounts of data in order to understand its meaning and structure.

There’s a similar situation with Apple’s property list (plist) files, which can be stored in XML or binary format. Either way, they’re not terribly easy to use.

So – what makes it easier for analysts?

XPath is a query language designed for getting data out of XML files in a structured way and we’ve developed a piece of software called PIPwhich takes advantage of this in order to simplify the presentation of the often-complex data stored in the files.

The power to create XPath queries was placed right at the centre of PIP so that if you come up against unfamiliar data PIP empowers you to write a query which you can then reuse. However, being analysts ourselves, we have already encountered a number of situations where we have used PIP and as such, PIP comes preloaded with a substantial library of XPath queries for many common files.

PIP doesn’t just make raw data easier to read, though; it saves a considerable amount of time for analysts. PIP can be used to parse individual files; however where it really comes into its own and saves significant amounts of time is where it allows you to process many files at once.

For example: PIP processed 263 Facebook application files from an iPhone image in four seconds, returning 1,800 records (including profile views, chat history, photo views with comments, and URLs).

The say a (moving) picture is worth a thousand words – so take a look at our video and see what PIP can do for you.

Alex Caithness

PIP Developer

How can geographical features affect cell site analysis?

Matthew Tart, one of CCL-Forensics’ cell site analysts looks at the effects that height and landscape have on cell site analysis techniques. He also looks at a scenario where, on the face of it, a suspect seems to be moving in a particular direction – but could actually be doing the opposite.

Q: It seems obvious that the landscape can affect the coverage area of cells, but just what sort of effect does it have?

A: There are two main effects. The first is that height limits coverage area by preventing the signal reaching areas in a “shadow” caused by the particular geographical feature (hills, mountains, that kind of thing). And the other is that being at height affects which mast (cell) you are able to connect to, compared to the cells which would serve at a lower level.

Q: Taking the first of those two, this is presumably about “line of sight”?

A: It is – but don’t be misled by the word “sight”. You don’t physically have to see a cell for it to provide service where you are – reflection, diffraction and other factors take care of that. Let’s consider a simplified example. The signal from the mast reduces when it travels through or around “stuff”. Whereas the walls of a building contain a relatively small amount of stuff, hills and mountains (clearly) contain a lot of stuff. It stands to reason that, if a hill is in the way, the signal will not be received on the other side.

Q: That sounds pretty obvious, but how do cell site analysts cope with this?

A: It’s all about the preparation: about knowing the landscape and the potential effects before you go out to survey (if, indeed, surveying is relevant to the investigation in question). It’s obviously wrong to be doing all your preliminary work in two dimensions, when the scene itself is in three.

Q: In terms of the other issue, i.e. height affecting which cell you connect to… just how high are we talking about?

A: We’re talking more about “artificial” height here… tower blocks and so on, rather than natural features. It’s feasible that if you’re higher than four storeys from the ground, a whole new range of cells may come into view. When you get above the rooftops of neighbouring buildings you have a whole new vista, meaning new cells can be seen. The “stuff” is no longer in the way.

A good example of this is on an estate, where a localised picocell provides coverage at street level, but twelve storeys up, a more remote macrocell provides coverage, despite being a number of miles away. Simply mapping this as a desktop exercise, you could incorrectly infer that the phone had moved a considerable distance.

Q: How misleading could this be?

A: Let’s look at an extreme example: of a valley with a mast situated high on each side, and one in the town below.

If an individual moves in the direction of the arrows shown in the diagram, i.e. from right to left through the town, he may use (in this example) mast A first, as it provides line-of-site coverage, but he is in the shadow of mast C. Next, he may use mast B as he moves through the town, as this provides localised coverage for the town only, and then as he travels back up the other side of the valley, he could use mast C, as he is in the shadow of mast A.

Plotting these on a map, and giving no consideration to the terrain, makes it look like he did the opposite. Simply looking at the mast location, and saying he used A, then B, then C, does seem to imply he is moving from left to right, rather than vice versa.

Looking at this from above…

Of course, in reality, you would more than likely be using a much larger set of data, so this is an extreme example, but it does illustrate the problems faced in not appreciating the effect of height.

In another example, let’s look at the other effect of height – that of providing service at height, which you wouldn’t expect at ground level.

In this example, the purple mast is designed to provide service at ground level (let’s say in this example it’s a picocell on the front of a nearby shop) but the orange mast would easily provide coverage at the top of the tower block, even though it is a considerable distance away. This demonstrates the importance of carrying out a survey which is in line with the requirements of the investigation.

Was the suspect likely to have been on the high levels of a building at the time of the crime? Was height a potential factor? Would a “walk survey”, using hand-held equipment, be more appropriate than a drive survey using vehicle-mounted equipment at ground level?

In summary, it’s worth remembering that a lot of network planning is focused on providing coverage at ground level, and it’s important therefore to consider the likelihood of more remote cells (at greater altitude) also providing service.

Matthew Tart

Cell Site Analyst

Deconstructing BlackBerry files the easy way

According to Wikipedia, Rubus is a large genus of flowering plants in the rose family, Rosaceae, subfamily Rosoideae. Blackberries, raspberries, and dewberries are common, widely distributed members of the genus.

That’s why the tool is named Rubus. It’s a free tool that allows investigators to reverse engineer raw BlackBerry data.

So – why do you need it?

You probably know that BlackBerry phones create an .ipd file when the device is backed up, and that a number of forensic tools will parse contacts, SMS, etc. from these files. Standard tools, though, may not show you the whole picture.

Although some tools may enable analysts to look at the extra data in a hex editor, this makes the data unwieldy and presents it without any meaningful structure. Rubus allows digital investigators to view all the data contained in the .ipd files in a structured fashion, providing access to a wealth of data that may prove crucial to a case.

What missing data?

Here’s an example. The third-party SMS application CrunchSMS stores messages in its own format in a table within the .ipd file – but they’re not stored in the BlackBerry’s SMS storage location. Rubus extracts this data and presents it in a usable format.

Where can I find it?

Rubus is available to download from our website, along with CCL’s other digital forensics software tools Epilog and PIP. Remember, it’s free – so take a look and find out how it can help your case.

Making CCTV evidence compelling in court

 

Ian Rogers

Ian Rogers

Ian Rogers, a CCTV analysis expert, has 16 years’ experience dealing with video evidence, including ten years with the British Transport Police. In this Q&A blog, he shares his thoughts and observations on how best to engage the jury while presenting robust and compelling evidence. Please feel free to contact Ian with your thoughts at info@ccl-forensics.com.

Q: Quite simply, to begin with: what makes a good court presentation?

A: Where CCTV evidence is concerned, the old cliché of “a picture paints a thousand words” has never been more true. The footage you show, and the way you show it, has to be “impactive” and look professional.

The first hurdle to overcome is to manage the jury’s expectations of what they’re going to see. Far too often, thanks to films and TV programmes, people expect to see something of a better quality than even the most professional expert can produce. I call it the “CSI factor”, as popular crime dramas tend to overplay the type of evidence that can be produced. Generally, even with the sort of advanced enhancement we can carry out, the images tend to be of a much poorer quality than many jury members expect.

The “CSI factor” also raises the jury’s expectation of the technology and equipment which will be used to display the evidence. If you are an OIC (officer in charge) presenting some really pivotal CCTV evidence, first ensure that the equipment does it justice. An old, slightly fuzzy TV is not the way to present a high-impact visual presentation. My top tip here is to make sure you know, well in advance, what will be available in court on the day, to allow you to show your footage. If you’re not happy, this will give you sufficient time to source alternative, more appropriate, equipment.

Q: So, once you’ve got the technology sorted – what about the content of the presentation itself? What makes a professional presentation?

A: One of the first points is to ensure that the work is carried out by someone technically proficient to do so. Secondly it’s imperative that professional, industry standard hardware and software is used to produce the presentation. Always resist cutting corners by giving footage to “that bloke down the corridor” who’s done a bit of home video editing, and has some basic software on his PC. The risk is that it’ll not only look unprofessional, but that the quality of the footage could be degraded and its evidential integrity compromised, particularly if they’re not conversant with the various file and compression formats.

On top of this, the jury may well be able to distinguish between a home-spun presentation and a professional version produced using broadcast-quality equipment. You need to maintain your credibility in front of the jury – and one lacklustre CCTV presentation could go some way to compromising that. Given the pressurised nature of the court environment, a professional DVD presentation with chapters and menus (where there are multiple pieces of footage) not only looks better to the jury, but also reduces the need for the OIC to fumble around finding the relevant piece of content. Credibility is maintained, and the jury have their expectations met.

Q: What about the actual content of the presentation? If you’ve got lots of relevant clips, how do you best plan what you’re going to show and how you’re going to show it?

A: This is where working with your CCTV expert is crucial. Liaise closely with your CCTV analyst to ensure that you have identified the most important parts of the raw footage, and produce an edit list if necessary. Look at how any appropriate enhancement techniques can be employed to improve its clarity. Discuss whether still images can be produced, which emphasise elements of the case, and whether highlighting or annotating the footage would make things clearer and more impactive.

Also, ensure that the menu structure and chapter points (where relevant) are created with you in mind, so you can easily find any part of the footage again if you need to.

Generally, the way to focus a jury’s attention on what is relevant is to use short, well-edited sequences with highlighting, slow-motion, enlargement and enhancement where most applicable. Don’t overuse these features – it only serves as a distraction.

When you’re actually presenting this, think of it as a visual storyboard; and the better you know the content, the more seamlessly you can weave it into the evidence you give in the dock. It goes without saying that practising the presentation will make it natural and intuitive – it’s very often the case that an unrehearsed presentation stands out a mile.

Q: When enhancement has been carried out, and you’re showing something that has been improved from the original, what is the best way of conveying this to the jury?

A: Simply, show them both versions wherever possible, but also explain why the enhancement has been carried out. It’s useful for the OIC to have a broad understanding of what enhancement has been done – just in case of any questions, but enhancement (if done by an experienced professional) is generally accepted in court as admissible evidence. It’s important here to also show if necessary that there is an effective audit trail as to what has been done, by whom and how.

I’m always happy to talk CCTV with anyone with a mutual interest, so please feel free to contact me at info@ccl-forensics.com or on 01789 261200.

Ian Rogers

CCTV Analysis Expert