guys, please respect that i am not going to hint at what the problem is, i´m pretty sure there are enough clever people reading this forum who would figure out how to bypass the protection of many commercial addon packages pretty quickly.
Actually i had the impression the weak spot is well known as i was pointed at it by a friend.
In a nutshell, i´d rather avoid the recommended solution by NT.
appreciate the comment about the obfuscator. If anyone has any other recommendations regarding code protection and license management, please shout
Aside from the fact that it is rather easy to bypass (read: get back the original unencrypted IL code which you can then easily convert to c# code) it presents a number of problems arising from the way in which it works.
Basically it uses low level hooks to bypass the MS JIT compiler and insert its own modified JIT compiler which knows how to reconstruct the IL code from the encrypted version that is stored in the native assemblies it creates when you protect your code.
Problems arise because their modified JIT compiler is not 100% compliant with the latest version of MS JIT compiler, so some things that are valid c# code will not work correctly as you would expect them to. I pointed out one such issue in a thread here related to casting of string types, where remotesoft compiler forces you to use .ToString() when you shouldn't need to. Also if MS changes their JIT compiler (as they did substantially with .NET 3.5) then remotesoft will have to change theirs and your code can potentially break and have to be redeployed and you are stuck waiting on remotesoft and telling your users not to upgrade their .net framework.
Another problem is that it makes it difficult to debug any code that is protected, ie you cannot debug it in visual studio and it obscures the true source of exceptions making it hard to report bugs (although that is true of pretty much any protection method).
So basically it gives you problems and not much protection. Yes it does stop decompilation with reflector but you could do the same thing with a simple obfuscator. If you use control flow obfuscation you also get the benefit that if someone does try to reverse engineer the IL code it will be mangled and difficult to reconstruct, whereas with remotesoft once you have obtained the decrypted IL it is unobfuscated and easily converted to the original c#.
As far as bypassing protection (aka cracking), that is trivial and there is pretty much no way to stop it even with unmanaged code. What I am concerned with is decompilation of the code where people can steal your code/ideas etc..
Last edited by sefstrat; August 31st, 2009 at 11:55 PM.
This is a very interesting thread, but I have to admit, you guys all know a lot more than I do. I have written a few indicators in Ninjatrader and would like to share them with some people (I may actually sell them). But I don't want my code to be given away, and I don't want people to be able to share with everyone.
I would just like a simple easy and preferably cheap way to do this. I know it is impossible to stop everyone, but I just need a way to limit, or make it difficult.
If I export it as compiled assembly, then run an obfuscator on it, that would not stop people from sharing it, or even posting it on a forum would it? So how do you stop that?
P.S. Sorry, like I said, I don't know much about this stuff.
Honestly, I would question how smart of business it is to lock the code for NT stuff.
I've found some interesting commercial stuff but once I found out it was locked it became literally worthless to me. A huge reason people use NT is to integrate stuff into their own custom setups, if I can't modify something to fit my needs then its worthless.
While you would run the risk of someone copying your idea, you run a greater risk of losing customers period.
You can tie it to their hardware somehow, ie the way ninjatrader does with machineID.. except their system is weak because it only enforces the machineID on the server side, a stronger but more tedious solution would be to enforce machineID in the actual binary file.
In other words you generate a seperate dll file for every user which has their unique machineID encrypted in it. That will stop most people from being able to share it..
That's been my standard suggestion to people as well. A determined person will always be able to hack client-side code. Since the client machine must be able to run the code, the machine owner can always intercept it. So if you don't want the important code to run on a secure server that you own, you might as well just take minimal steps to keep casual "sharers" from succeeding and not waste much more effort.
The answer is quite simple.
If most users were able to see (and understand) what's really in all these "magic"/expensive indicators, would they buy them ?
No, they won't...
Paying high prices for them gives to these indicators/strategies some kind of super-power. A basic marketing principle: "if it's expensive, it's good...".
Usually in trading, those who know don't talk, and those who talk don't know. (Al Brooks)
success requires no deodorant! (Sun Tzu)
The following user says Thank You to sam028 for this post:
Personally, I wouldn't pay anything for something I can't get the source to. Goes double for strategies - they're going to be obsolete in a few months anyway and if they're untweakable then they're useless. I'd feel much better about going back to some coder that had given me well thought out, fully commented source. In fact, i'd pay a premium for it... not that i'm going to pay someone to write code for me anyway ;-)
i'm not sure why people are so concerned about other people learning about their strategy ideas. surely if your strategy is so good, you should keep it to yourself and print yourself a mint. any strategy that's for sale is obviously not good enough to make the inventors a ton of money, either that or you're getting the version that lags by 1/2 bar and they're skimming off you, TWICE!
The following 4 users say Thank You to piersh for this post: