Can all programs be converted to assembly?

Say w开发者_如何转开发e have an exe, can that be readily converted to assembly? Is there a way for software authors to prevent/obstruct this?

No. A program can only be run by your system if it can understand it; if it understands it, it probably is in machine code, which is directly convertable to assembly.

What you can do is to try to employ code obfuscation methods, so as to make the disassembled binary as hard to understand as possible.

http://en.wikibooks.org/wiki/X86_Disassembly/Code_Obfuscation

Edit: Would like to add that, of course, with time and enough resources, someone will eventually figure out how to read your obfuscated code. It's unavoidable. What obfuscation does is to make reverse engineering your work as inconvenient as possible, to make it not worth their time pursuing it, so only those who want to reverse engineer it badly will do so.

Executables are designed to be executed (hence the name) by computer processors. The assembly language is a layer on top of the machine-code that the computer processor executes. If your program can be run as machine-code, then it can be read as assembly.

You probably have a situation like this: A proprietary C/C++ written program is being distributed to clients. Some of the clients have less than honest intentions, they decompile the program to assembly, change some instructions (for example those that prevent malicious use of the program, extending the programs trial feature indefinitely), and then recompile the program.

In that case, or similar, you must realize that all programs when not executed are simply as data on the disk. Anyone can read that data and change it to their liking. If this really is a problem, you're going to have to come up with another way to protect your program: For example delegating the important logic to a webservice that executes it and sends back the results. An example of this: Googles' search algorithm which runs on their own webservers - no one knows exactly how it works.

In a word, no. Just like you can't prevent someone from reading and analyzing a book that you give them.

If by "converted" you mean compiled, and by that you mean compiled to machine code, yes, absolutely. Every bit of code that runs on any box is running as machine code. For any particular language the answer varies based on whether tools exist to create a stand-alone executable that does not need the language's run-time libraries.

If by "converted" you mean manually coding it in Assembly, see the other answers. We don't do that because it takes a very long time to write the code.

As for obfuscation, the conversion/compilation I mention in the first paragraph does not really work for this. When you "compile" something like Java or C# the source is translated into a lot of pointers into the run-time libraries. Those pointers can easily be reverse engineered and the original code re-generated.

I think maranas has the best answer to this so far but would add that I think you can disassemble the program, with some conditions. First think of it this way, if it is actually executable, meaning can be executed by a processor then absolutely you can parse through that binary in exactly the same way the processor can and that means you can parse through every bit and byte and turn that into a human readable form ascii/assembler. This is always possible if the program can be executed.

Now, are there things that can prevent that from working if all you have is the .exe file, sure, lots of things and maranas answer linked to some of them, for example encryption, and if the keys to that encryption are in hardware or a user password or something that is not included in the .exe file then you may not be able to figure it out and it is game over.

Over the years of writing disassemblers I have seen different tricks, sometimes intentional, sometimes not. For example if you read the Zen of Assembly by Michael Abrash I seem to believe there was a discussion about the prefetcher in the 8088/86 the discussion being a way to tell one processor from another (remember this was before caches), but also to defeat hackers. What you could do for example is have one instruction modify the next instruction, increment it lets say. This would execute perfectly because that second instruction had already been fetched and was in the pipe, so the modified instruction was only in memory, the unmodified instruction would get executed. Naturally this needed to be code that was only run once as that instruction was being modified in ram. What this did was in particular stop folks from single stepping through your code with a debugger, because the debugger would execute the modified instruction and crash or do something like that. And if your disassembler attempted to simulate the program and didnt account for the way the hardware works again you would be lead off into the weeds. I have also seen the use of say loading a register with an immediate of zero followed by a branch if zero, which is the same as an unconditional branch (assuming that register really didnt need to be zero), follow this by some data that will cause the disassembler to get tripped up. You need to be on a variable word length instruction set for this to work. Not difficult for a human to figure out what happened and hand adjust the disassembly process to avoid the data word that is not an instruction, but more difficult for an automated tool (that isnt a simulator). The list of tricks goes on and on...

The bottom line is if your program can be executed by a processor then yes absolutely you can convert the machine code back into a human readable assembler form. And yes there are things you can do, in particular using hardware features that are secret or not obvious to the disassembler looking only at the executable file, that can and will prevent disassembly. As with any security measure if the user has physical access to the thing they can probably defeat it, if they have the ability to run the program on hardware they likely have the ability to defeat your security measure and disassemble it.