Afgedankte code

EN NL TR

Het vorige fragment

De fragmentenindex

Het volgende fragment

Iets dat iedereen interesseert is de nieuwe RIP-relatieve adresseringsmodus van de x64-systemen.  Het is de default-adresseringsmode van 64-bit programma's.

RIP-relatieve adresering houdt in dat je geheugen aanspreekt relatief ten opzichte van het RIP-register (of relatief van EIP indien de 32-adresseringsoperand gebruikt werd).

Alle bugs die gaan over ml64.exe zijn voor versie 8.00.2207, Ik heb geen weet van andere versies.  De laatste versie die ik geprobeerd heb is versie 8.00.50215.44 en die heeft de beschreven foutjes niet.

Ik ga er vanuit dat je kennis hebt van assemblerprogrammatie, dit artikel is niet echt voor beginnelingen.

NOTA: de auteur van diStorm64 heeft me op een (nogal zware) fout gewezen in dit artikel, ik wil hem langs deze weg nogmaals bedanken :)

• Hoe RIP/EIP-relatieve adressering werkt in 32-bit-mode
• Hoe RIP/EIP-relatieve adressering werkt in 64-bit-mode
• In verband met nuteloze operands in 64-bit-mode
• Absolute adressing in 64-bit-mode

• RIP/EIP-relatieve adressing in ML64

• RIP/EIP-relatieve adressing in FASM

• RIP/EIP-relatieve adressing in YASM
• Een testprogramma dat de oude en nieuwe techniek van het bekomen van RIP (EIP) demonstreert
• Een testprogramma dat de volgende instructie wijzigt via RIP-relatieve adressering
• Extra: Een andere bug in ML64

Hoe RIP/EIP relatieve adressering werkt in 32-bit-mode

In 32-bit-programma's kan je dit niet doen :

mov al, [eip]

Je zal iets zoals dit moeten doen :

call $ + 5 pop ebx add ebx, 1 + 1 + 1 + 1 ; POP + ADD + ModRM + imm8 mov al, [ebx] ; EBX verwijst nu naar de volgende instructie!

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

In 64-bit-programma's kan je dit wel schrijven :

mov al, [rip]

NOTA: ML64 is dom en laat ons niet toe het bovenstaande te schrijven!

; Nieuwe methode mov ah, [rip] ; RIP verwijst nu naar de volgende instructie aka NOP nop ; Alternatieve nieuwe methode lea rbx, [rip] ; RBX verwijst nu naar de volgende instructie nop cmp byte ptr [rbx], 90h ; Zou gelijk moeten zijn! ; Oude methode (gebruik makende van 64-bit-adressering!) call $ + 5 ; Een 64-bit-call-instructie is nog steeds 5 bytes! pop rbx add rbx, 5 ; RBX wijst nu naar de volgende instructie aka NOP nop mov al, [rbx] ; AH en AL zouden nu gelijk moeten zijn :) cmp ah, al

Het is ook leuk om te weten dat RIP in feite naar het einde van de huidige instructie wijst, dus RIP zal altijd naar de volgende offset wijzen ongeacht het aantal (nuteloze) operands je aan de opcode hebt toegevoegd.

In verband met nuteloze 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).

Absolute adressering in 64-bit-mode

Absolute adressering was niet geïmplementeerd in de oudere versies van ml64.  De laatste versie (8.00.50215.44) die ik geprobeerd heb, deed het wel! :

inc byte ptr [1000h] ; werkte niet in oudere ml64-versies!

Je moest dit schrijven om het zelfde resultaat te bekomen :

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

Door een bug assembleerden oudere versies van ML64 dit niet correct :

mov eax, [0] ; Domme ML64 misasembleert deze instructie!

RIP/EIP-relatieve adressering in ML64

Ik heb slecht nieuws, ML64, Microsoft's Macro Assembler voor x64-systemen, geeft ons geen volledige controle over RIP-relatieve adressering.  We kunnen noch RIP, noch EIP gebruik als een parameter in een adressering.

Maar, als we een variable gebruiken dan zal de linker dit automatisch naar een RIP-relatieve adressering omzetten.  Dit houdt in dat als je tweemaal dezelfde instructie schrijft, deze binair niet hetzelfde zal zijn :

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

NOTA: de actuele binaire uitvoer hangt af van de locatie van de code en van de locatie van de variable "test" tijdens het linken.

RIP/EIP-relatieve adressering in FASM

Good nieuws!  RIP-relatieve adressering werkt met flat assembler.

RIP/EIP-relative addressing in YASM

Good nieuws!  RIP-relatieve adressering werkt met YASM.

Een testprogramma dat de oude en nieuwe techniek van het bekomen van RIP (EIP) demonstreert

Ik heb volgende testprogramma geschreven dat zal nakijken of de volgende instructie een "nop" is, als RIP correct bekomen werd dan zal het verwijzen naar deze "nop"-instructie.  Ik heb sommige instructies moeten hardcoden omdat ML64 het manueel gebruik van RIP niet ondersteund (!) (Gezipte broncode en executable) :

extrn MessageBoxA: PROC extrn ExitProcess: PROC .data testok db 'RIP-gebaseerde adressering werkt!', 0 testfail db 'RIP-gebaseerde adressering faalde bij test ' testcode db '0' db '!', 0 testtitle db 'RIP-gebaseerde adressingstest door Fibergeek', 0 .code public Main Main: ; Plaats de waarde van een NOP in R8B mov r8b, 90h ; Ga er vanuit dat de test faalt lea rax, testfail ; Test 1 ; NOTA: hardcoding vanwege ML64's bug inc testcode ; cmp [rip], r8b : DB 44h, 38h, 05h, 00h, 00h, 00h, 00h nop jne klaar ; Test 2 ; NOTA: hardcoding vanwege ML64's bug inc testcode ; lea rbx, [rip] : DB 48h, 8Dh, 1Dh, 00h, 00h, 00h, 00h nop cmp [rbx], r8b jne klaar ; Test 3 inc testcode call $ + 5 nop pop rbx cmp [rbx], r8b jne klaar ; 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 klaar ; Alles geslaagd lea rax, testok klaar: ; Geef het resultaat weer en sluit af 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 ; In geval van :) ret END

Om deze source code in iets uitvoerbaar te toveren doe je :

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

(er vanuit gaande dat kernel32.lib en user32.lib in dezelfde directory staan als ml64.exe)

en

(waar XXX de naam is van het assemblerbestand)
 

Een testprogramma dat de volgende instructie wijzigt via RIP-relatieve adressering

Ik heb onderstaande testprogramma  geschreven om het aanpassen van de volgende instructie via RIP te demonstreren (Gezipte broncode en executable), dit programma vereist ML64 :

extrn VirtualProtect: PROC extrn MessageBoxA: PROC extrn ExitProcess: PROC .data testok db 'RIP-gebaseerde adressering werkt!', 0 testfail db 'RIP-gebaseerde adressering werkt niet!', 0 testtitle db 'Geschreven door Fibergeek', 0 oldprotect dd ? .code public Main Main: ; Eerst maken we deze codepagina schrijfbaar lea r9, oldprotect ; R9 = lpflOldProtect mov r8d, 40h ; R8D = flNewProtect mov rdx, 1 ; RDX = dwSize lea rcx, InXorInstruction ; RCX = lpAddress call VirtualProtect ; Bereid de test voor mov eax, 0 mov ecx, -1 ; Dit is de test, we zullen C0 verhogen met een ; OR EAX, EAX zal OR EAX, ECX worden ; ML64 zal RIP-relatieve adressing gebruiken! inc InXorInstruction XorInstruction DB 00Bh ; 0BC0 = or eax, eax InXorInstruction DB 0C0h ; Plaats in RAX de weer te geven tekst ; Als EAX nog altijd 0 is, dan faalde de test! or eax, eax lea rax, testfail jz skip lea rax, testok skip: ; Geef het resultaat weer en sluit af 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 ; In geval van :) ret END

Om dit programma te compileren en te linken start je ml64 als volgt :

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

(er vanuit gaande dat kernel32.lib en user32.lib in dezelfde directory staan als ml64.exe)

en

(waar XXX de naam is van het assemblerbestand)
 

Extra: Een andere bug in ML64

NOTA: deze bug komt niet langer voor in de nieuwere ML64-versies!

Tijdens het testen van ML64 had ik nog een bug gevonden : : ML64 liet ons toe 16-bit adressering-instructies in te voeren maar ze werden wel uitgevoerd door hun binaire overeenkomende 32-bit instructies, bijvoorbeeld :

mov [bx], eax

is binair hetzelfde als :

mov [edi], eax

Het vorige fragment

De fragmentenindex

Het volgende fragment