Howdy people..

Back in the old DOS days, I had a de-assembler so I could edit software whenever I wanted to do so... Add features and such..

Now, I wonder... Is there such a thing for Win32 code? VB de-assembler? C...?

I know about the legal issues some software might have... But it's for personal use...

Originally posted by hypernatic.net
Howdy people..

Back in the old DOS days, I had a de-assembler so I could edit software whenever I wanted to do so... Add features and such..

Now, I wonder... Is there such a thing for Win32 code? VB de-assembler? C...?

I know about the legal issues some software might have... But it's for personal use...

Sure there is such software. They are mostly known as "decompilers". Search for them on Google.

Expect to be unable to use it for anything at all, unless you know what happens underneath the hood of your computer.

Originally posted by jks

Expect to be unable to use it for anything at all, unless you know what happens underneath the hood of your computer.

Why is that?

I think he just means that unless you know assembler really well the program will not be of much use. Sounds like you had that covered though. Went looking myself and found something rather interesting:

http://www.itee.uq.edu.au/~csmweb/dcc.html

Produces hex, asm, and c code from a binary. Sounds neat.

Yeah but that's WAY WAY back :)

like 6 years or so...

But isn't there a way to compile it into VB or VC code or something?

Originally posted by hypernatic.net
Yeah but that's WAY WAY back :)

like 6 years or so...

But isn't there a way to compile it into VB or VC code or something?

You can turn it into anything you like, even a Turing machine :-)

It will however not be any more read-able or understandable than before. The reason is, that much of the "human-imposed structure" is lost when the program is compiled and decompiled. For example the names of variables, the exact loop structure used, etc. may (and often will) disappear.

So a decompile and then edit and recompile wont work?? At all??

Originally posted by hypernatic.net
So a decompile and then edit and recompile wont work?? At all??

Ofcourse it'll work.

What I'm saying is, that you most probably won't know what and where to edit (unless it is something very simple you want to edit).

C is a language used by humans, not computers. A computer cannot understand C language. A compiler takes the C code and turns it into a language a computer can understand (binary, hex, whatever you feel like calling it). Assembler is the closest a human can ever come to programming in binary/hex (or so I'm led to believe). The relationship between the assembly and the binary your particular machine can understand is very, very close.

To go backwards means you need to take the binary/hex and convert it into something a human can read. The closest possible thing is assembly, so it tries to convert everything into assembly. The problem is, when the program was compiled in the first place, the variables us humans used to keep track of things turned into binary addresses. To my knowledge, those variable names aren't kept anywhere (unless it's deliberate) and when the program is decompiled, it's a mess. Unless you wrote the program, it's very difficult to do anything with it. I'm sure it's possible, but very difficult.

I once tried out a decompiler back about 6-9 years ago... I saw the output and deleted the decompiler. :)

If you've ever coded in assembly, you know how cryptic it can be (unless you code in it all the time, then it's like writing a book, eh?). Imagine taking that cryptic code, taking out the variable names, restructuring the loops, and then trying to redecypher it. Hehe... Not my idea of fun. At all.

There are also decompilers out there that will go from binary->asm->C. That C code will be pretty darn ugly, I guarantee.

Originally posted by allera
whatever you feel like calling it). Assembler is the closest a human can ever come to programming in binary/hex (or so I'm led to believe).

Well, it's not the closest. Those that remember the programming "way-back-then" has probably tried programming directly in binary (for example setting switches "up" or "down" on the front of the computer, or using similar mechanisms to input the program one byte or "word" at a time). It's however not something that would be handy on a Pentium 4 :-)

Apart from that, I strongly agree with your post.

Originally posted by jks
(for example setting switches "up" or "down" on the front of the computer, or using similar mechanisms to input the program one byte or "word" at a time)
Ok ok, I was thinking more along the lines of a processor with greater than 8-bit processing power. Even less than 8-bit, I would seriously hate to be the guy sitting there programming in 1s and 0s, ups and downs, offs and ons. I hated doing that in projects that involved a simple processor we built that could add and multiply. Took forver...

But you're right, programming in bin/hex is fully possible. Heehee...

Originally posted by allera

Ok ok, I was thinking more along the lines of a processor with greater than 8-bit processing power. Even less than 8-bit, I would seriously hate to be the guy sitting there programming in 1s and 0s, ups and downs, offs and ons. I hated doing that in projects that involved a simple processor we built that could add and multiply. Took forver...

But you're right, programming in bin/hex is fully possible. Heehee...

I even tried that on processors with larger than 8-bit processing power :-)

We had one with 32 switches... another had 8 switches and a button to press that "changed bytes".