Hey,

Trace recording plus the translation of the trace into a format which the libtriton understands?

Yes.

Or will triton Be able to do the arm translation?

Nop.

In fact, the new design allow us to plug any arch. Currently, we will release only the x86 semantics but you can easily add ARM semantics if you want.

The new design looks like this:

$ tree src
src
├── api
│   └── api.cpp
├── arch
│   ├── architecture.cpp
│   ├── bitsVector.cpp
│   ├── immediateOperand.cpp
│   ├── instruction.cpp
│   ├── memoryOperand.cpp
│   ├── operandWrapper.cpp
│   ├── registerOperand.cpp
│   └── x86
│       ├── x8664Cpu.cpp
│       ├── x86Cpu.cpp
│       ├── x86Semantics.cpp
│       └── x86Specifications.cpp
├── bindings
│   └── python
│       ├── init.cpp
│       ├── modules
│       │   ├── smt2libCallbacks.cpp
│       │   └── tritonCallbacks.cpp
│       ├── namespaces
│       │   ├── initArchNamespace.cpp
│       │   ├── initCpuSizeNamespace.cpp
│       │   ├── initOperandNamespace.cpp
│       │   ├── initRegNamespace.cpp
│       │   ├── initSmtAstNodeNamespace.cpp
│       │   └── initX86OpcodesNamespace.cpp
│       ├── objects
│       │   ├── PyBitvector.cpp
│       │   ├── PyImmediate.cpp
│       │   ├── PyInstruction.cpp
│       │   ├── PyMemory.cpp
│       │   ├── PyRegister.cpp
│       │   └── PySmtAstNode.cpp
│       ├── pyXFunctions.cpp
│       └── utils.cpp
├── ctx
│   └── context.cpp
├── engines
│   ├── symbolic
│   │   ├── symbolicEngine.cpp
│   │   ├── symbolicExpression.cpp
│   │   └── symbolicVariable.cpp
│   └── taint
│       └── taintEngine.cpp
├── includes
│   ├── *.hpp
├── os
│   └── unix
│       ├── syscallNumberToString.cpp
│       └── syscalls.cpp
└── smt2lib
    └── smt2lib.cpp

As you can see, there is a x86 repository which contains all information about the arch's spec. The file x86Semantics.cpp contains x86 semantics based on the SMT2-Lib format. Example with the XOR instruction:

namespace triton {
  namespace arch {
    namespace x86 {
      namespace semantics {

        [...]

        void xor_s(triton::arch::Instruction& inst) {
          auto dst = inst.operands[0];
          auto src = inst.operands[1];
          auto op1 = api.buildSymbolicOperand(dst);
          auto op2 = api.buildSymbolicOperand(src);

          auto node = smt2lib::bvxor(op1, op2);

          auto expr = api.createSymbolicExpression(inst, node, dst);

          api.taintUnion(expr, dst, src);

          clearFlag(inst, ID_TMP_CF, "Clears carry flag");
          clearFlag(inst, ID_TMP_OF, "Clears overflow flag");
          pf(inst, expr, dst);
          sf(inst, expr, dst);
          zf(inst, expr, dst);
        }

        [...]

      }; /* semantics namespace */
    }; /* x86 namespace */
  }; /* arch namespace */
}; /* triton namespace */

If you want to add the ARM semantics, you have to keep the same structure as x86 (when the v0.3 will be released, I will write a blog post about that).

Then, as you said, with the new design, you can plug any tracer to extract semantics (online, offline or whatever).

An offline example:

import  sys
from    triton import *


trace = [
    (0x400000, "\x48\x8b\x05\xb8\x13\x00\x00"), # mov        rax, QWORD PTR [rip+0x13b8]
    (0x400007, "\x48\x8d\x34\xc3"),             # lea        rsi, [rbx+rax*8]
    (0x40000b, "\x67\x48\x8D\x74\xC3\x0A"),     # lea        rsi, [ebx+eax*8+0xa]
    (0x400011, "\x66\x0F\xD7\xD1"),             # pmovmskb   edx, xmm1
    (0x400015, "\x89\xd0"),                     # mov        eax, edx
    (0x400017, "\x80\xf4\x99"),                 # xor        ah, 0x99
]


if __name__ == '__main__':

    #Set the arch
    setArchitecture(ARCH.X86_64)

    for (addr, opcodes) in trace:
        # Build an instruction
        inst = Instruction()

        # Setup opcodes
        inst.setOpcodes(opcodes)

        # Setup Address
        inst.setAddress(addr)

        # optional - Update the register state at each program point
        inst.updateContext(Register(REG.RAX, 0x4444444455555555));
        inst.updateContext(Register(REG.RBX, 0x1111111122222222));

        # optional - Add memory access <addr, size, content> at each program point
        inst.updateContext(Memory(0x66666666, 4, 0x31323334));

        # Process everything. Builds IR and updates engines.
        processing(inst)

    sys.exit(0)

As you can imagine, the new design allows you to use any tracer like:

Pin / DynamoRIO
Unicore / Qemu / Bochs
IDA's debugger(s)
A database, a file or whatever...

I do my best to release the v0.3 as soon as possible. I hope it will be available in January 2016.

Cheers,

Extract engines into external libs #226

Description

Metadata

Metadata

Assignees

Labels

Projects

Milestone

Relationships

Development

Issue actions