IDA .sig file doesn't work when target is 16 bits?
 

I use IDA to disassemble a NE file.
And this 16 bits target used a 16 bits obj, I am sure for this.
But when I make a .sig file and apply, no functions matched.

IDA .sig works fine when tartget is 32 bits.
Does IDA .sig file works file when target is 16 bits? Only for 32 bits target?
Has someone successed in applying .sig to 16 bits target and
several functions matched?
//thanks

*.sig
 

Of course *sig files works also with 16 bit programs, but you should choose appropriate signature file for particular program - borland ,m$ etc ...

Regards.
Janus.

IDA's signature mechanism work well with 16bit code... Just disassemble any Borland's oldie and see by yourself.

Probably:
1) you made wrongly the signature
2) your program contains no statically linked functions belonging to your sig file

Have a look ;) !

Here is the function in obj and NE target
 

//From the obj:
_TEXT:23F4 _API_HL proc far ; CODE XREF: _API_HL_STACK+9p
_TEXT:23F4 ; _API_HL_CSTACK+9p
_TEXT:23F4 cmp word ptr es:[bx+6], 0
_TEXT:23F9 jz loc_248D
_TEXT:23FB
_TEXT:23FB loc_248B: ; CODE XREF: _API_HL+Ej
_TEXT:23FB jmp short near ptr sub_24EB
_TEXT:23FD ; ��������������������������������������������������������������������������?
_TEXT:23FD
_TEXT:23FD loc_248D: ; CODE XREF: _API_HL+5j
_TEXT:23FD cmp word ptr es:[bx+18h], 0Bh
_TEXT:2402 jnz loc_248B
_TEXT:2404 cmp word ptr es:[bx+16h], 0
_TEXT:2409 jnz loc_24A3
_TEXT:240B mov ax, 0
_TEXT:240E
_TEXT:240E loc_249E: ; CODE XREF: _API_HL+2Aj
_TEXT:240E mov es:[bx+1Ah], ax
_TEXT:2412 retf
_TEXT:2413 ; ��������������������������������������������������������������������������?
_TEXT:2413
_TEXT:2413 loc_24A3: ; CODE XREF: _API_HL+15j
_TEXT:2413 cmp byte ptr es:[bx+0FEh], 0

//From the target 16 bits exe (NE):
This function must be _API_HL in the obj, the two subs are exactly the same.
In IDA I change the sub name to _API_HL_?
plb .obj .pat
sigmake .pat .sig
.sig generated and applied to the exe, no functions matched.
//Why?

cseg01:4B95 _API_HL_? proc far ; CODE XREF: _API_HL_STACK+9p
cseg01:4B95 ; cseg01:5110p
cseg01:4B95 cmp word ptr es:[bx+6], 0
cseg01:4B9A jz loc_4B9E
cseg01:4B9C
cseg01:4B9C loc_4B9C: ; CODE XREF: _API_HL_?+Ej
cseg01:4B9C jmp short near ptr sub_4BF9
cseg01:4B9E ; ��������������������������������������������������������������������������?
cseg01:4B9E
cseg01:4B9E loc_4B9E: ; CODE XREF: _API_HL_?+5j
cseg01:4B9E cmp word ptr es:[bx+18h], 0Bh
cseg01:4BA3 jnz loc_4B9C
cseg01:4BA5 cmp word ptr es:[bx+16h], 0
cseg01:4BAA jnz loc_4BB4
cseg01:4BAC mov ax, 0
cseg01:4BAF
cseg01:4BAF loc_4BAF: ; CODE XREF: _API_HL_?+2Aj
cseg01:4BAF mov es:[bx+1Ah], ax
cseg01:4BB3 retf
cseg01:4BB4 ; ��������������������������������������������������������������������������?
cseg01:4BB4
cseg01:4BB4 loc_4BB4: ; CODE XREF: _API_HL_?+15j
cseg01:4BB4 cmp byte ptr es:[bx+0FEh], 0

Interesting, it seems you are right. If you send me the file I'll look deeper... Byez!