I'm trying to figure out how disassembler works. Specifically, how the content in memory maps to the corresponding assembly language opcode.
Below is the content in memory, first column address:
773eed5c 50 ff 15 0c 17 3a 77 90-90 90 90 90 8b ff 55 8b P....:w.......U.
773eed6c ec 51 51 83 7d 10 00 74-38 ff 75 10 8d 45 f8 50 .QQ.}..t8.u..E.P
773eed7c e8 14 d7 ff ff 85 c0 74-24 56 ff 75 fc ff 75 0c .......t$V.u..u.
773eed8c ff 75 08 e8 ab ff ff ff-83 7d 10 00 8b f0 74 0a .u.......}....t.
773eed9c 8d 45 f8 50 ff 15 9c 15-3a 77 8b c6 5e c9 c2 0c .E.P....:w..^...
773eedac 00 83 65 fc 00 eb d2 90-90 90 90 90 8b ff 55 8b ..e...........U.
773eedbc ec 57 e8 c7 d6 ff ff 8b-4d 0c 6a 34 5f 03 c7 0f .W......M.j4_...
773eedcc b7 00 40 40 03 c9 3b c8-0f 82 07 e5 00 00 56 e8 ..@@..;.......V.
And the corresponding disassemble result, first column memory address, second column opcode of instruction, the rest columns assembly instructions:
0x773eed5c 50 push eax
0x773eed63 90 nop
0x773eed65 90 nop
0x773eed67 90 nop
0x773eed6a 55 push ebp
0x773eed6d 51 push ecx
0x773eed6f 837d1000 cmp dword ptr [ebp+10h],0 ss:0023:056cfa8c=778237eb
0x773eed7c e814d7ffff call kernel32!Basep8BitStringToDynamicUnicodeString (773ec495)
Now I can see the opcode e814d7ffff
is on memory literally (e8 14 d7 ff ff
)
But how to interpret the content in memory address 0x773eed5c
? How the opcode for push eax
and the consecutive nop
s maps to memory content 0c15ff50 90773a17 90909090 8b55ff8b
?
UPDATE:
The disassemble result I gave above is incorrect. The correct result, as shown below, fits the content in memory nicely:
0x773eed5c 50 push eax
0x773eed5d ff150c173a77 call dword ptr [kernel32+0x170c (773a170c)] ds:0023:773a170c={ntdll!RtlExitUserThread (777ef608)}
0x773eed63 90 nop
0x773eed64 90 nop
0x773eed65 90 nop
0x773eed66 90 nop
0x773eed67 90 nop
0x773eed68 8bff mov edi,edi
0x773eed6a 55 push ebp
0x773eed6b 8bec mov ebp,esp
0x773eed6d 51 push ecx
0x773eed6e 51 push ecx
0x773eed6f 837d1000 cmp dword ptr [ebp+10h],0 ss:0023:0447fc24=778237eb
0x773eed73 7438 je kernel32!OpenFileMappingA+0x45 (773eedad) [br=1]
0x773eed75 ff7510 push dword ptr [ebp+10h] ss:0023:0447fc24=778237eb
0x773eed78 8d45f8 lea eax,[ebp-8]
0x773eed7b 50 push eax
0x773eed7c e814d7ffff call kernel32!Basep8BitStringToDynamicUnicodeString (773ec495)
For details about my mistake: I'm using pykd
to develop a tool around WinDbg. The documentation about its disasm
module doesn't cover the detail, so I used the wrong param to the disasm.jumprel
function, which result in the incomplete disassemble result.
There does seem to be some stuff missing.
50 push eax
ff 15 0c 17 3a 77 call [0x0c173a77] ; where did this thing go?
90 nop
90 nop
90 nop
90 nop
90 nop
8b ff mov edi, edi ; wut?
55 push ebp ; this looks like the beginning of a function
8b ec mov ebp, esp
51 push ecx
51 push ecx
83 7d 10 00 cmp [ebp + 10], 0
I disassembled this manually, I may have made mistakes. This code is weird. Your disassembly of it is even weirder and I have no idea how it happened.