点击OK，继续F8或者F9执行，选择Yes（pass to app） ，然后在python中执行io.interactive( )进行手动交互，随便输入一个shell命令如ls，在IDA窗口中再次按F9，弹出另一个捕获信号的窗口。
同样OK后继续执行，选择Yes（pass to app），发现python窗口中的shell命令被成功执行。
那么问题来了，我们这段ShellCode里面并没有system这个函数，是谁实现了“system("/bin/sh")”的效果呢？事实上，通过刚刚的调试大家应该能猜到是陌生的int 80h指令。查阅intel开发者手册我们可以知道int指令的功能是调用系统中断，所以int 80h就是调用128号中断。在32位的linux系统中，该中断被用于呼叫系统调用程序system_call( )，我们知道出于对硬件和操作系统内核的保护，应用程序的代码一般在保护模式下运行。
在这个模式下我们使用的程序和写的代码是没办法访问内核空间的。但是我们显然可以通过调用read( ), write( )之类的函数从键盘读取输入，把输出保存在硬盘里的文件中。那么read( ), write( )之类的函数是怎么突破保护模式的管制，成功访问到本该由内核管理的这些硬件呢？
答案就在于int 80h这个中断调用。不同的内核态操作通过给寄存器设置不同的值，再调用同样的指令int 80h，就可以通知内核完成不同的功能。而read( ), write( ), system( )之类的需要内核“帮忙”的函数，就是围绕这条指令加上一些额外参数处理，异常处理等代码封装而成的。32位linux系统的内核一共提供了0~337号共计338种系统调用用以实现不同的功能。
知道了int 80h的具体作用之后，我们接着去查表看一下如何使用int 80h实现system("/bin/sh")。通过http://syscalls.kernelgrok.com/，我们没找到system，但是找到了这个：
对比我们使用的ShellCode中的寄存器值，很容易发现ShellCode中的EAX = 0Xb = 11，EBX = &(“/bin//sh”), ECX = EDX = 0，即执行了sys_execve("/bin//sh", 0, 0, 0)，通过/bin/sh软链接打开一个shell，所以我们可以在没有system函数的情况下打开shell。需要注意的是，随着平台和架构的不同，呼叫系统调用的指令，调用号和传参方式也不尽相同，例如64位linux系统的汇编指令就是syscall，调用sys_execve需要将EAX设置为0x3B，放置参数的寄存器也和32位不同。
ShellCode的变形
在很多情况下，我们多试几个ShellCode，总能找到符合能用的。但是在有些情况下，为了成功将ShellCode写入被攻击的程序的内存空间中，我们需要对原有的ShellCode进行修改变形以避免ShellCode中混杂有\x00, \x0A等特殊字符，或是绕过其他限制。有时候甚至需要自己写一段ShellCode。我们通过两个例子分别学习一下如何使用工具和手工对ShellCode进行变形。
首先我们分析例子~/BSides San Francisco CTF 2017-b_64_b_tuff/b-64-b-tuff.从F5的结果上看，我们很容易知道这个程序会将我们的输入进行base64编码后作为汇编指令执行(注意存放base64编码后结果的字符串指针ShellCode在return 0的前一行被类型强转为函数指针并调用)
虽然程序直接给了我们执行任意代码的机会，但是base64编码的限制要求我们的输入必须只由0-9，a-z，A-Z， ，/这些字符组成，然而我们之前用来开shell的ShellCode
"\x31\xc9\xf7\xe1\xb0\x0b\x51\x68\x2f\x2f\x73\x68\x68\x2f\x62\x69\x6e\x89\xe3\xcd\x80"显然含有大量的非base64编码字符，甚至包含了大量的不可见字符。因此，我们就需要对其进行编码。
在不改变ShellCode功能的情况下对其进行编码是一个繁杂的工作，因此我们首先考虑使用工具。事实上，pwntools库中自带了一个encode类用来对ShellCode进行一些简单的编码，但是目前encode类的功能较弱，似乎无法避开太多字符，因此我们需要用到另一个工具msfVENOM。由于kali中自带了metasploit，使用kali的读者可以直接使用。
首先我们查看一下msfvenom的帮助选项：
