## 5 Discussion  
In this paper, we propose a novel fine-grained BCSD approach, named BlockMatch, using NLP techniques for basic block matching. The experiments show that BlockMatch outperforms the state-of-the-art methods PalmTree and SAFE. Here, we discuss the following questions:  
**Why does BlockMatch achieve good performance in basic block matching? ** The basic block matching in BCSD tasks belongs to fine-grained tasks. Compared with function-level BCSD methods, it specifically identifies which basic blocks are similar in binary files, while also facing a larger number of comparison examples. Experimental results have shown that the contrastive training framework plays a significant role in achieving high performance for BlockMatch. The contrastive training framework leverages DWARF debug information to automatically generate a large number of high-quality contrastive samples, facilitating the fine-tuning of BlockMatch, which enables BlockMatch to converge faster and handle hard samples effectively. Table 5 shows the average results of BlockMatch and other baselines, which demonstrates that BlockMatch generally outperforms PalmTree and SAFE in basic block similarity detection. Comparative results against other baselines demonstrate that this improvement is particularly pronounced in cross-compiler scenarios. For example, in the cross-compilers experiment (pool size = 10), BlockMatch achieves a recall@ of 0.790, while SAFE and PalmTree achieve recalls of 0.573 and 0.587, respectively. **Why does BlockMatch show a slight decrease in performance when used for cross-compiler basic block matching? ** Based on the results obtained from one-to-one and one-to-many basic block matching, it is evident that BlockMatch demonstrates slightly lower performance in cross-compiler basic block matching compared to cross-optimization basic block matching. Actually, the same issue also occurs in other approaches like SAFE and PalmTree. Analyzing this issue will help us make further improvements to our approaches in the future. We compare binary snippets compiled by Clang and GCC using -O0 option without any compiler optimization intervention and differences in the preferred instructions they generate. For example, in binary files compiled with GCC, there are numerous _endbr64_ instructions. These instructions are part of Intel's Control-Flow Enforcement Technology, which provides protection against Return-oriented Programming (ROP) attacks. However, in binary files compiled with Clang, the frequency of the _endbr64_ instruction is much lower. Similar issues have also been mentioned in other literature [58]. When the differences exceed the tolerance threshold of the model, it leads to the misidentification of similar basic blocks by the model. Although using a contrastive training framework can partially mitigate this issue, it is still challenging to completely eliminate the impact of these differences. We notice that the control flow graphs remain relatively consistent across different compilers, so we can consider using graph node alignment based on control flow graphs in future work to help overcome this issue. \begin{table}
\begin{tabular}{c c c c c c} \hline \hline  & **Candidate-1** & **Candidate-2** & **Candidate-3** & **Candidate-4** & **Candidate-5** \\ \hline BlockMatch & \(\bigcirc\) & \(\times\) & \(\times\) & - & - \\ PalmTree & \(\bigcirc\) & \(\times\) & \(\times\) & \(\times\) & \(\times\) \\ SAFE & \(\times\) & \(\times\) & \(\times\) & \(\bigcirc\) & \(\times\) \\ \hline \hline \end{tabular}
\end{table} 
Table 4: The result of locating the start position of vulnerability CVE-2022-0778 in the suspicious function’s basic blocks.