Destroying x86_64 instruction decoders with differential fuzzing
blog.trailofbits.com
Destroying x86_64 instruction decoders with differential fuzzing
1–10 of 113 posts
Re: Destroying x86_64 instruction decoders with differential fuzzing
#2From the great article:
"x86_64 is the 64-bit extension of a 32-bit extension of a 40-year-old 16-bit ISA designed to be source-compatible with a 50-year-old 8-bit ISA. In short, it’s a mess, with each generation adding and removing functionality, ..."
Nice way of wording that! :)
It also explains the complexity of the following 10 pages of text.
Re: Destroying x86_64 instruction decoders with differential fuzzing
#3“For reverse engineers and program analysts: x86_64 instruction decoding is hard.”
An idea that hit me while reading this: Using a tool like this should (help to) make it easy to determine if a commercial app is using GPL libraries illicitly by assembling a syntax tree of method signatures as a first line indicator that the executable contains code matching a GPL library. If first pass indicates a match a deeper analysis of operation codes could reveal “similarities too consistent to be coincidence.”
Or an I describing something that had been in use since 2001?
Re: Destroying x86_64 instruction decoders with differential fuzzing
#4Great project and write-up. I'm reminded of a couple other projects.
MC Hammer project for LLVM tests round-trip properties of the ARM assembler. http://llvm.org/devmtg/2012-04-12/Slides/Richard_Barton.pdf
Sandsifter x86 fuzzer. https://github.com/xoreaxeaxeax/sandsifter https://youtu.be/KrksBdWcZgQ
Re: Destroying x86_64 instruction decoders with differential fuzzing
#5From the great article: "x86_64 is the 64-bit extension of a 32-bit extension of a 40-year-old 16-bit ISA designed to be source-compatible with a 50-year-old 8-bit ISA. In short, it’s a mess, with each generation adding and removing functionality, ..." Nice way of wording that! :) It also explains the complexity of the following 10 pages of text.
Every time Intel has tried to more away from x86 (i960? Itanium? Maybe others...) they end up coming back. The years of backwards compatibility are a big selling point.
Re: Destroying x86_64 instruction decoders with differential fuzzing
#6From the great article: "x86_64 is the 64-bit extension of a 32-bit extension of a 40-year-old 16-bit ISA designed to be source-compatible with a 50-year-old 8-bit ISA. In short, it’s a mess, with each generation adding and removing functionality, ..." Nice way of wording that! :) It also explains the complexity of the following 10 pages of text.
See also this old Microsoft Windows 95-era joke:
“32 bit extensions and a graphical shell for a 16 bit patch to an 8 bit operating system originally coded for a 4 bit microprocessor, written by a 2 bit company, that can't stand 1 bit of competition.”
Re: Destroying x86_64 instruction decoders with differential fuzzing
#7Great project and write-up. I'm reminded of a couple other projects. MC Hammer project for LLVM tests round-trip properties of the ARM assembler. http://llvm.org/devmtg/2012-04-12/Slides/Richard_Barton.pdf Sandsifter x86 fuzzer. https://github.com/xoreaxeaxeax/sandsifter https://youtu.be/KrksBdWcZgQ
(Author here.)
Yep! Both sandsifter and MC Hammer provided inspiration for mishegos.
Re: Destroying x86_64 instruction decoders with differential fuzzing
#8From the great article: "x86_64 is the 64-bit extension of a 32-bit extension of a 40-year-old 16-bit ISA designed to be source-compatible with a 50-year-old 8-bit ISA. In short, it’s a mess, with each generation adding and removing functionality, ..." Nice way of wording that! :) It also explains the complexity of the following 10 pages of text.
Every time Intel has tried to more away from x86 (i960? Itanium? Maybe others...) they end up coming back. The years of backwards compatibility are a big selling point.
There is value in the fact that the instruction set is an abstraction. CPU's built with more low-level instruction sets became obsolete faster because they couldn't adapt to new features and maintain compatibility as easily.
Re: Destroying x86_64 instruction decoders with differential fuzzing
#9“For reverse engineers and program analysts: x86_64 instruction decoding is hard.” An idea that hit me while reading this: Using a tool like this should (help to) make it easy to determine if a commercial app is using GPL libraries illicitly by assembling a syntax tree of method signatures as a first line indicator that the executable contains code matching a GPL library. If first pass indicates a match a deeper anal…
For simple code match, you can just compared bytes without decoding instructions. If you want to try and identify functionally similar but not more or less identical code from binaries, good luck; it's a very hard problem. Antivirus companies and reverse engineers would love to know how to do that efficiently.
Re: Destroying x86_64 instruction decoders with differential fuzzing
#10Reading even a bit about x86_64's complexity makes me see why Apple would want to move Macs to ARM (among other reasons.)