Use of static boost.threading incompatible with CLI on windows 7

>> "this has to do with the use of boost.threading (which is incompatible with CLI as it uses TLS callbacks),"

The incompatibility is not to do with TLS or callbacks. It has to do with our use of boost::mutex. Which is not compatible with Microsoft's CLI (meaning you can't use the static versions of TA / TF in a C++/CLI compiled project). Us switching to use Microsoft's implementation of mutex (std::mutex) would not fix anything. Why? Because even MS's implementation of "mutex" is not compatible with C++/CLI.

So there's absolutely no way we can make static versions of TurboActivate and TurboFloat that are compatible with Microsoft's current implementation of C++/CLI.

Your choices are:

1. Use the dynamic versions of TurboActivate and TurboFloat. They work with every language.

2. Use the static version of TurboActivate and TurboFloat, but make sure your app or dll is a plain or C/C++ dll (not CLI).

>> "So hashing doesn't sound like the way forward"

You can also verify the Authenticode signature of the dll. But that's a good deal more work. Nothing can stop cracking. If that's what you're looking for, then you won't find it anywhere. Sure, people might *sell* it, but it's snake oil. You'd be buying lies.

As you are suggesting hashing or checking the Authenticode signature and we are not familiar with that, can you provide a sample implementation for c++?It needs to work on windows, linux and mac as our software is multiplatform, although the most pressure is on the windows version for now.Yesterday it only took me a few hours to build an alternative TurboActivate dll that completely bypasses all of the the security checks (even though I never tried this before), off course 100% is never possible but writing a replacement dll isn't rocket science after all.

And simply hashing & checking the hash on every startup eliminates that problem.

We don't build this into the library because there's no way to build it into the library.

There are tons of hashing libraries out there. Just google "C++ SHA256 hash file" and you'll find many examples. Then simply hash the files once, hardcode those into your app, then re-check the hash on every start of your app and compare them against the hardcoded hashes.

Authenticode is Windows-only, and is bit harder to program, but has the benefit of not requiring you to hardcode hashes in your app. Again, google is the best bet to find the best solution.

I'm quite inexperienced in this that's why I asked for sample code to include in my app. I understand that it can't be in the library itself and that it needs to be build/linked into our app. I spend some time googling around and I feel that validating the Authenticode is the best way because it relies on the certificate chain rather than on a hardcoded (easy to identify/replace) hash. We will stick to the static lib for our native code and would like to validate the Authenticode in the CLI dll (and that dll will be obfuscated afterwards). Also if we use hashing we would have to recalculate the hash every time you provide an update of the API, whereas the Authenticode validation can stay the same (as long as you keep using the same certificate), thus using Authenticode benefits maintainability and possibly upgrading the dll without a recompile (as long as the public interface of the dll doesn't change it should be ok).

The Authenticode is checked by the CLR but it does not break on it apparently (https://blogs.msdn.microsoft.com/shawnfa/2005/12/13/authenticode-and-assemblies/), I would have expected that the provided samples would take care of this issue. can you update the C# sample to contain code that actually does force this check somehow (in code, not in a configuration file because the user has access to that as well). Thinking of it, how do you convince your C# users that they are secured if replacing the dll is enough to bypass all security checks?

My goal is that a wannabe hacker needs to spend at least a few days before he cracks it, by eliminating the obvious weak links.

As you state "... the root of all the differences between LimeLM and all other licensing products is our philosophy. We built LimeLM from the ground up to be simple; simple for you and simple for your customers who will be running your software ..." based on your responses I don't feel its that simple, for you this might be something simple - for me it isn't

so could you please provide a sample that validates the Authenticode in a way that its not easy to bypass?we'll need it coded in c++ or CLI (if its easier for you to write it in C# we can translate it to CLI ourselves, I think)

I did a quick google search an came up with this result:

http://stackoverflow.com/a/308167/124805

Which led to a full C++ example showing how to verify the Authenticode signature of a file:

https://support.microsoft.com/en-us/help/323809/how-to-get-information-from-authenticode-signed-executables

Let me know if that helps.