# Large Language Models for Code Analysis: Do LLMs Really Do Their Job?

Chongzhou Fang∗1, Ning Miao∗1, Shaurya Srivastav1, Jialin Liu2, Ruoyu Zhang1,
Ruijie Fang1,
Asmita Asmita1, Ryan Tsang1, Najmeh Nazari1, Han Wang2 and Houman Homayoun1
1 University of California, Davis
Email:
<EMAIL_ADDRESS>
2 Temple University
Email<EMAIL_ADDRESS>
###### Abstract

Large language models (LLMs) have demonstrated significant potential in the
realm of natural language understanding and programming code processing tasks.
Their capacity to comprehend and generate human-like code has spurred research
into harnessing LLMs for code analysis purposes. However, the existing body of
literature falls short in delivering a systematic evaluation and assessment of
LLMs’ effectiveness in code analysis, particularly in the context of
obfuscated code.

This paper seeks to bridge this gap by offering a comprehensive evaluation of
LLMs’ capabilities in performing code analysis tasks. Additionally, it
presents real-world case studies that employ LLMs for the analysis of
malicious code. Our findings indicate that LLMs can indeed serve as valuable
tools for automating code analysis, albeit with certain limitations. Through
meticulous exploration, this research contributes to a deeper understanding of
the potential and constraints associated with utilizing LLMs in code analysis,
paving the way for enhanced applications in this critical domain.

_Keywords_ LLM $\cdot$ Code Analysis $\cdot$ Security

##  1 Introduction

In recent years, the emergence of large language models (LLMs) has
revolutionized the field of natural language processing and brought great
changes to many other areas. Ever since the access of ChatGPT [51] becomes
publicly available in late 2022, there is a rocketing number of users as well
as publicly-available services utilizing LLM APIs provided by OpenAI. These
models have demonstrated their abilities to understand and process inputs
including but not limited to natural languages, and have been involved in
different types of tasks. A typical use case of LLMs is text generation, since
it has the ability to produce high-quality natural language outputs [70]. This
has caused a heated debate in academia and eventually resulted in major
publishers announcing new regulations regarding the usage of generative AI
[13, 37]. Besides, LLMs have also manifested their extraordinary potential in
tasks related to programming, including code generation [61] and code
comprehension [68]. LLM-based assistant tools like Github Copilot [34] have
received tremendous attention and have been widely employed by programmers all
around the world. OpenAI has recently enabled more features in ChatGPT [52],
making LLMs more versatile and capable of engaging in more real-world tasks.

Amidst all possibilities of LLMs, code analysis and obfuscation are tasks that
are receiving more and more attention from computer scientists. Code analysis
[16] is an important task in software engineering, including code quality
assessment [56], vulnerabilities detection [64], etc. The huge size and
complex architecture of modern software systems motivate the wide usage of
automated code analysis, especially in security-related scenarios such as
software reverse engineering [19]. In response, malicious parties have
leveraged code obfuscation techniques to obscure source code and avoid being
detected. In response, researchers have proposed automated code analysis tools
like Abstract Syntax Tree (AST) [48] to analyze both non-obfuscated and
obfuscated code. However, such tools are highly dependent on the pre-defined
data types and not suitable for general software code analysis. Due to the
great potential of LLMs in these areas, researchers have started using LLMs to
perform related tasks [18, 68]. However, as pointed out by a recent survey
[15], there are few systematic analytical studies on this topic.

In this paper, we focus on evaluating the ability of LLMs to analyze input
code samples, and test if LLMs can be utilized for defensive analysis tasks.
We first construct a dataset containing code from real-world programs (on
Github, etc.) and their obfuscated versions to feed to LLMs, then we analyze
the outcomes and present our obtained key findings. We aim to answer two
critical research questions through a systematic analysis:

RQ1:

Do LLMs understand source code?

RQ2:

Can LLMs comprehend obfuscated code or code with low readability?

After that, as real-world case studies, we showcase if publicly-available LLMs
(e.g. ChatGPT) can be utilized for security-related tasks targeting real-world
malicious software.

The contributions of this paper are listed as follows:

  1. 1.

We construct two datasets consisting of code samples from popular programming
languages and obfuscated samples from these languages for our evaluation;

  2. 2.

We systematically evaluate the performance of publicly available state-of-the-
art LLMs, including the most popularly used GPT and LLaMA families on our
dataset, and present our findings;

  3. 3.

We conduct two case studies using LLMs to analyze real-world malicious
software to showcase the capability and limitations of LLMs in these tasks.

To the best of our knowledge, this is the first paper that provides a
systematic evaluation of the ability of LLMs to comprehend code and code with
obfuscation.

The remainder of this paper is organized as follows. We first introduce
related background knowledge in Section 2. Then we elaborate our experiment
settings of our analysis in Section 3. Essential results and findings are
presented in Section 4. In Section 5, we perform case studies and show how
LLMs can be utilized to assist code analysis in practical cases. Then we
briefly discuss future works in Section 6. Related works and a conclusion are
provided in Section 7 and Section 8, respectively. Our online appendix is
available at: https://sites.google.com/view/llmsfor-code-analysis/home

##  2 Background

In this part, we will provide an overview of the technical background of large
language models, code analysis, and code obfuscation.

###  2.1 Large Language Models

Large language models (LLMs) are a groundbreaking innovation in the field of
artificial intelligence, representing a significant milestone in natural
language understanding and generation. Most LLMs are built on deep learning
architectures, particularly transformer architectures and self-attention
mechanisms [62], which are trained on massive datasets containing a diverse
range of text from the internet, books, and Github. This extensive training
enables them to grasp the intricacies of languages, including grammar,
context, and semantics. Both companies and researchers have launched LLMs-
driven products and pre-trained models, such as OpenAI GPT series [53, 58],
Meta LLaMA [60], Standford Alpaca [59], etc. One of the critical features of
the LLMs is their ability to perform a wide range of natural language
understanding tasks, including text summarization, translation, sentiment
analysis, question-answering, etc. Besides natural language understanding
tasks, researchers also find that LLM models have significant performance
across various domains, from security and code generation [23] to healthcare
[22] and education [39]. These LLM-driven applications have the potential to
automate analysis tasks and provide instant information and assistance [14].

###  2.2 Code Analysis

Code analysis is a process in software engineering to examine source code,
byte code, or binary code to ensure quality, reliability, and security. Code
analysis has become a crucial practice to assist developers in identifying and
addressing problems early in the software development life cycle. The
increasingly large scale of modern software challenges motivates researchers
to propose automated tools. Prior works have proposed to extract structural
relationships, including inheritance, association, friend relationships,
interface hierarchies, attributes, data types, etc., from source code [48] to
build Abstract Syntax Tree (AST) for pattern-matching [69] to detect
vulnerabilities [20] and malicious activities [42]. However, the approach is
highly dependent on the pre-defined data types and can not be used for general
code analysis. In response, some researchers propose to extract features from
source code and leverage machine learning to build a vulnerability detection
model [72]. Though great progress has been achieved, selecting features and
obtaining large training datasets is challenging.

###  2.3 Code Obfuscation

Code obfuscation refers to the process of leveraging transformations to make
functionally equivalent programs that are difficult to understand, aiming to
protect the intellectual property of developed software or hide malicious
behaviors. Such transformations include encoding data, opaque predicates [65],
flattening control flow [40], etc. For example, [41] proposed a Mixed Boolean-
Arithmetic (MBA) expression to mix the bitwise operations (e.g., AND, OR, and
NOT) and arithmetic operations (e.g., ADD and IMUL), thereby creating more
difficulties for attackers to analyze programs. In modern software
development, obfuscation has been used to protect critical code parts against
reverse engineering [31]. However, the significant progress of LLMs challenges
existing code obfuscation-based protection approaches, questioning whether
existing obfuscation can still be effective against LLMs-based de-obfuscation
and preserve sensitive information in developed software. Hence, it becomes
urgent to evaluate the code analysis results of LLMs when code is obfuscated.
In this work, we leverage an open-source JavaScript obfuscation tool [10] to
generate obfuscated code and investigate whether LLMs are able to understand
their functionality. As presented in Listing 1 and Listing 2, a simple "Hello
World" function written in JavaScript can be changed into an unintelligible
one.

Listing 1: No Obfuscation

⬇

1// Paste your JavaScript code here

2function hi() {

3 console.log("Hello␣World!");

4}

5hi();

Listing 2: After Obfuscation

⬇

1function _0x1ec3(){var
_0x3ed452=[’259790KgLPlj’,’297688NTFutg’,’35ACWDkX’,’145716kEyGyf’,’18SFCPKB’,’1701952aKOEga’,’192jjwxUU’,’5LPjNwr’,’142417rtWDUq’,’Hello\x20World!’,’121610lhBPGW’,’2032200UghFpX’,’5nCOmEq’,’log’];_0x1ec3=function(){return
_0x3ed452;};return _0x1ec3();}(function(_0x22b342,_0x360ffb){var
_0x5047be=_0xfb3c,_0x4c7c5c=_0x22b342();while(!![]){try{var
_0x40c3be=parseInt(_0x5047be(0x90))/0x1*(-parseInt(_0x5047be(0x8e))/0x2)+-parseInt(_0x5047be(0x95))/0x3+parseInt(_0x5047be(0x97))/0x4*(parseInt(_0x5047be(0x99))/0x5)+parseInt(_0x5047be(0x8f))/0x6+parseInt(_0x5047be(0x94))/0x7*(parseInt(_0x5047be(0x93))/0x8)+parseInt(_0x5047be(0x96))/0x9*(-parseInt(_0x5047be(0x92))/0xa)+parseInt(_0x5047be(0x9a))/0xb*(-parseInt(_0x5047be(0x98))/0xc);if(_0x40c3be===_0x360ffb)break;else
_0x4c7c5c[’push’](_0x4c7c5c[’shift’]());}catch(_0x33f4b4){_0x4c7c5c[’push’](_0x4c7c5c[’shift’]());}}}(_0x1ec3,0x52a68));function
_0xfb3c(_0x257a0b,_0x17c420){var _0x1ec321=_0x1ec3();return
_0xfb3c=function(_0xfb3ca7,_0x44b6b2){_0xfb3ca7=_0xfb3ca7-0x8d;var
_0x34ca8b=_0x1ec321[_0xfb3ca7];return
_0x34ca8b;},_0xfb3c(_0x257a0b,_0x17c420);}function hi(){var
_0x2da467=_0xfb3c;console[_0x2da467(0x91)](_0x2da467(0x8d));}hi();

##  3 Experiment Settings

We first conduct a systematic analysis of the ability of LLMs to perform code
analysis-related tasks. In this section, we introduce the models and datasets
used in our experiments.

###  3.1 LLM Selection

In our analysis, we select four representative popular LLM models to deploy:

  * •

GPT-3.5-turbo: GPT-3.5 is a set of LLMs offered by OpenAI, and it is the
default model that is used for the popular LLM web tool ChatGPT [51].

  * •

GPT-4: GPT-4 is improved based on GPT-3.5 and it has been reported to be able
to handle different types of tasks [18]. It is also one of the most advanced
general-purpose LLMs currently.

  * •

LLaMA-2-13B [60]: LLaMA is a set of foundation LLMs offered by Meta, with
model parameter sizes ranging from 7B to 70B. LLaMA-2-13B contains 13B
parameters and is reported to output a lot of larger models. We select
LLaMA-2-13B as a representative medium-size LLM.

  * •

Code-LLaMA-2-13B-Instruct [55]: Code LLaMA is a family of LLMs provided by
Meta, using the previously mentioned LLaMA family as foundation models. Code-
LLaMAs are fine-tuned on code data, and it has been reported to outperform
other public models targeting code-related tasks.

We select these models for the reason that they are widely used and are the
current state-of-the-art publicly-available LLMs with the capability to
perform code tasks.

###  3.2 Non-Obfuscated Code Dataset

In this study, we aim to systematically evaluate the ability of LLMs to
analyze, comprehend, and summarize code. We first construct a non-obfuscated
source code dataset. Three languages are selected in this phase of study:
JavaScript, Python, and C. We select JavaScript and Python since they are
ranked the top $2$ most used languages on Github [33] and we use them as the
representatives of scripting languages. We select C as it is also ranked high
(#9) and it can be the representative of lower-level programming languages.
All three languages we select are widely deployed over the Internet and in
various computing systems.

For JavaScript, we employ the combination of:

  * •

The Octane 2.0 benchmark [11], which is a JavaScript benchmark to test
JavaScript performance. It contains benchmarks to test typical functionalities
of JavaScript users.

  * •

A list of practical JavaScript applications [5], including password generator,
etc.

For Python, we use the Python branch of the CodeSearchNet dataset [36]
provided by Google. It contains samples of Python projects crawled from the
Internet.

For C, we utilize the combination of:

  * •

A list of classic performance benchmarks, including CoreMark [30], Dhrystone
[63], Hint Benchmark [35], Linpack [29], NBench [54], Stream Benchmark [43],
TripForce [3] and Whetstone [28].

  * •

A subset of the POJ-104 dataset [46, 7], which consists of C code samples to
solve $104$ different programming problems in an OJ system. The POJ-104
dataset provides multiple different solutions for each programming problem. In
this study, for each programming problem, we randomly select one file from the
POJ-104 dataset to form the dataset used in this work.

For each code file in our dataset, we develop scripts to automatically remove
comments and eliminate their impacts on analysis results. Our goal is to let
LLMs focus on code, without providing too many natural language hints in code
comments.

The histograms regarding the line of code (LoC) distributions of processed
files are shown in Figure 1. We can see that our dataset includes code samples
spanning from very short (only a few lines) to very large-scale (over $10$k
lines). Besides, the code samples in our dataset are from different sources
covering different use cases. We believe the coverage of this dataset is
sufficient, since we have chosen the most popular programming languages and
selected a diverse set of code samples of different scales from different
application scenarios.

(a) C.

(b) Python.

(c) JavaScript.

(d) Overall.

Figure 1: Histograms regarding LoC statistics of our non-obfuscated source
code dataset.

###  3.3 Obfuscated Code Dataset

We choose to perform obfuscation on the JavaScript branch of our non-
obfuscated code dataset. This choice was driven by the prevalence of code
obfuscation practices in the JavaScript language, since JavaScript code is
usually visible to web users, making additional obfuscation protection
necessary. Besides, malicious JavaScript developers will also apply
obfuscation techniques to their code to hide the actual intent of their
scripts. We use an open-source tool to generate the obfuscation version of our
JavaScript code [10]. We apply $4$ different commonly-seen obfuscation schemes
to our dataset, including:

  1. 1.

Default obfuscation (DE), which replaces identifier names with meaningless
randomly generated strings, simplifies source code to reduce readability,
placing strings in separate arrays, etc. [10]

  2. 2.

Dead code injection (DCI), which inserts random unrelated code blocks to the
source code [26] in addition to the default scheme.

  3. 3.

Control flow flattening (CFF), which transforms the structure of a program and
hides control flow information [40] in addition to the default scheme.

  4. 4.

Split string (SS), which splits long strings into shorter chunks in addition
to the default scheme to alleviate information leakage from embedded texts
[66].

By testing the performance of LLMs on these obfuscated code samples, we will
be able to understand how classic obfuscation techniques impact the ability of
LLMs to understand

Besides obfuscating our previously acquired source code, we also combine
existing obfuscated code from online resources. We integrate winner code
samples from the International Obfuscated C Code Contest (IOCCC) [9], which is
a contest that challenges participants to write the most obscure and confusing
C code. Instead of asking LLMs to explain the code, we consider adding an
extra challenge to generate de-obfuscated code and see if the generated code
can be compiled and run. Experiments on this part of our obfuscated code
dataset evaluate the performance of LLMs when facing more flexible and non-
standard obfuscation techniques.

Figure 2: Diagram of our experiment pipeline.

###  3.4 Measurement Method

After collecting the response of code analysis from our target LLMs, we start
a manual validation process to check the correctness of the analysis results.
Since all the source code files we employ only come with a maximum of a few
tens of lines of concise comments and the description labels attached (if
there are any) are also succinct, we can not rely on directly applying certain
quantitative metrics (e.g., n-gram [17]) to determine the correctness of
generated analysis results, which necessitates a manual validation process.

Ground Truth. We choose to first manually examine the outcomes of GPT-4 [57],
since it has better natural language generation and deduction capability. We
manually compare the generated explanation for each code file and label the
generation results ‘correct’ if the functionality of the code and the
description match. After this step, we consider those descriptions marked
‘correct’ as the ground truth and use those descriptions for further
comparison.

Comparison Metrics. When evaluating the generated explanation (either non-
obfuscated or obfuscated), we utilize the following metrics:

  1. 1.

Cosine similarity (ranging from $0$-$1$), since it is widely used in natural
language processing-related tasks and can serve as a coarse grain metric in
this study;

  2. 2.

A Bert-based semantic similarity score [4] (ranging from $0$ to $5$) that is
more advanced in comparing the similarity of natural language inputs;

  3. 3.

ChatGPT-based evaluation [71, 25, 68, 18] (True or False). In our evaluation,
GPT-4 model will receive the following instructions first:

Instruction:

“You are given two descriptions of two code snippets: Description 1 and
Description 2. Corresponding code snippets are not available. From the given
text, do you think the two descriptions correspond to two code snippets with
roughly similar functionalities? Output should be "Yes" if similar, or "No"
otherwise, followed by a brief justification of how this is determined.”

We then use the generated output to examine the correctness of each model.

##  4 Results

In this part, we present our results on our non-obfuscated code dataset and
obfuscated code dataset, mainly to answer the two research questions raised in
Section LABEL:SecIntro:

  * •

RQ1: Do LLMs understand source code? (Section 4.1)

  * •

RQ2: Can LLMs comprehend obfuscated code? (Section 4.2)

We also present findings in our experiments.

###  4.1 Results on Non-Obfuscated Code Dataset

GPT-4 Results. The manually verified accuracy results of GPT-4 are shown in
Figure 3. We can see from Figure 3 that the accuracy performance of GPT-4 on
the three languages (C, JavaScript, and Python) is high. For all of the three
languages, over $95\%$ of the analysis generated by GPT-4 aligns with the
actual content of the code samples. The overall accuracy rate is $97.4\%$,
indicating that GPT-4 can serve as a powerful code analysis tool.

Figure 3: GPT-4 accuracy.

After meticulously analyzing the generated outputs of GPT-4, we also have the
following interesting findings.

Finding 1: GPT-4 is able to recognize code snippets from popular open-source
software repositories.

It has been reported that LLMs can leak memorized information acquired from
training during conversations [21]. In our experiments, we observe this
phenomenon multiple times. For example, our dataset contains source code files
from Heron project [8], a real-time analytics system developed by Twitter.
Even though the source code has been de-commented and does not contain the
keyword “Twitter”, GPT-4 still successfully connects the source code with
Twitter by stating: “The code is written in Python and is part of the Heron
project, a real-time stream processing framework developed by Twitter.” at the
beginning of its response. In another example, when we feed GPT-4 with a local
JQuery copy from the Octane benchmark set, GPT-4 also successfully recognizes
that the provided code is from the JQuery library:“The provided code is a part
of the jQuery library, …” at the beginning of its response. The same
phenomenon is also observed in the responses from other models, e.g. GPT-3.5.

This indicates that the training data of these models contain code samples
from popular open-source repositories, and LLMs are able to connect the
provided code snippets with their memorized information. This might be helpful
when analyzing code, since being able to connect source code with existing
software implementation can accelerate the process of understanding the intent
of target code snippets. Please note that this finding does not suggest that
we are conducting our experiments in a “test on training set” manner. In our
experiments, we focus on examining the generated detailed explanation of each
function/code sample, which is more likely deducted from the source code and
unlikely to be contained in the training set.

Finding 2: GPT-4 occasionally makes wrong associations.

In our experiments, though GPT-4 has a high analysis success rate, there are
still a few code samples that GPT-4 cannot correctly analyze. When using GPT-4
for analyzing a Python file related to stock market utilities, GPT-4
incorrectly concludes that the code uses the pandas package, even though it is
not imported in the code sample. We believe this is caused by matplotlib and
numpy packages being imported. These packages usually appear together in data
analytics scripts that are likely part of the training set. GPT-4 possibly
makes an incorrect association based on its memorized contents.

Finding 3: GPT utilizes information provided in identifier names to assist
code analysis.

It is intriguing to find that as a language model, GPT-4 utilizes natural
language hints embedded in identifier names to assist code analysis like
humans. For example, during the analysis for the CoreMark benchmark, GPT-4
recognizes identifiers named “ee_u8”, “ee_u16”, etc. are custom data types and
concludes that the underlying mapping may vary across different embedded
systems. During analyzing the JavaScript Octane benchmark, GPT-4 successfully
recognizes that the code samples are used for benchmarking/testing simply from
the appearance of a variable name “Benchmark”. This suggests that the LLMs
will be able to generate higher-quality analysis and provide more information
on clearly written code.

Analysis Accuracy of Other Selected Models. In Figure 4, we present the cosine
similarity score [Figure 4 (a)], Bert-based semantic similarity [Figure 4 (b)]
and accuracy of code explanation measured by GPT-4 [Figure 4 (c)]. We can see
that GPT3.5 achieves similar performance as GPT-4, indicating that both models
can achieve high performance in code analysis tasks. However, for the
LLaMA-2-13B model, the accuracy performance is low. Only a small portion of
its analysis results align with our ground truth. More findings obtained by
manually examining the generated results are provided below.

(a) Cosine similarity score.

(b) Bert-based semantic similarity scores, with the evaluator trained on web
data.

(c) ChatGPT measured accuracy results.

Figure 4: Similarity score/accuracy of analysis results generated by different
models.

Finding 4: Smaller models in our experiments (LLaMA-2-13B and Code-
LLaMA-2-13B-instruct) are unable to generate consistent paragraphs of code
analysis results, unlike GPT-3.5 and GPT-4.

While performing the designated code analysis tasks, instead of generating
consistent paragraphs, we observe that LLaMA-2-13B tries to repeat questions
and generates hints to itself. Rather than generating paragraphs to answer the
question directly, LLaMA-2-13B tends to generate multiple short and
inconsistent statements. In many cases, LLaMA-2-13B rephrases the input
question to a semantically different one (e.g. it rephrases “Analyze the
following piece of code ” to “Please tell me what this code does and what are
the vulnerabilities in this code.”). When handling long code samples,
LLaMA-2-13B tends to simply return part of the input code. These phenomena
indicate that LLaMA-2-13B does not have the ability to process code analysis-
related tasks.

The Code-LLaMA-2-13B-instruct model, which is based on LLaMA-2-13B and fine-
tuned on code samples, performs even worse. It cannot generate meaningful text
from our observation and only slightly modifies the input code and returns as
its response. In a few cases, we even notice that Code-LLaMA returns code
snippets from other files with slight modifications. Therefore, we do not
include its performance results in Figure 4. These phenomena indicate that
Code-LLaMA-2-13B-instruct, even though it is fine-tuned on code, is not
suitable for doing code analysis tasks.

Answer to RQ1: In our evaluation, for unobfuscated code, larger models like
GPT-3.5 or GPT-4 have a high probability of generating correct and detailed
explanations for input code snippets, while the smaller models, even fine-
tuned on code data, fail to generate correct outputs.

###  4.2 Results on Obfuscated Code Dataset

Obfuscated Code Analysis Capability Evaluation. We first focus on analyzing
the obfuscated JavaScript code samples. We use the same prompt to instruct
LLMs to analyze code and generate explanations as in the previous part.
Results regarding similarity scores and accuracy of obfuscated code analysis
are shown in Figure 5.

(a) Cosine similarity score.

(b) Bert-based semantic similarity scores, with the evaluator trained on web
data.

(c) ChatGPT measured accuracy results.

Figure 5: Similarity score/accuracy of obfuscated code analysis results
generated by different models.

From Figure 5 (c), we can see that GPT-4 still shows exceptional analysis
accuracy, reaching $87\%$ accuracy. GPT-3.5, on the other hand, is impacted by
obfuscation techniques, especially when more advanced techniques are applied
(control flow flattening, dead code injection, and split string). As for
similarity score metrics shown in Figure 5 (a) and (b), we can see that both
models suffer a performance degradation, yet the similarity scores of GPT-4
are constantly higher than GPT-3.5. These results indicate that when facing
obfuscated code analysis, GPT-4 is a better choice. There are other findings
as presented below:

Finding 1: Both LLaMA-2-13B and Code-LLaMA-2-13B-instruct are unable to
generate meaningful explanations once obfuscation techniques are applied.

In our experiments, we find that both models are unable to generate meaningful
results. In most cases, they simply return part of the obfuscated code that is
sent. Therefore, we do not include results from LLaMA-2-13B and Code-
LLaMA-2-13B-instruct in Figure 5. These results again indicate that these two
relatively small LLaMA models do not possess the ability to perform code-
analysis tasks properly.

Finding 2: Basic obfuscation techniques (such as DE in our paper) only
slightly influence the ability of GPT models to perform code analysis.

In our experiments, we found that basic obfuscation techniques like replacing
identifier names do not significantly impair the ability of GPT models to
produce analysis results. Indeed, both models lose information contained in
identifier names, but they are still able to extract sufficient information
from the execution flow and remaining strings and provide relatively reliable
explanations.

De-Obfuscated Code Generation. Besides comparing code explanation results on
the obfuscated JavaScript dataset, we also test the ability of LLMs to
generate de-obfuscated code. Since it is a challenging task, we only perform
this evaluation on the two most powerful models we have, i.e. GPT-3.5 and
GPT-4. We select $100$ contest winner projects after the year 2011 competition
of IOCCC [9] and instruct LLMs to perform code de-obfuscation tasks. LLMs are
prompted:

“You are an expert in code analysis. De-obfuscate the code and generate a
readable new version.”

and we directly feed the original code to LLMs. We select IOCCC because a more
diverse and flexible set of obfuscation techniques are applied, compared to
our automatically generated JavaScript dataset.

We evaluate the ability of LLM to generate de-obfuscated code from the
following $3$ aspects:

  1. 1.

whether code can be generated;

  2. 2.

(if generated) whether the generated code can pass compilation;

  3. 3.

(if compilable) whether the compiled code produces correct outputs.

Corresponding statistical results are presented in Figure 6. Our findings are
presented below.

Figure 6: Success rate of different models regarding de-obfuscation tasks.

Finding 3: Both GPT models in our evaluation fall short of generating
compilable and runnable de-obfuscated code.

As shown in Figure 6, for GPT-3.5, although it successfully produces code
outputs for all targets, only around $20\%$ of its output code samples are
compilable, and only $8\%$ of generated code samples ($38\%$ of compiled code
samples) can produce correct results. The performance of GPT-4 is worse than
GPT-3.5. It is able to generate de-obfuscated code for only $76\%$ of
experimented code samples. Only $19\%$ of all experimented code samples
($25\%$ of generated code) successfully pass the compilation step, and only
$4\%$ of all experimented code samples ($21\%$ of compiled code) produce
correct results. These statistics indicate that despite the strong ability to
produce explanatory analysis results, their performance on de-obfuscated code
generation is unsatisfying.

It is interesting to note that GPT-3.5 beats GPT-4 on these metrics in the
code de-obfuscation task, despite the fact that it is a less advanced model.

Finding 4: GPT-4 has a higher probability of associating given code samples to
the IOCCC contest. However, details are incorrect.

By examining responses generated by both models, we find that GPT-4 recognizes
that $22$ of the provided code samples belong to the IOCCC contest, while
GPT-3.5 is only able to identify $2$ of them. This indicates that despite
IOCCC code samples being included in the training set of both models, GPT-4 is
able to better associate the given input to its knowledge. However, when it
tries to identify specific code samples, i.e., provide exact year and author
names, the answers are wrong. For example, during our analysis, it identified
code sample that was awarded “Best Handwriting in 2015” as “Best One-Liner in
2015”. We then asked “What is the Best One-Liner award receiver of IOCCC
2015?”, and got a different but still incorrect answer that seems to be made
up by GPT-4. This indicates that the given incorrect information is possibly
not caused by misalignment in the training data.

Finding 5: GPT-4 has a higher probability of refusing to perform code-
generation tasks.

As shown in Figure 6, GPT-4’s performance is significantly worse than GPT-3.5
in this task, especially at the code generation step. We observe that GPT-4
will admit that the code is obfuscated and requires lots of expert work to
decipher, instead of generating code without additional remarks like GPT-3.5.
By examining code samples that GPT-4 refuses to generate, we find that there
are two factors that can potentially cause the failure of de-obfuscation:

  1. 1.

Code contains complicated logic.

  2. 2.

Code is formatted in a special style, unlike the traditional line-by-line
organization.

(a) 2013/cable2/prog.c .

(b) 2013/misaka/misaka.c .

(c) 2019/giles/prog.c .

Figure 7: Samples of specially-formatted code.

Examples of specially formatted code snippets are shown in Figure 7. To rule
out this factor, we select the POJ-104/9/1618.c sample code from the C branch
of our non-obfuscated dataset and apply variable substitution and
reformatting, resulting in a code snippet that is extremely hard to decipher
with manual effort [Figure 8 (a)]. We also select a file from the IOCCC
dataset (blakely.c from IOCCC 2011) and reformat the file to a normal format
[Figure 8 (b) and (c)].

(a) Reformatted code sample from POJ-104 dataset.

(b) 2011/blakely/blakely.c .

(c) Reformatted 2011/blakely/blakely.c .

Figure 8: Reformatted code.

In the first scenario, despite the obfuscation techniques applied, GPT-4 is
still able to generate correct explanations as well as de-obfuscation results.
In the second case, GPT-4 continues to refuse to generate de-obfuscated code.
This leads to our next finding:

Finding 6: Text-level obfuscation does not influence the abilities of LLMs to
perform de-obfuscation.

This also aligns with our findings while conducting analysis of the JavaScript
code, indicating that employing complex logic is the only way to trick LLMs.

Finding 7: GPT-4 generates code with higher readability.

Despite worse performance on code generation success rate, we find that code
generated by GPT-4 has higher readability compared to code generated by
GPT-3.5. GPT-4 is able to generate meaningful identifier names more often,
while part of the GPT-3.5-generated code still seems obfuscated. This
indicates that GPT-4 is still a better generative model if we take the quality
of the generated code into consideration.

Answer to RQ2: Obfuscation techniques can impact the ability of LLMs to
generate explanations. Smaller models in our experiments are unable to handle
obfuscated code. GPT-3.5 and GPT-4 both drops in analysis accuracy, though
GPT-4 still has an acceptable and better accuracy performance. Without special
optimization targeting de-obfuscated code generation, LLMs show a poor ability
to generate functional de-obfuscated code.

##  5 Case Studies

In this section, we conduct two case studies and show how the capability of
LLMs can be utilized for defensive static analysis. We select the Android msg-
stealer virus and the WannaCry ransomware [47] as our targets. Both viruses
have been found in the real world. In both cases, code samples are directly
obtained from decompilers. Decompiled and obfuscated code have a lot in
common: both do not contain meaningful identifier names, and the control flow
may not be straightforward.

###  5.1 Mobile Platform Virus Analysis

In our first case study, we focus on analyzing a decompiled Android virus from
the Internet. We utilize Java Decompiler [1] to decompile an android virus
called msg-stealer, obtained from [2]. As indicated by its name, this virus
maliciously steals SMS messages from Android mobile phone users. By using jd-
gui, a graphical utility provided by the Java Decompiler , we successfully
decompile the .apk file of the virus and generate $908$ .java files,
containing $\sim 250$k LoC. We feed every decompiled code file to both GPT-3.5
and GPT-4 and get $908$ code analysis responses in return. After that, we
instruct GPT-4 to read the analysis and give alerts if there are any abnormal
or potentially malicious behaviors. The diagram of our experiment pipeline is
shown in Figure 9.

Figure 9: Diagram of our Android case study pipeline.

This virus works in the following way:

  1. 1.

Upon signing up, it requires users to enter a phone number. It checks if the
entered phone number is from Iran (+98). If so, it requests to gain SMS
sending and reading privileges.

  2. 2.

It then continues to establish a connection using a specific URL.

  3. 3.

When an SMS message is received, it reads the whole packet of information and
performs a string match. Upon a successful match, the virus sends the content
of the SMS message to a specific site.

These functionalities are spread across $3$ different code files.

By examining the analysis generated by GPT-3.5 and GPT-4, we find that both
have correctly deciphered these behaviors from the decompiled source code.
Part of the responses from GPT-3.5 are shown below:

Response 1:

“… the code validates the entered phone number using a regular expression. If
the phone number is not valid, a toast message is displayed. Otherwise, the
code requests the ‘RECEIVE_SMS’ permission and checks if the permission is
granted.” (Step 1)

Response 2:

“… it builds a URL string by appending the ‘url’ and ‘info’ (user phone
number) parameters to a base URL. It then sends a GET request to this URL
using the AndroidNetworking library’s ‘get()‘ method.” (Step 2)

Response 3:

“… it retrieves the SMS messages from the intent extras, retrieves the message
body, and concatenates all message bodies into a single string. It then checks
if the string contains the text "(a trigger string in Persian)" and if so, it
updates a shared preference value named "lock" to "off". Finally, it uses the
‘connect‘ class to perform some action using the phone number retrieved from
the shared preferences and the concatenated string of SMS messages.” (Step 3)

These behaviors are apparently suspicious, since it requests SMS read/write
privilege (sensitive privilege) and communicates with and sends SMS messages
to a remote site. However, when we feed GPT-4/GPT-3.5 with its analysis
results and ask “Is there any potentially malicious behavior?”, we have the
following interesting observations.

Observation 1:

When feeding analysis results regarding the three steps independently, both
GPT-3.5 and GPT-4 fail to recognize the potentially malicious behaviors.

Observation 2:

When concatenating the information together and feeding to LLMs, only GPT-4
successfully points out potentially malicious behaviors.

These observations indicate that GPT-4 possesses a better capability to
understand natural language inputs and GPT-4 would be a better choice to
process the massive analysis results. However, our observations also suggest
that when using these LLMs for defensive analysis, it is important to provide
enough context otherwise LLMs will fail to detect security issues.

###  5.2 WannaCry Ransomware Analysis

In another case study, we aim for a more realistic target and analyze a
desktop virus to showcase if LLMs can be utilized to perform defensive
analysis on decompiled code. We select a malicious software called WannaCry
(also named WanaCrypt0r) [45], which is a ransomware that posted shockingly
devastating damages to various organizations and personal users in 2017.
WannaCry ransomware attack uses the EternalBlue exploit to compromise Windows
Service Message Block Protocol (SMBv1) and propagates itself through TCP port
445 [47, 38]. Once residing on a computer, it encrypts user files and demands
a ransom paid in bitcoins. It is reported that WannaCry ransomware has
impacted hospitals [49] and large companies including Nissan [27], TSMC [50],
etc.

In this case study, we directly feed the decompiled code file of WannaCry [6]
generated by an open-source decompiler RetDec [12] to LLMs. We aim to analyze
the behaviors of WannaCry, and test the ability of LLMs to understand and
analyze code. The decompiled code file contains around $11$k lines of C code
and automatically generated comments. The decompiled C code does not include
meaningful functions and variable names. It has identifier names such as
function_401000 and g33 that do not provide useful contextual information. The
automatically generated comments only specify memory addresses of functions
and branches, as well as a list of functions that are statically or
dynamically linked.

To feed the generated code to LLMs, we input the generated code to LLMs in an
interactive manner. In the first prompt, we state that we will input a code
file for it to analyze, and it may consist of multiple chunks of code due to
the length restrictions of input. For shorter functions, we copy and paste
$3$-$5$ functions in one round of query and obtain the response of analysis.
For longer functions whose length exceeds the length limit of input, we
partition the body of functions into multiple parts, each consisting of
$200$-$500$ lines of code. A sentence is first provided to LLMs, stating that
this is a long function and will be input as multiple chunks of code. Starting
from the second chunk of code, we state that “the following code snippet is
the remaining part of the previous function”. After the last partition of
code, we manually add a comment “// function ends” to indicate the end of the
function. No other manual operation is involved during the experiment. We
select to use GPT-3.5 in this experiment, since it is one of the easiest
accessible and most popular chatbot-based LLMs.

Part of the analysis results from GPT-3.5 that we consider interesting and
important are shown below. For the whole record of our experiment, please
refer to our online appendix.

Response 1:

“… Overall, these functions handle networking tasks. The first,
function_4072a0, seems to be part of a more complex communication protocol,
while the second, function_407480, checks for the ability to connect to port
445.”

Response 2:

“… This is interesting functionality, especially the last function. The
program is attempting to create a Windows service named “mssecsvc2.0”, which
sounds similar to a legitimate Microsoft Security service. This could indicate
malicious or at least suspicious behavior, as it seems like the program is
trying to disguise itself as a legitimate service.” (function_407c40)

Response 3:

“…$\bullet$ Initializes a URL string pointing to
http://www.iuqerfsodp9ifjap{…}jfaewrwergwea.com.
$\bullet$ Uses the Windows Internet (WinINet) API to open an internet session
and attempts to open the URL.
$\bullet$ Closes the internet handles after the operations.
$\bullet$ If it’s successful in opening the URL, it closes the internet handle
and returns, else it calls function_408090.
$\bullet$ This function seems to be checking for the availability of a
specific website, possibly as a kind of “alive” check or to determine network
connectivity. …” (function_408140)

Response 4:

“… The two goto labels lab_0x408755_9 and lab_0x4087c3_9 are exit points or
continuation points, but the actual code for these labels is not present in
the segment. They might direct the code to other parts of the function based
on specific conditions. …”

Response 5:

“… From the provided data, it’s challenging to pinpoint the exact purpose of
the application, but it seems like a complex program that could serve as a
service or a daemon on Windows, handling network communication, possibly
acting as a server or a service manager, with capabilities for file handling
and other utility tasks. However, this is a speculative overview based on the
given context, and a more detailed analysis would be required to confirm
this.”

From the findings presented above, we found that GPT-3.5 is capable of
analyzing a relatively large-scale decompiled c codebase with low readability.
It correctly extracts critical behaviors of our target ransomware, including:

  * •

Checking connectivity to port 445 (Response 1);

  * •

Creating service named mssecsvc2.0 (Response 2);

  * •

Querying a special url for “alive” check (Response 3).

These critical findings partially align with publicly available analysis of
WannaCry [44], as these are also considered important behavioral watermarks of
WannaCry ransomware. However, there are differences indicating that the
analysis is not fully correct. For example, according to the technical report
provided by Microsoft [44], the purpose of initiating mssecsvc2.0 service is
to exploit the SMB vulnerability, instead of simply disguising itself.
However, considering the lack of context information and the fact that GPT-3.5
correctly raises security concerns, this still demonstrates the capability of
LLMs in defensive analysis.

However, there are other observed weaknesses of GPT-3.5:

Observation 1:

Code address labels are ignored and not remembered.

In Response 4, GPT-3.5 replies that code for two labels is not provided. Yet
the code labels actually reside in the same function body and were provided to
GPT-3.5 a few rounds of queries ago due to the excessively long function body.
By looking back at the dialog record, we find that these labels are also not
mentioned in the response at the corresponding round of query. This indicates
that these labels are ignored, and not remembered during later processing. The
incapability to capture and remember important code information will hinder
the ability of LLMs to analyze long code bodies with more complicated context,
considering the rather strict input limit of each query.

Observation 2:

GPT-3.5 is conservative in providing conclusive remarks.

During our experiment, GPT-3.5 repeatedly mentions the need for more context
and its incapability to draw a conclusion about the intent of the provided
code. In the conclusive Response 5, it simply generates generic descriptions.
We suspect that GPT-3.5 learned the strategy to conservatively provide
information to improve the score of outputs during training.

Summary. In this case study, the analysis results of WannaCry show that
GPT-3.5 is able to capture the most important behaviors of this ransomware and
successfully provide a security alert (Response 2). Despite the observed
weaknesses, we confirm that LLM models like GPT-3.5 are able to extract
important information from decompiled code and raise security concerns if
there are any. This experiment shows LLMs’ superior ability in performing code
analysis and summarization, considering that the provided code has extremely
low readability and there is no extra context. Though at this point, LLMs
cannot replace expert human beings, they can still serve as an initial code
analysis assistant to accelerate the reverse engineering of software and aid
defensive code analysis.

##  6 Discussion

###  6.1 Using LLMs for Code Analysis

As shown in our analysis results, more advanced LLMs (e.g. GPT-3.5, GPT-4)
have a higher success rate of generating explanations for input code samples.
However, as found out in our analysis, smaller ones have poor performance, and
the results are not always reliable even for larger LLMs, especially when
complicated code obfuscation is involved. Smaller general-purpose LLMs, even
when specifically fine-tuned for coding tasks, struggle to produce meaningful
results. These findings suggest that at this point, utilizing larger LLMs are
still the safer choice for code analysis-related tasks.

###  6.2 Future Work

This work sheds light on some possible future directions in this area. First
of all, there is a gap in the literature about obfuscated code datasets. Most
works only focus on the ability to analyze normal code, without integrating
obfuscation techniques. Constructing such a large dataset would enable LLM
users to fine-tune pre-trained LLMs specifically for code analysis tasks
quickly. Second, in this paper, we report several interesting observations
regarding the memorization phenomena of LLMs [21]. The underlying mechanisms
still remain to be explored. Third, regarding similarity metrics, while the
n-gram algorithm-based metric has been reported to be suboptimal in capturing
semantic similarities [68], during our experiments, the newly employed
ChatGPT-based method [71, 25, 68, 18] is also not reliable and requires manual
work to calibrate, especially when code snippets and natural languages are
combined together in the inputs. We believe constructing a more sophisticated
metric that captures the essence of code analysis results is non-trivial and
could be one research direction.

##  7 Related Work

Code Analysis. Code analysis is crucial in modern software development to
identify vulnerabilities and ensure code quality. The significant progress in
artificial intelligence (AI) motivates researchers to adopt advanced AI models
to improve more effective code analysis. Mou et.al [46] proposed to use CNNs
to analyze syntax trees of programs. Feng et.al [32] targets detecting
vulnerability by collecting features from extracted syntax trees and employing
a Bi-GRU network to identify bugs in general code. The development of natural
language processing techniques, especially transformers and LLMs,
significantly boost this area. Chen et.al [24] employ a transformer-based
method to automatically predict variable names and types from decompiler
outputs, thus dramatically improving the readability of decompiler-generated
code. Similarly, Xu et.al [67] also proposes to use LLMs to assist in handling
decompilation tasks. It presents that using an iterative algorithm with
multiple LLM queries can improve the decompilation results.

LLM Evaluation. As LLMs become prevalent in recent years, there are a surging
number of review or analysis papers focusing on LLM’s capabilities. Bubeck
et.al [18] analyze the capabilities of GPT-4 from different aspects, including
vision, coding, and mathematics-related tasks and discuss the societal impacts
of such LLMs. A recent survey [15] focuses on security aspects of LLMs and
summarizes several attack and defence works on LLMs and points out future
directions of research in this field. Regarding analysis and evaluation of
code-related capabilities of LLMs, Chen et.al [23] evaluate LLMs trained on
code. However, their focus is primarily on the code generation aspects. The
work that is closest to ours is [68]. In the paper, they conduct an analysis
of the ability of instruction-tuned and fine-tuned LLMs to perform code
comprehension and generation tasks. However, code-obfuscation-related tasks,
including obfuscated code comprehension and de-obfuscated code generation, are
not included.

##  8 Conclusion

In this paper, we have conducted a thorough evaluation of the code analysis
capabilities of popular Large Language Models (LLMs). Our results reveal that
the larger LLMs, specifically from the GPT series, exhibit impressive
performance in code analysis tasks. On the other hand, the smaller models from
LLaMA family evaluated in this paper demonstrate unsatisfying performance in
these same tasks. When it comes to analyzing obfuscated code, the GPT-series
LLMs still produce reasonably useful results for explanation-related tasks;
however, they do encounter limitations in providing de-obfuscated code. Our
study also uncovers intriguing findings such as LLM memorization phenomena.
Our research highlights that, at the present stage, LLMs demonstrate
considerable potential in this field. However, there are still many unexplored
ways to optimize their performance.

## References

  * [1] Java decompiler.  http://java-decompiler.github.io/.
  * [2] Not so boring android malware.  https://maldroid.github.io/android-malware-samples//.
  * [3] tripforce.  https://github.com/microsounds/tripforce, 2016.
  * [4] semantic-text-similarity.  https://github.com/AndriyMulyar/semantic-text-similarity, 2019.
  * [5] js-apps.  https://github.com/jaiimeriios/js-apps, 2022.
  * [6] Wannacry/worm.c.  https://github.com/xcp3r/WannaCry/blob/main/worm.c, 2022.
  * [7] Codexglue/code-code/clone-detection-poj-104/.  https://github.com/microsoft/CodeXGLUE/blob/main/Code-Code/Clone-detection-POJ-104/README.md, 2023.
  * [8] incubator/heron.  https://github.com/apache/incubator-heron, 2023.
  * [9] The international obfuscated c code contest.  https://www.ioccc.org/, 2023.
  * [10] Javascript obfuscator tool.  https://obfuscator.io/, 2023.
  * [11] Octane 2.0.  https://chromium.github.io/octane/, 2023.
  * [12] Retdec.  https://github.com/avast/retdec, 2023.
  * [13] ACM.  Acm policy on authorship.  https://www.acm.org/publications/policies/new-acm-policy-on-authorship, 2023.
  * [14] Dogu Araci.  Finbert: Financial sentiment analysis with pre-trained language models.  arXiv preprint arXiv:1908.10063, 2019.
  * [15] Clark Barrett, Brad Boyd, Ellie Burzstein, Nicholas Carlini, Brad Chen, Jihye Choi, Amrita Roy Chowdhury, Mihai Christodorescu, Anupam Datta, Soheil Feizi, et al.  Identifying and mitigating the security risks of generative ai.  arXiv preprint arXiv:2308.14840, 2023.
  * [16] David Binkley.  Source code analysis: A road map.  Future of Software Engineering (FOSE’07), pages 104–119, 2007.
  * [17] Peter F Brown, Vincent J Della Pietra, Peter V Desouza, Jennifer C Lai, and Robert L Mercer.  Class-based n-gram models of natural language.  Computational linguistics, 18(4):467–480, 1992.
  * [18] Sébastien Bubeck, Varun Chandrasekaran, Ronen Eldan, Johannes Gehrke, Eric Horvitz, Ece Kamar, Peter Lee, Yin Tat Lee, Yuanzhi Li, Scott Lundberg, et al.  Sparks of artificial general intelligence: Early experiments with gpt-4.  arXiv preprint arXiv:2303.12712, 2023.
  * [19] Gerardo Canfora, Massimiliano Di Penta, and Luigi Cerulo.  Achievements and challenges in software reverse engineering.  Communications of the ACM, 54(4):142–151, 2011.
  * [20] Sicong Cao, Xiaobing Sun, Lili Bo, Ying Wei, and Bin Li.  Bgnn4vd: Constructing bidirectional graph neural-network for vulnerability detection.  Information and Software Technology, 136:106576, 2021.
  * [21] Nicholas Carlini, Florian Tramer, Eric Wallace, Matthew Jagielski, Ariel Herbert-Voss, Katherine Lee, Adam Roberts, Tom Brown, Dawn Song, Ulfar Erlingsson, et al.  Extracting training data from large language models.  In 30th USENIX Security Symposium (USENIX Security 21), pages 2633–2650, 2021.
  * [22] Marco Cascella, Jonathan Montomoli, Valentina Bellini, and Elena Bignami.  Evaluating the feasibility of chatgpt in healthcare: an analysis of multiple clinical and research scenarios.  Journal of Medical Systems, 47(1):33, 2023.
  * [23] Mark Chen, Jerry Tworek, Heewoo Jun, Qiming Yuan, Henrique Ponde de Oliveira Pinto, Jared Kaplan, Harri Edwards, Yuri Burda, Nicholas Joseph, Greg Brockman, et al.  Evaluating large language models trained on code.  arXiv preprint arXiv:2107.03374, 2021.
  * [24] Qibin Chen, Jeremy Lacomis, Edward J Schwartz, Claire Le Goues, Graham Neubig, and Bogdan Vasilescu.  Augmenting decompiler output with learned variable names and types.  In 31st USENIX Security Symposium (USENIX Security 22), pages 4327–4343, 2022.
  * [25] Cheng-Han Chiang and Hung-yi Lee.  Can large language models be an alternative to human evaluations?  arXiv preprint arXiv:2305.01937, 2023.
  * [26] Mihai Christodorescu and Somesh Jha.  Static analysis of executables to detect malicious patterns.  In 12th USENIX Security Symposium (USENIX Security 03), 2003.
  * [27] ChronicleLive.  Ransomware cyber attack recap: Nissan confirm they have been hit by hack which crippled NHS.  https://www.chroniclelive.co.uk/news/north-east-news/cyber-attack-nhs-latest-news-13029913, May 2017.
  * [28] Harold J Curnow and Brian A. Wichmann.  A synthetic benchmark.  The Computer Journal, 19(1):43–49, 1976.
  * [29] Jack J Dongarra, Piotr Luszczek, and Antoine Petitet.  The linpack benchmark: past, present and future.  Concurrency and Computation: practice and experience, 15(9):803–820, 2003.
  * [30] EEMBC.  Coremark.  https://www.eembc.org/coremark/, 2022.
  * [31] Abdelrahman Eid.  Reverse engineering snapchat (part i): Obfuscation techniques.  https://hot3eed.github.io/snap_part1_obfuscations.html.
  * [32] Hantao Feng, Xiaotong Fu, Hongyu Sun, He Wang, and Yuqing Zhang.  Efficient vulnerability detection based on abstract syntax tree and deep learning.  In IEEE INFOCOM 2020-IEEE Conference on Computer Communications Workshops (INFOCOM WKSHPS), pages 722–727. IEEE, 2020.
  * [33] Github.  The top programming languages.  https://octoverse.github.com/2022/top-programming-languages, 2022.
  * [34] Github.  Github copilot.  https://github.com/features/copilot, 2023.
  * [35] John L Gustafson and Quinn O Snell.  Hint: A new way to measure computer performance.  In Proceedings of the Twenty-Eighth Annual Hawaii International Conference on System Sciences, volume 2, pages 392–401. IEEE, 1995.
  * [36] Hamel Husain, Ho-Hsiang Wu, Tiferet Gazit, Miltiadis Allamanis, and Marc Brockschmidt.  Codesearchnet challenge: Evaluating the state of semantic code search.  arXiv preprint arXiv:1909.09436, 2019.
  * [37] IEEE.  Submission and peer review policies.  https://journals.ieeeauthorcenter.ieee.org/become-an-ieee-journal-author/publishing-ethics/guidelines-and-policies/submission-and-peer-review-policies/, 2023.
  * [38] Da-Yu Kao and Shou-Ching Hsiao.  The dynamic analysis of wannacry ransomware.  In 2018 20th International conference on advanced communication technology (ICACT), pages 159–166. IEEE, 2018.
  * [39] Enkelejda Kasneci, Kathrin Seßler, Stefan Küchemann, Maria Bannert, Daryna Dementieva, Frank Fischer, Urs Gasser, Georg Groh, Stephan Günnemann, Eyke Hüllermeier, et al.  Chatgpt for good? on opportunities and challenges of large language models for education.  Learning and individual differences, 103:102274, 2023.
  * [40] Tımea László and Ákos Kiss.  Obfuscating c++ programs via control flow flattening.  Annales Universitatis Scientarum Budapestinensis de Rolando Eötvös Nominatae, Sectio Computatorica, 30(1):3–19, 2009.
  * [41] Binbin Liu, Weijie Feng, Qilong Zheng, Jing Li, and Dongpeng Xu.  Software obfuscation with non-linear mixed boolean-arithmetic expressions.  In Information and Communications Security: 23rd International Conference, ICICS 2021, Chongqing, China, November 19-21, 2021, Proceedings, Part I 23, pages 276–292. Springer, 2021.
  * [42] Charles Curtsinger Benjamin Livshits, Ben Zorn, and Christian Seifert.  Zozzle: Low-overhead mostly static javascript malware detection.  In USENIX Security Symposium, 2010.
  * [43] John D McCalpin et al.  Memory bandwidth and machine balance in current high performance computers.  IEEE computer society technical committee on computer architecture (TCCA) newsletter, 2(19-25), 1995.
  * [44] Microsoft.  Wannacrypt ransomware worm targets out-of-date systems.  https://www.microsoft.com/en-us/security/blog/2017/05/12/wannacrypt-ransomware-worm-targets-out-of-date-systems/, May 2017.
  * [45] Savita Mohurle and Manisha Patil.  A brief study of wannacry threat: Ransomware attack 2017.  International journal of advanced research in computer science, 8(5):1938–1940, 2017.
  * [46] Lili Mou, Ge Li, Lu Zhang, Tao Wang, and Zhi Jin.  Convolutional neural networks over tree structures for programming language processing.  In Proceedings of the AAAI conference on artificial intelligence, volume 30, 2016.
  * [47] National Cybersecurity and Communications Integration Center.  What is wannacry/wanacrypt0r?, 2017.
  * [48] Iulian Neamtiu, Jeffrey S Foster, and Michael Hicks.  Understanding source code evolution using abstract syntax tree matching.  In Proceedings of the 2005 international workshop on Mining software repositories, pages 1–5, 2005.
  * [49] Sky News.  NHS cyberattack: List of hospitals hit by ransomware strike.  https://news.sky.com/story/nhs-cyberattack-full-list-of-organisations-affected-so-far-10874493, May 2017.
  * [50] The Hawker News.  Tsmc chip maker blames wannacry malware for production halt.  https://thehackernews.com/2018/08/tsmc-wannacry-ransomware-attack.html, August 2018.
  * [51] OpenAI.  Chatgpt.  https://chat.openai.com/, 2023.
  * [52] OpenAI.  Chatgpt can now see, hear, and speak.  https://openai.com/blog/chatgpt-can-now-see-hear-and-speak, 2023.
  * [53] OpenAI.  Gpt-4 technical report.  2023\.
  * [54] PetaBridge.  NBench.  https://nbench.io/, 2023.
  * [55] Baptiste Rozière, Jonas Gehring, Fabian Gloeckle, Sten Sootla, Itai Gat, Xiaoqing Ellen Tan, Yossi Adi, Jingyu Liu, Tal Remez, Jérémy Rapin, et al.  Code llama: Open foundation models for code.  arXiv preprint arXiv:2308.12950, 2023.
  * [56] Iflaah Salman, Ayse Tosun Misirli, and Natalia Juristo.  Are students representatives of professionals in software engineering experiments?  In 2015 IEEE/ACM 37th IEEE international conference on software engineering, volume 1, pages 666–676. IEEE, 2015.
  * [57] Katharine Sanderson.  Gpt-4 is here: what scientists think.  Nature, 615(7954):773, 2023.
  * [58] Irene Solaiman, Miles Brundage, Jack Clark, Amanda Askell, Ariel Herbert-Voss, Jeff Wu, Alec Radford, Gretchen Krueger, Jong Wook Kim, Sarah Kreps, et al.  Release strategies and the social impacts of language models.  arXiv preprint arXiv:1908.09203, 2019.
  * [59] Rohan Taori, Ishaan Gulrajani, Tianyi Zhang, Yann Dubois, Xuechen Li, Carlos Guestrin, Percy Liang, and Tatsunori B Hashimoto.  Alpaca: A strong, replicable instruction-following model.  Stanford Center for Research on Foundation Models. https://crfm. stanford. edu/2023/03/13/alpaca. html, 3(6):7, 2023.
  * [60] Hugo Touvron, Thibaut Lavril, Gautier Izacard, Xavier Martinet, Marie-Anne Lachaux, Timothée Lacroix, Baptiste Rozière, Naman Goyal, Eric Hambro, Faisal Azhar, et al.  Llama: Open and efficient foundation language models.  arXiv preprint arXiv:2302.13971, 2023.
  * [61] Priyan Vaithilingam, Tianyi Zhang, and Elena L Glassman.  Expectation vs. experience: Evaluating the usability of code generation tools powered by large language models.  In Chi conference on human factors in computing systems extended abstracts, pages 1–7, 2022.
  * [62] Ashish Vaswani, Noam Shazeer, Niki Parmar, Jakob Uszkoreit, Llion Jones, Aidan N Gomez, Łukasz Kaiser, and Illia Polosukhin.  Attention is all you need.  Advances in neural information processing systems, 30, 2017.
  * [63] Reinhold P Weicker.  Dhrystone: a synthetic systems programming benchmark.  Communications of the ACM, 27(10):1013–1030, 1984.
  * [64] Yichen Xie and Alex Aiken.  Static detection of security vulnerabilities in scripting languages.  In USENIX Security Symposium, volume 15, pages 179–192, 2006.
  * [65] Hui Xu, Yangfan Zhou, Yu Kang, Fengzhi Tu, and Michael Lyu.  Manufacturing resilient bi-opaque predicates against symbolic execution.  In 2018 48th Annual IEEE/IFIP International Conference on Dependable Systems and Networks (DSN), pages 666–677. IEEE, 2018.
  * [66] Wei Xu, Fangfang Zhang, and Sencun Zhu.  The power of obfuscation techniques in malicious javascript code: A measurement study.  In 2012 7th International Conference on Malicious and Unwanted Software, pages 9–16. IEEE, 2012.
  * [67] Xiangzhe Xu, Zhuo Zhang, Shiwei Feng, Yapeng Ye, Zian Su, Nan Jiang, Siyuan Cheng, Lin Tan, and Xiangyu Zhang.  Lmpa: Improving decompilation by synergy of large language model and program analysis.  arXiv preprint arXiv:2306.02546, 2023.
  * [68] Zhiqiang Yuan, Junwei Liu, Qiancheng Zi, Mingwei Liu, Xin Peng, and Yiling Lou.  Evaluating instruction-tuned large language models on code comprehension and generation.  arXiv preprint arXiv:2308.01240, 2023.
  * [69] Jian Zhang, Xu Wang, Hongyu Zhang, Hailong Sun, Kaixuan Wang, and Xudong Liu.  A novel neural source code representation based on abstract syntax tree.  In 2019 IEEE/ACM 41st International Conference on Software Engineering (ICSE), pages 783–794. IEEE, 2019.
  * [70] Wayne Xin Zhao, Kun Zhou, Junyi Li, Tianyi Tang, Xiaolei Wang, Yupeng Hou, Yingqian Min, Beichen Zhang, Junjie Zhang, Zican Dong, et al.  A survey of large language models.  arXiv preprint arXiv:2303.18223, 2023.
  * [71] Lianmin Zheng, Wei-Lin Chiang, Ying Sheng, Siyuan Zhuang, Zhanghao Wu, Yonghao Zhuang, Zi Lin, Zhuohan Li, Dacheng Li, Eric Xing, et al.  Judging llm-as-a-judge with mt-bench and chatbot arena.  arXiv preprint arXiv:2306.05685, 2023.
  * [72] Victor Zhong, Caiming Xiong, and Richard Socher.  Seq2sql: Generating structured queries from natural language using reinforcement learning.  arXiv preprint arXiv:1709.00103, 2017.