OpenRCE

About Articles Book Store Distributed RCE Downloads Event Calendar Forums Live Discussion Reference Library RSS Feeds Search Users What's New

Customize Theme

Flag: Tornado! Hurricane!

Created: Wednesday, April 9 2008 04:52.08 CDT Modified: Wednesday, April 9 2008 04:58.22 CDT

Printer Friendly ...

Another incorrect disassembly

Author: trufae

# Views: 3054

A friend of me which is working on a fpu-based crackme noticed a slighty operational difference, where the same opcode performs two different results with the same values...

Oops! different bytes producing the same opcode?

This bug happened to be a bug in many disassemblers like the one in ollydbg, IDA or udis86 (which I use in radare).

I get some interest on the problem and started to play a bit with radare:

Using objdump-based disassembler:



; Write the 4 bytes

[0x00000000]> wx dcc0 d8c0



; Disassembly using udis86

[0x00000000]> pD 4

 0x00000000           dcc0            fadd st0, st0           

 0x00000002           d8c0            fadd st0, st0  



; Using objdump-based disassembler:

[0x00000000]> pd 4

   0:   dc c0                   fadd   st(0),st

   2:   d8 c0                   fadd   st,st(0)

Having a closer look to the x86 specs:



 D8 		0 		FADD 	ST 	m32real

 DC 		0 		FADD 	ST 	m64real

 DC 		0 		FADD 	STi 	ST

So, looks like d8 opcode is for 32 bits and the 'dc' one for 64 bits, so the result of the operation differs by the precission.

I have notified the udis86 to fix the problem. And I plan to have this fixed in radare today.

Have fun

Blog Comments

igorsk	Posted: Wednesday, April 9 2008 06:41.05 CDT
I wouldn't be too hasty. Let's check in Windbg. `dcc0 fadd st(0),st d8c0 fadd st,st(0)` This page agrees too: http://www.ews.uiuc.edu/~cjiang/reference/vc83.htm

trufae Posted: Wednesday, April 9 2008 10:08.22 CDT

You are right. these opcodes have nothing to do with the m32/m64 stuff. I was a bit hasty ;)

I think that windbg and gnu binutils are performing the result properly.

But ST == ST(0), and the result differs by precission, so the most logical reply is that it is a bug in the FPU (in my current box. both operations perform the same result +6.283185307179586477). but in another one does not :/



.global main

.text

main:

        fldpi

.byte 0xdc, 0xc0   // fadd %st(0), %st

        int3

        fldpi

.byte 0xd8, 0xc0   // fadd %st, %st(0)

        int3

A funny bug :)

MazeGen	Posted: Thursday, April 10 2008 03:04.57 CDT
Just a bit of advertisement: You can point to that opcodes directly and use coder32 edition, which is clearer at first sight: http://ref.x86asm.net/coder32.html#xD8_0 FADD m32real / FADD ST, STi http://ref.x86asm.net/coder32.html#xDC_0 FADD m64real / FADD STi, ST

There are 28,229 total registered users.

Recently Created Topics
Reverse Engineering ...	Jan/23
Career: DoD Agency I...	Jan/22
"Disappearing&q...	Jan/17
Career: Software Sec...	Jan/11
Where is the call st...	Jan/07
IDA Pro 6.1 Breakpoi...	Jan/01
How to create data s...	Dec/30
can i search all mod...	Dec/23
IDA symbol table exp...	Dec/20
An anti-attach trick	Dec/17

Recent Forum Posts
Reverse Engineering ...	NirIzr
"Disappearing&q...	NirIzr
Reverse Engineering ...	charlie
"Disappearing&q...	charlie
An anti-attach trick	Bass
An anti-attach trick	waleeda...
An anti-attach trick	Bass
An anti-attach trick	waleeda...
An anti-attach trick	Bass
Looking for value in...	NirIzr

Recent Blog Entries
	cmathieu	Feb/07
Hacker Carnival
	waleedassar	Feb/06
OllyDbg v1.10 And Hardware ...
	waleedassar	Jan/31
Yet Another Anti-Debug Trick
	RolfRolles	Jan/22
Finding Bugs in VMs with a ...
	waleedassar	Jan/13
An OllyDbg Bug Disables Sof...
More ...

Recent Blog Comments
	waleedassar on:	Feb/07
OllyDbg v1.10 And Hardware ...
	NirIzr on:	Feb/07
OllyDbg v1.10 And Hardware ...
	NirIzr on:	Feb/05
Yet Another Anti-Debug Trick
	trolotou on:	Feb/05
Doudoune Moncler -Pennies F...
	waleedassar on:	Feb/01
Yet Another Anti-Debug Trick
More ...

Imagery

SoySauce Blueprint
Jun 6, 2008

[+] expand

View Gallery (11) / Submit