Why VB 6.0??

Printable View

Show 50 post(s) from this thread on one page

June 25th, 2008, 04:49 AM
Joeman

Re: Why VB 6.0??

Quote:

IMO, as a developer you need to stay current with the latest technologies; otherwise you are going to find that work is harder to find.

What do you mean that I won't beable to find work in c++ because it is older than me? really? All of you have mentioned was very small fragments about way the .net is better. I know it is 10 or so years old, but it seems to me it is pretty solid and can't be bashed very well besides that it is missing a few features. This is pointless. If a newbie wants to program in the .net, I don't mind that, but asking them not to use vb6 is just wrong. Oh and cpuwizard, your little code with asm put in doesn't mean it compiled to asm.

If you don't believe me, here are more post online in other places like msdn:
http://forums.msdn.microsoft.com/en-...-2b5d37c369c6/
http://www.physicsforums.com/archive.../t-204727.html
http://www.antionline.com/showthread.php?t=270787

After a bit of reading, that is enough proof you have a bigger and faster chance to decompile a .net app than c++.

See they put msil in the exe which this is so simple to convert back
http://msdn.microsoft.com/en-us/libr...k1(VS.80).aspx
look at that. microsoft allow you to get your original source code back and it uses their on tool.

Here is a more popular .net decompiler http://www.aisto.com/roeder/dotnet/

I could go on and on, but since you(cpuwizard) support microsoft from head to toe with your little badge from microsoft, I see no point in to say all the proven things over. Next time I will give you more links.

Quote:

By technology islands, I mean having to learn the various types of technologies in order to be able to produce a professional application - things like COM, DirectX, Network api's, Printing api's, GDI, and so on.

.Net just brings these disparate technologies into a more cohesive coding environment.

Vb6 has all of those. What are you talking about... and they are cohesive.
June 25th, 2008, 05:31 AM
metalmidget

Re: Why VB 6.0??

I had to learn VB6 for school last year, and I had a lot of fun with it as my first programming language.
These days I almost exclusively use C++, although the one thing I still do use VB6 for is the occassional.... 'proof of concept' I guess, for testing the basic logic of an algorithm.
Eg- Most of what I do is creating games purely as a hobbyist, and when I began creating a 2D collision detection system for my (C++) games, I started off (in VB6) by putting some shape controls on a form, setting them up to move with the keyboard, and using if statements in a timer, testing .Left .Width etc etc and turning them red when they collide.
Everything involved in that other than the actual if statements themselves is so mind-numbingly easy for anyone with the tiniest bit of VB6 experience, that you can focus on just the bit you're trying to get right. In a more complex system that uses C++ and DirectX, it's more difficult to create a system that you know is 100% bug free so that you can be 100% sure that if something is going wrong it's because of the exact few lines of code that you're implementing at that exact point in time.

TL;DR: I find that VB6 still has its uses, but only during development, not in a finished product.

metal
PS- having re-read that, I realise that vb.net and C# may well be just as good for the sort of thing I've described. Personally I haven't bothered to learn either of them (yet), so I wouldn't know.
June 25th, 2008, 06:26 AM
TheCPUWizard

Re: Why VB 6.0??

Quote:

Originally Posted by HanneSThEGreaT

... aren't even supported in .NET Framework 1.1. We are talking about .NET in general.

Actually that was never my intent at all. If people said they were migrating to xxx from vendor yyy that would have been expected.

The real point was legacy (un-supported) vs. current (with good future suport). Note that .Net 1.x is rapidly approaching the former....I would be nearly as suprised to find people developing new products aimed at 1.1
June 25th, 2008, 06:38 AM
TheCPUWizard

Re: Why VB 6.0??

Quote:

Originally Posted by Joeman

. Oh and cpuwizard, your little code with asm put in doesn't mean it compiled to asm.

You obvooiusly have never looked for yourself. That is the direct output from the debugger after hitting compile. Nothing was "put in" that is EXACTLY what executes for those C# lines.

Quote:

If you don't believe me, here are more post online in other places like msdn:
...After a bit of reading, that is enough proof you have a bigger and faster chance to decompile a .net app than c++....
See they put msil in the exe which this is so simple to conw: vert back
http://msdn.microsoft.com/en-us/libr...k1(VS.80).aspx
look at that. microsoft allow you to get your original source code back and it uses their on tool.

Yes, the FILE ON DISK contains MSIL (by default), but this is compiled to native code by JIT (Just In Time).

Even go back back and look at your post, and you acknolwedge that both C++ and .Net applications can be reverse engineered. Yes, by default it is easier to do this for a .Net application, but if there is motivation and skill then the differential is so small as to be insignificant in the hands of someone experienced (e.g. has logged over 100,000 hours developing software)

(btw: I have worked with and personally know many of the developers at Microsoft, I have also been published in MSDN (although it has been a few years - since before .Net in fact).
June 25th, 2008, 08:09 AM
GremlinSA

Re: Why VB 6.0??

Quote:

Originally Posted by Arjay

Now look at a guy like TheCPUWizard who has been in business for 35 years and imagine if he didn't stay current with new technologies? Do you think he would still be in business today if he only knew the languages/techniques that he learned in the first 5 years?

IMO, as a developer you need to stay current with the latest technologies; otherwise you are going to find that work is harder to find.

:thumb: :thumb: :thumb:
Agreed 100% ..

Staying current is key to keeping in business..

To compare to the current discution. Imagine a Electrical engineer opening a factory store where he manufactures and sell's 486 or P1 systems. 10 years ago he could have made a killing if his prices were comparable to the market. However today i doubt he'd make more than 1 sale, if!!..

VB6 has that look and feel that is, well VB6. and some people want the new XP or Vista look and feel that is easier to get with .NET...
June 25th, 2008, 09:34 AM
WizBang

Re: Why VB 6.0??

Quote:

Originally Posted by TheCPUWizard

Yes, the FILE ON DISK contains MSIL (by default), but this is compiled to native code by JIT (Just In Time).

That's just the point. What does it matter what's in memory, when the file contains MSIL? Change the file, and that changes what the compiler puts into memory.

Quote:

Originally Posted by TheCPUWizard

Even go back back and look at your post, and you acknolwedge that both C++ and .Net applications can be reverse engineered. Yes, by default it is easier to do this for a .Net application, but if there is motivation and skill then the differential is so small as to be insignificant in the hands of someone experienced (e.g. has logged over 100,000 hours developing software)

If a hacker spent 100,000 hours developing software, why would they resort to hacking someone else's work? Besides, MSIL is so much more vulnerable, just as Java is more vulnerable than C++. So with that ease of decompilation, any two-bit hacker will have a working copy of your source code far easier. It would no longer take such a dedicated effort.

Aside from your posts on this, everything I've read suggests .net is comparatively vulnerable. I'd think it would take a lot more proof than any person's statements on the forum to be convincing. Now, if you can post a .net file (not JIT output) which can't be decompiled by any of the various tools out there, that might be something.
June 25th, 2008, 09:53 AM
TheCPUWizard

Re: Why VB 6.0??

Quote:

Originally Posted by WizBang

Change the file, and that changes what the compiler puts into memory.

Applies to any environment, which is why any secure program MUST run security checks on the program and constant data sections of memory and refuse to run if tampering is detected.

Quote:

If a hacker spent 100,000 hours developing software, why would they resort to hacking someone else's work?

Because it can pay extremely well. The 100K figure quoted is actually based on my own work journal (109,872 as of this morning - starting June 24th 1977). My current "Reverse Implementation" charges start at $250/hr (US), and are only offered when the client has provided legal proof that they have a right to do so.

Quote:

Besides, MSIL is so much more vulnerable, just as Java is more vulnerable than C++. So with that ease of decompilation, any two-bit hacker will have a working copy of your source code far easier. It would no longer take such a dedicated effort.

A working copy of the default output from a managed language, I agree. Information is put into the file to allow for things such as reflection to work. This information should be stripped if there is a desire to stop people form having access. For a fair comparision, distribute your native applications with full .PDB files...

Quote:

Aside from your posts on this, everything I've read suggests .net is comparatively vulnerable. I'd think it would take a lot more proof than any person's statements on the forum to be convincing. Now, if you can post a .net file (not JIT output) which can't be decompiled by any of the various tools out there, that might be something.

Again we are back to a matter of degrees, and not absolutes as some other posters have been ranting about. This weekend i will post some samples of the output using various simple techniques to minimize what
is exposed, along with some simple examples of what can quickly be reversed engineered from a native C++ implementation of the identical program.

But if you want to run an experiment in the meantime. Take ANY .Net executable, run it through ngen.exe (which ships with the runtime) and examine the resulting .EXE file...

I think it is also important to look at the many commercial programs out there which do use .NET are written by responsible companies, and evaluate their "risk assesment" of any additional exposure resulting from using .NET.

Also consider Microsoft itself. When they released SharePoint 2003, it was based on .NET and was obsfucated to minimize the information that could readily be viewed (these were the only .NET assemblies shipped by Microsoft to be encoded this way). After a very short period of time, they realized that the negative impact of obsfucation (eliminating capabilities inherent in .NET assemblies simply because of the visibility) outweighed any "protection" of either Intellectual Property (and we know how possessive MSFT is) or of tampering.....

So, I agree with you in not taking the word of ANYONE. Investigate it for yourself. Look to see what applications have been successfuly attacked, and compare the percentages.
June 25th, 2008, 11:28 AM
WizBang

Re: Why VB 6.0??

Quote:

Originally Posted by TheCPUWizard

Because it can pay extremely well. The 100K figure quoted is actually based on my own work journal (109,872 as of this morning - starting June 24th 1977). My current "Reverse Implementation" charges start at $250/hr (US), and are only offered when the client has provided legal proof that they have a right to do so.

I'm sure "bootleg" copies which are being sold can be profitable, but what about the guys (who it seems have way too much free time on their hands) that hack a program, and upload it to any number of websites which more or less give the stuff away? Seems to me that's who we are mostly up against.

Quote:

Originally Posted by TheCPUWizard

A working copy of the default output from a managed language, I agree. Information is put into the file to allow for things such as reflection to work. This information should be stripped if there is a desire to stop people form having access. For a fair comparision, distribute your native applications with full .PDB files...

Again we are back to a matter of degrees, and not absolutes as some other posters have been ranting about. This weekend i will post some samples of the output using various simple techniques to minimize what
is exposed, along with some simple examples of what can quickly be reversed engineered from a native C++ implementation of the identical program.

Are you saying that the exe file can be compiled to a standalone executable, and not require the .net framework? Or are you saying that the exe file need not be MSIL at all?

As for reverse engineering a compiled C++ program, sure, we both know anything is possible, given enough time and resources, dedication and knowledge. But that doesn't make .net just as secure.

Quote:

Originally Posted by TheCPUWizard

But if you want to run an experiment in the meantime. Take ANY .Net executable, run it through ngen.exe (which ships with the runtime) and examine the resulting .EXE file...

Well, that I can't do on this machine, but it sounds like you're suggesting the exe would be "converted" in some way to native code, which to me should imply no longer needing the framework to run - a completely standalone exe. I'd be surprised if that's possible, and it would be news to me.

Quote:

Originally Posted by TheCPUWizard

I think it is also important to look at the many commercial programs out there which do use .NET are written by responsible companies, and evaluate their "risk assesment" of any additional exposure resulting from using .NET.

Also consider Microsoft itself. When they released SharePoint 2003, it was based on .NET and was obsfucated to minimize the information that could readily be viewed (these were the only .NET assemblies shipped by Microsoft to be encoded this way). After a very short period of time, they realized that the negative impact of obsfucation (eliminating capabilities inherent in .NET assemblies simply because of the visibility) outweighed any "protection" of either Intellectual Property (and we know how possessive MSFT is) or of tampering.....

So, I agree with you in not taking the word of ANYONE. Investigate it for yourself. Look to see what applications have been successfuly attacked, and compare the percentages.

If SharePoint was the only .net app distributed by ms, that tells me something. Plus it suggests they did it as an attempt to convince programmers to follow their "lead".

About looking at which .net apps have been attacked, successfully or not, just how would anyone do that?

But I will poke around to see if I can find something written in .net. However, if it requires the framework, that to me suggests it is MSIL, which wouldn't seem to be much proof of anything. I do see tons of programs claiming to protect .net apps though, which is highly suggestive.
June 25th, 2008, 06:48 PM
Joeman

Re: Why VB 6.0??

To CpuWizard:

I sure can't wait to see someone that can decompile quake 4 since it was written in c or any other game, but this haven't happened yet and I know why. Native code doesn't go back to anything. If you can find out the decompiler, so what. With 35 years of working with code, I think you would know that native code is just that and nothing else. Not msil. When I say compile, I mean just that. 100% pure native code compiled to the exe. If you can decompile c or c++, it would be in assembly language and that is it unless you plan on writing a reverse compiler if that is even possible.Your post says "Why vb6.0" and not "Why would you learn vb6.0". To me you are being very unclear on your intentions. You want to say you can decompile c++, but I never once show this. If you want to show you can decompile a c++ app, use the gcc compiler. I want to see this one get used for your decompiling c++ act. Also when you decompile the .net app, I want to see all the available .net decompilers without protecting your code. After that I want to see the .net app with protection go threw the .net decompilers and 100% documented.

I even tell my cousin that works with c#, that has a paying job with it, he can decompile his work and he has. He lost his source code for his project and got most of it back. Good for him.

People do have a point that businesses use the .net, but most of it isn't in the public domain. Most of the stuff in the public domain, is not the .net. I only ran into a few that are .net apps. The most apps I use are made with c++, c, java, python, delphi and so forth. The last in the list is the .net.

There are way too many versions of the .net and way too many versions of the ide. This produces nothing useful unless you like giving your money away for free.

One more thing. the .net is slower than vb6. Each time the computers get faster, the languages that are made gets slower. End of story. I am getting tried of this post. It is getting boring and anyone using the .net hasn't given a value reason to use it.. besides that is easy to use and it collects garabage
June 25th, 2008, 07:34 PM
Arjay

Re: Why VB 6.0??

Quote:

Originally Posted by WizBang

If SharePoint was the only .net app distributed by ms, that tells me something. Plus it suggests they did it as an attempt to convince programmers to follow their "lead".

Other MS applications have at least a portion of them written in .Net - Biztalk and SQL Server to name a couple.

Quote:

Originally Posted by WizBang

I do see tons of programs claiming to protect .net apps though, which is highly suggestive.

I see many programs out there that claim to speed up applications or clean the registry, but does that mean anything really?

To me, as a consultant/developer, I need to have the skills that enable me to bring in new work. The type of work that I do demands that I offer solid solutions that can be coded in a competitive amount of time. I can't (actually won't) offer a solution that has been coded with development tools that are no longer supported by Microsoft (such as VC6 or VB6). I would be embarassed to do so. It would be like recommending that my customer use Win95 or NT3.51 to run their critical software on.

Furthermore, many customers expect modern UI's or web interfaces. With Silverlight 2.0 you can get a modern UI, or RIA (Rich Internet Application), in the browser - in fact Silverlight 2.0 runs on many different browser and on non-Windows platforms such as the Mac and Linux. For those of you that don't know, Silverlight 2.0 is a subset of WPF (Windows Presentation Foundation). If you want to learn WPF or Silverlight, you need to learn .Net 3.0 or later.

If you can see the benefits that this new technology brings, understand you aren't going to be able to do this with 10 year old technology.
June 25th, 2008, 08:04 PM
Arjay

Re: Why VB 6.0??

Quote:

Originally Posted by Joeman

I sure can't wait to see someone that can decompile quake 4 since it was written in c or any other game, but this haven't happened yet and I know why.

Perhaps it is able to be decompiled but there are other security provisions in place that render the code unusable. Is that possible?

I agree with theCPUWizard that all code can be decompiled, and it is simply the degree to how easily this can be accomplished. Years ago I worked at Microsoft in the NT Application Compatibility Group. The job of that group at the time was to ensure that non-Microsoft applications worked on the new NT platforms. I worked in this group from right before NT3.51 shipped to just before the release of XP. We ran all sorts of tests on the 3rd party applications (like the Adobe products, Word Perfect Suite, and about 100 or so other top tier applications) just to be sure they behaved properly.

When the team discovered bugs, the developers would step through the application, essentially reverse engineering the code by looking at the assembly and figure out if it was a problem in the OS or a problem in the application. Many times the issue was the application, so they would contact the company that wrote the app (trying to get them to fix the app) and usually end up 'shimming' the app so it would work on the new OS.

The point of this was that these developers didn't have any source code for the applications and yet they were able to easily reverse engineer them.

How was this done? When you think about it, an application needs to interact with the system on some level, so how hard is it to set break points on the api's and see which api's are called, the order in which they are called, and see the parameters passed from the app to the api's? After watching these developers do it, it isn't too hard - and those guys got real good at doing it.

So Cpu is coming from this point of view where a native application can be easily reverse engineered when you know how to do this, it's trivial to reverse engineer a native app (and CPU even has tools to make it easier).

With regard to .Net code, it is pretty simple to run reflector to get the code on an app that hasn't been obvuscated; however if you are concerned with reverse engineering, you are going to obvuscate your code (which is easy to do). If you are really concerned about reverse engineering, you are going to take additional measures to secure your application (along the lines of techniques Quake used).

Just thinking that native code is secure because it's native code isn't enough.
June 26th, 2008, 01:55 AM
GremlinSA

Re: Why VB 6.0??

Following this conversation led me to a single thought, something that is true in all respects ...

"If you can build it, Someone else can un-build it!"

Take it when IBM released there first desktop PC (the 8088 , 8086). the most difficult part to duplicate on that system was the bios. A group of enginners sat with the bios, reverse engineered it and create all the IBM clones... Now no one will want to report it but my guess puts it that of the first 100 units of the IBM sold, at least half went into a engineers workshop to be reverse eng, or at least studied..

I worked at a place where we manufactured and repaired cornershop game machines. these worked mostly of the Z80 proc, and banks of EEROM. Alot of these roms had a hardware protection on them, (A programable pic that decoded the scrambled rom, onto the databus.) so if you read the Rom raw you got garbage, you add in the pic ( that was also hardwired to the Z80) and you could read the data.

The guy i worked for, Alex cracked this protection on each board within a day, and could get a clean dump of each rom.

The point is... you can even build a hardware rig to protect your code, but there will be someone else there that will be able to reverse it and pull out your code...

Gremmy..

BTW. did you know there was a big bug in "Ms Pacman" that allowed you to play for hours on a single credit...
June 26th, 2008, 06:29 AM
Joeman

Re: Why VB 6.0??

The reason you can't decompile quake 4 is because you cant!!!! It will only go back to assembly. That is it! Not the source code. I know how to reverse engineer and I am telling you assembly language is not the source!. Get over it. I understand people will read the Assembly language, but not the stupid source code. Why are all of you that confused? I have tweaked Quake 4( I won't go into details) and I am telling you can't get the source code back. Sure you can get a very advance asm decompiler(debugger) that will give your strings, api used and so forth, but that is a far cry to see how quake 4 stacked up all their work on. Come on do I know more than you about decompiling? All of you have "seen" people do it, but never have done it or you will know that you can't decompile c++ to its source code even if you wanted to. It is highly unethical and that is why people read the asm. If you want to call asm being the decompiled version of that app, go ahead, but when I say decompile I mean decompile to source code of what it originated from. There is nothing going to get me their functions source code in c++. You have a better chance of hand converting asm to c++, but for anything in the .net you have a better chance of getting a .net decompiler to do that job for you. You act like it is no big deal that microsoft hasn't done anything to protect your code. It is a pitty. I thought it would be neat to learn c#, but I had to refuse after my work was decompiled, so I went with the next best thing and the real thing... c++!!!

AND QUAKE 4 DOESN'T HAVE GOOD PROTECTION!!! I would know and people.. stop telling how reverse engineering works. I think I told you enough for you to know that I know what it is and how to do it.
June 26th, 2008, 08:17 AM
WizBang

Re: Why VB 6.0??

Thanks Joeman for restating and making the point clearer. That's what I've been saying also. Hacking, and looking at asm, etc is not the source code, and what those methods get you cannot be compiled like the source originally was. However, a .net decompiler can give you source code which you can use in the .net IDE just like any other source code, including compiling it into a working app. Obfuscation doesn't stop .net decompilers.

As I understand it, the reason for this is that .net is managed code. If it was true native code, it couldn't be managed, and it wouldn't require the runtime (framework) to run either.

Viewing asm in a debugger applies to any app, so it is of no relevance here.

Quote:

Originally Posted by Arjay

Other MS applications have at least a portion of them written in .Net - Biztalk and SQL Server to name a couple.

Fine, but that suggests to me either the programmers took an easy way out, or they are just trying to get developers to use .net just because ms used it. Bits and pieces of inconsequential code isn't so meaningful. The real question in my mind, is if ms creates entire applications in .net, and is successful at protecting them from being decompiled.

Quote:

Originally Posted by Arjay

I see many programs out there that claim to speed up applications or clean the registry, but does that mean anything really?

Yes, it does mean something. It means there's a market for it. It means there's a need for it. There are tools to obfuscate .net because it's vulnerable, and doing so is enough to keep the casual viewer from seeing too much. But once again, a .net decompiler can see right through this obfuscation.

Quote:

Originally Posted by Arjay

Furthermore, many customers expect modern UI's or web interfaces. With Silverlight 2.0 you can get a modern UI, or RIA (Rich Internet Application), in the browser - in fact Silverlight 2.0 runs on many different browser and on non-Windows platforms such as the Mac and Linux. For those of you that don't know, Silverlight 2.0 is a subset of WPF (Windows Presentation Foundation). If you want to learn WPF or Silverlight, you need to learn .Net 3.0 or later.

If you can see the benefits that this new technology brings, understand you aren't going to be able to do this with 10 year old technology.

Skins can be created in VB6, C++, and many other languages which came about quite a while before .net or Silverlight. Heck, what do you suppose Silverlight was written in anyway? For that matter, what was .net itself written in?

No amount of "bells and whistles" can make me want to give away my source code.
June 26th, 2008, 10:05 AM
GremlinSA

Re: Why VB 6.0??

Quote:

Originally Posted by Joeman

The reason you can't decompile quake 4 is because you cant!!!! It will only go back to assembly. That is it! Not the source code. I know how to reverse engineer and I am telling you assembly language is not the source!. Get over it. I understand people will read the Assembly language, but not the stupid source code.

---SNIP----

I would know and people.. stop telling how reverse engineering works. I think I told you enough for you to know that I know what it is and how to do it.

WOW you getting very worked up about this..

For some engineers, there is no need to get the exact source code, but rather just a breakdown of the code.. With Quake 4, decompilation to pure source is not needed, but if you could decompile it to a point where you can inject your own code into it, Recompile and have a running Game, with your own Quirks added.. You have succesfully reverse engineered the game..

I've used this method to fix a faulty game for the C64 many years ago.

Source does not need be in the original language used. But any language that can be recompiled ..

IE...

I write a App in VB.
You take it, and decompile it to C, (so you still see the calls to VB runtimes..)
Alter the code a little
Recompile it
--- Can be done ---
June 26th, 2008, 10:21 AM
WillAtwell

Re: Why VB 6.0??

I think a big factor here is can be done vs can be done easily.

If there truly is a decompiler that generates basic code from a exe created in vb dot net then that means pretty much any hack can get your code in a snap. Whereas pulling ASM out of an exe requires much greater skill to do anything with the code afterward.

I don;t know about the rest of you but I have been writing apps for years and ASM is still a bit over my head. Basic code on the other hand :)
June 26th, 2008, 11:11 AM
GremlinSA

Re: Why VB 6.0??

Quote:

Originally Posted by WillAtwell

I think a big factor here is can be done vs can be done easily.

If there truly is a decompiler that generates basic code from a exe created in vb dot net then that means pretty much any hack can get your code in a snap. Whereas pulling ASM out of an exe requires much greater skill to do anything with the code afterward.

I don;t know about the rest of you but I have been writing apps for years and ASM is still a bit over my head. Basic code on the other hand :)

The 6510 or 6502 Proccesors use a early 8 bit ASM, with only 53 commands, And access to 64k ram & rom (Like the Commodore 64)..

I can write code in this with a breeze, however today i will need a memory map to dbl check what and where everything is.. however, 32bit ASM, i never got round to studing it, and dont think i ever will..

And i also think you got the big factor spot on.... Done vs Easily Done....
June 26th, 2008, 02:34 PM
Arjay

Re: Why VB 6.0??

Say what do you guys do when you need to host some web content?

Do you manually create an application that responds to http requests, manages session state and so on or do you take the easy way out and use IIS or Apache server?

If you use IIS, do you program with ISAPI directly or do you take the easy way out and go the ASP route?

There might be a few exceptions to this but typically developers are going to host web content using ASP (or ASP.Net) and no one is going to accuse them of 'taking the easy way out.'

Should transitioning out of native code be any different?

I know personally I would laugh if someone told me I'm taking the easy way out because I choose to learn and code in the latest technologies. I would say "you bet I do, it's called 'being productive'".

This conversation reminds me of when I started in the business nearly 15 years ago. Back then there was a big debate saying that C was faster than C++ and many hardcore C application programmers just absolutely refused to see the benefits of writing OO code. Some of those C programmers made the jump and started writing crappy C++ (ala C styled code with objects) but that's another story. Other developers saw the benefits of OO and from that point on wrote applications in C++.

I realized then that there wasn't much use in trying to convince a C programmer the benefits of C++ - they either got it or they didn't. Most of those guys have since retired. I'm not sure if that was due to the fact that straight C jobs are very hard to find or because of other reasons.

It's something worth thinking about.
June 26th, 2008, 03:43 PM
TheCPUWizard

Re: Why VB 6.0??

QUOTE=GremlinSA]And i also think you got the big factor spot on.... Done vs Easily Done....[/QUOTE]

Are you sure? Consider the following two scenarios:

1) You have a program you would like to alter or duplicate to make some things easier to use, or provide some other small benefit. You find out that this would require a mid level programmer about 50 hours @ $75/hour. ($3,750).

2) You have a program that you want to alter or duplicate where having the changes would net you over $100,00K per year for the next 5 years. You find out that this would require a senior programmer about 200 hours at $175/hr ($35,000).

Obviously the first scenarion is easier, but the "reward"/"cost" ratio is not there. This is a large consideration in the value of "protecting" a program.

Also, the "cost" to the original developer must be considered. If I write a program which contains some "really great" graphics routines, but have no intention of getting additional revenue for the graphics engine itself, what does it really matter if someone steals the algorithyms (which are excrutiatingly difficult to legally protect in the first place).

"Silent" Tampering is perhaps the most serious threat in many cases. If I have a financial program sold to many clients) that someone can alter to re-diect funds, the impact can be enormous.

Having developed systems for Military, Industrial, Financial, Medical (included embedded medical devices), Legal, Publishing, and just about every other market (except Games....), the scenario always has to be evaluated for the specific target.

Realistically, the only way to get 99.9995% (five-nines) is to offer Software as a Service where the code runs on a machine that can be tightly controlled. This approach has been gaining alot of momentum as people realize that client side protection (regardless of type) can easily be broken (as illustrated by others in this thread) if there is sufficient motivation.

So the real debate centers on code that is going to be deployed to some "uncontrolled" environment. If we acknowledge that any software CAN be impacted, it follows that a decision must be made as to how high to raise the "motivation requirement".

Source Code:

Quote:

a computer program in its original programming language (as FORTRAN or C) before translation into object code usually by a compiler

http://www.merriam-webster.com/dictionary/Source%20Code

Does not have to look anything like the original. It merely must be something that is translatable back to object code.

So how important is having the information that is lost by compilation of a "standard" C++ program really worth?

I don't know how many of the readers of this thread have ever had to deal with supporting a program that was written in a country where you have absolutely no understanding of their written language. I have (many times).

Effecively the comments are useless as well as the variable names and other "symbolic" information. They might as well by "AAAAA","AAAAB","AAAAC".....

This is an annoyance, but takes little time to unravel (how many people do "Crypto-Quotes"???).

So this leaves program structure. While optimizing compilers do add some difficulty, the basic patterns are east to determine. Sure you may transpose:

Code:

int i=0; while(i<10) { i++; }

into

Code:

for (int i=0;i<10;++i) {}

It does not matter as either is equally readable and functionally equivilant.

C++ is actually easier than C [given equal levels of optimization by the compiler] because of the consistancy in which the "this" pointer must be handled when calling member methods. This grouping into classes (yes, you lose the private/protected/public) goes a long way in organizing the targeted software.

The tool I use is based on a program called "C-Scribe" which was written by the Application Testing Group at Sun many many years ago. Since I have been using it for about 22 years, I have made many many improvements. Given a runnable version of a program, I can usually recreate a functional equivilant in about 1-4 weeks.

But wait...."I can do that in .Net in about 30 seconds" and by default that is 100% true..

So lets review what has already been discussed:

1) If the motivation is high enough, the differential effort becomes meaningless, they are going to attack it anyway.

2) If tampering (as opposed to duplication) is the concern, then simple techniques such as Strong Naming and Code Access Security provide a high barrier.

3) If duplication (as opposed to tampering) is the concern, then Obsfucation will make the names meaningless (although this will disable some of the power of CLR based applications). If further masking is desired, then using ngen.exe to produce a native (rather than MSIL) executable can also be used.

4) Regardless of language, additional barrier (but never real protection) can be layered on.

The end result is that I have not seen a single situation where the .Net programiming model properly used) has be responsible for any "protection" issues.
June 26th, 2008, 04:07 PM
WillAtwell

Re: Why VB 6.0??

It sounds like you are saying that unless you take one or more special steps to protect the code it is at risk, and as pointed out any code can be reverse engineered given the time and talent but a decompiler that does all the work makes it extremely easy to do whereas it would require a great deal of effort to do some other programs. For example you don't see the source code for windows xp posted on the net but if there was a decomplier for it you would.
June 26th, 2008, 04:42 PM
GremlinSA

Re: Why VB 6.0??

Okay here is a very recent example of Hacking a program..

My work collegue (new programmer) just finished a project in VB.NET, and asked me to have a look at it.

Using my trusty hex editor, freely available to anyone (BTW my Hex editor source is also available on CG), and a very handy tool for debuging data problems turned up this..

http://i141.photobucket.com/albums/r...her/DBPASS.jpg
(I've removed trace details about the client because this project is going live soon)

The Compiled file has returned very important Database Password that is used to protect intelectual property.. The database contains high quality pictures that are used by the app, however the client does not want the end users to be able to access the images outside of the app..

This application was cracked in seconds, with no effort.. i may not have decompiled the app, however i was able to extract enough from it to gain access to protected info!!!

I would can this a successful application hack...
June 26th, 2008, 04:49 PM
GremlinSA

Re: Why VB 6.0??

Quote:

Originally Posted by WillAtwell

It sounds like you are saying that unless you take one or more special steps to protect the code it is at risk, and as pointed out any code can be reverse engineered given the time and talent but a decompiler that does all the work makes it extremely easy to do whereas it would require a great deal of effort to do some other programs. For example you don't see the source code for windows xp posted on the net but if there was a decomplier for it you would.

Decompilers are more specific to the compiler used, not the application to be decompiled..

hosting source for Windows XP will be a difficult task as there are hundreds of files that all make up Windows. However generic source for many of the components of windows is available, if you search the net deep enough...
June 26th, 2008, 06:28 PM
Joeman

Re: Why VB 6.0??

I see alot of people are now understanding that the .net is easily decompiled and some stubborn people still are saying that even the c or c++ language can be decompiled just like the .net or close enough, but the truth is that it is just not that simple nor very possible.

Quote:

Originally Posted by GremlinSA
For some engineers, there is no need to get the exact source code, but rather just a breakdown of the code.. With Quake 4, decompilation to pure source is not needed, but if you could decompile it to a point where you can inject your own code into it, Recompile and have a running Game, with your own Quirks added.. You have succesfully reverse engineered the game..

I've used this method to fix a faulty game for the C64 many years ago.

Decompiling a major product isn't needed? Why I beg to differ. I want that source code.
You don't need to decompile the exe for anything unless you are doing something permanent like you have. I tweaked the memory of quake 4. I read the asm in the memory. Same applies to all apps that are native and aren't native. I kept all the pointers that pointed to a certain spot in the memory and everytime quake 4 would load I had access to game variables.. You can easily stop people from reading your exe memory code and stopping people from modifing your exe by doing security checks, using hash checks and even more ways of doing so.

Let's look at some c++ source code and the asm produced while being debugged with code::block's debugger while the code was being executed.

Code:

#include <iostream> using namespace std; int main() { int Symbol[8][8]= { { 1, 2, 3, 4, 5, 6, 7 ,8}, { 1, 2, 3, 4, 5, 6, 7 ,8}, { 1, 2, 3, 4, 5, 6, 7 ,8}, { 1, 2, 3, 4, 5, 6, 7 ,8}, { 1, 2, 3, 4, 5, 6, 7 ,8}, { 1, 2, 3, 4, 5, 6, 7 ,8}, { 1, 2, 3, 4, 5, 6, 7 ,8}, { 1, 2, 3, 4, 5, 6, 7 ,8}, }; for(int X = 0; X < 8; X++){ for(int Y = 0; Y < 8; Y++){ cout << Symbol[X][Y]; } cout << endl; } while(1){} return 0; }

Keep in mind that this isn't the direct output. This has references in it because it is still not fully compiled and now for the debugged version(asm)

Code:

0x8048860 lea ecx,[esp+0x4] 0x8048864 and esp,0xfffffff0 0x8048867 push DWORD PTR [ecx-0x4] 0x804886a push ebp 0x804886b mov ebp,esp 0x804886d push ecx 0x804886e sub esp,0x124 0x8048874 lea ecx,[ebp-0x10c] 0x804887a mov edx,0x8048a00 0x804887f mov eax,0x100 0x8048884 mov DWORD PTR [esp+0x8],eax 0x8048888 mov DWORD PTR [esp+0x4],edx 0x804888c mov DWORD PTR [esp],ecx 0x804888f call 0x8048614 <memcpy@plt> 0x8048894 mov DWORD PTR [ebp-0x8],0x0 0x804889b jmp 0x80488ea <main+138> 0x804889d mov DWORD PTR [ebp-0xc],0x0 0x80488a4 jmp 0x80488cc <main+108> 0x80488a6 mov eax,DWORD PTR [ebp-0x8] 0x80488a9 mov edx,DWORD PTR [ebp-0xc] 0x80488ac shl eax,0x3 0x80488af add eax,edx 0x80488b1 mov eax,DWORD PTR [ebp+eax*4-0x10c] 0x80488b8 mov DWORD PTR [esp+0x4],eax 0x80488bc mov DWORD PTR [esp],0x8049d80 0x80488c3 call 0x8048594 <_ZNSolsEi@plt> 0x80488c8 add DWORD PTR [ebp-0xc],0x1 0x80488cc cmp DWORD PTR [ebp-0xc],0x7 0x80488d0 jle 0x80488a6 <main+70> 0x80488d2 mov DWORD PTR [esp+0x4],0x8048634 0x80488da mov DWORD PTR [esp],0x8049d80 0x80488e1 call 0x8048624 <_ZNSolsEPFRSoS_E@plt> 0x80488e6 add DWORD PTR [ebp-0x8],0x1 0x80488ea cmp DWORD PTR [ebp-0x8],0x7 0x80488ee jle 0x804889d <main+61> 0x80488f0 jmp 0x80488f0 <main+144>

If you think that was hard try looking fully compiled version. It is more simple to look at than compiled asm. All the reference of things, like the main, in the compiled asm output are lost...

As you can see they don't even resemble each other. The only thing they have in common is they do exactly the same thing. Asm is not the source code which it was written from. Sure asm is a language and I never stated that it wasn't, but asm is the only thing c++ can be decompiled to. In reality asm is what it compiles to and not what it decompiles as. It is sort of a miss understanding. Really the exe has the asm wrote as 10101... for ex. 10101001 could mean mov or pop. When you load the exe in notepad, you see weird numbers, but the underlining of the numbers are the bits that form asm codes. Now the computer runs the bits and executes the asm instruction. Using a disassembler you can view the files asm code for that exe. I can't recommend any programs that can do this for you.

Now if I had the .net installed and vs 2008, I would show you how much different msil makes it easy for a hacker to steal your source code. You don't have to read asm. You read source code like it originated from. Now how simple does that sound after looking at that asm code? ;)

I will not be using the .net because of that reason. Once good protection comes out and it speeds up to 500% faster than now, I might consider it. I will go with c++ and if I feel like securing my asm code output, I will, but at least I don't have to protect something that can be so easily decompiled to actual source code like it originated from with a click of a button.

Quote:

Originally Posted by TheCpuWizard
Realistically, the only way to get 99.9995% (five-nines) is to offer Software as a Service where the code runs on a machine that can be tightly controlled. This approach has been gaining alot of momentum as people realize that client side protection (regardless of type) can easily be broken (as illustrated by others in this thread) if there is sufficient motivation.

You are saying the best way to protect your code is to get it on a computer that is secured and managed, but how do you do that when it is downloaded on a computer that is being daily used by the user who wants to use your app? You can't secure that computer nor managed it. So basically the app can't be on such a computer...? How are you going to put it on this user's computer? With that senerio you have to take rights away from him/her to secure your work. I never heard of this before the .net came along.

Most people that use a high level language can't read such a low level language(asm). Maybe 0.01% can, but that is about all, so think about it. Do you want to use something that can be converted back to the original source code or something that can't?
June 26th, 2008, 06:30 PM
Arjay

Re: Why VB 6.0??

Quote:

Originally Posted by GremlinSA

This application was cracked in seconds, with no effort.. i may not have decompiled the app, however i was able to extract enough from it to gain access to protected info!!!

I would can this a successful application hack...

You would be able to read hardcoded strings in a hex editor of a native application as well.
June 26th, 2008, 07:24 PM
Arjay

Re: Why VB 6.0??

Quote:

Originally Posted by Joeman

I see alot of people are now understanding that the .net is easily decompiled and some stubborn people still are saying that even the c or c++ language can be decompiled just like the .net or close enough, but the truth is that it is just not that simple nor very possible.

If a hacker has access to the native binaries, they can reverse engineer the code. For an experienced developer, looking at assembly is as good as looking at original source code (remember my previous post about 'shimming' applications earlier).

This is exactly like home security. Most security experts will agree that any home can be broken into. By adding more security (locks, alarms, etc) you raise the bar, but given enough time the security measures can be defeated. What we are talking about is the raising the barrier to entry.

We can all agree that the barrier to viewing .Net code is low, more so than native code.

However, it is quite easy to obfuscate the code or ngen it and now you've raised the bar up to native code.

It's still not secure (and neither is native code), but the barrier to entry is a bit higher.
June 26th, 2008, 07:26 PM
TheCPUWizard

Re: Why VB 6.0??

Quote:

Originally Posted by Joeman

..... Really the exe has the asm wrote as 10101... for ex. 10101001 could mean mov or pop. When you load the exe in notepad, you see weird numbers, but the underlining of the numbers are the bits that form asm codes. Now the computer runs the bits and executes the asm instruction. Using a disassembler you can view the files asm code for that exe. I can't recommend any programs that can do this for you.

It is 100% determinable. An executed memory instruction has exactly one op code and a given byte has exactly one meaning. They are all covered here. http://ref.x86asm.net/

It is trivial to determine the "sync points" for op-code simply be seeing what locations are used as the target of a jump,call, branch. The entry point address is contained in the PE header.

When I get back home on Saturday (I am currently at a classic computer musuem and conference...great to see, touch, and sometime operate machines I worked on back in the 1970's :D ).
June 26th, 2008, 07:32 PM
Arjay

Re: Why VB 6.0??

Quote:

Originally Posted by WillAtwell

It sounds like you are saying that unless you take one or more special steps to protect the code it is at risk, and as pointed out any code can be reverse engineered given the time and talent but a decompiler that does all the work makes it extremely easy to do whereas it would require a great deal of effort to do some other programs. For example you don't see the source code for windows xp posted on the net but if there was a decomplier for it you would.

Is it important to you that all the code you write be harder to reverse engineer? If so, you can take the two minutes extra before shipping to run the obfuscator on the managed code.

That doesn't take much effort does it?

Does it matter that it requires an extra step?

Btw, the source for Windows XP is available on the internet. Microsoft was required to release portions of the source code so it's available.
June 26th, 2008, 08:53 PM
WillAtwell

Re: Why VB 6.0??

Quote:

Originally Posted by Arjay

Is it important to you that all the code you write be harder to reverse engineer? If so, you can take the two minutes extra before shipping to run the obfuscator on the managed code.

Yes it is important that code is harder to reverse engineer. I also see several programs available that decompile even when you use the obfuscator on them or so they say.

Quote:

That doesn't take much effort does it?

Apparently it still isn't very secure

Quote:

Does it matter that it requires an extra step?

Yes, many people may have never heard of such a need as they came from VB6 which is secure. One would naturally expect VS2003,5 and 8 to be at least as secure if not more so without taking any additional steps.

Quote:

Btw, the source for Windows XP is available on the internet. Microsoft was required to release portions of the source code so it's available.

Portions of the source code and "The source code" are two different things. If the source code were online then one could download it and build thier own custom copy of XP with ease. Somehow I do not think you will be able to find the components to do so.
June 26th, 2008, 08:57 PM
WillAtwell

Re: Why VB 6.0??

Quote:

Originally Posted by Arjay

If a hacker has access to the native binaries, they can reverse engineer the code. For an experienced developer, looking at assembly is as good as looking at original source code (remember my previous post about 'shimming' applications earlier).

For an experienced developer that is experienced in ASM perhaps but there are many of us who have never studied ASM at all or not in the last several years. Last time I used ASM was on a 8086 and even then I did not have a good handle on it. Yet I am a very experienced developer and have turned out many apps.

No matter how you try and spin it it is about 10,000 times easier if you have VB code to work with than ASM and there are a lot more people who would be able to use the VB which may not have a clue in ASM.
June 26th, 2008, 09:14 PM
TheCPUWizard

Re: Why VB 6.0??

Quote:

Originally Posted by WillAtwell

For an experienced developer that is experienced in ASM perhaps but there are many of us who have never studied ASM at all or not in the last several years. Last time I used ASM was on a 8086 and even then I did not have a good handle on it. Yet I am a very experienced developer and have turned out many apps.

No matter how you try and spin it it is about 10,000 times easier if you have VB code to work with than ASM and there are a lot more people who would be able to use the VB which may not have a clue in ASM.

I would like to see any analysis to support a figure of 10,000 times (+/- 10%)....
June 26th, 2008, 09:19 PM
Arjay

Re: Why VB 6.0??

Quote:

Originally Posted by WillAtwell

For an experienced developer that is experienced in ASM perhaps but there are many of us who have never studied ASM at all or not in the last several years. Last time I used ASM was on a 8086 and even then I did not have a good handle on it. Yet I am a very experienced developer and have turned out many apps.

No matter how you try and spin it it is about 10,000 times easier if you have VB code to work with than ASM and there are a lot more people who would be able to use the VB which may not have a clue in ASM.

It's not about spin.

Consider:
1) Native code is not secure. Do you need security or not? If you need to protect your source, thinking that a native binary is enough to prevent reverse engineering is a mistake.
2) If you are interested in stopping the casual hacker in a .Net app, obfuscate the code or run ngen. Then you have code that can't easily be read with reflector or if ngen'd you have a native binary. This takes about 2 minutes to do.

For an extra 2 minutes, it's interesting to have this issue as a major barrier for using .Net.
June 26th, 2008, 10:53 PM
WillAtwell

Re: Why VB 6.0??

I do use dot net and I have for some time now. Until I saw posts in this thread I was unaware that my code was at risk to a casual hacker. I assumed that it was protected as it was in the previous version. I find that rather alarming.

Some things are easier to code in dot net, some are not. Try talking to a serial port in VS2003 dot net for example or an IP port. Seems they drop the serial support and the winsock control though they do still have support for sockets.

I went online a bit ago and downloaded a sample de-compiler and sure enough it quickly pulled readable VB source code out of an exe that was written in vb.net 2003.

One would think that MS would have at least tied these programs which supposedly protect the code into the main IDE and by default use them.
June 27th, 2008, 01:27 AM
Arjay

Re: Why VB 6.0??

Quote:

Originally Posted by WillAtwell

I do use dot net and I have for some time now. Until I saw posts in this thread I was unaware that my code was at risk to a casual hacker. I assumed that it was protected as it was in the previous version. I find that rather alarming..

If it took you this long to discover this, perhaps a casual coder isn't aware as well?

Quote:

Originally Posted by WillAtwell

Some things are easier to code in dot net, some are not. Try talking to a serial port in VS2003 dot net for example or an IP port. Seems they drop the serial support and the winsock control though they do still have support for sockets..

In .Net 2.0, a SerialPort class was introduced. As for sockets, check out the System.Net.Sockets namespace for several classes that assist with network communication.

Quote:

Originally Posted by WillAtwell

I went online a bit ago and downloaded a sample de-compiler and sure enough it quickly pulled readable VB source code out of an exe that was written in vb.net 2003.

Did you try this again after running the Obfuscator?

Quote:

Originally Posted by WillAtwell

One would think that MS would have at least tied these programs which supposedly protect the code into the main IDE and by default use them.

In VS2005 and later, the 'Dot&fuscator Community Edition' is included in the tools menu.

See, that's the issue with using older programming environments - you don't really know what you're missing. ;)
June 27th, 2008, 04:13 AM
GremlinSA

Re: Why VB 6.0??

I'm still not sure why there is such a big issue about getting the 'pure source' out of the exe.
Unless it was some fantastic application that can put rockets into geo-orbital space, and you want to alter it to play chess, 99% of the time they guy fiddeling with your code is trying to bypass securities, activate the full version, or simply gain access to controlled info..
I've used that same old trusty hex editor to alter many applications to Perform my bidding, each written in a different lang, including C..

Often to bypass securities all that is needed is 1 or 2 simple ASM command changes. the better known ways are to either find where the code jumps to the security code, and NO-OP it out, or change the Branch command (BEQ to BNE or vice versa) in the security code.

CRC's can be recalculated and replaced, File size has not been changed, and it there is no further security checks the application runs 100%.

At one of the offices that i worked at we had a program that used a printer port security key (Dongle), How ever the cost of licencing one dongle was $5 000.00 (Yes five thousand dollars). The company purchased 10 licences, however this was still just not enough for all the users. and when units either got lost or stoped working i was asked to see what i was able to do..

One critical mistake in the app was the security key was only checked for at the very begining of execution, you could work for 5 hours and the app never checked it again. in offices where 2 or more pc's stood together i simply put a Auto Printer switch box with the Dongle, and ran lines to each PC's port. To start working each person only needed to have access to it for a few milliseconds. Every so often we did have a small problem with the responce time, but 9/10 times it ran the first time...

Here i 'Hacked' the application without even looking at the compiled code..

Then we turn to that 1% thats left, those are the cases where Due to hardware failure, sabatage, or even death, a company has lost the source code af an application that they are the legal owners of, and have every right to reverce engineer there own code.

However now this has strayed very far from the initial Question...

WHY train New programmers in VB6 ?? (code security is now tecnically no longer a valid reason)
June 27th, 2008, 06:52 AM
WizBang

Re: Why VB 6.0??

Quote:

Originally Posted by Arjay

In VS2005 and later, the 'Dot&fuscator Community Edition' is included in the tools menu.

Obfuscation has already proven insufficient for protecting the source code.

Quote:

Originally Posted by Arjay

See, that's the issue with using older programming environments - you don't really know what you're missing. ;)

C++ doesn't need obfuscation.

Let's put to rest the arguments about reverse engineering and hacking being "just as good" as fully decompiling back to source code. The differences are enormous. There are untold numbers more two-bit wanna-be hackers out there than there are those who are truly good at it. Being able to easily get readable source code means a huge increase in the number of crooks compromising the work.

Yes, any program can be compromised, but the degree of ease at which it can be done can mean the difference between profit and loss.

Now, about this "ngen" thing; Seems like it is being suggested that this would compile .net code to a native exe, thus gaining the same protection against decompiling that C++ has? This implies that there wouldn't be any dependency on the "framework", which also suggests that there wouldn't be any garbage collection. Is this true?
June 27th, 2008, 07:31 AM
WizBang

Re: Why VB 6.0??

Just did a little poking around, and found out what the deal is with ngen. This statement from another forum says it well:

Quote:

The main disadvantage of an ngen-compiled assembly (and there are lots) that you should worry about is that it does not provide any extra protection to your code. Applications compiled in this way still require that the assemblies are distributed so they can get metadata and fall back to JIT if the ngen data gets corrupted. This means that you've gained no security.
June 27th, 2008, 09:53 AM
WillAtwell

Re: Why VB 6.0??

Quote:

Originally Posted by Arjay

If it took you this long to discover this, perhaps a casual coder isn't aware as well?

I am sure many are not, but some are and that number will grow especially among hackers of which I am not one.

Quote:

In .Net 2.0, a SerialPort class was introduced. As for sockets, check out the System.Net.Sockets namespace for several classes that assist with network communication.

Yes I know that they added serialport in 2005. The point was that they removed it from 2003. Somethign that I have done for years in every form of Basic is suddenly unsupported in a supposed upgraded version. I also know about the sockets and have used them. They did remove the winsock control that was in the last several versions of VB and made the task quite a bit easier. Now that I have a good handle on the sockets class I actually like it better but it took a bit of effort to get it to work.

Quote:

Did you try this again after running the Obfuscator?

No but the decompiler that I used did have the option to un-obfuscate it as well.

Quote:

In VS2005 and later, the 'Dot&fuscator Community Edition' is included in the tools menu.

See, that's the issue with using older programming environments - you don't really know what you're missing. ;)

I guess that could be said about those who have not used the older versions. They would not notice the missing serial port connection in 2003 or the missing winsock and other things which were in VB for years and suddenly gone in 2003 to be later added in some way in 2005.

For me the biggest advantage to dot net is the mobile device capability and this is mostly what I use it for at this time.
June 27th, 2008, 10:10 AM
Joeman

Re: Why VB 6.0??

Quote:

Originally Posted by Arjay
If it took you this long to discover this, perhaps a casual coder isn't aware as well?

You bet and the hackers take full advantage of this. All the hackers know the .net can be decompiled. If they don't, they are new and they will learn this.

Quote:

Originally Posted by WizBang

Just did a little poking around, and found out what the deal is with ngen. This statement from another forum says it well:

Quote:

The main disadvantage of an ngen-compiled assembly (and there are lots) that you should worry about is that it does not provide any extra protection to your code.
Applications compiled in this way still require that the assemblies are distributed so they can get metadata and fall back to JIT if the ngen data gets corrupted. This means that you've gained no security.

There are no real security for the .net yet and this is just proves my point.
June 27th, 2008, 10:13 AM
Arjay

Re: Why VB 6.0??

Why should there be a sudden influx of folks just now discovering this? After all, .Net was first publically released in 2002 (and available in beta form prior to that). Again, it doesn't matter - if you need to secure your code, don't mistakenly think that native code does it for you.

As far as removing functionality. In the early versions, Microsoft didn't have time to replicate all the functionality of the Windows api. That's why they offered the ability to PInvoke, so you could make external COM or Windows api calls. And it's not as if they had this functionality in 2002 and removed it in 2003 - they didn't put it in there until they had time to, well, put it in there.

There were many things missing in the early versions of .Net and the IDE. It was after all v1.0 or v1.1 software. VC6 or VB6 each had several major releases by the this point. Is it surprising that the final release of software is more refined than an initial release?
June 27th, 2008, 10:16 AM
Joeman

Re: Why VB 6.0??

I know people can modify my programs to do things... like crack it, but I am more worried that if I use the .net, they will decompile my work back to the source code, copyright it and sue me because they own my work now or worse they sell it for money and then come after me. This can be a real scenario.
June 27th, 2008, 10:27 AM
Arjay

Re: Why VB 6.0??

Quote:

Originally Posted by Joeman

I know people can modify my programs to do things... like crack it, but I am more worried that if I use the .net, they will decompile my work back to the source code, copyright it and sue me because they own my work now or worse they sell it for money and then come after me. This can be a real scenario.

So protect your software with the techniques that have been outlined. If this is so important to you, then perhaps native code isn't sufficient and you should look into a DRM?

It seems a bit ridiculous to continue to complain about this point when it is so easy to do something about it.
June 27th, 2008, 10:31 AM
Joeman

Re: Why VB 6.0??

Man you are trying to put native code and back to source code in the same boat. Try this.. you need to steal a car, you have a bad pick set. This would be your c compiled to native code and you have made a copy of the key with a tool. This would be the .net decompiler. Now what one is easier? Yes, the .net decompiler making the key to get real source code back. I don't need to copyright my source code for c++ because I am the only able to get it.
June 27th, 2008, 10:36 AM
Joeman

Re: Why VB 6.0??

Quote:

Originally Posted by Arjay

It seems a bit ridiculous to continue to complain about this point when it is so easy to do something about it.

You can't do anything about it when it is that darn simple to get hacked unless microsoft steps up and does something about it, but I wouldn't hold my breath.
June 27th, 2008, 10:46 AM
Arjay

Re: Why VB 6.0??

Quote:

Originally Posted by Joeman

You can't do anything about it when it is that darn simple to get hacked unless microsoft steps up and does something about it, but I wouldn't hold my breath.

Microsoft doesn't need to do anything about it. The ball is in your court.
June 27th, 2008, 10:47 AM
Joeman

Re: Why VB 6.0??

Why should it be. It is their fault!
June 27th, 2008, 10:48 AM
GremlinSA

Re: Why VB 6.0??

Quote:

Originally Posted by Joeman

I know people can modify my programs to do things... like crack it, but I am more worried that if I use the .net, they will decompile my work back to the source code, copyright it and sue me because they own my work now or worse they sell it for money and then come after me. This can be a real scenario.

Firstly, you will have to write some blady excelent code, something that no-one else can!!

Secondly, It'll be easy to prove that you wrote the original, Expecially because you will have a release date long before their copyright date.

If this is a reason not to use the latest developing software, it's acctually very lame....
June 27th, 2008, 11:03 AM
RealityIsForLocos

Re: Why VB 6.0??

If you are saying that the original source code isn't important. Why are there hackers hacking into big cooperations like microsoft and stealing their source code for games and apps. Do you guys remember about half-life 2?

Quote:

Originally Posted by Arjay

Why should there be a sudden influx of folks just now discovering this? After all, .Net was first publically released in 2002 (and available in beta form prior to that). Again, it doesn't matter - if you need to secure your code, don't mistakenly think that native code does it for you.

Yes, it does. You will never get the original source code back if it is compiled to native code and for the hackers that are modifying your apps memory, you can stop them and that is a fry car from getting the original source code. It doesn't take a real hacker to read the .net decompiled source code because it is exactly the same thing as the original source code. There are alot of people that can program in the .net because it is so easy, so you are all vulnerable to all the newbies hackers and just people that can program in the .net, so I will stick with a program language that can compile to native code. All I will have to worry about is protecting my app's memory and exe unlike having to protect the source code lol.

PS I know that you could decomplie .net when it came out because it didn't
compile into native code but I guess some people had faith in microsoft.
June 27th, 2008, 11:06 AM
Joeman

Re: Why VB 6.0??

Quote:

Originally Posted by GremlinSA

Firstly, you will have to write some blady excelent code, something that no-one else can!!

Secondly, It'll be easy to prove that you wrote the original, Expecially because you will have a release date long before their copyright date.

If this is a reason not to use the latest developing software, it's acctually very lame....

Your tying to tell me sco group that had the thought they had the unix copyright that got over overthrown by novell had nothing to worry about because did own the unix source code at that time, but some very strong people made it not so. You just like giving your code to people don't you?

Just give it to me and I will show you how to feel about the .net.

One more thing, You can't make a badly excellent program in the .net. It is too slow.
June 27th, 2008, 11:52 AM
GremlinSA

Re: Why VB 6.0??

Quote:

Originally Posted by Joeman

You just like giving your code to people don't you?

Just give it to me and I will show you how to feel about the .net.

One more thing, You can't make a badly excellent program in the .net. It is too slow.

Go ahead, all the source for 'MY' applcations are online already. The projects i get paid for is a different story.. Just look at my signature for links to the two bigest private projects that i'm working on.. ( well havn't had time to do much on them lately).. And check out some of the articles, full source there too. then i also have a few projects of sourceforge, again full source there too..

I'm more of a OPEN SOURCE type of guy. However if someone else pay's for a program according to there given spec, I legally canot release the source, I'm also not legally allowed to release the exe.

What's the point many may say. Well with the GPL open source licence model, my code is available for all to use, and if it is truely brilliant code, somewhere someone will give credit for it, and not cash. For me programming is a hobby, that turned into my proffesion.

.NET may be one of the slower running development platforms, however (And i may get shot for this) it is also close to one of the more powerfull development tools, when it comes to windows applications (remeber you can include C#, VB & ASP into a single application)..

Wow very few subjects can get me typing this much ;)..
June 27th, 2008, 02:02 PM
WizBang

Re: Why VB 6.0??

I think one of the main things differentiating those who like .net and those who don't, is that those who do tend to be paid to write software which is not released to the general public. However, when your software needs to be widely distributed on the Internet, downloaded and purchased by as many people as possible, so you can afford to eat, it's quite a different story.

Quote:

Originally Posted by Arjay

So protect your software with the techniques that have been outlined. If this is so important to you, then perhaps native code isn't sufficient and you should look into a DRM?

It seems a bit ridiculous to continue to complain about this point when it is so easy to do something about it.

Since the techniques outlined, namely obfuscation and ngen, have been shown to be fairly pointless for public releases, it therefore doesn't appear to be "so easy to do something about it". Thus far, it has yet to be shown how .net code can be equally secure as a C++ native executable.

Quote:

Originally Posted by TheCPUWizard

This weekend i will post some samples of the output using various simple techniques to minimize what
is exposed, along with some simple examples of what can quickly be reversed engineered from a native C++ implementation of the identical program.

But if you want to run an experiment in the meantime. Take ANY .Net executable, run it through ngen.exe (which ships with the runtime) and examine the resulting .EXE file...

I look forward to your samples. But ngen means nothing if the MSIL still has to come along in order to make the program run. Your .net samples need to include all the files required for them to run.

Show 50 post(s) from this thread on one page

All times are GMT -5. The time now is 07:26 PM.