Originally posted by: JEDI
first 1/3 of the HL2 source code is leaked.
next, a full compiled version of HL2 pre-Beta is leaked.
how hard is it to get the source code from a compiled version? and if it is hard, WHY?
With standard java and c# or vb.net code, it's super easy because they are interpreted instead of native compiled. There are tons of tools. MS even includes a tool with dotnet called ILDASM. It stands for Intermediate Language Disassembler.Originally posted by: Argo
Originally posted by: JEDI
first 1/3 of the HL2 source code is leaked.
next, a full compiled version of HL2 pre-Beta is leaked.
how hard is it to get the source code from a compiled version? and if it is hard, WHY?
Depends on the programming language. If it's c/c++ (almost all games are written in c++) and it's a not a debug version - it's virtually impossible. It might be slightly easier for java/c#.
Fine if you're playing with yourself, using built-in cheat codes or something like a character editor in an RPG.Originally posted by: alkemyst
Now the comment about cheat writers??? WTF did that mean....some cheat apps are pretty elaborate and some are just commandline based, either way they aren't requirements to use.
It's a game the player should enjoy it, if that means being able to cast "Lightning Lvl. 1,000,000 Your body explodes into a fine bloody mist." their first time playing the game or have a BFG900000000 with unlimted ammo....
Originally posted by: Shanti
With standard java and c# or vb.net code, it's super easy because they are interpreted instead of native compiled. There are tons of tools. MS even includes a tool with dotnet called ILDASM. It stands for Intermediate Language Disassembler.Originally posted by: Argo
Originally posted by: JEDI
first 1/3 of the HL2 source code is leaked.
next, a full compiled version of HL2 pre-Beta is leaked.
how hard is it to get the source code from a compiled version? and if it is hard, WHY?
Depends on the programming language. If it's c/c++ (almost all games are written in c++) and it's a not a debug version - it's virtually impossible. It might be slightly easier for java/c#.
But there are also tools to obfuscate your compiled code and make it much more difficult to get anything readable or useful back.
Originally posted by: Descartes
Once compiled to "native" (which has a relative meaning) code there is absolutely no way to recover the original source code without insane amounts of metadata emitted in the binary itself (which is done in some cases). Compilers perform A LOT of optimizations that would seriously obfuscate the meaning of your code in its compiled-reverse-engineed form.
For those that understand how to reverse-engineer an application, it makes little sense to convert it to a higher-level language. Most cracks are done using interactive debuggers which display opcodes and the associated assembly instruction only, and the higher-level language like C or C++ are then used to exploit what's been discovered.
Originally posted by: NuclearFusi0n
Incredibly hard to get useful code unless you are a truely gifted programmer. You would have better things to do than hack on games though.
Originally posted by: JoLLyRoGer
Originally posted by: Descartes
Once compiled to "native" (which has a relative meaning) code there is absolutely no way to recover the original source code without insane amounts of metadata emitted in the binary itself (which is done in some cases). Compilers perform A LOT of optimizations that would seriously obfuscate the meaning of your code in its compiled-reverse-engineed form.
For those that understand how to reverse-engineer an application, it makes little sense to convert it to a higher-level language. Most cracks are done using interactive debuggers which display opcodes and the associated assembly instruction only, and the higher-level language like C or C++ are then used to exploit what's been discovered.
Right, but even reverse engineering the program in to assembaly code would allow you to re-compile it for a different OS or processor, provided you have a compiler on hand. (For example: Porting the program onto Linux using the source code and a linux native compiler.) Correct?
Semantics really. It's compiled into an intermediate language that is interpreted at runtime by either the JVM or the .net frameworkOriginally posted by: Descartes
Don't say interpretedThey're compiled, just to an intermediate language; IL for .NET, bytecode for Java.
Originally posted by: Shanti
Semantics really. It's compiled into an intermediate language that is interpreted at runtime by either the JVM or the .net frameworkOriginally posted by: Descartes
Don't say interpretedThey're compiled, just to an intermediate language; IL for .NET, bytecode for Java.
The point was that the distributed executable file is not native machine code but is an intermediate language that is easier to reverse engineer than native machine code.
Originally posted by: Descartes
Originally posted by: JoLLyRoGer
Originally posted by: Descartes
Once compiled to "native" (which has a relative meaning) code there is absolutely no way to recover the original source code without insane amounts of metadata emitted in the binary itself (which is done in some cases). Compilers perform A LOT of optimizations that would seriously obfuscate the meaning of your code in its compiled-reverse-engineed form.
For those that understand how to reverse-engineer an application, it makes little sense to convert it to a higher-level language. Most cracks are done using interactive debuggers which display opcodes and the associated assembly instruction only, and the higher-level language like C or C++ are then used to exploit what's been discovered.
Right, but even reverse engineering the program in to assembaly code would allow you to re-compile it for a different OS or processor, provided you have a compiler on hand. (For example: Porting the program onto Linux using the source code and a linux native compiler.) Correct?
Negative. There's a large variance of the instruction set CPUs support, especially when you consider bit-boundaries (32-bit, 64-bit like the Itanium, etc.). Different assemblers (nasm, masm, ...) support different instructions as well (e.g. masm has support for instructions that make procedure calls easier), and what works in one assembler might not work in another depending on what you used to reverse-engineer the application in the first place.
