2

I would like to limit who/what can use my C++ DLL. I have an .mq4 script ( or it can be anything else I guess ) and I use DLL-#import-ed functions in it.

How I want to do the limitation is: there is a static filepath in the DLL, and at the begining of every function I just calculate a new checksum ( sha1 ) of the file ( where filepath points to ) and compare it to the original checksum ( also static ). It's good, because if someone modify the .mq4, the function will not work.

My problem is: If I just leave the original .mq4 there, and I create a new one, importing the DLL in there, I can use the DLL with no problem, because in the DLL I'm checking the original .mq4, ( where the static filepath points to ) not where I have used it from.

So somehow I should figure it out, where the DLL has been imported and check the sum of that file. Or maybe there is another technique, I don't know.

user3666197
  • 1
  • 6
  • 50
  • 92
rdanee
  • 109
  • 1
  • 1
  • 9
  • I'm pretty sure that whatever we can come up with here, someone else can break... ;) – Mats Petersson Jul 16 '13 at 14:06
  • That is, unless the entire system is secured and only allowed to run executables that are part of some predefined image - but I expect that's not something your app will want to require... – Mats Petersson Jul 16 '13 at 14:07
  • Same question, different words, same answer: [The #1 law of software licensing](http://stackoverflow.com/a/4532568/103167) – Ben Voigt Jul 16 '13 at 15:06

1 Answers1

0

A principal solution: ( without a relation to the dilemma of "License or not License?" )

for the purpose of knowing who-imported / who-called a DLL-function, the conventional #import mechanics are too lightweight and principally open-source'd to potentional attacker.

The strongest and smartest and hardly paralleled protection ever seen is, by design, in occam parallel execution language ( used for transputers ), where caller and callee either have an agreement on communication protocol or not. So no one can hijack and use remote service just by sending an "un-solicited" call.

The second closest are ( occam-legacy followers ) languages with support for a CSP-based scheme - be it python, Go or other CSP-conformant engine.

( life-long victims of their own methods exposed to public )

The rest of world get used to live in an environment, where objects and DLL-s are endlessly vulnerable to attackers who may at any moment overload / mis-use any DLL-service or object method, while the DLL-side or the object instance has no way to protect itself and reject / deny a service once a caller is not permitted / allowed to ask for such a service.

MQL4 has an ability to communicate with CSP-"safe" environments, so if you indeed have such need, make your MQL4-side connected to the remote-side and benefit the CSP-safety to avoid unauthorised use of a service.

Proxy-mediator

In case you do not want to move that far, try to mediate your C++ DLL with a proxy, that:

  • enforces caller-identity per-call self-presentation
  • mediates caller-identity bound per-call reference-counting / checks
  • prevents fake-caller from hijacking the mediator node to gain target DLL access
  • preserves the mediator<->target handshaking details hidden from MQL4 side
user3666197
  • 1
  • 6
  • 50
  • 92