13

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?

  • Although it won't help you get much of anything back, its worth noting that the strings filter program can be very useful in identifying what a particular binary program is or does because it will print all the embedded text strings longer than a specified length in a binary file and looking at the messages in a program sometimes tells you a lot about what it is and does. – Joe Sep 10 '15 at 9:12
  • Possible/partial duplicate? stackoverflow.com/questions/193896/whats-a-good-c-decompiler – arielf Sep 12 '15 at 0:41
29

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.

  • Can you tell me how do I reverse engineer it and get back maximum amount of code coz I've lost the source – redchief Sep 8 '15 at 9:26
  • 7
    See my recent edit. There's no going back to the original source. With a lot of learning and a lot of time, you might be able to rewrite source based on the disassembled assembly code, but in most cases, it would be cheaper (unless your time is worthless) and easier to just rewrite it from scratch. – Oli Sep 8 '15 at 9:31
  • 1
    The way to get back the maximum amount of code is to restore the most recent backup. That is also, incidentally, the only way to reliably get back something resembling the original source code. – a CVn Sep 9 '15 at 12:18
  • 1
    Not disagreeing with the last paragraph at all, just a side note: some decompilers IME make a great job at restoring the exact code structure (aside of course from as you said comments, formatting, symbols' names...). If you didn't write the program in first place the recovered source code might be still unintelligible, however I think it's a great option to recover (at least partially) a lost source code / an unknown source code (with at least parts of it actually intelligible, depending on the specific code and on whether you're lucky as well) – kos Sep 9 '15 at 12:42
  • 1
    That's what all those EULAs in the proprietary software world say you are not allowed to do - reverse engineering/disassembly. They include clauses like this because it is possible to do - but certainly not easy! But as @MichaelKjörling says, the only good way to get things back is from multiple levels of backup for anything you care about. – Joe Sep 10 '15 at 8:59
7

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.

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.

3

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.

2

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.

  • I tried to reverse engineer it with upx packer but didn't work and also with the post you've suggested. So please tell me if there's another way. – redchief Sep 8 '15 at 9:25
  • Very sorry, but I cannot tell you anything more than what is written in @Oli's excellent post. – Hinz Sep 8 '15 at 10:03

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.