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

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.

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.

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.

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

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.

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.

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

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)

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?

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.

---

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.

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.

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?

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.