Printable View
:confused: I was wondering what the hardest programming language was to "Crack/Reverse engineer" ? I have been told all types of garbage mainly from people that can't even turn a computer on without a step by step guide written with crayons. I know Visual Basic is one of the easiest and some say that Delphi is easy. Is there a programming language that is so difficult to "Crack" that people don't even try to mess with it?
I ask these questions out of pure curiousity.
Crack the programming language or the program written in it ? wtf
:( oops the program written in it. Sorry about that , the flu and computers dont mix to well.
Well im not a programmer but can any complied .exe be decompiled all the way to the code without being give the source files etc ?
/* deleted - not relevant nor helpful - sorry, it got away from me */
What makes you think that you or half the jokers on this site are above this?Quote:
I have been told all types of garbage mainly from people that can't even turn a computer on without a step by step guide written with crayons.
What are you sniffing, dumbass?! You mean being brought back into original source? Not really... I have yet to see decompiled executables look anywhere near it's original source. But something like JAVA could ALMOST be brought back to original source though, or atleast close enought.Quote:
Well im not a programmer but can any complied .exe be decompiled all the way to the code without being give the source files etc?
Zen, you know you can actually delete that post instead of editing it saying you "deleted blah blah comment".
it is extremely difficult to fully gain access to source code from a compiled, executable file. I've done a bit of 'adjustments' to different game files and the like using a hex editor, but only to specific values and never to functions. If there's a solid decompiler out there I'd dearly love a copy of it...
Whatever language you program in, they are all compile into assembly so none is hardest to crack after a compile.
here's a good place to start http://www.debugmode.com/dcompile/
there are tons of decompilers, none of them will reproduce the exact source especially in this age of optimizers, but you can get reasonable results from a few. I've never tried running one on somthing huge, only on my own progs(few 100 to few 1000 lines at most) just to see. The Java decomp I tried worked the best for me, but that has alot to do with the way java is only part compiled/interpreted anyway.
Assembly is your best bet as was previously said, it takes time to understand what's going on but you'll find that disassembling an executable will yield much more reliable results.
So I guess to answer your question, no language is truly safe from being RE'd
Good luck...
Java, Python, Perl, and numerous others don't compile into assembly. Get a clue.Quote:
Originally posted here by SDK
Whatever language you program in, they are all compile into assembly so none is hardest to crack after a compile.
lol,Quote:
Originally posted here by ;TT
Java, Python, Perl, and numerous others don't compile into assembly. Get a clue.
/me watches tact fly out the window
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...Quote:
Originally posted here by ;TT
Java, Python, Perl, and numerous others don't compile into assembly. Get a clue.
Quote:
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'.
I guess what I'm sayin is uh... no.
Uh... cool. Alrighty then.
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.
Hi
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 -> 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" :D
Cheers
[1] http://www.datarescue.com/idabase/
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" ;)Quote:
Java, Python, Perl, and numerous others don't compile into assembly. Get a clue.
However you want to look at it. Java's an odd one.
http://java.sun.com/j2se/1.3/docs/to...ris/javap.html
http://www.cs.rpi.edu/~moorthy/Cours...bler/jasm.html
You can obfuscate your binary, with burneye or some other encryption tool. I don't know how trustworty burneye is but I know it does just that.
Wow thank you both. Those links you gave are really good and also helped me understand a bit more about java and decompiling.
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...
*I can prove this, ask me how...
the function called (compile-file...) turns the lisp code into compiled code...
On another note, you all are so condescending. Try constructive criticism.
The think its the processor and if we go deeper the ALU, all need to understand the compiled program. The compiled program is just a series of opcodes, that can be easily converted back to ASM, with no major hassle.
The difficulty only comes with things such as exterior calls to functions and libarys cause the code to become somewhat obfuscated,
but a good revenger can happily work his way logical or in a more abstract way around things like this, so if we talking about just a langauge whose compiler does not attempt optimisation and packing, then it is a logical set of steps to achieve this process.
i2c