Translating binary executable file languages?

In what language specifically is the code written in for the binary files that can be executed on macOS? I want to be able to read the obfuscated input/output that seems like its written in various formats.


I'm under the impression that it's either written in applesingle, binhex or macbinary. Is this the case and exclusively these or others too? I often will see large percentages of everything in pretty much random characters and then parts in plain English as mostly comma separated paragraphs. What all can the OS understand? What is the difference between all of these cryptic programming languages?


Can I just use binhex or uudecode to translate everything. There must some sort of formula to translate or it must follow some pattern the computer understands. For example I want to get the human readable text behind something like w%00%00%00 (I already know this usage/effect but what is that really say?). I would like something understandable like boolean where true is 1 and false is 0 that can be used constantly to translate stuff, if it exists.

MacBook Pro TouchBar and Touch ID, macOS Sierra (10.12.5)

Posted on Jun 23, 2017 12:11 PM

Reply
10 replies

Jul 7, 2017 7:56 PM in response to chase_daniel

Hello again chase_daniel,

What is impossible is trying to make a connection between the binary executable and source language when using a high-level, object-oriented language.


As we have said repeatedly, the binary is the meaningful language to the computer. Those are the low-level instructions that the Central Processing Unit will execute. They are all just numbers. You can substitute some mnemonics for the instructions and parameters and then call it "assembly language". If you have many years of experience with assembly and low-level debugging for a particular CPU, then you might be able to make sense about of the raw binary. But that would still be at a very low level - branch to instruction if contents of register are zero, push value onto the stack, pop value from the stack, add two numbers and store result in register. And that's about it. That is what the binary means.


You are welcome to ask your question on Stack Overflow if you want. It might not be the experience you hope to find though. Instead of other people telling you that you are wrong, you will have other people deciding that your question simply isn't worth anyone's time and they will close it for you. Here in Apple Support Communities, this is your question and you can award helpful and/or solved points if you want. Apple moderators will, on rare occasions, edit or delete a post that violates the Apple Support Communities Terms of Use. But generally, you are in charge. On Stack Overflow, the community is in charge, not you.

Jun 23, 2017 1:00 PM in response to chase_daniel

Do you have any knowledge of computer programming?


Are you after the source code (i.e. the lines the programmer wrote in a language like C++) which generates the executable? For that I think you would need a "decompiler" app.


Or are you just looking for the contents of some kind of text file which is in binary format?


Could you provide an example of the name of a file you want to decode?

Jun 23, 2017 1:53 PM in response to chase_daniel

Hi. Do you have a graduate degree in computer science? You'd need that to even begin to understand the answer to your question. The executable file is a mixture of coded instructions to the run-time loader, actual binary machine code instructions according to the processor's instruction set, and patches of initialized data. The text you see is some strings used by the program, messages, filenames, etc. If the program was written in a traditional language, like Fortran, it would be only pretty difficult to figure out. But if it's written in an object-oriented language, like Objective-C, it is essentially impossible, because the flow of control is so convoluted. Integration with shared libraries only adds to the fun.

Jun 23, 2017 2:00 PM in response to Diana.McCall

Rereading your question, I'd like to emphasize that there is no text form of a binary executable file. The source code, in the form of programming language statements, was written by programmers, using many source files. These were compiled and assembled to produce binary machine code, which was then merged by the linker to produce the file you see. This is not some kind of binary obfuscation. It is the process of converting human-readable text to machine instructions that the processor can execute directly.

Jul 7, 2017 6:44 PM in response to Diana.McCall

I don't see how having a graduate degree is necessary for something like this. Maybe it's more complex than what I was looking for but I'm not sure that's even the case.


Stack Exchange seems to be more focused on enabling users and sharing information as opposed to trying to convince people they are wrong and there is nothing further to see here good day. It's especially evident in so many good or complex questions that are never even responded to by the person asking them after being barraged with a bunch of people telling them they shouldn't even be asking really or simply are content with that's nothing to be interested in. I'm not saying that's exactly what happened here but I personally would have had different and hopefully more tangible suggestions for someone who was wondering this. Maybe even include some links of potentially useful resources.


If it's impossible how does a computer understand it? I'm assuming it must ultimately be translated into binary so a computer can understand it. Wouldn't this be able to be translated back into some form of meaning?

Jul 8, 2017 2:40 AM in response to chase_daniel

chase_daniel wrote:


I'm assuming it must ultimately be translated into binary so a computer can understand it. Wouldn't this be able to be translated back into some form of meaning?


The process of translating from programming language into executable is called compiling. Perhaps it would help if you looked into what that involves, via wikipedia or other sources. Translating back would be decompiling. Look that up in wikipedia as well. It is usually very difficult, except is special cases like a Java Virtual Machine.

Jul 8, 2017 3:45 AM in response to chase_daniel

I'd like to endorse etresoft's description. The computer is a relatively simple machine. It doesn't "understand" the binary instructions. It executes them. The bits in each instruction identify a particular command (LOAD, ADD, BRANCH, etc.), the flags to test/modify, the register to use, and the address and size of a memory data value. So, with some effort, you could interpret a program at that level, stepping along, keeping track of register and memory values, etc. But trying to tease meaning out of the millions of instructions in a given file would be humanly impossible.


On top of that, the flow of control (which instruction to execute next) of a modern object-oriented program is essentially inscrutable. The huge number of classes and methods (subroutines) mean that the program seems to jump around almost randomly. Shared libraries and system calls further complicate matters, since you'd need to decode the operating system resources along with the program being examined.


A long time ago, I was able to read binary code in the form of a hex dump printed by a lineprinter. But that was on the IBM 1130, a very simple computer with 32 K bytes of memory. It was a tedious process, and even then, the overall meaning was not really clear.

This thread has been closed by the system or the community team. You may vote for any posts you find helpful, or search the Community for additional answers.

Translating binary executable file languages?

Welcome to Apple Support Community
A forum where Apple customers help each other with their products. Get started with your Apple Account.