About RIP relative addressing

 

Something that everyone wonders about is RIP relative addressing on x64 systems.  It's the default addressing mode in 64-bit programs.

RIP relative addressing basicly means that you access memory relative to the RIP register (or relative to EIP if the 32-bit address override operand is used).

All the bugs mentioned in this article regarding ml64.exe are for version 8.00.2207, I don't know about other versions. The latest version I tried is 8.00.50215.44 and that version does not contains the bugs mentioned.

When reading this article I'm assuming you already know about assembler programming, this article isn't for beginners as I'm assuming some knowledge.

NOTE: the author of diStorm64 notified me about a (rather serious) error on this page, I hereby want to thank him :)

---

• How RIP/EIP relative addressing works in 32-bit mode
• How RIP/EIP relative addressing works in 64-bit mode
• About useless operands in 64-bit mode
• Absolutive addressing in 64-bit mode

• RIP/EIP-relative addressing in ML64

• RIP/EIP-relative addressing in FASM

• RIP/EIP-relative addressing in YASM
• A test program showing the old technique versus the new technique of obtaing the current value of RIP (EIP)
• A test program that modifies the next instruction using RIP-relative addressing
• Extra: Another bug in ML64

---

How RIP/EIP relative addressing works in 32-bit mode

In 32-bit programs you can't do this :

mov al, [eip]

But you will have to do something like this instead :

call $ + 5 pop ebx add ebx, 1 + 1 + 1 + 1 ; POP + ADD + ModRM + imm8 mov al, [ebx] ; EBX is now pointing to this instruction!

---

How RIP/EIP relative addressing works in 64-bit mode

In 64-bit programs you are allowed to write this :

mov al, [rip]

NOTE: ML64 is stupid and doesn't allow you to write the above code sample!

; New method mov ah, [rip] ; RIP points to the next instruction aka NOP nop ; Alternative new method lea rbx, [rip] ; RBX now points to the next instruction nop cmp byte ptr [rbx], 90h ; Should be equal! ; Old method (using 64-bit addressing!) call $ + 5 ; A 64-bit call instruction is still 5 bytes wide! pop rbx add rbx, 5 ; RBX now points to the next instruction aka NOP nop mov al, [rbx] ; AH and AL should now be equal :) cmp ah, al

It's also nice to note that the RIP is actualy pointing to the end of the instruction, so RIP will always point to the same offset regarding of how many (useless) operands you added before the opcode.

---

About useless operands in 64-bit mode

I hope you know what operands, opcodes etc. are :).

In 64-bit mode the segment operands are ignored and if you encode multiple REX bytes (see the AMD64/EM64T manuals) only the last REX byte is taken into account, so if you write a disassembler or if you are writing a program to emulate/protect/encrypt 64-bit executables, you need to take this behaviour into account.  The maximum size of an instruction taking all operand etc into account is 15 bytes (atleast that's what I read in the AMD64 programmer's manual).

---

Absolutive addressing in 64-bit mode

Absolute addressing was not supported in older ml64 versions, in the latest version I tried (8.00.50215.44) , it worked correctly! :

inc byte ptr [1000h] ; did not work in older ml64 versions!

You had to write this to obtain the same result :

xor rax, rax inc byte ptr [rax + 1000h]

Due to a bug, older versions of ML64 did not assemble this instruction correctly :

mov eax, [0] ; Stupid ML64 misassembles this instruction!

---

RIP/EIP-relative addressing in ML64

I've got bad news for you, ML64, Microsoft's Macro Assembler for x64 systems, does not give us full control over RIP relative addressing.  We can't use RIP nor EIP as a parameter in an address reference.

Instead, when we access a variable then the linker will convert it to RIP relative addressing automaticly.  This means that if you write two times the same instruction that at the binary level it will not be exactly the same :

mov eax, mytest ; 8B 05 32 20 00 00 mov eax, mytest ; 8B 05 2C 20 00 00 ret ; C3 mytest dd ?

NOTE: the actualy binary output will differ from the value of RIP at link time and the location of "test" in memory at link time

---

RIP/EIP-relative addressing in FASM

I've got good news!  You can use RIP relative addressing with flat assembler.

---

RIP/EIP-relative addressing in YASM

I've got good news!  You can use RIP relative addressing with YASM.

---

A test program showing the old technique versus the new technique of obtaing the current value of RIP (EIP)

I wrote the following test program which will check if the next instruction is a "nop", if RIP is obtained correctly than it will point to this "nop" instruction.   I had to hardcode some instructions because my version of ML64 does not support the usage of RIP manually (!) (Zipped source code plus executable) :

extrn MessageBoxA: PROC extrn ExitProcess: PROC .data testok db 'RIP based addressing worked!', 0 testfail db 'RIP based addressing failed at test ' testcode db '0' db '!', 0 testtitle db 'RIP based addressing test by Fibergeek', 0 .code public Main Main: ; Put the value of the NOP opcode in R8B mov r8b, 90h ; Assume that the test failed lea rax, testfail ; Test 1 ; NOTE: i'm hardcoding this instruction because of ML64 inc testcode ; cmp [rip], r8b : DB 44h, 38h, 05h, 00h, 00h, 00h, 00h nop jne done ; Test 2 ; NOTE: i'm hardcoding this instruction because of ML64 inc testcode ; lea rbx, [rip] : DB 48h, 8Dh, 1Dh, 00h, 00h, 00h, 00h nop cmp [rbx], r8b jne done ; Test 3 inc testcode call $ + 5 nop pop rbx cmp [rbx], r8b jne done ; Test 4 inc testcode call $ + 5 pop rbx add rbx, 1 + 1 + 2 + 1 ; 1=POP, 1=REX, 2=ADD, 1=imm8 nop cmp [rbx], r8b jne done ; All tests succeeded lea rax, testok done: ; Display the result and exit the program mov r9d, 0 ; R9D = UINT uType lea r8, testtitle ; R8 = LPCTSTR lpCaption mov rdx, rax ; RDX = LPCSTR lpText mov rcx, 0 ; RCX = HWND hWnd call MessageBoxA mov ecx, eax ; ECX = UINT uExitCode call ExitProcess ; Just in case :) ret END

In order the compile this program, you need to invoke ml64 like this :

ml64 XXX.asm /link /subsystem:windows /defaultlib:kernel32.lib /defaultlib:user32.lib

(assuming kernel32.lib and user32.lib reside in the same directory as ml64.exe)

and

(where XXX is the name of your assembly file)
 

---

A test program that modifies the next instruction using RIP-relative addressing

I wrote the following test program which will modify the next instruction (Zipped source code plus executable), this program needs ML64 :

extrn VirtualProtect: PROC extrn MessageBoxA: PROC extrn ExitProcess: PROC .data testok db 'RIP based addressing worked!', 0 testfail db 'RIP based addressing didn''t work!', 0 testtitle db 'Written by Fibergeek', 0 oldprotect dd ? .code public Main Main: ; We first need to make this page writeable lea r9, oldprotect ; R9 = lpflOldProtect mov r8d, 40h ; R8D = flNewProtect mov rdx, 1 ; RDX = dwSize lea rcx, InXorInstruction ; RCX = lpAddress call VirtualProtect ; Ensure that the used registers for the test are setup mov eax, 0 mov ecx, -1 ; This is the test, we will increment C0 with one ; OR EAX, EAX will become OR EAX, ECX ; ML64 will use RIP relative addressing! inc InXorInstruction XorInstruction DB 00Bh ; 0BC0 = or eax, eax InXorInstruction DB 0C0h ; Store in RAX the correct display text ; If EAX still is 0 than the test failed! or eax, eax lea rax, testfail jz skip lea rax, testok skip: ; Display the result and exit the program mov r9d, 0 ; R9D = UINT uType lea r8, testtitle ; R8 = LPCTSTR lpCaption mov rdx, rax ; RDX = LPCSTR lpText mov rcx, 0 ; RCX = HWND hWnd call MessageBoxA mov ecx, eax ; ECX = UINT uExitCode call ExitProcess ; Just in case :) ret END

In order the compile this program, you need to invoke ml64 like this :

ml64 XXX.asm /link /subsystem:windows /defaultlib:kernel32.lib /defaultlib:user32.lib /entry:Main

(assuming kernel32.lib and user32.lib reside in the same directory as ml64.exe)

and

(where XXX is the name of your assembly file)
 

---

Extra: Another bug in ML64

NOTE: this bug no longer exists in newer ML64 versions!

While testing the possibilites of ML64 I found another bug : ML64 allowed you to enter 16-bit addressing instructions but when you execute them, they will actually be executed as their 32-bit variants, for example :

mov [bx], eax

is at the binary level exactly the same as :

mov [edi], eax