• Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 718
  • Last Modified:

What's the best way to protect DLL API access? (C)


I'm looking for a way to protect which application can call which API of a DLL I'm creating. For example, I have a DLL to manage multiple devices. One application should be able to open one device but the second application should not be able to open that same device. Only the first application should be able to 'work' with the device and execute other APIs against the same device.

I could do this by passing back a random string from the open API to the first application which it could then use as 'password' and input param for every other API for this device. Is there a better, more secure way of doing it?
1 Solution
evilrixSenior Software Engineer (Avast)Commented:
COM provides a mechanism to do something similar to what you want to achieve via the IClassFactory2 interface.

If this is a key implementation detail you could wrap your DLL with a COM interface.
Make a table of the devices and IDs of the connected to them processes somewhere in the shared memory. Protect this shared memory with a named mutex. When an application will open a device, your DLL will register this application in this table in the shared memory. Any next call will verify the registration.
Instead of the shared memory you can use a disk file.
Sorry, I reject. Mutex and shared memory will not work since Terminal Sessions will not allow this. Every session has its own set of resources. You would need to create a GLOBAL mutex, but this is only available to admins.
You cannot secure DLL function calls bullet proof against this because a DLL is run in the context of the calling process and thus in its realm where it can nearly do whatever it want.
A shared file also has some problems, including access rights and the problem of leaving it alive after process' life.

If you really want to make it right, you should have used an extra process, either a real service or a COM single instance server. Only in this way your device is protected, since you have a good security barrier.

I'm not sure, but you are talking about a real device, maybe using a device driver? If so, I would suggest to put the check into the driver function IO message.

In the end, to protect resources, it is always the best (and only way) to put a third independent party between device and consumers.
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

Join & Write a Comment

Featured Post

The new generation of project management tools

With monday.com’s project management tool, you can see what everyone on your team is working in a single glance. Its intuitive dashboards are customizable, so you can create systems that work for you.

Tackle projects and never again get stuck behind a technical roadblock.
Join Now