Securing the source code

Anna Ivanova

I 've been assigned the task of evaluating MAGIC-XPA for desktop applications and I 'm currently collecting information for my presentation.
So far I didn't find much information on how secure is the source code from unauthorized access.
My questions so far are: 
1) Is it possible to secure the sources within the studio, i.e. set as read only or invisible to unauthorized users?
2) Is there any possibility to reverse engineer the ECF? Is there any compilation switch that removes debug information and any readable symbols from it? 
Thanks you for your help 
Anna Ivanova

Andreas Sedlmeier

Hi Anna,

Re 1 ) In Xpa you secure your sourcecode from unauthoried (read / write) access like you do with any other tool, programming language. You use a version control system and limit access to there. If you work with local copies on the development machines, you have to protect those too (like with harddisk encryption, ....).

Re 2) Nobody really knows I think, besides the vendor, and I think they *can* actually reverse engineer from .ECF almost completely - maybe comments/remarks are missing. What kind of encryption is used is unclear, where the encryption key(s) reside ... too.

If these are real issues you can obfuscate the XML sources yourself by writing a tool.  Compared to (f.i.) Java and .NET your code is probably "safer" in Magic - there's only the bitter aftertaste that the vendor does not document these things, ... Security by Obscurity ^^

In your applications you will have to make sure that users cannot modify the .INI files and/or commandline. Otherwise they can enable logging and flow-monitor output and again would get information from the source (and data), ...

Best regards,



Compared to (f.i.) Java and .NET your code is probably "safer" in Magic

Not so sure about that.
Magic has no Obfuscating mechanism and a poor Version Control support. Also, if you write some code and want to copy and past it to another program, it can be very painful as you keep losing some variables and any .Net code will stop working randomely.

-Obfuscating Java :
-Obfuscating .NET : DotFuscator Pro, SmartAssembly, XenoCode, Salamander. Back with .Net 1.1 obfuscation was essential: decompiling code was easy, and you could go from assembly, to IL, to C# code and have it compiled again. Since .Net 3.5 Try decompiling a 3.5 assembly; what you get is a long long way from compiling.

Andreas Sedlmeier

Well I wrote "maybe" anyways ^^ Magic has no ofuscation for the .ECF, Magic has encryption and that you have to break before "decompiling" (in quote because Magic does not compile anyways). I just fear that that wont be that hard resp. wont resist serious reverse-engineering and advanced debugging. Its a symmetric encryption with the keys somewhere stored in the application / Magic binaries. I do not really consider this a big issue however, code should be open anyways :). The bigger issue in this context is that you cannot digitally sign your Magic application. 

Question is too if you actually deploy anything to desktops anymore - or if you have Magic only on the server.


Anna Ivanova

Hi and thanks for the helpful replies. 
I do agree that code should be open anyways