
Time Stamp Counter (a.k.a. TSC, RDTSC) - peter_d_sherman
https://en.wikipedia.org/wiki/Time_Stamp_Counter
======
peter_d_sherman
Random Idea: If a virus or other malware is using the TSC register as its time
source (perhaps say, to wait an hour or more from machine startup before
activating itself to avoid detection), then the ability to simulate what it is
reading as its time source, and increment it, at various rates of speed, in a
virtual machine, could be of great benefit to virus and malware researchers...

Of course, the guest OS's time and other time sources would have to be updated
in sync... but this technique might go a long way to flushing out, the
existence at least, of such stealthy little critters...

Note to future self: If I design a VM in the future, then it must support this
"speed up time" feature... the same with an OS... and of course, log/notify
the user about any program executing this instruction and when...

In fact... why not go as far as to log/notify the user if/when ANY program
reads ANY (CPU, OS API, instruction counts etc.) time source, or thing that
could be used as a time source... any program so much as touches any of those
things, then if the program isn't given explicit permission to do so --
log/notify the user...

Oh... one more idea while I'm at it...

Same thing but applied to any random number generator (RNG). If I can pre-
program a set of values that go in there (and/or record the ones being
generated and replay them later), then I can create a more deterministic
machine in virtual environments. In other words, if the virus writer has code
which ways wait 1..random number minutes before activating -- then let's
replay those random numbers and see if we can't get determinism. Which brings
us to the OS level... since the RNG is shared by all programs, on a multi-
tasking OS running multiple programs, what is retrieved with multiple programs
is arbitrary. So at the OS level, record any single program's RNG requests,
and be able to play them back to that same program in the same order on the
next re-run of our OS in the VM...

