0

I want to create a Windows DLL that can only be called by applications that are known to me.

Suppose that inside my application (a Windows DLL to speak the truth), I have a list of business partners and that we agree in some sort of identification. I want to block any attempts from applications that are not in this list to access an exported function in the dll.

I'm looking at Windows Authenticode but I'm not sure if there is a standard path to solve this type of problem. Help is appreciated.

Padu Merloti
  • 3,219
  • 3
  • 33
  • 44
  • 1
    Don't make your API documentation public, give it only to known partners under NDA. Without this documentation, your DLL is pretty much unusable. – syam Aug 30 '13 at 18:03
  • Agreed, it will be unusable to the public, but not to a hacker. – Padu Merloti Aug 30 '13 at 18:06
  • You're assuming your DLL provides services that interest a *real* hacker enough to spend a lot of time reverse-engineering it (which, depending on the size of your API, could range from weeks to years...). Really, cracking a program to "work around" a protection (such as the one you're asking for) is easy enough nowadays and typically takes a few hours, but figuring out a whole API, its semantics, and the layout of the objects it uses is a whole other matter. Just don't bother, you'll save yourself quite a lot of time. – syam Aug 30 '13 at 18:13
  • 1
    Authenticode won't give you what you're looking for. It is a code-signing mechanism for ensuring tamper-resistance; not caller-authentication. But anyone can still invoke your functionality. There are things you can do to make it non-*trivial*, but outright-securing your code to a specific client is another realm entirely (and a considerably difficult one at that). – WhozCraig Aug 30 '13 at 18:17
  • @WhozCraig: http://msdn.microsoft.com/en-us/library/ms537361(v=vs.85).aspx explicitly says it is for authentication as well as integrity – Padu Merloti Aug 30 '13 at 18:43
  • 1
    @PaduMerloti Not the kind of authentication *you* want. You want caller-authentication (i.e. the caller is trusted). Authenticode (indeed any signature-system) provides *callee* authentication. I.e. You can "trust" the code your about to call because the it is validly signed by a certificate that is chained to a trusted CA in your root store. That does you no good for what you're describing (ie. I only want apps I trust to call *me*). – WhozCraig Aug 30 '13 at 18:46
  • 2
    +1 to @syam. Your code is running on an attacker's machine; you've already lost the battle. Whatever elaborate checks your DLL performs, the attacker will simply patch out. If you want your algorithms to be secure, run them on machines you control, as a web service, and have your trusted partners talk to it over the network, with appropriate authentication. – Igor Tandetnik Aug 30 '13 at 19:15
  • To extend @Igor's comment about "*Whatever elaborate checks your DLL performs, you've already lost the battle, the attacker will simply patch out*" => Keep in mind that even if you write 100kloc of "protection" code, in the end it always boils down to a few `if`s that have to be patched to reverse the condition. It's completely **useless** to try to protect yourself against hackers because they will always win, it's really too easy for them. – syam Aug 30 '13 at 20:16

1 Answers1

0

It's simply not possible to secure executable code against execution once unauthorized party has access to it. You can make it hard to execute the code, but a party determined enough will find a way to run it. You're effectively fighting the same battle as application and game authors are fighting against pirates, and looking at the number of executables that aren't yet cracked, your chances aren't good.