XML and plist parser – updated version available

We’ve updated PIP – our XML and plist parser.

PIP has already proved incredibly popular, and is used by a number of investigation agencies across the world.

The new version is available for download here (license key purchase required) – and is a free upgrade to those who have already bought PIP.

We’ve listened to feedback received from the family of PIP users, and have introduced the following improvements:

Improved Interface – to improve work-flow, we have updated the application’s layout

New Tree View – see, at-a-glance, the structure of your data

Automatic building of XPaths – The Tree View can now be used to show PIP the data you are interested in – and PIP generates the XPath automatically.  This feature even works with Apple’s Property List ‘dictionary’ structures.

Import/Export Batch Jobs – Set-up a batch job of XPaths for a particular folder structure (iOS Library or Application folders for example) and then export the batch so that you, or anyone else in your lab can re-use it when you next come across the same data

Command line version – version 1.1 of PIP comes with the “pipcmd” command-line utility, allowing you to integrate PIP into tool chains and other automated tasks

To find out more, or to purchase PIP, please visit our PIP download page.

 

Advertisements

Benefits of hindsight: Why ‘nurturing’ data can prove valuable for cell site analysts.

It’s at this time of year, when the sun is shining (well, it IS at the very moment these words are being written), that carrying out an intensive cell site survey seems almost like a perk of the job. But, as everyone involved knows, a cell site expert shouldn’t expect that each assignment should come with such luxuries.  Surveys aren’t always necessary – and even where they are, there could be a smarter solution.  In this month’s cell site ‘blog’, Matthew Tart looks at the possibility of using data from previous cases.

This month’s topic: Use of historic cell site data

Q: First of all, precisely what do we mean by historic cell site data?

A: Simply, it’s data CCL-Forensics has generated from carrying out previous cases, which we have organised and stored in an ever-growing database.  The reason we have this, is because we don’t carry out static surveys as we have found they have limited repeatability and failed validation (this is described in our previous blog here), which I’ll go into in a little more detail later.  So if we’re interested in where a particular cell serves, there is a potential that we’ve already surveyed relevant areas.  We’re not (quite!) up to UK wide coverage yet, but the database is growing rapidly, plus we’re getting additional cell data every time we travel between our offices and the general area of the survey.  

Q: So, how does this actually benefit the case. Surely, all cases are different, and you may still have to do some surveying?

A:  This is not necessarily a replacement for any future survey, it is an enhancement, but it does have some significant advantages.  The first being that it can help us to scope out a case, and therefore produce a more accurate strategy – keeping costs down.  The more CCL-Forensics know about the network infrastructure of the location in question, the more easily we can produce the most cost-effective forensic solution to the problem at hand. It’s also been useful in court, where very specific questions have been raised about the coverage of a cell; if we have relevant data, our expert in the witness box can easily (and with no cost to anyone involved), use that area information – adding value to proceedings.  In short, it means that we simply have more data with which to work – and scientifically, that’s a very good place to be.

Q: But isn’t there a risk that the data may be out of date?

A: The timeliness of data is always a consideration in cell site analysis.  One of the most common concerns tends to surround how the network may have changed in the (often) months between the incident and the survey.  By using data collected in the past, it could be more relevant to the time of the incident.  Additionally further surveys can be undertaken to assess whether that there have been changes in the network over a period of time – and not even the networks themselves can give us information as reliable as that.

Q:  Why aren’t all cell site analysts doing this?

A: I’m not saying it’s only CCL-Forensics who are doing it, but there are analysts who practice certain surveying techniques where keeping a database would not be appropriate.  Earlier, I mentioned the concept of carrying out static surveys.  CCL-Forensics have gone through this at length before, but this just goes to reinforce why turning up at a scene, carrying out a few measurements and then leaving again, is not the strongest piece of science in the world.

Using static surveys each job stands alone and in isolation from any other examination.

Q: It must take up a serious amount of storage space

A: CCL-Forensics had to buy a huge new server to hold this data, but it’s already been worth it.  We’ve saved so much time by having access to this data, and passed on significant cost savings as a result.  It also means that our clients are getting stronger evidence, effectively for free.  It’s stronger because we can more accurately assess service areas, and also get an educated idea of network changes, which can inform expectations at the outset of an investigation and same time during it.

For us, it’s definitely an investment in the future and ideally, we’d like to be a position where we have the whole country mapped, but that’s a little way away at the moment!

To finish with an example: There was an urgent pre case management hearing relating to an incident in a city 150 miles from our base.  We were asked to provide some analysis of call data records on a Wednesday morning, which were needed by the Thursday evening. 

CCL-Forensics checked our database and found extensive surveys in and around the locations of interest, and could make an informed estimate of cell service at those addresses without the disruption, delay and cost of travelling to the area and carrying out a survey.  Basically this would not have been possible, given the time constraint, had we not had the historic data. 

Of course it is not just the survey time that causes delay, it’s the preparation, travelling, data manipulation, analysis and reporting of that data.  But, as we’d already surveyed the area, the client had the report they needed well ahead of the deadline: something which would have been practically impossible otherwise. 

To summarise, every case we do makes CCL-Forensics service stronger.

For more information about historical cell site data usage, or any of the other issues highlighted in this month’s blog, please email Matthew Tart at mtart@ccl-forensics.com or call 01789 261200

 

Mystery box reveals digital secrets

Arun Prasannan, member of CCL-Forensics’ R&D team. 

Every now and again, an unusual device arrives for analysis at CCL-Forensics, which proves interesting – but above all, significant to an investigation.

Earlier this month, a UK law enforcement agency submitted what can only be described as a ‘black box’.  It was plastic, no bigger than a packet of cigarettes, and from the outside, it had only a slot for a SIM card and a socket for power.

Working closely with the investigating agency, a member of CCL-Forensics’ R&D team carried out an in-depth analysis of what was inside the device, and what data it was capable of storing.

It was initially suspected that it was some kind of tracking device, and when disassembled, it was found to contain a battery, and two separate circuit boards, to one of which was attached a mercury switch which detected movement.  One board contained all the circuitry one would normally expect on a mobile phone, and had everything it needed to connect to a GSM network.  When examined VERY closely, it was labelled (in very small print) with an IMEI number.  From this, we could identify the board, and then research all the available documents about that piece of hardware.

Interestingly, it was a widely used GSM module found in many mobile devices such as GPS trackers, Fax machines and even some phones.

The SIM card was analysed separately, and it was strongly suspected that there was additional data on the board itself.

Our analysts procured a test module, and carried out a comprehensive technical analysis to validate what data it could store.  It was found to have the capacity to store call data (made, received, missed), SMS and contacts – as well as some call timers.  It was also determined that SMS messages could be extracted without changing their status. 

Following this comprehensive research, it was found that the suspect device DID contain a number of phone numbers and call times – which were presented back to the investigator in the case.  This was a level of potentially vital evidence which would have been missed without this very low-level investigation of the device and the data it contained.

It also highlights the talents of CCL-ForensicsR&D department, and the value investigators can derive by not simply opting for a ‘plug and play’ forensic examination.

For more information, please contact us at research@ccl-forensics.com

The Forensic Implications of SQLite’s Write Ahead Log

By Alex Caithness, CCL-Forensics

SQLite is a popular free file-based database format which is used extensively both on desktop and mobile operating systems (it is one of the standard storage formats available on both Android and iOS). This article sets out to examine the forensic implications, both pitfalls and opportunities, of a relatively new feature of the database engine: Write Ahead Log.

Before we begin, it is worth taking a moment to describe the SQLite file format. Briefly, records in the database are stored in file which in SQLite parlance is called the ‘Database Image’. The database image is broken up into “pages” of a fixed size (the size is specified in the file header). Each page may have one of a number of roles, such as informing the structure of the database, and crucially holding the record data itself. The pages are numbered internally by SQLite starting from 1.

Historically SQLite used a mechanism called “Rollback Journals” for dealing with errors occurring during use of the database. Whenever any data on a page of the database was to be altered, the entire page was backed up in a separate journal file. At the conclusion of a successful transaction the journal file would be removed; conversely if the transaction was interrupted for any reason (crash, power cut, etc.) the journal remained. This means that if SQLite accesses a database and finds that a journal is still present something must have gone wrong and the engine will restore the database to its previous state using the copies of pages in the journal, avoiding corrupted data.

From version 3.7.0 of the SQLite engine an alternative journal mechanism was introduced called “Write Ahead Log” (ubiquitously shortened to “WAL”). WAL effectively turned the journal mechanism on its head: rather than backing up the original pages then making changes directly to the database file, the database file itself is untouched and the new or altered pages are written to a separate file (the Write Ahead Log). These altered or new pages will remain in the WAL file, the database engine reading data from the WAL in place of the historic version in the main database. This continues until a “Checkpoint” event takes place, finally copying the pages in the WAL file into the main database file. A Checkpoint may take place automatically when the WAL file reaches a certain size (by default this is 1000 pages) or performed manually by issuing an SQL command (“PRAGMA wal_checkpoint;”) or programmatically if an application has access to the SQLite engine’s internal API.

Initial state: No pages in the WAL

Initial state: No pages in the WAL

Page Altered - new version written to WAL

Page 3 is altered. The new version of the page is written to the WAL and the database engine uses this new version rather than the old version in the database file itself.

Checkpoint

A checkpoint operation takes place and the new version of the page is written into the database file.

It is possible to detect whether a database is in WAL mode in a number of ways: firstly this information is found in the database file’s header; examining the file in a hex editor, the bytes at file offset 18 and 19 will both be 0x01 if the database is using the legacy rollback journal or 0x02 if the database is in WAL mode. Secondly you can issue the SQL command “PRAGMA journal_mode;” which will return the value “wal” if the database is in WAL mode (anything else indicates rollback journal). However, probably the most obvious indication of a database in WAL mode is the presence of two files named as “<databasefilename>-wal” and “<databasefilename>-shm” in the same logical directory as the database (eg. if the database was called “sms.db” the two additional files would be “sms.db-wal” and “sms.db-shm”).

The “-wal” file is the actual Write Ahead Log which contains the new and updated database pages, its structure is actually fairly simplistic. The “-wal” file is made up of a 32 byte file header followed by zero or more “WAL frames”. The file header contains the following data:

Offset Size Description
0 4 bytes File signature (0x377F0682 or 0x377F0683)
4 4 bytes File format version (currently 0x002DE218 which interpreted as a big endian integer is 3007000)
8 4 bytes Associated database’s page size (32-bit big endian integer)
12 4 bytes Checkpoint sequence number (32-bit big endian integer which is incremented with every checkpoint, starting at 0)
16 4 bytes Salt-1 Random number, incremented with every checkpoint *
20 4 bytes Salt-2 Random number, regenerated with every checkpoint
24 4 bytes Checksum part 1 (for the first 24 bytes of the file)
28 4 bytes Checksum part 2 (for the first 24 bytes of the file)

* In testing it was found that although the official (and at the time of writing, up to date) command line version of SQLite v3.7.11 behaved correctly, when using SQLite Expert v3.2.2.2.2102 this value appeared to be regenerated after each checkpoint (which is assumed by the author to be incorrect behaviour)

The WAL Frames that follow the header consist of a 24 byte header followed by the number of bytes specified in the file header’s “page size” field which is the new or altered database page. The Frame Header takes the following form:

Offset Size Description
0 4 bytes Database page number (32-bit big endian integer)
4 4 bytes For a record that marks the end of a transaction (a commit record) this will be a 32-bit big endian integer giving the size of the database file in pages, otherwise 0.
8 4 bytes Salt-1, as found in the WAL header at the time that this Frame was written
12 4 bytes Salt-2, as found in the WAL header at the time that this Frame was written
16 4 bytes Checksum part 1 – cumulative checksum up through and including this page
20 4 bytes Checksum part 2 – cumulative checksum up through and including this page

There are a number of potential uses and abuses for the WAL file in the context of digital forensics, but first, the behaviour of SQLite while in WAL mode should examined. A number of operations were performed on a SQLite database in WAL mode. After each operation the database file along with its “-shm” and “-wal” files were copied, audited and hashed so that their states could be examined.

Step 1: Create empty database with a single table:

8a9938bc7252c3ab9cc3da64a0e0e06a *database.db
b5ad3398bf9e32f1fa3cca9036290774 *database.db-shm
da1a0a1519d973f4ab7935cec399ba58 *database.db-wal

1,024       database.db
32,768      database.db-shm
2,128       database.db-wal

WAL Checkpoint Number:  0
WAL Salt-1: 3046154441
WAL Salt-2: 220701676

Viewing the database file using a hex editor we find a single page containing the file header and nothing else. As noted as well as creating a database file, a table was also created, however this data was written to the WAL in the form of a new version of this page. The WAL contains two frames, this new version of the first page in addition to a second frame holding an empty table page. When accessing this database through the SQLite engine this information is read from the “-wal” file transparently and we see the empty table, even though the data doesn’t appear in the database file itself.

Step 2: Force a checkpoint using PRAGMA command:

dd376606c00867dc34532a44aeb0edb6 *database.db
1878dbcefc552cb1230fce65df13b8c7 *database.db-shm
da1a0a1519d973f4ab7935cec399ba58 *database.db-wal

2,048       database.db
32,768      database.db-shm
2,128       database.db-wal

WAL Checkpoint Number:  0
WAL Salt-1: 3046154441
WAL Salt-2: 220701676

Using the pragma command mentioned above, the database was “checkpointed”. Accessing the database through SQLite we see no difference to the data but examining the files involved, we can clearly see that the database file has changed (it has different hash) furthermore it has grown. Looking inside the database file we can see the two pages from the “-wal” file have now been written into the database file itself and SQLite will be reading this data from here rather than the “-wal” file.

The WAL Checkpoint number and salts were not changed at this point, as we will see they are altered the next time that the WAL is written to.

Another interesting observation is that the “-wal” file was left completely unchanged during the checkpoint process – a fact that will become extremely important in the next step.

Step 3: Insert a single row:

dd376606c00867dc34532a44aeb0edb6 *database.db
6dc09958989a6c0094a99a66531f126f *database.db-shm
e9fc939269dbdbfbc157d8c12be720ed *database.db-wal

2,048       database.db
32,768      database.db-shm
2,128       database.db-wal

WAL Checkpoint Number:  1
WAL Salt-1: 3046154442
WAL Salt-2: 534753839

A single row was inserted into the database using a SQL INSERT statement. Once again we arrive at a situation where the database file itself has been left untouched, evidenced by the fact that the database file’s hash hasn’t altered since the last step.

The “-wal” file hasn’t changed size (so still contains two WAL frames) but clearly the contents of the file have changed. Indeed, examining the file in a hex editor we find that the first frame in the file contains a table page containing the newly inserted record as we would expect. What is interesting is that the second frame in the file is the same second frame found in the file in the previous two steps. After a checkpoint the “-wal” file is not deleted or truncated, it is simply reused, frames being overwritten from the top of the file.

Examining the Frame’s headers we see the following:

Frame Page Number Commit Size Salt-1 Salt-2
1 2 2 3046154442 534753839
2 2 2 3046154441 220701676

Both frames relate to the same page in the database but their salt values differ. As previously noted these two salt values are copied from the WAL file header as they are at the time of writing. Salt-2 is regenerated upon each checkpoint, but key here is Salt-1 which is initialised when the WAL is first created and then incremented upon each checkpoint. Using this value we can show that the page held in second frame of the WAL is a previous version of page held in the first frame: we can begin to demonstrate a timeline of changes to the database.

Step 4: Force a checkpoint using PRAGMA command:

704c633fdceceb34f215cd7fe17f0e84 *database.db
a98ab9ed82393b728a91aacc90b1d788 *database.db-shm
e9fc939269dbdbfbc157d8c12be720ed *database.db-wal

2,048       database.db
32,768      database.db-shm
2,128       database.db-wal

WAL Checkpoint Number:  1
WAL Salt-1: 3046154442
WAL Salt-2: 534753839

Once again a checkpoint was forced using the PRAGMA command.  As before the updated pages in the WAL were written into the database file and this operation had no effect on the contents of the “-wal” itself. Viewing the database using the SQLite engine shows the same data as in the previous step.

Step 5: Insert a second row, Update contents of the first row:

704c633fdceceb34f215cd7fe17f0e84 *database.db
d17cf8f25deaa8dbf4811b4d21216506 *database.db-shm
ed5f0336c23aef476c656dd263849dd0 *database.db-wal

2,048       database.db
32,768      database.db-shm
2,128       database.db-wal

WAL Checkpoint Number:  2
WAL Salt-1: 3046154443
WAL Salt-2: 3543470737

A second row was added to the database using a SQL INSERT statement and the previously added row was altered using an UPDATE statement.

Once again, and as is now fully expected, the database file is unchanged, the new data has been written to the WAL. The WAL contains two frames: The first holds a table page containing the original record along with our newly added second record; the second frame holds a table page containing the updated version of our original record along with the new, second record. Examining the frame headers we see the following:

Frame Page Number Commit Size Salt-1 Salt-2
1 2 2 3046154443 3543470737
2 2 2 3046154443 3543470737

In this case both frames contain data belonging to the same page in the database and the same checkpoint (Salt-1 is the same for both frames); in this case the order of events is simply detected by the order in which the frames appear in the file – they are written to the file from the top, down.

Step 6: Insert a third row:

704c633fdceceb34f215cd7fe17f0e84 *database.db
5ac6d9e56e6bbb15981645cc6b4b4d6b *database.db-shm
672a97935722024aff4f1e2cf43d83ad *database.db-wal

2,048       database.db
32,768      database.db-shm
3,176       database.db-wal

WAL Checkpoint Number:  2
WAL Salt-1: 3046154443
WAL Salt-2: 3543470737

Next, a third row was added to the database using an INSERT statement. Viewing the database logicaly with the SQLite engine we see all three records. While database file remains unchanged, the “-wal” file now contains 3 frames: the first two are as in the previous step with the third and final new frame holding a table page with all three records. The frame headers contain the following information:

Frame Page Number Commit Size Salt-1 Salt-2
1 2 2 3046154443 3543470737
2 2 2 3046154443 3543470737
3 2 2 3046154443 3543470737

We now have three versions of the same page, as before the sequence of events is denoted by the order they occur in the file.

Step 7: Force a checkpoint using PRAGMA command:

04a16e75245601651853fd0457a4975c *database.db
05be4054f8e33505cc2cd7d98c9e7b31 *database.db-shm
672a97935722024aff4f1e2cf43d83ad *database.db-wal

2,048       database.db
32,768      database.db-shm
3,176       database.db-wal

WAL Checkpoint Number:  2
WAL Salt-1: 3046154443
WAL Salt-2: 3543470737

As we have observed before the checkpoint results in to the up-to-date records being written into the database, the “-wal” file is unaffected.

Step 8: Delete A Row:

04a16e75245601651853fd0457a4975c *database.db
dca5c61a689fe73b3c395fd857a9795a *database.db-shm
3b518081a5ab4a7be6449e86bb9c2589 *database.db-wal

2,048       database.db
32,768      database.db-shm
3,176       database.db-wal

WAL Checkpoint Number:  3
WAL Salt-1: 3046154444
WAL Salt-2: 2798791151

Finally in this test, the second record in the table (the record added in Step 5) was deleted using an SQL DELETE statement. Accessing the database using the SQLite engine shows that the record is no longer live in the database.

As per expectations the database file is unaffected by this operation, the changes instead being written to the WAL. The “-wal” file contains three frames:  the first frame holds a table page with the second record deleted (the data can still be seen, and could be recovered using a tool such as Epilog, however the metadata on the page shows that the record is not live). The remaining two pages are identical to the final two frames in the previous step. Examining the frame headers we see the following:

Frame Page Number Commit Size Salt-1 Salt-2
1 2 2 3046154444 2798791151
2 2 2 3046154443 3543470737
3 2 2 3046154443 3543470737

Here we once again see three frames all containing data from the same database page, this time the most recent version of the page is found in frame 1 as it has the highest Salt-1 value; the other two frames have a lower Salt-1 value and are therefore older revisions; as they both share the same Salt-1 value we apply the “position in file” rule, the later in the file the frame occurs, the newer it is. So in order of newest to oldest the frames are ordered: 1, 3, 2.

Summarising the findings in this experiment:

  • Altered or new pages are written to the WAL a frame at a time, rather than the database file
  • The most up-to-date pages in the WAL are written to the database file on a Checkpoint event – this operation leaves the “-wal” file untouched
  • After a Checkpoint, the “-wal” file is reused rather than deleted or truncated,  with new frames
  • Multiple frames for the same database page can exist in the WAL, their relative ages can be derived by first examining the frame header’s Salt-1 value with newer frames having higher values. Where multiple frames have the same Salt-1, their age is determined by their order in the WAL, with newer frames occurring later

Pitfalls and Opportunities

The most obvious opportunity afforded by the Write Ahead Log is the potential for time-lining of activity in database. To prove the concept, a small Python script was written which would automate the analysis of the frames in a WAL file and provide a chronology of the data; a sample output is shown below:

Header Info:
    Page Size: 1024
    Checkpoint Sequence: 3
    Salt-1: 3046154444
    Salt-2: 2798791151

Reading frames...

Frame 1 (offset 32)
    Page Number: 2
    Commit Size: 2
    Salt-1: 3046154444
    Salt-2: 2798791151

Frame 2 (offset 1080)
    Page Number: 2
    Commit Size: 2
    Salt-1: 3046154443
    Salt-2: 3543470737

Frame 3 (offset 2128)
    Page Number: 2
    Commit Size: 2
    Salt-1: 3046154443
    Salt-2: 3543470737

Unique Salt-1 values:
    3046154443
    3046154444

Chronology of frames (oldest first):

Page Number: 2
    Frame 2
    Frame 3
    Frame 1

With further work it should be possible to display a sequence of insertions, updates and deletions of records within a database – a feature which is a top priority for the next update of Epilog. Even without the ability to timeline, it is clear that deleted records can be stored and recovered from the WAL (functionality already present in Epilog).

One behaviour which hasn’t been described in full so far is that a database file in WAL mode isolated from its associated “-wal” file is, in almost all circumstances, a valid database in its own right. For example, consider the test database above as it is at the end of Step 8. If the database file was moved to another directory, as far as the SQLite database engine is concerned this is a complete database file. If this isolated database file was queried, the data returned will be that which was present at the last checkpoint (in our test case, this would be the 3 live records present at the checkpoint performed in step 7).

This raises an important consideration when working with a SQLite database contained in a disk image or other container (eg. a TAR archive): if the database file is extracted from the image or container without its associated WAL files, the data can be out-of-date or incomplete. The other side of the coin is that the “full up-to-date” version of the data (viewed with the WAL present) may lack records present in the isolated database file because of deletions pending a checkpoint. There is, then, an argument for examining databases both ways: complete with WAL files and isolated as it may be possible to obtain deleted records “for free”.

Summing Up

The Write Ahead Log introduced in SQLite 3.7 may afford digital forensics practitioners new opportunities to extract extra data and behaviour information from SQLite databases; however the mechanism should be understood to get the most of the new opportunities and avoid confusion when working with the databases.

If you have any comments or questions, please leave a comment below or get in touch directly at research@ccl-forensics.com.

References:

SQLite File Format

Write Ahead Log

Alex Caithness, CCL-Forensics

New version of PIP (XML and plist parser) coming soon

Our ever-popular XML and plist parsing tool, PIP, is coming of age with a new, improved version.

Currently in beta-test, and with the updated version available free to current PIP users (following its official release, obviously!), we’ll be announcing more details over the coming weeks.

As a teaser, this is what you can expect from the new version (v1.1):

  • Improved GUI – the layout of the application has been updated to improve work-flow
  • New Tree View – view your data graphically to see, at-a-glance, the structure of your data
  • Automatic XPath Building – Now you can use the Tree View to show PIP the data that you are interested in and PIP will generate the XPath automatically. This even works with Apple’s Property List ‘dictionary’ structures.
  • Import/Export Batch Jobs – Set-up a batch job of XPaths for a particular folder structure (iOS Library or Application folders for example) and then export the batch so that you, or anyone else in your lab can re-use it when you next come across the same data
  • Command line version – version 1.1 of PIP comes with the “pipcmd” command-line utility, allowing you to integrate PIP into tool chains and other automated tasks
For more information about XML and plist parsing, please visit http://www.ccl-forensics.com/pip or email us at pip@ccl-forensics.com.

CCL-Forensics at Criminal Law Conference

CCL-Forensics is pleased to be involved in the annual Law Society Criminal Law Conference this week.

Our Forensics Manager, Mark Larson, will take to the stage to discuss how digital evidence can prove crucial in criminal cases.

It’s happening at Chancery lane in London on Friday, and further details can be found at http://services.lawsociety.org.uk/events/node/54465.

We’ll be presenting alongside our counterparts at Manlove Forensics (http://www.manloveforensics.co.uk/), who will be concentrating on blood pattern analysis, body fluids and DNA profiling.

It’ll be a chance to give criminal law solicitors and others who have an interest in the criminal justice system, the opportunity to see how established, well accredited forensic expert witness companies can enhance criminal cases.

If you are attending this event, please stop by and say hello.  We’ll be handing out our famous stress-toy judges on the day, so don’t miss out!

.

Cell site analysis and impactive court presentation

The monthly cell site blog is back – and this month, we’ll be looking at what makes for an high impact piece of cell site evidence in court, as well as how going that extra mile at the outset of a cell site investigation can, in the long run, save time, money and bring your case to a speedier, more positive conclusion.

Impactive court presentation

By Dr. Iain Brodie, Cell Site Expert

Let’s consider a real case which CCL-Forensics investigated on behalf of a UK police force.  We’ll change some of the location and crime details for the sake of confidentiality, and to help with legalities.  The story goes like this:  there was an aggravated burglary at a house in a semi-rural location, and following enquiries, a man was arrested.  It was crucial for the prosecution to demonstrate the man was at the scene and not merely in the vicinity.

The prosecution claimed that the man in custody had made a number of phone calls to an accomplice, waiting outside the property, while the crime was in progress.  They obtained the call data records (CDRs) from the phone company which the phone (attributed to the individual) was connected to at the time.

CCL-Forensics cell site experts looked at the calls at the pertinent time, and could see that there were indeed incoming and outgoing calls – as well as a number of texts.  These events on the CDR used three different cell IDs (mobile phone mast sectors), but all took place over the period of a number of minutes.

In order to determine whether the suspect was likely to have been at the scene, surveys were carried out of the entire coverage areas of these three cells.  CCL-Forensics performed a number of drive surveys, looking at areas where the cells in question would initiate a mobile phone call.  Once these drive surveys had been carried out, for each of the three masts, they were uploaded onto our mapping system and the so-called ‘derived service areas’ were plotted.

The result was instantly compelling.  Like a neat Venn diagram, the areas overlapped, with that overlap area covering a comparatively small area.  Well within this area, was the crime scene.  It was, to a certain extent, a ‘textbook’ piece of evidence.  The fact that a number of cells were used at the time could easily be down to the fact that the suspect was moving around the house, and receiving a different dominant signal from different elevations of the property.

The question you may well ask, is why not just carry out a ‘spot sample’ at the crime location?  Surely this would have yielded the same result.  The reason for this was down to the case conference CCL-Forensics held with the investigating officer, where it was felt that a more robust survey was required to pre-empt any possible challenge from the defence.  This turned out to be a very wise move, as in the weeks after the survey was carried out, the defence put forward an alibi location which was only a comparatively short distance from the crime scene.

When this point was plotted on the same map (without the need to go out and re-survey), it does indeed show that one of the cells served (for initiating a call) at this location – but not all three.  The alibi location was therefore rejected, and based on the compelling evidence from cell site analysis, the suspect was found guilty.

The map shows the coverage areas, along with the overlap, which ultimately proved to be the pivotal piece of evidence in court.  When presented to the jury in this way, the impact is immeasurable. 

Image

The remit here was to find an effective balance between doing the bare minimum, and doing too much – incurring unnecessary costs.  Had a simple ‘spot sample’ been carried out in the first instance, it would have been necessary to return to the scene to carry out similar exercises at the alibi location – incurring delay and cost.  As it transpired, this was not necessary, as the measurements had already been taken.  In addition to this, the way the evidence was presented, showing the relevance of the small area where the cells’ service overlapped, proved to be an invaluable method of demonstrating the point to the jury.  Cell site evidence, when not presented in an impactive way, can be confusing in court – and at worst, can overwhelm those sitting on the jury.  This was an elegant, easily understandable piece of evidence – and it worked.

This enhanced service was agreed by collaboration of the cell site expert with the customer force at the initial case conference. This has shown the value of providing expert advice from the start of the analysis.

The power of the evidence more than justified ‘going that extra mile’ – and it ultimately saved the expense of carrying out at least one additional survey.  I hope this goes to show that a tailored investigation, based on the intelligence of the case and the requirements of the investigating officer, can be a much more powerful approach than a ‘one size fits all’ turn-up-and-survey approach.

If you would like more information about cell site analysis and its use in cases of this type, please contact me or any of my colleagues by emailing info@ccl-forensics.com.  As ever, please keep the feedback to these articles coming in.  We do enjoy reading your comments and opinions.

Keep posted as next month we will look at another aspect of cell site that will make or breaks a prosecution.