I think it's worth figuring out why native does it like this.
Believe me, I've been trying to. I'm only inferring that it should be loaded because using native wintrust calls CryptSIPLoad, and my implementation makes it continue on to call other functions that seem reasonable in that context.
I don't know what tests I can write to show that I should not pass the DLL's function pointers directly back to the caller. That might make sense if crypt32 were to try to unload unused function pointers periodically, since the API doesn't provide an unload function - but that seems overly complicated, and I unload them at DLL unload time instead.
If you have suggestions on tests I can write, I'm all ears.
Also the dll loading part of the patch is quite confusing, hopefully doing it closer to the native way would help make it clearer.
The complication comes from the fact that the registry allows one to have a separate DLL for each function in a SIP, but CryptAddSIPProvider does not. I therefore fail if the DLL names are different. This allows me to use an HMODULE as the hSIP member of a SIP_DISPATCH_INFO, rather than invent some more complicated scheme.
I can add more comments to try to explain that if you like. --Juan
____________________________________________________________________________________ Bored stiff? Loosen up... Download and play hundreds of games for free on Yahoo! Games. http://games.yahoo.com/games/front