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

We’ll be presenting alongside our counterparts at Manlove Forensics (, 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!



Double accreditation is a forensic first

We’re absolutely delighted to announce something of a ‘forensic first’.

CCL-Forensics has become the first UK digital forensic lab to be accredited to ISO17025 – not just for one part of the business – but for BOTH its computer and mobile phone labs.

It’s taken a long time to get here – and having this standard, cements our position as the UK’s leading supplier of digital investigation services.  It also means clients can have the maximum confidence in the quality of our services – especially if the case goes to court.

ISO17025 is a recommendation of the Home Office Forensics Science Regulator, Andrew Rennison – and all labs handling digital evidence should have it by 2015.  Put simply, it is one of the biggest steps forward the digital forensic industry has ever seen.  We’re already way ahead of the curve!

We’ve had ISO17025 for our phone lab for while now – and were one of only a small number of providers to do so.  The fact that we’ve now been accredited for our PC lab is huge news.

So what does it mean?  To give it its full title, it’s called “the general requirements for the competence of testing and calibration laboratories”.  That means that we are required to have in place an all-encompassing set of detailed standard operating procedures.  These procedures show that we operate a management system, are technically competent, and generate technically valid results.

It’s been the result of a lot of hard work – not only by our dedicated quality department – but by all members of staff who have worked tirelessly to ensure all the procedures are developed to the highest standard.

If you’d like more information about our quality standards, please email Dave Lattimore, Total Quality Manager at

More places you may not have looked for digital evidence

As promised, we continue our list of places you may not have looked for digital evidence. It’s not always obvious, and sometimes we have to dig deep to find anything useful. Read on to find out more…

  1. VOIP (Voiceover IP)

VOIP refers to the communication protocols, technologies, methodologies and transmission techniques involved in the delivery of voice communications and multimedia sessions over internet protocol (IP) networks.

It’s not new technology, but with many phones now having WiFi connectivity or data bundles included in tariffs as standard, it’s becoming a more popular way of communicating. VOIP replaces “traditional” over-the-network phone calls, enabling users to make calls using a computer (Skype is a well-known example of this type of technology).

The traces left by this activity are just as relevant as traditional call logs, but “calls” made using VOIP do not necessarily leave the same type of information on the phone, or call data records, as a standard call. Instead of being logged at the network provider with IMEI, IMSI and other data, it is just recorded as data transfer. It may not even show in the handset’s call list.

VOIP calls do, however, leave a deeper digital trail within a phone either within the application itself or in other log files. The apps may also have their own phonebooks, where contact details are stored separately from the phone’s standard contact list.

Computers are also used for VOIP communications, which will leave traces within the apps and on the hard drive in a similar way to mobile phones.

  1. Web browsers

Internet browsers – on computers, laptops, tablets and smartphones – contain a wealth of data that could prove vital to a case.

As well as a user’s browsing history, other evidential opportunities can include bookmarks, cache data, downloads, social media history, and more. Together with other forms of digital evidence, such as chat logs and emails, a picture can be built of the user’s behaviour, and may help to prove mens rea – intent to commit a crime – in a case. Conversely, of course, it could help to prove someone’s innocence.

Mobile internet has been around since 1999, but has improved vastly since then. Smartphones are now miniature computers, with full-colour and fully-functional mobile web pages – and mobile web browsers work in much the same way as standard browsers. The same information can be extracted from mobile web browsers, helping to add to the bigger picture.

  1. Dynamic key logger

Smartphones are – as their name suggests – generally pretty smart. Many of them can now “learn” how people use them, recording every key press in a log file. For instance, they will remember people’s names and place names between applications – not just in text message apps (as an example).

Users cannot disable this functionality and will not necessarily be aware of its existence. Dynamic key loggers are a potentially-rich source of evidence: it may be that a text message or email of interest may no longer be present on the device – but its content could exist in one of these log files.

The technology gives investigators another method of extracting data from mobile devices, adding an extra dimension to digital evidence.

  1. Data-hiding applications

If you know what you’re doing, it’s entirely possible to hide data on mobile phones, putting it beyond the reach of typical forensic extraction tools and techniques.

There are several apps that can be downloaded to smartphones which can hide data within other applications. This means that, for example, photographs could be hidden within – for example – the stocks and shares app on the phone, but they would only be retrievable using the data-hiding application.

The data remains hidden on the device if the data-hiding app is uninstalled, and can only be retrieved if the app is reinstalled. Valuable evidence may be going unnoticed if the deliberately-hidden data is not located.

CCL-Forensics’ R&D team has developed a technique to analyse the installed apps on a smartphone to identify what that phone is capable of, which enables our analysts to tailor the examination accordingly. How can you analyse a mobile phone unless you know what it can do?

  1. On the circuit board

Just occasionally, a mobile device is so complicated – or the data you’re after is so deeply buried – that the only viable option is interfacing directly with the circuitry.

“Chip off” forensics is nothing new – but removing chips from the circuit board of a device is a destructive process, and one that cannot necessarily be repeated by another qualified expert. Examining the chips in situ is much more desirable.

One such method of doing this is to interface directly with the circuit board. Many phones will have a series of JTAG (Joint Test Action Group) ports, to which connections can be made, and from which data can be retrieved. JTAG is an industry-standard method of carrying out such engineering work, but it is still necessary to interpret the data which is extracted.

CCL-Forensics has spent considerable time researching this. If you require further information about the potential of this technique, please get in touch.

More hints and tips will follow in a few days – stay tuned!

Have you looked everywhere for digital evidence?

Building a good case means gathering as much relevant evidence as possible to build a full picture of the situation.

There are several obvious places to look for evidence: a computer’s hard drive; a flash drive; a SIM card from a mobile phone, for example. But looking down the back of the proverbial sofa can reveal a whole heap of potential evidence you may not have thought of.

Here at CCL-Forensics, we like to be helpful – and we also love a good list. So here, for your delectation, are five places you may not have looked…

  1. Location-based services

SatNav devices are not the only way to stop yourself from getting lost these days. Quite apart from the traditional paper map, most mobile devices now contain built-in GPS which works with applications to provide location-specific data to the user.

A few examples: weather apps showing the local forecast need a GPS fix in order to deliver the correct data; social networking apps such as Facebook and foursquare also use GPS to place the user and their online friends in various locations; and a significant number of devices run GPS in the background without the user even noticing.

All this can leave valuable forensic traces on the device. It’s worth considering whether this data is relevant to your case, and if the geographical location of the person attributed to the phone is important. If so, this data should be requested as part of a handset examination. When combined with, for example, ANPR hits or cell site analysis it could strengthen your case.

  1. Geo-tagged images

Following on from location-based services, it’s now possible to tag photographs and other files with a code from a GPS signal to show where the device was when the file was created.

It’s not just mobile digital devices that do this, either; many digital cameras now use GPS signals to geo-tag their photographs.

This metadata can be used to associate individuals or locations featured in photos with a set of geographic coordinates. It’s potentially valuable data that could go unnoticed using “traditional” forensic tools.

  1. SatNav in your hand

Dedicated SatNav devices are well known among digital forensics investigators, but SatNav apps are becoming increasingly common on mobile devices, with smartphones beginning to replace windscreen-mounted devices. (There are a couple of interesting articles on this subject.)

There is an additional evidential opportunity available on the phones themselves, as there is the potential for them to contain records of directions, searches and other SatNav-based activity. If geographic location is relevant to your case, this opportunity should not be underestimated.

Search terms which coincide with significant locations in your investigation can, for example, show that the user had a specific interest in that location. GPS fixes, where recorded and retrieved, may show that the device had moved to or from that location.

  1. Instant messaging

Instant messaging facilities are now a major part of many computer and phone social media applications – not to mention newer tablet technology.

Using smartphones for instant messaging allows suspected criminals to communicate without details being recorded in text message history or on the billing records. Many tariffs now include data as well as airtime, making IM a much more accessible medium – and it can also be used over WiFi.

Most smartphones will have an inbuilt IM app, or will allow users to download one. Chats are conducted via the internet – but there is the potential to leave a forensic trace behind on the device itself.

This won’t be detailed in a standard examination report containing calls, texts and contact lists – but it’s worth considering whether this type of communication is relevant to your case.

A recent example of how instant messaging can be used extremely effectively in crime is last August’s riots. The BlackBerry Messenger (BBM) service is free and secure, and was used extensively to organise disturbances in the capital, and then throughout the UK. There are plenty of articles documenting how the system works, and how it worked during the riots.

It’s pretty obvious that recovering “fleeting” instant messages can be vital evidence in criminal cases – for the prosecution and for the defence.

  1. Organiser

How much of your life is on your mobile phone? With the widespread rejection of antique items such as paper diaries, smartphone organisers contain a huge amount of information about people’s appointments and movements.

They’re available on computers, smartphones and other mobile devices, and are often synced with other apps via online sites such as Google or Hotmail. It’s not just a diary, either; notes apps and programs are the modern equivalent of scribbling a note on a post-it, and can add a valuable extra dimension to evidence.

The data contained therein can provide a great evidential opportunity, complementing data found elsewhere on the suspect’s device(s).

There are 20 places you could try looking, in all – so stay tuned over the next couple of weeks.

Absence of evidence is not necessarily evidence of absence…

In what is probably the first published and peer-reviewed research paper of its kind, the title of this blog is, essentially, what I and my colleagues have argued.

Digital Investigation Journal has published our research in its December 2011 edition under the title: “Historic cell site analysis – Overview of principles and survey methodologies”. In the paper, we make a number of scientifically-justified recommendations on how cell site analysis surveys should be carried out.

It is important to note, though, that there will never be a perfect survey technique; survey methods are constantly evolving as technology moves on, and our analysts are continually searching for the best way to gather the appropriate evidence. Not to mention the fact that it very much depends on the case in question and what is required from the survey.

We outlined a number of advantages and disadvantages of several cell site survey techniques and explained the problems that can be encountered when interpreting survey data. These problems can cause practitioners to draw inappropriate conclusions from their results and can end up causing arguments in court.

Location samples


A five-minute static location sample would enable cells with a timing offset of less than five minutes to be selected over others. It is also a quick and efficient method for data collection and analysis.


As with spot samples, five-minute location samples showed significant variability in results with small changes of position and between equipment, but to a slightly lesser degree. Even with large amounts of data from a single location, it is still less likely that other legitimately-serving cells will be reselected.

Again, any piece of equipment may not monitor all “valid” cell IDs as serving, and conversely many neighbour cells were detected that never provided service. It would be inappropriate to exclude a cell from serving at a given location using this method because it had not been detected in the survey.

Area surveys


These showed the least variability in results between pieces of equipment.

This method optimises the chance of cell reselection, minimising the effects of restricted BA lists and non-dominance. It is not infallible, but there is a much clearer indication of which cells genuinely provide service at and in the immediate area of a location or property.

Area surveys provide a wider picture of the general network configuration around the area of the location, enabling comment as to possible network changes if further work is required at a later date.


It takes longer to generate data and there is more data produced, making it more complicated to analyse – and this adds time (and therefore cost) to the examination.

Large quantities of measurements are not routinely obtained at a single specific location (although this can be done) for cells with a timing offset to be selected.

More possible cells will be identified (some may be false positives for that specific location, especially if they are “small” cells at the edge of the sampled area). The experiments we conducted suggest that there would be an estimated increase of around 20 per cent because of this. However, they may become relevant to an investigation later because they are detected in the local area even if not at the specific target location.

It is rare that a specific point is highlighted as being where a call was believed to have been made from.

Cell surveys

The advantage of this type of survey for a “normal” voice call or text is that the size of the area served by the cell can be demonstrated, which can be extremely useful in highlighting the limitations of the cell site evidence (if the cell provides service over a large and relevant area) or in emphasising its importance (e.g. if the service area is very small).

With hundreds of data points, absence of a specific cell from the serving and neighbour information can be a good indicator a given cell would not be expected to provide service at the location.

So what’s the best way?

There is no perfect way to conduct cell site analysis surveys, but we need to be sure we can rely on survey data to indicate whether a cell does, or – more importantly – does not, legitimately serve at a location. Different investigators will have their own way of interpreting call record data from phone companies, and we have successfully challenged some of these in court.

For example: if a suspect claims that he was in a particular area at a particular time, and was using his phone at the time, this can be verified by analysing the coverage area of the mast that he claims he was using, or visiting the location to see if it serves there.

However, by simply turning up at the scene and taking a “spot sample” as to whether the mast serves that point is not sufficient. We are aware of investigators who do this, but it is quite feasible that by carrying out a more comprehensive analysis including, for example, approaching the scene from different directions, a different picture could be revealed.

The implications of this could be far reaching in terms of the verdict delivered during a criminal court case – the difference between “guilty” and “not guilty”.

We reviewed a number of survey techniques to determine the most reliable method for collecting RF survey data for historic cell site cases. Results from experiments have demonstrated that area surveys around a location of interest provide the most consistent method for detecting serving cells at a location.

Area surveys were also more reliable for excluding cell IDs from a location, and for assessing possible network changes if further surveys take place later.

We hope that this paper will set the standard for surveys in cell site analysis, and ensure that the criminal justice system is built upon a sound base of scientific evidence. Only by keeping up with changes in technology, and reviewing what other cell site experts are doing, can practitioners ensure that they undertake the most appropriate analyses. There is enormous scope for more research, and we hope to see much more published for peer review.

Matt Tart

Cell Site Analysis Expert

Cracking Android PINs and passwords

In a previous blog post we described a method to retrieve an Android pattern lock from the raw flash of a device. However, since version 2.2 (known as “Froyo”) Android has provided the option of a more traditional numeric PIN or alphanumeric password (both are required to be 4 to 16 digits or characters in length) as an alternative security measure.

The very act of writing the last blog got us thinking whether it was possible to use a similar approach to recovering the PINs and passwords.

Our first port of call was to return to the Android source code to confirm how the data was being stored (see listing 1). Both the numeric PIN and alphanumeric passwords were found to be processed by the same methods in the same way, both arriving as a text string containing the PIN or password.

As with the pattern lock the code is sensibly not stored in the plain, instead being hashed before it is stored. The hashed data (both SHA-1 and MD5 hash this time) are stored as an ASCII string in a file named password.key which can be found in the same location on the file system as our old friend gesture.key, in the /data/system folder.

However, unlike the pattern lock, the data is salted before being stored. This makes a dictionary attack unfeasible – but if we can reliably recover the salt it would still be possible to attempt a brute force attack.

     * Generate a hash for the given password. To avoid brute force attacks, we use a salted hash.
     * Not the most secure, but it is at least a second level of protection. First level is that
     * the file is in a location only readable by the system process.
     * @param password the gesture pattern.
     * @return the hash of the pattern in a byte array.
     public byte[] passwordToHash(String password) {
        if (password == null) {
            return null;
        String algo = null;
        byte[] hashed = null;
        try {
            byte[] saltedPassword = (password + getSalt()).getBytes();
            byte[] sha1 = MessageDigest.getInstance(algo = "SHA-1").digest(saltedPassword);
            byte[] md5 = MessageDigest.getInstance(algo = "MD5").digest(saltedPassword);
            hashed = (toHex(sha1) + toHex(md5)).getBytes();
        } catch (NoSuchAlgorithmException e) {
            Log.w(TAG, "Failed to encode string because of missing algorithm: " + algo);
        return hashed;

Listing 1

Source: com/android/internal/widget/

The salt which is added to the data before hashing is a string of the hexadecimal representation of a random 64-bit integer. Necessarily, this number must then be stored, and the source code showed that the Android.Settings.Secure content provider was being used to store the value under the lockscreen.password_salt key.

On the Android file system the backing store for this content provider is found in an SQLite database settings.db in the /data/data/ directory (see fig. 1).

Fig 1: Salt as stored in the settings.db SQLite database

Once we knew how these two essential pieces of data were being stored we were able to consider how they might be recovered from a raw flash dump. In the case of the hashes, our approach was similar to the pattern lock. Knowing that:

  • The dump was broken into chunks of 2048 bytes (2032 for storing the data, the remaining 16 used for YAFFS2 file system tags)
  • The passcword.key file contains two hashes encoded as an ASCII string:  an SHA-1 hash (40 hexadecimal digits long) followed by a MD5 hash (32 hexadecimal digits long) which would make the file 72 bytes long in total starting at the top of the chunk
  • The hashes only contain the characters 0-9 and A-F
  • The remaining 1960 bytes in the data portion of the chunk will be zero bytes

Recovering the salt required a little extra thought. The salt is stored in an SQLite database which, because of the structure of SQLite data, meant that it would be all-but-impossible to predict where in the chunk the data might be stored. Worse still, we couldn’t even be sure of the length of the data as it was stored as a string. However, having a deeper understanding of the SQLite file format allowed us to derive a lightweight and reliable way to recover the salt.

Fig 2: Raw data making up the Salt field in the settings.db database

Figure 2 shows the raw data for the salt record in the settings.db. An SQLite record is made up of two parts, a record header and the record data. The record header is made up of a sequence of values; the first value gives the length of the record header in bytes (including this value), the following values (serial type codes in SQLite parlance) define the data types which follow in the record data.

In our case our serial type codes represent two data types: a null and two strings. The null is unimaginatively represented by the zero-byte highlighted by the red box (if you take a look at Figure 1 you may notice that the first field is displayed as a numeric value 34; this column is defined in the schema as the type INTEGER PRIMARY KEY which means that the value is not actually stored in the record itself, hence being replaced by null. The reasons for this are out of the scope of this blog post, but if you’re particularly interested Alex is more than happy to explain, at length, another time!).

The other two values (highlighted by yellow and green boxes respectively) define strings; in serial type codes a string is represented by a value larger than thirteen, the length of the string can be found by applying the following formula where x is the value of the serial type code:

(x – 13)/2

We can test this by considering the second field: we know that this field will always contain the string: “lockscreen.password_salt” which is 24 characters (and bytes) long. The serial type code associated with this data is the value highlighted with the yellow box: 0x3D which is 61 in decimal. Applying the formula: 61 – 13 gives us 48, divided by 2 gives us 24 which is the length of our string.

The field containing the salt is also a string, but its length can vary depending on the value held. We know from the source code that it is a 64 bit integer being stored which gives us a range of -9223372036854775808 to 9223372036854775808 which, allowing for the negative sign means that the value, stored as a string, takes between 1 and 20 characters. Reversing the formula, the second field’s serial type code must be odd and fall between 15 and 53 (0x0F and 0x35).

Using this information we can create a set of rules which should allow us to search for this record in the raw dump so that we can extract the salt:

  • Starting with the record header:
    • First field is always null (and therefore a zero byte)
    • The next field is always a string of length 24 (serial type code 0x3D)
    • The third field is always a string with length 1-20 (odd serial type codes 0x0F-0x35)
  • Moving on to the record data:
    • The first null field doesn’t feature – it’s implicit in the record header
    • The first field to actually appear will always be the string: ”lockscreen.password_salt”
    • The next field will be a string of a positive or negative integer.

This allows us to define a regular expression that should reliably capture this record:


Understanding the record structure also means that once we have captured the record we can ensure that we extract the whole salt value; we can simply read the appropriate serial type code and apply the formula to get the length of the salt’s string.

Satisfied that we could reliably extract the data we needed to recover the PINs or passcodes we crafted a couple of Python scripts – one to find and extract the data in the flash dump, and the other to brute force the hashes recovered (using the salt). On our test handset (an Xperia X10i running Android 2.3) we set a number of PINs and passcodes and found that even on a fairly modest workstation (Python’s hashing modules are gratifyingly efficient) PINs of up to 10 digits could be recovered within a few hours.

The passwords obviously have a much larger key-space so took longer, but the attack still seems feasible for shorter passwords and the script can easily be modified to only use Latin characters and digits rather than any other special characters or work from a password dictionary which could expedite the process.

Fig 3: Running the BruteForceAndroidPin script standalone

Once again we are happy to be releasing the scripts so that other practitioners can make use of this method. The scripts can be downloaded here:

Alex Caithness and Arun Prasannan of the R&D team

Forensic software tools – get ‘em while they’re hot, they’re lovely!

The R&D team at CCL-Forensics are a busy bunch. Over the past couple of years, they’ve developed a number of forensic software tools to examine the evidence that standard tools can’t reach.

Here’s a quick overview of what’s on offer. Follow the links to find out more, or give us a shout by phone (01789 261200) or email ( – we’re always happy to talk geek with like-minded practitioners.

epilog allows investigators to recover deleted data from SQLite databases, a widely-used format in many devices including mobile phones, computers and SatNavs). Many off-the-shelf tools will only allow you to view live records.

PIP is our XML and plist parsing tool. It allows investigators to present often-complex data from XML files quickly, efficiently, and in a user-friendly format. Apple’s property list files – both XML and binary formats – present no obstacle to PIP at all.

dunk! is a splendidly-named tool for digging around in cookies. Unlike standard tools, it analyses known cookie types to uncover potential new evidence and help give context to other browser artefacts. This includes showing the path the user took to arrive at a particular webpage by parsing Google Analytics cookies, revealing a wealth of information previously unavailable to practitioners.

rubus  is FREE! We like to give a little love back to the community, so with this in mind, we made our BlackBerry backup deconstruction tool available. Not having found a tool that would do the job, we made our own – enabling analysts to reverse engineer BlackBerry backup data stored in .ipd files.

The tools all went through beta-testing first, and were pronounced ready to unleash upon the world. Since then, they’ve been subject to an introductory pricing period, and have been bought and used successfully around the world.

Now that we’re confident in the tools we’ve developed, we’re also confident in their value to our customers. So with that in mind, if you haven’t bought the tools already, you may want to think about doing so! The introductory pricing period finishes at the end of March – and although they’ll still be extremely good value for money, they will be a little more expensive.

We’ve had useful feedback from our customers in the past, which has helped us to further develop our tools, and we always welcome comments and suggestions on our software. Feel free to comment below, or get in touch with us in more traditional ways!