Calculating Viable Opcode Windows

After analyzing SharedUserData for temporal addresses it should become clear that the SystemTime attribute is by far the most useful and potentially feasible attribute due to its scale and update period. In order to successfully leverage it in conjunction with an exploit, though, the viable opcode windows must be calculated so that a time to strike can be selected. This can be done prior to determining what the actual date is on a target machine but requires that the storage capacity (size of the temporal address in bytes), the update period, and the scale be known. In this case, the size of the SystemTime attribute is 12 bytes, though in reality the 3rd attribute, High2Time, is exactly the same as the second, High1Time, so all that really matters are the the first 8 bytes. Doing the math to calculate per-byte durations gives the results shown in figure . This indicates that it is only worth focusing on opcode permutations that start at byte index four due to the fact that all previous byte indexes have a duration of less than or equal to one second. By applying the scale as being measured since Jan 1, 1601, all of the possible permutations for the past, present, and future can be calculated as described in chapter . The results of these calculations for the SystemTime attribute are described in the following paragraphs.

In order to calculate the viable opcode windows it is necessary to have identified the viable set of opcodes. In this case study a total of 320 viable opcodes were used (recall that opcode in this case can mean one or more instruction). These viable opcodes were taken from the Metasploit Opcode Database[2]. After performing the necessary calculations and generating all of the permutations, a total of 3615 viable opcode windows were found between Jan. 1, 1970 and Dec. 23, 2037. Each viable opcode was broken down into groupings of similar or equivalent opcodes such that it could be made easier to visualize. Figure shows a graph of all of the viable opcode windows between 1970 and 2038 as broken down by opcode groupings.

Figure: Opcode occurrences by year (size=8, period=100nsec, scale=1601epoch)

Looking closely at figure it can bee seen that there were two large spikes around 2002 and 2003 for the [esp + 8] => eip opcode group which includes pop/pop/ret instructions common to SEH overwrites. Looking more closely at these two years shows that there were two significant periods of time during 2002 and 2003 where the stars aligned and certain exploits could have used the SystemTime attribute as a temporal return address. Figure shows the spikes in more detail. It's a shame that this technique was not published about during those time frames! Never again in the lifetime of anyone who reads this paper will there be such an occurrence.

Figure: [esp + 8] => eip spikes in 2002, 2003

Perhaps of more interest than past occurrences of certain opcode groups is what will come in the future. The table in figure shows the upcoming viable opcode windows for 2005.