Reconstructing Assembly Truth Map

So I recently read [1] which evaluates several disassemblers. The truth/test binaries are generated by the SPEC CPU 2006 Benchmark suite. The authors provide detailed build instructions for the ELF set inside a VirtualBox. However, reconstructing the Windows binaries seems impossible for me, as the authors didn’t provide the SPEC configuration files for building those binaries. So building the binaries with VisualStudio2015, which actually match with the provide mapping files [2] didn’t work (bruteforcing/guessing the compilation settings).

For example most of the samples “SPEC/vs15-32/C++” and “SPEC/vs15-32/C” have the following prologue of the .text base (see appendix for properties description):

[2]
@0x0000000000401000:  [FBIC]
@0x0000000000401001:  [IC]C
@0x0000000000401003:  [IC]CC
@0x0000000000401006:  [IC]
@0x0000000000401007:  [IC]
@0x0000000000401008:  [IC]CC
@0x000000000040100b:  [IC]C
@0x000000000040100d:  [JIC]C

All of the 64 bit samples have following prologue:

<Segment .text, vaddr 0x0000000000001000, size 1600112, flag [RX]>
@0x0000000140001000:  [FBIC]CCCC
@0x0000000140001005:  [IC]CCCC
@0x000000014000100a:  [IC]
@0x000000014000100b:  [IC]CCC
@0x000000014000100f:  [IC]CC
@0x0000000140001012:  [IC]CC
@0x0000000140001015:  [IC]CC
@0x0000000140001018:  [JIC]C

I tried several configurations for the SPEC build instructions with VS2015 Compiler and intel compiler. However, inspecting all of the resulting binaries don’t match with the provided ground truth of [1].

So two concrete questions:

1. When all samples share similar .text prologues, they all share
   similar libraries?

2. Could somone infer the compilation details by the repeating
   prologues?

---

Properties descriptions:

  d - data
  c - code
  i - instruction boundary
    Note that if a byte is an instruction boundary (start of an instruction),
    this implies that it is a code byte
  o - instruction boundary (start of overlapping instruction)
  b - basic block start
    Basic block boundaries are not always explicitly listed, as they can usually
    be found by parsing the instruction/function listing into a control-flow graph
  f - function start
  e - program/binary entry point
  r - function end (return, tail call, etc.)
  j - control-flow instruction (jmp, call, ret, ...)
  x - crossref/call instruction
  n - NOP or other function padding

[1] An In-Depth Analysis of Disassembly on Full-Scale x86/x64 Binaries

Dennis Andriesse

Zeus is a family of credential-stealing trojans which originally
appeared in 2007. The first two variants of Zeus are based on
centralized command servers. These command servers are now routinely
tracked and blocked by the security community. In an apparent effort
to withstand these routine countermeasures, the second version of Zeus
was forked into a peer-to-peer variant in September 2011. Compared to
earlier versions of Zeus, this peer-to-peer variant is fundamentally
more difficult to disable. Through a detailed analysis of this new
Zeus variant, we demonstrate the high resilience of state of the art
peer-to-peer botnets in general, and of peer-to-peer Zeus in
particular.