Привет всем!

Подскажите, пожалуйста. Я сделал перехват winapi функции ReadFile и нужно занести файл, который читался этой функцией в ОП.
Какой метод будет самым быстрым? Проецирование или виртуальная память? 

И ещё, после того как я записал файл в память, мне нужно при следующем перехвате ReadFile передать указатель на мой файл в ОП,
просто подменив HANDLE у ReadFile... как получить этот HANDLE у файла в ОП?

Или все же проецирование использовать?? Я уже запутался, помогите...

Это сообщение отредактировал(а) freezeman - 27.3.2012, 20:04

Честно, несколько раз перечитывал и не понял что нужно. Выдохни и опиши что ты хочешь хочешь сделать и что хукаешь (импорт или dll). Насколько я понял подмену чтения файла, если так, то открывай файл который будешь подсовывать, как открывать зависит от размера, если несколько килло то нет смысла мапить и прописывай HANDLE своего файла, указатель трогать незачем, буфер уже выделен (или нужно?), а так, проще и правильнее (хуки зло) хукнуть CreateFile.

У меня перехватывается функция ReadFile, я набираю статистику по перехвату/обращению и наиболее часто используемые файлы хочу поместить в ОП.
Затем при следующем перехвате, если я определю, что файл уже в ОП, то в перехваченную функцию ReadFile нужно как-то передать "указатель" на этот же файл, но в ОП.

Вопроса в общем 2: как лучше заносить файл в ОП и как получить HANDLE этого файла в ОП (чтобы просто подставить в перехваченную ReadFile и все) или можно как-то другим методом это реализовать?

Решение в лоб - Мапить файл и из проекции заполнять буфер (указатель) размер сколько читать передается. ReadFile не трогать. 

Спасибо за совет, проверю его завтра..)

Добавлено через 6 минут и 44 секунды

Но думаю, что это не очень хорошее решение, желательно каким-нибудь образом HANDLE передать в ReadFIle... Если я просто заполню буфер тупо по параметрам вызова ReadFile, то вернуть системе этот ReadFile не получится без проблем...

Подскажите, please!!))

Если я просто заполню буфер тупо по параметрам вызова ReadFile, то вернуть системе этот ReadFile не получится без проблем...
Какие еще проблемы?

После перехвата функции ReadFile нужно вернуть её системе, модифицированную или нет, а если я просто заполню буфер, то что указывать в указателе на файл (первый параметр - HANDLE), NULL?

в данном случае, совсем не обязательно, можно просто вернуть TRUE

Ок, а подскажите ещё, пожалуйста, как этот буфер заполнить...

Например успешно промапил файл и считал то return true если нет,то return false. Примеры работы с проекциями с мотри в MSDN или в гугле - Чтение фала + FileMapping, примеров овер 9000 на всех языках.

это зависит от твоей конкретной реализации свопа,

если перехватывать CreateFile и в нем создавать объект мепирования (CreateFileMapping), как предлагает Akira,
то дескриптор этого маппинга и нужно вернуть из CreateFile,

в таком случае, на ReadFile нужно вызвать MapViewOfFile со смещением и размером, пришедшими из ReadFile,
MapViewOfFile вернет указатель на исходный буфер,

вот данные из этого буфера и нужно перекинуть в буфер, пришедший в ReadFile и вернуть TRUE,
конечно, если MapViewOfFile вернет NULL, ReadFile должен вернуть FALSE, соответственно

только на CloseHandle, нужно соответственно закрыть дескриптор исходного файла

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

Понятно, а если так реализовать:
у меня набирается статистика по обращениям к файлам, затем по алгоритму выбираются файлы, которые нужно поместить в ОП,
а после очередного перехвата ReadFile, если этот файл, к которому идет обращение функцией ReadFile, занесен в ОП, то считать его из ОП.
Это было общее описание задачи.

Если я на этапе копирования файла в ОП, сделаю проекцию и назову её по имени файла+какие-нибудь доп. атрибуты, а когда произойдет след перехват я проверю сущ ли такая проекция, если да, то 
заполню буфер как вы описали, если нет просто верну ReadFile до перехвата...

И ещё при проекции скорость чтения из неё так как из ОП или как с жесткого диска??

Можно и из ОП раз так хочется (только где столько памяти взять?  ) из одного буфера будешь передавать в другой буфер, а ReadFile не нужно трогать, оно там и нах не нужно. Потеря из за проекции не значительны и на фоне чтения из диска можно и не думать об этом. Плюс в проекции это то что ты можешь открывать и читать файлы в несколько гигов, а вот такие держать в памяти не вариант. Я бы выбрал проекцию.

значит нужно завести список таких файлов и на ReadFile искать эти данные в нем,

вроде же все очевидно, можно сделать так:
1. перехватываем CreateFile:
 - проходим по списку files, ищем по имени запись файла
 - нашли - возвращаем его индекс (или его уникальный номер)
 - не нашли - создали такую запись, открыли файл и вернули индекс новой записи(или ее уникальный номер)
2. перехватываем ReadFile:
 - переходим в списке files к записи файла (в первом параметре, соответственно будет индекс или уникальный номер этой записи)
 - не нашли - передали параметр в реальную ReadFile
 - нашли - расчитываем его статистику, сохраняем ее результаты в записи
 - если требуется отобразить файл в память, создаем отображение, сохраняем дескриптор в записи
 - если требуется прочитать отображение, делаем это по схеме постом выше, используя дескриптор отображения, он же уже находится в записи
 - если требуется прочитать файл напрямую, делаем это, передав параметры в реальную ReadFile, дескриптор файла ведь там же
3. перехватываем CloseHandle:
 - переходим в списке files к записи файла (в первом параметре, соответственно будет индекс или уникальный номер этой записи)
 - не нашли - передали параметр в реальную CloseHandle
 - нашли - закрыли открытые дескрипторы, удалили запись


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

если при этом будет слишком много мелких файлов, любая проекция будет невыгодна, независимо от того медленная она или быстрая