Few questions about reverse engineering?
- Thread starter Ice Rich
- Start date
Soldato
Yes. At it's most root level all compiled code can be turned into assembler. Being able to do something useful with that is another matter. There are programs that offer to turn a compiled assembly of X language back into X language source, but the results I've seen of those vary from crap that looks nothing like the original to completely unusable rubbish that won't even re-compile.
Do you mean from a compiled assembly? If so, probably yes. Nothing I know of off-hand though.
Many thanks, i'm just thinking back to the days when I had a 'Action Replay' plugged into my N64. You then had a visual representation of the code - I presume in binary form? You could then use 'hex' to replace the last 2 digits to assign a different value (for example the colour of a car).
I did not fully understand it then and my memory is more hazy now. What is the actual purpose of hex? Is it to change binary values without 'messing up' the code structure (i.e so it is still usable).
I see. But what stops a competitor from using a piece of code which someone else created and changing it very slightly?
Soldato
What stops this is in the first answer I gave - the fact that code decompilers are generally crap. If a developer is any good, he'll have a good idea of how most things are achieved.
Hex, or hexadecimal, is simply a base-16 numerical system, there's nothing specifically about it which will change code.
Associate
- Joined
- 4 Dec 2009
- Posts
- 519
Your action replay didnt give you a view of the source code. What it did give you was a view of the in memory variables and register values. This is why it could be used to give you extra lives for example as it just a case of altering a variable. Much in the same way peek and poke were used on the old school spectrums. The action replay "poshed" this up by "knowing" what game was been used so could customize the view for you the user making the numbers on screen make more sense.
You can still do this with modern executables running on windows its how most of the Trainers you get as a "Yarr me heartys" work.
In answer to your question. Yes you can reverse engineer some code. I for example have used this to great effect with java.
Anybody delivering "production" level applications though will most likely of used an obsfucator. This parses the entire code tree and renames all the variables, methods and functions so that its extremely hard to understand and all but impossible to follow logic and functionality.
You can still do this with modern executables running on windows its how most of the Trainers you get as a "Yarr me heartys" work.
In answer to your question. Yes you can reverse engineer some code. I for example have used this to great effect with java.
Anybody delivering "production" level applications though will most likely of used an obsfucator. This parses the entire code tree and renames all the variables, methods and functions so that its extremely hard to understand and all but impossible to follow logic and functionality.
Ahh I see, thanks.
The codes used to be broken in 2 parts, e.g.:
D01C8675 0020
So I presume the first part was the actual memory location and if it was called, the next four digits were used to set the value?
What language do you think the original programmer would have used, would it of had to of been hex? Or is the Action Replay converting the original code into this more readable form? (I presume hex is easier to work with the binary?)
Right that makes sense. So when the code is finished instead of just doing a normal compile, they use this obsfucator and it jumbles the code up so no one can easily de-compile into its original form?
But I presume the the original coder would have the right 'settings' to decompile to the state it was in exactly?
Hex is used to display the values because a) it's easier on the eyes than binary, and b) it fits the data more succinctly than other number systems (an 8-bit byte has a range that fits perfectly into a pair of hex digits; 00 to FF, rather than 0 to 255 in decimal).
So it's a coincidence really of 2^8 (a byte) == 16^2 (pair of hex digits), nothing more.
What programmers use to create programs range from:
- high level languages that are close to human-readable and require significant optimization and compiling to be turned into machine code (a binary splodge of instructions and data)
- low level languages like assembly which are as close to being machine code (and therefore usually more specific to the hardware/cpu its running on) but where the instructions are not binary values but short abbreviated words, like jmp, mov, etc. High level anguages that are NOT interpreted (C/C++ for example) can get decompiled back to this level. Those that are interpreted (a .Net language or Java) can be decompiled either back to 'source' or an 'intermediate' language that is higher level than this.
- machine code; the final raw code that can be executed by a computer. Not practical for coding/editing with in a computing environment at all, but very practical for the computer itself. Instead of the instruction text 'jmp' you may just have '8', instead of 'mov' you may just have '12', etc.
Even the original coder who applies obfuscation before the code is compiled would not be able to get it back to the original source code form through decompiling (because if he could, anybody could), but only by retaining a copy of the original source code. It's still a program mind you, and works as it was written, it just looks fugly and you lose the context that is given by the original names of things.
There is pretty much nothing, short of putting your code inside a chip that will self-destruct when tampered with, that can prevent it from being decompiled from machine code to at least assembly, and this can be readable enough for avid hackers and reverse engineers to debug and modify (many viruses and trojans understand this in order for them to piggy-back onto applications and spread, therefore their writers will understand assembler and read/write it too). Whether it's worth the effort or not depends on what's at stake.
So it's a coincidence really of 2^8 (a byte) == 16^2 (pair of hex digits), nothing more.
What programmers use to create programs range from:
- high level languages that are close to human-readable and require significant optimization and compiling to be turned into machine code (a binary splodge of instructions and data)
- low level languages like assembly which are as close to being machine code (and therefore usually more specific to the hardware/cpu its running on) but where the instructions are not binary values but short abbreviated words, like jmp, mov, etc. High level anguages that are NOT interpreted (C/C++ for example) can get decompiled back to this level. Those that are interpreted (a .Net language or Java) can be decompiled either back to 'source' or an 'intermediate' language that is higher level than this.
- machine code; the final raw code that can be executed by a computer. Not practical for coding/editing with in a computing environment at all, but very practical for the computer itself. Instead of the instruction text 'jmp' you may just have '8', instead of 'mov' you may just have '12', etc.
Even the original coder who applies obfuscation before the code is compiled would not be able to get it back to the original source code form through decompiling (because if he could, anybody could), but only by retaining a copy of the original source code. It's still a program mind you, and works as it was written, it just looks fugly and you lose the context that is given by the original names of things.
There is pretty much nothing, short of putting your code inside a chip that will self-destruct when tampered with, that can prevent it from being decompiled from machine code to at least assembly, and this can be readable enough for avid hackers and reverse engineers to debug and modify (many viruses and trojans understand this in order for them to piggy-back onto applications and spread, therefore their writers will understand assembler and read/write it too). Whether it's worth the effort or not depends on what's at stake.
Last edited: