Navman iCN320 Sat Nav device

I have previously written elsewhere a guide to investigating TomToms and of course there is TomTology and the paper by Beverley Nutter of the MPS out there as well.

Today I had a Navman iCN320 sat nav come my way.

After a brief look it seems that the crucial three files are within the SYSTEM directory:

• RECENT.DAT
• FAVVER4.DAT
  
• ROUTE.DAT

They are stored on a 256mb MMC card formatted FAT16.

RECENT.DAT stores up to thirty of the recently navigated to destinations. These destinations are stored in records of 520 bytes in length. Each destination has its Lat/Long coordinates stored in 8 bytes starting at Record Offset 507. These are decoded by bookmarking in Encase as a 32 bit integer. In the UK Latitude will begin in the range 49-59 and is decimally notated. Longitude is in the range -5 to +1.6 ish. When bookmarking as a 32 bit integer Longitude is shown first and will often be a negative value (i.e. anywhere west of Greenwich).

FAVVER4.DAT possibly stores up to 200 user entered favourite destinations. These favourite destinations are stored in records of 1508 bytes in length. Each destination has its Lat/Long coordinates stored in 8 bytes starting at Record Offset 352. These are also decoded by bookmarking in Encase as a 32 bit integer.

ROUTE.DAT I speculate is used to store the origin of the last navigated journey. Coordinates can be found at record offset 507.

GREP search expression for Encase ......[\x4f-\x55]\x00

Looks like a bit of testing is in order!

The net widens!

Saw this on the BBC news today. The gist of the article is possession of drawings and computer-generated images of child sex abuse would be made illegal in the UK.

Although I agree with the sentiment has anyone given any thought to the practicalities? I can see another category being specified within SGC Guidelines with no thought being given to our tools of the trade (C4P etc.)

How do you tell if an account password is set in Mac OSX ?

A colleague asked me "How do you tell if an account password is set in Mac OSX ?". A bit like buses two mac problems have turned up at once.

A simple question? - well after looking at this for a while I thought -give me one on sport!

When you google this problem you find tons of stuff on cracking/ hacking/ replacing/ passwords and a few relevant sites that I will reference at the end of this post.

I am going to focus on Mac OSX 10.4 and 10.5. Password hashes for each user are contained in files at the path private\var\db\shadow\hash. The file names comprise of the generated user Id for each user and these can be reconciled (on Tiger boxes) to the user name by looking at the store.xxxx files in var\db\netinfo\local.nidb.

When you look at the hash files in the text pane within Encase it will look something like

NTLMNTLMNTLMNTLMNTLMNTLMNTLMNTLMNTLMNTLMNTLMNTLMNTLMNTLMNTLMNTLM000000000000
000000000000000000000000000000000000SHA1SHA1SHA1SHA1SHA1SHA1SHA1SHA1SHA1SHA1
0000000000000000SaSHA1SaSHA1SaSHA1SaSHA1SaSHA1SaSHA1SaSHA1SaSHA1000000000000
0000000000000000000000000000000000000000000000000000000000000000000000000000
0000000000000000000000000000000000000000000000000000000000000000000000000000
0000000000000000000000000000000000000000000000000000000000000000000000000000
0000000000000000000000000000000000000000000000000000000000000000000000000000
0000000000000000000000000000000000000000000000000000000000000000000000000000
0000000000000000000000000000000000000000000000000000000000000000000000000000
0000000000000000000000000000000000000000000000000000000000000000000000000000
0000000000000000000000000000000000000000000000000000000000000000000000000000
0000000000000000000000000000000000000000000000000000000000000000000000000000
0000000000000000000000000000000000000000000000000000000000000000000000000000
0000000000000000000000000000000000000000000000000000000000000000000000000000
0000000000000000000000000000000000000000000000000000000000000000000000000000
0000000000000000000000000000000000000000000000000000000000000000000000000000
000000000000000000000000

NTLM represents a 64 character NTLM hash.
SHA1 represents a 40 character SHA1 Panther compatibility hash.
SaSHA1 represents a 48 character salted SHA1 hash used by Tiger and Leopard.

The NTLM hash comprises a 32 character NT hash and a 32 character LM hash and will only exist if Windows File Sharing is enabled for this user (or in Tiger boxes has been in the past). I have seen only a 32 character NT hash on Leopard boxes (i.e. the first 32 characters). The SHA1 hash will only exist if the box has been upgraded from Panther and may also be salted with four zeroes preceding the 40 characters. The SaSHA1 hash comprising of 48 characters will exist in all cases from FO169.

If an account is enabled for Windows File Sharing it is easy to establish whether a password is set. This is because the NTLM hash for a blank password is known and is in all cases:

31D6CFE0D16AE931B73C59D7E0C089C0AAD3B435B51404EEAAD3B435B51404EE

therefore any other NTLM hash must represent a password of some kind. In Leopard it appears that only an NT password hash is stored and therefore only the first 32 characters of the blank password hash will be stored.

I have created a few test accounts and the hash files are as follows:

1) apple pw test\0\1 Customer\Macintosh_HD\private\var\db\shadow\hash\49BE7F58-7656-4FF3-A77B-21CC32E774CB

This is a hash file from a Leopard box - note the 32 character NT hash which represents a blank password.

31D6CFE0D16AE931B73C59D7E0C089C0000000000000000000000000000000000000000000000000
00000000000000000000000000000000000000000000000000000000000000000000000000000000
000000003894ED462BFB59E9E750F719DD326D62685D51BE63F0823E000000000000000000000000
00000000000000000000000000000000000000000000000000000000000000000000000000000000
00000000000000000000000000000000000000000000000000000000000000000000000000000000
00000000000000000000000000000000000000000000000000000000000000000000000000000000
00000000000000000000000000000000000000000000000000000000000000000000000000000000
00000000000000000000000000000000000000000000000000000000000000000000000000000000
00000000000000000000000000000000000000000000000000000000000000000000000000000000
00000000000000000000000000000000000000000000000000000000000000000000000000000000
00000000000000000000000000000000000000000000000000000000000000000000000000000000
00000000000000000000000000000000000000000000000000000000000000000000000000000000
00000000000000000000000000000000000000000000000000000000000000000000000000000000
00000000000000000000000000000000000000000000000000000000000000000000000000000000
00000000000000000000000000000000000000000000000000000000000000000000000000000000
0000000000000000000000000000000000000000

2) apple pw test\1\1 Apple_HFS_Untitled_1\Bootable Backup\private\var\db\shadow\hash\322CD0AA-AE6D-4100-A94C-E27A7D64EA5B

This is a hash file from a Tiger box - note the 64 character NTLM hash which represents a blank password.

31D6CFE0D16AE931B73C59D7E0C089C0AAD3B435B51404EEAAD3B435B51404EE0000000000000000
00000000000000000000000000000000000000000000000000000000000000000000000000000000
00000000AE9FF34A30316C6A3ED60E16E01DACE0CB2EC125F4535523000000000000000000000000
00000000000000000000000000000000000000000000000000000000000000000000000000000000
00000000000000000000000000000000000000000000000000000000000000000000000000000000
00000000000000000000000000000000000000000000000000000000000000000000000000000000
00000000000000000000000000000000000000000000000000000000000000000000000000000000
00000000000000000000000000000000000000000000000000000000000000000000000000000000
00000000000000000000000000000000000000000000000000000000000000000000000000000000
00000000000000000000000000000000000000000000000000000000000000000000000000000000
00000000000000000000000000000000000000000000000000000000000000000000000000000000
00000000000000000000000000000000000000000000000000000000000000000000000000000000
00000000000000000000000000000000000000000000000000000000000000000000000000000000
00000000000000000000000000000000000000000000000000000000000000000000000000000000
00000000000000000000000000000000000000000000000000000000000000000000000000000000
0000000000000000000000000000000000000000

3) apple pw test\1\1 Apple_HFS_Untitled_1\Bootable Backup\private\var\db\shadow\hash\F796D172-5974-4BD6-AF20-A389C45137AC

This is also hash file from a Tiger box for another account- note the 64 character NTLM hash which represents a blank password and also that the salted SHA1 hash is different to the previous entry.

31D6CFE0D16AE931B73C59D7E0C089C0AAD3B435B51404EEAAD3B435B51404EE0000000000000000
00000000000000000000000000000000000000000000000000000000000000000000000000000000
0000000030A5A46EEC7D0CA83AB340F593DC98B9DC9C3A7984807428000000000000000000000000
00000000000000000000000000000000000000000000000000000000000000000000000000000000
00000000000000000000000000000000000000000000000000000000000000000000000000000000
00000000000000000000000000000000000000000000000000000000000000000000000000000000
00000000000000000000000000000000000000000000000000000000000000000000000000000000
00000000000000000000000000000000000000000000000000000000000000000000000000000000
00000000000000000000000000000000000000000000000000000000000000000000000000000000
00000000000000000000000000000000000000000000000000000000000000000000000000000000
00000000000000000000000000000000000000000000000000000000000000000000000000000000
00000000000000000000000000000000000000000000000000000000000000000000000000000000
00000000000000000000000000000000000000000000000000000000000000000000000000000000
00000000000000000000000000000000000000000000000000000000000000000000000000000000
00000000000000000000000000000000000000000000000000000000000000000000000000000000
0000000000000000000000000000000000000000

The last two files illuminate the problem - because of the salt in the absence of a NTLM hash how do you determine if a null/blank password has been set. I understand that the salt that prefixes the hashed password in tiger/leopard has 2^32 potential values which is a big number. I have tried to use a password cracking program MacKrack but it does not seem to like blank passwords however the pre-patched version of John The Ripper which includes support for OSX salted SHA1 hashes does cope with them.

To use JTR download a pre-compiled version from here and unzip. Then create a text file containing an entry in the form user:saltedSHA1hash (i.e. for the hash in the example above user:30A5A46EEC7D0CA83AB340F593DC98B9DC9C3A7984807428). Next launch Terminal and drag into it the file John from the unzipped JTR download and then drag in your text file and press return.

Last login: Mon May 26 00:03:32 on console
test-machine-imac:~ test$ /Users/test/Downloads/john-1.7.2-macosx-universal/run/john /Users/test/Desktop/jtr.txt
Loaded 1 password hash (Salt SHA1 [salt-sha1])
           (test)
guesses: 1  time: 0:00:00:00 100% (2)  c/s: 12950  trying:
test-machine-imac:~ test$

The process is complete once you see the command prompt. The output of the password is in the form
Password (user name)
In this example the user name I used was test and because the password is blank nothing precedes (test).
The result will also be recorded in John.pot. If the password is not blank JTR will keep trying to guess what the password is -blank passwords will be identified almost instantly. The example I have shown above utilises a Mac OSX version of JTR - there is also a Windows version which is equally as good and runs from the command line - just a pity you can't drag files to the windows command prompt.

Another issue to consider if the ability to configure a Mac to login automatically to a nominated account without inputting a password. Luckily the com.apple.loginwindow.plist clearly indicates whether the autologin facility has been used and additionally the log at private\var\log\secure.log also contains reference to this facility when it has been used.

References
http://www.dribin.org/dave/blog/archives/2006/04/07/os_x_passwords/
http://www.machacking.net/kb/files/crackingosxhashes.txt
http://www.macshadows.com/forums/index.php?s=&showtopic=8516&view=findpost&p=62916
http://www.macos.utah.edu/documentation/system_deployment/radmind/faqs/manage_local_users.html
http://www.macshadows.com/kb/index.php?title=Mac_OS_X_password_hashes#Mac_OS_10.4_.27Tiger.27
http://freaky.staticusers.net/ugboard/viewtopic.php?t=17175

wtmp

A while back over at forensic wiki I posted a few Mac OSX artefacts which may be evidentially useful.  

The wtmp file was one of them.  This file contains login and shutdown information for Mac OSX 10.4 and earlier, sadly I found out today that wtmp is now deprecated in Leopard and has been super-ceded with asl.db.

To view wtmp you could copy the suspect file to your mac and within terminal use the command Last -f and pipe out the parsed file to a text file in the form:

testac_ console macintoshtestcom Tue Feb 19 21:37 still logged in
reboot ~ Tue Feb 19 21:36
shutdown ~ Tue Feb 19 15:51
testac_ console macintoshtestcom Tue Feb 19 15:26 - 15:51 (00:24)
reboot ~ Tue Feb 19 15:26
shutdown ~ Tue Feb 19 10:37
testac_ console macintoshtestcom Tue Feb 19 10:28 - 10:37 (00:09)
reboot ~ Tue Feb 19 10:26
shutdown ~ Tue Feb 19 00:52
testac_ console macintoshtestcom Mon Feb 18 18:44 - 00:52 (06:07)
reboot ~ Mon Feb 18 18:42
shutdown ~ Mon Feb 18 18:39
testac_ console macintoshtestcom Sun Feb 17 17:55 - 18:39 (1+00:44)
reboot ~ Sun Feb 17 17:51
shutdown ~ Sun Feb 17 17:47
testac_ console macintoshtestcom Mon Feb 11 11:21 - 17:47 (6+06:25)
reboot ~ Mon Feb 11 11:21
shutdown ~ Mon Feb 11 03:31
testac_ console macintoshtestcom Sun Feb 10 14:28 - 03:31 (13:03)
reboot ~ Sun Feb 10 14:27
shutdown ~ Fri Feb 8 15:35
testac_ console macintoshtestcom Fri Feb 8 14:24 - 15:35 (01:10)
reboot ~ Fri Feb 8 14:24
shutdown ~ Fri Feb 8 14:21
 

and so on....

This works fine using Terminal in Tiger but for some reason using the Last command in Leopard does not work.  

I have asked about this elsewhere and someone suggested the wtmp parser within the Encase Case Processor.  The results I got were unintelligible.   

Whilst revisiting this subject I discovered that older  wtmp files are archived into gzip files which may become useful to someone!

Tableau writeblockers and sata laptop hard drives

We use a variety of Tableau writeblockers and found that the T35i was regularly not recognising newish sata laptop hard drives.

It seems Tableau have encountered this and released a firmware update (v5.20) back in February 2008.

Bearflix

Bearflix is a peer to peer file sharing program from the Bearshare stable working on the Gnuttela network. I have examined Limewire in detail in the past and posted a lot of stuff at Forensicwiki.com.

A recent box I looked at had Bearflix installed and I found that it saves what amounts to the holy grail in these type of investigations - the user inputted search terms. The program has in built banner advertising and I found that these banner adverts cause entries to be made within Internet Explorers History index.dats. The URLs contain the search terms (presumably so that the adverts can be tailored to the search term). How cool is that! I have documented this in a couple of slides following

Google Searches

Google search terms can be great evidence and I doubt that many machines exist where they can't be found. NetAnalysis identifies them within URLs and cached webpages may hold some results pages.

On a Vista box I am looking at there is a helpfully named folder entitled Local Search History at the path

C\Users\{account name}\AppData\Roaming\Google\Local Search History

The equivalent location on XP is C:|Documents and Settings\{account name}\Application Data\Google\Local Search History.

Within this folder are five files on the box I am looking at

1. google%2Emaps.w
2. google%2Eweb.w
3. google%2Egroups.w
4. google%2Eimages.w
5. google%2Enews.w

Each one contains search terms in unicode. I have tested and found as it appears the type of google search is contained in the filename (e.g. google map searches are in google%2Emaps.w and so on).

Notably testing using IE7 with a separate Google Toolbar installed running in Vista revealed that searches made using

1. Instant search box (set to Google)
2. Google Toolbar
3. Google webpage

all populated google%2Eweb.w .

I have found traces of these files in unallocated clusters also.

The google toolbar has a Clear History option and as far as I can tell this modifies the MFT for the file resulting in Encase reporting an Empty File. In testing I carried out searches that caused google%2Eweb.w to extend over three clusters as follows

I cleared search history and via disk view in Encase viewed each cluster. In cluster 1447520 I found remnants of google%2Eweb.w but after a few minutes this cluster was zeroed out (during this test I had pointed Encase at my local drive). So at this point I am not sure why I have found traces in unallocated.

ReadMessageLight.htm presentation

Having looked at the ReadMessageLight problem further I have prepared the following presentation (which allows larger, more readable screenshots)

ReadMessageLight[1].htm

Stumbled across a lot of these webpages recently within Temporary Internet Files. After a bit of testing it seems they originate from Windows Live Hotmail when the client is the Classic Version (as opposed to the full version). They appear to be read hotmail email messages and may be only partially viewable within the documents view within Encase. Browsers may struggle to display any (or all) of the contents also due to the embedded scripting. In my test email the main message body was not displayed although most other elements of the email were. I have found some pages that have this problem and some that don't. I think newer versions of Windows Live Hotmail are susceptable.

It seems ajax and some javascript is responsible and stems from Hotmail converting HTML markup into ASCII (more here) The coding contains a function getElementById and the body of the message is contained within an innerHTML property. I am actively looking for workarounds - suggestions welcome.

PLEASE SEE NEWER POST ABOVE

suggestqueries.google.com and search.xml

I have mounted a drive with Encase PDE and run Histex 2.11.0002 against it -loaded the resulting index.dats into NetAnalysis and have 577004 URL records to review - joy! So I start by applying the Advanced Search Engine Criteria filter and I only have 27000 of those including lots of URLs like:

http://suggestqueries.google.com/complete/search?=foren&output=toolbar&client=toolbar&hl=en

and

http://suggestqueries.google.com/complete/search?q=forens&output=toolbar&client=toolbar&hl=en

and so on..

The URL file name for each was in the form search[1].xml search[2].xml etc.etc.  I had not seen this before so a quick play with google revealed that this domain had been around in 2006... must be the length of the queue!

So what is it all about then?  Well in this case it seems to be down to the google toolbar and the auto suggestions feature that changes as you type into the toolbar search box.

The drop down suggestion box contains the content of the associated xml file

A new  search.xml file is created each time the auto suggestion list changes which appears to happen when an additional character is typed into the toolbar field.   The contents of these search.xml files themselves are not necessarily good evidence but the URL that led to their creation is.

Ramblings from the sausage factory

I work at the coal face of a UK computer forensics lab.

We carry out production line forensics  - day in day out - welcome to the sausage factory.