- } else if ((*p & 0xFB) == 0x48) {
- if (*p & 0x04) {
- /* 0x4C */
- if (*(p + 1) == 0x8D) {
- if ((*(p + 2) & 0x7) == 0x5) {
- /* Load effective address relative (x86_64) */
- opcode_nbytes = 3;
- goto have_opcode;
- }
- }
- } else {
- /* 0x48 */
- if (*(p + 1) == 0x8B) {
- if (*(p + 2) == 0x5 || *(p + 2) == 0xD) {
- /* Load relative (x86_64) */
- opcode_nbytes = 3;
- goto have_opcode;
- }
- } else if (*(p + 1) == 0x8D) {
- if ((*(p + 2) & 0x7) == 0x5) {
- /* Load effective address relative (x86_64) */
- opcode_nbytes = 3;
- goto have_opcode;
- }
+ } else if ((p[0] & 0xFB) == 0x48) {
+
+ /* 0x48 or 0x4C. In 64-bit code this is a REX prefix byte with
+ * W=1, R=[01], X=0, and B=0, and it will be followed by the
+ * actual opcode, then additional bytes depending on the opcode.
+ * We are most interested in several common instructions that
+ * access data relative to the instruction pointer. These use a
+ * 1-byte opcode, followed by a ModR/M byte, followed by a
+ * 4-byte displacement. */
+
+ /* Test: does the ModR/M byte indicate RIP-relative addressing?
+ * Note: there seems to be a mistake in the format here; the
+ * mask really should be 0xC7 instead of 0x07 so that both the
+ * MOD and R/M fields of ModR/M are tested, not just R/M. */
+ if ((p[2] & 0x07) == 0x05) {
+ /* Check for the LEA (load effective address) or MOV
+ * (move) opcodes. For MOV there are additional
+ * restrictions, although it seems they are only helpful
+ * due to the overly lax ModR/M test. */
+ if (p[1] == 0x8D ||
+ (p[1] == 0x8B && !(p[0] & 0x04) && !(p[2] & 0xF0)))
+ {
+ opcode_nbytes = 3;
+ goto have_opcode;