1. Welcome to TechPowerUp Forums, Guest! Please check out our forum guidelines for info related to our community.

What stops Source code rips?

Discussion in 'Programming & Webmastering' started by <<Onafets>>, Nov 25, 2010.

  1. <<Onafets>>

    <<Onafets>>

    Joined:
    Nov 8, 2008
    Messages:
    779 (0.24/day)
    Thanks Received:
    77
    Location:
    Sydney, Australia
    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?
     
    Last edited: Nov 25, 2010
    smartali89 says thanks.
  2. streetfighter 2

    streetfighter 2 New Member

    Joined:
    Jul 26, 2010
    Messages:
    1,655 (0.62/day)
    Thanks Received:
    732
    Location:
    Philly
    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.

    The short answer is pretty much everything.
     
    smartali89 says thanks.
  3. W1zzard

    W1zzard Administrator Staff Member

    Joined:
    May 14, 2004
    Messages:
    16,962 (3.43/day)
    Thanks Received:
    17,948
    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

    the only thing that has never been cracked before is something that's not interesting enough for the pro crackers
     
    smartali89 says thanks.
    10 Year Member at TPU
  4. <<Onafets>>

    <<Onafets>>

    Joined:
    Nov 8, 2008
    Messages:
    779 (0.24/day)
    Thanks Received:
    77
    Location:
    Sydney, Australia
    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?
     
  5. W1zzard

    W1zzard Administrator Staff Member

    Joined:
    May 14, 2004
    Messages:
    16,962 (3.43/day)
    Thanks Received:
    17,948
    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
     
    <<Onafets>> says thanks.
    10 Year Member at TPU
  6. Arel3 New Member

    Joined:
    Nov 7, 2010
    Messages:
    39 (0.02/day)
    Thanks Received:
    3
    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.
     
  7. Kreij

    Kreij Senior Monkey Moderator Staff Member

    Joined:
    Feb 6, 2007
    Messages:
    13,817 (3.50/day)
    Thanks Received:
    5,629
    Location:
    Cheeseland (Wisconsin, USA)
    I don't bother obfuscating my code.
    Hell, I usually just give out the source code if someone asks for it. :laugh:
     
    10 Year Member at TPU
  8. Arel3 New Member

    Joined:
    Nov 7, 2010
    Messages:
    39 (0.02/day)
    Thanks Received:
    3
    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.
     
    <<Onafets>> says thanks.
  9. qubit

    qubit Overclocked quantum bit

    Joined:
    Dec 6, 2007
    Messages:
    14,533 (3.99/day)
    Thanks Received:
    8,274
    Location:
    Quantum Well UK
    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. :D 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. :respect: I wish it was at the heart of every desktop PC instead of x86.
     
    <<Onafets>> says thanks.

Currently Active Users Viewing This Thread: 1 (0 members and 1 guest)