在組件86 IA-32

Question

我試圖讀取組件的文件（86，IA-32）中讀取文件，我發現這個例子：

mov ebx,eax 
mov al,0x3 
mov edi,esp 
mov ecx,edi 
xor edx,edx 
mov dh,0xff 
mov dl,0xff 
int 0x80 

其中eax中（第一指令）有開放系統調用的返回碼。
有，我還沒有完全瞭解兩兩件事：

1. 爲什麼做mov edi,esp然後mov ecx,edi而不是做直接mov ecx,esp？
2. 爲什麼把0xff和0xff放在edx寄存器裏面？讀系統調用期望count所以在這種情況下的文件大小。

EDIT（完整代碼）：

section .text 

global _start 

_start: 
    ;read the file 
    jmp short call_rw 

rw: 
    push 0x5 
    pop eax 
    pop ebx 
    xor ecx,ecx 
    int 0x80 
    mov ebx,eax 
    mov al,0x3 
    mov edi,esp 
    mov ecx,edi 
    xor edx,edx 
    mov dl,0xff 
    mov dh,0xff 
    int 0x80 
    mov edx,eax 
    push 0x4 
    pop eax 
    mov bl, 0x1 
    int 0x80 
    push 0x1 
    pop eax 
    inc ebx 
    int 0x80 

call_rw: 
    call rw 
    message db "/home/user/file.txt" 

Answer 1

關於第一個問題，我看到一對夫婦的相當明顯的可能性，但問題並沒有包含足夠的信息，以確保這很可能準確。

第一個可能性是，在edi大小被用於在後面的代碼一些其他的目的，所以此舉對edi已經完成了一些有用的東西，但我們不能看到究竟是什麼在這裏，因爲我們不能看到使用它的其他代碼。

另一個明顯的可能性就是它只是一個錯誤。

有幾個不太明顯的可能性，例如mov ecx, edi被用作其他代碼的入口點，所以如果您從該代碼的開始處開始，它使用的值爲esp，但還有其他代碼將一些其他值加載到edi，然後跳轉到mov ecx, edi，從而使用不同的值而不是esp中的值。

還有一些其他的可能性，例如某人基本上插入了一些NOP的等價物（例如）讓一部分代碼與某個邊界對齊，但沒有儘可能多的分心線，就好像它們會寫出NOP（說）5次。

對於第二個問題，0xffff在edx基本上意味着它將從該文件讀取多達65535個字節。他們很可能分配了一個65535字節的緩衝區，所以他們不想在一次調用中讀取更多的數據。

編輯（完成代碼添加到問題後）。好的，現在我們可以看到完整的代碼，我們可以從代碼是（儘可能好的）非常傳統地寫入開始。

他首先跳到call_rw，然後（顯然是不夠）call ing rw從那裏。這會在call_rw之後立即將地址推入堆棧。然後在rw處，他從堆棧中彈出返回值爲ebx。這將message的地址加載到ebx中，然後將其用作下一個系統調用（函數5，它打開文件，期望ebx包含指向文件名稱的指針）的參數。

不好意思，我只想猜測代碼要麼是故意（但相當低效）的混淆嘗試，要麼是內部生成某種面向堆棧的內部代碼的編譯器的結果，然後在將其轉換爲面向註冊的目標代碼方面做了非常糟糕的工作。或者我的第一印象（見下面的腳註）是正確的。

取出克魯夫特後，第一對夫婦的SYS通話摸出這東西一般順序：

; open the file 
mov eax, 5 
mov ebx, offset filename 
xor ecx, ecx 
int 0x80 

; read the file 
mov ebx, eax 
mov eax, 3 
mov ecx, esp 
mov edx, 0xffff 
int 0x80 

很抱歉，但我懶得整理出所有的休息。乍一看，它看起來像進入了一個無限循環（call_rw之前的代碼流入call_rw，再次呼叫rw）。它的一些體操可能會阻止實際發生，但如果沒有一個有說服力的理由來解決這個問題，我就沒有動力去理清這個特定的混亂。

---

1. 我在爲外交在這裏工作真的硬。在修訂之前，這提到了作者是「可認證的精神病患者」。