{"title": "Coda: An End-to-End Neural Program Decompiler", "book": "Advances in Neural Information Processing Systems", "page_first": 3708, "page_last": 3719, "abstract": "Reverse engineering of binary executables is a critical problem in the computer security domain. On the one hand, malicious parties may recover interpretable source codes from the software products to gain commercial advantages. On the other hand, binary decompilation can be leveraged for code vulnerability analysis and malware detection. However, efficient binary decompilation is challenging. Conventional decompilers have the following major limitations: (i) they are only applicable to specific source-target language pair, hence incurs undesired development cost for new language tasks; (ii) their output high-level code cannot effectively preserve the correct functionality of the input binary; (iii) their output program does not capture the semantics of the input and the reversed program is hard to interpret. To address the above problems, we propose Coda1, the first end-to-end neural-based framework for code decompilation. Coda decomposes the decompilation task into of two key phases: First, Coda employs an instruction type-aware encoder and a tree decoder for generating an abstract syntax tree (AST) with attention feeding during the code sketch generation stage. Second, Coda then updates the code sketch using an iterative error correction machine guided by an ensembled neural error predictor. By finding a good approximate candidate and then fixing it towards perfect, Coda achieves superior with performance compared to baseline approaches. We assess Coda\u2019s performance with extensive experiments on various benchmarks. Evaluation results show that Coda achieves an average of 82% program recovery accuracy on unseen binary samples, where the state-of-the-art decompilers yield 0% accuracy. Furthermore, Coda outperforms the sequence-to-sequence model with attention by a margin of 70% program accuracy. Our work reveals the vulnerability of binary executables and imposes a new threat to the protection of Intellectual Property (IP) for software development.", "full_text": "Coda: An End-to-End Neural Program Decompiler\n\nCheng Fu, Huili Chen, Haolan Liu\n\nUC San Diego\n\n{cfu,huc044,hal022}@ucsd.edu\n\nXinyun Chen\nUC Berkeley\n\nxinyun.chen@berkeley.edu\n\nYuandong Tian\n\nFacebook\n\nyuandong@fb.com\n\nFarinaz Koushanfar, Jishen Zhao\n\nUC San Diego\n\n{farinaz,jzhao}@ucsd.edu\n\nAbstract\n\nReverse engineering of binary executables is a critical problem in the computer\nsecurity domain. On the one hand, malicious parties may recover interpretable\nsource codes from the software products to gain commercial advantages. On the\nother hand, binary decompilation can be leveraged for code vulnerability analysis\nand malware detection. However, ef\ufb01cient binary decompilation is challenging.\nConventional decompilers have the following major limitations: (i) they are only\napplicable to speci\ufb01c source-target language pair, hence incurs undesired develop-\nment cost for new language tasks; (ii) their output high-level code cannot effectively\npreserve the correct functionality of the input binary; (iii) their output program does\nnot capture the semantics of the input and the reversed program is hard to interpret.\nTo address the above problems, we propose Coda1, the \ufb01rst end-to-end neural-based\nframework for code decompilation. Coda decomposes the decompilation task into\nof two key phases: First, Coda employs an instruction type-aware encoder and a\ntree decoder for generating an abstract syntax tree (AST) with attention feeding\nduring the code sketch generation stage. Second, Coda then updates the code sketch\nusing an iterative error correction machine guided by an ensembled neural error\npredictor. By \ufb01nding a good approximate candidate and then \ufb01xing it towards\nperfect, Coda achieves superior performance compared to baseline approaches. We\nassess Coda\u2019s performance with extensive experiments on various benchmarks.\nEvaluation results show that Coda achieves an average of 82% program recovery\naccuracy on unseen binary samples, where the state-of-the-art decompilers yield 0%\naccuracy. Furthermore, Coda outperforms the sequence-to-sequence model with\nattention by a margin of 70% program accuracy. Our work reveals the vulnerability\nof binary executables and imposes a new threat to the protection of Intellectual\nProperty (IP) for software development.\n\nIntroduction\n\n1\nDecompilation is the process of translating a binary executable to the corresponding high-level code.\nThis technique has been widely used in various security applications, such as malware analysis and\nvulnerable software patching [1, 2]. Malicious attackers can also use decompilers to reverse engineer\n(RE) the commercial off-the-shelf (COTS) software products and reproduce it for illegal usage [3].\nDecompilation is a challenging task since the semantics in the high-level programming language (PL)\nis obliterated during compilation. Existing decompilers are language-speci\ufb01c and incur tremendous\nengineering overhead when extending to new PLs. Furthermore, they fail to preserve the semantic\ninformation in the target high-level PL (see Appendix F), thus the output is hard to interpret.\nIt is intuitive that decompilation can be formulated as a general program translation task. Recently,\nan increasing number of neural network (NN)-based approaches have been proposed to tackle natural\nlanguage translation problems. For instance, sequence-to-sequence (Seq2Seq) based models achieve\n1 Coda is the abbreviation for CodeAttack.\n\n33rd Conference on Neural Information Processing Systems (NeurIPS 2019), Vancouver, Canada.\n\n\fthe state-of-the-art performance on program translation [4, 5]. We identify three main subroutines\nin code decompilation: (i) learning control dependency from the connections between basic blocks\nin the low-level code; (ii) learning data dependency from the register usage and memory access;\n(iii) learning the grammar of the target PL. A straightforward neural-based solution is to use an\nautoencoder-decoder for translating the low-level program to the high-level code. Katz et al. [6]\npresent a Recurrent Neural Network (RNN)-based method for decompilation. However, we observe\nthat the naive Seq2Seq models are not suitable for decompilation due to the following reasons. First,\nthe inputs to the decompiler are structured low-level statements2 that have different construction\nformats (e.g., number and type of operands). Processing the program as sequence inputs ignores the\nstatement boundaries, thus breaks the modular property of the input program. Second, the output\nprogram of the Seq2Seq model has a lower probability of capturing the grammar of the target PL\nsince the output is sequentially generated without explicit boundaries. Third, the three subroutines\nmentioned above are entangled together in the Seq2Seq model, making the learning process hard.\nIn this work, we propose Coda, a neural program decompilation framework that resolves the above\nlimitations. The requirement to yield a perfect program recovery is very hard to ful\ufb01ll using a\nsingle autoencoder, especially for long programs. As such, Coda decomposes decompilation into\ntwo sequential phases: code sketch generation and iterative error correction. By \ufb01nding a good\napproximate program and then iteratively updating it towards the perfect solution using dynamic\ninformation, Coda engenders superior performance compared to the single-phase decompilers.\nPhase 1. Coda uses an instruction type-aware encoder and a abstract syntax tree (AST) decoder\nfor translating the input binary into the target PL. Our encoder deploys separate RNNs for different\ntypes of statements, thus the statement boundaries are preserved. Furthermore, the control and data\ndependency in the input program are translated to the connections between the hidden states of\ncorresponding RNNs. The output from the AST decoder maintains the dependency constraints and\nstatement boundaries using terminal nodes, which facilitates learning the grammar of the target PL.\nPhase 2. In this stage, Coda employs an RNN-based error predictor (EP) to identify potential\nprediction mistakes in the output program from Phase 1. Ensembling method can be used to boost\nthe performance of the error prediction. The EP is used to guide the iterative correction of the output\nprogram. Unlike traditional decompilers which utilize only the syntax information from the input,\nCoda leverages the Levenshtein edit distance (LD) [7] between the compilation of the updated output\nprogram and the ground-truth low-level code to prevent false alarms induced by the EP.\nEmpowered by the two-phase design, Coda achieves an average program accuracy of 82% on various\nbenchmarks. While the Seq2Seq model with attention and the commercial decompilers yield 12%\nand 0% accuracy, respectively. We demonstrate that Coda\u2019s output preserves both the functionalities\nand the semantics. In summary, this paper makes the following contributions:\n\nPresenting the \ufb01rst neural-based decompilation framework that maintains both semantics and\n\nfunctionalities of the target high-level code.\nIncorporating various design principles to facilitate the decompilation task. More speci\ufb01cally, Coda\ndeploys instruction type-aware encoder, AST tree decoder, attention feeding, iterative error correction\nthat leverages both the static syntax and dynamic information.\nEnabling an ef\ufb01cient end-to-end decompiler design. Coda can be easily generalized to RE executable\nin a different hardware instruction set architecture (ISA) or PL with negligible engineering overhead.\nCorroborating Coda\u2019s general applicability and superior performance on various synthetic bench-\nmarks and real-world applications.\nThis is the \ufb01rst paper that provides a holistic and effective solution to the decompilation problem using\ndeep learning. Our work sheds new light on the vulnerability of open sourcing binary executables\nwithout any protection. More speci\ufb01cally, we show that the attacker can recover interpretable high-\nlevel code with correct functionality from the binary \ufb01le, which imposes a signi\ufb01cant threat on the\nIntellectual Property (IP) of the program developer.\n2 Program Decompilation Problem\nWe introduce the background of low-level code construction and potential challenges in decompilation\nin Section 2.1. The formal de\ufb01nition of code decompilation and our threat model is given in\nSection 2.2 and Section 2.3, respectively.\n\n2 We refer each line of the code as a statement.\n\n2\n\n\f2.1 Preliminaries and challenges\nContemporary software development consists of the following steps: high-level programming, code\ncompilation, deploying the obtained binary \ufb01les to the pertinent hardware. During the execution,\na sequence of instructions is carried out on the hardware. There are three main instruction types,\nnamely, memory, arithmetic, and branch operations. Different instruction types feature different\ninstruction \ufb01elds, indicating various types and numbers of operands. Figure 1 (a) shows an example\nof the high-level code snippet and the corresponding low-level code. Line 0 is a memory instruction\nwhich fetched a word into register $1 from the memory address computed from register $fp and 24.\nLine 3 is an arithmetic operation which multiplies the value stored in $1 and $2. Line 8 refers\nto an unconditional branch requiring one operand as opposed to three. Note that lw,mul,j are\nthe opcodes of the instructions. Program decompilation is challenging since there are two types of\ndependencies existing in the low-level program that shall be preserved by the decompiler.\nIntra-statement dependency. Each instruction has a strict structure restriction on the operands as\nrequired by the grammar of the low-level ISA. For example, in the instruction lw $2,8($fp), the\n\ufb01rst and the third operand represent registers while the second operand is an instant value.\nInter-statement dependency. Besides the constraints in a single instruction, control \ufb02ow and data\ndependency exist across multiple instructions. For instance, line 2 and line 3 has data dependency\nsince the mul operation needs to consume the value from the load destination register.\n\nFigure 1: (a) Example low-level assembly code snippet and its corresponding high-level C program.\nThe red line indicates the instruction type and its encoded hidden state. (b) The expanding nodes\nfrom the AST decoder. (c) The red node is an example of how the prediction is computed.\n\n2.2 Problem de\ufb01nition\nWe de\ufb01ne the task of Program Decompilation as follows:\nProblem Decompilation De\ufb01nition: Let P denote an arbitrary program in the high-level language\nand \u0393 denote the compiler. Given the low-level code \u03c6 = \u0393(P ), the mission of decompilation is to\ndevelop a decompiler \u0393\u22121 that satis\ufb01es \u0393(P ) = \u0393(P (cid:48)) where P (cid:48) = \u0393\u22121(\u03c6).\nWe observe that traditional decompilers such as RetDec or Hex-Rays are only targeted to maintain\nthe functionality of the binary code during decompilation. Coda is motivated to address the above\nlimitation by recovering a high-level program with both correct functionality and semantics. Besides,\nwe identify two types of constraints of the high-level program that can be explored to verify the\ncorrectness of the decompiler\u2019s output.\nInput-output Behavior Constraint: Given a set of input-output pairs {(I k, Ok)}K\nk=1 where Ok =\n\u03c6(I k) is obtained by executing the low-level program \u03c6, the decompiler shall output a program P (cid:48)\nsuch that \u03c6(cid:48)(I k) = Ok for every k \u2208 1, ..., K where \u03c6(cid:48) = \u0393(P (cid:48)).\nCompilation Matching Constraint: The ideal LD between the compilation result \u03c6(cid:48) of the correctly\nrecovered program and the input low-level code \u03c6 is zero under the same compiler con\ufb01guration.\n2.3 Threat Model\nWe assume the attacker has the following information: (i) the compiler con\ufb01guration that is used to\ngenerate the input program; (ii) the interface of static/dynamic libraries included in the high-level\ncode; (iii) the disassembler for the pertinent hardware. The above information can be easily obtained\nusing binary analysis techniques in previous work [8\u201310]. Our objective is to RE a high-level program\nthat depicts the correct computation graph (control and data dependency) and preserves semantic\ninformation and functionality as the source high-level program. Reconstruction of data types [3],\n\ufb01nding the function entry point in binary [10, 11, 8] or reconstruct meaningful variable names [12]\nare different research directions that have been studied in prior works.\n\n3\n\n\f3 Coda Overview\nFigure 2 shows the global \ufb02ow of Coda. Coda framework consists of two key phases: (i) High-level\ncode sketch generation and (ii) iterative error correction. We detail these two phases as follows.\n\nFigure 2: The global \ufb02ow of Coda decompilation. The denoising and tokenization steps are omitted\nin this \ufb01gure for simplicity (See Appendix A.1).\n\n3.1 Code Sketch Generation\nWe employ the neural encoder-decoder architecture for generating the sketch code from the low-level\nprogram \u03c6. In this paper, the encoder takes the assembly program generated from the disassembler as\nthe input and output an AST that can be equivalently converted to the high-level program. We discuss\nthe key modules of Coda\u2019s code sketch generation below.\n\nInstruction-type Aware Program Encoding. Coda employs the N-ary Tree-LSTM presented\nin [13] as the input encoder to handle different instruction types, namely, memory, arithmetic, and\nbranch. More speci\ufb01cally, each statement in the input low-level program is fed to the designated\nLSTM that handles the corresponding instruction type for encoding.\n\nIterative Error Correction\n\nTree Decoder for AST Generation. We observe that PLs have more rigorous restrictions on\nthe syntax and semantics compared to natural languages. Coda opts to use tree decoder for AST\ngeneration because of the following advantages: (i) The code statement boundary is naturally\npreserved by the tree decoder using the terminal node representation. (ii) The nodes that are connected\nin the AST indicate that their corresponding statements in the input program have dependency\nconstraint. Note that the spatial distance for these statements in the program might be large. (iii) The\nerror propagation problem during code generation is mitigated using the tree decoder compared to\nsequential generation. (iv) AST representation facilitates the veri\ufb01cation of syntax restriction.\nAttention Feeding. Our evaluation result shows that code sketch generation is ineffective without\nattention mechanism (achieving a token accuracy of only 55%). Coda applies parent attention and\ninput instruction attention feeding mechanism [14, 15] that feed the information of the parent node\nand the input nodes during node expansion performed by the decoder.\n3.2\nThe output AST from the code sketch generation phase might contain prediction errors. As such, we\nconstruct an error predictor (EP) and an iterative error correction machine (EC machine) as shown in\nFigure 2. Speci\ufb01cally, we freeze the autoencoder-decoder from the previous stage and reuse them to\ngenerate the states of the input nodes hk, k = 0, ..., K and output nodes ht, t = 0, ..., T . Here, K\nand T denote the total number of input states and output states from sketch generation stage. These\nstates (hk and ht) are fed as the input to the EP. Furthermore, Coda leverages compiler veri\ufb01cation\nto remove false alarm made by the EP. Note that the input-output behavior of the ground-truth\nbinary executable can also be used as constraints that eliminate false alarms from EPs. To push the\nperformance even further, we ensembled multiple EPs to cover more errors in the decompiled code.\nIterative Error Correction machine. The output of the ensembled EP (containing the location\nand error type information in the code sketch) is passed to the EC machine. Note that the EC machine\nprioritizes the potential correction strategies based on the con\ufb01dence scores obtained from the EP.\nDuring each iteration of the error correction process, Coda \ufb01rst corrects a single error and validate\nthe resulting high-level code sketch by checking the LD between the compiled code sketch and\nground-truth as mentioned above. If the error correction is successful, Coda proceeds to the next\niteration where EP generates new guidance for the EC machine.\n4 Methodology\nIn this section, we detail two key phases of Coda\u2019s design as shown in Figure 2: autoencoder based\ncode sketch generation, and neural-based iterative error correction.\n4.1 Autoencoder-based Code Sketch Generation\nWe introduce the main modules of Coda\u2019s code sketch generation phase as follows.\n\n4\n\n\fInstruction-aware encoding. The computation \ufb02ow of Coda\u2019s input program encoding is shown\nin Equation (1) where the subscript n refers to nth instruction statements. To capture the intuition\nof learning the intra and inter-dependency of the instruction statements as discussed in Sec 2, Coda\nemploys an N-ary Tree Encoder [13] which is suitable for encoding task where the children are\nstructured. The input states are fed into the N-ary Tree Encoder with a consistent order of the\ncorresponding instruction type. As such, the intra-statement dependency can be effectively captured.\nParticularly, Coda designates a speci\ufb01c N-ary encoder for each instruction type, i.e., memory, branch\nand arithmetic instructions (LST Mi where i \u2208 {mem, br, art}). Note that in Coda\u2019s code encoding\nprocess, each non-terminal node has at most 4 children, consisting of the embedded states of up to 3\noperands in the current instruction (hop\ni where i = 0, 1, 2), and the context vector of the previous\ni\ninstruction (hn, cn). Coda encodes the input instructions with the maximal number of operands (i.e.,\n3) and pads short statements with zero states. The input x is the embedding of the instruction opcode\nof the current statement. The basic block header (e.g., $B2 in line 9 of Figure 1 (a)) are also handled\nas branch instructions.\n\n, cop\n\n0 ; cop\n\n1 ; cop\n\n2 ]), x), i \u2208 {mem, br, art}\n\n0 ; hop\n\n1 ; hop\n\n2 ], [cn; cop\n\n(hn+1, cn+1) = LST Mi(([hn; hop\n\n(1)\nBinary Abstract Syntax Tree decoder. The output states of the last instruction in the low-level\ncode is used as the input to Coda\u2019s tree decoder for AST generation. Non-leaf nodes in general AST\nstructures may have multiple children, which complicates the high-level code generation process\nsince the number of children varies for different nodes. To address this uncertainty in the decoding\nstage, Coda generates a binary tree in Left-Child Right-Sibling representation which is equivalent\nto the target AST output. As a result, each sub-tree in the AST output has a regulated structure that\nis consistent with the root. We deploy two LSTMs that predict the left and the right child of the\ncurrent node separately. The states (h, c) from a given AST node will be fed into the left/right LSTM\nto generate the left/right child, as shown in Equation (2) and (3). These two expanded nodes will\nbecome the new parent nodes to generate its children using the left/right LSTM. The obtained binary\nAST tree will be transformed back to its equivalent AST tree. Note that Coda\u2019s output AST does\nnot contain the statement ending token as the termination is naturally represented by the terminal\nnodes. For example, a complete statement a = b \u2217 c can be recovered from the AST subtree without\nan explicit ending token as shown in Figure 1. The state transition equations of Coda\u2019s AST decoder\nare shown as follows:\n\n(hL, cL) = LST ML((h, c), [Hot; et])\n\n(hR, cR) = LST MR((h, c), [Hot; et])\n\n(2)\n(3)\nHere, the subscript t denotes the current expanding node Nt in the output AST. The symbols ot and\net indicate the predicted token value and the attention vector (explained later) of the node Nt. H\nis a trainable token embedding matrix with dimension d \u00d7 V , where d and V are the embedding\ndimension and the vocabulary size of the high-level PL, respectively.\nInput Instruction and Parent Attention Feeding. To make better use of the information encoded\nfrom the input program and the parent context of the current expanding node, we employ instruction\nand parent attention feeding during AST decoding [16, 14]. Intuitively, predicting the current node\nwhile leveraging the relevant information from the input instructions and the node\u2019s parent provides a\nricher context for high-level code generation. Parent attention feeding is performed using Equation (2)\nand (3) during the state transition of the AST decoder. As for input instruction attention feeding, we\n\ufb01rst compute the probability that a node Nk in the input program corresponds to the expanding node\nNt as shown in Equation (4). Coda\u2019s input instruction attention is obtained from the expectation\nvalue of the hidden states of all nodes in the input program as shown in Equation (5).\n\nk = P (Nk|Nt) \u221d exp{hT\nK(cid:88)\nst\nct = E[hk|Nt] =\n\nk \u00b7 ht}\nhk \u00b7 st\n\nk\n\n(4)\n\n(5)\n\nct is then incorporated into the hidden state of the current node ht using Equation (6) where W1 and\nW2 are two trainable matrices with dimension d \u00d7 d, resulting in the attention vector et of the current\nnode. The \ufb01nal prediction output ot of the current expanding node is then be computed from the\nlinear mapping of et as shown in Equation (7). Wout is a trainable matrix of size V \u00d7 d.\n\nk=0\n\net = tanh(W1ct + W2ht)\n\not = argmax sof tmax(Woutet)\n\n5\n\n(6)\n\n(7)\n\n\f4.2 Neural-based Iterative Error Correction\nWe propose iterative Error Correction as the second phase of Coda framework to further improve\nthe quality of decompilation as discussed in Sec. 3.2. There are two key modules in this stage: an\nensembled neural EP and an Iterative EC machine. We characterize possible errors in Coda\u2019s code\nsketch into three types: (i) Nodes in the AST may be mispredicted to other tokens. For example, the\n\u2018while\u2019 might be misclassi\ufb01ed into \u2018if\u2019 token. (ii) A redundant line of code. (iii) A Missing line of\ncode. For error (i), the EP shall output the correct token value to guide the EC machine for updating\nthe node. For error (ii) and (iii), the EC machine removes/randomly adds a non-terminal node with\nleaf children in the predicted error location, thus converting the error type into a misprediction error\n(i). (See Appendix B for details) Equation (8) shows the hidden state transition of Coda\u2019s EP. We\ndeploy the \ufb01xed autoencoder from phase 1 followed by gated recurrent units (GRUs) with attention\nas the EP\u2019s architecture. Given the ground-truth input (\u03c6) and the compiled code sketch (\u03c6(cid:48)), the EP\nreturns the error status (\u20180/1\u2019) and the error types for each node in the output AST. The input to the\nt\u22121); and (ii) the concatenation\nGRU consists of two parts: (i) the hidden state of the parent node (hEP\nt ) obtained by forwarding \u03c6 and \u03c6(cid:48) to the autoencoder.\nof the hidden states (denoted by h\u03c6\n(8)\nThe attention layer in EP following the mechanism discussed in Sec. 4.1. Particularly, the input to\nthe attention layer ht in Equation( 4) is now replaced by the hidden state hEP of the current node.\nk and h\u03c6(cid:48)\nThe state of source input (hk) is substituted with the combination of the encoded states h\u03c6\nk .\nFurthermore, Coda ensembles multiple EPs to cover larger error space. The correction suggestion\nprovisioned by the EP is accepted if and only if the LD between the golden low-level code and the\ncompilation of the updated code sketch does not increase.\nThe work\ufb02ow of Coda\u2019s iterative EC machine is shown in Algorithm 1. The detail of the function\nF SM_Error_Correct in line 9 is presented in Appendix B.\nAlgorithm 1 Work\ufb02ow of iterative EC Machine.\nINPUT: NEP Ensembled Error Predictors EP ; Source assembly \u03c6; Decompiled Sketch pro-\n\nt and h\u03c6(cid:48)\nhEP\nt = GRU (hEP\n\ngram P (cid:48); Compiler \u0393; Maximum iterations Smax and steps in each iteration cmax;\n\nt ; h\u03c6(cid:48)\nt ])\n\nt\u22121, [h\u03c6\n\nQ \u2190 [], \u03c6(cid:48) = \u0393(P (cid:48)), \u2206(cid:48) \u2190 Edit_loss(\u03c6, \u0393(P (cid:48)))\nif \u2206(cid:48) = 0 then break\nQ \u2190 EPi(P (cid:48)) for i = 1,...,NEP\n\nOUTPUT: Error corrected program P (cid:48)\nf.\n1: si \u2190 0\n2: while si < Smax do\n3:\n4:\n5:\n6:\n7:\n8:\n9:\n10:\n11:\n12:\n13: Return: P (cid:48)\n\n(cid:101)Q \u2190 P rob_sort(Q, cmax)\nwhile (cid:101)Q is not empty do\nerr, node \u2190 (cid:101)Q.pop()\nt \u2190 F SM_Error_Correct(P (cid:48), err, node)\nP (cid:48)\n\u2206 = \u2206(cid:48) \u2212 Edit_loss(\u03c6, \u0393(P (cid:48)\nt ))\nif \u2206 \u2265 0 then\nP (cid:48) \u2190 P (cid:48)\nf \u2190 P (cid:48)\n\nt\n\n// Attach all the detected error to queue Q\n\n// Rank Q using output probabilities, keep cmax results.\n\n// correct the error in the program\n\n5 Evaluation\n5.1 Experimental Setup\nWe assess the performance of Coda on various synthetic benchmarks with different dif\ufb01culty levels\nand real-world applications as summarized in Table 1 (Stage 1) and Table 2 (Stage 2). Given the\nbinary executable as the input, we use an open-source disassembler [17, 18] for MIPS [19] and\nx86-64 [20] architecture to generate the corresponding assembly code that is fed to Coda.\nBenchmarks. We describe the four main tasks in our evaluation as follows.\n(i) Karel. Karel [21] is a C-based library that can be used to control the movement of a robot in a 2D\ngrid and modify the status of the environment. The assembly description of Karel programs has only\ncallback functions (no arguments) and global control \ufb02ags as shown in Appendix E. As such, Karel\nis suitable to evaluate Coda\u2019s capability of recovering the control \ufb02ow graphs (CFGs) of the source\ncode (see possible CFGs in Appendix A.2).\n\n6\n\n\f(ii) Math Library (Math). We generate synthetic benchmarks using math.h library [22] to assess\nCoda\u2019s performance for recovering both data and control dependencies.\n(iii) Normal Expression (NE). Common operations such as \u201d+,\u2212,\u2217,\\,(cid:107),(cid:29), &, ==,\u2227\u201d are the\nmain components of NEs in high-level PL. We observe that reconstructing normal expressions is\nmore dif\ufb01cult compared to function calls since the former one has less explicit structures.\n(iv) Composition of Functional Calls and Normal Expressions (Math+NE). We also construct\nsynthetic benchmarks consisting of both NEs and library functions calls. The dataset is constructed\nby replacing the variables in NE with the return value of a random math function (see Appendix E).\n(v) Real-world implementations. We test Coda\u2019s performance on real-world projects: (1) neural\nnetwork construction programs in pytorch C++ API [23] (2) Hacker\u2019s Delight loop-free programs [24]\nprovided in [25]. These programs are used for encoding complex algorithms as small loop-free\nsequences of bit manipulating instructions.\nTraining Data Generation. To build the training dataset for stage 1, we randomly generate 50,000\npairs of high-level programs with the corresponding assembly code for each task. The program is\ncompiled using clang with con\ufb01guration -0O which disables all optimizations. The subscript S and\nL in Table 1 denotes short and long programs with an average length of 15 and 30, respectively. The\ntree representation of each statement in the high-level code has a maximum depth of 3.\nThe training dataset for the error correction stage is constructed by injecting various types of errors\ninto the high-level code. In our experiments, we inject 10 \u223c 20% token errors whose locations are\nsampled from a uniform random distribution. To address the class imbalance problem during EP\ntraining, we mask 35% of the tokens with error status \u20180\u2019 (i.e., no error occurs) when computing the\nloss. Detailed statistics and examples of the dataset can be found in Appendix A.2 and E.\nError Predictor Training. We manually inject three types of errors (Sec. 4.2) into the ground-truth\ncode sketch and set the training target for each EP to the corresponding error types. Note that the EP\nalso learns to output the correct substitution token when the target is the misprediction error type.\nMetrics. We evaluate the performance of the Coda using two main metrics: token accuracy and\nprogram accuracy. Token accuracy is de\ufb01ned as the percentage of the predicted tokens in high-level\nPL that match with the ground-truth ones. Program accuracy is de\ufb01ned as the ratio between the\nnumber of predicted programs with 100% token accuracy and the number of total recovered programs.\n5.2 Results\nPerformance of Sketch Generation. Coda yields the highest token accuracy across all benchmarks\n(96.8% on average) compared to all the other methods as shown in Table 1. The NE task appears to be\nthe hardest one while Coda still engenders 10.1% and 80.9% margin over a naive Seq2Seq model with\nand without attention, respectively. More importantly, the result demonstrates that our Inst2AST+Attn\nmethod is more tolerant of the growth of the program length compared to the Seq2Seq+Attn baseline.\nWe hypothesize that this is because Inst2AST with attention focuses on the states of each instruction\nas a whole instead of every input token. As such, it is less sensitive to the growth of assembly token\nlength. Note that Coda achieves higher token accuracy on Math+NE benchmarks compared to NE\nones. This is due to the fact that the assembly description of function calls has a prologue of argument\npreparation [11] that is easy to identify than NE which directly operates on variables.\nWe observe that the majority of the token errors are misprediction in the sketch, especially when\nthe program size is large. Besides, the sketch may have missing or repetition statements. The\nimperfection of code sketch generation motivates the design of the error correction stage in Coda.\nOur empirical results show that in the recovered code sketch from Stage 1 has very few syntax errors\nthat lead to decompilation failure. This further validates the capability of Coda to automatically learn\nthe syntax structure of the high-level language. A small portion of syntax errors exists in the sequence\ndecoding baseline and we use a script to check and \ufb01x these syntax bugs. The token accuracy reported\nin Table 1 is measured before the script checking. Token errors that do not result in compilation\nfailure are corrected in the Phase 2.\nPerformance of Error Correction. Table 2 summarizes the performance of Coda\u2019s iterative error\ncorrection. We feed the recovered code sketch with imperfect token accuracy generated from stage 1\nto the pretrained EP. Recall that the EP consists of the \ufb01xed autoencoder from stage 1 and a GRU\nlayer. Here, EPs that reuse the Seq2Seq+attn and Inst2AST+attn sketch generator are denoted as\nEPs2s and EPi2a, respectively. We set Smax = 30 and cmax = 10 for EC machine in Algorithm 1.\n\n7\n\n\fTable 1: Token accuracy (%) comparison between Coda and alternative methods for code generation.\nColumns 1-2 denotes the Seq2Seq baseline. The last two columns denote the instruction-aware\nencoding (Inst) and AST decoding (AST) methods of Coda with and without attention (Attn)\nmechanism. The combination of a sequence-based model with Inst or AST is shown in Columns 3-4.\n\nInst2AST Inst2AST+Attn\n\nBenchmarks\n\n(Math+NE)S\n\nKarelS\nMathS\nNES\n\nKarelL\nMathL\nNEL\n\n(Math+NE)L\n\nSeq2Seq\n\n51.61\n23.12\n18.72\n14.14\n33.54\n11.32\n11.02\n6.09\n\nSeq2Seq+Attn\n\n97.13\n94.85\n87.36\n87.86\n94.42\n91.94\n81.80\n81.56\n\nSeq2AST+Attn\n\n99.81\n99.12\n90.45\n91.98\n98.02\n96.63\n85.92\n85.32\n\nInst2seq+Attn\n\n98.83\n96.20\n88.48\n89.67\n98.12\n93.16\n85.97\n86.16\n\n74.80\n56.29\n55.59\n56.62\n64.42\n45.63\n46.43\n43.77\n\n99.89\n99.72\n94.66\n97.90\n98.56\n98.63\n91.92\n93.20\n\nA single EP achieves 66% (EPs2s) and 69% (EPi2a) accuracy on average across benchmarks for\npredicting the error type in the sketch programs. Note that we only consider the prediction of the \ufb01rst\nerror due to the iterative nature of the EC machine.\nWhen ensembling 10 EPs (NEP = 10), the detection rate of \ufb01rst error can be enhanced to 84% and\n89% on average for EPs2s and EPi2a, respectively. Note that EPi2a achieves a higher accuracy on\nerror prediction across benchmarks compared to EPs2s. That is because the component of the EPi2a,\ni.e., Inst2AST+attn, achieves a better token accuracy compared to Seq2Seq+attn in EPs2s.\nThe ensembled EPs will guide our iterative EC machine as detailed in Algorithm 1. Coda\u2019s EC\nmachine increases the program accuracy from 12% to 61% and from 30% to 82% on average for\nSeq2Seq+Attn-based and Inst2AST+attn-based code sketch generation, respectively. In summary,\nCoda\u2019s best con\ufb01guration (Inst2AST+attn with EC) achieves an average of 82% \ufb01nal program accu-\nracy while the Seq2Seq model with or without attention approach yields 12% and 0%, respectively.\n\nTable 2: (i) First error prediction accuracy with various ensembled number of ensembled EPs. (ii)\nProgram accuracy before and after error correction (EC) when NEP =10. Note that NEP stands for\nthe number of ensembled EPs and model refers to the architecture of sketch generation.\n\nBenchMarks\n\n(Math+NE)S\n\nMathS\nNES\n\nMathL\nNEL\n\n(Math+NE)L\n\n(i) First Error Detection Rate (EP,NEP )\n\ns2s, 1\n69.6\n64.2\n65.1\n65.4\n60.3\n61.0\n\ni2a,1\n74.1\n67.6\n67.3\n71.7\n64.7\n66.5\n\ns2s,5\n84.9\n76.0\n78.4\n80.9\n71.6\n73.9\n\ni2a,5\n88.5\n79.2\n84.4\n83.1\n76.5\n77.5\n\ns2s,10\n91.4\n83.5\n83.6\n87.5\n78.1\n80.2\n\ni2a,10\n94.2\n88.7\n90.1\n91.3\n84.5\n85.3\n\n(ii) Befor EC\ni2a\ns2s\n40.1\n64.8\n12.2\n6.6\n43.2\n3.5\n51.8\n21.7\n2.6\n0.2\n0.1\n4.9\n\nAfter EC\ni2a\n100.0\n78.6\n89.2\n99.5\n56.4\n67.2\n\ns2s\n91.2\n53.0\n63.6\n83.9\n33.1\n38.3\n\nResults on Real-world Applications. We assess Coda on two real-world applications: Pytorch C++\nAPI-based [23] model architecture construction and bit twiddling hack in Hacker\u2019s Delight [24]. The\nmodel de\ufb01nition and the bit twiddling task programs consist of a sequence of function calls and a\nsequence of loop-free normal expressions, respectively. Examples of these two applications are given\nin Appendix E. Coda achieves 100% program accuracy across all benchmarks for these two tasks.\nComparison to Previous Works. We demonstrate that Coda outperforms two state-of-the-art\ndecompilers: RetDec [26] open-source tool and sequence-to-sequence based decompiler [6]. The\noutput from RetDec has a large LD to the ground-truth low-level code after compilation. Furthermore,\nthe high-level program recovered by RetDec fails to preserve the functionality of the input and is\nhard to interpret. (See Appendix F for examples). The Seq2Seq-based approach proposed in [6] takes\na sequence of bytes or bits directly from the binary executable as the input. We re-implement their\ntechnique and assess its performance on Math+NE synthetic benchmarks. Empirical results show that\ntheir Seq2Seq-based method achieves 11% token accuracy and 0% program accuracy on average.\n5.3 Discussion\nWe discuss the factors that might in\ufb02uence the performance of Coda framework as follows.\nRecover complex ISA. We identify that the performance of Coda decreases when the input low-\nlevel code is buit from more complicated ISA, such as x86-64 (details shown in Appendix D). This\nis mainly because: (i) x86-64 has more advanced instruction types that support different levels of\n\n8\n\n\fgranularity for memory read/write while MIPS supports only 32-bits read/write operations. As such,\nthe number of input token types in x86-64 is much larger than the one in MIPS ISA when compiling\nthe same high-level program; (ii) the branch \ufb02ag is not visible as part of the branch instructions in\nx86-64 since it is stored in the condition register. In MIPS ISA, Coda can extracts the branch \ufb02ag\ndirectly from the input instruction. Therefore, it is harder to recover the control dependencies in\nx86-64 compared to MIPS.\nRecover complicated structures. In Section 5.2, we evaluate Coda on synthetic benchmarks that\nhave the same program components as the previous decompiler works [27]. These benchmarks\ninclude function calls, normal expressions, nested control graphs, variables with different types\nand data dependencies. Complex data structures/control graph/static library reliance impose greater\nchallenges to the program decompilation task. Data type and structure identi\ufb01cation is an individual\nresearch direction which has been widely studied in previous works [3, 28]. Coda is suf\ufb01cient to\nresolve real-world applications such as Pytorch API or Hacker\u2019s delight applications. Combining\nCoda with these works can recover more complicate programs.\nRecover long programs. We assess Coda on programs (NE and Math+NE) with the average code\nlength (L) of 45 and 60. The token accuracy in Phase 1 drops by -5.4%/-13.5% (Inst2AST) on average\ncompared to the results on benchmarks with L = 30. We identify two challenges to decompile long\nprograms: (i) Unlike natural language with period as the end of sentence, there is no clear boundary\nto divide assembly code. The length of the input tokenized assembly grows to a very large value\n(Appendix A.2). (ii) Also, training the auto-encoder in Coda is more challenging for long encoding\nsequences due to the limited GPU memory.\n6 Related Work\nConventional Program Decompilation. There has been a long line of research on reverse engineer-\ning of binary code [29\u201331, 8, 10, 27, 2, 32]. Many decompilers such as Phoenix [27], Hex-rays [33]\nand RetDec [26, 34] (the most recent one) have been developed. Other works, such as TIE [3] or RE-\nWARDS [35], target at reconstructing the correct variable types, which is different from the objective\nof Coda. Learning-based methods have been proposed for identifying function entry point [8, 10, 11]\nfor disassembling binary code. These methods are orthogonal to Coda and can be integrated into our\nframework to tackle a wider range of decompilation tasks. To the best of our knowledge, no practical\ndeep learning-based techniques have been proposed for program decompilation.\nNeural Networks for Code Generation. Neural networks have been used for code generation in\nprior works [36\u201338, 14, 39]. Instead of recovering the high-level program from the corresponding\nassembly code, these works synthesize the program from the collected input-output pairs [40, 39],\nnatural language [37], or other domain-speci\ufb01c languages [14, 4]. In [6], they use a sequence-to-\nsequence model for decompilation with direct Byte-by-byte sequence input which yields a low\naccuracy as shown in Sec. 5. Coda demonstrates the \ufb01rst effective program decompilation framework.\nNeural Networks for Error Correction. The idea of iteratively \ufb01xing errors in the program using\nneural networks has been proposed [41\u201343]. In [42], they suggest using GRUs for embedding the\nexecution trace in order to identify bugs in the target program. DeepFix [41] deploys an autoencoder\nto \ufb01x typos that leads to a compilation failure. Note that the error correction stage of Coda has a\ndifferent objective from the above works. More speci\ufb01cally, we use an autoencoder-based error\npredictor to identify the token errors in output from the code sketch generation stage.\n7 Conclusions and Future Work\nIn this paper, we present Coda, the \ufb01rst neural-based decompilation framework that is corroborated\nto preserve both the semantics and the functionality of the high-level program. Coda consists of two\nkey phases for program RE. First, Coda generates the high-level program with a high token accuracy\nleveraging an instruction-aware encoder and an AST decoder network architecture with attention.\nNext, Coda iterative correct errors with the guidance of the ensembled EP which further improves\nCoda\u2019s token and program accuracy. Extensive experiments on various benchmarks corroborate that\nCoda outperforms the Seq2Seq model and traditional decompilers by a large margin. We believe that\nour work is a milestone for program security and decompilation.\nMeanwhile, we observe that several challenges remain in our current framework that can be addressed\nin the future work: (i) There are no explicit ending symbols in decompilation task. Future research\ncan tackle this issue to RE large-size binary \ufb01le. (ii) Previous works on the identi\ufb01cation of more\ncomplicated data structures can be incorporated into Coda to RE more complicated applications.\n\n9\n\n\fReferences\n[1] \u201cEffective and ef\ufb01cient malware detection at the end host,\u201d in Presented as part of the 18th\nUSENIX Security Symposium (USENIX Security 09). Montreal, Canada: USENIX, 2009.\n[Online]. Available: https://www.usenix.org/node/\n\n[2] K. Yakdan, S. Dechand, E. Gerhards-Padilla, and M. Smith, \u201cHelping johnny to analyze\nmalware: A usability-optimized decompiler and malware analysis user study,\u201d in 2016 IEEE\nSymposium on Security and Privacy (SP), May 2016, pp. 158\u2013177.\n\n[3] J. Lee, T. Avgerinos, and D. Brumley, \u201cTie: Principled reverse engineering of types in binary\n\nprograms,\u201d 2011.\n\n[4] A. T. Nguyen, T. T. Nguyen, and T. N. Nguyen, \u201cLexical statistical machine translation for\nlanguage migration,\u201d in Proceedings of the 2013 9th Joint Meeting on Foundations of Software\nEngineering, ser. ESEC/FSE 2013. New York, NY, USA: ACM, 2013, pp. 651\u2013654. [Online].\nAvailable: http://doi.acm.org/10.1145/2491411.2494584\n\n[5] A. T. Nguyen, T. T. Nguyen, and T. N. Nguyen, \u201cDivide-and-conquer approach for multi-phase\nstatistical migration for source code (t),\u201d in 2015 30th IEEE/ACM International Conference on\nAutomated Software Engineering (ASE), Nov 2015, pp. 585\u2013596.\n\n[6] D. S. Katz, J. Ruchti, and E. Schulte, \u201cUsing recurrent neural networks for decompilation,\u201d in\n2018 IEEE 25th International Conference on Software Analysis, Evolution and Reengineering\n(SANER).\n\nIEEE, 2018, pp. 346\u2013356.\n\n[7] H. Hyyr\u00f6, \u201cExplaining and extending the bit-parallel approximate string matching algorithm of\n\nmyers,\u201d Citeseer, Tech. Rep., 2001.\n\n[8] T. Bao, J. Burket, M. Woo, R. Turner, and D. Brumley, \u201c{BYTEWEIGHT}: Learning to\nrecognize functions in binary code,\u201d in 23rd {USENIX} Security Symposium ({USENIX}\nSecurity 14), 2014, pp. 845\u2013860.\n\n[9] A. Rahimian, P. Shirani, S. Alrbaee, L. Wang, and M. Debbabi, \u201cBincomp: A strati\ufb01ed approach\n\nto compiler provenance attribution,\u201d Digital Investigation, vol. 14, pp. S146\u2013S155, 2015.\n\n[10] N. E. Rosenblum, X. Zhu, B. P. Miller, and K. Hunt, \u201cLearning to analyze binary computer\n\ncode.\u201d 2008.\n\n[11] E. C. R. Shin, D. Song, and R. Moazzezi, \u201cRecognizing functions in binaries\nwith neural networks,\u201d in 24th USENIX Security Symposium (USENIX Security 15).\nWashington, D.C.: USENIX Association, 2015, pp. 611\u2013626.\n[Online]. Available:\nhttps://www.usenix.org/conference/usenixsecurity15/technical-sessions/presentation/shin\n\n[12] A. Jaffe, J. Lacomis, E. J. Schwartz, C. L. Goues, and B. Vasilescu, \u201cMeaningful variable\nnames for decompiled code: A machine translation approach,\u201d in Proceedings of the 26th\nConference on Program Comprehension, ser. ICPC \u201918. New York, NY, USA: ACM, 2018,\npp. 20\u201330. [Online]. Available: http://doi.acm.org/10.1145/3196321.3196330\n\n[13] K. S. Tai, R. Socher, and C. D. Manning, \u201cImproved semantic representations from tree-\n\nstructured long short-term memory networks,\u201d arXiv preprint arXiv:1503.00075, 2015.\n\n[14] X. Chen, C. Liu, and D. Song, \u201cTree-to-tree neural networks for program translation,\u201d in\n\nAdvances in Neural Information Processing Systems, 2018, pp. 2547\u20132557.\n\n[15] L. Dong and M. Lapata, \u201cLanguage to logical form with neural attention,\u201d in Proceedings of\nthe 54th Annual Meeting of the Association for Computational Linguistics (Volume 1: Long\nPapers). Berlin, Germany: Association for Computational Linguistics, Aug. 2016, pp. 33\u201343.\n[Online]. Available: https://www.aclweb.org/anthology/P16-1004\n\n[16] B. McCann, J. Bradbury, C. Xiong, and R. Socher, \u201cLearned in translation: Contextualized\nword vectors,\u201d in Advances in Neural Information Processing Systems, 2017, pp. 6294\u20136305.\n\n[17] \u201cmipt-mips,\u201d https://github.com/MIPT-ILab/mipt-mips.\n\n10\n\n\f[18] REDasm, https://github.com/REDasmOrg/REDasm, 2019.\n\n[19] G. Kane, MIPS RISC Architecture. Upper Saddle River, NJ, USA: Prentice-Hall, Inc., 1988.\n\n[20] Intel, \u201cIntel\u00ae 64 and ia-32 architectures software developer manuals,\u201d 2017. [Online].\n\nAvailable: https://software.intel.com/en-us/articles/intel-sdm\n\n[21] R. E. Pattis, \u201cKarel the robot,\u201d https://www.cs.mtsu.edu/~untch/karel/.\n\n[22] \u201cMath c++ library,\u201d http://www.cplusplus.com/reference/cmath/.\n\n[23] P. C. API, https://pytorch.org/cppdocs/, 2019.\n\n[24] H. S. Warren, Hacker\u2019s delight. Pearson Education, 2013.\n\n[25] E. Schkufza, R. Sharma, and A. Aiken, \u201cStochastic superoptimization,\u201d SIGPLAN Not., vol. 48,\nno. 4, pp. 305\u2013316, Mar. 2013. [Online]. Available: http://doi.acm.org/10.1145/2499368.\n2451150\n\n[26] RetDec, https://retdec.com/, 2017.\n\n[27] D. Brumley, J. Lee, E. J. Schwartz, and M. Woo, \u201cNative x86 decompilation using semantics-\npreserving structural analysis and iterative control-\ufb02ow structuring,\u201d in Presented as part of the\n22nd {USENIX} Security Symposium ({USENIX} Security 13), 2013, pp. 353\u2013368.\n\n[28] Z. Lin, \u201cReverse engineering of data structures from binary,\u201d Ph.D. dissertation, Purdue Univer-\n\nsity, 2011.\n\n[29] C. Cifuentes, Reverse compilation techniques, 1994.\n\n[30] M. Emmerik and T. Waddington, \u201cUsing a decompiler for real-world source recovery,\u201d in 11th\n\nWorking Conference on Reverse Engineering.\n\nIEEE, 2004, pp. 27\u201336.\n\n[31] D. Brumley, I. Jager, T. Avgerinos, and E. J. Schwartz, \u201cBap: A binary analysis platform,\u201d in\nComputer Aided Veri\ufb01cation, G. Gopalakrishnan and S. Qadeer, Eds. Berlin, Heidelberg:\nSpringer Berlin Heidelberg, 2011, pp. 463\u2013469.\n\n[32] O. Katz, Y. Olshaker, Y. Goldberg, and E. Yahav, \u201cTowards neural decompilation,\u201d arXiv\n\npreprint arXiv:1905.08325, 2019.\n\n[33] Hex-Rays, https://www.hex-rays.com/, 2017.\n\n[34] J. Kroustek and D. Kol\u00e1r, \u201cRetargetable analysis of machine code,\u201d Ph.D. dissertation, PhD\n\nthesis, Brno University of Technology, 2014.\n\n[35] B. Dolan-Gavitt, T. Leek, M. Zhivich, J. Gif\ufb01n, and W. Lee, \u201cVirtuoso: Narrowing the semantic\nIEEE,\n\ngap in virtual machine introspection,\u201d in 2011 IEEE Symposium on Security and Privacy.\n2011, pp. 297\u2013312.\n\n[36] W. Ling, P. Blunsom, E. Grefenstette, K. M. Hermann, T. Ko\u02c7cisk\u00fd, F. Wang, and A. Senior,\n\u201cLatent predictor networks for code generation,\u201d in Proceedings of the 54th Annual Meeting of\nthe Association for Computational Linguistics (Volume 1: Long Papers). Berlin, Germany:\nAssociation for Computational Linguistics, Aug. 2016, pp. 599\u2013609. [Online]. Available:\nhttps://www.aclweb.org/anthology/P16-1057\n\n[37] P. Yin and G. Neubig, \u201cA syntactic neural model for general-purpose code generation,\u201d in\nProceedings of the 55th Annual Meeting of the Association for Computational Linguistics\n(Volume 1: Long Papers). Vancouver, Canada: Association for Computational Linguistics, Jul.\n2017, pp. 440\u2013450. [Online]. Available: https://www.aclweb.org/anthology/P17-1041\n\n[38] M. Rabinovich, M. Stern, and D. Klein, \u201cAbstract syntax networks for code generation and\n\nsemantic parsing,\u201d arXiv preprint arXiv:1704.07535, 2017.\n\n[39] X. Chen, C. Liu, and D. Song, \u201cTowards synthesizing complex programs from input-output\n\nexamples,\u201d arXiv preprint arXiv:1706.01284, 2017.\n\n11\n\n\f[40] \u2014\u2014, \u201cExecution-guided neural program synthesis,\u201d in International Conference on Learning\n\nRepresentations, 2019. [Online]. Available: https://openreview.net/forum?id=H1gfOiAqYm\n\n[41] R. Gupta, S. Pal, A. Kanade, and S. Shevade, \u201cDeep\ufb01x: Fixing common c language errors by\n\ndeep learning,\u201d in Thirty-First AAAI Conference on Arti\ufb01cial Intelligence, 2017.\n\n[42] C. Piech, J. Huang, A. Nguyen, M. Phulsuksombati, M. Sahami, and L. Guibas, \u201cLearning\nprogram embeddings to propagate feedback on student code,\u201d arXiv preprint arXiv:1505.05969,\n2015.\n\n[43] K. Wang, R. Singh, and Z. Su, \u201cDynamic neural program embedding for program repair,\u201d arXiv\n\npreprint arXiv:1711.07163, 2017.\n\n12\n\n\f", "award": [], "sourceid": 2029, "authors": [{"given_name": "Cheng", "family_name": "Fu", "institution": "University of California, San Diego"}, {"given_name": "Huili", "family_name": "Chen", "institution": "UCSD"}, {"given_name": "Haolan", "family_name": "Liu", "institution": "UCSD"}, {"given_name": "Xinyun", "family_name": "Chen", "institution": "UC Berkeley"}, {"given_name": "Yuandong", "family_name": "Tian", "institution": "Facebook AI Research"}, {"given_name": "Farinaz", "family_name": "Koushanfar", "institution": "UCSD"}, {"given_name": "Jishen", "family_name": "Zhao", "institution": "UCSD"}]}