16bit jump recognizing error in 32bit image.

[XVilka]

See example here http://xvilka.me/phx_uefi.bin

1. Open bios file with radare2 using this command:

   r2 -e asm.bits=32 -e io.va=true phx_uefi.bin

You should choose valid asm.bits value due to arch of image.

1. Do bootblock segment relocation:

   [0x00000000]> S $s-0x10000 0xf000:0x0000 0x10000 0x10000 bootblk rwx

where '$s' - variable, file size (see output of '???' command)

Then set this as 16bit segment

[0x00000000]> Sa x86 16

You can check result by typing just 'S' command.

You can also set DOS-like addressing notation:

[0x00000000]> e asm.segoff=true
[0000:0000]>

1. go to 0xf000:0xfff0, where BIOS starts

'[0000:0000]> s 0xf000:0xfff0'

1. Disassembly

   [f000:fff0]> pd 1
   f000:fff0 e908ff0000 jmp dword 0x10fefd

While here opcode is 'e908ff' and all, so this is jmp f000:fefb.

Same for f000:fefb

[f000:fefb]> pd 1
f000:fefb      e913fd662e     jmp dword 0x2e76fc13

Which should be
f000:fefb e913fd jmp f000:fc11

[XVilka]

Looks like this is analyzer issue, and can't be unit-tested by rasm2 line - should be some small binary?

[XVilka]

You can check also f000:fc11 address:
[f000:fc11]> pd
f000:fc11 66b80100 mov ax, 0x1
f000:fc15 0000 add [eax], al
f000:fc17 0fa2 cpuid

which obviously (IDA thinks so too) should be:
[f000:fc11]> pd
f000:fc11 66b801000000 mov eax, 0x1
f000:fc17 0fa2 cpuid

And so on...

[radare]

Thanks for reporting!

This bug was hard to fix because it was caused by two bugs. It should be fixed now in git. Can you try it and reopen the bug if can't reproduce?

I wrote this script to test the bug in an automated way.

$ cat test.rsc
e asm.segoff=true
e asm.bits=32
e io.va=1
f sz = 0x10000
S $s-sz f000:0000 sz sz bootblk rwx
s 0xf000:0100
Sa x86 16
S
s 0x1f0100
?e---------------------
pd 3
e asm.bits=16
pd 3
q!

$ r2 -qi test.rsc phx_uefi.bin