FYI you most definitely can beat LLVM in terms of quality. Its diassembler was designed originally only to support the instructions that the compiler could generate. While they've since filled out most of the instruction set, there are still a whole set of subtleties it can't deal with well, simply because the compiler part of it was never designed to output them. (e.g. see segment prefixes)

It depends on what you are looking to achieve.

If you take a look to e.g. McSema https://github.com/trailofbits/mcsema, these guys have been able to use LLVM to transform assembly back to LLVM intermediate representation (IR). The IR is an abstract language used by LLVM during compilation to optimize the generated code. Being abstract basically allows to use optimizers across all LLVM supported architectures.

In these terms, I think LLVM has a clear advantage over competitors.

The following blog post give a nice overview of the McSema achievements: http://blog.trailofbits.com/2014/06/23/a-preview-of-mcsema/

hi, I'm one of the mcsema authors and the original author who was responsible for mcsema using the LLVM instruction decoder and it was a mistake. if I had a choice between going back in time and assassinating Hitler, or convincing myself to use XED instead of mcinst...

Hi Munin,

What you did with McSema was really impressive and I’m glad discussing with one of the authors! I get the point you regret using LLVM, it seemed to me to be the best choice since LLVM has wide instruction semantics implementations, that more basic tools such as Xed do not offer. If I get it correctly… you would rather re-implement such semantic yourself? Or have you got any other tool / idea I’m not aware of?

I don't regret using LLVM at all. I regret using the instruction decoding features in LLVM. if I could do it again (and someone younger, smarter, and better looking than me is) I would combine the LLVM IR with the XED instruction decoder. we would still emit the semantics of the instructions as LLVM, but we would use XED to figure out which instruction we were decoding.

Medusa: https://github.com/wisk/medusa

x64dbg: http://x64dbg.com/

Bindead: https://bitbucket.org/mihaila/bindead/overview

There's also Binary Ninja. Still in beta, but available to anyone who requests to join the beta before it's public release: https://binary.ninja

The only mention of "beta" that I can find on the site is: http://binary.ninja/eula.txt

Where is the request form?

Email, slack, or the "Questions or Comments?" popup are all acceptable

A bit late to show, and surely offtopic, but as alternative links were already posted, here's another one: ScratchABit https://github.com/pfalcon/ScratchABit . Features: written in well-known interpreted language (Python), hacking on ScratchABit is actually easy. Implements subset of IDAPython API, so existing community modules for various processors support, etc. can be reused.

binaryninja: https://binary.ninja/

Another alternative disassembler to Hopper/IDA is Relyze: https://www.relyze.com/

Been using it for a while and like it allot, has a great interface for reversing and diffing win binaries. Will be keeping an eye on Panopticon, looks promising :)