JtheD

Hello Everybody,

I need to know that is there a way to look inside a EXE file, i mean how to decompile a VB EXE file.

Thanking in advance


Sincerly
JtheD

OnErr0r

You don't.

BillSoo

This is one of the most common myths in VB....the mysterious fantabulous decompiler!

The short answer is that there ain't no such beast. The long answer is a bit more complex.

Back around version 3 or 4, VB compiled to a kind of p-code rather than a true executable. This p-code contained a *lot* of redundant information about the source code. Things like variable names and comments for instance. Thus someone wrote a decompiler that could decompile a VB3 executable. Note that VB3 is a 16bit language, not 32 bit like VB6.

If you compile a program in VB6, the default is to compile to native machine code. As part of this process, the compiler strips variable names and comments from the code. It also optimizes your program as much as it can, depending on settings. Once it is done, you can never get back the original VB source since so much is lost. The best you can do is decompile to assembly code and from that, make guesses as to what the original code *might* have looked like.

If you change the compiler options and compile to p-code, like VB3 did, then *maybe* you can decompile it but since it's 32 bit, you probably can't use the old VB3 decompiler to do it. Also, it's likely that MS did away with that strange practice of keeping so much info in the p-code.

So there is no decompiler available unless you
a) program in VB3 OR
b) program in VB6 AND set your compiler options to p-code

If "a", then there is a decompiler, but I don't know where you can get it. If "b", then I don't know of one, I doubt one exists, but I can't deny the possibility that one may exist.

Lord_Riff_Raff

Ah good because I was about to ask the same question to check that no-one else could do this before I bothered obfursicating my code.

Then again it does mean we won't find the equivelent of the brilliant java decompilers that give better code out then code in.

Ales Zigon

Yep!

BillSoo

The compilation process is "one way" and as such, is similar to many other processes. For instance, consider the simple parity check.

You start off with a number of bits (0 or 1). You count the number of "1" bits and if they are odd, you add a "1" and if they are even, you add a "0".

So:
10101010 + 0 = 101010100
11100110 + 1 = 111001101

The system is irreversible in that you cannot determine what the original number was if all you have is the parity bit. I mean, given a "1", the original number could have been
11100110 or 11110111 or 00000001
You *do* know that is isn't 00000000 or any other even parity, but that's about it.

When you disassemble the executable to assembler, you may see some kind of loop structure. Is it a Do-While or a For-Next Loop? You may be able to tell, or you might not. And in any case, the variable names, procedure names etc. are all lost. You would be better off rewriting the code from scratch (and take advantage of the opportunity to make it better too!).