If this is your first visit, be sure to
check out the FAQ by clicking the
link above. You may have to register
before you can post: click the register link above to proceed. To start viewing messages,
select the forum that you want to visit from the selection below.

Originally posted here by ;TT Java, Python, Perl, and numerous others don't compile into assembly. Get a clue.

Actually...I don't know Java, Python, or numerous others, but I know a touch of Perl. It compiles at run time, if I recall correctly. And for the processor to read and execute the code, it has to break it down into 1's and 0's...machine code. Is machine code the same thing as assmebly? I didn't think so, but now I'm not so certain...

"Data is not necessarily information. Information does not necessarily lead to knowledge. And knowledge is not always sufficient to discover truth and breed wisdom." --SpafAnyone who is capable of getting themselves made president should on no account be allowed to do the job. --Douglas Adams (1952-2001)
"...people find it far easier to forgive others for being wrong than being right." - Albus Percival Wulfric Brian Dumbledore

Originally posted here by zencoder Actually...I don't know Java, Python, or numerous others, but I know a touch of Perl. It compiles at run time, if I recall correctly. And for the processor to read and execute the code, it has to break it down into 1's and 0's...machine code. Is machine code the same thing as assmebly? I didn't think so, but now I'm not so certain...

Assembly language is still only a textual representation of machine code. It's a collection of mnemonics (insert college flashback here) used to represent the binary instructions that are 'machine code'.

"Data is not necessarily information. Information does not necessarily lead to knowledge. And knowledge is not always sufficient to discover truth and breed wisdom." --SpafAnyone who is capable of getting themselves made president should on no account be allowed to do the job. --Douglas Adams (1952-2001)
"...people find it far easier to forgive others for being wrong than being right." - Albus Percival Wulfric Brian Dumbledore

Wow I ask a small question and get maybe 2 or 3 helpful answers and of course one jerk in the middle that thinks thier above everyone else. Anyways thanks for the replys and for the link. You have helped me out in a way.

Phatcat, it is not simple to ask good questions, but your one leads to a
couple of interesting aspects. Congrats.

My main message: There are differences in difficulties, but in the end it depends on what
you have to RE. Is it a very complicated hash algorithm or just simple if-statements?
And this task is completely independent on everything: It can be very hard
to understand what an algorithm is doing even if you have it in source code.
So, RE also includes the understanding of the source code.

Different compilers -&gt; different machine code

There are differences, in my opinion.

It might be a matter of taste, but let us look at stand-alone executables only.
On one hand, an executable built with VisualBasic has a (visually) rich structure
in it, due to the drag-drop controls. Therefore, it is simpler to be REd, because the
pieces are already given. On the other hand, executables built with c/c++ compilers
are more "messy". And here, there are even substantial differences based on the compiler
used (Microsoft-cc vs devc++, gcc vs icc vs KCC vs pgcc). So I claim it is simpler (faster...)
to RE a visual basic executable, than a console program compiled with M-cc. Now, what
about a Visual C program using MFC? Note, there are tools like IDA[1], which supports
the process of RE immensely.

Interpreter versus compiler

Several languages like BASIC, Lisp, Perl and maybe even Java are "interpretative" languages
(Is there a Perl compiler? I would be interested ).

If you want to reconstruct the source code (not to understand it), you are already done
(yes, even with Java: as far as I recall, there are quite capable program reconstructing the
.java file based on the .class file). I call java an interpretative language, because the
bytecode (.class)-file is interpreted while runtime.

You can't really protect an executable - however, you can apply some "security through obscurity"

Java, Python, Perl, and numerous others don't compile into assembly. Get a clue.

That's because they aren't compiled. cep't Java. Scripts are interpreted. Also, if you consider assembly to be "human-readable notation for the machine language that a specific computer architecture uses", Then perhaps Java can be dissesebled into an "assembly language"
However you want to look at it. Java's an odd one.

The difference between an interpreted and a compiled language lies in the result of the process of interpreting or compiling.

An interpreter produces a result from a program, while a compiler produces a program written in assembly language.

The assembler of architecture then turns the resulting program into binary code.

Assembly language varies for each individual computer, depending upon its architecture. Consequently, compiled programs can only run on computers that have the same architecture as the computer on which they were compiled.

As previously stated Java is (like C# is now) the wierd one as far as programming languages go. It's "Compiled" into java byte code, which is then interpreted by the Java Virtual Machine, which I've heard is very similar to the sparc architectures bytecode. Which mean that it is technically not compiled or interpreted, it's both, a wierd hybrid of the multiple types. BASIC, while generally interpreted, became compiled with certain versions of it (QB4.5) was on that I recall. Much like VB is now. Although if I remember correctly it was a pain in that you had to have the obj files with the exe for it to run.

On the disassembly thing:

No matter what programming language you start out in, if compiled, when disassembled they will be pretty much the same, because of the great multitude of steps that go into forming a compiler, it would be very difficult (read impossible) to get them to the exact way they were in their original source. Because of the different optimizations and various other steps in the compile process, the code (functions and what not) may be in a completely different order than originally written in. While theoretically possible to do this, these many steps for compilation make it extremely difficult, so while something similar may be given to you it won't be exact. And because a single hardware architecure has to have the same machine independent language, all languages on that machine, when compiled, could in theory be disassembled with the same degree (depending on the algorithm its disassembling mind you) of difficulty.

You should not have to worry about doing such things with an interpreted language (even though many*, i.e. php can now be compiled, Common LiSP is also interpreted or compiled*) because they are interpreted and you are supposed to have the source to run them...