開源軟體因為流通性高，所以較常被採用，因此當一個套件出現漏洞時，經常會危害大量的使用者，又 library 等級的漏洞泛用性最高，在許多的套件裡可能由於開發者版權意識不佳，亦或者是為了規避 license，在有些時候過於底層的 library 可能已經包進二進制檔而難以察覺，因此讓開發項目變得危險，而使用者也暴露於風險之中。

　　同時，在 fuzzing 過程中，如果遇到已知的元件，應該能夠以更有效率的方式進行 Fuzzing，諸如採用相對應的檔案格式，亦或是較容易觸發的輸入類型，基於以上兩種目，我們都需要先進行元件的檢測，這裡以 function 為基本單位來進行發想，以市面的上 diff 為例，在 binary 上先從函式頭尾，抑或是 calling 來定義出每個 function 的起頭與結尾，之後針對每個 function 取特徵值後，當有新的檔案進來時，我們便能使用啟發式的方式來匹配出相對應的 function，最簡單的便是 yara rule。

　　但因為編譯過程最佳化以及 CPU 架構等因素，單純的 yara rule 並不能算是完美，因此套用現在市面上的有 CFG fuzzy、SPP 等靜態方法來增加匹配的良率，在一般情境下，這些方法組合起來的匹配率並沒有到完美，但考慮到 library 因為效率問題並不會進行混淆，所以能夠找到一個良率堪用的圖同構。

　　逐步建立建立特徵庫，並實作基本架構同時，cli 工具已經能夠以可閱讀形式輸出相關 binary 相似度之外亦已經模組化，能夠使用 JSON 與網頁前端相接，方便人類除錯及相關延伸應用，將持續加入匹配方法來提高匹配度。

　　建立起模型之後，期望將取的資訊回饋給 fuzzing ，使之能夠更準確的往較可能有錯誤的方向探索，由於在此實驗中，被 fuzzing 的設備是嵌入式系統，調查文獻後，許多人是採取模擬的方式來進行，但是效率較差之外，亦有相容性的問題，而由於本次測定的目標是 Linux base 的嵌入式系統，經過初期的測試，raspberry pi其實就足以勝任，並不需要模擬整個作業系統，透過在樹莓派上建置 docker的方案，速度上並不需要讓步太多，接下來只要對周邊設備進行模擬即可。