No need for a book, you need to understand how DLLs operate.
Lets say you have a class with useful code :
- Code: Select all
namespace SecretUserAuthorizationAlgorithm
{
class AuthorizeUsers
{
public:
bool isAuthorized (string userName, string pass)
{return false; }
}
}
Now, lets say you have many executable who need to be running this code.Instead of compiling the code into each executable (by adding the source code into each project) you have the option to compile it into a separate module, a DLL.
When you compile the above mentioned class as a Dll, the compiler creates the same binary object as if you compiled it as a part of executable file, however a Dll interface is being added to it (basically a few extra functions that load this object into memory and etc.).
Now, you obviously can't run this Dll as you would've ran a normal executable (it does not have a main() by the way) as you have to create an instance of this class first.
What you can do is, you can reference this file in other executables:
- Code: Select all
relyOn UsersAuthorize.dll ;//in reality taken care of by the linker
//you have to add a "reference" to the dll.
using SecretUserAuthorizationAlgorithm
int main()
{
AuthorizeUsers accessGuard;
if (accessGuard.isAuthorized("user", "pass"))
{
AcessArea51();
}
else
cout<<"Please remain call. FBI is on its way to your residence.";
return 0;
}
What happens is that the executable has been told that such class exists and what that class' public functions are, so when the executable is running, it would attempt to run that function.
The way this work is as follows: some extra code is added to your exec, so that the first time you reference something that resides in a dll, that extra code will look in memory to see if the dll is loaded. If it is, it will create an object and everything is fine.
If the dll is not loaded, the OS will look for it and attempt to load it (it looks first in the local folder). If the DLL is not found anywhere you get BSD (blue screen of Death, not the OS) (in Win98, XP is better when it comes to that.)
Why would you use a Dll ?? Well, it gets loaded in memory only once, so you save memory. Also your code is more modular. You can change the implementation and recompile only the dll, not the whole app (as long as you keep the public functions the same).
Now, about Dll, injection: someone could write a dll thats the same as the original one, but change it so that it isAuthorized() always returns true. Then, the attacker will replace the legit dll with the malicious one and that dll will be loaded and called instead.
Then the Ruskies will get access to Area51 and steal all our captured alien space ships
Now this is over simplification of course, dll could be signed with a key that would prevent such injection (keys of all executable and binaries must match), but thats the general idea...
