A puzzling cell site case

This month’s cell site blog takes a look at an obscure case involving international roaming. Dr Iain Brodie tackles an unusual occurrence involving breaking and entering.

Call data records were supplied, but they showed an unexpected pattern of calls which would leave even the most experienced cell site analyst baffled.

This is featured in the case study below. If you require more information, please feel free to get in touch on 01789 261200 or email ibrodie@ccl-forensics.com.

Case study: An unusual international roaming scenario

CCL-Forensics’ cell site analysts recently carried out investigations for a case from about a year ago in which the suspect was accused of a spate of breaking and entering.

I was initially very puzzled by the call data records for the suspect’s phone, some of which are reproduced below:

Unusual call data activity

As you can see, the call data records appeared to show some very rapid movement of the suspect’s phone – including international roaming. After further analysis, we had to admit that we were a little stumped.

However, ANPR data was subsequently for the suspect’s vehicle was subsequently made available to us. This, together with some eyewitness reports, made the case much clearer and we were able to piece together what had happened, and identify the culprit.

Take a look at the ANPR data below to find out what had happened.

Continue reading

Advertisements

Does the weather affect the accuracy of cell site analysis techniques?

It’s a common question asked of cell site analysts. How does, for example, rain affect the validity of cell site analysis techniques? Iain Brodie looks at weather and its effect – or otherwise – on cell site measurements, surveying and interpretation.

Q: This sounds like a question which regularly comes up in court. Is it?

A: In short, yes. I’ve regularly been asked about the effects, particularly of rainfall, on the coverage of mobile phone masts. It’s a very common challenge as to the admissibility of cell site evidence. The simple answer that is it does make a difference, BUT… not a significant one.

Q: So what difference does it make?

A: As mentioned earlier, very little. In the UK, even the heaviest rain pulses never come in bursts of more than 40mm per hour. Even at this intensity, the level of attenuation (reduction in signal strength) is less than one decibel per kilometre – or to put that into English, not very much at all. Remember also, that unless the weather conditions in question are very localised, it is likely that all relevant cells will be affected by a similar amount – hence cancelling out any major effect.

It could only really become an issue (and still not a very major one) when a cell covers a very large distance – typically for rural cells.

Q: What about cells which are linked together by radio link, rather than underground cables?

A: It’s a relatively common configuration that rural masts are linked together by a microwave link, rather than being connected directly to the network by traditional copper or fibre-optic cable. It’s been questioned in court as to whether rainfall or other meteorological conditions can affect this, hence “knocking out cells” for a period of time.

These microwave links operate on a much higher frequency than the waves used to connect individual calls – and that makes them much more susceptible to heavy rain – BUT… the power with which they operate is high enough that it would only cause an issue in a tiny minority of cases. It HAS happened – just not very often. Plus, the skill of the cell site analyst is called into play here, as knowledge of how the network is configured can be crucial.

For example, certain network operators tend to use microwave links between sites – others tend not to. Knowing this, puts this issue – and any potential challenges from the other side – into context.

Q: Is there a general rule of thumb about the technical effects of the weather?

A: In summary, you can never say weather has no effect – but any small effect it does have is likely to have no significant impact on the validity of the cell site analysis of the case in question.

Remember that even if a particular cell WAS to be affected by weather at the time of the offence, a good cell site analyst would also pick up other (neighbouring) cells which might also serve at each location surveyed. So if a cell had been inoperative either at the time of the alleged crime, and a different cell was serving at the scene, our survey process would generally detect the other cell anyway.

Clearly a cell could also be off air at the time of the survey (although I don’t tend to like surveying in really foul weather!) so we wouldn’t know for sure if it would have served or not. However, if we suspected that the cell being off air was temporary we would survey on repeat occasions. Also we retain all our survey data from all investigations so often we can see any changes to networks over time from previous surveys in the area.

Q: Are there any other weather related effects? Surely radio towers get hit by lightning and equipment rooms are prone to flooding? Does snow ever build up on the antennas and affect their performance?

A: Firstly, radio towers are always built with lightning conductors and the antennas themselves are insulated from the metallic structure of the tower. Radio equipment rooms tend to be sealed and mounted on small platforms so as to avoid being flooded. As for snow – the antennas are vertical, and since they do transmit energy, there is also a very slight warming effect. Thus they are highly unlikely to ever be affected by a build-up of snow. Of course I cannot say for sure that faults have never occurred in extreme weather – but I can say that even in the most extreme weather – such faults are still highly unlikely.

Q: So, to wrap up, if you were challenged in court about the effect of the weather on cell site analysis, what would you say?

A: Simply that you can never say weather has NO effect, but the amount of variation it causes is not sufficient to discredit cell site analysis as a science. Remember that the more data you have, and the more analysis you do, over a significant timescale – the more robust the evidence… and a drop or two of rain isn’t going to affect that.

SQLite analysis for forensic practitioners

epilog‘s developers have put together a one-day training course to help you to get the best possible results from digital investigations involving SQLite databases.

The course covers the basics of epilog and demonstrates how to deal with SQLite logically, as well as covering how to optimise results and advanced use of the tool. It will help you to get more from your investigations.

For example, the iPhone web cache is stored in an SQLite database. In a recent case, epilog recovered and presented nearly 5,000 entries from the web cache, where only 400 live (visible) entries were shown – including both textual and binary data. The tool streamlined the process by identifying the tables from which the data originated, and then allowed the investigator to use the “export to insert statements” functionality to make these records live again. This enabled the deleted cached records to be parsed and processed.

Our training course will teach you how to do this, and much more.

It takes place on February 7, 2012, at our offices in Stratford-upon-Avon. It’s a one-day course, costing just £250+VAT per person – a bargain in anyone’s book. Call us now on +44 (0)1789 261200 or email info@ccl-forensics.com for more information or to book a place.

Alex Caithness

epilog developer

PIP II: More about XPaths

Never one to break my word, I’d like to welcome you to PIP: The Video part II, as promised in the first video.

We’ll take a more in-depth look at XPaths, and show you in a little more detail how PIP can help you to get more out of digital investigations.

If you’d like more information about PIP, or have any suggestions for additions to the library, please contact us on pip@ccl-forensics.com.

Alex Caithness

PIP developer

Challenges surrounding the extraction of CCTV evidence

Q: What are the main challenges faced by police when it comes to extracting raw CCTV evidence?

A: Quite simply it’s the multitude of different systems out there, all recording in a myriad of proprietary formats and using different recording methods. There’s no standard way of extracting data. This means that the task of retrieving CCTV evidence is becoming increasingly more complex. Most systems now tend to fall into one of two categories: DVR-based or NVR-based.

DVRs, or digital video recorders, are stand-alone units that are essentially the modern equivalent of the old video cassette recorder (VCR). The CCTV cameras are connected directly to the unit and the DVR digitally compresses the analogue video onto an internal hard drive. They are often found as single units in small business or retail premises, although they’re increasingly to be found in private residences too. However, DVRs can also be cascaded together and networked for use in much larger systems, such as town centre schemes.

NVRs, or network video recorders, differ in that they record video that’s been digitally encoded by the camera and then transmitted over a network. The advantage is that they don’t have to be connected directly to the cameras and can be placed anywhere within an IT network. This in turn means that recordings can be remotely managed and viewed from any location across the network.

However, just to confuse things further, there are also numerous PC-based systems where the CCTV recording and playback is integrated within the computer rather than a standalone DVR/NVR unit.

Q: And within these groups, presumably the devices are all different?

A: Absolutely – there is no real industry standard, and most digital CCTV systems use a proprietary compression format, or codec as it’s known. This means that there is no simple way of extracting viewable video files – and therein lies the problem.

Q: How much of a problem is this?

A: It can be a big one. Many digital CCTV systems have a built in CD/DVD writer or USB port for downloading and archiving data, but this will still be in a proprietary format and needs an associated proprietary player to view the video.

There may also be occasions when the recording unit itself must be removed, but this can have numerous cost and legal implications, particularly in terms of insurance, security, etc.

The solution is that you need a large array of tools to get at this evidence, and then to process it into a form which means you can use it in court without compromising the chain of evidence and losing quality of the footage.

Q: So, what’s the advice for investigators who need to seize CCTV evidence?

A: Most investigators already know that it is preferable to download the data directly from the system rather than remove the device from the premises.

The most important thing is to ensure that the CCTV footage is retrieved in its native format, as this retains image quality and integrity. Ideally the replay software should be downloaded too, or at the very least a note made of the make and model of the system. If you can’t download it at the scene then you’ll need to take the whole recording unit, which will need to be treated like a standard computer exhibit and the hard drive forensically imaged.

It is also important to remember that it’s often impractical to download all the recorded footage, and consideration must be given to the time period of interest and the cameras required.

Whatever you do, don’t just pull out the hard drive! This may seem like an obvious option but it’s fraught with problems. The hard drive from a DVR will rarely be compatible with anything other than the original recorder, and will often not be in a Windows-compatible format. Therefore the video files will not be accessible when connected to a PC.

Q: So if you have the data on disc, what happens next?

A: It tends to fall into three categories:

  1. You have the data in a proprietary format, and it comes with a player application.
  1. You have the proprietary data, but with no player.
  1. The device exports in a format (for example .avi) which can be viewed with, say Windows Media Player. Whichever one you get, you will still have to process this data, and maintain its integrity and quality. This is where you need the vast array of tools mentioned previously, firstly to replay and capture the relevant footage from the player, and then to edit, enhance, and compile it into something court-friendly. You can’t just walk into a pressurised court environment with a collection of discs containing hours of footage and expect to spin through to the points of interest!

Q: …and if you have to image the hard drive in the device?

A: You still have to find a way to extract and convert this raw data into something usable, and that takes time. It should also be noted that a clone may not always be recognised by the host DVR, in which case using the original hard drive may be the only option. Either way, this should only be undertaken by suitably competent technical staff.

Q: When you have extracted and converted the footage, how do you go about editing, compiling and analysing it?

A: Again, this is where the range of tools comes in. Here at CCL-Forensics, we have invested considerably in cutting-edge image processing technologies and have the most powerful forensic video enhancement, editing and analysis systems available today. With this technology there isn’t any sort of CCTV or video footage that we shouldn’t be able to deal with. I’d be more than happy to give anyone a guided tour, to show just what’s possible.

Why not give CCL-Forensics a call on 01789 261200 or info@ccl-forensics.com if you have any queries, or a current case. A no-obligation chat about CCTV is just a phone call away!

Grab deleted SMS from Androids

In this, the third in our series of brief videos about epilog, senior programmer Alex Caithness demonstrates how epilog can be used to present deleted SMS messages from a raw image acquired from the JTAG interface of an Android phone.

epilog is an SQLite forensic tool from CCL-Forensics, and is available for download as a free trial from our website.

For more information about epilog, please contact the team at epilog@ccl-forensics.com.

Android Ice Cream Sandwich Browser Cookies (and other artefacts)

The Android browser traditionally had data structures that were distinctly Android; but as Alex Caithness explains, there are signs of convergence with another of Google’s pet projects…

I should probably start by explaining that Android has a delightful habit of naming its operating systems after desserts. The upside of this is that it’s quirky; the downside is that cake consumption in the lab increases by a significant factor.

Hence the name “Ice Cream Sandwich”.

Across previous versions of Android, the cookie storage format has remained unchanged: they have been neatly stored in the browser’s “databases” folder in the “cookies” table of the “webview.db” SQLite database; this appears to have changed in version 4.0 of Android AKA Ice Cream Sandwich (ICS).

Firstly, what is peculiar is that the “webview.db” file still contains the legacy “cookies” table, however in testing this was never populated. Instead, a new database named “webviewCookiesChromium.db” is used to store cookie data.

The name of the file gives us a big clue to the nature of the file – we’re seeing a convergence between the Android browser and Chromium (the browser upon which Google Chrome is built). Investigating the database confirms this; the schema and structure of data in this new database is identical to that of Chrome’s.

The great news for Dunk! users is that they can go right ahead and use the Google Chrome decoder on this file to parse and extract the cookies held.

There is also a second cookies database present in ICS named “webviewCookiesChromiumPrivate.db”. This database contains cookies transmitted while an “Incognito Tab” (the private browsing feature) is being used. The structure is identical to the other database; however, when the incognito tab is closed the file is truncated to 0 bytes.*

Further evidence of this convergence towards Chrome comes from the cache structure which, like the cookies, has moved to the same structure as is found in Chrome. For more details, take a look at http://www.chromium.org/developers/design-documents/network-stack/disk-cache.

*Although further research is required we anticipate that epilog will be able to recover these records from a raw dump of the flash chip!

Alex Caithness

R&D Team