News:

Masm32 SDK description, downloads and other helpful links
Message to All Guests

Main Menu

disassembler

Started by minor28, May 07, 2017, 09:45:43 PM

Previous topic - Next topic

minor28

I am writing a disassembler like dumpbin. At this point I can decode integer and FPU operations. SSE, VMX and SMX are next to work with.

My own programs are decoded correctly. But I have discovered some strange decodes in other programs that I wonder about. Dumpbins get the same results.


6E outs dx,byte ptr [esi]
67 ;no mnemonic. Prefix for 16 bit addressing
65 ;prefix for gs segment. 64 (next byte) is fs segment
64 00 4C 69 6E add byte ptr fs:[ecx+ebp*2+6Eh],cl

The combination 67 65 64 is strange for me. The first and the last lines are assembled correctly but all four are not.

I wonder if anyone knows how these four lines should be coded in masm lang to give this result.

jj2007

Try Olly: Select a range of lines well before and after the codes you are interested in, then hit Ctrl A like "analyse".

mineiro

You can check on intel/amd manuals about opcode generation.
https://software.intel.com/en-us/articles/intel-sdm

On link below have a c source code of a disassembler that you can check too.
http://www.agner.org/optimize/#objconv
I'd rather be this ambulant metamorphosis than to have that old opinion about everything

minor28

With Ollydbg I found out that it appears that a lot of data is stored between two processes. This means that the dumpbin as well as my disassembler do not decode correctly when you save data that way.

The process after data

00 55 8B add byte ptr [ebp-75h],dl
EC in al,dx

insted of

55 puch EBP
8B EC mov EBP,ESP


Thanks

sinsi


6E outs dx,byte ptr [esi]
67 ;no mnemonic. Prefix for 16 bit addressing
65 ;prefix for gs segment. 64 (next byte) is fs segment
64 00 4C 69 6E add byte ptr fs:[ecx+ebp*2+6Eh],cl


Maybe they're not code bytes but text?
6E 67 65 64 00 4C 69 6E    nged.Lin

newrobert

it's look like ascii code, maybe in .text session;