Type of code conversion used in Linux executable files

Question

I want to ask that what type of encoding is used to make linux executable files e.g. hexadecemal, binary or anything else. how is it converted ? Is there any way to get back the original code from this executable file?

Here's a bit of code I have:

ELF���������>�����%|�����@�������������������@�8��@���������������������@�������@�����7<�����7<������� ������������������f�����f���������������������� ������[�UPX!L
h�h�8����������?�E�h=��ڊ̓�N�    4���9ISloB�q�w�]ȉ.��,ς��Q䝦����#e��-�N����/�b,���d<��'��-E��6E�s�/�U���ly�V�Y2]"a��S�.�hU�|�S�J�I�2���X}
�G0�;���5d�$���.)

what is it suppose to mean?

Answer 1

It's binary. The source code has been compiled. You can view it in an editor (a hex editor like bless might make for more refined changes) but you really need to know what you're doing. It's likely only good for making string changes.

For anything more hardcore, you can start to reverse engineer the binary into assembly code. This is often regarded as the lowest level human-parsable computer language.

objdump -d helloworld | less

But it'll include a lot of compiler nonsense too. For example, if you compile the most simple helloworld.cpp with G++ and then objdump it, you end up with 226 lines (208 stripped) of yuck. You could write a "hello world" in just 15 lines of assembly, compile it and objdump it but that still blossoms into 166 lines (stripped).

If you're good enough with assembly, this may give you enough access to understand what's happening, and even let you change it... But to answer your original question:

You cannot turn compiled code back into the original source code.

Sorry. It's a one-way transformation that loses information (comments, formatting, readable algorithm concepts, etc), is statically linked to other things and is generally optimised in such a way that would make it unintelligible to anything but the best and most seasoned programmers.

To give you an idea of the scale of the problem, the whole idea of reverse engineering software has its own Stack Exchange site.

Answer 2

I have not enough reputation points for a comment so it is an answer:

No, it is not possible to convert it "back". You mention upx packer, did you ever read the manual of upx?

If you lost the source, or do not have access to code of somebody else doesn't matter here, it is simply not possible.

The binary executable was produced with a compiler, don't believe anything stated on this site, just read the manual of exactly that compiler. Then, you could add here, in what language the original code was written, which compiler was used, and then you might note yourself that this steps (preprocessing, compiling, linking, maybe packing) are not reversed as a whole, but could only be analyzed what the original author might have intended, and written.

Answer 3

This is probably a binary file (an ELF File) as described nicely here:

https://en.wikipedia.org/wiki/Executable_and_Linkable_Format

If you have altered it with a normal text editor and saved your changes, this was no good idea and you may have destroyed it.

Answer 4

As Oli pointed out already in his answer, you can't get the very original source code of an executable.

During the compilation of a source code (compilation intended as in its typical wider acceptation, hence as the whole process that "transforms" a source code into an executable), lots of informations are lost.

The C preprocessor, for one, will do the following (among other things):

• Interpret, execute and remove preprocessor directives (# statements)
• Remove comments
• Remove unnecessary whitespace

On the other hand what isn't lost during the compilation of the source code is technically revertible to a functionally equivalent source code.

This is because:

• Binary instructions have a 1:1 corrispondency with assembly instructions; the assembling of an assembly source code is just a mere conversion of the assembly instructions to the binary instructions based on a table of corrispondencies; a single binary instruction is always identifiable and revertible to a single assembly instruction;
• Assembly instructions don't have a 1:1 corrispondency with C instructions; the compilation of a C source code is usually not just a mere conversion of the C instructions to the assembly instructions based on a table of corrispondencies, in fact it's often the opposite; usually a C instruction is converted into multiple (often different based on the compiler) assembly instructions; however, patterns of multiple assembly instructions are usually identifiable and revertible to a single C instruction;

There are tools called decompilers whose purpose is to try to revert an executable to a functionally equivalent source code; however the result is usually something far from the very original source code (and usually also uncompilable);

Consider this program:

#include <stdio.h>

#define MESSAGE "Literal strings will be recovered" // This preprocessor directive won't be recovered

/*

This comment and the comment above won't be recovered

*/

int main(int argc, char* argv[]) {
    printf(MESSAGE);
    return 0;
}

By compiling it into an executable and decompiling it into a source code again, this is more or less what you usually get back (in this specific case I used gcc / Boomerang):

// address: 0x80483fb
int main(int argc, char **argv, char **envp) {
    printf("Literal strings will be recovered");
    return 0;
}

As predicted:

• Preprocessor directives are missing
• Comments are missing (aside from // address: 0x80483fb, which has been added by the decompiler)
• Unnecessary whitespace is missing (aside from newlines and tabulations, which have been added by the decompiler)

This is also a pretty good result; it's not rare to get inline assembly instructions into the code:

asm("assembly_instruction");
__asm__("assembly_instruction");

The bottom line is (as pointed out already in the other answers): you can't get the very original source of an executable*.

_{*However, depending on the executable and on your luck, you might be able to get something using a decompiler.}

Answer 5

Executables are usually binary if you are talking about compiled programs. You can find more information by using file path/to/executable. You can display binary executables in hexadecimal by using e.g. hexdump -C path/to/executable | less (whatever good that would do you). If you want to "convert it back to its original form" you'd have to use an appropriate decompiler see this post, e.g., though that would give you quite unreadable code not the original it was compiled from. If it's not a compiled binary it would be some kind of executable script, which should be easily readable in any text editor. What you showed us here is probably a a compiled executable. ELF means "Executable and Linking format" which is a common binary format on Linux/Unix systems. There's a possibility to extract the readable string parts from binary files by using strings path/to/executable, if this is what you need.