📚 OpenRCE is preserved as a read-only archive. Launched at RECon Montreal in 2005. Registration and posting are disabled.








Flag: Tornado! Hurricane!

Blogs >> trufae's Blog

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: 3702

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



Add New Comment
Comment:









There are 31,328 total registered users.


Recently Created Topics
[help] Unpacking VMP...
Mar/12
Reverse Engineering ...
Jul/06
let 'IDAPython' impo...
Sep/24
set 'IDAPython' as t...
Sep/24
GuessType return une...
Sep/20
About retrieving the...
Sep/07
How to find specific...
Aug/15
How to get data depe...
Jul/07
Identify RVA data in...
May/06
Question about memor...
Dec/12


Recent Forum Posts
Finding the procedur...
rolEYder
Question about debbu...
rolEYder
Identify RVA data in...
sohlow
let 'IDAPython' impo...
sohlow
How to find specific...
hackgreti
Problem with ollydbg
sh3dow
How can I write olly...
sh3dow
New LoadMAP plugin v...
mefisto...
Intel pin in loaded ...
djnemo
OOP_RE tool available?
Bl4ckm4n


Recent Blog Entries
halsten
Mar/14
Breaking IonCUBE VM

oleavr
Oct/24
Anatomy of a code tracer

hasherezade
Sep/24
IAT Patcher - new tool for ...

oleavr
Aug/27
CryptoShark: code tracer ba...

oleavr
Jun/25
Build a debugger in 5 minutes

More ...


Recent Blog Comments
nieo on:
Mar/22
IAT Patcher - new tool for ...

djnemo on:
Nov/17
Kernel debugger vs user mod...

acel on:
Nov/14
Kernel debugger vs user mod...

pedram on:
Dec/21
frida.github.io: scriptable...

capadleman on:
Jun/19
Using NtCreateThreadEx for ...

More ...


Imagery
SoySauce Blueprint
Jun 6, 2008

[+] expand

View Gallery (11) / Submit