Was the file viewed?

Without knowing the associated application, it's hard to make any conclusions. The prosecution can speculate but any conclusions would be unwarranted. Was the file recovered from slack space or was it recovered using the data from its MFT entry? Does the prosecution not know the original file name or did they just not include it in the report? The file name tells you which app the jump list is associated with. The extension will tell you if it's an automatic or custom jump list.

The application and type of jump list (automatic vs custom) matters. A jump list entry for Windows Media Player likely indicates that the file was viewed whereas an entry for Firefox could merely indicate that it was downloaded using the browser. An custom jump list entry indicates that the user pinned the item. If the video file name is not descriptive (e.g. "1.wmv"), then your theory about it referring to another file is possible. If the name is less generic (e.g. "nasty_contraband.avi" then you're probably stretching).

Sam,

The prosecution allege that they can say with some certainty that a file (video) has been viewed because a "deleted" jumplist record has been recovered. From what I can tell, this is a partial recovery so that filename is present, but they have not listed any times or applications attached. At this stage, I am assuming this information is missing.

There are a couple of things at play here…

First, this is likely a Windows 7 system or above…that may be important later.

Second, both automaticDestinations and customDestinations jump lists have a defined structure. The automatic jump lists are an OLE format file, and each of the individual streams (with the exception of the DestList stream) is an LNK file format stream.

The custom jump list is a series of LNK files concatenated together.

The fact that the jump list item is "partial" and "deleted" is significant, and if I were in your shoes, I'd be wanting to look at the binary data "near" the item that was identified. I'd want to know if the item found was an ASCII string, or if it was Unicode. It isn't likely that the prosecution is looking at a shell item ID list, which is the other significant portion of an LNK file.

My role of course is to suggest that the file may well never have been viewed. On that basis, I have developed the following theories

1) Established that there is a real chance that another file with the same name could have caused the jumplist record to be in existence.

This depends on the name of the file, the "deleted partial jump list" item, etc.

2) The file itself may have been "auto opened", or in fact the jumplist record may have been created on creation, in absense of a specific user action. Without "modified" times to the jumplist record, this cannot be ruled out.

Perhaps, but it would also be much less likely. In sure attorneys say a lot during a trial, but if I were on the jury and an attorney said that a jump list item could have been created with NO interaction from the user, I would assign much less weight to that statement; in fact, I would begin to question everything else that attorney said, and try to pick it apart.

This is actually pretty easy to test. Copy a video file onto a system in a similar location as to the one found, and then go about your business, never actually accessing the file. Let the system run for a considerable amount of time…a day, perhaps. Then check the system to see if the file was added to any jump lists.

3) The file itself could have been deleted and then undeleted. This would again create such a record. The only distinguising feature would be the application id, which we do not have at this stage.

I don't know that deleting then undeleting the file would have created the entry in question. While some user action is required for a jump list item to be created, I don't know of any application ID for a jump list that would indicate that the sole action from the user was to delete and then undelete the file.

Anything is *possible*, but as with #2, this theory is pretty unlikely.

4) The video in question could have been opened, or attempted to have been opened with an application that has no ability to display such a file type. Again, the result is similar to point 3.

That's possible, albeit easy to check. With the file extension, it is trivial to determine with application would have opened the file by default, had the user simple double-clicked on it.

Something else to keep in mind…the Windows Registry holds a great deal of information regarding files viewed by the user. So…do the shellbags show any indication of the folder path to the file being accessed by the user (this may be unique, or it may be something regularly accessible by the user, such as the desktop)? Are there any indications of the file listed anywhere in the Registry? You should search by name, not including the path. Also, check for deleted entries in the Registry…again, this is trivial.

5) The video could have been a part of a playlist, therefore causing a jumplist record, again, without ever being viewed.

This really depends on the data being looked at.

From the above information, I would suggest fairly confidently that the mere existence of a partial jumplist record could in no way be used as evidence that the file had been viewed by the user.

I would've said that from the very beginning, and not had to go through various theories. 😉

There's not telling what the other side believes is a "partial" jump list, particularly one that's been deleted. I'd look very closely at the data itself, and the first thing I'd try to determine is, what do they call a "deleted partial jump list". Knowing the structure (which is well documented at the MS site, as well as other locations) of both jump lists and shortcuts, you should be able to determine this, and get additional information (time stamps, etc.). As was mentioned, you won't get the appID for the jump list, so significant context will be missing.

Speaking of context, how many other user accounts are on the system? A deleted entry won't have the appropriate context to tie it to a specific user. Without knowing more about what information is actually available, the other side may have the full path to the file, which includes the file path…but not knowing that, I thought I'd offer that up.

Something else I would look for is the breadth of activity for the user. Does all of activity seem to go back to a certain point in time and just stop? This might be indicative of a wiping utility.

Finally, does the system have Volume Shadow Copies available? If so, check those.

Sam,

The prosecution allege that they can say with some certainty that a file (video) has been viewed because a "deleted" jumplist record has been recovered. From what I can tell, this is a partial recovery so that filename is present, but they have not listed any times or applications attached. At this stage, I am assuming this information is missing.

There are a couple of things at play here…

First, this is likely a Windows 7 system or above…that may be important later.

Second, both automaticDestinations and customDestinations jump lists have a defined structure. The automatic jump lists are an OLE format file, and each of the individual streams (with the exception of the DestList stream) is an LNK file format stream.

The custom jump list is a series of LNK files concatenated together.

The fact that the jump list item is "partial" and "deleted" is significant, and if I were in your shoes, I'd be wanting to look at the binary data "near" the item that was identified. I'd want to know if the item found was an ASCII string, or if it was Unicode. It isn't likely that the prosecution is looking at a shell item ID list, which is the other significant portion of an LNK file.

My role of course is to suggest that the file may well never have been viewed. On that basis, I have developed the following theories

1) Established that there is a real chance that another file with the same name could have caused the jumplist record to be in existence.

This depends on the name of the file, the "deleted partial jump list" item, etc.

2) The file itself may have been "auto opened", or in fact the jumplist record may have been created on creation, in absense of a specific user action. Without "modified" times to the jumplist record, this cannot be ruled out.

Perhaps, but it would also be much less likely. In sure attorneys say a lot during a trial, but if I were on the jury and an attorney said that a jump list item could have been created with NO interaction from the user, I would assign much less weight to that statement; in fact, I would begin to question everything else that attorney said, and try to pick it apart.

This is actually pretty easy to test. Copy a video file onto a system in a similar location as to the one found, and then go about your business, never actually accessing the file. Let the system run for a considerable amount of time…a day, perhaps. Then check the system to see if the file was added to any jump lists.

3) The file itself could have been deleted and then undeleted. This would again create such a record. The only distinguising feature would be the application id, which we do not have at this stage.

I don't know that deleting then undeleting the file would have created the entry in question. While some user action is required for a jump list item to be created, I don't know of any application ID for a jump list that would indicate that the sole action from the user was to delete and then undelete the file.

Anything is *possible*, but as with #2, this theory is pretty unlikely.

4) The video in question could have been opened, or attempted to have been opened with an application that has no ability to display such a file type. Again, the result is similar to point 3.

That's possible, albeit easy to check. With the file extension, it is trivial to determine with application would have opened the file by default, had the user simple double-clicked on it.

Something else to keep in mind…the Windows Registry holds a great deal of information regarding files viewed by the user. So…do the shellbags show any indication of the folder path to the file being accessed by the user (this may be unique, or it may be something regularly accessible by the user, such as the desktop)? Are there any indications of the file listed anywhere in the Registry? You should search by name, not including the path. Also, check for deleted entries in the Registry…again, this is trivial.

5) The video could have been a part of a playlist, therefore causing a jumplist record, again, without ever being viewed.

This really depends on the data being looked at.

From the above information, I would suggest fairly confidently that the mere existence of a partial jumplist record could in no way be used as evidence that the file had been viewed by the user.

I would've said that from the very beginning, and not had to go through various theories. 😉

There's not telling what the other side believes is a "partial" jump list, particularly one that's been deleted. I'd look very closely at the data itself, and the first thing I'd try to determine is, what do they call a "deleted partial jump list". Knowing the structure (which is well documented at the MS site, as well as other locations) of both jump lists and shortcuts, you should be able to determine this, and get additional information (time stamps, etc.). As was mentioned, you won't get the appID for the jump list, so significant context will be missing.

Speaking of context, how many other user accounts are on the system? A deleted entry won't have the appropriate context to tie it to a specific user. Without knowing more about what information is actually available, the other side may have the full path to the file, which includes the file path…but not knowing that, I thought I'd offer that up.

Something else I would look for is the breadth of activity for the user. Does all of activity seem to go back to a certain point in time and just stop? This might be indicative of a wiping utility.

Finally, does the system have Volume Shadow Copies available? If so, check those.

Thanks for this, very useful!

In terms of auto-open, I was referring to a setting in which a download is opened automatically after being downloaded. The user may not have seen this happen.

With a recovered jumplist, can you forsee a situation where it is possible to work out what the appID is for this?

In my view, without timestamps to match up, I would say the jumplist shouldn't be used in evidence, as it is inconclusive and may lead to incorrect assumptions being made.

With a recovered jumplist, can you forsee a situation where it is possible to work out what the appID is for this?

Again, we don't even know if this is a "recovered jumplist" at all, as I honestly do not know how they'd be able to tell the difference between a recovered portion of a jumplist and a shortcut file.

The only way I could see that they could work out the appID is if the MFT record were to be marked as "not in use" (ie., deleted) but it still contained the original run list; if they were able to collect up the sectors in the run list and reassemble them, then yes, I could see how it would be possible to get the appID.

In my view, without timestamps to match up, I would say the jumplist shouldn't be used in evidence, as it is inconclusive and may lead to incorrect assumptions being made.

Once again, it's not clear without looking at the raw data, and knowing the context in which it was recovered, that this is even a "recovered jumplist".