Checking Bios time ...
 
Notifications
Clear all

Checking Bios time yes or no

24 Posts
8 Users
0 Likes
4,162 Views
(@rich2005)
Posts: 535
Honorable Member
 

I won't quote the above posts as it'll make this thread far too long….;)

But whilst saying yes to collection, you do both further describe problems with actually basing any opinion on the reading, and/or why it might not be right.

We could probably all go on and on listing further reasons not to rely on it, or why it shouldn't be taken at face value, or used to assert that an earlier timestamp of some kind is likely to be correct.

As for the merit to counsel knowing it…..that's a double edged sword. You could record/report and it could result in lots of explanation/argument in the box. Equally you could not record it and have the same issue (in both scenarios explaining why you can't rely on it as an indication historic timestamps are correct for all the reasons we've described and no doubt countless more). Either way, I think you should always be prepared to be questioned about timestamps, and whilst it's a horrible subject with endless possibilities, could inevitably crop up at any moment.

Whichever way you cut it, we all know you can't say with any confidence at all, that just because the clock is correct now, that any timestamps in the past are accurate. Equally, just because it's inaccurate at the time of examination, you can't infer that all the previous timestamps were inaccurate.

So, if times are significant, we're back to trying to properly investigate the time issue more thoroughly, and trying to to do the difficult task of trying to give indications of why the time might, or might not be, reliable.

I could argue that the capture, and reporting of the clock alone, is arguably misleading to non-forensics people, by virtue of the fact they might understandably make the logical leap that it's quoted to indicate the other timestamps they're seeing are likely to be reliable, and that, without sufficient explanation / explanatory notes, it potentially does more harm than good.

A better question might be "when WOULD you rely, or give any meaningful weight, to the RTC taken at the time of examination of a seized device"?

 
Posted : 20/05/2019 5:06 pm
passcodeunlock
(@passcodeunlock)
Posts: 792
Prominent Member
 


A better question might be "when WOULD you rely, or give any meaningful weight, to the RTC taken at the time of examination of a seized device"?

A good analyst would never rely on the RTC taken at the time of examination of a seized device. As I wrote before, the BIOS time / RTC serves documentation purposes only.

 
Posted : 20/05/2019 7:50 pm
(@athulin)
Posts: 1156
Noble Member
 

I could argue that the capture, and reporting of the clock alone, is arguably misleading to non-forensics people, by virtue of the fact they might understandably make the logical leap that it's quoted to indicate the other timestamps they're seeing are likely to be reliable, and that, without sufficient explanation / explanatory notes, it potentially does more harm than good.

I don't think you raised that question. You asked about collecting the information … not including it in the final report. My answer addresses the collecting part only.

As for making more harm than good … you must be able to say 'this is hard evidence, and there cannot be any technical doubt about it', or 'this evidence may be used only under the assumption that … ' etc. In some cases, you must say 'evidence as to … could not be obtained with any degree of confidence, and so this question has not been answered at all in this report.' Or words to that effect.

As to writing anything without sufficient explanation or without explanatory notes … in my world that's never a option.

A better question might be "when WOULD you rely, or give any meaningful weight, to the RTC taken at the time of examination of a seized device"?

When it is demonstrably false, or turns out to be so out of synch with other evidence that the possibility that it has been used as 'correct' on boot time must be considered. (Basically, when it calls other evidence or the base for other evidence into question.) This should force the analyst to ensure that the base for the time line or important parts of it do not solely rely on the assumption RTC being correct on boot, but on stronger evidence such as logs from NTP synchs, or such.

Actually, such assurance should really be part of standard operating procedure as part of evaluating the evidentiary value of any timestamp in an environment that does not synch timestamps as soon as the system is turned on (or, equivalently, started from a power state that does not maintain internal timers).

And it does not seem impossible that it may be important to verify that the battery driving a battery-powered RTC is indeed within operational limits. If it isn't, … well, that seems to establish doubt that all timestamps are indeed correct … so extra work needs to be spent on limiting such doubts.

 
Posted : 20/05/2019 7:55 pm
jaclaz
(@jaclaz)
Posts: 5133
Illustrious Member
 

When I booted this PC this morning its RTC was showing 21/05/2019 0812.54, roughly at the same time another PC surely connected to an internet time service was showing 21/05/2019 0813.01 UTC.

Now let's see what kind of logical (or illogical 😯 ) leaps can anyone derive from the above statement, intentionally void of any comment, explanation or corollary, only a simple, straightforward statement . roll

jaclaz

 
Posted : 21/05/2019 9:19 am
(@rich2005)
Posts: 535
Honorable Member
 

When it is demonstrably false, or turns out to be so out of synch with other evidence that the possibility that it has been used as 'correct' on boot time must be considered. (Basically, when it calls other evidence or the base for other evidence into question.) This should force the analyst to ensure that the base for the time line or important parts of it do not solely rely on the assumption RTC being correct on boot, but on stronger evidence such as logs from NTP synchs, or such.

But surely you should NEVER solely rely on the assumption that the RTC being correct lends weight to the fact that other historic timestamps are correct (and vice versa).

Actually, such assurance should really be part of standard operating procedure as part of evaluating the evidentiary value of any timestamp in an environment that does not synch timestamps as soon as the system is turned on (or, equivalently, started from a power state that does not maintain internal timers).

Even in an environment that doesn't synch timestamps as soon as the system is turned on, with an accurate (or not) RTC, how can you derive credibility from the current RTC. It could have been changed in the bios just prior to seizure. It could have been changed in the bios during a certain point in time and then actions taken. And countless other possibilities.

And it does not seem impossible that it may be important to verify that the battery driving a battery-powered RTC is indeed within operational limits. If it isn't, … well, that seems to establish doubt that all timestamps are indeed correct … so extra work needs to be spent on limiting such doubts.

I would argue that doubt should always exist and an inaccurate RTC doesn't change that.

A good analyst would never rely on the RTC taken at the time of examination of a seized device. As I wrote before, the BIOS time / RTC serves documentation purposes only.

I don't really know what "documentation purposes" means. There's endless things you could document but you select which based on value. Do you fingerprint every component of every machine?

When I booted this PC this morning its RTC was showing 21/05/2019 0812.54, roughly at the same time another PC surely connected to an internet time service was showing 21/05/2019 0813.01 UTC.

Now let's see what kind of logical (or illogical 😯 ) leaps can anyone derive from the above statement, intentionally void of any comment, explanation or corollary, only a simple, straightforward statement . roll

jaclaz

A person not familiar with digital forensics could easily make the leap that because the time on the computer was accurate to within a small number of seconds that the timestamps in the case would be likely to be accurate. We know this is not true.

 
Posted : 21/05/2019 11:21 am
jaclaz
(@jaclaz)
Posts: 5133
Illustrious Member
 

A person not familiar with digital forensics could easily make the leap that because the time on the computer was accurate to within a small number of seconds that the timestamps in the case would be likely to be accurate. We know this is not true.

Good. )

BUT persons not familiar with digital forensics (which shouldn't BTW judge or derive anything from data - as opposed to conclusions - in a digital forensics report) can be divided in
1) persons not familiar with digital forensics AND knowing that they are not familiar with it
2) persons not familiar with digital forensics NOT knowing that they are not familiar with it or BELIEVING WRONGLY that they are familiar with it

Category #1 will ask to someone familiar with digital forensics (and there won't be any leap).
Category #2 cannot be cured.

jaclaz

 
Posted : 21/05/2019 12:10 pm
(@rich2005)
Posts: 535
Honorable Member
 

A person not familiar with digital forensics could easily make the leap that because the time on the computer was accurate to within a small number of seconds that the timestamps in the case would be likely to be accurate. We know this is not true.

Good. )

BUT persons not familiar with digital forensics (which shouldn't BTW judge or derive anything from data - as opposed to conclusions - in a digital forensics report) can be divided in
1) persons not familiar with digital forensics AND knowing that they are not familiar with it
2) persons not familiar with digital forensics NOT knowing that they are not familiar with it or BELIEVING WRONGLY that they are familiar with it

Category #1 will ask to someone familiar with digital forensics (and there won't be any leap).
Category #2 cannot be cured.

jaclaz

Indeed.
My point was really just to debate the actual value of collecting/reporting the RTC value. Especially in the context of seized items rather than a "live" examination.
Like most of us I've done it as a matter of course for donkeys years.
I'm just more skeptical now of the actual merit for "dead" / "powered down" items.
Having said that, I suppose the merit of checking it is more, as athulin said, as a prompt for further investigation, rather than anything else.
Thinking out loud, I was making the counter-argument of that obviously we should treat timestamps with more skepticism and therefore shouldn't need prompting, but I suppose if you take into account the realities of time/money, which most people have to work within, then a significantly outlying RTC might be justification to say more time needs to be spent validating timestamps (even if in reality most cases would benefit from more scrutiny of timestamps, for reliability, but will never be paid for by the employer/court/client etc).

 
Posted : 21/05/2019 1:20 pm
(@athulin)
Posts: 1156
Noble Member
 

But surely you should NEVER solely rely on the assumption that the RTC being correct lends weight to the fact that other historic timestamps are correct (and vice versa).

I can't imagine how you interpret what I wrote. I see nothing in there that leads to the point you are questioning.

Even in an environment that doesn't synch timestamps as soon as the system is turned on, with an accurate (or not) RTC, how can you derive credibility from the current RTC. It could have been changed in the bios just prior to seizure. It could have been changed in the bios during a certain point in time and then actions taken. And countless other possibilities.

Um … I wasn't saying anything about that. I was addressing an RTC that is undeniably out of synch, not one that isn't. As RTC is the basis of system time after power-on (unless you have other solutions) until a better time has been obtained from somewhere, you somehow need to address that – for example by documenting a conclusion that system timestamps between X and Y are not necessarily in synch with local time, and thus should not be relied on.

Or … you may say that RTC is unreliable, and so *all* timestamps after a power up until a NTP synch is unreliable. Unless, perhaps, the diff was smaller than some well-chosen limit. As long as you document it, so that readers of your report can evaluate it.

I view establishing the relationship between system time and local time a basic and mandatory part of forensic analysis and report. I happen to regard badly out of synch RTC as one of several inputs to such a process, and for that reason needs to be collected and documented.

In some cases, I even get direct questions from customers about any indication (even low-confidence ones) about booting with a different operating system, and when it happened. If RTC is off by UTC offset, it's could be such indication. System logs where time synch time is on that order may also be such indicators. As I do not participate in the customer's internal investigations, I can only answer their questions, and warn about low-confidence indicators. In writing.

It might be slightly better to put your original question on a slightly different base for example "Does anyone have ISO 17025 methods that use computer RTC in any way, and so require that information about RTC and its operational environment needs to be collected?"

 
Posted : 21/05/2019 4:32 pm
jaclaz
(@jaclaz)
Posts: 5133
Illustrious Member
 

So, if we make a decision tree of sorts
A) RTC date/time is recorded/logged (at a given time, as well logged, coming from a known to be accurate enough source)
or
B) RTC date/time is NOT recorded/logged

IF A)
A1) the RTC date/time is accurate (within a "reasonable" approximation [1]) and this may (or may not) mean anything or something or the opposite of it, and this can of course be debated, argued and counter argued as much as you want.
or
A2) the RTC date/time is NOT accurate (within the same "reasonable" approximation) and this may (or may not) mean anything or something or the opposite of it, and this can of course be debated, argued and counter argued as much as you want.

IF B)
B) Nothing can be said about the accuracy (or lack of it) of the RTC.

The only argument (or counter argument) in case B) is that the investigator could (or should) have logged it and IF he/she had logged it THEN we could be in either A1) or A2) but we will never know.

I personally would always prefer the arguments (and counter arguments) in A).

jaclaz

[1] which we can tentatively assume amounting to a small amount of seconds

 
Posted : 21/05/2019 5:42 pm
(@fissa)
Posts: 27
Eminent Member
Topic starter
 

Thanks for all the reply's! Very usefull. (I was afk for a few days, so i apologise for not responding sooner)

When posting i had i mind getting and yes or no, with an argument why so. I have learned, reading all the reply's, there is no right or wrong. Im convinced taking note of the bios time is only a small effort and therefor something i will do in the future. But then again; for what use. It doesnt say anything about the time-set in the past, so i cant derive any rights.

An interesting topic. I think it will keep me busy untill the end of times ^^

 
Posted : 21/05/2019 7:26 pm
Page 2 / 3
Share: