Hi,

I have an exe file i want to convert it into orginal to view its source code(VBScript).Can any one help me out how to do this task.

Thanks in Advance
Naag

Simple answer: you can't.

Imagine if you could get the source code of Microsoft Office or anything like that, just by opening the exe in a file reader.

They would lose soooo much money.

In some cases you can. I have a .NET decompiler that can reconstruct the original source code of any .NET program. It works extremely well too. However, in most cases, it is possible to disassemble a program into assembly language.

Yeah, but VBScript?

Didn't notice that part until now. Pretty sure he meant normal VB code.

Wow, I was hoping you could too. Oh Well.

Yep.. agreeing with others. The simple answer is, you can't get the source.

VB6 compiles to native code, so the best you'd get is assembler language. Even if the program is compiled to PCode, it'll be hard to find a decompiler that'll come close to giving you anything but a mess. iirc, the last decent VB decompilers were around in VB3 days. Since the "native code" option was introduced, there hasn't been much development on a VB decompiler.

Native code's nothing like dotNet. dotNet "compiles" to an intermediate language that's compiled "Just in Time" on the target computer... that adds the benefit of targetting specific CPUs and other hardware, but it makes it incredibly easy to decompile. There are tons of dotNet decompilers available.... in fact, there are so many, quite a few software vendors simply "up the price" of their suites and include the price of the source... which is cool, if you can afford it... there's a lot to be learned from looking at the source.

By the way... if it's an exe, it's not VBScript. It's probably VB4, 5 or 6... thinking a bit here (imagine that!) are you sure it's even VB? If so, how? Did you lose the source after compiling?

Quite often VBScript is stored in its source code form.
If the extension of the file is VBS (such as file1.vbs), then open the file in any text editor to read the source.

It is possible to have upto 100% accurate decompilation for non-native code. That is why you will find decompilers for .NET, Java, ActionScript, VB6 (P-code) etc. This is because for byte-code format specific techniques are imposed by the compiler to implement each feature( this gives you the best performance ).

For Example,
A while() loop will always have the same pattern in Java Byte-code, VB6 p-code and .NET managed code (it doesn't have to be so, but Sun and Microsoft insisited that it be so)

Thus, A simple series of steps for decompilation specific to a byte-code language will work for all programs compiled in the same format.

But decompilation techniques for native code are not yet developed as of now as each compiler has its own tricks and techniques to implement a code construct.

For Example, a particular machine-code pattern might be equivalent to a while() loop compiled in VC++ but Borland C++ might have a different method of implementing while(). It is difficult to consider this situation while attempting decompilation.

Hence you can't use the same set of decompilation steps to decompile every program.


EVERY machine code instruction has a unique and equivalent assembly language instruction.

Thus, it is always possible to convert machine language instructions to assembly (holds true even for programs protected with Packers)

Actually, just as there are .NET obfuscators, that can scramble a .NET program so it cannot be decompiled, there are also anti-disassembler obfuscators, to make programs fool disassemblers.

Wrong. Very Wrong.
The only thing obfuscators do is change the name of classes and variables to A,B,C,D or random hex strings such as 2342f42b123a123c13e().

Here's how they work.

If I use MessageBox.Show() anywhere in my program instead of appearing in the Decompiled code as System.Windows.Forms.MessageBox.Show(parameters) it will appear as A.B.C.D.E(parameters) (or worse yet, 2342f42b123a123c13e.565213162fcad.6237462376273.bad.b32fca(parameters) )and it can be very frustrating to understand this in larger programs.

Java Obfuscators use the same principle.

Obfuscators do not prevent decompilation as the result of the decompiler is still correct. It just makes it harder to read for reversers.


Yes, but by cheating.
They insert incorrect machine code instructions in the code and surround it with jump like this:

An example of an incorrect machine code instruction is the byte 0x08.
0x08 is the instruction for the OR instruction which consists of 2 bytes.
But since only 1 byte is provided (0x08), the following byte (from the program code) will be considered as the parameter for the OR instruction.

If such an instruction gets executed, the program will crash. Hence a jump prevents the incorrect byte from being executed.

Disassemblers will still try to disassemble the OR instruction and will either screw up the disassembled code or crash.

However, this technique (and other similar ones) does not affect smarter disassemblers such as IDA Pro.

I have a .NET obfuscator. I tested it on a program, and when i tried to decompile it, my decompiler screwed up so bad i had to close it in task manager. Maybe it just wasn't a good decompiler.

Try Reflector .NET or ILDASM (shipped with Visual Studio)

I have the express editions, so i didn't get any of the luxuries. I am using a free decompiler called Xenocode Fox Community edition. It's like an express of the pro version, and so it's missing some features, but overall it does a fair job.

Oh, okay.
But Reflector .NET is free.

What's it's home page?

Click here.

Thanks, that reflector thing is great. Way better than what i was using.