gdabah/distorm

Powerful Disassembler Library For x86/AMD64

Powerful Disassembler Library For x86/AMD64

Welcome to the diStorm3 binary stream disassembler library project.

diStorm3 is really a decomposer, which means it takes an instruction and returns a binary structure which describes it rather than static text, which is great for advanced binary code analysis.

diStorm3 is super lightweight (~45KB), ultra fast and easy to use (a single API), licensed under BSD!

For a light hooking library see the https://github.com/gdabah/distormx project.

"We benchmarked five popular open-source disassembly libraries and chose diStorm3, which had the best performance (and furthermore, has complete 64-bit support).", July 2014, Quoting David Williams-King in his Thesis about Binary Shuffling.

Installing diStorm3 - 'python -m pip install distorm3'

RTFM, the wiki has plenty of info.

distorm's Issues

The _LIB preprocessor macro is not unique, preventing inclusion of distorm in another library

What steps will reproduce the problem?
1. Create a new library, try to use distorm from inside that library.

What is the expected output? What do you see instead?
Since the new library project also #defines _LIB in the project settings,
the distorm exports are preprocessed out of the header file.

Usually this is solved by giving the _LIB macro a unique name, for example
_LIB_DISTORM3 to prevent collisions.

What version of the product are you using? On what operating system?
r48, msvc2008.

Original issue reported on code.google.com by [email protected] on 12 May 2010 at 10:58

incorrect 64-bit decode of 0x488b3d534c5f

What steps will reproduce the problem?

run the following python code

from distorm3 import Decode, Decode64Bits
for op in  Decode(0x400000, '488b3d534c5f'.decode('hex'), Decode64Bits):
    print op[2]


What is the expected output? What do you see instead?

It prints:
DB 0x48
DB 0x8b
DB 0x3d
PUSH RBX
POP RDI

However other disassemblers print:
MOV RDI, QWORD PTR [0x5F4C74]


What version of the product are you using? On what operating system?
distrom3-1.0 python installer

Original issue reported on code.google.com by [email protected] on 5 Nov 2010 at 7:45

Unable to disassemble valid VXORPS instruction.

What steps will reproduce the problem?
1. Try to disassemble a VEX-encoded AVX VXORPS instruction using
'distorm_decompose'. Currently, I'm seeing it fail on the following instruction:

C5 FC 57 C0      vxorps      ymm0,ymm0,ymm0

What is the expected output? What do you see instead?
I'd expect it to return DECRES_SUCCESS, and set usedInstructionCount to 1. 
Instead, I see DECRES_MEMORYERR. I attempted to follow the decoding, and it 
recognizes that its a VEX encoded instruction, but appears to derail in 
inst_get_info.

What version of the product are you using? On what operating system?
Using trunk r193 on Windows 7.

In the code I'm looking at, there's a sequence of these instructions:

C5 FC 57 C0      vxorps      ymm0,ymm0,ymm0 
C5 F4 57 C9      vxorps      ymm1,ymm1,ymm1 
C5 EC 57 D2      vxorps      ymm2,ymm2,ymm2 
C5 E4 57 DB      vxorps      ymm3,ymm3,ymm3 
C5 DC 57 E4      vxorps      ymm4,ymm4,ymm4 
C5 D4 57 ED      vxorps      ymm5,ymm5,ymm5 
C5 CC 57 F6      vxorps      ymm6,ymm6,ymm6 
C5 C4 57 FF      vxorps      ymm7,ymm7,ymm7 

The Visual Studio 2008 decoder has no problem with them.

Original issue reported on code.google.com by [email protected] on 26 Sep 2011 at 9:32

the output disassembling INS/OUTS is confusing

What steps will reproduce the problem?
1.  disassemble the following code with latest disasm-32.exe choosing 32-bit 
mode
a5 f3 a5 f3 ab f3 aa 66 ab f3 6e f3 66 6f f3 6c 6e 6c
and get the following output:
00000000 (01) a5                       MOVSD
00000001 (02) f3a5                     REP MOVSD
00000003 (02) f3ab                     REP STOSD
00000005 (02) f3aa                     REP STOSB
00000007 (02) 66ab                     STOSW
00000009 (02) f36e                     REP OUTS DX, [ESI]
0000000b (03) f3666f                   REP OUTS DX, [ESI]
0000000e (02) f36c                     REP INS [ES:EDI], DX
00000010 (01) 6e                       OUTS DX, [ESI]
00000011 (01) 6c                       INS [ES:EDI], DX

What is the expected output? What do you see instead?
1. a consistent output format for INS/OUTS and MOVS/STOS.
INS/OUTS follows the format of OUTS XX, XXX, while MOVS/STOS follow the format 
of MOVSB/MOVSW/MOVSD.

2. For OUTS/ins, I want to get the operand size information like the following 
result,
6E              OUTS DX,BYTE PTR DS:[ESI] 

Since the following two instructions share the same mnemonics and operands, the 
result is confusing to judge the operand size.
00000009 (02) f36e                     REP OUTS DX, [ESI]
0000000b (03) f3666f                   REP OUTS DX, [ESI]

Maybe I'm asking a silly question, but can anyone make it clear?

What version of the product are you using? On what operating system?
distorm3-1.0
on Windows 7 enterprise (32-bit)

Please provide any additional information below.

Original issue reported on code.google.com by [email protected] on 6 Sep 2011 at 1:02

Used-Registers-Mask

Add registers mask support, for quick look up of registers used in an 
instruction.

Original issue reported on code.google.com by [email protected] on 13 Sep 2010 at 10:18

Build fils when compiling with MinGW

What steps will reproduce the problem?
1. Compile distorm using MinGW:

C:\Users\tantalum\Documents\Research\distorm>python setup.py build 
--compiler=mingw32

2. Watch the build fail because the wrong arguments are passed to gcc:
running custom_build
running build_py
creating build
creating build\lib
creating build\lib\distorm3
copying python\distorm3\sample.py -> build\lib\distorm3
copying python\distorm3\__init__.py -> build\lib\distorm3
running build_clib
running custom_build_clib
building 'distorm3' library
creating build\temp.win-amd64-2.7
creating build\temp.win-amd64-2.7\src
C:\strawberry\c\bin\gcc.exe -mno-cygwin -mdll -O -Wall -Isrc -Iinclude -c 
src\decoder.c -o build\temp.win-amd64-2.7\src\decoder.o /Ox /Ob1 /Oy ""/D 
WIN32"" ""/D _DLL"" ""/D LIBDISTORM"" ""/D SUPPORT_64BIT_OFFSET"" ""/D _MBCS"" 
/GF /Gm /Zi /EHsc /MT /Gy /W4 /nologo /c /TC /Fdbuild\vc90.pdb
gcc: /Ox: No such file or directory
gcc: /Ob1: No such file or directory
gcc: /Oy: No such file or directory
gcc: /D: No such file or directory
gcc: WIN32: No such file or directory
gcc: /D: No such file or directory
gcc: _DLL: No such file or directory
gcc: /D: No such file or directory
gcc: LIBDISTORM: No such file or directory
gcc: /D: No such file or directory
gcc: SUPPORT_64BIT_OFFSET: No such file or directory
gcc: /D: No such file or directory
gcc: _MBCS: No such file or directory
gcc: /GF: No such file or directory
gcc: /Gm: No such file or directory
gcc: /Zi: No such file or directory
gcc: /EHsc: No such file or directory
gcc: /MT: No such file or directory
gcc: /Gy: No such file or directory
gcc: /W4: No such file or directory
gcc: /nologo: No such file or directory
gcc: /c: No such file or directory
gcc: /TC: No such file or directory
gcc: /Fdbuild\vc90.pdb: No such file or directory
error: command 'gcc' failed with exit status 1


What is the expected output? What do you see instead?
The expected outcome would be for the correct flags to be passed to gcc instead 
of just pretending that everything uses MSVC.

What version of the product are you using? On what operating system?
I'm using the svn HEAD version with Windows 7 on a 64-bit machine

So what's the core of the issue?
The problem lies in setup.py around line 180. The build selects the extra 
compiler flags depending on the operating system instead of the compiler being 
used. For windows the extra compiler flags are suitable for MSVC but cause gcc 
to fail.

    if 'windows' in system:
        libraries = [(
            'distorm3', dict(
            package='distorm3',
            sources=get_sources,
            include_dirs=['src', 'include'],
            extra_compile_args=['/Ox', '/Ob1', '/Oy', '"/D WIN32"',
                                '"/D _DLL"', '"/D LIBDISTORM"', '"/D SUPPORT_64BIT_OFFSET"',
                                '"/D _MBCS"', '/GF', '/Gm', '/Zi', '/EHsc',
                                '/MT', '/Gy', '/W4', '/nologo', '/c', '/TC',
                                '/Fdbuild\\vc90.pdb'],
            extra_link_args=['/MANIFEST']))]

Original issue reported on code.google.com by [email protected] on 6 Apr 2011 at 1:54

XSAVEOPT not decoded

What steps will reproduce the problem?

Disassemble these bytes in 64-bit mode:
0f ae 30

What is the expected output? What do you see instead?

Expect: XSAVEOPT [RAX]
Get:  
DB 0xf
SCASB
DB 0x30


What version of the product are you using? On what operating system?

diStorm 3.1, MacOS X 10.6.8

Please provide any additional information below.

I don't see a decode for XSAVEOPT in x86sets.py, so it should probably just be 
added there.

Original issue reported on code.google.com by [email protected] on 9 Feb 2012 at 6:46

vmovhps is shown as vmovlhps

What steps will reproduce the problem?

Disassemble in 64-bit mode: 0xc5 0xf0 0x16 0x01

What is the expected output? What do you see instead?

Expect: VMOVHPS XMM0, XMM1, QWORD [RCX]
Get:    VMOVLHPS XMM0, XMM1, QWORD [RCX]


What version of the product are you using? On what operating system?

diStorm 3.1 on MacOS X 10.6.8

Please provide any additional information below.

When the ModRM byte specifies a memory operand, this byte sequence has a 
different mnemonic than when register operands are specified. 

For example:
0xc5 0xf0 0x16 0xc0
is correctly output as:
VMOVLHPS XMM0, XMM1, XMM0

Original issue reported on code.google.com by [email protected] on 8 Feb 2012 at 10:53

64bits 32bits confusion

What steps will reproduce the problem?
1. print distorm3.Decode(0,'QW', distorm3.Decode32Bits) will print out
[(0L, 1L, 'PUSH ECX', '51'), (1L, 1L, 'PUSH EDI', '57')] but 
print(distorm3.Decompose(0,'QW', distorm3.Decode32Bits)[0]), 
print(distorm3.Decompose(0,'QW', distorm3.Decode32Bits)[1]) will print out 
PUSH RCX, PUSH RDI

What version of the product are you using? On what operating system?
i'm using the latest distorm on windows7 x64

Please provide any additional information below.

Original issue reported on code.google.com by [email protected] on 15 Oct 2010 at 12:50

mov (0x8e) should has [SREG, RFULL_M16] as its operand

I'm using diStorm's disOps python script to generate an instruction database, 
and try to write a disassembler (to learn x86 instruction set better).

Currently mov (0x8e) has [SREG, RM16] as its operand. Objdump uses 32bit 
register in its decoding output.
But for lldt (0x0f 0x00 /02), which has [RM16] as its operand, objdump uses 
16bit register.

Here's a comparison of objdump's output for mov (0x8e and 0x8c) and lldt:

8e e0:   mov  %eax,%fs
8c e8:   mov %gs,%eax
0f 00 d2:    lldt %dx

When consulting the Intel Manual (vol 2b, 2011 version), the mov (0x8e) opcode 
has the same note as 0x8c.
So I guess mov (0x8e) should also have RFULL_M16 as its 2nd operand, the same 
as the 1st operand of mov (0x8c).

Original issue reported on code.google.com by [email protected] on 15 Mar 2012 at 10:35

opcode == 83 on OSX but opcode == 462 on Windows?

I'm seeing some different results from distorm3.Decompose depending on the 
platform where it runs. Below is output from a Windows and OSX machine, both 
running the same revision of code (186) and both given the same input buffer. 
Note opcode == 83 on OSX but opcode == 462 on Windows. 

On my OSX machine, sys.maxint is 9223372036854775807. On Windows, sys.maxint is 
2147483647...not sure if that's part of the cause. 

C:\volatility20>python
Python 2.6.5 (r265:79096, Mar 19 2010, 21:48:26) [MSC v.1500 32 bit (Intel)] on 
win32
Type "help", "copyright", "credits" or "license" for more information.
>>> import distorm3
>>> for op in distorm3.Decompose(0, "\xe9\x91\xbf=\x8f", distorm3.Decode32Bits):
...     print op.__dict__
...
{'mnemonic': 'JMP', 'operands': [<distorm3.Operand object at 0x01850530>], 
'flowControl': 'FC_UNC_BRANCH', 'instructionClass': 'ISC_INTEGER', 'flags': [], 
'rawFlags': 1280, 'opcode': 462, 'address': 0L, 'unusedPrefixesMask': 0, 
'instructionBytes': '\xe9\x91\xbf=\x8f', 'dt': 1, 'segment': 255, 'valid': 
True, 'isSegmentDefault': False, 'size': 5}
>>> print distorm3.__revision__
$Id: distorm.py 186 2010-05-01 14:20:41Z gdabah $

$ python
Python 2.6.1 (r261:67515, Jun 24 2010, 21:47:49) 
[GCC 4.2.1 (Apple Inc. build 5646)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import distorm3
>>> for op in distorm3.Decompose(0, "\xe9\x91\xbf=\x8f", distorm3.Decode32Bits):
...     print op.__dict__
... 
{'mnemonic': 'JMP', 'operands': [<distorm3.Operand object at 0x1004e3c50>], 
'flowControl': 'FC_UNC_BRANCH', 'instructionClass': 'ISC_INTEGER', 'flags': [], 
'rawFlags': 1280, 'opcode': 83, 'address': 0L, 'instructionBytes': 
'\xe9\x91\xbf=\x8f', 'dt': 1, 'valid': True, 'size': 5}
>>> print distorm3.__revision__
$Id: distorm.py 186 2010-05-01 14:20:41Z gdabah $

Original issue reported on code.google.com by [email protected] on 15 Aug 2011 at 1:33

Wrong disassembly for cmp 0x20,%edi in 64-bit mode

In 64-bit mode, distorm says:
0000000000000000 (07) 3b3c2520000000           CMP EDI, [0x20]
and the second argument has type O_DISP. Should not it be O_IMM?

objdump says:
3b 3c 25 20 00 00 00    cmp    0x20,%edi

This does not seem right.

Original issue reported on code.google.com by [email protected] on 2 Nov 2010 at 1:18

distorm_decode : 1st Param Doesn't Work

In what mode did you try to disassemble (16/32/64)?
32

What is the input buffer (binary stream) you used to reproduce the problem?
Use hex.
unsigned char rawData[] =
{
    0xFF, 0x55, 0x8b, 0xec ,0x8b ,0x45 ,0x08 ,0x03 ,0x45 ,0x0c ,0xc9 ,0xc3
} ;

What is the expected output (or what instruction)?
0x00000000 (01) 55                       PUSH EBP
0x00000001 (02) 8bec                     MOV EBP, ESP
0x00000003 (03) 8b4508                   MOV EAX, [EBP+0x8]
0x00000006 (03) 03450c                   ADD EAX, [EBP+0xc]
0x00000009 (01) c9                       LEAVE
0x0000000A (01) c3                       RET

Which tool did you use to see the expected output?
VS 2010

What do you see instead?
0x00000001 (03) ff558b                   CALL DWORD [EBP-0x75]
0x00000004 (01) ec                       IN AL, DX
0x00000005 (03) 8b4508                   MOV EAX, [EBP+0x8]
0x00000008 (03) 03450c                   ADD EAX, [EBP+0xc]
0x0000000B (01) c9                       LEAVE

What version of diStorm are you using? On what platform (Python/EXE/other)?
Revision 204, VS 2010 SP1, EXE

Please provide any additional information below.
Test Code:

_DecodeResult res;
    _DecodedInst decodedInstructions[1000];
    unsigned int decodedInstructionsCount = 0, i = 0;
    _OffsetType offset = 0;
    unsigned int dver = distorm_version();
    printf("diStorm version: %d.%d.%d\n", (dver >> 16), ((dver) >> 8) & 0xff, dver & 0xff);

    unsigned char rawData[] =
{
    0xFF, 0x55, 0x8b, 0xec ,0x8b ,0x45 ,0x08 ,0x03 ,0x45 ,0x0c ,0xc9 ,0xc3
} ;
    res = distorm_decode(offset+1, (const unsigned char*)rawData, sizeof(rawData)-1, Decode32Bits, decodedInstructions, MAX_INSTRUCTIONS, &decodedInstructionsCount);
    for (int i = 0; i < decodedInstructionsCount; i++) {
#ifdef _AMD64_
        printf("%08I64x (%02d) %-24s %s%s%s\r\n", decodedInstructions[i].offset, decodedInstructions[i].size, (char*)decodedInstructions[i].instructionHex.p, (char*)decodedInstructions[i].mnemonic.p, decodedInstructions[i].operands.length != 0 ? " " : "", (char*)decodedInstructions[i].operands.p);
#else
        printf("0x%08X (%02d) %-24s %s%s%s\r\n", decodedInstructions[i].offset, decodedInstructions[i].size, (char*)decodedInstructions[i].instructionHex.p, (char*)decodedInstructions[i].mnemonic.p, decodedInstructions[i].operands.length != 0 ? " " : "", (char*)decodedInstructions[i].operands.p);
#endif
    }

Original issue reported on code.google.com by [email protected] on 8 Mar 2012 at 11:16

MOVD/MOVQ instruction not recognized

In what mode did you try to disassemble (16/32/64)?
64

What is the input buffer (binary stream) you used to reproduce the problem?
Use hex.
66490f7ed0

What is the expected output (or what instruction)?
MOVD/MOVQ

Which tool did you use to see the expected output?
Python console

What do you see instead?
>>> import distorm3
... i = distorm3.Decompose(0x0000000140c49a7e, "66490f7ed0".decode('hex'), 
distorm3.Decode64Bits)[0]
... print i
UNDEFINED R8, XMM2
>>> i.instructionClass
16: 'ISC_SSE2'
>>> i.mnemonic
17: 'UNDEFINED'
>>> i.valid
18: True

What version of diStorm are you using? On what platform (Python/EXE/other)?
distorm3.1.0, distorm-package 3.1
Python 2.7.2 (32 bits)
Windows 7 x64

Please provide any additional information below.

Original issue reported on code.google.com by [email protected] on 4 May 2012 at 11:28

• Merged into: #32

Add DDK support again

Add the sample project for DDK kernel disassembling once again.

Original issue reported on code.google.com by [email protected] on 16 May 2010 at 6:44

Incorrect instruction operands from DecomposeGenerator

When decomposing a 64-bit binary, the instruction:
mov    rax, 0xffffffffffffffff

seems to give a operand[1] of '0x-1', yet other immediate operands which would 
be negative if interpreted signed, show the correct outcome. I would expect all 
operands to be given independent of sign, ie. as raw hex, right?

For example, attached is a test case showing the problem. The test case uses a 
DecomposeGenerator to decompose:

mov   rax,0x7fffffffffffffff           
mov   rax,0xffffffffffffffff           
mov   rax,0x8000000000000000        

I then print what distorm thought the instruction was, and then the operands 
from the Instruction instance.

% python bug.py
MOV RAX, 0x7fffffffffffffff
  operands: 1: RAX      2: 0x7fffffffffffffff
MOV RAX, 0xffffffffffffffff
  operands: 1: RAX      2: -0x1
MOV RAX, 0x8000000000000000
  operands: 1: RAX      2: 0x8000000000000000

Operand 2 of the second instruction is incorrect(?).

I am using todays svn on OpenBSD-current with Python-2.7. Bug reproducible on 
i386 and amd64.

A patch to fix this would be appreciated.

Thanks

Original issue reported on code.google.com by [email protected] on 22 Jul 2012 at 12:50

Attachments:

• bug.py

diStorm3 now in openSUSE security repo

I've just added diStorm3 to the openSUSE security repo for testing.  

It will likely be forwarded soon to the openSUSE factory for inclusion in 
openSUSE 12.2 this summer.

I created a specfile which you can find here.  Feel free to include that in the 
source zip/tarball if you like.

Any comments / testing appreciated.

fyi: this is obviously not a bug report, but I didn't see a mailinglist or 
other feedback mechanism.

Original issue reported on code.google.com by [email protected] on 9 Feb 2012 at 7:44

instructionBytes is missing

Is there something wrong ?

>>> from distorm3 import *
>>> x = Decompose(0x400000, 'b800000000'.decode('hex'), Decode32Bits)
>>> x[0].instructionBytes
''

Original issue reported on code.google.com by [email protected] on 7 Sep 2010 at 1:16

Unable to disassemble valid CMPEQPD instruction

In what mode did you try to disassemble (16/32/64)?
64

What is the input buffer (binary stream) you used to reproduce the problem?
Use hex.
660fc2da01

What is the expected output (or what instruction)?
CMPEQPD?

Which tool did you use to see the expected output?
Python console

What do you see instead?
>>> import distorm3
... i = distorm3.Decompose(0x0000000140c49a7e, "660fc2da01".decode('hex'), 
distorm3.Decode64Bits)[0]
... print i
MPEQPD XMM3, XMM2
>>> i.instructionClass
31: 'ISC_SSE2'
>>> i.mnemonic
32: 'CMPLTDD'
>>> i.valid
33: True

What version of diStorm are you using? On what platform (Python/EXE/other)?
distorm3.1.0, distorm-package 3.1
Python 2.7.2 (32 bits)
Windows 7 x64

Please provide any additional information below.

Original issue reported on code.google.com by [email protected] on 4 May 2012 at 1:12

VMFUNC not decoded

What steps will reproduce the problem?
Disassemble in 64-bit mode:
0f 01 d4

What is the expected output? What do you see instead?
Expect: VMFUNC
Get:
   1: (   0) 0f                       DB 0xf
   2: (   1) 01d4                     ADD ESP, EDX

What version of the product are you using? On what operating system?
diStorm 3.1; OSX 10.6.8

Please provide any additional information below.

I'm not sure if Intel added this to the VMX instruction set after the other VMX 
instructions, but it looks like this one is missing from x86sets.py. All of the 
other VMX instructions appear to decode correctly.

For reference, I'm using the Intel Combined Volumes 1-3 document dated Dec 2011 
and downloaded from here:
http://www.intel.com/content/www/us/en/processors/architectures-software-develop
er-manuals.html

Original issue reported on code.google.com by [email protected] on 13 Feb 2012 at 7:49

movq mnemonic isn't defined

What steps will reproduce the problem?

Disassemble this byte stream in 64-bit mode:
"\x66\x48\x0f\x6e\xc2"; // movq

What is the expected output? What do you see instead?

I expect to see the "movq" instruction. I see "undefined" mnemonic instead.

What version of the product are you using? On what operating system?

diStorm 3.1 built on MacOS X 10.6.8.

Original issue reported on code.google.com by [email protected] on 7 Feb 2012 at 5:41

"XSAVE" mnemonic is shown as "XAVE"

What steps will reproduce the problem?
Disassemble these bytes in 64-bit mode:
0f ae 20

What is the expected output? What do you see instead?
Expect: XSAVE [RAX]
Get: XAVE [RAX]

What version of the product are you using? On what operating system?

diStorm 3.1 built on MacOS X 10.6.8

Please provide any additional information below.

Looks like a simply typo bug in x86sets.py.

Original issue reported on code.google.com by [email protected] on 9 Feb 2012 at 6:35

ctypes byref takes one argument

What steps will reproduce the problem?
1. Test script test_distorm.py
#!/usr/bin/env python

import sys
from distorm3 import Decode, Decode32Bits

l = Decode(0x100, open(sys.argv[1], "rb").read(), Decode32Bits)

2. Test file: any flat binary x86 code

3. ./test_distorm.py test_file

What is the expected output? What do you see instead?
The expected output is to run without syntax errors. I get:
Traceback (most recent call last):
  File "./test_distorm.py", line 6, in <module>
    l = Decode(0x100, open(sys.argv[1], "rb").read(), Decode32Bits)
  File "/usr/local/lib/python2.6/dist-packages/distorm3/__init__.py", line 444, in Decode
    return list( DecodeGenerator(offset, code, type) )
  File "/usr/local/lib/python2.6/dist-packages/distorm3/__init__.py", line 412, in DecodeGenerator
    p_code     = byref(code_buf, instruction_off)
TypeError: byref() takes exactly one argument (2 given)
[Note: it should say 408 instead of 412 this is the patched version with the 
patch commented out so line numbers are offset by 4]

What version of the product are you using? On what operating system?
distorm3 from the download section as well as svn revision 166 produce this 
error.
I am using Python 2.6.5 on an Ubuntu 10.04 LTS x86_64.

Please provide any additional information below.
I found another old issue and a fix for it that states that byref can take an 
optional offset argument, this doesn't seem to be true.

FIX:
This is a very quick (and dumb) fix. I replaced the problem line 408 in 
__init__.py:
p_code = byref(code_buf, instrcution_off)
with:
code_buf = create_string_buffer(code[instruction_off:])
p_code = byref(code_buf)

Original issue reported on code.google.com by [email protected] on 9 Jan 2011 at 10:03

Enable control flow support for Python bindings

Hi,

I am using your disassembler for my PhD work. I needed the flow control 
functionality to be available from Python. Diff attached.

Cheers

Original issue reported on code.google.com by [email protected] on 19 Jun 2012 at 4:13

Attachments:

• distorm.diff

Unable to disassemble valid CMPSS instruction

What steps will reproduce the problem?
Using distorm3 python library:

>>> import distorm3
>>> i = distorm3.Decompose(0x0000000001647a58, "f3410fc2c105".decode('hex'), 
distorm3.Decode64Bits)[0]
>>> print i
SS XMM0, XMM9
>>> i.instructionClass
0: 'ISC_SSE'
>>> i.mnemonic
1: 'UNDEFINED'
>>> i.valid
2: True

What is the expected output? What do you see instead?
CMPSS
An undefined instruction

What version of the product are you using? On what operating system?
distorm3.1.0, distorm-package 3.1

Please provide any additional information below.

Original issue reported on code.google.com by [email protected] on 24 Jan 2012 at 8:34

SYSENTER and SYSEXIT are not decoded

What steps will reproduce the problem?
Disassemble:
0x0f 0x34
0x0f 0x35

What is the expected output? What do you see instead?

Expect:
SYSENTER
SYSEXIT

Get:
   1: (   0) 0f                       DB 0xf
   2: (   1) 34                       DB 0x34

   1: (   0) 0f                       DB 0xf
   2: (   1) 35                       DB 0x35


What version of the product are you using? On what operating system?

diStorm 3.1 on MacOS X 10.6.8

Original issue reported on code.google.com by [email protected] on 9 Feb 2012 at 6:05

PEXTRQ mnemonic isn't decoded

What steps will reproduce the problem?

Disassemble:
0x66 0x48 0x0f 0x3a 0x16 0x00 0x00

What is the expected output? What do you see instead?
Expect: PEXTRQ [RAX], XMM0, 0x0
Get: UNDEFINED [RAX], XMM0, 0x0

What version of the product are you using? On what operating system?

diStorm 3.1 on MacOS X 10.6.8

Original issue reported on code.google.com by [email protected] on 9 Feb 2012 at 4:44

• Merged into: #32

Problem disassembling x64 FAR JMP

The engine is unable to property disassemble the 14 bytes instruction, ex:

FF25000000008877665544332211 JMP 0x1122334455667788

Thanks

Original issue reported on code.google.com by [email protected] on 15 Nov 2011 at 1:44

VTESTPS and VTESTPD are shown as "VPTESTPS" and "VPTESTPD"

What steps will reproduce the problem?

Disassemble these bytes in 64-bit mode:
c4 c2 7d 0e 01         
c4 c2 7d 0f 01            


What is the expected output? What do you see instead?
Expect:
VTESTPS YMM0, [ECX]
VTESTPD YMM0, [ECX]

Get:
VPTESTPS YMM0, [ECX]
VPTESTPD YMM0, [ECX]

What version of the product are you using? On what operating system?

3.1; Mac 10.6.8

Please provide any additional information below.

Looks like a simple typo of the mnemonic name in x86sets.py.

Original issue reported on code.google.com by [email protected] on 10 Feb 2012 at 5:30

_DLL macro conflict with MSVC + static libdistorm + dynamic runtime

Hi,

the preprocessor symbol _DLL is currently used to define whether libdistorm3 
functions should be exported or not.

src/config.h:117:
  /* If the library isn't compiled as a .DLL don't export functions. */
  #ifndef _DLL
  #undef _DLLEXPORT_
  #define _DLLEXPORT_
  #endif

This results in a conflict when using distorm under MSVC library and linking 
with MSVCRT, because then _DLL is defined as follows:

_DLL    -    Defined when /MD or /MDd (Multithreaded DLL) is specified.
             <http://msdn.microsoft.com/en-us/library/b0084kay(v=VS.100).aspx>

Unfortunately there is probably no way to really infer whether the sources are 
compiled as a part of static .lib or into a .dll AFAIK.

But I think you should at least use a different macro, like LIBDISTORM_EXPORTS, 
instead of _DLL. Symbol names beginning with an underscore like this are often 
deemed reserved anyway.

Original issue reported on code.google.com by [email protected] on 21 Feb 2011 at 11:18

RDRAND isn't decoded

What steps will reproduce the problem?
Disassemble these bytes in 64-bit mode:
0x0f 0xc7 0xf0

What is the expected output? What do you see instead?
Expected: RDRAND EAX
Get: 
   1: (   0) 0f                       DB 0xf
   2: (   1) c7                       DB 0xc7
   3: (   2) f0                       DB 0xf0

What version of the product are you using? On what operating system?

diStorm 3.1 on MacOS X 10.6.8

Please provide any additional information below.

This instruction was added by Intel recently:
http://en.wikipedia.org/wiki/RdRand

Original issue reported on code.google.com by [email protected] on 9 Feb 2012 at 6:52

Byte 0x63 is incorrectly dissassembled as ARPL instead of invalid in 16-bit mode

What steps will reproduce the problem?
1. Decode byte 0x63 with Decode16Bits.


What is the expected output? What do you see instead?
You should see DB 0x63.
You will see ARPL <mem>, <reg>.


What version of the product are you using? On what operating system?
Not sure. Win32.


Please provide any additional information below.
Around line 300 of instructions.c there is a check for ARPL vs. MOVSXD. The 
check is for 32-bit and 64-bit, but not for 16-bit.

The line:

return ci->dt == Decode64Bits ? (_InstInfo*)&II_movsxd : &II_arpl;

should be changed to:

return ci->dt == Decode64Bits ? (_InstInfo*)&II_movsxd : ci->dt == Decode32Bits 
? &II_arpl : NULL;

which fixes the problem.

Original issue reported on code.google.com by [email protected] on 29 Apr 2011 at 6:26

Distorm cannot disassemble based on processor; struct DecodeType is not specific enough

What steps will reproduce the problem?
1. Disassemble 8086 (16-bit) code.
2. Disassemble 0x6C in 16-bit mode.
3. The INS - Input String from Port (80188+) opcode is disassembled, even 
though it doesn't exist on the 8086 processor.

What is the expected output? What do you see instead?
We do not expect to see 80186 opcodes disassembled when trying to disassemble 
8086 code. For example, 6C 22 21 in 8086 is:
DB      6C
AND     AH,[BX+DI]
but in 80186 it is:
INS     [ES:DI], DX

What version of the product are you using? On what operating system?
r165

Please provide any additional information below.

The _DecodeType is not a sufficient data type for determining how to 
disassemble.  Instead, a ProcessorType should instead be used.  This would 
would allow the disassembler to accommodate all x86 opcode sets, as well as any 
other future processors.  It would be rather easy to convert to this new data 
type: the existing DecodeTypes would simply convert to 80186, 80386, and 80686 
(or something similar), without any other code changes.

Original issue reported on code.google.com by [email protected] on 30 Apr 2011 at 2:42

Mac install script

What steps will reproduce the problem?
1. go to ./build/mac/
2. run 'make' and attempt to install by running './instpython.sh'
3. will install but fail to load in Python

Please provide any additional information below.

libdistorm64.so should be copied as "distorm3.so" instead of "distorm.so"

Original issue reported on code.google.com by [email protected] on 9 Apr 2010 at 10:50

Sample python script does not work

What steps will reproduce the problem?
1. Run the sample program via "python sample.py"

What is the expected output? What do you see instead?
Sample.py's output

What version of the product are you using? On what operating system?
Revision 132; any OS

Please provide any additional information below.
The distorm should be replaced by distorm3

Original issue reported on code.google.com by [email protected] on 7 Sep 2010 at 6:15

distorm3 has problems compiling/running on OSX 64bits [PATCH]

What steps will reproduce the problem?
1. Compilation fails
2. Once fixed distorm3 segfaults if running the executable in 64bits

The patch will:
-Allow distorm3 to successfully build on OSX
-Build universal binaries for 32bit & 64bit environments
-Successfully execute in 64bits

The build process for OSX goes like:
-Enter "build/mac"
-Run "make"
-Change to "Python/"
-Run "python setup.py install"

That should build a universal (i386, x86_64) binary for the Python library and 
get it installed. Patch is attached that fixes the issues described

Original issue reported on code.google.com by [email protected] on 10 Oct 2010 at 11:50

Attachments:

• distorm_ox_patch.diff

Make installers for Python wrappers

See which module is easier for usage and wrap them all.
Also, what about 32/64 bits ?
And Python3.x?

Original issue reported on code.google.com by [email protected] on 16 May 2010 at 6:42

OSX install fails as Make never creates 'libdstorm64.dylib' or 'distorm3.so'. No make errors pop up.

What steps will reproduce the problem?
1.  make all
2.  ./instpython.sh
3.



What is the expected output? What do you see instead?

After reading instpython.sh, I would expect 'make all' to create the
files:
  libdistorm64.dylib and distorm3.so
in the current working directory.

Instead, it creates only distorm3.dylib and running './instpython.sh'
fails as expected with: "*** Error: Can't find libdistorm64.dylib!"

The make all command produced no errors (echo $? prints 0), only a few
warnings which I
have attached.




What version of the product are you using? On what operating system?

I'm trying to install distorm3 on OSX 10.6.3 from the zip file in
the "Downloads" section.




Please provide any additional information below.

I have attached the output produced by the 'make all' command
(makeout.txt).  I've also attached the warnings I see during 
make all (makewarning.txt).

Original issue reported on code.google.com by [email protected] on 29 Apr 2010 at 5:04

Attachments:

• makeout.txt
• makewarning.txt

"vpblendw" mnemonic is incorrectly defined as "vpblendvw"

What steps will reproduce the problem?

Disassemble these bytes:
0xc4 0xe3 0x69 0x0e 0xd9 0x00

What is the expected output? What do you see instead?
Expected: vpblendw xmm3, xmm2, xmm1, 0x0
Got: vpblendvw xmm3, xmm2, xmm1, 0x0

What version of the product are you using? On what operating system?
diStorm 3.1 built on MacOS X 10.6.8.

Please provide any additional information below.

From the Intel ISA manual Vol 2B, page 4-73:
VEX.NDS.128.66.0F3A.WIG 0E /r ib
VPBLENDW xmm1, xmm2, xmm3/m128, imm8

Original issue reported on code.google.com by [email protected] on 7 Feb 2012 at 5:38

Unexpected disassembly results on OpenBSD

Hi,

I am giving distorm a test run. I hacked together a python script that attempts 
to locate a function (dwarf info found using pyelftools) and disassemble the 
first 10 instructions therein.

I made a simple test program in C:

---8<---
int
do_stuff()
{
        return (errno);
}

int
main(void)
{
        printf("This is a test: %u %d\n", getpid(), do_stuff());

        return (0);
}
---8<---

We compile this with gcc and enable debug symbols so we can easily find main(). 
The binary is called "a".

Manual inspection with radare2 (http://radare.org/y/) shows the beginning of 
main looks like this:

---8<---
       0x00400a0d  sym.main:
       0x00400a0d     55               push rbp
       0x00400a0e     4889e5           mov rbp, rsp
       0x00400a11     53               push rbx
       0x00400a12     4883ec08         sub rsp, 0x8
       0x00400a16     b800000000       mov eax, 0x0 
       0x00400a1b     e8e0ffffff       call dword sym.do_stuff 
---8<---

This code *has* been relocated by radare2, so all addresses are virtual.

Now using distorm:

---8<---
def decode(filename, vaddr):
    print("Decoding %s at vaddr %s" % (filename, hex(vaddr)))
    with open(filename, "rb") as f:

        i = 0
        iterable = distorm3.DecodeGenerator(vaddr, f.read(), distorm3.Decode64Bits)
        for (offset, size, instruction, hexdump) in iterable:
            print("%.8x: %-32s %s" % (offset, hexdump, instruction))
            i += 1
            if (i == 10):
                break
---8<---

The vaddr parameter is provided by pyelf tools, The address of main matches 
what radare2 is reporting, so I believe the vaddr of main to be correct.

I get the following output:

---8<---
Decoding a at vaddr 0x400a0d
00400a0d: 7f45                             JG 0x400a54
00400a0f: 4c460201                         ADD R8B, [RCX]
00400a13: 0100                             ADD [RAX], EAX
00400a15: 0000                             ADD [RAX], AL
00400a17: 0000                             ADD [RAX], AL
00400a19: 0000                             ADD [RAX], AL
00400a1b: 0000                             ADD [RAX], AL
00400a1d: 0200                             ADD AL, [RAX]
00400a1f: 3e0001                           ADD [RCX], AL
00400a22: 0000                             ADD [RAX], AL
---8<---

I am not sure if this is a case of PEBCAK, but the instruction stream distorm 
is decoding does not appear to be correct.  I wondered if it was decoding file 
offsets rather than virtual addresses, but it can't be this, as the instruction 
stream there is [5e, 0a, 50, 00, ... ], which does not match either.

Odd.

I am attaching the binary incase it helps.

Cheers

---- TEMPLATE QUESTIONS ----
In what mode did you try to disassemble (16/32/64)?
64

What is the input buffer (binary stream) you used to reproduce the problem?
Not really related, see below.

What is the expected output (or what instruction)?
See above

Which tool did you use to see the expected output?
radare2

What do you see instead?
See above

What version of diStorm are you using? On what platform (Python/EXE/other)?
Python2.7 and distorm-3.2 on OpenBSD/amd64

Original issue reported on code.google.com by [email protected] on 17 May 2012 at 11:26

Attachments:

• a

Make Dual-License

One license for non commercial users, still open source, of course.
And another license for purchase for commercial users.

Original issue reported on code.google.com by [email protected] on 21 Sep 2010 at 9:34

"VPCMPESTRI" shown as "VCMPESTRI"

What steps will reproduce the problem?
Disassemble these bytes in 64-bit mode:
c4 e3 79 61 d9 00

What is the expected output? What do you see instead?
Expect: vpcmpestri xmm3, xmm1, 0x0           
Get: vcmpestri xmm3, xmm1, 0x0 

What version of the product are you using? On what operating system?
3.1; Mac 10.6.8

Please provide any additional information below.

Looks like another typo in x86sets.py:

        Set("66, 0f, 3a, 61", ["VCMPESTRI"], [OPT.XMM, OPT.XMM128, OPT.IMM8], IFlag.MODRM_REQUIRED | IFlag._32BITS | IFlag.PRE_VEX)
        Set("66, 0f, 3a, 60", ["VPCMPESTRM"], [OPT.XMM, OPT.XMM128, OPT.IMM8], IFlag.MODRM_REQUIRED | IFlag._32BITS | IFlag.PRE_VEX)
        Set("66, 0f, 3a, 63", ["VPCMPISTRI"], [OPT.XMM, OPT.XMM128, OPT.IMM8], IFlag.MODRM_REQUIRED | IFlag._32BITS | IFlag.PRE_VEX)
        Set("66, 0f, 3a, 62", ["VPCMPISTRM"], [OPT.XMM, OPT.XMM128, OPT.IMM8], IFlag.MODRM_REQUIRED | IFlag._32BITS | IFlag.PRE_VEX)

Original issue reported on code.google.com by [email protected] on 10 Feb 2012 at 5:38

VPEXTRQ disassembles incorrectly

What steps will reproduce the problem?

Disassemble:
0xc4 0xe3 0xf9 0x16 0x00 0x00

What is the expected output? What do you see instead?

Expect: VPEXTRQ [RAX], XMM0, 0x0
Get: VPEXTRD RCX, XMM3, 0x0

What version of the product are you using? On what operating system?

diStorm 3.1 on MacOS X 10.6.8.

Unlike issue 33, the operand string appears to be wrong here in addition to the 
wrong mnemonic.

Original issue reported on code.google.com by [email protected] on 9 Feb 2012 at 4:51

new tiny features

Add a 'registersUsed' field in _DInst, to make it quickly testing if some 
register is used in the 4 potential operands.

This feature will also solve the rip-relative register test on the same go.

Add FC_CMOV for CMOV instruction, and FC_SET for SET instructions.

Original issue reported on code.google.com by [email protected] on 9 Sep 2010 at 2:22

lipo: can't open input file: /var/tmp//ccQgpum2.out (No such file or directory)

What steps will reproduce the problem?
1. python setup.py build
2.
3.

What is the expected output? What do you see instead?
I expected it to build in stead I receive the following output:

Macintosh:distorm3 freemonj$ sudo python setup.py build
running build
running custom_build
running build_py
running build_clib
running custom_build_clib
building 'distorm3' library
gcc-4.2 -Wl,-F. -bundle -undefined dynamic_lookup -arch i386 -arch ppc -arch 
x86_64 build/temp.macosx-10.6-universal-2.6/src/decoder.o 
build/temp.macosx-10.6-universal-2.6/src/distorm.o 
build/temp.macosx-10.6-universal-2.6/src/instructions.o 
build/temp.macosx-10.6-universal-2.6/src/insts.o 
build/temp.macosx-10.6-universal-2.6/src/operands.o 
build/temp.macosx-10.6-universal-2.6/src/prefix.o 
build/temp.macosx-10.6-universal-2.6/src/textdefs.o 
build/temp.macosx-10.6-universal-2.6/src/wstring.o 
build/temp.macosx-10.6-universal-2.6/src/x86defs.o 
build/temp.macosx-10.6-universal-2.6/include/mnemonics.o -o 
build/lib/distorm3/libdistorm3.so
ld: duplicate symbol __REGISTERTORCLASS in 
build/temp.macosx-10.6-universal-2.6/src/operands.o and 
build/temp.macosx-10.6-universal-2.6/src/decoder.o for architecture i386
collect2: ld returned 1 exit status
ld: warning: in build/temp.macosx-10.6-universal-2.6/src/decoder.o, missing 
required architecture ppc in file
ld: warning: in build/temp.macosx-10.6-universal-2.6/src/distorm.o, missing 
required architecture ppc in file
ld: warning: in build/temp.macosx-10.6-universal-2.6/src/instructions.o, 
missing required architecture ppc in file
ld: warning: in build/temp.macosx-10.6-universal-2.6/src/insts.o, missing 
required architecture ppc in file
ld: warning: in build/temp.macosx-10.6-universal-2.6/src/operands.o, missing 
required architecture ppc in file
ld: warning: in build/temp.macosx-10.6-universal-2.6/src/prefix.o, missing 
required architecture ppc in file
ld: warning: in build/temp.macosx-10.6-universal-2.6/src/textdefs.o, missing 
required architecture ppc in file
ld: warning: in build/temp.macosx-10.6-universal-2.6/src/wstring.o, missing 
required architecture ppc in file
ld: warning: in build/temp.macosx-10.6-universal-2.6/src/x86defs.o, missing 
required architecture ppc in file
ld: warning: in build/temp.macosx-10.6-universal-2.6/include/mnemonics.o, 
missing required architecture ppc in file
ld: duplicate symbol __REGISTERTORCLASS in 
build/temp.macosx-10.6-universal-2.6/src/operands.o and 
build/temp.macosx-10.6-universal-2.6/src/decoder.o for architecture x86_64
collect2: ld returned 1 exit status
lipo: can't open input file: /var/tmp//ccQgpum2.out (No such file or directory)
error: command 'gcc-4.2' failed with exit status 1


What version of the product are you using? On what operating system?
I am using distorm3 on Darwin Macintosh.local 10.7.0 Darwin Kernel Version 
10.7.0: Sat Jan 29 15:17:16 PST 2011; root:xnu-1504.9.37~1/RELEASE_I386 i386

Please provide any additional information below.

Original issue reported on code.google.com by [email protected] on 6 Apr 2011 at 6:18

Extra Returns

What steps will reproduce the problem?
1. Run disasm32.exe -b64 disasm32.exe >disasm32.txt

What is the expected output? What do you see instead?

There are empty lines when I open the txt file.
In fact, when I open the txt file with an hexadecimal editor, every carriage 
return is saved as: 0D 0D 0A, which means that there is an extra 0D.

Original issue reported on code.google.com by [email protected] on 2 Jul 2010 at 10:19

32 chars isn't enough to contain DWORD [EAX+0x12345678], 0x87654321

MAX_TEXT_SIZE is too small to decode some instruction operands.

Original issue reported on code.google.com by [email protected] on 17 Nov 2010 at 9:21

Finish wrapper decompose API in Python

See if the structured types in C can be better lay-out in a way, so it's 
easier to work with them in c-types also.

Original issue reported on code.google.com by [email protected] on 16 May 2010 at 6:43

call bug in distorm3

What steps will reproduce the problem?
1. for a in distorm3.DecodeGenerator(0x40ac12d4, '65e8ff75f88b'.decode('hex'), 
distorm3.Decode32Bits):
     print a[2]
2. the result is CALL 0xffffffffcca488d8 which doesn't seem right in 32 bits

i'm using the latest distorm, on windows 7, x64

Original issue reported on code.google.com by [email protected] on 8 Oct 2010 at 4:10

Unable to disassemble valid MPEQSD instruction

What steps will reproduce the problem?
Using distorm3 python library:
>>> import distorm3
>>> i = distorm3.Decompose(0x00000000019bc461, "f20fc2f701".decode('hex'), 
distorm3.Decode64Bits)[0]
>>> i.opcode
5: 4548
>>> i.mnemonic
6: 'UNDEFINED'
>>> i.valid
7: True

What is the expected output? What do you see instead?
MPEQSD
INVALID

What version of the product are you using? On what operating system?
distorm3.1.0, distorm-package 3.1
Windows 7 x64

Please provide any additional information below.
0x11c4: "MPEQSD",
is missing in distorm3.Mnemonics

Original issue reported on code.google.com by [email protected] on 24 Jan 2012 at 8:42

• Merged into: #29