wrong analysis of 16bit jumps #36

XVilka · 2012-11-20T03:33:31Z

For example, see this code:

f000:0540   6633c0     xor eax, eax
f000:0543   0fa2          cpuid
f000:0545   6681fb47656e75  cmp ebx, 0x756e6547
f000:054c   7404         jz 0xf0552
f000:054e   fa              cli
f000:054f    f4              hlt
f000:0550   ebfc          jmp 0xf054e
f000:0552   0f08          invd
f000:0554   0f6eff        movd mm7, edi
f000:0557   668bc4     mov eax, esp
f000:055a   e9c806     jmp word 0xc25

Here radare2 can recognize deadloop:

-> f000:054f f4  hlt
.=< f000:0550 ebfc jmp 0xf054e

but not this normal jump:

f000:054c     jz 0xf0552
...
f000:0552     invd

The text was updated successfully, but these errors were encountered:

radare · 2012-11-20T17:33:39Z

I have workarounded a little to identify the issue. text disasm looks correct, but code analysis fails because opcode length differs from the disasm one (anal != asm). What looks wrong for me is this:

$ cat < EOF > test.rsc
wx 6633c0 0fa2 6681fb47656e75 7404faf4 ebfc 0f08 0f6eff 668bc4 e9c806
e asm.bits=32
pd 10
e asm.bits=16
?e ----
pd 10
EOF
$ r2 -qi test.rsc -
        0x00000000      6633c0           xor ax, ax
        0x00000003      0fa2             cpuid 
        0x00000005      6681fb4765       cmp bx, 0x6547
        0x0000000a      6e               outsb 
        0x0000000b      7574             jnz 0x81
        0x0000000d      04fa             add al, 0xfa
    |   0x0000000f      f4               hlt 
    `=< 0x00000010      ebfc             jmp 0xe
        0x00000012      0f08             invd 
        0x00000014      0f6eff           movd mm7, edi
----
        0x00000000      6633c0           xor eax, eax
        0x00000003      0fa2             cpuid 
        0x00000005      6681fb47656e75   cmp ebx, 0x756e6547
        0x0000000c      7404             jz 0x12
    .-> 0x0000000e      fa               cli 
    |   0x0000000f      f4               hlt 
    `=< 0x00000010      ebfc             jmp 0xe
        0x00000012      0f08             invd 
        0x00000014      0f6eff           movd mm7, edi
        0x00000017      668bc4           mov eax, esp

I would suggest writing a separate x86-16 code analysis,because it seems to have strange results.

Also notice that the 32bit disassembly shows 16bit registers, and 16bit one shows 32bit ones :? is this correct?

also here there is the disasm done by pyew and ida: (thx matalaz)

http://pastebin.com/N7DZzdLE
http://pastebin.com/is4eg1x3

XVilka · 2012-11-20T22:25:02Z

Image is here - http://xvilka.me/ami_bios.bin
Here is diassembly from IDA

BOOTBLK:0540             ; void __cdecl CPU_check()
BOOTBLK:0540             CPU_check       proc near                                   ; CODE XREF: CPU_early_init+13�j
BOOTBLK:0540 66 33 C0                    xor     eax, eax                            ; Logical Exclusive OR
BOOTBLK:0543 0F A2                       cpuid                                       ; Get CPU ID
BOOTBLK:0545 66 81 FB 47+                cmp     ebx, 'uneG'                         ; Compare Two Operands
BOOTBLK:054C 74 04                       jz      short continue                      ; Jump if Zero (ZF=1)
BOOTBLK:054C
BOOTBLK:054E FA                          cli                                         ; Clear Interrupt Flag
BOOTBLK:054F F4                          hlt                                         ; Halt
BOOTBLK:054F
BOOTBLK:054F             ; ---------------------------------------------------------------------------
BOOTBLK:0550 EB                          db 0EBh
BOOTBLK:0551 FC                          db 0FCh
BOOTBLK:0552             ; ---------------------------------------------------------------------------
BOOTBLK:0552
BOOTBLK:0552             continue:                                                   ; CODE XREF: CPU_check+C�j
BOOTBLK:0552 0F 08                       invd                                        ; Invalidate Data Cache
BOOTBLK:0554 0F 6E FF                    movd    mm7, edi                            ; Move 32 bits
BOOTBLK:0557 66 8B C4                    mov     eax, esp
BOOTBLK:055A E9 C8 06                    jmp     CPU_init_j                          ; return at address, stored in *mm7* register
BOOTBLK:055A
BOOTBLK:055A             CPU_check       endp

radare · 2012-11-22T17:08:43Z

Should be fixed in the last commit in git. now the anal.x86 uses anal.x86.udis86 when asm.bits is 16

Thanks!

XVilka · 2014-11-10T12:11:42Z

Not exactly wrong but not sure if this notation is good enough:

$ ./radare2.exe asrock_p4i65g.bin
 -- Set color to your screen with 'e scr.color=true'
[f000:fff0]> pd 1
           ;-- entry0:
           f000:fff0    eaaaff00f0   ljmp 0xffaa, 0xf000
[f000:fff0]>

XVilka · 2014-11-10T12:14:47Z

Also this (note the jb instruction at [f000:4749]):

[f000:4736]> pd 10
/ (fcn) SMBus_Write_Byte 102
|          f000:4736    660fcc       bswap esp
|          f000:4739    66c1c010     rol eax, 0x10
|          f000:473d    8ae2         mov ah, dl
|          f000:473f    90           nop
|          f000:4740    bc4547       mov sp, 0x4745 ; 0x00004745
|      ,=< f000:4743    eb65         jmp SMBus_Host_Transaction_Complete_Error
|      |   f000:4745    47           inc di
|      |   f000:4746    47           inc di
|      |   f000:4747    8ad4         mov dl, ah
|      |   f000:4749    724d         jb 0xf4798
[f000:4736]> pd 20
/ (fcn) SMBus_Write_Byte 102
|          f000:4736    660fcc       bswap esp
|          f000:4739    66c1c010     rol eax, 0x10
|          f000:473d    8ae2         mov ah, dl
|          f000:473f    90           nop
|          f000:4740    bc4547       mov sp, 0x4745 ; 0x00004745
|      ,=< f000:4743    eb65         jmp SMBus_Host_Transaction_Complete_Error
|      |   f000:4745    47           inc di
|      |   f000:4746    47           inc di
|      |   f000:4747    8ad4         mov dl, ah
|     ,==< f000:4749    724d         jb 0xf4798
|     ||   f000:474b    8ac2         mov al, dl
|     ||   f000:474d    b405         mov ah, 5 ; 5
|     ||   f000:474f    90           nop
|     ||   f000:4750    bc5547       mov sp, 0x4755 ; 0x00004755
|    ,===< f000:4753    eb4e         jmp SMBus_ICH5_Reg_Write_Byte
|    |||   f000:4755    57           push di
|    |||   f000:4756    47           inc di
|    |||   f000:4757    66c1c008     rol eax, 8
|    |||   f000:475b    24fe         and al, 0xfffe
|    |||   f000:475d    b404         mov ah, 4 ; 4
[f000:4736]>

radare · 2014-11-10T12:23:17Z

is this a capstone regression?

radare · 2014-11-10T12:25:49Z

i would say no. lets open a bug in capstone before they release! quick!

On 11/10/2014 01:11 PM, Anton Kochkov wrote:

Not exactly wrong but not sure if this notation is good enough:

|$ ./radare2.exe asrock_p4i65g.bin
-- Set color to your screen with 'e scr.color=true'
[f000:fff0]> pd 1
;-- entry0:
f000:fff0 eaaaff00f0 ljmp 0xffaa, 0xf000
[f000:fff0]>
|

—
Reply to this email directly or view it on GitHub
#36 (comment).

radare · 2014-11-10T12:33:32Z

capstone-engine/capstone#213

i have opened this issue. lets see if they can fix it quickly. distros
will not use our embedded capstone library, so i guess this can be fixed
in their side.. but maybe we should switch to udis only for 16bit, what
do you think?

On 11/10/2014 01:11 PM, Anton Kochkov wrote:

Not exactly wrong but not sure if this notation is good enough:

|$ ./radare2.exe asrock_p4i65g.bin
-- Set color to your screen with 'e scr.color=true'
[f000:fff0]> pd 1
;-- entry0:
f000:fff0 eaaaff00f0 ljmp 0xffaa, 0xf000
[f000:fff0]>
|

—
Reply to this email directly or view it on GitHub
#36 (comment).

XVilka · 2014-11-10T12:49:43Z

@radare lets wait a bit, depends if they can fix it fast enough.

radare · 2014-11-10T13:24:35Z

its fixed now :) quite fast, isnt? can you retry?

XVilka · 2015-04-10T23:54:59Z

Fixed for

[f000:fff0]> pd 1
           ;-- entry0:
           f000:fff0    eaaaff00f0   ljmp 0xffaa, 0xf000
[f000:fff0]>

but still present to

|      |   f000:4747    8ad4         mov dl, ah
|     ,==< f000:4749    724d         jb 0xf4798
|     ||   f000:474b    8ac2         mov al, dl
|     ||   f000:474d    b405         mov ah, 5 ; 5
|     ||   f000:474f    90           nop

radare · 2015-04-11T08:40:50Z

Shouldnt be discussed with capstone?

On 11 Apr 2015, at 01:55, Anton Kochkov [email protected] wrote:

Fixed for

[f000:fff0]> pd 1
;-- entry0:
f000:fff0 eaaaff00f0 ljmp 0xffaa, 0xf000
[f000:fff0]>
but still present to

| | f000:4747 8ad4 mov dl, ah
| ,==< f000:4749 724d jb 0xf4798
| || f000:474b 8ac2 mov al, dl
| || f000:474d b405 mov ah, 5 ; 5
| || f000:474f 90 nop
—
Reply to this email directly or view it on GitHub.

radare · 2015-05-20T19:03:06Z

This thing depends partly on a capstone bug that is taking more time to get fixed that the expected.. so lets move this to 1.0

jvoisin · 2015-09-01T20:42:23Z

What capstone bug?

radare · 2015-09-01T21:25:47Z

capstone-engine/capstone#352 capstone-engine/capstone#352
capstone-engine/capstone#111 capstone-engine/capstone#111

Also see: capstone-engine/capstone#111 (comment) capstone-engine/capstone#111 (comment)

On 01 Sep 2015, at 22:42, jvoisin [email protected] wrote:

What capstone bug?

—
Reply to this email directly or view it on GitHub #36 (comment).

Maijin · 2015-12-07T13:21:39Z

@XVilka looks like the

ljmp 0xf000:0xffaa                                    ;[1]

Regressed again, it needs a test definitely, see the result of $j =>

[f000:fff0]> ? $j
61440 0xf000 0170000 60K 0000:0000 61440 00000000 61440.0 0.000000f 0.000000
[f000:fff0]>

radare · 2015-12-08T00:38:44Z

Capstone issue again? Is there a test?

On 07 Dec 2015, at 14:21, Maijin [email protected] wrote:

@XVilka looks like the

ljmp 0xf000:0xffaa ;[1]
Regressed again, it needs a test definitely, see the result of $j =>

[f000:fff0]> ? $j
61440 0xf000 0170000 60K 0000:0000 61440 00000000 61440.0 0.000000f 0.000000
[f000:fff0]>
—
Reply to this email directly or view it on GitHub.

Maijin · 2015-12-10T21:37:02Z

@radare
https://github.com/radare/radare2-regressions/commit/be31f7ecb39d6726fcaca01b99847f89d9199176

radare · 2016-10-27T11:07:39Z

is this still an issue? is this a capstone bug?

radare · 2016-10-27T11:10:36Z

Moving to 9999 release because i guess capstone will never fix this

Maijin · 2016-10-28T19:30:03Z

And no that's not fixed in r2 patch see the broken test

radare closed this as completed Nov 22, 2012

radare modified the milestones: 1.0.0, 0.9.9 May 20, 2015

Maijin added the has-test label Dec 31, 2015

radare modified the milestones: 9999, 1.0.0 Oct 27, 2016

Maijin mentioned this issue Nov 5, 2016

Fix ljmp with immediate segment:offset #6125

Merged

Maijin closed this as completed Nov 5, 2016

radare mentioned this issue Jan 16, 2017

0x00007fdf5d136cb5 in r_io_seek #6516

Closed

radare mentioned this issue Mar 7, 2017

Segfault on graph display for MIPS #6937

Closed

radare mentioned this issue Mar 21, 2017

Segfault when saving large projects (sort stack exhaustion) #7079

Closed

radare mentioned this issue Aug 22, 2017

radare2 - 'wa' failed to assemble x64 opcode #8251

Closed

radare mentioned this issue Oct 7, 2018

Saving a binary after analysis freezes R2 #11098

Closed

radare mentioned this issue Apr 8, 2019

Segmentation fault with R in graph view #13653

Closed

yossizap pushed a commit to yossizap/radare2 that referenced this issue Dec 30, 2019

Improved exit dialog. Fixes radareorg#36

f20033e

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

wrong analysis of 16bit jumps #36

wrong analysis of 16bit jumps #36

XVilka commented Nov 20, 2012 •

edited by jvoisin

Loading

radare commented Nov 20, 2012

XVilka commented Nov 20, 2012

radare commented Nov 22, 2012

XVilka commented Nov 10, 2014

XVilka commented Nov 10, 2014

radare commented Nov 10, 2014

radare commented Nov 10, 2014

radare commented Nov 10, 2014

XVilka commented Nov 10, 2014

radare commented Nov 10, 2014

XVilka commented Apr 10, 2015

radare commented Apr 11, 2015

radare commented May 20, 2015

jvoisin commented Sep 1, 2015

radare commented Sep 1, 2015

Maijin commented Dec 7, 2015

radare commented Dec 8, 2015

Maijin commented Dec 10, 2015

radare commented Oct 27, 2016

radare commented Oct 27, 2016

Maijin commented Oct 28, 2016

wrong analysis of 16bit jumps #36

wrong analysis of 16bit jumps #36

Comments

XVilka commented Nov 20, 2012 • edited by jvoisin Loading

radare commented Nov 20, 2012

XVilka commented Nov 20, 2012

radare commented Nov 22, 2012

XVilka commented Nov 10, 2014

XVilka commented Nov 10, 2014

radare commented Nov 10, 2014

radare commented Nov 10, 2014

radare commented Nov 10, 2014

XVilka commented Nov 10, 2014

radare commented Nov 10, 2014

XVilka commented Apr 10, 2015

radare commented Apr 11, 2015

radare commented May 20, 2015

jvoisin commented Sep 1, 2015

radare commented Sep 1, 2015

Maijin commented Dec 7, 2015

radare commented Dec 8, 2015

Maijin commented Dec 10, 2015

radare commented Oct 27, 2016

radare commented Oct 27, 2016

Maijin commented Oct 28, 2016

XVilka commented Nov 20, 2012 •

edited by jvoisin

Loading