Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
| From | Rod Pemberton <NeedNotReplyHere@xrsevnneqk.cem> |
|---|---|
| Newsgroups | comp.os.msdos.programmer, alt.lang.asm |
| Subject | Re: 16 bit code |
| Date | 2016-11-26 20:08 -0500 |
| Organization | Aioe.org NNTP Server |
| Message-ID | <20161126200838.13f7dcda@_> (permalink) |
| References | <o1cv35$n1s$1@dont-email.me> |
Cross-posted to 2 groups.
On Sat, 26 Nov 2016 16:34:41 -0500 "Bill Cunningham" <nospam@nspam.invalid> wrote: (I added alt.lang.asm. You could also try comp.lang.asm.x86.) > This is a disasssembly of a driver code. The ext was .sys. Which > is DOS is probably always a driver. Does anyone know what it's > saying. There's no ints called. This isn't source code. Maybe you > can't get that from a disassembly. > > > > 210D:0100 0F DB 0F > 210D:0101 00B98AFF ADD [BX+DI+FF8A],BH > 210D:0105 F3 REPZ > 210D:0106 AE SCASB > 210D:0107 47 INC DI > 210D:0108 61 DB 61 > 210D:0109 031F ADD BX,[BX] > 210D:010B 8BC3 MOV AX,BX > 210D:010D 48 DEC AX > 210D:010E 12B1048B ADC DH,[BX+DI+8B04] > 210D:0112 C6F70A MOV BH,0A > 210D:0115 0AD0 OR DL,AL > 210D:0117 D348DA ROR WORD PTR [BX+SI-26],CL > 210D:011A 2BD0 SUB DX,AX > 210D:011C 3400 XOR AL,00 > 210D:011E FC CLD > 210D:011F 2000 AND [BX+SI],AL > > > nasm would asemble this. Well, it probably wouldn't assemble it as it is. A hex dump doesn't reveal any text data: (sorry, line wraps) 00000000 0f 00 b9 8a ff f3 ae 47 61 03 1f 8b c3 48 12 b1 |..¹.ÿó®Ga...ÃH.±| 00000010 04 8b c6 f7 0a 0a d0 d3 48 da 2b d0 34 00 fc 20 |..Æ÷..ÐÓHÚ+Ð4.ü | 00000020 00 |.| ndisasm -b16 00000000 0F db 0x0f 00000001 00B98AFF add [bx+di-0x76],bh 00000005 F3AE repe scasb 00000007 47 inc di 00000008 61 popaw 00000009 031F add bx,[bx] 0000000B 8BC3 mov ax,bx 0000000D 48 dec ax 0000000E 12B1048B adc dh,[bx+di-0x74fc] 00000012 C6 db 0xc6 00000013 F7 db 0xf7 00000014 0A0A or cl,[bp+si] 00000016 D0D3 rcl bl,1 00000018 48 dec ax 00000019 DA2B fisubr dword [bp+di] 0000001B D0 db 0xd0 0000001C 3400 xor al,0x0 0000001E FC cld 0000001F 2000 and [bx+si],al Of course, 0F is not a valid instruction anymore, and so is not a valid code entry point, unless it's actually 8086 code which had the obsolete "POP CS" instruction, or some of the "undocumented" 0x0F instructions that have existed (IBTS, XBTS, UMOV, CMOV, LOADALL, UDx, RDPMC, 286 hang, SETO, PFCMPGE, etc), or 0x0F instructions for the V20 processor, or 0x0F escape instructions for various emulators, like Virtual PC, etc. However, AFAIK, the undocumented 0x0F instructions and escapes, all seem to be followed by a value other than zero ... The single math coprocessor instruction FISUBR in the middle of a bunch of regular instruction, would seem to indicate that this might just be a bunch of data, junk, or padding, but that could be because NDISASM doesn't like the 0xC6 MOV encoding. Of course, this "break" or dis-jointed code in the middle, might also seem to imply that there is some data stored in-between two code pieces? If we skip a couple of bytes, the start looks better, but we still don't know what is correct: ... 00000002 B98AFF mov cx,0xff8a 00000005 F3AE repe scasb ... It could very well start with an 8086 POP CS: 00000000 0F pop cs ; 8086 only 00000001 00B98AFF add [bx+di-0x76],bh 00000005 F3AE repe scasb ... NDISASM doesn't seem to like the 0xC6. Perhaps, it's not valid for 16-bit code? The C6 MOV instruction is C6 /0, and will encode as C6 C7 0A. Apparently, that's not a valid instruction encoding with F7 instead of C7. Although, it may execute on some earlier processors, as it could be undocumented form. If we correct the three bytes for the 0xC6 MOV that NDISASM doesn't like: 00000000 0F pop cs 00000001 00B98AFF add [bx+di-0x76],bh 00000005 F3AE repe scasb 00000007 47 inc di 00000008 61 popaw 00000009 031F add bx,[bx] 0000000B 8BC3 mov ax,bx 0000000D 48 dec ax 0000000E 12B1048B adc dh,[bx+di-0x74fc] 00000012 C6C70A mov bh,0xa 00000015 0AD0 or dl,al 00000017 D348DA ror word [bx+si-0x26],cl 0000001A 2BD0 sub dx,ax 0000001C 3400 xor al,0x0 0000001E FC cld 0000001F 2000 and [bx+si],al Now, it doesn't look too bad. The FISUBR is gone. The address in the ADC instruction seems odd though. Although, it still appears to be "junk" code, or perhaps compiler generated, as it's not obvious that it's doing anything useful. It does look slightly better as 32-bit, with 0xC6 MOV fixed, but it still has the 0F. ... 00000002 B98AFF mov cx,0xff8a 00000005 F3AE repe scasb 00000007 47 inc di 00000008 61 popaw 00000009 031F add bx,[bx] 0000000B 8BC3 mov ax,bx 0000000D 48 dec ax 0000000E 12B1048B adc dh,[bx+di-0x74fc] 00000012 C6C70A mov bh,0xa 00000015 0AD0 or dl,al 00000017 D348DA ror dword [eax-0x26],cl 0000001A 2BD0 sub edx,eax 0000001C 3400 xor al,0x0 0000001E FC cld 0000001F 2000 and [eax],al If you want to correctly disassemble a piece of code, you need to have actually stepped through it or disassembled it from a known code entry point. The reason you need to know the entry point is that the x86 instruction set is full, i.e., any byte could be code or data. So, there is really nothing which can indicate whether you're looking at data or code. Anyway, my guess is it's junk or data, but I've also seen compiled C code that looks similarly useless. So, maybe it's compiled C or Pascal, etc. Rod Pemberton
Back to alt.lang.asm | Previous | Next | Find similar | Unroll thread
Re: 16 bit code Rod Pemberton <NeedNotReplyHere@xrsevnneqk.cem> - 2016-11-26 20:08 -0500
csiph-web