.algo file can comeback to see code again?

Mikro
09 Jun 2017, 17:07

Nope, as far as my Knowledge goes by compiling the Programming Language with the Compiler you create an Imediate Code wich is machine readable but cannot be reopened with your Workstation.

But maby an IT-Engineer arround here can elaborate in a few more Details? Or prove me wrong?

(I'd like to reverse engineer Algos, too ;)

Cheers

Mirko

kricka
09 Jun 2017, 21:50

Encryption security is of highest standard

The security used by Spotware for the encryption of the code is of the highest standard. This is, of course, essential for programmers who like to distribute the code or are working for a trading company that does not want the code to be readable by others then the programmers and the inner circle of the company. Reverse engineering as "Mikro" explained is not possible with a cBot code created to be non-readable.

Therefore it's very important for a programmer to secure the full code of the cBot with several backups in case the encrypted code becomes corrupted for some reason and a new version needs to be created from the original unencrypted code.

Uche
10 Jun 2017, 11:25

code security

cAlgo files can be reverse engineered with the right tools and skill,all you can do is to make it harder for people to do so.

Spotware
12 Jun 2017, 11:57

Hi to all,

cAlgo files are encrypted and can be decrypted only by cAlgo. Therefore it is not possible to be reverse engineered. Reverse engineering would be possible only if the files where obfuscated or compiled to native code, somehing which is not the case with cAlgo.

Harry Sty
19 Jun 2017, 08:26

RE:

Spotware said:

Hi to all,

cAlgo files are encrypted and can be decrypted only by cAlgo. Therefore it is not possible to be reverse engineered. Reverse engineering would be possible only if the files where obfuscated or compiled to native code, somehing which is not the case with cAlgo.

Any Turing based machines, of which cAlgo is a class of, or more generally pretty much all of our current compute architecture is based on, can be reverse engineered. The question is at what cost.

Even if encryption is added as a layer, you will still need to decrypt it to run. At that point, anyone adept enough can read the original intent of the cBot. The question is still the same, at what cost does the reader want to pay to read the code.

skoutz.rothchild
19 Jun 2017, 10:31

RE: RE:

Harry Sty said:

Spotware said:

Hi to all,

cAlgo files are encrypted and can be decrypted only by cAlgo. Therefore it is not possible to be reverse engineered. Reverse engineering would be possible only if the files where obfuscated or compiled to native code, somehing which is not the case with cAlgo.

 

Any Turing based machines, of which cAlgo is a class of, or more generally pretty much all of our current compute architecture is based on, can be reverse engineered. The question is at what cost.

Even if encryption is added as a layer, you will still need to decrypt it to run. At that point, anyone adept enough can read the original intent of the cBot. The question is still the same, at what cost does the reader want to pay to read the code.

What you say is theoretically correct but is knowledge of no practical usage. Everyone with computer science degree knows that but even if Spotware encrypts their files with a typical AES encryption algorithm, it will practically take enormous time to decrypt. No matter how much you invest. Quoting Wikipedia

"...This is a very small gain, as a 126-bit key (instead of 128-bits) would still take billions of years to brute force on current and foreseeable hardware. Also, the authors calculate the best attack using their technique on AES with a 128 bit key requires storing 2⁸⁸ bits of data (though this has later been improved to 2⁵⁶,^[28] which is 9 petabytes). That works out to about 38 trillion terabytes of data, which is more than all the data stored on all the computers on the planet in 2016. As such this is a seriously impractical attack which has no practical implication on AES security... "

 

Uche
20 Jun 2017, 11:48

calgo's code protection policy is all a whitewash,they still havn't answered my question on why non-obfuscated dll files in the calgo files I posted on this website was decompiled with a free software from Jetbrains.Don't believe everything they tell you,they are just running a business.

Spotware
21 Jun 2017, 12:45

Dear Uche,

There is no evidence that your cBots have been decrypted and decompiled. The most possible reason that your cBot code leaked is that you have accidentally uploaded it with source code. If you have a specific method that can decrypt and decompile a cBot, please share it and we will investigate.

BeardPower
22 Jun 2017, 06:03

RE: RE: RE:

skoutz.rothchild said:

What you say is theoretically correct but is knowledge of no practical usage

I assume he was not referring to breaking AES, but normal decryption with the key, which can be grabbed.
The decryption key needs to be stored somewhere, be it a passphrase or the hash of the passphrase. The .calgo files are used by cTrader/cAlgo, so they need to load and decrypt the files. To achieve this, they need the key, which means it has to be stored somewhere. The decryped/plaintext key is at some point available in RAM and so it can be grabbed.The attack vector is not the encrypted .calgo file, but the application, which is using/decrypting it, which is cTrader/cAlgo.

skoutz.rothchild
22 Jun 2017, 10:46

RE: RE: RE: RE:

BeardPower said:

skoutz.rothchild said:

What you say is theoretically correct but is knowledge of no practical usage

I assume he was not referring to breaking AES, but normal decryption with the key, which can be grabbed.
The decryption key needs to be stored somewhere, be it a passphrase or the hash of the passphrase. The .calgo files are used by cTrader/cAlgo, so they need to load and decrypt the files. To achieve this, they need the key, which means it has to be stored somewhere. The decryped/plaintext key is at some point available in RAM and so it can be grabbed.The attack vector is not the encrypted .calgo file, but the application, which is using/decrypting it, which is cTrader/cAlgo.

You are absolutely right even though I don't think this is what his point was. But again, good luck with that :) ! Even with decryption gone, you still need to pass through the obfuscation security layer... To be honest, I believe that most people would not undersand what a cBot does even if they were given the actual C# code. Personally I believe that Spotware's security is more than enough for cBots that in general do not cost more that some bucks to buy. More sophisticated strategies are usually offered through signals or pamm accounts rather that cBots. If you have such a valuable strategy that worths all this hacking effort and you sell it as a cBot then you are really running your business bad. 

Uche
22 Jun 2017, 12:49

I do advise to make sure codes are well obfuscated by testing with multiple decompilers because your algo's dll is always available once it's decrypted on runtime.

Also,only distribute codes you can afford to lose.

BeardPower
22 Jun 2017, 18:48

RE:

skoutz.rothchild said:

But again, good luck with that :)
 

cTrader/cAlgo is also just managed code, which eases decompiling and grasping through the decryption routines a lot.

Even with decryption gone, you still need to pass through the obfuscation security layer... To be honest, I believe that most people would not undersand what a cBot does even if they were given the actual C# code.

Don't forget that cTrader/cAlgo is not native code, but managed code. Decompilers/Disassemblers these days and their output are of such high quality, that obfuscation is pretty meaningless. I think a person, who is not able to understand/write C# code, would not bother with Reverse Engineering the code in the first place.

And you are totally right about the value, access to the source code has to people. We are not talking about the newest rocket science schematics here.
You always have to comply with the law regarding Reverse Engineering anyways.

cosmolev
25 Oct 2020, 20:50

RE:

Uche said:

I do advise to make sure codes are well obfuscated by testing with multiple decompilers because your algo's dll is always available once it's decrypted on runtime.

Also,only distribute codes you can afford to lose.

That is a good idea. C# Decompiler is also available online and so is the easiest to test.