Гипотеза о том, как SF4 выявляет эмуляторы.

Гипотеза о том, как SF4 выявляет эмуляторы.

Ни для кого не секрет, что последние версии SF научились удачно ставить палки в колеса таким CD/DVD-эмуляторам, как DaemonTools и Alcohol120%.
Лично меня давно мучает вопрос: как он это делает ?
И вот после дня, потраченного на запуск одного программного продукта при помощи VirtualPC, возникла одна правдоподобная идея.
Дело в том, что в этом случае проверка не заканчивается и не появляется надпись о том, что обнаружено применение эмулятора. Все просто напросто замирает (но не зависает), и система в итоге становится нестабильной.
Казалось бы, почему такого казуса не происходит с VMware ?
И почему в даун уходит вся виртуальная машина VirtualPC, а не запущенный на ней эмулятор ?
Размышляя над этим вопросом, мне в голову пришла лишь одна мысль -- они тактуются по разному, на основе разных ТАЙМЕРОВ !

Ведь, что такое эмулятор физического устройства ?
Это программа, которая ориентируясь на показания какого-либо ТАЙМЕРА производит некие действия, аналогичные тем, что производит эмулируемое (образцовое) устройство.
Чтобы осложнить работу эмулятора, можно:
1) либо просто его обнаружить по загруженным в память драйверам, исполняемым файлам;
2) либо лишить эмуляторы исходных данных, притормозив файловую или сетевую системы;
3) и т.п.
Но еще никто не догадывался временно останавливать или даже откручивать назад ТАЙМЕР, используемый эмуляторами !!!
Суть этих опасных (с т.з. стабильности системы) действий такова, что эмулятор ждет наступления момента X, чтобы отправить данные, запрошенные программой.
Но поскольку мерзкий старморс, пользуясь своей исключительной (благодаря драйверам нулевого уровня) близостью к железу, в это время постоянно подкручивает таймер назад, то эмулятор зря ждет -- нужный момент никогда не наступит и данные, соответственно, никогда не будут отосланы (по крайней мере, до тех пор, пока "старый" не оставит таймер в покое).
Таким образом, возникает та самая пауза в несколько секунд, которая и выдает эмулятор с головой!
Точно так же безответственные манипуляции с таймером действуют и на другие программы, обрабатывающие и выдающие данные по таймеру. В момент проверки работающий WinAMP перестает воспроизводить музыку (отсылать данные по таймеру на звуковоспроводящее устройство). Не исключением оказалась и VirtualPC.

Возникает вопрос, почему на VirtualPC действуют подобные варварские махинации с таймером, а на VMware -- нет ?
Возможно, все дело в том, что в системе существует не один, а несколько таймеров.
Помните шумиху про пляски частот ? Если нет, то советую перечитать следующие статьи Александра Леменкова:
nForce2 – а пляшут ли частоты?
nForce2 – Решение проблемы "пляски частот"
В них есть кое какая информация по таймерам.
В последней статье есть даже программа, позволяющая отслеживать работу некоторых таймеров: TimerTest.rar. Запустив эту программу, изменив RTC rate, например, до 5, а затем запустив приложение с SF4, можно убедиться в том, что старморс изменяет работу таймеров!
Вот лог одного из запусков:

[ST:12: 3: 3],[CT:12: 3: 3], C-S:0, 1001ms ticks, CPU(S):1604 Mhz, CPU(A):1603 Mhz

Таймер RTC был искажен (я задал RTC rate=5)

[ST:12: 3: 5],[CT:12: 3: 8], C-S:3, 3520ms ticks, CPU(S):1349 Mhz, CPU(A):383 Mhz

[ST:12: 3: 6],[CT:12: 3:12], C-S:6, 3519ms ticks, CPU(S):1348 Mhz, CPU(A):383 Mhz

[ST:12: 3: 7],[CT:12: 3:15], C-S:8, 3520ms ticks, CPU(S):1349 Mhz, CPU(A):383 Mhz

запуск FlatOut2 (SF 4.0.9):

[ST:12: 3: 8],[CT:12: 3:19], C-S:11, 3520ms ticks, CPU(S):1350 Mhz, CPU(A):384 Mhz

[ST:12: 3: 9],[CT:12: 3:22], C-S:13, 3517ms ticks, CPU(S):1344 Mhz, CPU(A):382 Mhz

[ST:12: 3:10],[CT:12: 3:26], C-S:16, 3519ms ticks, CPU(S):1348 Mhz, CPU(A):383 Mhz

[ST:12: 3:11],[CT:12: 3:29], C-S:18, 3518ms ticks, CPU(S):1346 Mhz, CPU(A):383 Mhz

[ST:12: 3:12],[CT:12: 3:33], C-S:21, 3520ms ticks, CPU(S):1349 Mhz, CPU(A):383 Mhz

[ST:12: 3:13],[CT:12: 3:36], C-S:23, 3519ms ticks, CPU(S):1348 Mhz, CPU(A):383 Mhz

[ST:12: 3:14],[CT:12: 3:39], C-S:25, 2980ms ticks, CPU(S):484 Mhz, CPU(A):163 Mhz

SF4 полез до таймеров:

[ST:12: 3:15],[CT:12: 3:40], C-S:25, 999ms ticks, CPU(S):1601 Mhz, CPU(A):1603 Mhz

[ST:12: 3:16],[CT:12: 3:41], C-S:25, 1003ms ticks, CPU(S):1608 Mhz, CPU(A):1604 Mhz

[ST:12: 3:17],[CT:12: 3:42], C-S:25, 999ms ticks, CPU(S):1602 Mhz, CPU(A):1604 Mhz

[ST:12: 3:18],[CT:12: 3:43], C-S:25, 1000ms ticks, CPU(S):1602 Mhz, CPU(A):1603 Mhz

[ST:12: 3:20],[CT:12: 3:45], C-S:25, 1088ms ticks, CPU(S):1744 Mhz, CPU(A):1603 Mhz

.
К сожалению, возможностей указанной утилиты недостаточно, чтобы 100%-но доказать остановку или подкрутку таймеров в обратном направлении. Для этого потребовалась бы программа, безостановочно ведущая измерения значений таймеров во время проверки. Возможно, в будущем такая подвернется под руку.
Если изложенная здесь гипотеза верна, то остается выяснить ответы на следующие вопросы:

• Какими таймерами пользуются VMware и VirtualPC ?
  
• Каким таймером пользуются эиуляторы DT и A120% и существует ли возможность перевести их на таймеры от VMware (желательно без декомпиляции) ? Если существует, то почему их авторы этого еще не сделали ? ;)
  
• Приведет ли смена ядер операционной системы WinXP к изменениям в поведении виртуальных машин и эмуляторов (в т.ч. внутри виртуальных машин) ? Надо будет поэкспериментировать.

Обращаю внимание еще раз: все, описанное здесь, лишь гипотеза, которую нужно проверить (доказать/опровергнуть).
Если есть какие-то вопросы, предложения, то просьба высказывать их здесь или здесь.