x86 Disassembly
en.wikibooks.org
x86 Disassembly
1–10 of 29 posts
Re: x86 Disassembly
#2Write a disassembler at least once. It's much easier than you think it is (even with X86) --- it's essentially a file format parser --- and very illuminating.
Re: x86 Disassembly
#3Write a disassembler at least once. It's much easier than you think it is (even with X86) --- it's essentially a file format parser --- and very illuminating.
As someone looking more into x86_64 assembly, instruction encoding, syscalls and ELF files recently, not only the lack of good starting points but also the amount of work required to get into it is a pity.
I'm currently using [0] as a helping hand among other resources which is quite good; my maybe not-so-interesting results are at [1].
For example, to get a good overview of instruction encoding you have to 0/ read through and ditch horrible blog posts 1/ find the correct Intel manual 2/ search and read through thousands of PDF pages until you find something interesting 3/ understand the environment and facts that are either implicitly given or in the documents but not easy to find.
For the handful lines of actual code I wrote yesterday [1] I still have around 25 tabs open. Complexity and no end in sight.
Do you have any recommendations and hints as where to start with this in the year 2015?
[0] http://0xax.blogspot.se/p/assembly-x8664-programming-for-lin...
Re: x86 Disassembly
#4Write a disassembler at least once. It's much easier than you think it is (even with X86) --- it's essentially a file format parser --- and very illuminating.
And then you realize you could actually take it a step further and before you know it you are hunting for documentation on the amount of cycles each intruction and data access takes and other obscure clocking info, nevermind there are a thousand and one emulators already in existence that are several orders of magnitude better than the half assed attempt you are trying to come up with. Fun times :)
Re: x86 Disassembly
#5Write a disassembler at least once. It's much easier than you think it is (even with X86) --- it's essentially a file format parser --- and very illuminating.
And then you realize you could actually take it a step further and before you know it you are hunting for documentation on the amount of cycles each intruction and data access takes and other obscure clocking info, nevermind there are a thousand and one emulators already in existence that are several orders of magnitude better than the half assed attempt you are trying to come up with. Fun times :)
Cycle accurate emulation of modern x86 would be impossible. Intel simply won't release the secret sauce on branch prediction, cache prediction, out of order execution, internal instruction engine, etc.
Re: x86 Disassembly
#6This book is missing very actively developed reverse engineering framework radare2 [1], which is supporting not only x86/x86_64 but also arm, mips, ppc, avr, arc, 8051, TI tms320c55x family and even more!
[1] http://rada.re/
Re: x86 Disassembly
#7Write a disassembler at least once. It's much easier than you think it is (even with X86) --- it's essentially a file format parser --- and very illuminating.
As someone looking more into x86_64 assembly, instruction encoding, syscalls and ELF files recently, not only the lack of good starting points but also the amount of work required to get into it is a pity. I'm currently using [0] as a helping hand among other resources which is quite good; my maybe not-so-interesting results are at [1]. For example, to get a good overview of instruction encoding you have to 0/ read t…
Seconding this. I've implemented a part of x86 instruction encoding and you either find resources:
* comprehensible, but far from complete (some blogs)
* complete, but hard to understand and requiring some implicit knowledge (Intel manual or [1])
Rather than disassembler I recommend writing some simple JIT compiler, with [2] as a starting point. You skip some problems this way.
[1] http://ref.x86asm.net/ this seems pretty cool as a reference, but I can't wrap my head around it
[2] http://eli.thegreenplace.net/2013/11/05/how-to-jit-an-introd...
Re: x86 Disassembly
#8Write a disassembler at least once. It's much easier than you think it is (even with X86) --- it's essentially a file format parser --- and very illuminating.
And then you realize you could actually take it a step further and before you know it you are hunting for documentation on the amount of cycles each intruction and data access takes and other obscure clocking info, nevermind there are a thousand and one emulators already in existence that are several orders of magnitude better than the half assed attempt you are trying to come up with. Fun times :)
That's such a huge problem with exploratory programming: the demotivating effect of knowing that there are better versions of almost anything you're building, because other people have been working on the problem for longer.
You have to get over it and keep going anyways or you'll never become one of those people yourself! (Or even be able to make an informed decision about whether you want to).
Not coincidentally: part of the point of the company we just started. :)
Re: x86 Disassembly
#9Write a disassembler at least once. It's much easier than you think it is (even with X86) --- it's essentially a file format parser --- and very illuminating.
I'm currently writing one in JavaScript of all languages, just to prove it works. also, it's true multi-platform ;)
Re: x86 Disassembly
#10Earlier quoted context omitted.
And then you realize you could actually take it a step further and before you know it you are hunting for documentation on the amount of cycles each intruction and data access takes and other obscure clocking info, nevermind there are a thousand and one emulators already in existence that are several orders of magnitude better than the half assed attempt you are trying to come up with. Fun times :)
Cycle accurate emulation of modern x86 would be impossible. Intel simply won't release the secret sauce on branch prediction, cache prediction, out of order execution, internal instruction engine, etc.
On the other hand, the absence of such information means that games don't depend on it.