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

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.

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.

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.

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

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

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.

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

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.

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

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

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?

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?

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.

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. ;)

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.

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 :)

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

Quote:

---

Originally Posted by RobDog888

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 :)

Quote:

---

Originally Posted by 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...

---

I warned you I havent done much with security :D

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

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.

Quote:

---

Originally Posted by RobDog888

I warned you I havent done much with security :D

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 :)

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..

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?

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.

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.

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

VB Code:

<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

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

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...

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

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.

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

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..

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?

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.

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.

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

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.

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.

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

Quote:

---

Originally Posted by Pradeep1210

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.

Quote:

---

Originally Posted by esposito

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.

---

The .net version of visual basic is far more powerful then VB6. The language itself has many needed improvements and the library around it has gotten larger.

At some point and time you have to motivate your clients to upgrade or join the C++ bandwagon.

Quote:

---

Originally Posted by Maven

The .net version of visual basic is far more powerful then VB6. The language itself has many needed improvements and the library around it has gotten larger.

At some point and time you have to motivate your clients to upgrade or join the C++ bandwagon.

---

If the (commercial) software you are working on can be created in VB6, it does not make any sense to develop it in .NET because, if you did, you would just limit the number of your potential customers.

Delphi contains a lot of native controls very similar to those you can find in VB.NET and you can choose whether to produce native executables or .NET byte code. So, at some point and time, I will have to say goodbye to VB6 and concentrate on Delphi only.

Byte code can be just great if you program for yourself or your own company. Nevertheless, if your target is the general public, then developing .NET executables would mean shooting yourself in the foot. The reasons are only two: the "Framework size hell" and reverse-engineering of your software.

if you have the ability to install your application in the GAC, then there is a utility called ngen which compiles a .NET assembly into native code.

I think there are a few other considerations and such to take into account when doing this, but it is possible..

esposito, there is no "framework size hell"

The framework is a 1 time 25MB download... trivial by todays standards of downloading games off the web that weigh in at a few gigs....

the reverse engineering is not a big deal either, unless you have some secret algorithms in your application. Otherwise what does any app you have written really do that someone couldn't just write themselves versus reverse engineer?

If it is a matter of piracy, then native code won't stop that.. just look at windows or any other highly known commercial app that you can download off any given torrent site.


I sell commercial .NET written applications to my users, and I have not had any issues with the framework. The only issue I have had is when XP users did not have SP2, which is required for the .NET 2.0 framework, but by instructing them to get the service pack, I am helping them out keep their system secure, in addition to getting my software running on their machine.

Now I am not saying every VB6 app should be written over in .NET, but any new applications should be written in .NET otherwise you are just going to leave yourself in the dust... VB6 is already 3 VB versions old, and soon to be 4.

Quote:

---

Originally Posted by kleinma

if you have the ability to install your application in the GAC, then there is a utility called ngen which compiles a .NET assembly into native code.

---

Interesting. Does it allow you to get a standalone executable that does not need the Framework to run? Where can I get more info about ngen?

Quote:

---

esposito, there is no "framework size hell"

The framework is a 1 time 25MB download... trivial by todays standards of downloading games off the web that weigh in at a few gigs....

---

It all depends on your target customers. Believe me, some time ago, for testing purposes, I gave away a freeware organizer developed in .NET. Result: I was shelled with e-mails telling me they could not run the program. Please don't take for granted that people are willing to download 25 megabytes from the Web to make your app work. In most cases, they will just look elsewhere for less problematic software.

Quote:

---

the reverse engineering is not a big deal either, unless you have some secret algorithms in your application. Otherwise what does any app you have written really do that someone couldn't just write themselves versus reverse engineer?

If it is a matter of piracy, then native code won't stop that.. just look at windows or any other highly known commercial app that you can download off any given torrent site.

---

Reverse-engineering is a very big issue especially for developers like me, who sell software to the average citizen. .NET apps can be decompiled and reverse-engineered even by inexperienced amateur hackers, so you can be sure that your software will be cracked the day after you release it. Those who can crack a VB6 executable have much more experience and generally don't waste their time decompiling accountancy software like mine.

Quote:

---

I sell commercial .NET written applications to my users, and I have not had any issues with the framework. The only issue I have had is when XP users did not have SP2, which is required for the .NET 2.0 framework, but by instructing them to get the service pack, I am helping them out keep their system secure, in addition to getting my software running on their machine.

---

I understand you get in direct contact with your customers. On the contrary, my customers find my software either on CD-ROM's attached to Italian computer magazines or download it from the Web. After installation, my software MUST WORK IMMEDIATELY, otherwise I lose a customer.

Quote:

---

Now I am not saying every VB6 app should be written over in .NET, but any new applications should be written in .NET otherwise you are just going to leave yourself in the dust... VB6 is already 3 VB versions old, and soon to be 4.

---

New applications should be written in Delphi. It's the best investment I can see for the foreseeable future.

Quote:

---

Originally Posted by esposito

New applications should be written in Delphi. It's the best investment I can see for the foreseeable future.

---

The following article is an extract from one of the most popular Web sites dedicated to Delphi:

Quote:

---

What to do for a new application that needs to run on Win32 today, .Net tomorrow

What to do for a new application that needs to run on Win32 today, but that will eventually migrate to .Net sometime in the future? This isn't an unreasonable question -- shoot, it is probably very common. There are certainly new development projects being started everyday, and .Net looms out on the horizon for all of them. It is also a question that is tough for Microsoft shops to answer. While the .Net Framework is readily available, it is certailny not ubiquitous, and there are plenty of machines out there in the corporate world, small businesses, and homes that can't even handle the .Net Framework and that won't be able to handle it for sometime yet. That means that Win32 may be the only option for new development. However, anyone starting new development today probably will want to be able to migrate that app to the .Net platform in the future. If you choose C++ or VB6 for the Win32 version, there simply is no easy way to migrate that application to .Net. Any Microsoft-based development solution for the Win32 platform today means pretty much a complete re-write for that application when it comes time to migrate it to .Net.

But hey, there is a solution -- a non-Microsoft one -- to this problem: Delphi. Delphi provides a powerful, fully-capable Win32 development platform, and with the VCL for .Net, a much, much smoother migration path for Win32 to .Net. And when you do move to .Net, Delphi 8 for the .Net Framework provides powerful tool that is a first class citizen in the .Net development world. If you are starting a new development project in Win32, and need to be able to move that project to the .Net framework some time in the future, then Delphi is your only real choice. Microsoft-only development organizations quite conspicuously have no similar choice. The VCL is cross-platform -- at least between Win32 and .Net. Applications build in Win32 using Delphi and the VCL should migrate relatively smoothly to the .Net platform today . VCL for .Net exists, and has been available to Delphi 7 owners via the Delphi for .Net Preview since last summer.

Now I am not at all claiming that the migration will be totally seamless -- you may need .Net version of third-party components, and if any of your code calls into the Win32 API directly, you'll need to update that. In addition, not all of the technologies that were in Delphi 7 will make it into Delphi 8, and certainly the presence of garbage collection in the .Net framework may affect the way your code works, but the migration is clearly not a complete rewrite as discussed above. Heck, at this year's Borland Conference, they compiled and ran in Delphi for .Net an application that was originally a demonstration application for Delphi 1 -- a 16-bit development tool! Can't get much more compatible than that.

This fact alone ought to be changing the way that developers and companies view Delphi. Delphi will drastically lower the overall total cost of a project by drastically reducing the time and effort needed to migrate a Win32 application that needs to be built today to the .Net framework tomorrow. Delphi doesn't lock you in to either Win32 or .Net and doesn't force you to move to .Net faster than you or your budget might want you to. Delaying the transition to .Net can also save money, as building applications in Win32 now for existing hardware can extend the life of that hardware rather than accelerating the hardware upgrades to run the .Net Framework.

Smart managers already know that they are stuck in a tough spot and smart Delphi developers will be quick to point out the advantages of using Delphi for new development. So if you have been looking for that silver bullet to convince your managers or your customers to use Delphi as the development tool for that upcoming project, you now have it.

---

What are these hackers doing to your software once they reverse engineer it?

esposito, keep in mind that when you didn't have the .net 1.0 or 1.1 framework installed and tried to launch a .net exe, you would get a weird cryptic error. In the .NET 2.0 framework, they have added an error handler to tell the person they need the .NET 2.0 framework installed.

It is not a full solution, but it does make things a bit easier

Also, anybody who has ever done automatic updates will have all the frameworks, in which case nothing extra will get installed, just like VB6. If the VB virtual machine ever stops being bundled with the OS, which may happen, then your VB6 progs will stop working as well.

I see the point about the reverse engineering. People don't actually have to reverse engineer anything to steal your software, though it would make it a bit easier if you happen to be including some kind of embedded passcode that allows operation. In that case, they could reverse engineer your code, and strip out the protection parts. Or they could just re-write the program, as they would need to do practically that anyways. What else would they gain from reverse engineering?

Quote:

---

Originally Posted by esposito

If the (commercial) software you are working on can be created in VB6, it does not make any sense to develop it in .NET because, if you did, you would just limit the number of your potential customers.

Delphi contains a lot of native controls very similar to those you can find in VB.NET and you can choose whether to produce native executables or .NET byte code. So, at some point and time, I will have to say goodbye to VB6 and concentrate on Delphi only.

Byte code can be just great if you program for yourself or your own company. Nevertheless, if your target is the general public, then developing .NET executables would mean shooting yourself in the foot. The reasons are only two: the "Framework size hell" and reverse-engineering of your software.

---

The only way this holds true is if your developing some kind of legacy software that nobody new to the market is interested in. It's pretty much a safe bet that .net will provide more options and more efficiency to customers who are willing to make the move.

Companies that refuse to make the move are shooting themselves in the foot and will one day come to regret not keeping their IT updated. Because one day their going to wake up and find that they have problems finding old obsolete parts for their old systems, their software will become increasingly difficult to maintain and expand due to less and less people who deal in old technology, security problems, not to mention documentation which eventually becomes quite rare. In a nutshell once a company digs themselves into a digital hole, it will cost them a fortune to pull their company back out of it.

.NET solves a lot of these problems for companies and individuals alike. You can access this framework from visual basic, C#, and even C++. It's an umbrella under which you can create a solid system on with the knowledge that your not gong to be tying yourself into a certain version of a certain language. It's simply a good move for both the software developer and the costumer alike.

I don't know who it was that said "The customer is always right". That's simply not true, the customer is not always right, it's just your job to make them think they are. So make them think they are right to go with .net. It'll be better for you and them, even if they don't realize it yet.

Quote:

---

Reverse-engineering is a very big issue especially for developers like me, who sell software to the average citizen. .NET apps can be decompiled and reverse-engineered even by inexperienced amateur hackers, so you can be sure that your software will be cracked the day after you release it. Those who can crack a VB6 executable have much more experience and generally don't waste their time decompiling accountancy software like mine.

---

#1. If your doing this in hopes that it will protect some algorithm from competitive companies, think again! The only way you can get protection from this is through legal options. Patents, trademarks, and copyrights are the ONLY way to protect yourself from this. Anything else is just an illusion of security that doesn't exist at ALL.

#2. If your doing this out of concerns of piracy, think again! There is by far more documentation on how to crack native code then there is on byte code. Go do a little research and you'll find that it's childishly simple to crack a native executable. It's just about completely point and click. They load things up in a disassembler, do a search, and poof... They simply hex out the results by entering in a value. In fact, 99% of the people who provide all the cracks to warez, DON'T KNOW ASSEMBLY! They just use a combination of 2-3 programs and can crack a program with one of the many tutorials floating around on the internet. Again the only protection you can obtain from this is by legal options. At that point you can send a DCMA take down notice and force their ISP, hosting servers, etc to remove that content.

Quote:

---

I understand you get in direct contact with your customers. On the contrary, my customers find my software either on CD-ROM's attached to Italian computer magazines or download it from the Web. After installation, my software MUST WORK IMMEDIATELY, otherwise I lose a customer

---

Then why not include the .net library in your install package just like you would any other library that your program makes use of? During the install process a check is made to see if the user has .net on their machine... if not then install. For example... I can go out and buy a video game and not have to worry about going to Microsoft to download the latest version of direct x, the video game developer has included the latest version at time of release with their install package. So it installs if I don't already have the latest version of direct x.

Quote:

---

Originally Posted by Edneeis

What are these hackers doing to your software once they reverse engineer it?

---

They just share it through peer-to-peer software.

Quote:

---

Originally Posted by kleinma

esposito, keep in mind that when you didn't have the .net 1.0 or 1.1 framework installed and tried to launch a .net exe, you would get a weird cryptic error. In the .NET 2.0 framework, they have added an error handler to tell the person they need the .NET 2.0 framework installed.

It is not a full solution, but it does make things a bit easier

---

Yes, it does. But the problem with the Framework size still remains and, as I said, a lot of people don't feel like downloading (and installing) tens of megabytes for an accountancy application.

Quote:

---

Originally Posted by Shaggy Hiker

Also, anybody who has ever done automatic updates will have all the frameworks, in which case nothing extra will get installed, just like VB6. If the VB virtual machine ever stops being bundled with the OS, which may happen, then your VB6 progs will stop working as well.

---

This is only partially true. I thought everybody who had XP SP2 also had the Framework installed on their machine, but I found out that the updates are selective and you can choose which patches you want to download. The only OS that is surely equipped with all versions of the Framework is Vista but, before it "overcomes" XP, we'll have to wait for a long time.

Quote:

---

I see the point about the reverse engineering. People don't actually have to reverse engineer anything to steal your software, though it would make it a bit easier if you happen to be including some kind of embedded passcode that allows operation. In that case, they could reverse engineer your code, and strip out the protection parts. Or they could just re-write the program, as they would need to do practically that anyways. What else would they gain from reverse engineering?

---

As I said, I am talking about amateur hackers who just want to show how good they are at cracking software. For developers like me, they are extremely dangerous because, after having cracked your software, they usually like sharing it with as many people as possible.

Quote:

---

Originally Posted by Maven

The only way this holds true is if you're developing some kind of legacy software that nobody new to the market is interested in. It's pretty much a safe bet that .net will provide more options and more efficiency to customers who are willing to make the move.

---

My software does not need any special advanced function that VB6 is unable to give me. My software only deals with issuing invoices, printing fiscal receipts, managing libraries, bookstores, video rental shops etcetera. I don't need the "overkill" provided by .NET. My only concern is that MS could break compatibility with VB6 applications in the future. If it were not for this concern of mine, I would just stop complaining about the "threat" of being forced to switch to .NET. I would just ignore .NET and go on along my way.

Quote:

---

.NET solves a lot of these problems for companies and individuals alike. You can access this framework from visual basic, C#, and even C++. It's an umbrella under which you can create a solid system on with the knowledge that your not gong to be tying yourself into a certain version of a certain language. It's simply a good move for both the software developer and the costumer alike.

---

All I need is a programming language that allows me to create standalone software, possibly hard to crack. The rest is marginal. From this point of view, Delphi seems to be more reliable than .NET. People like me don't like byte code otherwise we would have switched to Java more than ten years ago.

Quote:

---

I don't know who it was that said "The customer is always right". That's simply not true, the customer is not always right, it's just your job to make them think they are. So make them think they are right to go with .net. It'll be better for you and them, even if they don't realize it yet.

---

The customer is not always right. The customer is only very pragmatic and looks for the most convenient and less time-consuming solution on the market. The Framework is an obstacle to the deployment of your software and tends to irritate the impatient customer.

Quote:

---

If your doing this out of concerns of piracy, think again! There is by far more documentation on how to crack native code then there is on byte code. Go do a little research and you'll find that it's childishly simple to crack a native executable. It's just about completely point and click. They load things up in a disassembler, do a search, and poof... They simply hex out the results by entering in a value. In fact, 99% of the people who provide all the cracks to warez, DON'T KNOW ASSEMBLY! They just use a combination of 2-3 programs and can crack a program with one of the many tutorials floating around on the internet. Again the only protection you can obtain from this is by legal options. At that point you can send a DCMA take down notice and force their ISP, hosting servers, etc to remove that content.

---

Those hackers can only delete code and can't write the missing parts. On the contrary, reverse-engineering gives you the possibility of getting the plain .NET source code, modifying/integrating it and compiling it again. Sorry, this is too much.

Quote:

---

Then why not include the .net library in your install package just like you would any other library that your program makes use of? During the install process a check is made to see if the user has .net on their machine... if not then install. For example... I can go out and buy a video game and not have to worry about going to Microsoft to download the latest version of direct x, the video game developer has included the latest version at time of release with their install package. So it installs if I don't already have the latest version of direct x.

---

My software is usually published on CD-ROM's together with plenty of other software. No publishing house would ever accept to include the Framework together with my app.

Quote:

---

Originally Posted by esposito

My software is usually published on CD-ROM's together with plenty of other software. No publishing house would ever accept to include the Framework together with my app.

---

They are shooting themselves in the foot then.

That is like saying you made a game, but the publisher won't allow directX to be distributed along with it...