Проблема: Необходимо достоверно определить, вносились ли изменения в таблицу (Excel, SQL, CSV) после её последнего сохранения, без доверия к встроенным датам файловой системы (которые легко подделываются).

Причины:
1. Подмена метаданных: Дата «Изменено» в свойствах файла может быть изменена через `SetFileTime` или атрибуты.
2. Необновление даты: Редактирование без сохранения не меняет дату файла.
3. Ложный след: Восстановление предыдущих версий (Shadow Copy) может перемешать временные метки.

Решение (3 уровня глубины):

1. Базовый — хэш-контроль (для контрольных точек)
- Если есть эталонный хэш (MD5/SHA256) файла сразу после сохранения, вычислите текущий:
cmd
certutil -hashfile "C:\table.xlsx" SHA256

- Ограничение: Работает только при заранее взятом хэше. Не покажет факт неавторизованного редактирования, если эталона нет.

2. Продвинутый — метаданные файла таблицы в контексте версий
- Проверка версий файла (Windows Previous Versions):
- Клик ПКМ по файлу → «Свойства» → «Предыдущие версии».
- Если версии отличаются по размеру/дате — минимум одно сохранение после даты эталона. Не говорит о редактировании — только о факте записи.

- Анализ метаданных OOXML (для .xlsx/.xlsm):
- Распакуйте `file.xlsx` (это ZIP) и проверьте `docProps/core.xml`:
xml
2024-03-15T10:00:00Z

- Если `modified` > даты эталонного сохранения — прямое доказательство редактирования. Дата подделывается только через распаковку и правку XML.

3. Форензика — анализ логов файловой системы ($MFT/JumpList)
- NTFS $MFT (Master File Table):
- Используйте `MFT Explorer` или `$MFT` парсер.
- Сравните атрибуты `$STANDARD_INFORMATION` (SI) и `$FILE_NAME` (FN).
- Признак редактирования: Время `$SI.Modified` — время последнего изменения данных. Если `SI.Modified` > `FN.Creation` — изменение было.
- Команда извлечения (только для экспертов, читать блок RAW):
cmd
fsutil mft readFile C:\ 0x1C0 > mft_dump.txt  (пример для ручного разбора)


- Jump Lists (Windows 10/11): Содержат историю открытия и сохранения конкретных файлов приложением (Excel, Notepad++). Анализ через `JLECmd.exe` или вручную `%APPDATA%\Microsoft\Windows\Recent\AutomaticDestinations\`.
- Результат: Даты последнего сохранения в Excel — если дата в Jump List позднее эталона, файл редактировали.

Итоговая рекомендация для OSINT/форензики:
- Наиболее надёжный метод без эталонного хэша — сопоставление атрибутов $MFT (SI vs FN) и анализ `docProps/core.xml` внутри OOXML-контейнера.
- Для баз данных (SQLite/MySQL) — проверка WAL-журнала (Write-Ahead Log) — если размер журнала >0 при закрытой БД — были изменения после последнего сохранения (CHECKPOINT).