|Informative Information for the Uninformed|
Next: Determining System Time Up: Temporal Return Addresses Previous: Calculating Viable Opcode Windows   Contents
The time to attack is entirely dependent on both the update period of the temporal address and its scale. In most cases, temporal addresses that have a scale that is relative to an arbitrary date (such as 1970 or 1601) are the most useful because they can be predicted or determined with some degree of certainty. Regardless, a generalized approach can be used to determine projected time intervals where useful opcodes will occur.
To do this, it is first necessary to identify the set of instructions that could be useful for a given exploit, such as a jmp esp. Once identified, the next step is to break the instructions down into their raw opcodes, such as 0xff 0xe4 for jmp esp. After all the raw opcodes have been collected, it is then necessary to begin calculating the projected time intervals that the bytes will occur at. The method used to accomplish this is rather simple.
First, a starting byte index must be determined in terms of the lowest acceptable window of time that an exploit can use. In the case of a 100 nanosecond timer, the best byte index to start at would be byte index 4 considering all previous indexes have a duration of less than or equal to one second. The bytes that occur at index 4 have a 7 minute and 9 second duration, thus making them feasible for use. With the starting byte index determined, the next step is to create permutations of all subsequent opcode byte combinations. In simpler terms, this would mean producing all of the possible byte value combinations that contain the raw opcodes of a given instruction at a byte index equal to or greater than the starting byte index. To help visualize this, figure provides a small sample of jmp esp byte combinations in relation to a 100 nanosecond timer.
Once all of the permutations have been generated, the next step is to convert them to meaingful absolute time representations. This is accomplished by converting all of the permutations, which represent past, future, or present states of the temporal address, to seconds. For instance, one of the permutations for a jmp esp instruction found within the 64-bit 100nanosecond timer is 0x019de4ff00000000 (116500949249294300). Converting this to seconds is accomplished by doing:
11650094924 = trunc(116500949249294300 / 10 ^ 7)
This tells us the number of seconds that will have passed when the stars align to form this byte combination, but it does not convey the scale in which the seconds are measured, such as whether they are based from an absolute date (such as 1970 or 1601) or are simply acting as a timer. In this case, if the scale were defined as being the number of seconds since 1601, the total number of seconds could be adjusted to indicate the number of seconds that have occurred since 1970 by subtracting the constant number of seconds between 1970 and 1601:
5621324 = 11650094924 - 11644473600
This indicates that a total of 5621324 seconds will have passed since 1970 when 0xff will be found at byte index 4 and 0xe4 will be found at byte index 5. The window of opportunity will be 7 minutes and 9 seconds after which point the 0xff will become a 0x00, the 0xe4 will become 0xe5, and the instruction will no longer be usable. If 5621324 is converted to a printable date format based on the number of seconds since 1970, one can find that the date that this particular permutation will occur at is Fri Mar 06 19:28:44 CST 1970.
While it's now been shown that is perfectly possible to predict
specific times in the past, present, and future that a given
instruction or instructions can be found within a temporal address,
such an ability is not useful without being able to predict or
determine the state of the temporal address on a target computer at
a specific moment in time. For instance, while an exploitation
chronomancer knows that a jmp esp can be found on March
6th, 1970 at about 7:30 PM, it must also be known what the target
machine has their system time set to down to a granularity of mere
seconds, or at least minutes. While guessing is always an option,
it is almost certainly going to be less fruitful than making use of
existing tools and services that are more than willing to provide a
would-be attacker with information about the current system time on
a target machine. Some of the approaches that can be taken to gather
this information will be discussed in the next section.