Source Code Foundation Models are Transferable Binary Analysis Knowledge Bases

Q1. Presentation

We will improve the presentation for clarity and impact, such as the positioning of Table 1 and Table 2.

Q2. What is the purpose of the user study? Is it just for the statement that CHRF is consistent with human preference in line 216?

The user study is a crucial component of the study regarding meaningful metrics for the binary summarization task. Binary summarization is not general text generation, but rather a reverse-engineering task. As such, the metrics that apply to general text generation might not reflect additional properties of generated summary such as context relevance and functionality.

In our preliminary study, we noticed that LLMs respond in different styles (e.g., different wording and order) while (1) generating summary directly from decompiled code and (2) generating summary with additional contexts. As our reference summary is generated by an LLM given source code, the summary style is more similar to that of direct summarization and differs from context-augmented summarization (i.e., RAG and ProRec). Therefore, commonly used metrics can be easily influenced by the style difference and cannot reflect real performance differences on context relevance and functionality which reverse engineers care about.

To measure the true performance of each approach, we carry out user study and meta-evaluation of commonly used metrics. Metrics for automatic evaluation of general text-generation tasks are widely studied in natural language processing [1, 2, 3]. We follow these works to leverage correlation between automatic metrics and human evaluation as the meta-metric for evaluation. As shown in Figure 5 in our paper, we meta-evaluated BLEU [4], METEOR [6], ROUGE-L [7], and CHRF [8], among which CHRF has the highest correlation with human scores for both context relevance and functionally.

Moreover, recent studies [3,5] have shown that LLM-as-a-judge becomes more correlated with humans for evaluating text generation in many aspects such as naturalness, coherence, engagingness, and groundedness. Thus, we propose an LLM-based metric for binary summarization. As shown in Figure 5, the correlation of the LLM-based metric has higher correlation with human scores compared to all traditional automatic metrics for both context relevance and functionally.

To conclude, CHRF and the LLM-based metric we propose are the two metrics that are most consistent with human scores and we report them as our final metrics for evaluating binary summarization.

[1] Zhang et al. Bertscore: Evaluating text generation with bert. 2019 arXiv.

[2] Yuan et al. Bartscore: Evaluating generated text as text generation. 2021 NeurIPS.

[3] Zheng et al. Judging llm-as-a-judge with mt-bench and chatbot arena. 2023 NeurIPS.

[4] Papineni et al. Bleu: a method for automatic evaluation of machine translation. 2002 ACL.

[5] Chan et al. ChatEval: Towards Better LLM-based Evaluators through Multi-Agent Debate. 2024 ICLR.

[6] Banerjee et al. METEOR: An automatic metric for MT evaluation with improved correlation with human judgments. 2005 ACL Workshop.

[7] Lin et al. Rouge: A package for automatic evaluation of summaries. 2004 Text summarization branches out.

[8] Popović et al. chrF: character n-gram F-score for automatic MT evaluation. 2015 SMT Workshop.

Q3. What is the reason for only adopting ROUGE-L and using the precision, recall, and F1 score for ROUGE-L? Could you present a clearer explanation for the choice of metrics?

We would like to clarify that "ROUGE-L" for evaluating binary function recovery (Table 2) is essentially at the character level, which indicates a finer granularity than subword-level precision and recall which is used by SymLM [1] metrics. This helps to avoid some limitation of the tokenization. This kind of character-level metrics, such as character-level BLEU, have been widely used in NL2Bash command generation tasks [2, 3]. We will make this clearer in our paper by calling it charROUGE-L.

In fact, character-level metrics show consistent results with SymLM metrics and char-ROUGE-L. We show more character-level metrics on binary function recovery below.

As function names are typically brief and precise, without much verbose descriptions as in summarization, these statistics-based metrics are all informative. The reason we only show charROUGE-L is that we think that charROUGE-L is more intuitive for binary function recovery, as high charROUGE-L shows a longest common subsequence overlap between the prediction and the reference which means a similar function name that can hint reverse engineers. Overall, we believe the metrics do demonstrate that our method is better than baselines for binary function name recovery.

[1] Jin et al. Symlm: Predicting function names in stripped binaries via context-sensitive execution-aware code embeddings. 2022 CCS.

[2] Lin et al. NL2Bash: A Corpus and Semantic Parser for Natural Language Interface to the Linux Operating System. 2018 LREC.

[3] Shi et al. Natural Language to Code Translation with Execution. 2022 EMNLP.

[4] Zhou et al. DocPrompting: Generating Code by Retrieving the Docs. 2023 ICLR.

We really appreciate the reviewer’s continuous efforts in helping us improve our submission.

Better suited to SE

With all due respect, we think NeurIPS is the right home for our submission. Even though our task is related to Software Engineering and Security, our core contributions are mainly on the deep learning side, and the NeurIPS community has the sufficient expertise to review our paper.

Our contributions are:

• We propose a novel and general probe-and-recover framework for HOBRE tasks. The framework has the potential to be useful in other tasks as well.
• We introduce a novel neural architecture for the prober in the ProRec framework, which is a cross-modal encoder-decoder that encodes binary functions with structural information into node embeddings and conditionally decodes them into symbol-rich source code snippets.
• We introduce the corresponding compute-efficient alignment training for the prober that aligns pre-trained binary encoders and source code foundation models in the token embedding space of the source code foundation models, which is also novel.
• We show that LLM-based automatic metrics have high correlations with human preferences and are suitable for HOBRE tasks, which belongs to a larger topic of evaluation of models.

There are many papers that have been accepted by top-tier AI conferences that focus on SE problems and contribute on the AI side. Here we list a few of them [1-8].

In contrast, many papers published in SE utilize AI techniques/metrics in a black-box fashion, e.g., [9-11]. There is uncertainty whether SE reviewers would appreciate our technical contributions. In the past, we had submitted papers having a similar nature to this submission to SE conferences. Our submissions were rejected because reviewers found our papers difficult to understand and believed that our papers should have been submitted to AI conferences. While we are grateful for the reviewer’s intensive SE expertise, we hope the reviewer could understand that not all reviewers in the SE community would appreciate the technical contributions like those in our submission.

[1] Gao et al. Virtual Compiler Is All You Need For Assembly Code Search. 2024 ACL Long

[2] Zhang et al. Self-Edit: Fault-Aware Code Editor for Code Generation. 2023 ACL Long

[3] Yu et al. Codecmr: Cross-modal retrieval for function-level binary source code matching. 2022 NeurIPS.

[4] [Oral] Wu et al. Repoformer: Selective Retrieval for Repository-Level Code Completion. 2024 ICML

[5] [Spotlight] Pei et al. Exploiting Code Symmetries for Learning Program Semantics. 2024 ICML

[6] Zhang et al. Coder Reviewer Reranking for Code Generation. 2023 ICML

[7] [Oral] Jimenez et al. Swe-bench: Can language models resolve real-world github issues?. 2024 ICLR

[8] [spotlight] Zhou et al. Docprompting: Generating code by retrieving the docs. 2023 ICLR

[9] Xia et al. Fuzz4all: Universal fuzzing with large language models. 2024 ICSE

[10] Peng et al. Generative Type Inference for Python. 2023 ASE

[11] Zan et al. DiffCoder: Enhancing Large Language Model on API Invocation via Analogical Code Exercises. 2024 FSE

Error review

If we understand the reviews correctly, the errors pointed out by the reviewers could be fixed with simple changes. It does not appear to be the case that our paper is flawed because of these errors. We will perform a rigorous error check as suggested by the reviewer.

The possibility of undetected errors by the reviewers

If we understand the reviews correctly, there were errors that affected understanding. We believe that we have addressed them in the rebuttal. If possible, we would really appreciate it if the reviewer can elaborate on unaddressed errors that caused doubts on our reliability, which seems to be a substantial criticism of our work.

”With only part of the user study for these metrics presented in the Appendix. Crucial details are missing”

Our answer in the earlier response under the title “The details of the user study & direct results from user study” provided the missing details. Please let us know if any additional information is needed.

The new user study provided does not offer sufficient evidence to convincingly demonstrate the effectiveness of the method

Our new user study shows that our method is substantially better than the baselines. In particular, ProRec’s improvements over direct-prompting baseline nearly doubles the improvement of RAG over direct-prompting, achieving 4.76/5 in context relevance and 4.62/5 in functionality.

Note that the user study is only for binary summarization. For the other task binary function name recovery, we strictly follow existing work [1] in evaluation and show significant improvement over RAG (5-10% absolute improvement in token-level precision and recall)

[1] Jin et al. Symlm: Predicting function names in stripped binaries via context-sensitive execution-aware code embeddings. 2022 CCS.

Thank you for your continuous efforts in helping us improve the quality of our submission.

These numbers are correct. Note that we have a triple of precision, recall, and F1 values for each function name (by measuring the individual token or character matches in the name).

The reported statistics are averages over all function names. As such, it is possible that the averaged F1s are not in between the averaged precisions and recalls. A similar case is the Table 2 in this paper [1].

In fact, we directly reused the scripts in SymLM and ROUGE-L to compute such statistics.

We are grateful that you pointed out this confusion. We will clarify.

[1] Allamanis et al. A convolutional attention network for extreme summarization of source code. 2016 ICML

We are very grateful for the tremendous time the reviewer has spent on helping us!

Presentation

We think the suggested presentation is better than what we proposed in the previous response. We will revise following the suggestions.

Possibility of user study data leakage

We did not disclose corresponding techniques to users, so that they did not know which technique is used to generate a summary after the user study. Therefore, we believe there was no data leakage.

User study templates

We checked all suggested studies [1-3 (index of reference provided by the reviewer)]. The study in [1] aims to identify the keywords in a snippet of source code that should be included in the code summary, which is different from our task. Therefore, the following discussion focuses on comparing our study with [2] and [3].

The user studies in [2, 3] aim to evaluate source code function summary. Their studies are similar to ours, in terms of how to conduct them, participants (three Ph.D students and three senior researchers), and scale (100 code snippets). In particular, their templates include the following: “For each code snippet, we show the participants the oracle comment and the results from four approaches”; “To ensure fairness, the participants are not aware of where the comments are generated from”; “Each participant is asked to rate … (1) Naturalness … (2) Adequacy … (3) Usefulness … on a 5-point Likert scale”, which resembles ours.

On the other hand, they are different from ours due to the different objectives. In particular, for our binary summarization, we aim to evaluate context relevance and functionality due to the lack of source code. In contrast, [2, 3] aim to evaluate generated summaries of source code snippets regarding naturalness, adequacy and usefulness. We derive our evaluation prompts from a thorough survey on the reverse engineering domain [4]. The survey summarizes 8 key sub-goals of a human reverse engineer, where two of them (i.e., the overall context of a program, and the functionality of a program) can be enhanced by the binary code summarization task. We therefore construct our evaluation aspects accordingly.

Appendix C2 in our paper discusses our evaluation aspects for binary code summarization and the rationale. We will revise the title from “Details and Rationale for GPT4Evaluator” to “Evaluation Aspects and Rationale for Human Study and GPT4Evaluator” because our human study and GPT4Evaluator share the same set of aspects.

[4] Bryant et al. Understanding how reverse engineers make sense of programs from assembly language representations. Air Force Institute of Technology, 2012.

but it seems that you lack an informative explanation of why the prober code generated is informative

In this response, we explain why the prober generated code is informative via the two examples shown in the original paper. We will add the corresponding discussions to the paper.

The case study in Figure 11 of the paper shows a function that initializes an encryption key. The decompiled code and the source code are shown in Figure 11a and 11b, respectively. We can see that the decompiled code contains nested loops with complex bitwise operations that are hard to reason about. On the other hand, the prober generates a function “aes_key_expansion”, indicating the original function may be similar to the expansion of an AES encryption key. We can see that the generated code has a similar context to the ground truth source code function and is thus informative to the HOBRE task. We speculate the prober can generate code within the correct context because it associates subtle patterns (e.g., certain bitwise operations in loops) with encryption.

Similarly, the case study in Figure 12 of the paper shows a function that reads the temperature from a sensor. Two of the code snippets generated by the prober (Figure 12c) are “sht4x_get_humidity” and “sgp30_get_tvoc”. Both code snippets correctly reflect the context that “read data from a sensor”. Note that it is not easy to deduce such context from the decompiled code (Figure 12a). Therefore, the prober provides more context information. We speculate the prober captures context information from the code patterns (e.g., consecutive if-statements conditioned on fields of a structure), and the conversion operation (the assignment before the last return statement in Figure 12b). The former may indicate different running status of the sensor, which are commonly seen patterns in cyber-physical systems; and the latter may imply the conversion from integer values to floating point values in certain ranges, which is a commonplace operation when reading data from a sensor.

Q1. Analyze the reason why prober helps

Please refer to Q2 in global response.

Q2. Why are previous works ignored?

We will cite and discuss the related work CP-BCS in our paper. We cited supervised methods that train end-to-end binary summarization models, such as BinT5 [1] and HexT5 [2]. However, as shown in a previous study [3], supervised baselines underperform LLMs with regard to generalizability (HexT5 achieves 6.32% METEOR compared to ChatGPT’s 28.13% for binary summarization on a new benchmark). Therefore, in our paper we primarily use zero-shot LLMs as our baselines.

Following the reviewer’s suggestion, we collected the results of CP-BCS on our test set during rebuttal. Note that CP-BCS is a supervised model trained for binary function summarization, whereas ProRec does not require any data for summarization. More importantly, their summarization target is the docstring/comment of a function parsed from source code, which is not identical as the summarization targets in our experiments which are LLM summarizations from source code. For a fair comparison, we prepend the comments summarized by CP-BCS to the decompiled code as additional context for LLMs (gpt3.5-turbo-1106) to revise it into their own summarization styles, so that the final candidate summaries can be properly compared with reference source code summaries. Here, “+CP-BCS comment” means we augment the decompiled code with the comment for LLM to summarize. If we only evaluate the comments generated by CP-BCS, the CHRF drops to 5.44.

We can see that CP-BCS comments have negative impacts on direct-prompting results on our test set, potentially due to the distribution difference between training and test data. Moreover, we cannot easily adapt/transfer CP-BCS to this distribution since the training requires comments within the source code which do not exist in many functions in our training data. It is possible to distill summarization from LLMs, but the cost is high given the large amount of data. For ProRec, data is less of a problem since all the compilable projects can be used to produce binary-source pairs that can be used for alignment.

[1] Al-Kaswan et al. Extending source code pre-trained language models to summarize decompiled binaries. 2023 SANER.

[2] Xiong et al. HexT5: Unified Pre-Training for Stripped Binary Code Information Inference. 2023 ASE.

[3] Shang et al. How far have we gone in stripped binary code understanding using large language models. 2024 arXiv.

Q3. How does the retrieval work? Why can your retrieval method find relevant source code snippets?

As we discussed in the global response, our retrieval baseline is standard, following the common practice, and is able to retrieve relevant source code snippets if they exist.

We agree that function-level similarity score might not be equivalent to ideal relevance score for retrieval within the context of HOBRE. However, how to define such ideal relevance is itself a research problem that needs to be further studied. We will try to explore how to define ideal relevance for binary and source code for HOBRE in future work, which might lead to better retrieval methods that are more suitable for HOBRE tasks.

Q4. Why use the retrieval method proposed in this paper? What about the straightforward solution of using CodeBLEU to search for similar disassembled code and use the corresponding source code snippets?

Binary similarity[1-3] (i.e., binary-to-binary search) is a long studied field that we are quite familiar with (these techniques leverages more complex structures such as control-dependence, data-dependence, and dynamic traces, which are more accurate than CodeBLEU score which is based on AST and n-gram). Despite these successes, an assumption that binary similarity techniques can solve HOBRE is that there always exists such “similar code snippets” within the existing knowledge base (collected before hand), which is hardly true in practice as we mentioned above.

In (easier) use cases where we would actually encounter binaries within the datastore, binary similarity tools can be first leveraged as a filter. However, it’s still necessary to have ProRec for unseen functions.

[1] Pei et al. Trex: Learning Execution Semantics from Micro-Traces for Binary Similarity. 2022 TSE

[2] Wang et al. jTrans: Jump-Aware Transformer for Binary Code Similarity. 2022 ISSTA.

[3] Want et al. CEBin: A Cost-Effective Framework for Large-Scale Binary Code Similarity Detection. 2024 ISSTA

Q5. Why not try building a prober exploiting the LLMs directly, i.e., let the LLM generate probed context?

Leveraging black-box LLMs as probers is challenging because they are not heavily pre-trained on binary code and have limited understanding of it. ProRec addresses this through alignment training.

To demonstrate this empirically, we conduct experiments on binary function name recovery. We first prompt a black-box LLM (gpt3.5-turbo-1106) to translate decompiled functions into readable ones, sampling multiple results as diverse probed contexts. Using the same prompt as ProRec and the same LLM, we perform function name recovery with additional context. We call this method "self-probing."

The following table is the performance of self-probing (gpt3.5-turbo-1106) compared to direct-prompting, RAG, and ProRec on 100 randomly sampled test data. (“RoL” stands for ROUGE-L, “P” for precision, “R” for recall, “F” for F1 score).

We can see that self-probing performs slightly better than direct-prompting but is not comparable to RAG or ProRec.

Dear Reviewer 9NVM,

Thank you for your thoughtful feedback on our paper! We have made every effort to address your concerns and questions. As the reviewer-author discussion period is coming to a close, we would greatly appreciate it if you could let us know whether our responses have addressed your concerns.

We are looking forward to your reply. Thank you once again!

Best regards,

The Authors

Thank you for reviewing our paper and for your kind feedback! We are delighted to hear that you consider our work in this important area to be both novel and effective.

Please see our response below.

Q1. Missing example of RAG

We show two examples of RAG in the uploaded PDF file. Both figures can be interpreted similar to Figure 11 in the submission. The code snippets retrieved by a retriever are shown in yellow blocks. In Figure 1 of the uploaded PDF, we can see that RAG helps LLM generate a more context-relevant summary. That is because the datastore contains code snippets that are very similar to the query function (e.g., the function sp_256_ecc_recode in Figure 1c is a crypto related function that performs bitwise operations).

On the other hand, RAG is less helpful than ProRec when the datastore does not contain functions similar to the query function. For example, in Figure 2 of the uploaded PDF, the query function pops an element from a queue. The datastore does not contain similar functions, so the retriever retrieves two snippets of code that have similar syntactic features (e.g., null pointer checks at the beginning; pointer accesses in the loop condition). The retrieved results are not relevant to the ground truth code context. By contrast, ProRec recognizes local semantic information such as getting an element from a queue, and atomic memory operations. Therefore, the probed code snippets are more relevant to program contexts even if the entire query program is not in the datastore.

Thank you for taking the time to review our paper and for your kind words! We are delighted to know that you enjoyed the well-grounded motivation and thorough experiments.

Q1. Security concerns about ProRec being used by malicious agents to understand better and exploit critical software infrastructure

Just like LLMs could improve malicious agents’ productivity, our method might help them too. We will be careful on the license and regularization when releasing our models and data.

Q2. Which other fields could benefit from the ProRec architecture you propose?

Human-oriented binary reverse engineering is a fundamental research field in software security. ProRec can potentially benefit security assessments of contemporary devices such as home automation systems [1, 2] and autopilot technology [3], maintaining and hardening legacy software [4, 5, 6], detecting vulnerabilities in commercial-off-the-shelf software [7, 8], and analyzing malware [9]. We will add a discussion in revision.

[1] Angelakopoulos et al. {FirmSolo}: Enabling dynamic analysis of binary Linux-based {IoT} kernel modules. USENIX Security 23.

[2] Aonzo et al. Humans vs. machines in malware classification. USENIX Security 23

[3] Miller et al. Probabilistic disassembly. 2019 ICSE.

[4] Carlini et al. {Control-Flow} bending: On the effectiveness of {Control-Flow} integrity. USENIX Security 15.

[5] Martin et al. Dynamically checking ownership policies in concurrent C/C++ programs. 2010 ACM Sigplan Notices.

[6] Carbone et al. Mapping kernel objects to enable systematic integrity checking. 2009 CCS.

[7] Xu et al. Spain: security patch analysis for binaries towards understanding the pain and pills. 2017 ICSE.

[8] Li et al. SemHunt: Identifying Vulnerability Type with Double Validation in Binary Code. 2017 SEKE.

[9] Xu et al. Autoprobe: Towards automatic active malicious server probing using dynamic binary analysis. 2014 CCS.

Q3. How do you plan to extend this work in the future?

We plan to extend this work in the following directions in the future:

• Building program-level agents that analyze entire binaries containing multiple functions.
• Applying ProRec to various downstream tasks such as vulnerability detection and software hardening.
• Integrating it with popular reverse engineering tool chains such as IDA [1] and Ghidra [2] to achieve broader impact.

We will add a section discussing the limitations and future work in the paper.

[1] IDA-Pro. https://hex-rays.com/ida-pro/

[2] Ghidra. https://ghidra-sre.org/