What stops Source code rips?

[<<Onafets>>]

Since i started programming have always wondered what stops source being ripped from programs. I.e opening a .jar file displays random stuff (obviously not source) yet game crackers manage to crack games with out the source code. IS the gibber jabber when opening .exe files with notepad decryptable and if not what makes it so unique that it has never been cracked before?

In simple terms, what stops source code being extracted from already compiled programs?

 

[streetfighter 2]

If you open a compiled executable (exe) with a hex editor it may appear to be gibberish (and some of it really is) but to advanced users there are some decipherable blocks, some of which can be understood and, occasionally, even converted into high level languages.

I want to point out though that "decompiling" is a bit of a contradiction and although technically possible, it's not likely to resemble the original source code unless the binary was compiled with debug options. There are tools like IDA Pro
and Dependency Walker along with memory tools and hex editors which can be used to reverse engineer software but it is a very laborious and difficult task even for skilled programmers.

I'm not sure about .jar files but I know that Java is a pseudo-compiled language which involves compiling it into a platform-unspecified "bytecode" which is interpreting by the Java program.

In simple terms, what stops source code being extracted from already compiled programs?

The short answer is pretty much everything.

 

[W1zzard]

when using .net, delphi or java your program can be easily decompiled into what is basically the original source code. there are some obfuscators that make it harder.

when using a compiled language like c or c++ your program is turned into assembly code and disassembly produces only assembly code, not native language code. there are very few decompilers for native that look at the assembly code and try to figure out what kind of statement it was that created that assembly code.

the bottom line is that you can not 100% protect your code from other people reading or modifying it. you can make it harder though

what makes it so unique that it has never been cracked before?

the only thing that has never been cracked before is something that's not interesting enough for the pro crackers

 

[<<Onafets>>]

Thanks, that answered my question perfectly! So basically what your saying, unless programs are encrypted with random, complex algorithms, all source can be ripped with enough time and patience?

 

[W1zzard]

unless programs are encrypted with random, complex algorithms,

all source can be ripped with enough time and patience. period.

you need to decrypt to execute, so just dump the decrypted code off the cpu

 

[Arel3]

Ya. I'm with the other posters that have answered. It's usually due to either some type of encryption, or it's compiled.

Both can be decrypted or compiled programs can be broken down into their individual files and those files can be opened and read. Usually in plain text. The trick is figuring out which compiler was used or decoding the encryption to get to the actual code in the form of simple text.

Then again some coding languages that are made of simple text that can be opened in windows notepad...the syntax of how it all comes together and works may look like gibberish.

 

[Kreij]

I don't bother obfuscating my code.
Hell, I usually just give out the source code if someone asks for it.

 

[Arel3]

I don't bother obfuscating my code.
Hell, I usually just give out the source code if someone asks for it.

hehe...you're rare. Most coders I know of, even my self with some of the really cool things I've created as a 'first', guard their production files and source code like satans pit bulls that guard the gates of hell. LOL!!

I'm glad to share the result under GNU/GPL but the source and production files?
NAY NAY!!!
Figure it out. Maybe someone, if they do spend the time to bust it open and figure it out, can improve it.

 

[qubit]

I've programmed early versions of the ARM processor in Assembler back in the early 90s on Acorn computers and it was a fantastic experience. Because it's a true RISC CPU, all instructions fit into a 32-bit word. This means that all the instructions get disassembled accurately every time, with no room for ambiguity.

Wondering what I mean? x86 instructions being CISC, vary in byte length from somthing like 1 byte all the way to 5 bytes (I don't know the exact figures, so don't pull me up on this detail). This means that when looking at object code, ambiguities arise over what blocks of bytes decode to what instructions. This doesn't happen with ARM instructions. Where there is actual data or empty space filled with random garbage, it will still be disassembled into apparent ARM instructions (where it fits valid op-codes). However, it's easy to separate real ones from fake ones by following the program flow by eye. And I'm sure they now have automated tools to spot these in a flash.

The ARM CPU is so elegantly designed. I wish it was at the heart of every desktop PC instead of x86.