內核漏洞的shellcode

-1

我想寫的32位Linux的shellcode內核模式將做到這一點：內核漏洞的shellcode

commit_creds (prepare_kernel_cred(0));

所以我創建一個文件：

xor eax, eax 
call 0x1234567 
call 0x1234568 
ret

哪裏0x1234567是地址prepare_kernel_cred和0x1234568是commit_creds的地址，都可以從/ proc/kallsyms中找到。

我用nasm -f elf和objdump -d來組裝它以獲取機器碼。

我得到的是這樣的：

31 c0    which is xor eax, eax 
e8 7c 67 06 c1  which is call prepare_kernel_cred 
e8 7c 65 06 c1  which is call commit_creds 
c3     which is ret

這是行不通的。但是，使用e8 79而不是e8 7c和e8 74而不是第二個e8 7c工作。我不記得我從哪裏得到第二個機器代碼（我在不同的文件中），但我很好奇爲什麼這會起作用，而不是簡單地將它組裝起來就像那樣工作。

是什麼類型的CALL是這樣的？爲什麼它不能像上面顯示的那樣簡單地組裝代碼？如果我使用e8 79和e8 74作爲CALL，我的玩具漏洞對我的人造內核錯誤工作正常，但是當我使用來自nasm/objdump的組合機器代碼時失敗。

來源

2013-02-19 ioctlvoid

以E8h開頭的CALL變體接近調用相對於當前指令的位移指定的地址。這就解釋了爲什麼這些值需要根據不同的指令而有所不同。不過，我對你如何讓nasm發佈代碼感到茫然。你確定這不是作業嗎？

來源

2013-02-19 05:17:01

謝謝。不，這不是功課。我只是試圖讓自己的玩具利用我自己的內核（空指針解引用）。如果我組裝「調用0xc1066480」和「調用0xc1066380」，我就可以在它們兩個上獲得e8 7c。（.m文件中的nasm -f elf，objdump -d）。 – ioctlvoid 2013-02-19 15:51:04

我發現，我用下面的命令之前，編譯如下：

gcc -m32 -Ttext=0 -nostdlib

這給了我同樣的結果，因爲我從以前了。我也得到一個警告，它默認從0x0開始。

但是爲什麼nasm沒有重現這個呢？我用objdump進行了檢查，兩個文件中的起始地址似乎都是0x0。

來源

2013-02-19 16:35:51 ioctlvoid

內核漏洞的shellcode

回答

相關問題