"ao" command doesn't respect the "asm.bits" setting

[begoon]

[0x00000100]> e asm.bits
16
[0x00000100]> pd 1
      0x00000100      e9010f           jmp word 0x1004
[0x00000100]> ao 5
addr: 0x00000100
size: 5
type: 1 (jmp)
eob: 1
jump: 0xffffffffc9341006
fail: 0xffffffffffffffff
stack: 0
cond: 0
family: 0

So, "pd 1" reports that the opcode length is 3 (which is correct), but "ao 5" says "size: 5". Maybe it interprets it in 32-bit mode instead of 16-bit.

I'm testing on:

./bin/r2 -v
radare2 0.9.1git @ darwin-little-x86-64 build 2012-09-24
commit: 757d692e19d6ebb7a31d301e8f5405e5120e6b83

[radare]

The problem is that the anal plugin was only for 32 and 64.

We are using udis86 to disassemble and x86im to analyze.

I have pushed a commit that does some more work in anal.plugin=x86.udis86 and also added a hack on top of the default analysis of 32bits to fix that 16bit analysis.

Let me know if you find more oplen issues on 16bits.

The plan is to work on code analysis internals for the next release.

We should use the udis86 info for 16bits. But i dont think we can get a full implementation of the code analysis information.

We need more test cases also.

Thanks!

On Sep 24, 2012, at 20:33, Alexander [email protected] wrote:

[0x00000100]> e asm.bits
16
[0x00000100]> pd 1
0x00000100 e9010f jmp word 0x1004
[0x00000100]> ao 5
addr: 0x00000100
size: 5
type: 1 (jmp)
eob: 1
jump: 0xffffffffc9341006
fail: 0xffffffffffffffff
stack: 0
cond: 0
family: 0
So, "pd 1" reports that the opcode length is 3 (which is correct), but "ao 5" says "size: 5". Maybe it interprets it in 32-bit mode instead of 16-bit.

I'm testing on:

./bin/r2 -v
radare2 0.9.1git @ darwin-little-x86-64 build 2012-09-24
commit: 757d692
—
Reply to this email directly or view it on GitHub.

[begoon]

Thanks for the quick update, but seems the patch isn't quite full. Even if the instruction in the 16-bit mode is 3 byte long, only "ao 5" shows it, along with a bit of the following one, for some reason.

[0x00000100]> pd 1
      0x00000100      e9010f           jmp word 0x1004

[0x00000100]> ao 3
Oops at 0x00000100 (e9 01 0f ...)
[0x00000100]> ao 4
Oops at 0x00000100 (e9 01 0f ...)
[0x00000100]> ao 5
addr: 0x00000100
size: 3
type: 1 (jmp)
eob: 1
jump: 0x00001004
fail: 0xffffffffffffffff
stack: 0
cond: 0
family: 0

addr: 0x00000103
size: 2
type: 67108864 (xor)
eob: 0
jump: 0xffffffffffffffff
fail: 0xffffffffffffffff
stack: 0
cond: 0
family: 0

[radare]

I have written a test case for this issue, I will look at it tonight or
tomorrow.

see:
https://github.com/vext01/r2-regressions/commit/566b66e5312dc3568a67826e6ad32dd81e220c6a

Thanks

On 09/25/12 14:02, Alexander wrote:

Thanks for the quick update, but seems the patch isn't quite full.
Even if the instruction in the 16-bit mode is 3 byte long, only "ao 5"
shows it, along with a bit of the following one, for some reason.

|[0x00000100]> pd 1
0x00000100 e9010f jmp word 0x1004

[0x00000100]> ao 3
Oops at 0x00000100 (e9 01 0f ...)
[0x00000100]> ao 4
Oops at 0x00000100 (e9 01 0f ...)
[0x00000100]> ao 5
addr: 0x00000100
size: 3
type: 1 (jmp)
eob: 1
jump: 0x00001004
fail: 0xffffffffffffffff
stack: 0
cond: 0
family: 0

addr: 0x00000103
size: 2
type: 67108864 (xor)
eob: 0
jump: 0xffffffffffffffff
fail: 0xffffffffffffffff
stack: 0
cond: 0
family: 0
|

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

[radare]

It should be fixed now. Can you test again?

[begoon]

Works, thanks.