If i create a new (empty) dll with a same function name (that does nothing, ofc), i could avoid your protection..
This library should be integrated into the program then.
or i'm wrong?
Originally Posted by TheTrigger
If i create a new (empty) dll with a same function name (that does nothing, ofc), i could avoid your protection..
This library should be integrated into the program then.
or i'm wrong?
To prevent a dll override you could do a checksum of the file using any hash type like md5 or sha1...example:
It's fairly trivial to change one hardcoded hash to another using any decent hex editor / decompiler, though.
What would happen if a legitimate DLL was loaded into the process, would your protection prevent it? Take DllImport as an example:
From the MSDN docs:
Originally Posted by msdn
Locating and loading the DLL, and locating the address of the function in memory occur only on the first call to the function.
This means that any external libraries will only be loaded when the PInvoke'd function is first called. If I was to call "Activate()" prior to any of my other PInvoke'd functions, would the program fail to load the libraries into memory?
Originally Posted by Jason
It's fairly trivial to change one hardcoded hash to another using any decent hex editor / decompiler, though.
The developer need to improve it, i just brought him an example.
Originally Posted by Jason
What would happen if a legitimate DLL was loaded into the process, would your protection prevent it? Take DllImport as an example:
....
This means that any external libraries will only be loaded when the PInvoke'd function is first called. If I was to call "Activate()" prior to any of my other PInvoke'd functions, would the program fail to load the libraries into memory?
Since kernel32.dll is always loaded into .net apps DllImport will just use LoadLibrary of the current dll, most of dll injectors create a remote thread using an external address so when the thread will start they will get the hooked function instead of LoadLibrary.
Originally Posted by Sam
Since kernel32.dll is always loaded into .net apps DllImport will just use LoadLibrary of the current dll, most of dll injectors create a remote thread using an external address so when the thread will start they will get the hooked function instead of LoadLibrary.
That doesn't make any sense.
Originally Posted by Jason
That doesn't make any sense.
Try yourself , the dll just handle native injection do not affects the .net app.