Peer Review of a Strategy Without Disclosure

Quote from rufus_4000:

First of all, very few things would stop a very determined technologist from reverse engineer the strategy if you provide any executable to them. But never the less, there are some approachs for the paranoid.

1) Write your software that require the presence of a physical key (i.e., a secure USB dongle), and then *take* the dongle back after 30 days. This can still be spoofed via virtual device drivers that just records the challenges, and play it back. And it is a huge pain to code to any GSS-API based token library. I have something like this for my own system, but I don't even distribute any part of the object code.

2) Write your software that require the user to be online, so that the software need to contact your "mothership" server everyday upon startup for "challenge", if it does not challenge successfully, then intentionally corrupt the executable (!). Similarly, this can be defeated via properly analyzed spoofing.

3) Probably simpler, just load up your software onto a laptop, lock down the laptop (no CD access, no usb access, all network ports except the permitted ones), give them the laptop, and then only give them a low acces level login (password set to expire). Again, this can be defeated via just a standard O/S attack, possibly via network scanning and stack breaking.

Basically, this just makes the effort of breaking your system harder, it doesn't make it impossible.


Interesting post. Is this valid for any operating system?
 
Quote from 9999:

Interesting post. Is this valid for any operating system?

Yes. Any protection scheme can be broken. period. Just depends on the level of skill/determination required to break it.
 
Quote from 9999:

Interesting post. Is this valid for any operating system?

More or less, like Stephen mentioned, it just depends on how much hoops the hacker has to jump through. In a perfectly controlled environment, where anything and everything can be spoofed (IP addresses, disk access, memory access, etc), then pretty much most of the mechanisms can be defeated.

Of course, any one up for a little quantum crytography? Disclaimer, I was a crytopgrapher as my day job back in the early 90s, before I got into finance, so paranoia is something I am quite familiar with.
 
Execute some of the mission critical code in external hardware. Build a little board 2 inches by 3 inches with a cheap CPU, flash, and CPLD. Put your Important Code in there and (very important!) enable the CPLD security flag. Give it a USB interface, glop it with epoxy (to discourage logic analyzer probing), and Bob's your uncle. You can have the hardware lock up and fail to operate after N number of executions, or after date D, or after P number of power cycles, or whatever else your loving heart desires.
 
Quote from SyndBroker:

Provide a DLL that acts as a proxy to your real logic implemented on a secure server somewhere. Use a secure protocol between the proxy DLL and the server to prevent casual sniffing. The DLL should do nothing more than forward the requests to the server and retrieve the responses. After 30 days, take the server down.

I like this solution the best,

But in general, I'm not sure what you're trying to accomplish by providing it to others. If it works for you trade it. If you don't have enough $$$ to trade it like you want on your own, then I guess I could see where this would be beneficial. If you want to sell it, then yes, I'd see that as a way to allow other traders to see it.

Another idea. If you just want to prove that the software generates profitable trades, do it using IM. Everytime a trade is generated, have your program send an IM to anyone who is interested. Then, they'd know exactly when your trades went off and could determine P&L, slippage, and costs for themselves. But if it's something they would need to provide parameters for, that obviously wouldn't work.
 
Back
Top