Secrets and Evidence of Older Mobiles

It is good to learn that the Nokia 3310 may make a return, albeit with an Android operating system. The nostalgia for these types of mobile phones has clearly not been lost. What it might suggest is that consumers still want a mobile telephone to remain a mobile telephone and to look like one.

The older mobile phones I have in mind though are the ones that are still used in examinations, investigations and research. Since there is nostalgic sentiment in the air I thought you might be interested in some examples of older mobile phones from my lab toolkit.

Now these old buzzards are used for basic GSM telephony services. There isn't a universal SIM that will work with these as some from my collection operate with a 5-volt SIM and so on. Importantly they are used due to the fact they have an external antenna and extendable external antenna. In some investigation instances RSSI will show network detection and a small amount of RF power whereas mobiles/smartphones with embedded antennas show Emergency Calls Only.

You might recall I have written numerous articles on radio surveys and two that may seem appropriate to this discussion are:

CSA: Mobile Phones and Fringe Coverage
http://trewmte.blogspot.co.uk/2010/06/csa-mobile-phones-and-fringe-coverage.html

GSM Radio Test Measurements
http://trewmte.blogspot.co.uk/2010/06/gsm-radio-test-measurements.html

The next selection of mobiles/smartphones each provide different radio characteristics due to the manufacturer's selection of RF chipset and functionality.

My five beauties, as I call them, are my Nokia 3210s. Great phones and they still operate perfectly well today. You can also see in the photo that all bar one mobile have embedded antenna. Some are mobile phones and some are smartphones. Combined they offer the ability for RF surveys and testing voice telephony, data downloads, instant messaging etc. The common laptop application Network Monitor (NMonitor/NetMonitor) still provides good feedback when connected to the Nokia 3210 (nmon activated). Blackberry requires a bit of setting up with applications such as MagicBerry, BBHTool, etc., and creating JAD-files (depending on what you want to achieve). Now with the Samsung models GT-I8160 and GT-I9100 both are used with 2G and 3G networks and illustrates the point that two models of smartphone from the same manufacturer display didn't RF survey details.

Now I wont bore you with an explanation of the details just to say these investigation RF surveys require knowing the various ServiceMode states. In particular, if you are conducting a PRACH and RACH survey, relevant to investigations for Access Requests (e.g. the phone is not in idle mode but seeking a service), then the GT-I9100 is useful in that it displays not just the LAC but also the Cell ID the RACH (access) request was made. Quite a few mobiles do not do this when looking into the ServiceMode states. You have to be quick, mind you, as the ServiceMode screen changes fairly quickly if you are not ready to take a photo.

Yet another, quite old-ish, mobile phone that I haven't shown so far is the Nokia 6303. The photo shown below should explain everything. But for those not familiar to testing and examination; where a charge in the billing appears for an SMS or at least details of a called number sent an SMS (even if sent message is free) it is quite possible the party receiving the message can read it but the message wont be saved. This is known as a Class 0 message (commonly referred to as a Flash Message). Depending on make and model of mobile phone, part or all of the message which is only held in RAM might still be recoverable, provided seizure and examination is undertaken and completed fairly quickly, as RAM is updating perpetually. 

The Nokia 6303 is one of those mobiles that the handset manufacturer in combination with mobile network operator enabled this feature as they foresaw revenue generation from it and also recognised that a reasonable memory storage capacity in handset and SIM card need not be blocked up with trivial messages.

The 6303 came with a 940 MB memory card for downloaded applications etc. This proved to be useful in an investigation where text messages didn't have alphabet characters but a series of dots and dashes. At first it was thought this was incomplete text chat messages or some sort of smiley face that didn't form properly when typed on the screen.

When reviewing hundreds of text messages recovered from a mobile or smart phone it is quite easy to overlook or ignore a message as being meaningless. However, I researched the matter and following testing the message turned out to be Morse Code. I tracked down the application for this and cross-checked with the device that had been examined.

            

So next time you see a text message with an odd presentation look closely to see if it has relevance and whether your mobile phone forensic suite software has the capability to either identify the message contains additional features or can translate the message.

Hope you have enjoyed this brief look at older mobile phones used in and for mobile forensic examination, investigations and research.

HERREVAD Databases Geo Location Artefacts

From a recent discussion regarding HERREVAD Databases it has emerged that they are in fact undocumented Android features for google mobile services (GMS). Any extracted and harvested data from these databases is on the basis "as is" recovered. Oxygen Forensic Detective 911 WiFiHistory.png presents a helpful and useful example of recovered data from HERREVAD:

Image courtesy of http://www.oxygen-forensic.com/images/whatsnew/911/WiFiHistory.png

From research conducted the results identified little has been written about HERREVAD (GMS). It may be there is more information out there, possibly in a internet walled garden, but not very much is revealed using the well-known internet search engines. From what has been discovered it is recorded below so should more information come to light this discussion can be updated.

As can be seen in the above screen image it shows records of WiFi History of connections to WiFi network servers. In this regard, as has been previous stated in another discussion at this blog, WiFi location analysis should naturally form part of cell site analysis as smartphones have multiple radio in them (http://trewmte.blogspot.co.uk/2014/08/csa-site-survey-method4cell-types.html).

Three databases have been identified so far, but no information was found that actually described what each database actually recorded, so assumptions are based upon the title of the databases and data recovered:

'/data/data/com.google.android.gms/shared_prefs/herrevad.xml'
'/data/data/com.google.android.gms/databases/herrevad'
'/data/data/com.google.android.gms/databases/herrevad-journal'

Moreover, no guidance was found to define whether each of databases are providing data-support to one another. It is an assumption that the information stored in each combines together to provide an abstract of connection events. It could be said this is evidence of the 'fact' the data are recorded there. It means the recording was made due to a smartphone's sensor activity showing the device had detected and decoded the WLAN networks, including SSID and BSSID (MAC address) info, as well as timestamps; thus there is proximity to a source. So here is potential evidence, but that doesn't necessarily confirm what is happening during the connection.

In the above image WiFiHistory.png it displays a number of connections consistent with the same network (so to speak) and on various dates and times. It is possible to draw an inference from that of a device in regular proximity to a particular WiFi network, thus a 'distance' (in space and time) to a location. This would support the merits of investigating those identities.

the only independent document found at this time discussing HERREVAD is that from Connie Bell, in her partial MSc thesis:

'PROVIDING CONTEXT TO THE CLUES: RECOVERY AND RELIABILITY OF LOCATION DATA FROM ANDROID DEVICES'
http://etd.fcla.edu/CF/CFE0005924/Bell-Connie-ThesisFinalDraft.pdf

In this thesis Connie states:

"However, during a review of the databases’ contents, it became clear that the database did not capture all of the instances in which the  devices were connected to WLAN networks, based on test session activity."

"From these examinations, it seems clear that connectivity-related log artifacts may be quite useful in ruling out the possibility that the  WLAN sensor was disabled at a particular time. However, it may be more difficult to affirm that the sensor was indeed enabled at a particular  time, since these logs seem to only document when the device is actually connected to a network."

"A device may have the WLAN functionality enabled but be out of range or not connected due to wireless network security, for example. In  situations like these, it seems the log files would not indicate that the device WLAN feature was active, since the device would then default  to cellular data services"

The research took into account Connie's observations regarding lost WiFi updates to the databases. Two useful web resource site to search are github and pastebin; both commonly have various types of processing dumps which field useful clues for investigation.

The following is part of a logcat dump. This logged failed event (colour red) could be due to the device's sensor proximity to/from a network or surrounding noise meant insufficient data was available to complete sending a HERREVAD record entry update or that the third party plugin failed for some other reason:

(com.estrongs.android.pop) from content://downloads/my_downloads/6 format 2
98.12-26 19:31:01.741   536   536 I installd: free_cache(6186696) avail 33903247360
99.12-26 19:31:01.764  4260  4260 V Herrevad: NQAS connected
100.12-26 19:31:01.776  1016  2567 D WifiService: New client listening to asynchronous messages
101.12-26 19:31:01.796  4678  4678 I ConfigService: onCreate
102.12-26 19:31:01.927  4260  7615 I ReportNQOperation: [202] g.a: Not enough data to save wifi report to local db:  com.google.android.gms.herrevad.g.s@nnnnnn

This .pdf https://www.dropbox.com/s/ds89ulvcgezcgsy/Pandora%20Herrevad.pdf shows a complete logcat dump from a post on pastebin. Another example can be found here at github https://gist.github.com/mujeebulhasan/b5e910fc23ec5a41c924e7b5971f1e31

It was noted during research that a number of logcat dumps were for third party apps making use of HERREVAD Databases, so any further research may wish to include:

- Gaming
- Apps download
- Weather
- Travel
- Leisure (running etc)
- Photos
and so on

Some search terms you may wish to consider when analysing images from smartphones or logcat dumps:

Connie Bell thesis suggests:

select local_reports.network_type, local_reports.ssid,
local_reports.security_type, local_reports.bssid,
local_reports.timestamp_millis,
datetime((local_reports.timestamp_millis)/1000,'unixepoch')
as "Converted timestamp (UTC)"
from local_reports
order by local_reports.timestamp_millis asc

Additionally, from the research here it is suggested the following maybe helpful, too:

HERREVAD
BSSID
SSID
UEID
date
time
timestamp
locationid
location
LocationFilter
WiFiInfo
WiFi
MAC
RSSI
download or downloaded
com.google.android.gms.persistent
com.google.android.gms.herrevad.services.LightweightNetworkQualityAndroidService
com.google.android.gms.herrevad.h.g.a
com.google.android.gms.herrevad.h.l.f

For time-stamps they may require conversion so here are a couple of sites that might assist you:
http://www.epochconverter.com/
http://www.unixtimestamp.com/

Further research will continue and efforts will be made to update this thread. If any reader can provide any additional information, please send an email to trewmte@gmail.com and please provide your details and confirm if you wish to have these included in any update.