Today I was happy to see how radare was able to disassemble and debug the 0F 1X XX opcodes and ida/olly does not.
This is a HARD bug on their software, so malware can use this opcode to fool the code analysis and break the debugging of certain parts of the program. Parts of code that are executed but cannot be stepped or continued with breakpoints because none of them can properly calculate the length of this opcode (they say that this opcode is 2 bytes and it is an unknown one. objdump fails like olly or ida, but not udi86. The choosed disassembly library for x86 on radare. The disassembly of this opcode is: > s eip && wx 0f1900 && pD 20 0xB7FBF8C0 eip: 0xB7FBF8C0 0f1900 nop [eax] uh..strange one... a nop that acts on the value pointed by eax? Here's the patch to fix objdump: http://sourceware.org/ml/binutils/2006-06/msg00157.html Intel make 't official the past year: http://softwarecommunity.intel.com/isn/Community/en-US/forums/thread/980709.aspx Opcodes 0F 18 through 0F 1F are hinting NOPs reserved for future use. On older cpu's in throws an excepction coz it's not a valid instruction. Symantec says: http://www.symantec.com/enterprise/security_response/weblog/2007/02/x86_fetchdecode_anomalies.html "Finally, 0f 1f (multi-byte NOP) is also undocumentedly fully allocated. Interestingly, despite its name, it does access memory if the Mod/RM byte tells it to, so this "No OPeration" can cause page faults. Not quite a NOP after all." I can't understand why intel can make this kind of insane opcodes become official. A nop with conditional trap...I think that actually some packers take care of this to change the program flow by handling these exceptions ;) A runtime program should check for cpuid to know if this instruction is or not supported by the cpu. --pancake _______________________________________________ radare mailing list [email protected] https://lists.nopcode.org/mailman/listinfo/radare
