yaxpeax

a few things i talk about and hack on refer to The Yaxpeax Project. or, just “yaxpeax”. yaxpeax-arch talks about “shared traits … from the yaxpeax project”. it’s worth saying explicitly what the thing is or isn’t.

my thesis is that most programs are not inherently more difficult to work with (e.g. read, write, modify) as machine code than as source code it was compiled from. where machine code seems dense, this is a consequence of decades of neglect and missing tooling. aspirationally, “yaxpeax” is what i think could support high-quality tooling for that category of problem.

realistically, “yaxpeax” is a pile of disassemblers and their partial integration into a library for control-flow and data-flow analysis.

even this, it seems, is enough to have a twinkle of promise!!

… though that’s the best and only example of code analysis being as useful as i’d hope, so far. this is why “yaxpeax” as a project is fuzzy, and i primarily talk about it as a pile of disassemblers; those are neatly-scoped with a simple enough interface, and are reusable.

and in some uses of my own - of course i find nails for my hammer:

but the real place i hope to find yaxpeax one day is to be used for analysis tasks like

register numbering 

constructing an SSA-style representation of machine code, in turn letting me (or you!!!) get value anlyses,

range inference 

anyway, between Then and Now.. Ghidra has become an entire thing. Binary Ninja still exists and continues improving. maybe yaxpeax ends up just a pile of neat disassemblers and toys demos in my (ha ha) spare time.