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

Advertisements

Epilog version 1.1 to the launch pad

The long-awaited upgrade to epilog has arrived.

It is available as a free upgrade for existing epilog users and can be purchased by new users from our website.

Read on to find out what’s new – and take a look at our explanatory video on our YouTube channel…

Well, first off: epilog 1.1 includes a database rebuilder. For analysts with tools and scripts designed only to operate on live data, this will be a sanity saver. It’s an integrated solution for rebuilding recovered records into a copy of the live database, enabling deleted data to be parsed or processed.

It also allows the user to choose whether to include the current live records, options to disable triggers and remove constraints from the database schema to tailor the rebuilding.

We’ve been keeping up with new developments in the world of SQLite. Version 3.7 of the SQLite library introduced a new journal format called “Write Ahead Log” or WAL. The new version of epilog will permit WAL file parsing. It differs from the traditional journal mechanism in that it writes new data into a separate file when specifically asked to by the database engine, rather than backing up data to a rollback journal.

In epilog 1.1 the requirement for an “associated database” when conducting a raw data or disk image search has been removed, and instead the user can provide the database page seize and text encoding manually (the option to use an associated database is still available for when it’s more convenient). There are also extra options for improving results when reading from raw dumps from flash chips.

Epilog 1.1 will now mark in grey records that have been recovered but which are truncated; this allows the user to make more informed decisions about the data. We’ve also improved the signature search algorithm to remove the need for “in the case of multiple concurrent deletion” signatures.

New export modes have been added, allowing users to output to a flat tab separated values (tsv) file. The “INSERT export” has been overhauled to make it more convenient to use.

And finally, what was formerly the “Table Analysis” feature has been upgraded to “Database and Table Details” and now reports further information regarding the database structure and parameters.

The epilog team is always happy to receive comments and suggestions, so please feel free to get in touch either by leaving a comment below, or emailing epilog@ccl-forensics.com.

Epilog customers: a software tease

Here at CCL-Forensics, we like to tease our software customers from time to time with the promise of future goodies.

The R&D team has been beavering away on a number of projects recently, including making improvements and adjustments to our existing software.

Our epilog users will doubtless be excited to learn that version 1.1 is nearly ready for release. It’s being beta-tested as you read this, so it should soon be winging its way to existing users as a free upgrade, and will be available for new users to purchase.

So what’s new?

Well, first off: epilog 1.1 includes a database rebuilder. For analysts with tools and scripts designed only to operate on live data, this will be a sanity saver. It’s an integrated solution for rebuilding recovered records into a copy of the live database, enabling deleted data to be parsed or processed.

It also allows the user to choose whether to include the current live records, options to disable triggers and remove constraints from the database schema to tailor the rebuilding.

We’ve been keeping up with new developments in the world of SQLite. Version 3.7 of the SQLite library introduced a new journal format called “Write Ahead Log” or WAL. The new version of epilog will permit WAL file parsing. It differs from the traditional journal mechanism in that it writes new data into a separate file when specifically asked to by the database engine, rather than backing up data to a rollback journal.

In epilog 1.1 the requirement for an “associated database” when conducting a raw data or disk image search has been removed, and instead the user can provide the database page seize and text encoding manually (the option to use an associated database is still available for when it’s more convenient). There are also extra options for improving results when reading from raw dumps from flash chips.

Epilog 1.1 will now mark in grey records that have been recovered but which are truncated; this allows the user to make more informed decisions about the data. We’ve also improved the signature search algorithm to remove the need for “in the case of multiple concurrent deletion” signatures.

New export modes have been added, allowing users to output to a flat tab separated values (tsv) file. The “INSERT export” has been overhauled to make it more convenient to use.

And finally, what was formerly the “Table Analysis” feature has been upgraded to “Database and Table Details” and now reports further information regarding the database structure and parameters.

So, we’ve been pretty busy working on epilog and have taken on board the feedback we’ve received. We’re always happy to receive comments and suggestions, so please feel free to get in touch either by leaving a comment below, or emailing epilog@ccl-forensics.com.

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.