最近看一些USB fuzzing方面的東西,總結一下。主要是軟件方面的工做。linux
qemu支持USB重定向協議,用來遠程鏈接USB設備,vUSBf使用這個來實現不一樣USB設備的虛擬化。github
在USB重定向協議中,USB的數據經過網絡而不是直接的硬件接觸,QEMU中運行系統,而外部設備的虛擬經過重定向協議鏈接QEMU來實現,也就是redirserver,整個架構以下:網絡
在redirserver端實現USB設備的虛擬和fuzzing,在QEMU中運行OS,二者經過USB重定向協議鏈接。同時還須要兩個部件架構
文章地址:https://www.usenix.org/system/files/conference/woot14/woot14-vantonder.pdf併發
提出了一個USB測試框架,文章用到了Facedancer,一種用來測試USB的硬件設備,產生USB數據。而後通過中間層MC,最後經過一個Facedancer連到被測試主機上,能夠在MC處作fuzzing框架
文章在這裏:https://ieeexplore.ieee.org/stamp/stamp.jsp?tp=&arnumber=5663316jsp
這個直接改了QEMU,QEMU能夠經過主機的設備文件訪問主機上的USB設備,文章攔截QEMU與主機的設備交互信息加入fuzzing模塊ide
按照這個說法是否是必需要有相應的硬件設備才能進行fuzzing了?函數
該文章使用S2E進行錯誤注入。
S2E是選擇符號執行,能夠將符號執行應用於大型程序,好比像內核。它自己就支持使用SystemTap腳本將外部設備的輸入符號化,而後進行符號執行,官方介紹看這裏https://github.com/S2E/s2e-old/blob/master/docs/SystemTap.rst
根據這篇文章的內容,貢獻是兩點:
一、作了提出了一種將故障注入與併發模糊和符號執行相結合的設備驅動程序缺陷檢測方法
二、咱們介紹了模擬虛擬USB設備的方法,該設備容許測試任意客戶機驅動程序
按照我如今的理解,他虛擬USB設備的方式好像和vUSBf並無太多的區別,在USB枚舉階段,因爲USB協議已經定好了數據交換的格式,因此只須要個更改那5中描述符就能夠了,可是在真實的數據卷換場景下面,vUSBf須要根據不一樣的設備來模擬。每太明白它的這部分模擬是怎麼作的,USB數據交換的4種模式,感受它就是抽象了一下這4中交換數據方式,而後就說能夠通用模擬了。
故障注入這一點,它就使用了符號執行,在相應USB的回調函數中,經過systemTap腳本的控制,用符號執行讓該函數以錯誤的值返回。好像是這個意思,S2E的這幾個函數的含義也還不是太清楚。
谷歌開發的基於覆蓋的系統調用fuzzing,也發現了不少的USB漏洞
具體漏洞信息看這裏:https://github.com/google/syzkaller/blob/master/docs/linux/found_bugs_usb.md
使用Syzkaller挖USB漏洞:https://data.hackinn.com/ppt/OffensiveCon2019/Coverage-Guided%20USB%20Fuzzing%20with%20Syzkaller.pdf
硬件設備,該板的目的是容許USB設備在主機端Python中編寫,這樣一個工做站就能夠對其餘主機的USB設備驅動程序進行模糊測試
不是專門fuzzingUSB的,可是能夠對內存映射IO和MDA的數據進行fuzzing。須要對內核源碼進行修改。