Hello. I'm trying to find out how to make it so only certain applications I have given authorisation to can use a C DLL I have created so that when I release it with a .Net application it cannot be used by others. I found out how to check what the current running exe is called. However this is not practical for obvious reasons.

So is it possible to somehow make a DLL do a MD5 check of the exe that is using it?
Any other methods of checking if the exe is "authorised" are also appreciated.

Thanks for your help.

Icewolf.

Dani AI

Generated

Short answer for : hashing the EXE is possible, but MD5 is a weak, brittle control. It can be used as a quick integrity check, but for real protection use either Authenticode signature verification (WinVerifyTrust) or a server-backed license/token system. Those approaches raise the bar far higher than a simple MD5 compare.

If you still want a local hash check inside the DLL, get the process main-module path from inside the DLL and compute a cryptographic hash (prefer SHA-256). Compare the binary digest to a whitelist or to a signed token. Example pattern (Windows, C):

#include <windows.h>

BOOL IsAllowedExe(void)
{
    char path[MAX_PATH];
    if (GetModuleFileNameA(NULL, path, MAX_PATH) == 0) return FALSE;

    unsigned char digest[32];
    if (!ComputeSHA256FromFile(path, digest)) return FALSE; // implement with CNG/CryptoAPI or a library

    // compare digest to allowed values
    const unsigned char allowed1[32] = { /* expected bytes */ };
    return memcmp(digest, allowed1, 32) == 0;
}

Notes, caveats and troubleshooting:

  • Do not rely on MD5; use SHA-256 or better. An attacker can replace binaries or patch your DLL/EXE to skip checks.
  • Prefer verifying the EXE's digital certificate thumbprint (Authenticode) — harder to forge than a raw hash on disk.
  • If files are locked or packed, open them with appropriate share flags and check GetLastError. Packed/updating installers will change on-disk hashes; signatures survive many benign repacks.
  • This advice extends 's point about locating the EXE and explains why 's self-modification example demonstrates the limits of naive file edits. Client-side checks are only one layer—combine signing, server validation, and tamper-detection for meaningful protection.

Hello,

If you can gain information like the name of the executable, you can probably find the path to it. It should be possible to get the path to an executable from it's PID.

Then with the path you can easily do your MD5 check.

Hope this helps.

// Zoon

Hello. Sorry for the late reply. Thanks for that information. Would fopen allow me to open an exe that is running? Thanks for all your help :)

fopen should allow you to open the file for reading, but will not open it for writing. Note that if you try to open the file for writing, it WILL NOT return a null file, but as soon as you try to write to it the program will crash. That is what happened to me (Windows XP Pro SP3) with this program:

#include <stdio.h>

int main(int argc, char **argv) {
	char *exe = argv[0];
	strcat(exe, ".exe")

	printf("%s\n", exe);
	
	FILE *in = fopen(exe, "r");
	
	FILE *out = fopen(exe, "w");
	
	if (in == NULL) printf("in is NULL!\n");
	if (out == NULL) printf("out is NULL!\n");
	
	char line[1024];
	
	printf("Attempting to read...\n");
	fgets(line, 1024, in);
	printf("%s\n\n", line);
	
	printf("Attempting to write...\n");
	fputs("hello", out);
	
	return 0;
}

What the program does is try to read from itself, and write to itself.

DISCLAIMER: I take no responsibility for any damage this program may cause to any part of your computer.

EDIT: Added the operating system I tested this program on.

Be a part of the DaniWeb community

We're a friendly, industry-focused community of developers, IT pros, digital marketers, and technology enthusiasts meeting, networking, learning, and sharing knowledge.