Does not detect DOS Executables
See original GitHub issueghidra_9.1-BETA_DEV (and also 9.0.4)
if i open up a simple 16 bit dos exe (build with nasm assembler and ulink) Ghidra doesn’t detect it as Old-Style DOS Exe
The exe is working and correctly assembled - checked with dosbox debugger and IDA Pro (also tested with several other assemblers - its a linker thing)
single.asm
; build with:
; nasm.exe (https://www.nasm.us/pub/nasm/releasebuilds/2.14.02/)
; ulink.exe (ftp://ftp.styx.cabel.net/pub/UniLink/)
;
; nasm.exe -f obj -o single.obj single.asm
; unlink.exe single.obj
BITS 16
segment seg000 align=16
text: db 'Hello World!',0ah,0dh,'$'
segment seg001 align=16
..start:
mov ax,seg000
mov ds,ax
push ax
pop ax
call far print
mov ax,0x4c00
int 0x21
segment seg002 align=16
print:
mov dx,text
mov ah,9
int 0x21
retf
segment seg003 stack
resb 256
checked it with serveral Linkers: wlink.exe: Open Watcom Linker Version 2.0 beta Sep 13 2019 01:44:55 (64-bit) link.exe: Microsoft ® Segmented Executable Linker Version 5.60.339 Dec 5 1994 optlink.exe: OPTLINK ® for Win32 Release 8.00.17 (from the dmd package: dmd.2.088.0.windows) ulink.exe: UniLink v1.11 [beta] (build 11.27) from ftp://ftp.styx.cabel.net/pub/UniLink/
all exes except the ulink.exe linked exe getting detected as Old-Style DOS Exe the only real difference is a “UniLink” string between the header and relocation table
IDA Pro detects all of them as DOS MZ Executables
optlink.single.exe -> detected as Old-Style DOS Exe
exe_header:
signature: MZ
bytes_in_last_block: 0x0068
blocks_in_file: 0x0001
num_relocs: 0x0002
header_paragraphs: 0x0003
min_extra_paragraphs: 0x0010
max_extra_paragraphs: 0xffff
ss:sp: 0x0004:0x0100
checksum: 0x0000
cs:ip: 0x0001:0x0000
reloc_table_offset: 0x001e
overlay_number: 0x0000
data between header and relocation table:
00000000 00 00 ..
relocation_table:
0 0x0001:0x000A
1 0x0001:0x0001
ulink.single.exe -> detected as Raw binary
exe_header:
signature: MZ
bytes_in_last_block: 0x0088
blocks_in_file: 0x0001
num_relocs: 0x0002
header_paragraphs: 0x0005
min_extra_paragraphs: 0x0011
max_extra_paragraphs: 0xffff
ss:sp: 0x0004:0x0100
checksum: 0x0000
cs:ip: 0x0001:0x0000
reloc_table_offset: 0x0040
overlay_number: 0x0000
data between header and relocation table:
00000000 55 6E 69 4C 69 6E 6B 00 00 00 00 00 00 00 00 00 UniLink.........
00000010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00000020 00 00 00 00 ....
relocation table:
0 0x0001:0x0001
1 0x0001:0x000A
nasm sample dos exes build with serveral linkers: http://s000.tinyupload.com/?file_id=77824670479507329081
data between header and relocation table by linker:
optlink.exe: 00 00
link.exe: 01 00
wlink.exe: 00 00 00 00
ulink.exe:
00000000 55 6E 69 4C 69 6E 6B 00 00 00 00 00 00 00 00 00 UniLink.........
00000010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00000020 00 00 00 00 ....
Issue Analytics
- State:
- Created 4 years ago
- Reactions:1
- Comments:12
i would also add ‘PE’ to the check
The problem is here: https://github.com/NationalSecurityAgency/ghidra/blob/208433c9f7b2e4af8cd26d0b757ecb74a37e8f07/Ghidra/Features/Base/src/main/java/ghidra/app/util/opinion/MzLoader.java#L72-L74 and here: https://github.com/NationalSecurityAgency/ghidra/blob/208433c9f7b2e4af8cd26d0b757ecb74a37e8f07/Ghidra/Features/Base/src/main/java/ghidra/app/util/bin/format/mz/DOSHeader.java#L255-L261
ulink
has ae_lfarlc
value of 0x40