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