Is that documentation correct (about there not being import libraries??)
It states that the function has no associated import library .. what about
wintrust.lib?
When I invoke CryptCATGetMemberInfo on one of the Tag entries
in a cat file (NT5.cat), the function succeeds, but the CRYPTCATMEMBER.pwszFileName
returns NULL (but most other members are valid).
Why is this?
- Mitch
Any time I look at crypto documentation, I assume that the documentation is
incorrect unless it matches what I see in reality. I suspect that if the
function is exported enough that LoadLibrary / GetProcAddress work, it's
exported through the library:
C:\WINDOWS>dumpbin /exports "d:\Program Files\Microsoft Platform
SDK\Lib\WinTrust.Lib" | findstr /i cryptcatopen
_CryptCATOpen@20
>When I invoke CryptCATGetMemberInfo on one of the Tag entries
>in a cat file (NT5.cat), the function succeeds, but the
> CRYPTCATMEMBER.pwszFileName
>returns NULL (but most other members are valid).
>Why is this?
I'm not sure that the cat files actually contain the file name.
Try using CryptCatEnumerateAttr to see what attributes are actually stored.
Alun.
~~~~
[Please don't email posters, if a Usenet response is appropriate.]
--
Texas Imperial Software | Find us at http://www.wftpd.com or email
23921 57th Ave SE | al...@wftpd.com.
Washington WA 98072-8661 | WFTPD, WFTPD Pro are Windows FTP servers.
Fax/Voice +1(425)807-1787 | Try our NEW client software, WFTPD Explorer.
XP Pro SP2 and consider the following file:
crypt32.dll file (file version 5.131.2600.2180).
I calculate the SHA1 hash of this to be (hex-encoded bytes):
B9E14B84A8D39E982D192906FC0C190EDC1CCCA0
The function CryptCATAdminCalcHashFromFileHandle() however
returns a different value for the Hash of the same file:
A741494AF4FEFF83C554909322C643D0DBD2F968
and THIS value is in fact in the NT5.cat catalog.
So what exactly IS hashed by CryptCATAdminCalcHashFromFileHandle()
and used for the cat file tag value?
- Mitch
"Alun Jones" <al...@texis.invalid> wrote in message news:y-idnTkye5e...@comcast.com...
Thanks for your post!
Yes, just as Alun pointed out, this is a doc error, we can use the static
lib. AFAIK, the need to LoadLibrary and GetProcAddress went away as of
Win2k.
The CRYPTCATMEMBER.pwszFileName returns NULL is expected. Filename is
optional and we don’t store them in NT5.cat. The usage pattern is the app
verifies a file signature by hashing the file and then queries the catalog
database to find a catalog. Filenames are not reliable since they are not
unique and can be modified after signing.
Hope this helps!
Best regards,
Jeffrey Tan
Microsoft Online Partner Support
Get Secure! - www.microsoft.com/security
This posting is provided "as is" with no warranties and confers no rights.
.. if it was ever there in the first place. I can't envision how you would
create a DLL that exported a function, but in a way that the export didn't
make it into the import LIB - unless you somehow distributed the wrong version
of the LIB for the DLL, and in that case, you'd have the problem that the
exports might point to the wrong address.
>The CRYPTCATMEMBER.pwszFileName returns NULL is expected. Filename is
>optional and we don’t store them in NT5.cat. The usage pattern is the app
>verifies a file signature by hashing the file and then queries the catalog
>database to find a catalog. Filenames are not reliable since they are not
>unique and can be modified after signing.
The file name member certainly doesn't add any security, but it might add a
little "red flag" if you hash a file, and it matches the hash for some file
completely unrelated (without matching the hash for the file it claims to be!)
Optional features are there to be used!
Ones that are static do not have c14n done against them
which is why some match. "
--------------------
So related question to this, is there a tool or api to C14n process a PE
file? Does the resultant data represent a valid (and runable) PE file?
- Mitch
"Mitch Gallant" <jens...@community.nospam> wrote in message news:uMt5lvYQ...@TK2MSFTNGP14.phx.gbl...
(1) When I invoke:
signtool verify /a /v somepe.exe
the tool calculates the (C14n preprocessed) hash of somepe.exe and then
brute force systematically searches for an Tag entry match in a series (/a)
of .cat files in the cat file database?
(2) The reverse process (finding out what file a specific Tag entry in a cat file
corresponds to) has no hints, so this "reverse lookup" process would be quite
slow? This is where having the filename might be useful in some situations.
Thanks,
- Mitch
""Jeffrey Tan[MSFT]"" <je...@online.microsoft.com> wrote in message news:7sFxy9YQ...@TK2MSFTNGXA03.phx.gbl...
Cheers,
- Mitch Gallant
MVP Security
""Jeffrey Tan[MSFT]"" <je...@online.microsoft.com> wrote in message news:7sFxy9YQ...@TK2MSFTNGXA03.phx.gbl...
Sorry for the late response. I was OOF these days.
You have posted several replies in this thread, I am not sure which is your
curren concern. Can you collect your current problem context and concern in
well-defined logic order in a single reply to me? Then I will concentrate
my effect more efficiently.
I look forward to hearing from you. Thanks
Thanks for reading all my responses to myself :-)
I don't think there are any outstanding issues now! I think I've
figured this out .. but if/when you have time, you might
read the article here:
http://www.jensign.com/hash
and if there are any errors in my comments please advise :-)
Cheers,
- Mitch Gallant
MVP Security
""Jeffrey Tan[MSFT]"" <je...@online.microsoft.com> wrote in message news:vcL71mmR...@TK2MSFTNGXA03.phx.gbl...
I am glad you have figured out yourself.
Yes, your page is really an informative page. If I got time, I certainly
will give it a review :-)
Suggestion: don't use Microsoft-lingo outside of Microsoft. Few people get
"OOF".