在前面編寫Shellcode的過程中，我們用到的字符串要么直接使用DB定義，要么通過PUSH直接壓入棧上（相當(dāng)于定義局部變量），這樣的話，如果一個(gè)Shellcode中的字符串多一點(diǎn)的話，僅字符串就要占用不少空間。而且，在1.7節(jié)中，我們在kernel32.dll的導(dǎo)出表中查找函數(shù)名稱的時(shí)候，有一個(gè)字符串比較的過程，要將我們指定的函數(shù)名（如LoadLibraryA）與導(dǎo)出表中的函數(shù)名比較，這樣一方面我們要保存需要查找的函數(shù)名，另一方面比較字符串占用了比較多的代碼。還有，字符串問題會(huì)有前面的NULL字節(jié)的問題。

我們能不能把字符串去掉一些呢？常用的方法是Hash，即將一個(gè)字符串算出一個(gè)Hash值，然后進(jìn)行比較，這樣，我們就不需要保存待查找的函數(shù)名，而只保存一個(gè)Hash值，同樣，比較的代碼也會(huì)少一些。當(dāng)然，效率可能會(huì)降低，因?yàn)槊總€(gè)字符串都需要算完整的Hash值，而直接比較的話，差別比較大的字符串馬上就可以判斷出來。但在Shellcode中，效率一般不是優(yōu)先考慮的，優(yōu)先考慮的是代碼體積，如果能用十幾個(gè)字節(jié)能解決問題，就不要用幾十個(gè)字節(jié)，因?yàn)?#xff0c;有漏洞的程序留給我們可用的空間是有限的，每一個(gè)字節(jié)都是寶貴的。而且，代碼量越大，隱蔽性越差，被人發(fā)現(xiàn)的概率越大。

那么需要找一個(gè)字符串Hash算法，這個(gè)算法至少要保證在一個(gè)dll中，所有的函數(shù)名算出來的Hash值是唯一的。最常用的是ROR13 Hash算法，這也是Metasploit中使用的算法，它的思想如下：

/*********************************************************/ acc := 0; for c in input_string do // 對(duì)于字符串中的每個(gè)字符 acc := ROR(acc, 13) // 先將acc循環(huán)右移13位 acc := acc+c // 與當(dāng)前字符求和 end /*********************************************************/

• 1
• 2
• 3
• 4
• 5
• 6
• 7

算法來自：https://www.fireeye.com/blog/threat-research/2012/11/precalculated-string-hashes-reverse-engineering-shellcode.html

這里只記錄這樣一個(gè)方法，具體實(shí)現(xiàn)與上一節(jié)大同小異，不過是換掉函數(shù)compare_string而已，就不寫代碼了。?
實(shí)現(xiàn)請(qǐng)看這篇文章：http://www.tophertimzen.com/blog/shellcodeTechniquesCPP/

總結(jié)

以上是生活随笔為你收集整理的栈溢出笔记1.8 字符串问题的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。