Paging I/O – шифрование
От: Storozh Россия  
Дата: 31.01.03 22:09
Оценка:
Как следует из DDK, данные при страничном вводе-выводе описываются MDL Irp->MdlAddress. Проблема со способом модификации таких данных из драйвера фильтра FS – следует ли

1. использовать MmGetMdlVirtualAddress для определения VA и
2. копировать их кол-вом MmGetMdlByteCount в отдельный буфер,
3. шифровать/дешифровать,
4. обновить Irp->MdlAddress.

Подойдет ли такой способ, и нет каких-нибудь подводных камней в такой реализации?
Re: Paging I/O – шифрование
От: Valerio Россия linkedin.com/in/boronin
Дата: 01.02.03 11:02
Оценка:
S>Как следует из DDK, данные при страничном вводе-выводе описываются MDL Irp->MdlAddress. Проблема со способом модификации таких данных из драйвера фильтра FS – следует ли

S>1. использовать MmGetMdlVirtualAddress для определения VA и

S>2. копировать их кол-вом MmGetMdlByteCount в отдельный буфер,
S>3. шифровать/дешифровать,
S>4. обновить Irp->MdlAddress.
направление выбрано правильно ,
но способ никуда не годится (пока)

поехали разбирать случай с
if (NULL == Irp->MdlAddress)


1. Зачем тебе VA from MmGetMdlVirtualAddress Тебе надо
PCHAR   buffer = MmGetSystemAddressForMdl(mdl);

т.к. ты не всегда в контексте того же пользовательского процесса и эти адреса не всегда будут валидны
2. не надо если уже есть MDL, зачем его копировать туда-сюда бестолку? это работа для системы...
3. нужно делать прямо с buffer
4. не надо

S>Подойдет ли такой способ, и нет каких-нибудь подводных камней в такой реализации?

конечно есть
... << RSDN@Home 1.0 beta 5 >>
Valery A. Boronin, RSDN Team, linkedin.com\in\boronin
R&D Mgmt & Security. AppSec & SDL. Data Protection and Systems Programming. FDE, DLP, Incident Management. Windows Filesystems and Drivers.
Re: Paging I/O – шифрование
От: Valerio Россия linkedin.com/in/boronin
Дата: 01.02.03 11:32
Оценка: 3 (1)
мое первое сообщение не совсем верное (я его пробовал удалить, но я не модер еще)

не совсем верное оно, т.к. не было указано для чего нужно, для чтения или записи?
мой первый ответ был для чтения if (NULL != Irp->MdlAddress):

1. Зачем тебе VA from MmGetMdlVirtualAddress Тебе надо
PCHAR   buffer = MmGetSystemAddressForMdl(mdl);

т.к. ты не всегда в контексте того же пользовательского процесса и эти адреса не всегда будут валидны
2. не надо если уже есть MDL, зачем его копировать туда-сюда бестолку? это работа для системы...
3. нужно делать прямо с buffer
4. не надо

Это сработает, т.к. тебе можно расшифровать пользовательский буфер прямо в памяти после того как чтение оригинального пакета успешно пройдет. При записи же любое приложение ИМХО сильно удивится если после WriteFile буфер с данными у приложения изменится волшебным образом

ответ на случай с записью: действительно, предложенный способ более близок, но все равно есть моменты которые в корне не верны, вроде пункта 1 выше — общий момент.

алгоритм для модификации IRP_MJ_WRITE:
1. свой MDL (IoAllocateMdl/MmProbeAndLockPage)
2. свой IRP (roll your own Irp, IoAllocateIrp) с MDL из 1
3. модифицируем 2 как хочется
4. IoCallDriver с пакетом из 2
5. ждем пока 3 не отработает
6. освобождаем ресурсы 2 и 1
7. выставляем статус оригинального пакета соответственно 4

S>Подойдет ли такой способ, и нет каких-нибудь подводных камней в такой реализации?

время покажет
... << RSDN@Home 1.0 beta 5 >>
Valery A. Boronin, RSDN Team, linkedin.com\in\boronin
R&D Mgmt & Security. AppSec & SDL. Data Protection and Systems Programming. FDE, DLP, Incident Management. Windows Filesystems and Drivers.
Re[2]: Paging I/O – шифрование
От: Storozh Россия  
Дата: 01.02.03 13:13
Оценка:
Здравствуйте, Valerio, Вы писали:

S>>Подойдет ли такой способ, и нет каких-нибудь подводных камней в такой реализации?

V>время покажет

Буду пробовать — тут еще вылазит проблема с длиной файлов. В любом случае спасибо.
Re[3]: Paging I/O – шифрование
От: Valerio Россия linkedin.com/in/boronin
Дата: 01.02.03 16:06
Оценка: 3 (1)
S>Буду пробовать — тут еще вылазит проблема с длиной файлов. В любом случае спасибо.

проблемы с записью файлов, не кратных PAGE_SIZE или блокам в твоем алгоритме?

ну это уж конечно тебе тоже нужно самому отслеживать, не забывать
таких штучек тут очень много

т.к. ты про это не писал, а вопрос был задан "как изменить запрос размером в MDL buffer size bytes", то и ответ этого не учитывал

понятно, что указанный мной выше алгоритм можно применять для генерации произволного числа своих подзапросов (в т.ч. и разной длины) на чтение и\или запись или что угодно в ответ на "прилет" пакета

попариться придется короче очень сильно, куда без этого
... << RSDN@Home 1.0 beta 5 >>
Valery A. Boronin, RSDN Team, linkedin.com\in\boronin
R&D Mgmt & Security. AppSec & SDL. Data Protection and Systems Programming. FDE, DLP, Incident Management. Windows Filesystems and Drivers.
Re[2]: Paging I/O – шифрование
От: Storozh Россия  
Дата: 01.02.03 16:48
Оценка:
Здравствуйте, Valerio, Вы писали:

Интересно, справедливо ли все вышесказанное для noncashed i/o?
Re[3]: Paging I/O – шифрование
От: Valerio Россия linkedin.com/in/boronin
Дата: 02.02.03 07:54
Оценка:
S>Интересно, справедливо ли все вышесказанное для noncashed i/o?

несомненно

это справедливо даже и для всех остальных случаев, "работать-то будет, но такая фигня получится(с) анекдот"
... << RSDN@Home 1.0 beta 5 >>
Valery A. Boronin, RSDN Team, linkedin.com\in\boronin
R&D Mgmt & Security. AppSec & SDL. Data Protection and Systems Programming. FDE, DLP, Incident Management. Windows Filesystems and Drivers.
Re[4]: Paging I/O – шифрование
От: Storozh Россия  
Дата: 11.02.03 18:04
Оценка:
Здравствуйте, Valerio, Вы писали:

V>проблемы с записью файлов, не кратных PAGE_SIZE или блокам в твоем алгоритме?

V>попариться придется короче очень сильно, куда без этого

Спасибо! С MMF и всем остальным я разобрался но, как и предполагалось, вылезла проблема с длиной файлов и вот какого рода:

Шифрование реализовано блоками по 8 байт, и, следовательно, если размер файла не кратен 8, то в последнем блоке может получиться до 7 байт ерунды. Для того чтобы при открытии файла восстановить его оригинальный размер, в конце шифрованного файла отведено 8 байт под хранение первоначальной длины.

При поступлении IRP_MJ_QUERY_INFORMATION я читаю оригинальную длину файла и

в поцедуре завершения обработки ввода-вывода пытаюсь усечь до нее размер файла


((PFILE_STANDARD_INFORMATION)(Irp->AssociatedIrp.SystemBuffer))->EndOfFile.LowPart = opened_file->length;


В общем-то это работает для большинства приложений, но тот же нотепад вываливается с сообщением о нехватке памяти. Причем, если я не усекаю,а увеличиваю размер файла, то нотепад выполняется нормально, отображая в конце естественно до 7 байт ерунды и 8 байт размера.
В чем тут дело и как это поправить?

Помогите, пожалуйста, советом
Re[5]: Paging I/O – шифрование
От: Valerio Россия linkedin.com/in/boronin
Дата: 12.02.03 06:32
Оценка: 3 (1)
СТОРож, времени совершенно на РСДН сейчас нет, проверяю его пару раз в день и отвечать подробно мне тяжело.

S>В общем-то это работает для большинства приложений, но тот же нотепад вываливается с сообщением о нехватке памяти. Причем, если я не усекаю,а увеличиваю размер файла, то нотепад выполняется нормально, отображая в конце естественно до 7 байт ерунды и 8 байт размера.


Коротко отвечу пока так: изменением real files size ты нажил себе кучу проблем
Могу только сказать, что real file size vs exposed is one of most complicated tasks in our area, так что лучше пока этого не делать, если еще базовый алгоритм не функционирует надежно (по ответу это ясно видно).

S>При поступлении IRP_MJ_QUERY_INFORMATION я читаю оригинальную длину файла и

S>в поцедуре завершения обработки ввода-вывода пытаюсь усечь до нее размер файла

Ты задел только надводную часть айсберга
Вообще говоря, у меня был проект где это было реализовано, но ребята из OSR недавно проконсультировали меня и из их слов следует, что я сам не намного ушел под воду — проблемы с интеграцией с Mm и Сс в частных случаях не решаются со 100% гарантией по идеологическим причинам (design NT), причем ты прав, если файл не уменьшается + своя шапка в конце, все выглядит стабильно. Стоит тебе переместить твои 8 байт в начало, как проблем наживешь на порядок круче и быстрее (OSR info, сам не пробовал, но верю почему-то )

Совет такой:
1) размер файла не меняй
2) посмотри сюда (здесь для чтения, но суть для записи та же):
            //
            //decrypt data, breaking if we exceed ValiDataLength as a well known 
            //FSD conformance rule.
            //
            for ( i = 0; i < MmGetMdlByteCount(mdl); i++)
            {
                if(Fcb && ( Fcb->ValidDataLength.LowPart - 1 ) < (offset.LowPart + curLen))
                    break;
                //
                //decrypt
                //
                //
                buffer[i] ^= 0x5A;
                curLen++;
            }


объяснять некогда, да думаю, ты и сам разберешься, ключевое слово произнесено

еще можно пробовать вот как (при записи полезно)
    //use in case of read/write
    if(isPagingIo && offset.QuadPart+len > Fcb->FileSize.QuadPart)
    {
        len = (ULONG)( Fcb->FileSize.QuadPart - offset.QuadPart );
    }


Удачи!
... << RSDN@Home 1.0 beta 6 >>
Valery A. Boronin, RSDN Team, linkedin.com\in\boronin
R&D Mgmt & Security. AppSec & SDL. Data Protection and Systems Programming. FDE, DLP, Incident Management. Windows Filesystems and Drivers.
Re[6]: Paging I/O – шифрование
От: Storozh Россия  
Дата: 13.02.03 17:09
Оценка:
Здравствуйте, Valerio, Вы писали:

Valerio, огромное спасибо за обстоятельные ответы и внимание к моим трудностям, тем более, что

V>СТОРож, времени совершенно на РСДН сейчас нет, проверяю его пару раз в день и отвечать подробно мне тяжело.


Спасибо!


V>Коротко отвечу пока так: изменением real files size ты нажил себе кучу проблем


Отлично, откладываю длину в сторону, раз это такая засада, тем более, что есть хорошие алгоритмы шифрования байт-в-байт, которые, собственно, ее(длину) не меняют.

Теперь встал другой вопрос (честно говоря, не знаю сложный или нет) Суть в следующем:

Драйвер экспортирует функции шифрования из DLL, переключаясь между разными DLL по команде из GUI.

Так вот, если я открываю шифрованный файл, используя DLL1, а затем DLL2, то результат получается один, так как, я предполагаю, в памяти сохраняется валидная копия данных, расшифрованных DLL1.

С записью вообще ситуация непредсказуемая, потому как в момент записи модифицированных страниц на диск, может быть активна любая DLL.

Какими средствами это поправляется? Если не очень сложно, то подскажите в каком направлении думать. Понятно, что надо принудительно делать нужные страницы невалидными, предварительно сбрасывая их на диск. Но КАК?

Посоветуйте, пожалуйста, чего делать
Re[7]: Paging I/O – шифрование
От: Valerio Россия linkedin.com/in/boronin
Дата: 15.02.03 12:46
Оценка: 3 (1)
S>Посоветуйте, пожалуйста, чего делать

правильно, нужно иногда сбрасывать кэш на диск, предпочтительно в момент открытия файла, для которого сменился способ обработки

вот в помощь, поиграйтесь :
MmFlushImageSection( fileObject->SectionObjectPointer, MmFlushForWrite );
CcFlushCache( fileObject->SectionObjectPointer, NULL, 0, &ioStatus);
CcPurgeCacheSection( fileObject->SectionObjectPointer, NULL, 0, FALSE );


обратите внимание что это shared system resources и нужно будет в Fcb захватить пару ERESOURCES
... << RSDN@Home 1.0 beta 6 >>
Valery A. Boronin, RSDN Team, linkedin.com\in\boronin
R&D Mgmt & Security. AppSec & SDL. Data Protection and Systems Programming. FDE, DLP, Incident Management. Windows Filesystems and Drivers.
Re[8]: Paging I/O – шифрование
От: Storozh Россия  
Дата: 20.02.03 16:39
Оценка: 12 (1)
Здравствуйте, Valerio, Вы писали:

V>вот в помощь, поиграйтесь :

V>
V>MmFlushImageSection( fileObject->SectionObjectPointer, MmFlushForWrite );
V>CcFlushCache( fileObject->SectionObjectPointer, NULL, 0, &ioStatus);
V>CcPurgeCacheSection( fileObject->SectionObjectPointer, NULL, 0, FALSE );
V>


Спасибо, наигрался!

Ситуация следующая:
Эффект виден лишь от применения CcPurgeCacheSection — здесь действительно все хорошо (с чтением).
С чтением вообще все хорошо


А вот с записью история интересная:

Эксперимент №1:

1. Включаю кодирование -> Создаю в секретном каталоге документ WordPad -> Пишу текст -> Сохраняю
2. Откл. кодирование -> Открываю с помощью WinHex (16-ричный редактор) и выясняется, что все зашифровано,
кроме огрызка последней страницы. Ну то есть, если файл 5000 байт, то 4096 зашифрованы, а остальные нет.

Эксперимент №2:

1. Включаю кодирование -> Открываю зашифрованный архив WinZip'ом -> Изменяю его содежимое -> Cохраняю
2. Откл. кодирование -> А он, собака, и не зашифрованный совсем! все 50КБ


Сразу оговорюсь, что скорее всего это НЕ проблемы, связанные непосредственно с реализацией шифрования неких
объемов данных, т.к. с большинством приложений все выглядит хорошо; так, с нормальным Word'ом проблем не
возникает, как впрочем и с WinRar.

Было у меня подозрение, что это связано с write-back cache with lazy write. Вроде того, что данные, записываемые в файлы, сначала хранятся в страницах кэша в памяти, а потом по мере накопления записываются на диск — возможно как раз в тот момент, когда кодирование выключено. По крайней мере это единственное, что приходит на ум.

Сначала я думал, что эти проблемы можно решить своевреммено сбрасывая кэш, но
MmFlush И СсFlush, хотя и отрабатывают успешно, результатов не дают (странно, но после того как я их вызываю не запускается Paging I/O. Ведь по идее вызов этих функций должен повлечь I/O operations and hence reenter the FSD.)

Я пошел дальше — выставил MmModifiedPageLifeInSeconds равным 5 сек. вместо 300 по умолчанию, так чтоб
модифицированные страницы жили в памяти не более 5 сек. Не помогло.

Так вот, каким образом на диске появляются открытые данные? Ведь выбранное направление (фильтр на Paging и
Non-Cached I/O
) должно покрывать все возможные способы модификации данных на диске! Каким образом должен
работать WordPad и WinZip, чтобы получить в итоге имеющиеся результаты?

Заранее спасибо!
Re[9]: Paging I/O – шифрование
От: Valerio Россия linkedin.com/in/boronin
Дата: 20.02.03 18:38
Оценка: 12 (1)
зашел на минуту писать пока некогда
на понял сразу из Вашего текста, просто уточню на всякий случай:
указанные ф-и рассчитаны на применение только в IRP_MJ_CREATE/CLEANUP/CLOSE

этого должно быть достаточно вполне для любой деятельности (я использую в CREATE когда скажем just encrypted файл должен быть показан as is, i.e. я должен сбросить кэш на диск и отключить свою обработку на лету для этого файла. Или наоборот, включить для открытого обычным образом до этого)

всякие указанные вещи вроде ссылок на lazy writer тут к делу никак не относятся, не грейте этим голову. Вам нужно всего лишь правильно обработать SectionObjectPointer и торчащие из него Data и Image Section Objects

вообще говоря, даже из Create обработчика все эти вещи довольно небезопасны, в случае нескольких фильтров в стеке устройств. Рекомендую учитывать такое условие при захвате ресурсов:
            if(Fcb && IoGetTopLevelIrp() == NULL)


до новых встреч! я ушел
... << RSDN@Home 1.0 beta 6 >>
Valery A. Boronin, RSDN Team, linkedin.com\in\boronin
R&D Mgmt & Security. AppSec & SDL. Data Protection and Systems Programming. FDE, DLP, Incident Management. Windows Filesystems and Drivers.
Re[10]: Paging I/O – шифрование
От: Storozh Россия  
Дата: 27.02.03 18:26
Оценка:
Здравствуйте, Valerio, Вы писали:


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


V>указанные ф-и рассчитаны на применение только в IRP_MJ_CREATE/CLEANUP/CLOSE


1. Почему после вызова CcFlushCacheSection — хотя и возвращается STATUS_SUCCESS — не следует Paging I/O? (По крайней мере ни filemon, ни мой DbgPrint его не замечают.) Вроде как CcFlush для того и существует, чтобы сбрасывать модифицированные страницы на диск

2. А вот это просто непостижимая для меня головоломка: Допустим есть зашифрованный zip-архив. Открываю его в течении сессии шифрования WinZip'ом, модифицирую, и на диске появляются открытые данные (т.е. он саморасшифровался, когда его никто не просил). Такая же ерунда, когда я модифицирую картинку в ACDSee С WinRar и большинством других приложений таких проблем нет.

КАКИМ ОБРАЗОМ появляются открытые данные в секретном каталоге, если все попытки туда писать я перехватываю, и шифрую весь Paging & Non-Cached I/O???

Может есть какие-нибудь идеи? Поделитесь, пожалуйста.
Re[11]: Paging I/O – шифрование
От: Storozh Россия  
Дата: 03.03.03 17:27
Оценка:
S>КАКИМ ОБРАЗОМ появляются открытые данные в секретном каталоге, если все попытки туда писать я перехватываю, и шифрую весь Paging & Non-Cached I/O???

Из хелпа к Filemon'у:

On Windows NT/2K there is a special file name, DASD (Direct Access Storage Device), that is used to indicate file I/O that is bypassing file system structures and directly effecting data on the logical partition

Как выясняется проблема в следующем:

WinZip использует зтот так называемый DASD (Direct Access Storage Device) для записи на диск. Создается stream file object, для которого я не могу вычислить полный путь (мне важен каталог), и соответственно, принять решение шифровать или нет.

В Filemon'e это выклядит так:


1. IRP_WRITE_OPERATION:
winzip32.exe:157     IRP_MJ_WRITE   D:\_XOR\WZA.tmp  SUCCESS   Offset: 0 Length: 20641

..
2. IRP_PAGING_IO:
winzip32.exe:157     IRP_MJ_WRITE*  D: DASD          SUCCESS   Offset: 0 Length: 24576






Так вот вопрос: как мне идентифицировать случай со страничной записью в нужный мне файл. Возможно в качестве ключа я должен использовать FileObject->FsContext или FileObject->SectionObjectPointer? Я имею в виду, что после прилета странного пакета "D:DASD" нужно сравнить FsContext и SectionObjectPointer с аналогичными элементами отслеженного ранее "D:\_XOR\WZA.tmp". Всегда ли это корректно (если вообще корректно)?

И не может ли мне помочь FILE_STREAM_INFORMATION ?

Подскажите, пожалуйста, чего делать. Заранее спасибо
Re[11]: Re[11]: Paging I/O – шифрование
От: Valerio Россия linkedin.com/in/boronin
Дата: 10.03.03 14:59
Оценка:
V>>указанные ф-и рассчитаны на применение только в IRP_MJ_CREATE/CLEANUP/CLOSE
кстати тут я был не совсем прав, можно применить и в других местах, но все равно есть масса ограничений

S>1. Почему после вызова CcFlushCacheSection — хотя и возвращается STATUS_SUCCESS — не следует Paging I/O? (По крайней мере ни filemon, ни мой DbgPrint его не замечают.) Вроде как CcFlush для того и существует, чтобы сбрасывать модифицированные страницы на диск

объяснение простое: ИМ ВИДНЕЕ
ты свое дело сделал — fileflushbuffers сказал — изменения пойдут на диск, через всю цепочку фильтров и FSD — в каждом из них свое поведение и возможно политика кэширования-оптимизации

S>2. А вот это просто непостижимая для меня головоломка: Допустим есть зашифрованный zip-архив. Открываю его в течении сессии шифрования WinZip'ом, модифицирую, и на диске появляются открытые данные (т.е. он саморасшифровался, когда его никто не просил). Такая же ерунда, когда я модифицирую картинку в ACDSee С WinRar и большинством других приложений таких проблем нет.


надо смотреть файлмоном что там точно происходит — порядок вызовов и каких
потом у себя долго смотреть

может быть просто какие-то случаи мимо тебя проходят или ты своей логикой их отсек

похоже, ты вступил наконец на тропу настоящего геморроя — начинается маета с короткими именами, альтернативными потоками на NTFS и проблема открытия одного файла по разным именам и по несколько instances (я с pkzip25 в свое время напарился, эти архиваторы часто бывают хорошим тестом)

S>КАКИМ ОБРАЗОМ появляются открытые данные в секретном каталоге, если все попытки туда писать я перехватываю, и шифрую весь Paging & Non-Cached I/O???


вероятно, не все — см выше
подскажу еще способы которые часто игнорируются — открытие файла по file ID/object ID, хотя это вряд ли твой случай. тут скорее всего проблемы из серии описанных выше — большая проблема с подсчетом ссылок на открытый файл — когда его открывают более одного экземпляра, да еще и по-разному

плюс тут конечно и система свой фунт изюма — оптимизаций добавляет

S>Может есть какие-нибудь идеи? Поделитесь, пожалуйста.

всегда рад
... << RSDN@Home 1.0 beta 6a >>
Valery A. Boronin, RSDN Team, linkedin.com\in\boronin
R&D Mgmt & Security. AppSec & SDL. Data Protection and Systems Programming. FDE, DLP, Incident Management. Windows Filesystems and Drivers.
Re[12]: Re[12]: Paging I/O – шифрование
От: Valerio Россия linkedin.com/in/boronin
Дата: 10.03.03 15:03
Оценка: 6 (1)
S>Как выясняется проблема в следующем:

S> WinZip использует зтот так называемый DASD (Direct Access Storage Device) для записи на диск. Создается stream file object, для которого я не могу вычислить полный путь (мне важен каталог), и соответственно, принять решение шифровать или нет.


ну как я и писал в предыдущем посте — начался гемор со стримами
однако смею возразить, I'm sure, DASD doesn't matter for you in concern WinZip activity, just pass it down

ДУМАЮ, следует немного больше учесть при записи-чтении, есть еще IRP_MN_Xxx случаи + сеть:

    //
    //if the request is paging(or just non-buffered),
    //encrypt the data, allocate the Irp and call the FSD.
    //Alternatively we could replace mdl(or user buffer, encrypt it, and pass down to the FSD)
    //via the framework.
    //
    if( shouldProcess && !FlagOn( MinorFunction, IRP_MN_MDL)  && 
        !FlagOn(MinorFunction, IRP_MN_COMPLETE)  && ( isPagingIo || isNonBufferedIo))
    {}

    //
    //Checking fileObject->ReadAccess for network non-paging IO, we follow LanmanRedirector
    //caching heuristics. It caches read and read/write access enabled files. Other cases
    //(namely writeonly files)do not lead to paging Io write requests with LanmanRedirector.
    //Read paging operations are not affected by these heurustics
    //Note also that these default caching heuristics can be changed 
    //via rdr registry Parameters values.
    //In your production implementation you should read these registry values and behave 
    //accordingly.
    //See the MS KB article "How to Disable Network Redirector File Caching"
    //
    if (shouldProcess && 
        !FlagOn( MinorFunction, IRP_MN_MDL)  && !FlagOn(MinorFunction, IRP_MN_COMPLETE)  &&
        ( isRemoteFile && 
            ( !fileObject->ReadAccess  ||
                fileObject->ReadAccess && ( fileObject->PrivateCacheMap == NULL)
            ) 
        )  
    )


S> Так вот вопрос: как мне идентифицировать случай со страничной записью в нужный мне файл. Возможно в качестве ключа я должен использовать FileObject->FsContext или FileObject->SectionObjectPointer? Я имею в виду, что после прилета странного пакета "D:DASD" нужно сравнить FsContext и SectionObjectPointer с аналогичными элементами отслеженного ранее "D:\_XOR\WZA.tmp". Всегда ли это корректно (если вообще корректно)?

S>
S> И не может ли мне помочь FILE_STREAM_INFORMATION ?
смотря что от него хочется

S>Подскажите, пожалуйста, чего делать. Заранее спасибо


короче говоря так: ключ ДОЛЖЕН быть Fcb и уж никак не file object!!!
ибо как я писал в пред посте, много экземпляров файла могут быть, но у них у всех ОДИНАКОВЫЙ Fcb — верно для локальных файловых систем по-крайней мере
... << RSDN@Home 1.0 beta 6a >>
Valery A. Boronin, RSDN Team, linkedin.com\in\boronin
R&D Mgmt & Security. AppSec & SDL. Data Protection and Systems Programming. FDE, DLP, Incident Management. Windows Filesystems and Drivers.
Re[13]: Re[12]: Paging I/O – шифрование
От: Storozh Россия  
Дата: 09.04.03 19:12
Оценка:
Приветствую!

Ну кто бы мог подумать, что поступить в аспирантуру это такой гемор (в наше-то время! ). Целый месяц пришлось убить на решение этого вопроса, а потом и на создание приличного GUI. Вот, наконец-то, дошли руки и до драйвера.

V>ну как я и писал в предыдущем посте — начался гемор со стримами

V>однако смею возразить, I'm sure, DASD doesn't matter for you in concern WinZip activity, just pass it down

После доработок, описанных в предыдущем моем посте, работа драйвера меня устраивает и все выглядит довольно стабильно. Через эти доработки, кстати, и удалось избавиться от незашифрованных "огрызков" Wordpad'а и решить проблему с WinZip'ом. Да, сразу оговорюсь, что я сеть еще не трогал (может потому и стабильно, что не трогал ). Вообще говоря, я только зондирую вопрос внедрения шифрования в чтение и запись разделяемых ресурсов. Это вопрос недалекого, но все-таки будущего, и, думаю, будет правильнее вынести его в отдельную тему.

Сейчас голова у меня болит о другом: Необходимо подключать БЛОЧНЫЙ алгоритм шифрования, что повлечет за собой увеличение длины файла за счет хранения real file size, а это, понятно дело, гемор почище, чем со стримами . В свое время я пытался подступиться к нему, но ничего путного не вышло. Так вот, что необходимо учесть, кроме как в поцедуре завершения обработки IRP_MJ_QUERY_INFORMATION усечь до real_file_size размер файла? Пробовал еще CcFileSizes, но все не то. Если есть идеи — то заранее спасибо ,


>ДУМАЮ, следует немного больше учесть при записи-чтении, есть еще IRP_MN_Xxx случаи + сеть:


Интересно, откуда этот код? Поделитесь, пожалуйста, линками на ресурсы по теме

V>короче говоря так: ключ ДОЛЖЕН быть Fcb и уж никак не file object!!!


Я использую FileObject->FsContext (это ведь и есть Fcb?) в качестве ключа.
Re[14]: Re[12]: Paging I/O – шифрование
От: Valerio Россия linkedin.com/in/boronin
Дата: 10.04.03 13:31
Оценка:
S>Ну кто бы мог подумать, что поступить в аспирантуру это такой гемор (в наше-то время! ). Целый месяц пришлось убить на решение этого вопроса, а потом и на создание приличного GUI. Вот, наконец-то, дошли руки и до драйвера.
Поздравляю с поступлением?

V>>ну как я и писал в предыдущем посте — начался гемор со стримами

V>>однако смею возразить, I'm sure, DASD doesn't matter for you in concern WinZip activity, just pass it down

S>После доработок, описанных в предыдущем моем посте, работа драйвера меня устраивает и все выглядит довольно стабильно. Через эти доработки, кстати, и удалось избавиться от незашифрованных "огрызков" Wordpad'а и решить проблему с WinZip'ом. Да, сразу оговорюсь, что я сеть еще не трогал (может потому и стабильно, что не трогал ). Вообще говоря, я только зондирую вопрос внедрения шифрования в чтение и запись разделяемых ресурсов. Это вопрос недалекого, но все-таки будущего, и, думаю, будет правильнее вынести его в отдельную тему.

просто с сетью у Вас уже нет такой "легкой" концепции для использования, как Paging I/O.

S>Сейчас голова у меня болит о другом: Необходимо подключать БЛОЧНЫЙ алгоритм шифрования, что повлечет за собой увеличение длины файла за счет хранения real file size, а это, понятно дело, гемор почище, чем со стримами . В свое время я пытался подступиться к нему, но ничего путного не вышло. Так вот, что необходимо учесть, кроме как в поцедуре завершения обработки IRP_MJ_QUERY_INFORMATION усечь до real_file_size размер файла? Пробовал еще CcFileSizes, но все не то. Если есть идеи — то заранее спасибо ,

ИМХО блочный алгоритм не обязан приводить к увеличению длины файла.
можно шифровать блоками, а последний хвостик как-то по-другому шифровать
Опять же есть возможность использовать режим шифрования, позволяющий за счет производительности шифровать все серьезным алгоритмом но побайтно (если размер блока N, то имеем N проходов, чтобы получить вместо N байт 1 искомый байт, если правильно помню). Имеет смысл таким образом шифровать хвост?

Вообще говоря вот это точно можно отдельной темой выносить
Если же трудности Вас не пугают, готовьте много терпения и... ну Вы знаете что обычно нужно в нашем деле

S>

>>ДУМАЮ, следует немного больше учесть при записи-чтении, есть еще IRP_MN_Xxx случаи + сеть:
S>Интересно, откуда этот код? Поделитесь, пожалуйста, линками на ресурсы по теме
Код из моего рабочего проекта, линков нет, пишем сами

V>>короче говоря так: ключ ДОЛЖЕН быть Fcb и уж никак не file object!!!

S>Я использую FileObject->FsContext (это ведь и есть Fcb?) в качестве ключа.
Да, конечно Опять же актуально для локальных файлов точно (наличие и уникальность Fcb).
... << RSDN@Home 1.0 beta 6a >>
Valery A. Boronin, RSDN Team, linkedin.com\in\boronin
R&D Mgmt & Security. AppSec & SDL. Data Protection and Systems Programming. FDE, DLP, Incident Management. Windows Filesystems and Drivers.
Re[15]: Re[12]: Paging I/O – шифрование
От: Storozh Россия  
Дата: 11.04.03 11:51
Оценка:
Здравствуйте, Valerio, Вы писали:


V>Поздравляю с поступлением?


Ну да, поступил, спасибо


V>ИМХО блочный алгоритм не обязан приводить к увеличению длины файла.

V>можно шифровать блоками, а последний хвостик как-то по-другому шифровать
V>Опять же есть возможность использовать режим шифрования, позволяющий за счет производительности шифровать все серьезным алгоритмом но побайтно (если размер блока N, то имеем N проходов, чтобы получить вместо N байт 1 искомый байт, если правильно помню). Имеет смысл таким образом шифровать хвост?


Хорошая мысль! Только в таком исполнении этот подход вряд ли подойдет на уровне концепции разрабатываемой системы шифрования, которая предполагает использование любых внешних алгоритмов шифрования. Т.е., конечно, костыль-то вставить можно, только некрасиво.

Все же я попытался развить эту идею и в конце концов запихнул ее в эту самую концепцию.
В конечном варианте так:
1. Тело (массив кратный 8) файла шифруется блоками по 8 байт
2. Если есть N байт в хвосте, то последний блок формируется с учетом (8-N)байт предпоследнего блока, т.е. (8-N)байт предпоследнего блока будут зашифрованы дважды.

Может я и непонятно излагаю, но таким образом длина файла не меняется, что меня радует.
Тут проблемка с совсем маленькими файлами < 8, но и тут есть заплатка, так что вперед и с песнями.


Вопрос такой: каким образом при записи определять, что это и есть хвост?

Анализ fcb->FileSize, IrpSp->Parameters.Write.ByteOffset, IrpSp->Parameters.Write.Length?
Но тут грабли: fcb->FileSize при нескольких последовательных операциях страничной записи в файл меняется по крайней мере дважды. Например при сохранениии документа WordPad первые несколько операций записи проходят с одним
fcb->FileSize, а последние — с изменившимся. Посоветуйте, пожалуйста, способ однозначно идентифицировать, что происходит окончательная запись в окончательный хвост?


V>Код из моего рабочего проекта, линков нет, пишем сами


Мы тоже
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.