4 ms·

Time Stamp Counter (a.k.a. TSC, RDTSC)

peter_d_sherman 7y ago
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...

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...