I’m developing some custom indicators for NinjaTrader 8 and I’d like to share them with others, but I want to make sure the source code remains protected.
Could anyone explain the best way to apply security or obfuscation to my indicators so that users can install and use them without being able to see or modify the source code?
Additionally, I’d like to control which users can run the indicator, ideally by checking their Machine ID. Is there a way to create or manage a list of allowed Machine IDs so that only authorized users can use it, and if their ID isn’t registered, they’d need to contact me for access?
Any tips, examples, or recommended tools for this kind of protection would be greatly appreciated.
Pd: I don’t know if this is the correct site to ask, feel free to move my question if it’s in the incorrect place.
The link posted above by marcus is the current documented and supported way to do what you’re looking for and get “some” security to deter the average bad actor but won’t prevent the motivated ones. There is no absolute security, just levels and how much effort you are willing to put into it. I think most vendors here are aware of this and accept the risks with this approach simply because nothing better is readily available.
There are at least a few vulnerabilities with the approach outlined in the above link.
People can still bypass the machine ID security you get with NT licensing portal. Some people (including myself) have created their own home grown measures to add a second layer of security to prevent unauthorized use. It could be something as simple as a protected google sheet with a list of authorized machine IDs or a more sophisticated solution.
AgileDotNet has a lot more security features by itself but only one is used when incorporated with NT export - code encryption. This makes reverse engineering the code more inconvenient, but not completely impossible. A motivated hacker can still dissect your code with readily available tools.
While AgileDotNet has the ability to do string obfuscation, this feature isn’t enabled with the standard NT export. Manually enabling that feature when exporting from NT tends to create code that is unusable when importing on a client’s system, so you can’t even manually use this feature.
Regarding #3, if your indicator is going to include web or database links and login credentials, passwords, account numbers, etc, as string constants, beware that strings aren’t encrypted and these can easily be extracted from code even if your assembly has been obfuscated with AgileDotNet. If you need to protect sensitive information in your compiled assembly, you would need to come up with a better solution on your own that most likely uses strong encryption.
This is not to discourage you from moving forward. As I mentioned most of us here are aware of these and accept the risks so we can move forward and market our products. Just be aware of the capabilities and vulnerabilities with any approach.
I always wondered, what happens if you’ve bought software and you want to move it to another machine and the vendor has shut down or died or something. Is your software locked to a Machine forever?
