cmpham / distorm Goto Github PK
View Code? Open in Web Editor NEWAutomatically exported from code.google.com/p/distorm
License: GNU General Public License v3.0
Automatically exported from code.google.com/p/distorm
License: GNU General Public License v3.0
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:
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
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
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
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
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
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
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
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
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
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:
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
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
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
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
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
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
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:
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:
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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:
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
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
A declarative, efficient, and flexible JavaScript library for building user interfaces.
๐ Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. ๐๐๐
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google โค๏ธ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.