Механизм образования временных меток в Windows – часть 2

Содержание

1 Проверочные вопросы
2 Различное время у одних и тех же файлов
3 Какой часовой пояс был установлен?
4 Ищем следы перевода системного времени
- 4.1 Событие безопасности
- 4.2 Дивергенция последовательности событий

Здравствуйте! Продолжаю статью про образование временных меток в операционных системах Windows. По традиции, сперва проверочные вопросы:

Проверочные вопросы

Почему при просмотре различными программами отображается различное время создания файлов у одних и тех же файлов?
Как узнать, какое смещение часовых поясов было установлено в системе не включая компьютер?
Какие следы остаются при ручном изменении системного времени?

Различное время у одних и тех же файлов

Сейчас покажу, что я имею ввиду. Создадим на пустом NTFS-томе один файлик. Я пока не буду говорить его истинную дату создания, посмотрим, сможете ли вы сами догадаться.

Откроем этот том при помощи популярной программы для восстановления информации: R-Studio:

Видим дату создания: 08.12.2018 21:25:12.

Теперь представим, что у нас проблемы с файловой системой и мы читаем 16-ричный дамп диска другой программой. Здесь я воспользуюсь WinHEX, чтобы показать одну интересную деталь:

Тот же самый файл. Интерпретатор данных показывает дату 08.12.2018 10:25:12. Теперь внимание вопрос. Какой дате верить? У нас есть 08.12.2018 10:25:12 и 08.12.2018 21:25:12.

На самом деле фокус тут в том, что на диск временные метки записываются в формате UTC (речь о файловой системе NTFS), а отображаются уже с учётом смещения часового пояса. Сейчас у меня стоит +11 часов (Магадан). Поэтому R-Studio (а вместе с ней и тот же самый Total Commander, проводник и ряд других программ) любезно прибавит эту разницу и покажет 21:25:12. Но если я передам этот диск своему товарищу в С-Петербург, например, и он его подключит к своему компьютеру через адаптер, то увидит дату создания файла 08:12:2018 13:25:12 (при условии, что у нас с ним разница в 8 часов). Вот такая вот путаница может возникнуть. Это нужно обязательно учитывать.

Совет: Описывая какое-либо время события обязательно учитывайте, какой часовой пояс был установлен в операционной системе! Либо приводите всё к формату UTC.

Кстати, пользуясь случаем хочу порекомендовать качественный IT блог с множеством различных видеокурсов и интересных статей: https://itvdn.com/ru/blog. Для общего и специального развития компьютерщика должно быть очень полезно!

Какой часовой пояс был установлен?

Предположим, что мы не можем включить компьютер и посмотреть, какой же там часовой пояс был установлен? Ну например, нам предоставили только жёсткий диск и/или операционная система частично неработоспособна.

Поможет нам в этом системный реестр.

Пример такой: подключили жёсткий диск к своему компьютеру (через адаптер), системному разделу присвоена буква G:.

Проводником или чем удобнее, открываем каталог: G:\Windows\system32\config и ищем файлы SYSTEM и SOFTWARE без расширений – это “ульи” системного реестра. Подключаем их к своему редактору реестра через команду: “Файл -> Загрузить куст”. При этом нужно выбрать раздел своего реестра, например HKEY_LOCAL_MACHINE, куда будет примонтирован внешний реестр.

Монтируем SYSTEM и SOFTWARE файлы, давая им осмысленные имена, например remote_SYS, remote_SOFT.Теперь переходим в раздел: “remote_SYS\ControlSet001\Control\TimeZoneInformation” и смотрим на параметр “TimeZoneKeyName”. В нашем случае он равен “Vladivostok Standard Time”.

Кстати, если ControlSet00X есть несколько разделов, то узнать текущий можно из раздела “\remote_SYS\Select” параметр “Current”. Этот параметр показывает текущую конфигурацию. Нетрудно срастить этот параметр с такой вещью как “Последняя удачная конфигурация” – несколько независимых набора настроек, позволяющих загрузить систему в случае каких-либо фатальных изменений настроек (что-то типа резервной копии).

Итак, теперь переходим в раздел “\remote_SOFT\Microsoft\Windows NT\CurrentVersion\Time Zones”, открываем раздел “Vladivostok Standard Time” и ищем параметры “Display” и “TZI”. Display показывает отображение зоны:

Display = “UTC+10:00…”. Что как бы намекает…

А теперь откроем параметр TZI:

A8 FD FF FF …. Не совсем понятно, что это. Обратимся к официальной документации:

typedef struct _REG_TZI_FORMAT { LONG Bias; LONG StandardBias; LONG DaylightBias; SYSTEMTIME StandardDate; SYSTEMTIME DaylightDate; } REG_TZI_FORMAT;

LONG – 4 байта. Октрываем стандартный калькулятор и вводим данные. Порядок байт обратный, то есть попарно вводим с конца (A8 FD FF FF превращается в FF FF FD A8):

Преобразуем в десятичный вид и видим “-600”. Это и есть разница с UTC-временем в минутах. То есть временная метка на диске – 600 минут = время в UTC. Отсюда делаем вывод, что действительно установлен часовой пояс UTC+10:00.

Уморился я что-то… Интересно хоть? Ладно, идём дальше. Теперь что касается перевода времени пользователем.

Ищем следы перевода системного времени

Часто предприимчивые юзеры перед созданием какой-либо пакости начинают шаманить системное время. Поставят неверную дату и сделают шалость. Потом вернут как было. Начинаешь смотреть – да, шалость есть, но произошла вовсе не тогда, когда планировалось. Неужели ничего нельзя сделать?

Можно. Давайте поглядим.

Событие безопасности

Во-первых, всякое изменение системного времени – есть событие. И событие настолько важное, что генерируется специальная запись в журнале безопасности. Её легко отфильтровать по коду события 4616 (даже в штатном интерфейсе просмотра событий есть фильтры).

Вот так выглядит синхронизация времени операционной системой:

Видно, что событие инициировано от имени NT AUTHORITY\LOCAL SERVICE, а новое время установлено близко к предыдущему и весьма “грубо”, то есть цифры после точки (тысячные доли секунды).

А вот так выглядит время, установленное вручную:

Обратите внимание на инициатора – локальный пользователь. А также новое время установлено с точностью до секунды (после точки – все нули). Дело в том, что штатный интерфейс позволяет указывать время только с точностью до секунды, а программа синхронизации времени может выставлять до тысячных долей. В этом примере время практически не поменялось. Но если бы оно отличалось, то пришлось бы строить параллельно новую шкалу времени, где в моменте перевода времени таймлайн бы делился и отсчёт шёл бы уже относительно нового времени.

Если какое-либо событие попадает внутрь этой “петли” времени, то нельзя с уверенностью сказать, происходило оно в то время, когда время было истинно, или уже потом, когда время было сфальсифицировано. По крайней мере необходимо искать другие признаки. Как-нибудь расскажу.

Кстати, если вдруг нужно исследовать журналы событий системы со съемного диска, то они лежат в каталоге: G:\Windows\System32\winevt\Logs (сейчас нас интересует System.evtx)

Дивергенция последовательности событий

Ой какое страшное слово. И что оно значит? Сейчас объясню простым языком. Дело в том, что помимо даты события в журнал записывается его порядковый номер (который только увеличивается). То есть первое событие произошло в дату X. Второе – в дату X + 2 секунды. Третье – в X + минута.. и т.д. Нетрудно догадаться, что с увеличением порядкового номера будет увеличиваться и время. Но что произойдёт, если будет установлена дата, которая уже прошла?

Так или иначе, запишется какое-либо событие (а поверьте на слово, ежесекундно в операционной системе происходит много разных вещей, в том числе генерирующих события) с порядковым номером N+1, а его дата будет X – Y. То есть оно затешется где-то между других событий. И если упорядочить все события по дате, то увидим характерный “излом” порядковых номеров типа:

1, 2, 3, 4, 5, 4567, 4568, 4569, 6, 7, 8, …. Некоторые события вклинятся не в свою очередь. Это и будет характерным признаком того, что компьютер какое-то время работал с неверно выставленной системной датой/временем. И смотреть тут придётся все журналы (наиболее полные – Security, software, applications и т.д. Любые, вплоть до журнала браузера, антивируса или программы, ведущей логи. Последовательность событий будет нарушена.

Вот пример. Берём программу Event Log Explorer (или любую подобную, где можно включить столбец “№ записи”), открываем журнал (текущий или с удалённой системы с каталога “Windows\system32\winevt\Logs”) и сортируем записи по дате. На скрине видна стрелочка. Ищем расхождения в номерах записей – вот я выделил рамкой, обратите внимание на первый столбец. Налицо явное “вклинивание” записей 48тысячных в 47тысячные.

Значит что нужно сделать? Перейти на 48538 событие (скорее всего это будет 4616 – смена системного времени), записать себе позицию предыдущего времени и пересчитать дельту всех интересующих событий… Затем найти последнее событие 4616, когда снова будет установлено новое время и замкнуть “временную петлю”.