Re: Which is more secure against decompiling .Net or 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.
Re: Which is more secure against decompiling .Net or VB6?
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.
Re: [RESOLVED] Which is more secure against decompiling .Net or VB6?
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.
Re: [RESOLVED] Which is more secure against decompiling .Net or VB6?
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.
Re: [RESOLVED] Which is more secure against decompiling .Net or VB6?
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.
Re: [RESOLVED] Which is more secure against decompiling .Net or VB6?
What are these hackers doing to your software once they reverse engineer it?
Re: [RESOLVED] Which is more secure against decompiling .Net or VB6?
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
Re: [RESOLVED] Which is more secure against decompiling .Net or VB6?
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?
Re: Which is more secure against decompiling .Net or VB6?
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.
Re: [RESOLVED] Which is more secure against decompiling .Net or VB6?
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.
Re: [RESOLVED] Which is more secure against decompiling .Net or VB6?
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.
Re: [RESOLVED] Which is more secure against decompiling .Net or VB6?
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.
Re: Which is more secure against decompiling .Net or VB6?
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.
Re: Which is more secure against decompiling .Net or VB6?
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...
