Study Protection is just a MEGA FAIL

Questions about MultiCharts and user contributed studies.
Laurent
Posts: 159
Joined: 20 Nov 2010
Location: France
Has thanked: 76 times
Been thanked: 34 times

Study Protection is just a MEGA FAIL

Postby Laurent » 09 Feb 2012

Well first, let's say I like MC a lot, but that security feature... just su**s.

Let's share my experience.
A few days ago, I thought it was a good idea to protect some of my indicators with that "protection". To keep a minimum of compatibility (compared to sef), I thought it was a light but nice protection.

I put a password on about 60 indicators, then export my files. Yeah nice, before to share them with someone, I had the good idea to open that fabulous PLA format!

Let's take an example,

Code: Select all

<?xml version="1.0" encoding="UTF-16" standalone="yes"?>
<Graph>
<GraphNode>
<data first="i_Aaroon" second="1"/>
<signature ObligatoryParamCount="0" RetType="0" StorageType="32"/>
<StudyProperties BarRefMode="1" BarRefValue="50" SaveAsSymbol="0" SemilogAxis="1" UpdateOnEveryTick="1">
<PlotInfo Color="255" IsExists="1" Name="hi" Num="1" ShowLastPriceMarker="1" Style="0" Type="0" Width="0"/>
<PlotInfo Color="16711680" IsExists="1" Name="lo" Num="2" ShowLastPriceMarker="1" Style="0" Type="0" Width="0"/>
<PlotInfo Color="16776960" IsExists="1" Name="hiref" Num="3" ShowLastPriceMarker="1" Style="0" Type="0" Width="0"/>
<PlotInfo Color="65535" IsExists="1" Name="loref" Num="4" ShowLastPriceMarker="1" Style="0" Type="0" Width="0"/>
</StudyProperties>
<PasswordState IsProtectedByPassword="1" Password="ceJroSnS5jbYy8TS7afdyQ=="/>
<NodeText Encoded="1">e1RISVMgSVMgQU4gQVJPT059CgppbnB1dDp0aG9sZCgyMCksbGVuZ3RoKDI1KTsKdmFyOmhpcmVm
KDApLGxvcmVmKDApOwpoaXJlZj0xMDAqKChsZW5ndGgtbnRoaGlnaGVzdGJhcigxLGgsbGVuZ3Ro
KSkvbGVuZ3RoKTsKbG9yZWY9MTAwKigobGVuZ3RoLW50aGxvd2VzdGJhcigxLGwsbGVuZ3RoKSkv
bGVuZ3RoKTsKcGxvdDEoaGlyZWYsImhpIik7CnBsb3QyKGxvcmVmLCJsbyIpOwpwbG90Myg1MCt0
aG9sZCwiaGlyZWYiKTsKcGxvdDQoNTAtdGhvbGQsImxvcmVmIik7Cgp7IElmIHlvdSBjYW4gcmVh
ZCB0aGF0Li4uIGl0IHN1Y2tzLi4uIH0K
</NodeText>
</GraphNode>
</Graph>
Well nice my code seems protected, with a password, and I can't see the code (Whoua).

Moderator's Note: [edited out]

So I do not understand why you do not use AES256, you prompt the password to the user and you encrypt the content in AES.... just simple for a developper and 100000000 times secure.

Now there's the SEF export, but I'm sure there no special security on this format, it's just compiled code you may reverse it (I'm ok with the fact it will take clearly much timer but it was possible for TS/eld).

So why don't you implement a REAL security mechanism to have a minimum of security.
I know things are not unbreakable (specially on thick client), but just a minimum please.

I'm sad tonight!

Best Regards

User avatar
TJ
Posts: 7740
Joined: 29 Aug 2006
Location: Global Citizen
Has thanked: 1033 times
Been thanked: 2221 times

Re: Study Protection is just a MEGA FAIL

Postby TJ » 09 Feb 2012

Now there's the SEF export, but I'm sure there no special security on this format, it's just compiled code you may reverse it (I'm ok with the fact it will take clearly much timer but it was possible for TS/eld).
The SEF is compiled. It will take some technical knowledge, time and effort to decompile it. The decompiled file will be "machine code-like", and probably not sensible to the causal reader.

The TS/eld is encrypted, not compiled.


One caution on the SEF:
When you import a SEF file, which can consist of an indicator and multiple functions,
if you happened to have functions with the same names (which is quite often the case),
the import process will over write your functions and render them "read only".

My suggestion to MultiCharts:
The import process should rename any duplicate filenames instead of destructive over writing.
eg. append (2) at the end of the filename.

User avatar
Stan Bokov
Posts: 963
Joined: 18 Dec 2009
Has thanked: 367 times
Been thanked: 302 times

Re: Study Protection is just a MEGA FAIL

Postby Stan Bokov » 10 Feb 2012

Now there's the SEF export, but I'm sure there no special security on this format, it's just compiled code you may reverse it (I'm ok with the fact it will take clearly much timer but it was possible for TS/eld).

So why don't you implement a REAL security mechanism to have a minimum of security.
I know things are not unbreakable (specially on thick client), but just a minimum please.

I'm sad tonight!

Best Regards
I want to clarify something. SEF files are "compiled" while TS files are "protected". There is a big difference between these two approaches. Compiled means they are a bunch of zeros and ones, and the only practical way to decompile them is to rewrite it from scratch by observing the behavior (which can be done with any indicator anyway). There is no source code in the SEF files at all. Plus, they are only compatible with the version of MC that they were compiled in, adding another level of protection.

Protected TS files contain source code, so that they can be compatible across versions. They can be opened rather easily, exposing source code. Same goes for NT protected studies. So, SEF is the most protected you will get.

As you mentioned, it's possible to open anything if you want it bad enough. But with SEF it simply becomes cost-prohibitive to bother with them, unless your system makes enough money every day to pay for this decompilation :)

Laurent
Posts: 159
Joined: 20 Nov 2010
Location: France
Has thanked: 76 times
Been thanked: 34 times

Re: Study Protection is just a MEGA FAIL

Postby Laurent » 10 Feb 2012

I'm okay with you for the SEF format, I don't think people will try to reverse/decompile each file. In fact it can be done but it would take really a LOT of time just to have something you do not understand.

But the problem for me, SEF is compatible only with your version of MC?! Too bad to share with a few people, if you need to compile everytime they change of version :)

For the Study protection in a PLA file (the real problem for me), in fact that's not a protection, the password is not used to encode the indicator, and the content is not encrypted but just encoded. It's trivial to use a base64 decoder to get the content.

The good way to handle it and to use security best practices is:
- The password must not be stored in the PLA file. (even encoded/encrypted)
- When the user use the "study protect" feature, the editor asks for a password (as now).
- The editor use this password to encrypt the content of the source code with a strong algorithm such AES 256.
- The encrypted content is exported in the node text.
- To decrypt the content, you need the password.

If you use a password of more than 10 characters with alpha/num/specials, there's no way to decrypt the content just by a bruteforce (it's really encrypted and not encoded).

Why not choose that solution?

PS: The only problem I see is maybe the editor will ask the password a few times more when you compile an indicator and you have protected your function because the password is not stored.

User avatar
Stan Bokov
Posts: 963
Joined: 18 Dec 2009
Has thanked: 367 times
Been thanked: 302 times

Re: Study Protection is just a MEGA FAIL

Postby Stan Bokov » 11 Feb 2012

Laurent,

I gave some further thought to your comments, and I wanted to update my answer.
First, the method of password protection that you are discussing is obviously not perfect. It provides a minimal level of security to prevent the general user from looking at the script. To be fair, TS also carries the password in the script, but archives it. This means that one can use another program similar to the one you refer to in order to open general ELDs.

Second, every single program has weaknesses that can be abused, and the information you provide can be used for illegal opening of user scripts. It is not correct to provide concrete instructions to perform potentially illegal activities in the open, you should have sent this info in private to voice your concerns. We could also post links to generic tools that are capable of opening TS files, but we don’t do that, since it’s not correct.
Moderator’s note: specific instructions to open scripts were removed, and this thread has been closed. In the future do not post such content in the open.

Third, regarding SEF protection and binary disassembly. I want to clarify that it is possible to disassemble commands sent at the machine level, and it is possible to reconstruct each script step by step. However, it will take an experienced hacker (and I mean someone who reads assembler commands better than English) several weeks to perform the task. Such people are very rare, and their time is so expensive, that it is extremely unlikely someone will go through the trouble to unlock an indicator.

Fourth, it’s impossible to write a universal tool to read binary code, unlike byte code that is used in TS (not even mentioning managed code like C# used by our competitors, which is open to everyone).

Fifth, your idea doesn’t work. Any script no matter how much you encode it, is still transformed into readable format before being sent to GCC. A hacker can write a program to interject into that part of the process, dump that info into a file and have the source code. Therefore, what you propose is not a solution.

Lastly, we realize that SEFs being compatible with only the current version is a real pain the rear for most developers. So, we implemented a new method where, beginning at MultiCharts 8, all SEF files will be forward compatible.


Return to “MultiCharts”