Nibble has sent me a patch for updating udis86 to 1.7 (the last version), and seems that stills giving the same translation for this opcode.
I understand that the translation is correct, but the representation can be ambiguous because there's no named 8bit register for SP/ESP, but I think that for a correct translation the disassembler should expand the value to fit with the register size or "cast it" to byte. but this last options sounds weird to me. I will ping Vivek Mohan (the author of udis86) to resolve this issue. Btw you can also try to use the olly disassembler as backend for x86. This can be enabled by setting: e asm.syntax=olly The problem is that looks a bit broken, but the nice thing is that it resolves the 83 e4 0f to "AND ESP,FFFFFFF0". Feel free to have a look on the sources to fix the problems with the olly disassembler. Thanks for the pr! :) --pancake On Sat, 15 Nov 2008 22:03:39 -0500 "Evan Teran" <[EMAIL PROTECTED]> wrote: > I wouldn't call the 0x0f thing a bug. It is a byte oriented op which > only effects the LSB of the operand. So the disassembly is technically > correct IMO. > > On Sat, Nov 15, 2008 at 9:11 PM, pancake <[EMAIL PROTECTED]> wrote: > >> Finally I decided to spend some time playing with radare :) This was > >> on my TODO for a long time. > >> > >> Anyway, I have a few notes after some short usage time: > >> > >> 1) Building from sources using ACR (i.e. ./configure ... ; make) > >> always fails on my Ubuntu (Hardy) system while compiling grava (it > >> cannot find some GTK headers and also some GUI headers, even though I > >> used --without-gui in configure). I had to fiddle with CFLAGS to make > >> it build properly. > > > > Mmh, do you have vte-dev and gtk-dev ? there are no more dependencies for > > the gui. But i will have to drop the vte dependency probably. > > > > Can you provide me some feedback of the errors? I had no problems with > > any of my boxes :/ > > > >> 2) I tried a simple session with /bin/ls. Steps followed: > >> > >> - set .radarerc to: > >> > >> eval scr.color = true > >> eval asm.syntax = intel > >> eval file.analyze = true > >> eval file.id = true > >> eval file.flag = true > > > > its ok > > > >> - start radare with "radare /bin/ls" > >> - disassemble with "pd". Here are the first lines of what I get: > >> ; [13] 0x08049a80 size=00066748 align=0x00000010 r-x .text > >> .......... > >> > >> Note the instruction at 0x08049A85. While on radare it translates to > >> "and esp, 0xf0", on objdump (and HT) it is "and esp,0xfffffff0". > >> Also note the instruction at 0x08049A9C. While on radare it is "call > >> 0x8049635", on objdump/HT, it is "call 0x8049630". > > > > Yeah the 0xf0 is a bug reported in TODO. But I'm now investigating about the > > source of this problem in udis86, I will hopefully push a fix for this > > before monday.. but upgrading udis86 doesnt seems to be easy. And we should > > probably need to wait for the upcomming "libr" to handle this properly. > > > > These bugs will force me to release a 1.1 :) > > > > The call bug it is fixed in the mercurial repo (thanks Nibble for the fast > > response :) > > > >> I'm using radare 1.0. > >> > >> Keep up the good work! > > > > Thanks for the feedback! Nibble is looking to fix these bugs, and I hope to > > have the 0xf0 bug fixed soon. Let see if its fixed in udis-1.7 or it was > > just > > a bug in my integration or what the fuck :) > > > > I have uploaded a new snapshot at > > http://www.radare.org/get/radare-20081116.tar.gz > > > > But I recommend you to always check from the mercurial repository. > > > > Enjoy! > > > > --pancake > > _______________________________________________ > > radare mailing list > > [email protected] > > http://lists.nopcode.org/listinfo.cgi/radare-nopcode.org > > > _______________________________________________ > radare mailing list > [email protected] > http://lists.nopcode.org/listinfo.cgi/radare-nopcode.org > --pancake _______________________________________________ radare mailing list [email protected] http://lists.nopcode.org/listinfo.cgi/radare-nopcode.org
