I need to check certificates (incl. catalog) on file objects that have already been through
IRP_MJ_CLEANUP. (like the ones you may get from a LoadImageNotify callback).
I can read them fine in kernel mode. However to check certificates I must make the content available in usermode. On top of that WinVerifyTrust() uses memory mapped file access internally
So I really need a filehandle:
Open again by name is unsafe.
Open again by FileId is not supported by FAT.
Copying everything into a temp-file is not elegant.
Can I somehow make the reopen trick work ?
(New CreateFile with blank filename and specify the FO as related file object ?).
Unfortunately all the functions that I could find need a *handle* to the related FO.
Rolling my own IRP_MJ_CREATE would take a PFILE_OBJECT instead but according to the archives this is not a recommended thing to do.
You cannot do a great deal with the file object after cleanup. I don’t
suppose that you can do anything in your cleanup processing ? (like squirrel
away any catalogue you happen to find?)
To make things worse all sorts of things may be happening after cleanup and
if you have an open handle you get in the way of things.
What exactly is you (file level) requirement? Just read some data from the
file? You might get away with a paging read. What are the operations that
will trigger this happening?
Open again by name is unsafe.
Absolutely, but you might be able to code around it - on a local disk.
That way you plug the rename window with a busy loop. The check of
FsContext is a shorthand way of seeing whether the underlying FSD believes
that the stream is really the same thing. This doesn’t work reproducibly
over the network.