1. 场景git
咱们发现了一个SQL注入点，在经过sqlmap dump数据的时候出现乱码了，若是咱们但愿经过sqlmap选项，以合理的方式处理这些乱码的数据，就须要一些技巧性的使用方式了。github
1.1 注入点sql
能够看到下图中，在我VPS上的sqlmap的--sql-shell选项下，经过sql语句来获取某个字段的内容时，sqlmap输出的数据是乱码的shell
2. 技巧编码
关于dump数据输出乱码，咱们至少能够用二种以上的技巧来解决spa
--binary-fields：将指定的字段以十六进制的格式输出(☆☆☆☆☆五星推荐)3d
--encoding：数据返回时的所使用的的编码调试
不一样版本的sqlmapcode
2.1 --binary-fieldsblog
好比在上面的场景中，咱们mb_name字段出现乱码，则咱们能够经过--binary-fields=mb_name的方式来解决这一个问题，完整的命令以下：
sqlmap -r xxx.txt -D dbname -T tablename -C mb_id,mb_email,mb_password,mb_name --dump --binary-fields="mb_name" --sql-shellwww.csfk0731.com
咱们能够再次在sql-shell的模式下获取mb_name内容
接下来，咱们应该如何对这里的十六进制数据作处理?好比笔者上面mb_name对应的编码为euc-kr
import binascii
name = '3439B1E2B1BAC0C7'
binascii.unhexlify(name).decode("euc-kr")
2.2 --encoding
--encoding通常用于返回页面没有设置响应头Content-Type和meta标签的编码时使用和配置，好比在上面的场景下，--encoding=euc-kr
sqlmap/lib/request/basic.py
2.3 不一样版本的sqlmap
为了更好的了解乱码问题的出现，我在本地电脑也进行了数据获取的操做，发现本地电脑获取mb_name数据时，并无出现乱码的状况。
这时候我经过增长-v 3这一个参数来查看更多调试信息，发现了问题所在。
2.3.1 VPS上的输出
这里面有一条调试信息引发了个人注意turning off NATIONAL CHARACTER casting，咱们暂且先记录下来
2.3.2 本地电脑的输出
2.3.3 问题的根源
经过对比上面两个图片的调试信息，咱们能够知道出现乱码时的PAYLOAD：CAST(mb_name AS CHAR)，没有乱码时
CAST(mb_name AS NCHAR)。
为了验证是否由于CAST后的数据类型不一致，咱们能够经过--no-cast选项来模拟乱码的场景，发现关闭CAST后，出现了咱们熟悉的乱码，从而能够肯定CAST(mb_name AS NCHAR)时才不会乱码。
2.3.4 问题的分析
咱们在sqlmap的github地址来查找这个调试信息turning off NATIONAL CHARACTER casting。
代码以下：传送门
对应的git blame地址：git blame 传送门
git commit对好比下
从上面的信息咱们知道，sqlmap新版本修复了一个union注入时NCHAR问题，在union注入的状况下，新版sqlmap会自动去掉CAST(mb_name AS NCHAR)的使用。
2.3.5 问题的解决
知道问题是不一样版本的sqlmap致使的，那么我们切换版本便可
#新版git
git switch -c c6557e2
#旧版git
git checkout c6557e2