Google Chrome Times...
 
Notifications
Clear all

Google Chrome Timestamp Question

11 Posts
5 Users
0 Likes
2,160 Views
(@cooper9216)
Posts: 6
Active Member
Topic starter
 

Hello all,

Background

I am currently working a case whereby items in Google Chrome history are relevant.

First of all I used Internet Evidence Finder v.6.13.0.10358 over an E01 file and reviewed the Google Chrome history. I have identified items relevant to the case and these are present within AppData\Local\Google\Chrome\UserData\Default\History.

The E01 forensic image is of a laptop which is running Windows 7 Home Premium.

Issue

IEF is showing the same last visited date/time, to the second, for numerous records.

I have then exported the History database and manually examined this with SQLiteSpy to verify IEF has parsed the database correctly.

Upon manual examination the History database has a large number of different records, different URLs, which all have the same timestamp. Again the timestamp is to the second.

For example, I have in excess of 80 records all with the timestamp 23-01-2018 173324.

I have not seen Google Chrome history present the timestamps like this before.

I have searched the forums for similar posts but this search has so far been negative. My collegues are also unsure of what is happening in this instance.

I look forward to any responses )

Many thanks,
cooper9216

 
Posted : 26/05/2018 1:44 pm
Bunnysniper
(@bunnysniper)
Posts: 257
Reputable Member
 

I look forward to any responses )

Many thanks,
cooper9216

Tried different tools? Perhaps some change in time format or you discovered a bug?

Please try Hindsight https://github.com/obsidianforensics/hindsight on the same evidence and compare the output. Hindsight and X-Ways Forensics are my preferred tools for analyzing browser history. Once I find something is strange, I try all available tools I have to see, which tool has a problem (or not). Anyway, please post the solution here once you find it, I am really interested about what has happened in this case.

regards, Robin

 
Posted : 28/05/2018 9:27 am
(@mcman)
Posts: 189
Estimable Member
 

As for different URLs having the exact same time, I'm not certain but have a few guesses. One guess could be a restored session that had a bunch of tabs open and once they were restored, all the tabs updated their timestamp. Another might be Chrome Sync, check what kind of sync settings are on the computer, maybe they synced up from another device on the account. The visits and visits_source tables should help with this as well.

Was this from a live system or was the db open at the time of acquisition? Check for a wal file as well. IEF/AXIOM will automatically search both together but if you just exported the db, you may get some additional info in the wal file.

If that doesn't work, see what else happened on the system at that given time, that might give you a clue to what the user/system was doing.

Trying in another tool is always helpful but he said he manually looked at the database and the timestamps were as such so every tool would likely report the same thing. Worth verifying but if a simple SQLite viewer is showing the same thing, I expect other tools to do so as well.

Jamie McQuaid
Magnet Forensics

 
Posted : 28/05/2018 2:37 pm
PaulSanderson
(@paulsanderson)
Posts: 651
Honorable Member
 

Do you have examples of the raw dates - Chrome stores time as micro seconds since 1/1/1601

Are the dates all the same to the exact mirosecond?

 
Posted : 29/05/2018 9:21 am
(@cooper9216)
Posts: 6
Active Member
Topic starter
 

As for different URLs having the exact same time, I'm not certain but have a few guesses. One guess could be a restored session that had a bunch of tabs open and once they were restored, all the tabs updated their timestamp. Another might be Chrome Sync, check what kind of sync settings are on the computer, maybe they synced up from another device on the account. The visits and visits_source tables should help with this as well.

Was this from a live system or was the db open at the time of acquisition? Check for a wal file as well. IEF/AXIOM will automatically search both together but if you just exported the db, you may get some additional info in the wal file.

If that doesn't work, see what else happened on the system at that given time, that might give you a clue to what the user/system was doing.

Trying in another tool is always helpful but he said he manually looked at the database and the timestamps were as such so every tool would likely report the same thing. Worth verifying but if a simple SQLite viewer is showing the same thing, I expect other tools to do so as well.

Jamie McQuaid
Magnet Forensics

Thanks Jamie,

Completely overlooked the possibility of an import from another browser (first case with this scenario)! Problem solved!

Cheers, Ryan

 
Posted : 30/05/2018 6:36 am
watcher
(@watcher)
Posts: 125
Estimable Member
 


For example, I have in excess of 80 records all with the timestamp 23-01-2018 173324. …

As Paul Sanderson replied, this would appear to be an artifact of the tool used as the raw data is not nornally stored that way. The "month/day/year" format is typical of U.S. dates but not common in the rest of the world, so unless this is a U.S. machine, it's another indicator of tool interpretation (or misinterpretation).

Oops, misread that; Not U.S. but the recommendation stands.

On the other hand, it's extremely unlikely that micro seconds since 1/1/1601 would misinterpret to a plausible current date.

My guess would be that the tool is pulling out some other string date and this is not a browser history date at all.

Check the raw data.

 
Posted : 31/05/2018 2:39 pm
(@mcman)
Posts: 189
Estimable Member
 

As Paul Sanderson replied, this would appear to be an artifact of the tool used as the raw data is not nornally stored that way. The "month/day/year" format is typical of U.S. dates but not common in the rest of the world, so unless this is a U.S. machine, it's another indicator of tool interpretation (or misinterpretation).

On the other hand, it's extremely unlikely that micro seconds since 1/1/1601 would misinterpret to a plausible current date.

My guess would be that the tool is pulling out some other string date and this is not a browser history date at all.

Check the raw data.

He did check the raw data which showed the same date.

AXIOM/IEF also pulls the correct date that Paul mentioned in his post.

His question wasn't the validity of the translation to a date/time, it was the fact that he had multiple entries with the same date/time and needed to explain why that was happening. His follow up post explains the reason for it (an import from another browser) which makes sense from an investigative standpoint.

Jamie

 
Posted : 31/05/2018 3:04 pm
PaulSanderson
(@paulsanderson)
Posts: 651
Honorable Member
 

His question wasn't the validity of the translation to a date/time, it was the fact that he had multiple entries with the same date/time and needed to explain why that was happening. His follow up post explains the reason for it (an import from another browser) which makes sense from an investigative standpoint.

Jamie

If I understand what has been said - I am surprised the the import gets the URLs OK but does not correctly import the dates, or rather seems to stamp them at the time of the import. What would be the logic of this? Thats why I would like to see the raw dates and see if that tells us anything

 
Posted : 31/05/2018 3:08 pm
watcher
(@watcher)
Posts: 125
Estimable Member
 

He did check the raw data which showed the same date.

AXIOM/IEF also pulls the correct date that Paul mentioned in his post.

His question wasn't the validity of the translation to a date/time, it was the fact that he had multiple entries with the same date/time and needed to explain why that was happening. His follow up post explains the reason for it (an import from another browser) which makes sense from an investigative standpoint.

Jamie

Got that, but part and parcel of checking the raw data when oddities appear includes correlating the odd data to the source. If AXIOM/IEF pulls the correct date, does it not indicate the source of that information? Misattribution to another browser would be concerning.

In any case, glad it was resolved.

 
Posted : 31/05/2018 3:13 pm
(@mcman)
Posts: 189
Estimable Member
 

If AXIOM/IEF pulls the correct date, does it not indicate the source of that information? Misattribution to another browser would be concerning.

Yep, we give exact source and location for everything we find. Table and record number for databases or file offset for carved data within a file so it should be pretty obvious which browser/user profile it came from, he should have everything needed to verify that.

Jamie

 
Posted : 31/05/2018 3:18 pm
Page 1 / 2
Share: