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.

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

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.

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.

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

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

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

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.

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.

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.

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

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

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?

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.

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.