[RESOLVED] Which is more secure against decompiling .Net or VB6?

[dac9901]

Hi Everyone,

I have programmed in both VB6 and VS2005 .Net. I am creating a new application but can't decide which vb version to use. I've heard .Net app's can be easily decompiled if one does not use an obfuscation.

The program I am creating will be sold for around $250. I like programming in .Net better than VB6 but the lack of security concerns me.

Is VB6 just an vulnerable as .Net?

I would appreciate any thoughts or ideas.

[circuits2]

Security comes from your coding techniques, not simply the language. Both can be decompiled by MSIL so it is up to you to encrypt sensitive data. However, there should be no question as to which one to use, especially if you intend on selling the app. VB2005 will provide better longevity and easier maintenance.

[dac9901]

Thanks for your reply Circuits2.

I will be using a dongle to protect against license infringement. Do you recommend any software to obfuscate the source code.

Thanks in advance for your help.

[sspoke]

VB.NET is extremely easy to decompile as you get the full source code.. VB6 is not fully decompilale unless you know very good assembly.

as obfuscation goes I think its all useless...

I recommand getting a packing program which has no cracked unpackers those make it harder to decompile.. unless the hacker can dump memory correctly. A good packer goes for 700$ usd I forgot its name but its Softsentry something

[dac9901]

Sspoke,

What decompiler software do you use to retrieve the source code from .Net. I have created a .net app in the past. I would like to try some security and then try to decompile it. Any recommendations?

Thanks,
Clint

[sspoke]

you can try the first google topic

http://www.remotesoft.com/salamander/

Notice look at that site option!

[ ] de-obfuscate(turn any obfuscated code into recompilable format)

just upload your application and it will decompile some of it as a demo.. I had some executable program which I found off sourceforge which was comepetely free.

[circuits2]

A .NET app can be decompiled by using the MSIL disassembler Ildasm.exe

[RobDog888]

VB 6 apps are next to impossible to decompile but you can get close. .NET apps are easier for the common person to decompile but still again with obfusication and string naming they can only get close.

[Merrion]

Surely the biggest threat is someone just copying and distributing the executable?

[dac9901]

RobDogg,

According to Salamander(Remotesoft) they can decompile even obfuscated exe's. Is there any security that can be added to .NET that can't be decompiled easily? Obviously no source code is unbreakable. I am only concerned with the average "joe" hacker being able to decompile my .Net executable. When there is commercial software to decompile even obfuscated executable's it makes me wonder if I should develop in VB6.

Thanks,
Clint

[dac9901]

Are there any obfuscation solutions that can't be easily reversed using a decompiler like Salamander? I am leaning towards developing VB6 instead of .NET unless I can find a decent obfuscation software.

Any thoughts?

[RobDog888]

Well they may be speaking of the free included obfusicator as there are several good ones out there but they cost a few thousand dollars.

You can also use the sn.exe Strong Naming utility. I havent used it yet but it helps to throw in whatever you can to prevent easy reading.

Do you have a registratiion scheme in place already?

[dac9901]

RobDogg,

I will be using a security dongle to protect against license infringement. The Dotfuscator(free edition) can not be distributed with a commercial application. The Dotfuscator professional edition is $1890.00. I will take a look at the strong naming utility. Thanks for your help.

[RobDog888]

Np, but as I mentioned, security is something I havent really got into. Kleinma has done allot with security for distribution of apps. If you need more perhaps he will see the thread and add his 2 cents.

[kleinma]

Just an FYI, but strong naming won't make your exe any more secure than not strong naming it.

strong naming just gives it a unique name so another app can't pretend its your app...

There is a pay app called cliSecure
http://www.secureteam.net/
They have a full working demo

I don't know how "crackable" it is, but it uses some sort of pre CLR encryption/decryption, which means its decrypted at runtime to pass the code to the CLR to run on the .NET framework.

ILDASM doesn't work to view an exe/dll that has been encrypted. You could try other decompilers to see if they work.

I had talked to someone at MS about the whole "security" thing and they said that it has not become much of an issue of concern, and it is how other framework based languages, like Java has been from day 1

If you have a hardware dongle, then you are already in pretty good shape..

There are other methods.. one method I have messed around with, but not perfected, is using my code signing certificate.

I bought one from 100 bucks, so I can sign my exe's with a digital certificate.

So I did some testing of signing a given EXE with a cert, and then getting a hash code as a string, and storing it in my dll that the exe references. When an object in the dll is created, I validate that the calling exe has a cert that matches the hash code I specified.

it worked, but in my preliminary testing, it was rather slow. I have been too busy to continue work on that at the moment, but it should let you know that there are a few ways you can do things, and the more clever you are, the harder it would be for a hacker to figure out what's going on.

The other question that always seems to come into play is how much do you actually NEED to protect your source code.

By taking a few steps, you will likely make it harder to decompile and figure out the source code, than it would for someone to just write it themselves.

Lets face it, anyone with enough skill to totally decompile your obfuscated app into totally understandable and readable source code could likely just have written the app themselves in less time.

If you have some amazing secret algo that your app uses that is top secret or something then I suggest one of the 2 things:

1) Make your app require a web connection, and keep your algo in a dll via a webservice. The windows app invokes the webserver to send the needed data, and return the correct value. The algo never touches their machine, its all done server side.

2) write a dll for your "secret" code in VB6 or another non IL language, and reference that DLL in your .NET app. I doubt anyone is out to steal your GUI when they could just copy it if they really wanted.

Hope all this helps.. I am going through some of the same stuff now, but my concerns have been alleviated a little bit though my research.

[Pradeep1210]

Though this is off topic, I think this is worth mentioning...

I have myself worked on a VB6 application with dongle in a commercial application.

The biggest challenges were:
1. All customers didn't like the heavy .NET framework to be installed on their systems for some reson or the other.
2. Many were using very old systems like P2, P3, Celeron, some even P1 and 486. All they cared was that my app should run on their system. The VB6 runtime is quite small compared to huge .NET. So VB6 was the way to go instead of .NET at this moment.

So if you intend to use it in a commercial app, I would recommend using VB6.

Pradeep

[RobDog888]

Weel although that can be true for your experience I would think it depends on the target audience?

[Pradeep1210]

Weel although that can be true for your experience I would think it depends on the target audience?

Yes true, but one of the biggest concerns of a commercial application vendor to whom the target audience is not known. You won't like to loose a large section of clients just because they are using old hardware or they are reluctant to install .NET framework on their systems.

Pradeep

[RobDog888]

Just an FYI, but strong naming won't make your exe any more secure than not strong naming it.

strong naming just gives it a unique name so another app can't pretend its your app...

I warned you I havent done much with security

But sn does help keep someone from using your dlls in their apps so it could be considered part of security.

[kleinma]

I haven't seen giving a strong name prevent usage in an app

and if you are talking about that while LinkDemand custom attribute thing you can do above your classes, not only is it a royal pain in the butt because you can ONLY put it at the class level instead of the assembly level (explain that to me please) so you have to indicate it for every class in your dll that you want to have linked to your SN.

ok so that may not be the end of the world, however, I can no longer get the whole link demand thing to work. It worked in 2003, however when I upgraded my testing project to 2005, it failed to work anymore...

I think a codeproject article that demonstrated this issue had a comment where someone stated the same thing, that it wasn't working in 2005.

Again this is one of those things I haven't had enough time to mess around with to figure out all the details.

[Pradeep1210]

I warned you I havent done much with security

But sn does help keep someone from using your dlls in their apps so it could be considered part of security.

Not exactly.

They could still use your dlls. Infact the prime purpose of strong names is to register your dll globally. For private assembiles you won't need a strong name

The strong name just helps generrate a GUID for the dll so that it can be registered in the GAC and used at a global system level. (similar to previous MTS)

Pradeep

[kleinma]

the very fact that CAS can be totally turned off by the end user would make any attempt to use code access security as the lock on your app totally useless...

Also COM doesn't use CAS, so if you expose your objects to COM, then CAS can't be used to verify the process creating your objects, and therefor will also be useless..

[RobDog888]

So the bottom line is there is no security in .NET that can keep the average hacker out.

That link you posted Matt does it work like a wrapper around your exe or something?

[kleinma]

I don't know its exact inner workings, however I do know it does make your exe a bit larger.

My guess it adds some sort of descrabler into your code, so when the exe is executed, the first action taken by the system is to decrypt the code, then pass it to the CLR.

This likely has some impact on performance, but I haven't tested that. I just found that app in my research on this whole topic.

[kleinma]

Here I found an article which talks about why using StrongNameIdentityPermission attributes to verify callers have the specified strong name doesn't work anymore in .NET 2.0

http://blogs.msdn.com/eugene_bobukh/...06/415217.aspx

CAS is pretty useless unless its in a nicely configured corporate environment... The average joe PC end user is going to have default permissions set for .NET which is full trust on the local drive, partial trust on network drives.

[kleinma]

I will post more info as I find it here, and hopefully put together some sort of tutorial on the best way to tackle at implementing as much security as possible in .NET without compromising the performance or ability of the app itself.

so far I have been able to successfuly validate any calling DLL against the caller to match strong names. There is a small performance hit, but I am trying to close that gap as much as possible. If I create 100,000 objects with no checking, it takes (about) .17 seconds, if I create the same amount with the check, it takes about 7 seconds.

Now if you were doing a loop, creating the same type of object over and over, that could be an issue, however bringing the number of created objects down to something more real world, like lets say 100 or even 1000, and its creates them all well under a second.

I also found in 2005, you can add an assembly level directive

<Assembly: System.Runtime.CompilerServices.SuppressIldasm()>

Now this simply disallows anyone from using the ildasm utility on your .NET assemblies. It doesn't do anything to block a 3rd party disassembler, but it's a start I suppose, since it wasn't included in .NET 1.1

[Genom]

kleinma sorry but I am still learning VB.Net how can I use this code?
<Assembly: System.Runtime.CompilerServices.SuppressIldasm()>

[kleinma]

Genom, that is an assembly level directive, so you have to add it to your AssemblyInfo.vb file of your project.

To get to that file, in the solution explorer you need to click the icon for "Show All Files" which will then make the "My Project" node of your project expandable to see the files under it.

When you expand that node, you will see AssemblyInfo.vb. Open that and add that directive to the bottom.

However if you are REALLY trying to make sure your app is as secure as possible, then I would recommend you learn all about code obfuscation. Because supressing ILDASM is nice and all, but it doesn't stop any other decompiler...

[Genom]

thanks very much I have found Aspose.Obfuscator and it is free as it says.
Aspose.Obfuscator

[kleinma]

I know they used to offer that for free (but not support) and I know you can still download it, but you might want to check on their site because I am pretty sure I remember them stating something like it was also no longer being developed any further (it might not even work for .NET 2.0 apps, I am not sure)

If you have the full version of Visual Studio, then you can use the free version of Dotfuscator that is packaged with it. I don't think its packaged with VB 2005 express though.

I have used several obfuscators and theirs is so far the best I have used.

[Genom]

no its a pitty taht i use express edition. If I can earn some money I will buy pro edition...

[kleinma]

All other code obfuscators I have tried have all sucked pretty bad to be honest. Either they had horrible limitations, or they just didn't work right, or were really cryptic on how to use them.

Even the one that comes with Visual Studio (which for the record is simply packaged with it and NOT a Microsoft product) took me a little while to figure out, but they seem to be the best one...

You also have to determine how big a deal it is if someone can decompile your app.... If your app isn't doing anything that amazing, and you aren't protecting any intellectual property like some math algorithm, then it might not be that big a deal..

[RobDog888]

So Matt, have you used any expensive obfusicators? If price isnt an issue is that any out there better then the packaged on in VS?

[kleinma]

No I am too poor to get the full version of their obfuscator, but if I had it, it would make my life easier.

The free one doesn't support incremental obfuscation. What that does is uses an XML file on your dev box to map the name scrambling it does. So if you have an exe and a dll, and you obfuscate them both, then make a change to the dll, you can obfusctate just that one (and hence not have to redistribute the exe as part of an update, just the dll) and it maps it all correctly. With the free version I simply have to obfuscate all the dlls and exes everytime there is an update, and redistribute them all.

My main commercial apps aren't huge in overall size, so its not horrible to deal with this limitation.

The full version also supports encrypting string constants in your exe, like connection strings and things like that (not that you should ever hard code connection strings in an app )

So I just use my own symmetrical encryption/decryption class for any string constant that could be considered "sensitive", and hard code the strings encrypted and decrypt them at runtime.

So most of the limitations that affect me I have found work arounds, but the full version would be nice, and there are probably features I don't even know about.

If you do use the free dotfuscator, I recommend registering it at their site because it will give you access to download the latest patches for it.

[RobDog888]

So you think its worth the Single User license price of $1,890 for the full version for use on commercial apps or just stick with the free version?

Good stuff on the encryption capabilities.

[Slaine]

I use spices.net to do my obfuscation and can thouroughly recommend it.

[kleinma]

If you can afford a commercial grade obfuscator, it will no doubt make it easier for you to protect your IP better....

However the commercial apps I write are not the type of apps that johnny hacker is going to try to crack, because they just don't cater to that type of industry (like games, operating systems, and other app categories do)

That is why for now I dont shell out any extra cash for a full blown obfuscator.

[Maven]

All programming languages are vulnerable to reverse engineering. That is just a simple fact of programming life. The most that you can do is add a few things to throw off a, quite honestly, old fashion decompiler. Most of the better decompilers such as IDA Pro don't get thrown off so easily.

I don't know why companies continue to waste their time and money on silly protection schemes that wont survive 2 seconds in the wild. I can go out right now and download the best version of vista, visual studio, or any other name brand application. These companies have invested enormous amounts of money in this area for years, and for years I've been able to download it along with various cracks to point and click away their grand security of the day. The only person they end up annoying is the person who actually pays for the program. For example: I upgrade my computer and had to do a format. Well I ended up having to call Microsoft because XP had been installed so many times and it wouldn't let me do it again.

The only thing that I can reason is companies do this to impress stock holders, not because of some notion that this provides some great security. The only way that you can protect something in a limited fashion is if it stays encrypted at all times, and only gets decrypted in some secure chip located on the processor. Even at that point however, it would only take someone who knows the difference between a resistor and a transistor to pull out the private keys of the chip and decrypt the code. At the end of the day, there is never going to be reliable security for trade secret protection.

The best thing you can do is invest that money into legal protections through patents, trademarks, and copyrights.

[superbovine]

You could make it open source or free and just sell support.

[esposito]

Yes true, but one of the biggest concerns of a commercial application vendor to whom the target audience is not known. You won't like to loose a large section of clients just because they are using old hardware or they are reluctant to install .NET framework on their systems.

Pradeep

Wise words. This is the exact reason why, after so many years, I am still reluctant to switch to .NET.

MS said this is not a major concern, but in my opinion it is very dangerous to develop commercial applications in byte code, unless you want to give away your software to the dogs.

There used to be a very good packager called Thinstall 2.0 that allowed you to get a standalone native executable from a .NET application. The size of the resulting exe was quite small, so it looked to me like the best solution to the problem of deployment.

Unfortunately, Thinstall 2.0 is incompatible with Windows Vista and the next version, Thinstall 3.0, works in a completely different way: it obliges you to install and unistall the Framework everytime you want to package a .NET exe (can you imagine how long it takes?) and the size of the resulting native exe is just enormous.

So, against my will, I still develop my applications in VB6, while doing some practice with Delphi, that I for one consider the only decent alternative to VB6.