文法誤り訂正手法の転用によるデコンパイラの歪み修正手法の提案
開地 竜之介1

柗本 真佑1

楠本 真二1

概要：バイトコードからソースコードを復元するための手法としてデコンパイラが数多く提案されている．
デコンパイラはプログラムの解析を目的として広く利用されている．しかし，コンパイル時に変数名など
一部の情報が失われるため，完全な復元は難しく元のソースコードとの差異，すなわち歪みが発生してしまう．この歪みはソースコードの可読性の低下のみならず，プログラムの振る舞いの変化にもつながる可能性がある．また，デコンパイラの種類によって異なる歪みが発生する．そこで本研究では，自然言語処理の分野で用いられる文法誤り訂正を転用したデコンパイラの歪み修正手法を提案する．文法誤り訂正の中でも特に深層学習ベースの手法を用いることで，プログラミング言語やデコンパイラの種類によらず
ソースコード復元における歪み修正が可能となる．実験では，識別子歪みと構造的歪みの 2 種類の歪みに関して，提案手法でそれぞれどの程度修正が可能かを検証した．その結果，識別子歪みでは約 55%，構造的歪みでは約 91%を修正できることを確認した．

1. はじめに中間言語と高水準言語の命令は 1 対 1 で対応するとは限らないことが原因であり，例えば，繰り返し処理を for 命令

コンパイラが生成したバイトコードやバイナリから，そと while 命令のどちらに復元するべきかは一種の推論問題の生成元となったソースコードを復元する技術としてデコとなる．場合によっては，この構造的な歪みによってプロンパイラが存在する [1]．デコンパイラは一種のリバースエ

グラムの挙動が異なってしまうことも指摘されている [7]．

ンジニアリングツールであり，様々な目的で利用される．

また，発生する歪みは適用するデコンパイラによって異一つの活用方法は，ソースコードへアクセスできない環

なる．Java では CFR や Procyon，Jad，Fernﬂower など

境下での対象の振る舞いの把握である．IntelliJ や Eclipse

様々なデコンパイラが開発されており，各種デコンパイラをはじめとする多くの IDE はデコンパイラを搭載しておによって異なる歪みが発生する [7]．デコンパイラの復元

り，利用中のライブラリの具体的な処理内容を確認する

性能には差があり [8]，また復元可能な対象言語のバージョことが可能である．また，デコンパイラはバイナリを対象

ンも様々である．Java の場合，言語バージョン改定に伴っとしたセキュリティ解析 [2] の重要な技術の一つであり，て新たな言語仕様が追加されることも多く，その対応状況

Android アプリに対するマルウェア検出手法 [3][4] も提案

はデコンパイラによって異なる．これらの点から，最良なされている．

デコンパイラを確定することは難しく，画一的な歪み修正

デコンパイラが抱える一つの課題として，復元したソー方法の実現も容易ではないといえる．

スコードに含まれる元のソースコードとの差異が挙げら

本研究の目的は，デコンパイラの種別に依存しないソーれる．本稿ではこの差異を歪み（Quirk）と呼ぶ．バイト

スコードの歪み修正の実現である．そのために，深層学習にコード等の中間言語には，元のソースコードに含まれてい基づく文法誤り訂正手法（Grammatical Error Correction;

た識別子名は含まれていない．よって情報量の観点からもGEC）を転用した歪み修正手法を提案する．GEC とは，識別子名の完全な復元は不可能である [5]．識別子名はプロ

自然言語の文章を入力として，その文章に含まれる文法的グラム理解において重要な役割を占める [6] ことが知られな誤りを検出し修正する手法である．本稿ではソースコーており，その適切な復元はライブラリ理解という活用におドの歪みを一種の文法誤りだと見なすことで，GEC の転用

いて重要な課題であるといえる．さらに識別子名のみならを可能とする．提案手法の利点の一つは，メタアプリケー

ず，プログラム構造の歪みが発生することもある．これはションである深層学習の活用により，特定のデコンパイラに特化しない歪み修正が可能という点にある．また，学習1

大阪大学大学院情報科学研究科 大阪府吹田市

に用いるソースコードのペア（元コードと復元コード）をみが発生する点が挙げられる．

全自動で生成できるため，深層学習に必要な大量のデータ

図 1 にデコンパイラ CFR と JAD によって生成されたを確保しやすいという利点も存在する．評価実験として，実際の歪みの例を示す．左の元のソースコードと比べて，競技プログラミングのデータセット ReCa[9] に対して提案

デコンパイル後コードには様々な歪みが発生している．こ手法の適用を試みた．その結果，識別子名に関する歪みのこでは歪みを識別子名に関する歪みとプログラム構造に関

55%，プログラム構造に関する歪みの 91%を取り除くことする歪みの 2 種類に大別する．単純化のために，まずは右ができた．

上の CFR の歪みについて説明する．

2. 準備
2.1 文法誤り訂正
文法誤り訂正（Grammatical Error Correction; GEC）とは，自然言語で記述された文章の中から文法的な誤りを自まず識別子歪みに着目すると，ローカル変数名のほとんどは適切に復元できていない．唯一 for 文のインデックス

i は歪んではいないものの，頻度を表す occurence や数値集合を表す numbers といった，プログラムの振る舞いの理解に役立つ情報のほとんどが失われている．

動で検出し修正する技術である．GEC のアプローチは 3次に構造的歪みに着目する．第一に final 修飾子が省種類に大別できる [10][11]．一つはルールベースの手法で略されており，その値や参照が不変であるという開発者のあり，文法ルールやパターンに基づいて特定の文法エラー

意図や制約は読み取れない．final 修飾子やメソッド修飾を検出し修正する．もう一つは統計的なアプローチであ子はコンパイラに対する制約の明言であり，コンパイル後る．大規模な文法付きコーパスを使用して統計モデルをトのバイトコードには含まれない．よってその完全な復元はレーニングし，文法エラーの検出と修正を行う．近年は深難しい．さらに，番兵（-1 の要素）の発見条件は for 命

層学習を利用した機械翻訳（Neural Machine Translation;

令の繰り返し条件に統合されている．この統合に伴って，NMT）ベースの手法 [12][13] が主流となっている．本研究

番兵発見条件の反転（==から!=への反転）という歪みも発では，NMT ベースの文法誤り訂正を転用する．

生している．また軽微な歪みではあるものの，単項演算子の++は全て後置から前置に変換されている．全体的なソー2.2 深層学習
深層学習とは，多層構造のニューラルネットワークを用いている機械学習の手法の一つである．従来の機械学習でスコードそのものの振る舞いは等価ではあるものの，開発者の意図的に記述した狙いが読み取りにくくなっているといえる．

は特徴量の設計を人間が行う必要があったが，深層学習で次に 2 つのデコンパイラ（CFR と JAD）の復元ソース

は特徴量を自動で抽出できる．そのため，人の手で特徴量

コードを比較すると，異なる歪みを生成していることが分を指定することが困難な非構造化データを扱う画像認識やかる．特に識別子名は JAD は CFR とは異なる戦略で復音声認識といった分野でよく活用される．また，機械翻訳元している点が読み取れる．識別子名はバイトコードにはや対話システムといった自然言語処理の分野でも活用され含まれていないため，変数の型やその用途などの情報からるようになった．

復元せざるを得ない．その復元の戦略が異なると全く異なさらに近年では，事前学習済みモデルが広く利用されるる識別子歪みが発生する．デコンパイラ Fernﬂower の場合ようになってきている．事前学習済みモデルとは，大規模は，型すら無視して全て var0，var1 のような連番の名前

なデータセットを用いて事前に学習を行っており汎用的を付与する．構造的歪みという観点では，番兵条件の forなタスクに対応可能な深層学習モデルのことである．学習

文への統合という構造の大幅な歪みは CFR と共通していデータの収集が困難なタスクに対しても、少ないデータでるが，単項演算子の歪みは発生していない．このようにデ事前学習済みモデルをファインチューニングすることによコンパイラによって発生する歪みは異なるため，ルール

り高い精度のモデルを得ることが可能となる．代表的な事

ベース等の画一的な手法での歪みの修正は容易ではない．

前学習済みモデルとしては，2018 年に Devlin らによって提案された BERT[14]，2020 年に Brown らによって提案された GPT-3[15], また今回活用する CodeT5[16] などがある．

3. 提案手法
3.1 概要本研究ではデコンパイラの種類に依存しない歪み修正の実現を目的として，GEC を転用した歪み修正手法を提案

2.3 デコンパイラと歪みする．ソースコードの歪みを一種の構文的誤りだと見なす

バイトコードからソースコードを復元するための手法とことで，ルールを用いない汎用的な歪み修正を実現する．

してデコンパイラが存在する．デコンパイラの問題点とし具体的な手法としては，Transformer ベースの事前学習済て，元のソースコードを完全に復元することはできず，歪みモデルである CodeT5[16] を用い，歪みを含む・含まなOriginal code

Decompiled code (CFR)

int count(final int[] numbers) {int occurence = 0;
for (int i = 0; i < numbers.length; i++) {if (numbers[i] == -1) { // found sentinel
break;}
occurence++;}return occurence;}

int count(int[] arrn) {int n = 0;
for (int i = 0; i < arrn.length&& arrn[i] != -1; ++i) {++n;}return n;}

Decompiled code (JAD)

Compileint count(int ai[]){
int i = 0;
for(int j = 0; j < ai.length&& ai[j] != -1; j++)i++;

Decompile by CFR

011010101101

Decompile by JAD

Bytecode
Identifier quirk
Structure quirk

return i;}

図 1: デコンパイラによって発生した歪みの例

Step 1

Step 2Pre-trained model

Original code
Fine-tuned model
Train data

Compile011010101101Pair

Decompile

Step 3

DivideDatasetFine tune

Fix quirks

Evaluation data

Quirk fixed

Extract

Quirk remained
Quirk injected

Quirk

Decompiled code

Test data

Fixed code

図 2: 提案手法による歪み修正の流れ
いソースコードのペアを用いて翻訳タスクとしてファイン

データセット等の任意のデータソースからソースコードのチューニングを適用する．生成されたモデルは歪みを含む集合を得る．次に全てのソースコードをコンパイルしてバ

入力コードから，歪みを含まないコードへ翻訳するように

イトコード（言語によっては機械語）を生成する．さらに

ソースコード変換を実施する．なお本手法は，特定の言語

任意のデコンパイラを用いてバイトコードからソースコー

やデコンパイラに依存しない汎用的な手法である．学習対

ドの復元を試みる．この時点で復元コードには一定の歪み象となるデータセットがテキスト形式のソースコードペアが含まれている．最後に，元コードと復元コードをペアにであり，様々な言語やデコンパイラへの適用が可能である．

してデータセットを生成する．

3.2 提案手法の流れ

Step 2: ファインチューニング

図 2 に提案手法による歪み修正の流れを示す．提案手法
は次の 3 つのステップから構成される．

本ステップでは，次にファインチューニングにより歪み修正モデルを生成する．Step 1 で生成したデータセット
を訓練データ，検証データ，テストデータの 3 種に分割す

Step 1: データセットの作成

る．分割の割合は順に 0.80，0.15，0.05 である．さらに訓

このステップでは，学習に用いる元コード・復元コード

練データと検証データを用いて，CodeT5 に対するファイのペアのデータセットを作成する．まず，GitHub や公開

ンチューニングを実施する．この際の学習タスクは，ペア

のデータセットを用いた翻訳タスクとなる．最終的に歪みに分類する．図 1 において紹介した，番兵発見条件の反転を文法誤りのように見なし修正するモデルが得られる．

は構造的歪みの一つである．識別子歪みと同様に可読性の低下につながる．また，最悪の場合プログラムの振る舞い

Step 3: 歪みの修正にも影響を与えてしまう．

最後に生成されたモデルを使って歪み修正を試みる．テ
ストデータに含まれる復元コードをファインチューニング
で生成したモデルに入力する．結果として一定の歪みが取り除かれた修正コードが得られる．

4. 実験設定
4.1 実験目的
提案手法の有用性を確認するための実験を行う．復元
コードに含まれていた識別子歪みと構造的歪みが，それぞ4.3 歪みの検出方法
復元コードと修正コードそれぞれに含まれる歪みを検出するために，GumTree[17] を使用して元コードとの

AST の差分を検出する．GumTree はプログラムのバージョン間での変更箇所を特定し，それらの変更内容を 7
種類に分類可能なツールである．その 7 種類は，match,

update-node, insert-node, delete-node, insert-tree, deletetree, move-tree である．

れどの程度修正されたのかを検証する．まず初めに元コー

図 3 に，GumTree を使って AST の差分を可視化した例

ドと復元コード，元コードと修正コードとの AST の差分を示す．これは，図 1 における元コードと CFR による復を検出し，復元コードと修正コードに含まれる歪みの集合

元コードのうち，それぞれの for 文に絞った例である．黄をそれぞれ得る．その後，2 つの集合の包含関係を分析し，色のハイライトが識別子歪みを表しており，ピンク色のハ

復元コードに含まれる歪みがどの程度修正できたのか検証

イライトが構文的歪みを表している．この時，識別子歪みする．

は単一ノードの更新に基づくため，黄色でハイライトされ提案手法は，特定のプログラミング言語やデコンパイラ

たノードの数と GumTree で実際に検出される歪みの数がに特化しない歪み修正が可能である．ただし本稿では，プ一致する．一方で，構造的歪みではピンク色でハイライト

ログラミング言語として Java を対象に実験を行う．また，されたうちの各ノードや部分木の変更が歪みに関与する．

デコンパイラには CFR*1 を利用する．CFR は，復元コー

そのため，GumTree によって一つのブロック内から複数ドのコンパイル可能性が高く元コードとの AST の差分がの歪みが検出される．このように，本稿の実験では構造的小さい [7] など，Java のデコンパイラの中でも優れている

歪みを細かく検出している．今後は，ブロック単位で構造ため採用した．

的歪みを検出した場合の実験を検討している．

4.2 歪みの定義

4.4 歪み修正能力の評価方法

本稿では，復元ソースコードと元のソースコードの抽象

GumTree によって得られた復元コードと修正コードそ

構文木の差分を歪みと定義する．また，2 種類の歪みを定れぞれに含まれる歪みの集合の包含関係を分析し，提案手義する．

法によってどの程度歪みを修正できたかを評価する．
図 4 に示すベン図は復元コードに含まれる歪みの集合 A

識別子歪みと修正コードに含まれる歪みの集合 B の包含関係を表す

識別子歪みは識別子名の変更に関する歪みである．AST

ベン図である．このベン図において A ∩ B̄ の集合は，復元においてラベルが SimpleName か QualiﬁedName である

コードには含まれて修正コードには含まれない歪みの集合

ノードの更新を識別子歪みに分類する．図 1 において黄色である．すなわち，提案手法による修正で取り除くことがのハイライトで示した歪みは識別子歪みの一つである．コ

できた歪みといえる．同様にして考えると，A ∩ B の集合

ンパイル時に識別子名の情報が失われることから，通常デは提案手法では取り除けなかった歪みの集合，Ā ∩ B の集

コンパイラでは識別子名の復元は困難である．元コードで合は提案手法により新たに追加されてしまった歪みの集合

変数に意味のある名前がつけられていたとしても，デコンであるとわかる．

パイル後には名前が変わってしまうため可読性の低下につながる．

以上のように，復元コードと修正コードそれぞれに含まれる歪みの集合の包含関係を考えることで，提案手法に
よってどの程度歪みを修正できたかを評価する．

構造的歪み
構造的歪みとはソースコードの構文の変化に関する歪みのことである．識別子歪み以外の差分をすべて構造的歪み

4.5 データセット
本稿の実験では，競技プログラミングの解答として提出されたソースコードを収集したデータセットである ReCa[9]*1https://www.benf.org/other/cfr/

ForStmt
VarDeclInfixExpr

PrimtvType

Block
IfStmtInfixExpr

VarDeclInfixExpr

SimpleName: i

SimpleName: i

InExprOp

ArrayAccess

NumLiteral

QualName: arrn

SimpleName: numbers
SimpleName: i
InExprOp

PostfixExpr
PreExprOp
SimpleName: i

InExprOp

PrefixExpr

InfixExpr

PreExpOp

ArrayAccess

PostExprOp

NumLiteral

SimpleName: numbers

Block

SimpleName: i

ExprStmt

InExprOp

PostfixExpr

PrefixExpr

updated node
removed node

Identifier quirk

added node

Structure quirk

BreakStmtr

PreExprOp

PreExpOp

SimpleName: n

NumLiteral

PostExprOp

図 3: GumTree を用いた歪み検出の例

Quirks indecompiled code

Quirks in
fixed code

4.6 事前学習済みモデル
本稿の実験で利用する事前学習済みモデルは，Wang らによって提案された CodeT5[16] である．CodeT5 は，Code-SearchNet[18] のデータセットで事前学習された TransQuirks
fixed

Quirksremained

Quirksinjected

former ベースのモデルであり，コードの生成や変換，修正などマルチタスクに対応している．CodeT5 には異なる
サイズのモデルが複数あるが，メモリの問題から今回はCodeT5-small を利用した．
図 4: 2 つの歪み集合の包含関係を用いる．ReCa には，C，C++，Python，Java の 4 種類のプログラミング言語のソースコードが含まれているが，今回は Java だけを対象とした．また，復元コードを本実験で CodeT5 を利用する際のハイパーパラメータは
表 1 の通りである．また，ファインチューニングに要した
時間はおよそ 1 時間 30 分であった．
表 1: 本実験におけるハイパーパラメータ
ハイパーパラメータ

数値

フィードフォワード次元

2,048

埋め込みサイズ512

みを抽出した．さらに，その中でもファイルサイズが 2KB

エポック数

20

以下のコードのみを抽出して実験対象とした．当初，ファバッチサイズ

16

イルサイズによる選別は行わずに実験を行った結果，メモ

レイヤ数

6

リの問題が発生しモデルのファインチューニングが途中で

ヘッド数

8

得るためにはコンパイラにより生成されたバイトコードが必要である．そのため，コンパイル可能なソースコードの止まってしまった．メモリの問題を引き起こさないこととファインチューニングに用いるデータ数が十分であるかの両方を考慮し，最終的に 2KB 以下のソースコードを対象とすることに決定した．

5. 実験結果と考察
5.1 実験結果

以上の条件を満たすコードを抽出した結果，17,220 の

図 5 と図 6 に識別子歪みの集合と構造的歪みの集合そ

ソースコードが集まった．これを 0.80:0.15:0.05 の比率でれぞれに関するベン図を示す．ベン図の中の数値はテスト

分割し，それぞれ訓練データ，検証データ，テストデータ

データとして用いた全ソースコード (861 個) の歪みの総計

として実験に使用した．

を表している．まず図 5 の識別子歪みに着目すると，復Quirks in decompiled code

Quirks in decompiled code

Quirks in fixed code

Quirks in fixed code

= 55%
17,503個= 91%
46,219個

14,332個

9,999個Quirks fixed

Quirks fixed

1,210個= 8%
31,835個

15,542個

Quirks injected= 69%

14,425個
4,426個

50,645個

図 5: 識別子歪みのベン図

Quirks injected

図 6: 構造的歪みのベン図

5.2 考察元コードに含まれる識別子歪みの合計は 31,835 個であっ提案手法による修正で，識別子歪みのうち約 55%を修正た．このうち，提案手法により取り除くことができたのはできたのに対して，構造的歪みは約 91%と識別子歪みより

17,503 個であり，約 55%の歪み修正に成功した．一方で，も大幅に修正成功率が高くなった．このような結果となっ提案手法によって，新たに 1,210 個の歪みが追加されてした要因を考察する．

まっている．これは，修正コードに含まれる識別子歪みの
うち 8%とかなり少数であった．

識別子名のつけ方は，ある程度の共通認識は存在するが開発者への依存度が高く，同じ意味の変数であっても異な

次に，図 6 から復元コードに含まれる構造的歪みの合計

る名前がつけられることが多々ある．一方で，ソースコー

は 50,645 個とわかる．このうち，提案手法により取り除く

ドの構文に関しては同じ言語であればそれほど開発者へのことができたのは 46,219 個であり，約 91%と大部分の歪依存度は高くないと考える．今回使用した事前学習済みモ

みを修正できた．一方で，新たに追加された構造的歪みはデルの事前学習用のデータセットとファインチューニング

9,999 個であり，修正コードに含まれる歪みのうち約 69%に使用したデータセットは，いずれも複数の開発者によっとなり，識別子歪みの場合よりも増加した．

て作成されたソースコードから成る．したがって，事前学

図 7 に，提案手法による歪み修正の実例を示す．ただ習済みモデルは開発者によって正解が大きく変化しうる識

し，修正による効果が分かりやすくなるようにソースコー

別子歪みの修正よりも，ある程度正解が定まっている構造

ドの一部を省略している．この実例において一番に着目し的歪みの修正の方が適しているのだと考える．

たいのはピンクのハイライトがなされている構造的歪みである．まず初めに，元コードでは boolean 型の変数 f をフ

6. おわりにラグとしており，これによって最終的な出力が決定される．

本研究では，デコンパイラで復元されたソースコードに一方で，復元コードでは int 型の変数 n の値をフラグ代わ

含まれる 2 種類の歪みの修正方法として，事前学習済みモ

りにしているが，この変数の役割を直感的に理解すること

デルを活用した手法を提案した．結果として，復元コード

は難しく，可読性が低下している．さらに，for 文の中のに含まれる識別子歪みの約 55%，構造的歪みの約 91%を提if 文の条件式が反転したことにより，人間が普通は書かな

案手法により修正できることを確認した．

いようなコードになっている．それはまさしく可読性の低また，今後の課題として以下の 3 つを挙げる．1 つ目は，下の原因である．それに対して，修正コードではフラグと実験で用いるデコンパイラの種類を増やすことである．デして boolean 型の変数を使っており，その役割を明確にしコンパイラの問題点として歪みの発生があるが，この歪みている．また，if 文に関してもより理解のしやすい元コー

はデコンパイラの種類で異なってくる．提案手法は，ファドの書き方へ修正しており，可読性が高くなっている．

インチューニングの際のデータセットを変えることでデコ

また，黄色のハイライトで示される識別子歪みに着目す

ンパイラの種類によらず網羅的に歪みの修正を行うことがると，復元コードと修正コードで歪みの数に差がないため可能と考える．そのため，複数のデコンパイラを用いた実うまく修正できていないように見える．しかし，修正コー験を行う必要がある．2 つ目は，異なる観点の評価指標を

ドでは配列が arr，フラグが flag というようにプログラ用いることである．今回は，歪み修正の能力を評価するに

ム中での役割が直感的に理解可能な名前に変化している．

あたり，AST の差分のみに着目している．しかし，実用

確かに，元コードと同じ名前への修正はできていないため性を考えると，修正コードがコンパイル可能であるか，元今回の定義においては修正失敗であるが，むしろ可読性のコードのテストケースを通過するかといった観点での評価

観点では修正コードの方が優れている．この点は，提案手を行う必要がある．3 つ目は，既存手法との比較である．

法の強みの一つであると考える．

デコンパイラにより発生する識別子歪みの修正手法が存在Original code
void main(...) {int[] a = ... abbreviatedboolean f = true;for (int i = 0; i < a.length - 1; i++) {long t = a[i] * 2;
if (a[i+1] < t && a[i] != a[i+1]) {f = false;
break;}}
if (f)
System.out.println("NO");
else
System.out.println("YES");}

Compile & Decompile

Fix by proposed method

Decompiled code (CFR)

Fixed code

void main(...) {int[] nArray = ... abbreviatedint n;
n = 1;for (int i = 0; i < nArray.length - 1; ++i) {long l = nArray[i] * 2;
if ((long)nArray[i + 1] >= l|| nArray[i] == nArray[i + 1]) continue;
n = 0;
break;}
if (n != 0) {System.out.println("NO");} else {System.out.println("YES")
Identifier quirk}
Structure quirk}

void main(...) {int[] arr = ... abbreviatedboolean flag = true;for (int i = 0; i < arr.length - 1; i++) {long k = arr[i] * 2;
if (arr[i+1] < k && arr[i] != arr[i+1]) {flag = false;
break;}}
if (flag)
System.out.println("NO");
else
System.out.println("YES");}図 7: ReCa のある題材における歪み修正の実例
する [19][20]．今後は，提案手法とこれらの手法との比較を検討している．
謝辞

本 研 究 の 一 部 は ，JSPS 科 研 費（JP21H04877，[6]

JP20H04166，JP21K18302，JP21K11829）による助成を
受けた．

[7]

参考文献
[1]

[2]

[3]

[4]

[5]

Cifuentes, C. and Gough, K. J.: Decompilation of binary
programs, Software: Practice and Experience, Vol. 25,
No. 7, pp. 811–829 (1995).
Cifuentes, C., Waddington, T. and Van Emmerik, M.:
Computer security analysis through decompilation andhigh-level debugging, Working Conference on Reverse
Engineering (WCRE), pp. 375–380 (2001).
Milosevic, N., Dehghantanha, A. and Choo, K.-K. R.:
Machine learning aided Android malware classiﬁcation,
Computers and Electrical Engineering, Vol. 61, pp. 266–
274 (2017).
Cen, L., Gates, C. S., Si, L. and Li, N.: A probabilistic discriminative model for android malware detection
with decompiled source code, Transactions on Dependable and Secure Computing (TDSC), Vol. 12, No. 4, pp.
400–412 (2014).
Jaﬀe, A., Lacomis, J., Schwartz, E. J., Goues, C. L.
and Vasilescu, B.: Meaningful variable names for decompiled code: A machine translation approach, Interna-

[8]

[9]

[10]

[11]

tional Conference on Program Comprehension (ICPC),
pp. 20–30 (2018).
Hofmeister, J., Siegmund, J. and Holt, D.: Shorter
identiﬁer names take longer to comprehend, International Conference on Software Analysis, Evolution andReengineering (SANER), pp. 217–227 (2017).
Harrand, N., Soto-Valero, C., Monperrus, M. andBaudry, B.: The strengths and behavioral quirks ofJava bytecode decompilers, International Working Conference on Source Code Analysis and Manipulation(SCAM), pp. 92–102 (2019).
Mauthe, N., Kargén, U. and Shahmehri, N.: A largescale empirical study of android app decompilation, International Conference on Software Analysis, Evolution
and Reengineering (SANER), pp. 400–410 (2021).
Liu, H., Shen, M., Zhu, J., Niu, N., Li, G. and Zhang,L.: Deep Learning Based Program Generation From Requirements Text: Are We There Yet?, Transactions on
Software Engineering (TSE), Vol. 48, No. 4, pp. 1268–
1289 (2022).
Felice, M., Yuan, Z., Andersen, Ø. E., Yannakoudakis,
H. and Kochmar, E.: Grammatical error correction using
hybrid systems and type ﬁltering, Conference on Computational Natural Language Learning: Shared Task
(CoNll), pp. 15–24 (2014).
Yuan, Z. and Felice, M.: Constrained grammatical error correction using statistical machine translation, Conference on Computational Natural Language Learning:
Shared Task (CoNLL), pp. 52–61 (2013).

[12]

[13]

[14]

[15]

[16]

[17]

[18]

[19]

[20]

Yuan, Z. and Briscoe, T.: Grammatical error correction using neural machine translation, Conference of theNorth American Chapter of the Association for Computational Linguistics: Human Language Technologies(NAACL), pp. 380–386 (2016).
Wang, Y., Wang, Y., Dang, K., Liu, J. and Liu, Z.:
A comprehensive survey of grammatical error correction, Transactions on Intelligent Systems and Technology (TIST), Vol. 12, No. 5, pp. 1–51 (2021).
Devlin, J., Chang, M.-W., Lee, K. and Toutanova,
K.: Bert: Pre-training of deep bidirectional transformers for language understanding, arXiv preprint
arXiv:1810.04805 (2018).
Brown, T., Mann, B., Ryder, N., Subbiah, M., Kaplan,J. D., Dhariwal, P., Neelakantan, A., Shyam, P., Sastry,G., Askell, A. et al.: Language models are few-shot learners, Advances in Neural Information Processing Systems (NeurIPS), Vol. 33, pp. 1877–1901 (2020).
Wang, Y., Wang, W., Joty, S. and Hoi, S. C.:
Codet5: Identiﬁer-aware uniﬁed pre-trained encoderdecoder models for code understanding and generation,
arXiv preprint arXiv:2109.00859 (2021).
Falleri, J., andXavier Blanc, F. M., Martinez, M. andMonperrus, M.: Fine-grained and accurate source code
diﬀerencing, International Conference on AutomatedSoftware Engineering (ASE), pp. 313–324 (2014).
Husain, H., Wu, H.-H., Gazit, T., Allamanis, M. andBrockschmidt, M.: Codesearchnet challenge: Evaluating the state of semantic code search, arXiv preprint
arXiv:1909.09436 (2019).
Lacomis, J., Yin, P., Schwartz, E., Allamanis, M.,
Le Goues, C., Neubig, G. and Vasilescu, B.: Dire: A
neural approach to decompiled identiﬁer naming, International Conference on Automated Software Engineering (ASE), pp. 628–639 (2019).
Nitin, V., Saieva, A., Ray, B. and Kaiser, G.: DIRECT:A Transformer-based Model for Decompiled Identiﬁer
Renaming, Workshop on Natural Language Processingfor Programming (NLP4Prog), pp. 48–57 (2021).