FEATURED VIDEO

Sponsored By:


SLIDE SHOWS
These up-and-coming storage companies from the 2008 CRN Emerging Vendor list have a winning view on the storage space.
Solution providers interested in a refreshing take on VoIP from young, up-and-coming companies need look no further. The 2008 CRN Emerging Vendor list includes six VoIP vendors on the rise.
We picked the top of the line. Check out the these companies, selected from our database of 178 emerging vendors.
INSIDE CHANNELWEB
techcareers logo Search Jobs:


  

Post Resume|Employers

Recent Post:


Semiconductor Sales
Infinity Sales seeking Semiconductor Sales in Woodland Hills, CA
spacer

Review: V.I. Laboratories' CodeArmor


By Mario Morejon, ChannelWeb
4:29 PM EST Fri. Mar. 07, 2008
How secured are your .Net applications? By design, the .Net architecture is a hacker's paradise and there's little one can do with compilers for protection. Code obfuscation provides some level of protection by scrambling logic and making it hard to read decompiled code.

During a .Net compilation, the intermediate language provides extensive details on the source code. A simple decompilation is all that's needed to crack the metadata added into .Net executables and DLLs.

As the days of native executable dwindle, developers have to start getting used to encrypting source code. Developers who have made the transition between native binaries forget that the new environment is virtually open for hacking. Newbie developers entering the market are unaware of the security risks.

In conversation with VARs on internal systems in major corporations, reviewers discovered that security policies often miss encrypting production code and internal communication between applications. Often this oversight gives disgruntled employees an opportunity to access critical data or even enter malicious code in the applications. Let's just say that anyone with access to these applications can easily reverse engineer their code.

So what can IT managers do to mitigate this risk? Test Center reviewers examined V.I. Labs's CodeArmor to see if it can hamper a decompilation process. First, reviewers tested a simple class that we compiled into a library. We used Visual Studio 2005 Express edition. Reverse engineering .Net code took seconds with RemoteSoft's decompiler.

Here's a piece of the original source code "

We used CodeArmor to encrypt the DLL with the highest security settings. A simple wizard walks developers through the encryption process. CodeArmor provides multiple runtime settings such as multithreading, logs and various file extensions. The tool provides an encryption/decryption DLL and a authentication DLL that must be deployed with the original file.

We turned on the default DLL that embeds itself into the original file. Here's the result after decompiling the original code -

We got an error loading the DLL with the RemoteSoft decompiler, so we could not even see check the file.

We also received an error when we tried it with Dis#, which is another C# decompiling tool. Dis# was more accurate in approximating the source code than the RemoteSoft after decompiling the original code.

CodeArmor's technology also uses an anti-tampering algorithm, in addition to its encryption process to stop hackers from entering new functions at runtime. After several times comparing the unencrypted DLL with the CodeArmor DLL using a hex editor, reviewers were not able to manually decipher any metadata that could help us deconstruct the code.

CodeArmor's encryption and similar technologies should be made part of a security policy when developing .Net applications.


RATE THIS ARTICLE Worse 1 2 3 4 5 Better
CHANNELWEB MARKETSPACE >> (Sponsored Links)
ADVERTISEMENT




CHANNEL SERVICES >>