Возникла одна идея. Для ее реализации требуется дать системе сигнал о том, что некий файл был изменен. Предполагается, что к файлу нет доступа ни на запись, ни на чтение(он зашифрован, заблокирован, нет прав и прочая). Я пытался брутфорсить google по словарю: file, notify, notification, "сообщения windows", filenotifychange и так далее. У Рихтера тоже не нашел ничего по сабжу. Если плохо искал, намекните, пожалуйста. И вообще, возможно ли такое сотворить из юзермода, с правми администратора? PS: С удивлением для себя выяснил, что ntfs потоки не совсем равноценны. "Основной" - главнее. То есть, при отсутствии прав на запись в файл к нему и дополнительный поток "прицепить" не удается. С точки зрения обывателя это логично. Но, мне показалось, что дополнительный поток ntfs должен быть вполне самостоятельным объектом. Не угадал-с.
Функция notification была создана для удобства, в 2000-м ее по-моему не было. Соответственно если нужно фальшивое сообщение, то нужно просто смоделировать - инжект, хук и т.п. Не думаю, чтобы были какие-то сложности. т.к. функция не критична в плане безопасности.
В справочнике Р.Саймона по Win 200 API ее на самом деле нет. В MSDN я ее тоже не нашел. Что за загадочная функция? 1) Вообще, задачи защитить файл от изменений не стоИт. Требуется обмануть (в частном случае) виндовую "Службу восстановления системы", заставив ее создать копию файла в точке восстановления. Насколько я понял, она это делает , если файл был изменен. 2) Интересует также общий случай. (сабж)
SHChangeNotify(SHCNE_UPDATEITEM, SHCNF_PATH, FilePath, NULL); Сработает для тех, кто подписался на события с помощью SHChangeNotifyRegister.
Насколько я понял, служба восстановления системы не подписана на указанные события. Вероятно, без ковыряния ядерных структур тут не обойтись. А там и без этого изврата можно обойтись. Халявы не вышло В любом случае, спасибо.
Если быть точным, то не служба, а winlogon.exe Нет никаких ограничений на использование этого API из обычного процесса.
Делал так: Код (Text): invoke SHChangeNotify,SHCNE_DELETE,SHCNF_PATH, addr f,0 invoke GetLastError invoke dwtoa, eax, addr TempBuff Каспер сказал, что это страшный сцуко zbot.gen Кроме того, имеем ERROR_INVALID_HANDLE
Хех, Касперу почему-то не доставляет отсутствие ExitProcess. Результат пока таков: После SHCNE_DELETE подопытный файл перестает отображаться в окне проводника, пока не нажмешь F5. Интересный эффект. Но, в ресторы файл попадает только тогда, когда он был изменен, а не удален, поменял атрибуты и проч. Здесь http://msdn.microsoft.com/en-us/library/bb762118(VS.85).aspx подходящего сообщения я что-то не нашел.
В том и дело, SHCNE_UPDATEITEM пробовал, не срабатывает. SHCNE_ATTRIBUTES пробовал тоже, на всякий случай. Хотя, даже если менять атрибуты через проводник - не срабатывает. Хотя, судя по реакции на SHCNE_DELETE - должно работать? Меня смущает SHChangeNotify, которую я использую и FindFirstChangeNotification. Так и должно быть?
Похоже, смущало правильно. Сделал так, что одна программа регистрируется получателем уведомлений ( FindFirstChangeNotification, WaitForSingleObject), другая посылает уведомления через SHChangeNotify. В итоге - ноль реакции. Если изменяю файл на самом деле, реакция есть. Сейчас вот дочитаю msdn...
SHChangeNotify работает на уровне shell'a. Может ловить не только файлы но и любые shell items Ловится через SHChangeNotifyRegister FindFirstChangeNotification работает на уровне файловой системы и ловит только файлы/директории. Ловится через Wait функции. Перекрестно эти фунуции не работают. Т.е FindFirstChangeNotification не поймает SHChangeNotify
