Securing DLLs
Michael Winter
it uses, is there any other way of making sure that an application is
using the DLL it thinks it is.
For example, a fake DLL could be placed in the application's execution
path (or wherever the application is going to load it from) that calls
the real DLL whenever it needs information that it can't provide
itself, and return dummy results in other cases. What could be done
to prevent this?
By the way, this isn't crucial - I'm just interested.
Mike
--
Michael Winter
M.Winter@[no-spam]blueyonder.co.uk (remove [no-spam] to reply)
Slava M. Usov
news:kM4cb.3658$FA3.32...@news-text.cableinet.net...
> Apart from getting the application to perform a CRC check of the DLL
> it uses, is there any other way of making sure that an application is
> using the DLL it thinks it is.
The whole thing can be roughly divided as follows:
1. The application loads the DLL explicitly. Then the application can
theoretically check the identity of the DLL [and reject it if it is
unknown].
2. The application loads the DLL implicitly. Then it cannot check its
identity and somebody else must do it for it. This case is harder, and more
so because most DLLs are loaded this way.
Checking identity is not very hard these days when strong digital signatures
and cryptographic algorithms [and libraries] are ubiquitous. What is hard is
maintaining a library of such signatures, especially in case 2, especially
when you need to manage it centrally for hundreds and thousands of
installations. But that can be done, I know a company that does that for
living.
S
