Simon Key

[sdckey]

Nothing To Do With Forensics - All About Losing Weight

So, if you had a hard time reading the title and are expecting this post to be about computer forensics, let me be clear: you couldn’t be more wrong. It’s all about my ongoing experiences trying to lose weight.

Basically, I had a bit of a epiphany, and I thought it might help others to share it.

I turned 50 this year, and trying to get my weight down to something verging on normal seemed to be getting harder and harder.

At the beginning of June, I hit 216.8 pounds (just under 15½ stones) and although this wasn’t the heaviest I’ve been, I decided enough was enough.

I fired-up my trusty Weight Watchers but not Weight Watchers phone app (Ultimate Food Value Diary if you’re interested), entered the numbers, and proceeded to track my points keeping them under the prescribed limit in the process.

Sure as eggs are eggs, my weight did a U-turn and started to come down, slowly but surely.

Now it’d be great if that was the end of the story, but you just know it isn’t - right?

The problem for me (and I’m guessing for a lot of other people) is not that Weight Watchers doesn’t work, it’s that sticking to it sometimes seems impossible.

This time around, I got to the point where I stalled big-time and couldn’t stop snacking. I’d encountered this problem before, but this time it was just a nightmare. No matter what I did, I couldn’t make forward progress.

After having chewed on it for a few days (pardon the pun), eventually the light dawned.

I couldn’t stop snacking because the onset of summer had brought with it hot weather and I was dehydrated. I was mistaking feelings of thirst for feelings of hunger.

So, armed with this knowledge, I went back to my diet but with a new approach and a spring in my step. 

Every time I got to the point of thinking I simply had to have something to eat, I considered where I was in the day, how long it was since I’d last eaten, and whether I might actually be thirsty rather than hungry. 

If I was at all unsure, maybe because drinking a can of Pepsi Max or some other diet drink didn’t seem to make a difference, I’d take a leak and check the colour of my urine. Invariably, if I thought I was hungry but wasn’t, it’d be a dark yellow, thus telling me I still hadn’t had enough to drink.

This approach transformed the management of my diet such that I now consider the following to hold true, for me at least -

I have, for many years, been eating at times when I should have been drinking.

If I stick to my diet then, yes, I can expect to experience slight feelings of hunger (if not, something is wrong), but anything more is probably down to being dehydrated.

Whilst I can eat pretty-much anything if I count my points, I need to be aware that certain foods, particularly those high in salt content, will make me thirsty. This in turn can trick me into thinking that I’m hungry. 

For example, I love McDonalds Sausage and Egg McMuffins, but if I have one of those in the morning instead of porridge, I struggle to keep a lid on my hunger-pangs for the rest of the day.

Eating food with a high water content, salad for instance, helps to keep me hydrated thus keeping my pseudo-hunger-pangs at bay.

I absolutely must count my points and be honest with myself whilst doing so. If I do that then I can be assured that I am getting enough to eat. If I’m still feeling starving-hungry, I need to go drink.

Not only must I count my points, I must make best use of them. Crash-dieting is counter-productive. Not only will I end-up hungry for real, I won’t keep the weight off.

Sustainable weight-loss is a gradual process and happens in steps. This is why the pukka Weight Watchers app will only let me weigh myself once a week. Going a couple of days without losing weight is to be expected. If I ignore this and keep going, my weight will come down.

Following these steps and watching the weight come-off (I was 201.8 pounds this morning and my waist has dropped two sizes) has given me a new-found confidence when it comes to losing weight. 

Thinking about it, not linking the lack of dietary success to dehydration led to frustration when my diet wasn’t going well. I’m a very logical person and now that I understand exactly what’s going-on, I’m a lot more relaxed about the whole process. If I stick to my points and keep my fluid levels up, I know that my weight will continue to drop without me suffering too much in the process.

Some of you will no doubt be saying that all this is common knowledge. If so, I wish someone had told me!

[sdckey]

Manually Decoding Mac OS X QuickLook Thumbnail Images

I was recently asked how to decode Mac OS X QuickLook thumbnail images.

It’s possible to mount these files as compound files in EnCase, but what follows shows how to decode them manually.

Thumbnails in thumbnails.data files are raw bitmaps without any header.

This information needed to locate and decode each thumbnail is stored in the associated index.sqlite file.

The following SQL query can be used to obtain the information needed to decode each thumbnail. Records are output according to thumbnail-size, largest first.

SELECT folder || file_name, width, height, bitsperpixel, bitmapdata_location, bitmapdata_length FROM files JOIN thumbnails ON files.rowid = thumbnails.file_id ORDER BY bitmapdata_length DESC

The following screenshot shows one example of a record produced by the above query –

In this example, the record contains the following information –

• Width: 512 pixels

• Height: 512 pixels

• Bits Per Pixel: 32

• Bitmap offset: 57388176

• Bitmap length: 1048576

Armed with this information we can locate the thumbnail-data and extract it using EnCase -

The easiest way to open the file is to use IrfanView’s Open As > Raw File menu-option. It’s necessary to provide the thumbnail’s dimensions and bits-per-pixel settings as obtained from the database. Colour-order is RGBA.

We can then see the thumbnail –

[sdckey]

VSS Examiner EnScript Problems in Windows 10

I’ve been testing the VSS Examiner EnScript with some new Windows 10 evidence files and noticed that it’s pulling in files from mounted shadow copies that are already in the current case. In this case my examination machine was also running Windows 10.

After doing a little investigation I found that the files were being retrieved by the script because their hash values didn’t match those contained in the case.

It transpires that the volume shadow copy links provided by Windows through the use of VSSADMIN and WMI don’t appear to be working correctly. Many of the files that are accessed through those links contain blocks that are filled with null-bytes when they should in fact contain data.

To demonstrate this, take the example of the EnScript source-code file shown in the following screenshot -

As we can see, the file is located on my C volume and has an MD-5 hash value of 162bd099bb8548be0f213bc636a562aa.

I can use VSSADMIN to obtain the path of the C volume’s last shadow copy and then use MKLINK to mount it into a folder on my D volume -

When I look at the copy of the EnScript file in this volume shadow copy the hash is different even though the file hasn’t changed, as indicated by its last-written date -

As we can see, the hash is now 6d031b35da373d98b3c0dac94248745c.

If we take a look at the EnScript source-code file in a hex-editor we can see the blocks of null-bytes that corrupt the rest of the source code -

So, sorry to be the bearer of bad news, but if you’re a user of the VSS Examiner EnScript you may need to seek an alternative method of examining Windows 10 volume shadow copy data. Unless Microsoft fix the bug of course...

[sdckey]

Recovering Deleted MS Windows EVTX Event-Logs

Back in 2012 I wrote an EnScript to recover deleted MS Windows EVTX event-logs. I’d forgotten about it till today, when it occurred to me that the script wasn’t available through EnCase App Central.

The script is fairly straightforward to run. You’ll most often use it to search unallocated clusters -

EVTX files are quite complicated, particularly as they contain data in a format called BinXml, which is a compressed, tokenized version of XML. 

EVTX log-files consist of a header plus one or more chunks. It is these chunks that contain the event-log records.

Unfortunately most of the records within a chunk are not self-contained - they incorporate parts of preceding records from the same chunk. This means that it’s not practicable to search for deleted records on an individual basis.

That said, the EVTX Log Entry Finder EnScript works by looking for deleted chunks, as can be seen when viewing the bookmarks created by the script, as shown by the following screenshot -

This screenshot shows the ‘ElfChnk’ signature at the start of a deleted chunk. Having located a chunk, the script prepends a synthezied EVTX event-log header and then hands it over to EnCase’s internal EVTX parsing engine, which will try and parse it.

If all things go well, the script will bookmark the resultant data both as an XML bookmark and in EnCase’s event-log record format. The following screenshot demonstrates how useful this can be when searching for deleted event-log records relating to the insertion and removal of external USB flash-memory disks - 

The logs shown in the above screenshot originate from the Microsoft-Windows-DriverFrameworks-UserMode%4Operational.evtx event-log file. Many of the logs contain the device path and serial number of the USB device that’s been connected.

It would be nice to export the recovered logs as a sequence of one or more EVTX log-files that Windows can parse. Unfortunately this is not a trivial thing to do because of the error protection mechanisms that are present in EVTX file/chunk headers. That said, comparing the data bookmarked by the script to that visible in the MS Windows event-viewer application will usually help the examiner to understand exactly what they’re seeing -

The script will be available on EnCase App Central soon. If you’re a registered GSI Support Portal user you can download it from the following URL -

https://support.guidancesoftware.com/forum/downloads.php?do=file&id=1245

If you’d like more information about the structure of EVTX log-files check-out Joachim Metz’s libevtx project.

[sdckey]

Windows Drive Letter Assignments

Those folks in the forensic world will know that the drive-letters associated with volumes in EnCase aren’t always the ones used on the host Windows machine.

Tristan Oliver, one of our part-time GSI instructors, pointed-out the fact that there didn’t seem to be any EnScript that could automatically ascertain the correct drive-letters for such volumes and asked if anything could be done about this.

As a result of this, I came-up with the Windows Drive Letter Assignments EnScript, which is geared-up for ascertaining the drive-letter assignments for Windows volumes (NTFS, FAT and exFAT) from fixed disks.

Take the following screenshot, for example. It shows the hard-disk from my son's Dell UEFI laptop and another hard-disk from one of our training evidence files. My son’s hard-disk has seven partitions; the disk from the training evidence file has three.

When the script processes my son’s disk, it skips two unformatted volumes shown in EnCase as ‘E and ‘I’, identifies that the volume shown by EnCase as drive ‘G’ is actually the system volume, drive ‘C’; it also identifies the volumes shown as ‘C’, ‘D’, ‘F’ and ‘H’ as boot, diagnostic and recovery partitions that don’t, according to the Windows Registry, have any drive-letter assignments.

In relation to the disk from the training evidence file, the script identifies that whilst the system volume is indeed volume ‘C’, the other two volumes are actually ‘E’ and ‘F’, not ‘D’ and ‘E’.

Hopefully this will make it a little easier to allocate the correct drive-letter assignments in EnCase before proceeding with your examination!

You can download the script from here. Please be sure to read the inbuilt help-text so you know exactly how the script works and are aware of its limitations.

[sdckey]

Hash List Importer V2

This script can be downloaded by clicking here.

The previous version of the script was designed to import the hash-values from a set of target files; it wasn’t really meant to handle large hash-sets such as those provided by the nice people at the NSRL.

The new version of the script now supports this; it also supports import of the hashes contained in the NSRLFile.txt file (the key component of the NSRL hash-sets) directly.

I’ve tested it with the NSRLFile.txt from the minimal NSRL hash-set. That particular file is just under 5GB in size (uncompressed) and contains a little over 41,387,000 hashes. It took approximately two hours and ten minutes to import the contents of the file into a new EnCase V7 hash-library.

[sdckey]

Mac OS X Time Machine Parser V1.0

The Mac OS X Time Machine Parser EnScript mentioned in a previous tweet is now available for download from the GSI Support Portal; it will also be available on EnCase App Central in due course.

I gave a demonstration of the script during my Mac session at this year’s CEIC conference. As a reminder, the script allows the examiner to write blue-checked files from a Mac OS X Time Machine volume into a logical evidence file (LEF) re-creating the correct backup-paths in the process. Ascertaining this information would otherwise be quite difficult due to the convoluted manner in which Time Machine uses HFS+ hard-linked files and folders so as to avoid backing-up data that exists in a previous backup set,

The internal hashing mechanism used by the LEF ensures that only one instance of a file will be stored even if multiple backups of it exist within the Time Machine volume.

Please note that the script does not currently support Time Machine volumes in the form of sparse-bundle (folder) disk-images mounted using EnCase's View File Structure option. These are used by Apple’s Time Capsule device.

Work is ongoing in this area, but until that is completed, it will be necessary to drag and drop such images into EnCase in order to treat them as a type of evidence file. Making these images available using EnCase's Virtual File System (VFS) feature should avoid having to extract from the source disk-image.

[sdckey]

EMLX to EML Mail Converter V4.1

V4.0 of this EnScript was failing when encountering *.emlxpart files without an associated *.partial.emlx file. It’s not clear why these files exist, but V4.1 of the script skips them in any case.

The script can be downloaded from the Guidance Software Inc. Support Portal and will available on EnCase App Central soon.

[sdckey]

NTFS $UsnJrnl Parser V4.1

I’ve just uploaded V4.1 of the  NTFS $UsnJrnl Parser EnScript to the Downloads section of the Guidance Software Inc. Support Portal.

I updated the script so as to allow the examiner to control the way in which one or more entries in the Reason(s) column of the output spreadsheet are delimited. The script previously used newline (CRLF) characters but these required the use of double-quote string delimiters, which aren’t supported by applications such SQLite Expert Professional (they are supported by MS Excel and MS Access).

I also updated the script so as to apply TZ and DST offsets to record time-stamps.

The script will be available on EnCase App Central shortly.