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

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

Experts,

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?
0
php-newbie
Asked:
php-newbie
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.
http://msdn.microsoft.com/en-us/library/ms680095(VS.85).aspx

If this is a key implementation detail you could wrap your DLL with a COM interface.
0
 
pgnatyukCommented:
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.
0
 
ChristianWimmerCommented:
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.
0

Featured Post

What does it mean to be "Always On"?

Is your cloud always on? With an Always On cloud you won't have to worry about downtime for maintenance or software application code updates, ensuring that your bottom line isn't affected.

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