Pith. sign in

REVIEW 5 major objections 5 minor 51 references

RINSER predicts Windows API names in obfuscated malware with 85.77% accuracy by training BERT on 'API codeprints' extracted from disassembly.

Reviewed by Pith at T0; open to challenge. T0 means a machine referee read the full paper against a public rubric. the ladder, T0–T4 →

Challenge this review Re-run · record.json Download PDF Read on arXiv ↗

T0 review · deepseek-v4-flash

2026-08-05 05:49 UTC pith:YNBSKQ4I

load-bearing objection RINSER is a genuinely useful new application with a large dataset, but the headline numbers are undercut by arithmetic errors, a binary-split leak risk, and a FLIRT-label circularity that needs an independent validation set. the 5 major comments →

arxiv 2509.04887 v1 pith:YNBSKQ4I submitted 2025-09-05 cs.CY

RINSER: Accurate API Prediction Using Masked Language Models

Muhammad Ejaz Ahmed , Christopher Cody , Muhammad Ikram , Sean Lamont , Alsharif Abuadbba , Seyit Camtepe , Surya Nepal , Muhammad Ali Kaafar This is my paper
classification cs.CY
keywords Windows API predictionAPI codeprintsmasked language modelmalware deobfuscationstatic binary analysisstripped binariesBERTPE binaries
verification ladder T0 review T1 audit T2 compute T3 formal T4 reserved

The pith

A machine-rendered reading of the paper's core claim, the machinery that carries it, and where it could break.

The paper claims that Windows API calls can be identified even when their names are stripped or obfuscated, by training a masked language model on 'API codeprints' — small windows of assembly instructions that set up each API call's parameters. On a test split of 4.7M codeprints from malware binaries, the model names the hidden API correctly 85.77% of the time on normal binaries and 82.88% on stripped binaries. RINSER also resolves 69,921 API calls that a commercial disassembler leaves unnamed, including 65 capabilities confirmed by manual analysis. The practical payoff: an analyst can be pointed to likely API identities quickly, and the approach beats three prior tools by more than 20 points.

Core claim

The central claim is that the assembly context around a call is enough to name the API, and that a masked-language-model objective can learn that mapping without labels. The paper introduces API codeprints: the API name, its parameter names and values, and the instructions semantically tied to those parameter values. BERT-style pretraining on 4.7M codeprints teaches the model to fill a mask over the API name; fine-tuning adapts it to stripped binaries. On 1,148 unseen binaries accuracy is 88.80%, and on binaries whose API names IDA leaves unresolved, RINSER recovers 69,921 names, including 65 APIs tied to C2, spying, and evasion.

What carries the argument

The key object is the API codeprint, built in three steps: find API call sites and parameter pushes from IDA-disassembled code; semantically backtrack from each register-based parameter value through preceding instructions to collect the instructions that touch the same registers; and symbolically map memory and address operands to tokens like 'mem', 'complex', and 'saddr' to control vocabulary. The codeprint is fed to a masked language model (BERT), which is trained to predict the masked API token from its surrounding context; this is what lets the model transfer to stripped and obfuscated binaries.

Load-bearing premise

The whole pipeline assumes IDA FLIRT reliably annotates which API is called and the names of its parameters; if that annotation is wrong, both the training label and the test label are wrong, so the measured accuracy reflects fidelity to IDA as much as true API identification.

What would settle it

Compile a set of Windows C programs with symbols and known API names, strip them, and obfuscate names with a method other than dynamic GetProcAddress resolution (e.g., direct IAT rewriting with hash-based lookup), then compare RINSER's predictions to the true names; if codeprint extraction drops below the claimed ~91% parameter-detection accuracy or accuracy on such binaries falls far below 85%, the push-and-annotation assumption is the breaking point. Alternatively, inspect mispredictions: RINSER outputs parameters like 'hwnd' or symbols like 'maddr' for non-API tokens, indicating the model i

Watch this falsifier. Get emailed when new claim-graph text bears on it.

Share X Bluesky LinkedIn Reddit HN

If this is right

  • An analyst who sees an obfuscated 'call dword_4031A5' can be shown the most likely API name in seconds, cutting manual reverse-engineering time.
  • The approach should transfer to other API-name prediction tasks: parameter-value prediction, API call sequence prediction, and deobfuscation of dynamically resolved imports using GetProcAddress.
  • Releasing the 4.7M-codeprint dataset gives other researchers a common benchmark to compare API prediction work on Windows, where source-independent large datasets were missing.
  • Because the model learns context rather than exact import entries, it stays accurate when control flow is displaced by jump-based transformations, with accuracy dropping only from 89.03% to 85.43%.

Where Pith is reading between the lines

These are editorial extensions of the paper, not claims the author makes directly.

  • The evaluation's ceiling is set by IDA FLIRT: reported accuracy partly measures agreement with FLIRT's annotations, so gains on fully unknown APIs may be lower or higher than 85.77%; a test against independently compiled, symbol-known Windows programs would separate the two.
  • The semantic-backtracking design suggests the method could extend from x86 stdcall to x64 and fastcall conventions, where parameters pass in registers, provided codeprint construction is adapted.
  • A natural stress test is malware that hides calls by push/ret sequences or statically linked libraries — the paper notes these as limitations; future work could use a classifier trained on surrounding instructions rather than only the call operand.
  • If the codeprint dataset is public as claimed, it enables transfer learning for low-resource malware families by fine-tuning on a handful of labeled samples.

Editorial analysis

A structured set of objections, weighed in public.

Desk editor's note, referee report, simulated authors' rebuttal, and a circularity audit.

Referee Report

5 major / 5 minor

Summary. The paper presents RINSER, a framework for predicting Windows API function names from x86 PE binaries. RINSER introduces 'API codeprints', which combine an API's name, its parameter names/values, and semantically related assembly instructions obtained by register-based backtracking from IDA Pro disassembly (Algorithm 1 and 2). The codeprints are tokenized and normalized, then used to pre-train a BERT-style masked language model; the model is fine-tuned for stripped binaries. The authors report 85.77% accuracy on a 10% test split of 4.7M codeprints, 82.88% on simulated stripped codeprints, 88.80% on 1,148 unseen binaries, and 69,921 predicted API names in cases where IDA did not resolve the API. They also compare with three baselines and evaluate robustness against instruction randomization and code displacement.

Significance. If the central claims hold, the paper makes a useful contribution: it provides a large malware-derived WinAPI dataset, a concrete codeprint construction method, and evidence that masked language modeling can exploit API calling context. The ablation study (Appendix A) convincingly shows that full codeprints matter, and the manual validation of 65 obfuscated API names (Appendix E.3) is a genuinely independent check. However, the headline accuracy numbers rest on FLIRT-derived labels, and several reported numbers are internally inconsistent. These issues are load-bearing for the main claims and need to be fixed before the results can be accepted at face value.

major comments (5)
  1. [§5.4, Table 3] Table 3 reports per-row accuracies that do not match the counts in the same table. Row 1: 337,283/449,472 = 75.0%, not 56.94%. Row 2: 164,763/187,084 = 88.1%, not 73.34%. Row ≥6: 74,437/77,092 = 96.6%, not 91.84%. Only the overall 821,895/991,561 = 82.88% is consistent. The surrounding paragraph explains the parameter-count trend using these rows, so the corrected numbers are needed; as printed, the claim that accuracy increases monotonically with parameter count is not supported.
  2. [§3.2.1, §4.2, §5.2] Algorithm 1 (Steps 8–15) identifies API names and parameter names from IDA FLIRT annotations, and §4.2 constructs the labeled dataset from those same annotations. The validation against Microsoft documentation in §4.2 checks API/parameter-name lists, not the per-callsite labels used for training and testing. Both train and test labels therefore originate from the same FLIRT/IDA pipeline, so the reported accuracy may partly measure the model's agreement with IDA's annotation decisions rather than its ability to infer API identity independently. The §5.2 extraction accuracy (91.4%/90.5%) also derives from FLIRT-based extraction. Please provide an independent ground truth for a random sample of test codeprints (e.g., compiled known source or manual reverse engineering) and report accuracy on that sample, along with an analysis of cases where FLIRT annotations are wrong.
  3. [§4.2, Table 2, §5.3] Table 2 reports a 10% test split of 4,744,969 codeprints, but the paper does not state that the split is at the binary level. If codeprints from the same binary appear in both training and test, the 85.77% accuracy in §5.3 can be inflated by binary-specific leakage. The in-the-wild evaluation in §E.2 on 1,148 unseen binaries is an encouraging complementary result, but the main headline number should either be recomputed with a binary-disjoint split or explicitly accompanied by a statement of the split unit and the corresponding accuracy.
  4. [§5.5, §E.3] Section 5.5 reports that RINSER 'correctly predicted' 69,921 API names among 148,685 IDA-unresolved codeprints. Since IDA did not resolve these names, correctness is not defined unless there is an independent ground truth, such as the corresponding non-obfuscated binaries. The manual validation of 65 unique APIs in Appendix E.3 covers only the unique-name level, not the 69,921 predicted instances. Please specify how each of the 69,921 predictions was verified, or report the deobfuscation evaluation only on the subset with known ground truth. The '66% deobfuscation' result on the manually crafted dataset also lacks the denominator and per-API details.
  5. [Appendix D, Table 9] Table 9 is internally inconsistent with the main results. The 'Actual predictions' column gives 89.21% for Normal §5.3 and 82.08% for Stripped §5.4, but §§5.3–5.4 report 85.77% and 82.88%. The Obfuscated row's 47.03% matches 69,921/148,685 only if that is the intended denominator, which is not stated in §5.5. Please reconcile these values and clarify whether different test sets were used. Also, the improvement column reports percentage-point differences (e.g., 0.41 pp) but labels them as percentages; this should be corrected.
minor comments (5)
  1. [Abstract, §1] The paper calls the dataset 'the largest publicly available dataset of this type' but no repository link or availability statement appears in this version. Please add a URL or DOI, and clarify the exact release conditions.
  2. [Algorithm 1, Algorithm 2] The algorithm pseudocode contains typesetting artifacts such as '/u1D439 instrs' and repeated 'instrs' placeholders, and the Unicode variables are difficult to read. Please clean the pseudocode so that the extraction steps are unambiguous.
  3. [References] Reference [25] is labeled 'Hugging Face. Windows apis to intents by malware' and points to malapi.io, but the text in §5.1 cites it for the Transformers fill-mask pipeline. The correct reference appears to be [33]. Please verify and fix this citation.
  4. [Table 10] Table 10 lists 'WriteProcessMemory' twice in the 5-parameter row. Remove the duplicate entry.
  5. [§5.1] The notation for predicted and ground-truth API names uses the same symbol for both quantities ('predicted API name (/u1D464)' and 'ground truth API name (/u1D464)'). Use distinct symbols, e.g., ŷ and y, to define the accuracy metric.

Circularity Check

0 steps flagged

No significant circularity; the API-name predictions are a standard masked-token recovery task over codeprints whose labels and features come from an external annotator (IDA FLIRT) with independent Microsoft documentation validation.

full rationale

RINSER's derivation chain is not circular in the sense of the review rubric. Algorithm 1 constructs API codeprints by reading API names from call operands and parameter names from IDA FLIRT annotations; the ground-truth dataset in Section 4.2 is also based on FLIRT annotations, but those annotations are an external signature-recognition tool, and the paper states that the extracted names were validated against Microsoft's official documentation, which serves as an independent reference. The prediction task in Section 5.1 masks the API-name token from a codeprint and asks the model to fill it in from the remaining tokens; this is a conventional cloze-style supervised setup, not an equation in which the predicted value is defined in terms of the input. The stripped-binary evaluation removes the API and parameter names before prediction, and the obfuscated-binary evaluation uses codeprints in which IDA did not resolve an API name at all, so those settings are not trivially reducible to reading off the label. The large-scale in-the-wild evaluation on 1,148 unseen binaries is external to the training split, and the manual confirmation of 65 obfuscated APIs is an independent check. The overlap between the feature source and label source (both IDA FLIRT) is a legitimate validity and dataset-bias concern that could affect how much the reported accuracy reflects reproduction of FLIRT's signature decisions, but it is not a self-definitional or by-construction circularity under the rules of this pass. There is also no load-bearing self-citation, no imported uniqueness theorem, and no ansatz smuggled in via citation.

Axiom & Free-Parameter Ledger

4 free parameters · 4 axioms · 2 invented entities

The central result depends on assumptions that are not independently verified. Ground truth for 4.7M codeprints is generated by IDA Pro FLIRT annotations and the authors' own heuristics, and the same pipeline generates the test set. Symbolic mapping rules and the context-group threshold are hand-chosen. No external benchmark validates that codeprints are sufficient. These choices do not by themselves invalidate the approach, but reported accuracy numbers are conditional on a specific proprietary toolchain and on the authors' normalization decisions.

free parameters (4)
  • cosine similarity threshold for context groups = 0.91
    Hand-chosen threshold in Appendix D defining when two API names are contextually similar; directly changes the context-aware accuracy numbers.
  • symbolic mapping thresholds for hex addresses = saddr (<=2 hex digits), maddr (2-4), laddr (>4), complex (>=3 operands)
    Hand-defined mapping rules in Table 11 used to normalize codeprints; changes the token distribution and the model input.
  • top-k API truncation for baseline comparison = 1,024
    Evaluation versus Palmtree/Trex is restricted to the 1,024 most frequent API names (covering 96.93% of training and 98.98% of test), which favors dominant classes.
  • BERT masking probability = 15%
    Standard BERT hyperparameter chosen for the masked-LM pretext task; affects what the model learns.
axioms (4)
  • domain assumption IDA Pro FLIRT annotations correctly identify API names and parameter names in normal binaries
    Used as ground truth for all 4.7M codeprints (Section 4.2) and for parameter extraction (Section 3.2.1). If FLIRT is wrong, model labels and inputs are wrong.
  • domain assumption x86 stdcall parameters are always passed via push instructions and annotated by IDA
    Algorithm 1 scans only for push instructions to identify parameters (lines 12-15). Modern compilers often use mov or lea to set up stack arguments, so this premise is a heuristic with roughly 91% accuracy.
  • ad hoc to paper Register dataflow backtracking captures all semantically relevant context for an API call
    Algorithm 2 assumes instructions sharing a CPU register with a parameter value are sufficient context for predicting the API; no formal justification beyond the paper's ablation.
  • domain assumption Unpacked malware binaries from VirusShare are representative of real-world obfuscated malware
    Dataset selection in Section 4.1 excludes packed malware, so results may not generalize to packed samples.
invented entities (2)
  • API codeprint no independent evidence
    purpose: Input representation for the masked LM, combining API name, parameter names/values, and backtracked assembly instructions
    A new analytical construct defined in Section 3.2; its sufficiency is supported only by the paper's own ablation, not by an external benchmark.
  • context-based groups no independent evidence
    purpose: Sets of APIs with pairwise cosine similarity at least 0.91, used to relax the evaluation metric in Appendix D
    A new evaluation construct; no external validation that cosine similarity of BERT embeddings corresponds to functional equivalence.

pith-pipeline@v1.4.0-alltime-deepseek-medium · 4374 in / 4186 out tokens · 190845 ms · 2026-08-05T05:49:12.259919+00:00 · methodology

0 comments
Cite this review

Pith. "Pith review of RINSER: Accurate API Prediction Using Masked Language Models." pith.science (2026). https://pith.science/paper/YNBSKQ4I

@misc{pith2026250904887,
  author       = {Pith},
  title        = {Pith review of: RINSER: Accurate API Prediction Using Masked Language Models},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/YNBSKQ4I}},
  note         = {Machine review of arXiv:2509.04887}
}
Share X Bluesky LinkedIn Reddit HN
read the original abstract

Malware authors commonly use obfuscation to hide API identities in binary files, making analysis difficult and time-consuming for a human expert to understand the behavior and intent of the program. Automatic API prediction tools are necessary to efficiently analyze unknown binaries, facilitating rapid malware triage while reducing the workload on human analysts. In this paper, we present RINSER (AccuRate API predictioN using maSked languagE model leaRning), an automated framework for predicting Windows API (WinAPI) function names. RINSER introduces the novel concept of API codeprints, a set of API-relevant assembly instructions, and supports x86 PE binaries. RINSER relies on BERT's masked language model (LM) to predict API names at scale, achieving 85.77% accuracy for normal binaries and 82.88% accuracy for stripped binaries. We evaluate RINSER on a large dataset of 4.7M API codeprints from 11,098 malware binaries, covering 4,123 unique Windows APIs, making it the largest publicly available dataset of this type. RINSER successfully discovered 65 obfuscated Windows APIs related to C2 communication, spying, and evasion in our dataset, which the commercial disassembler IDA failed to identify. Furthermore, we compared RINSER against three state-of-the-art approaches, showing over 20% higher prediction accuracy. We also demonstrated RINSER's resilience to adversarial attacks, including instruction randomization and code displacement, with a performance drop of no more than 3%.

Figures

Figures reproduced from arXiv: 2509.04887 by Alsharif Abuadbba, Christopher Cody, Muhammad Ali Kaafar, Muhammad Ejaz Ahmed, Muhammad Ikram, Sean Lamont, Seyit Camtepe, Surya Nepal.

Figure 1
Figure 1. Figure 1: Real-world example illustrates the standard and [PITH_FULL_IMAGE:figures/full_fig_p002_1.png] view at source ↗
Figure 2
Figure 2. Figure 2: A real-world example of the sendto API call with its parameters pushed onto the stack (highlighted). Comments (’;’) show parameter names generated by IDA [PITH_FULL_IMAGE:figures/full_fig_p003_2.png] view at source ↗
Figure 3
Figure 3. Figure 3: An overview of RINSER. (A) We first disassemble the input binary using IDA Pro. (B) Then, we build API context by: (1) identify￾ing API callsites and input parameters from disassembly (§ 3.2.1), (2) backtracking, starting from parameters, in the disassembly to extract semantically-related assembly instructions for each API, resulting in API codeprints (§ 3.2.2). (3) we perform symbolic mapping and normal￾i… view at source ↗
Figure 4
Figure 4. Figure 4: API context building from source code backtracking for RegDeleteKeyA (left). The set of semantically-related source code instructions (middle). Symbolic mapping to avoid OOV problem (right). Normalized API codeprints are shown at right-bottom. step 9), its parameter names (obtained from step 15) and values (obtained from step 17), and the context for parameters (obtained from step 18). 3.2.2 Semantic backt… view at source ↗
Figure 5
Figure 5. Figure 5: Examples of API FindResourceA under normal and stripped binary cases. Blue text represent API name where red-color font is API parameter names. Normal binaries contain both the names and values of parame￾ters, whereas stripped binaries contain only the values [PITH_FULL_IMAGE:figures/full_fig_p006_5.png] view at source ↗
Figure 6
Figure 6. Figure 6: Histogram of confidence scores for APIs’ parameters’ count and parameters’ names. 5.2 API parameters extraction accuracy We compute the confidence score of RINSER in identifying API names and their parameters by analyzing disassembly. For exam￾ple, consider the API CryptReleaseContext, which takes two input parameters: hProv and dwFlags. If this API is used 100 times in a given dataset, and RINSER correctl… view at source ↗
Figure 7
Figure 7. Figure 7: APIs distributions within training dataset. [PITH_FULL_IMAGE:figures/full_fig_p013_7.png] view at source ↗
Figure 8
Figure 8. Figure 8: API prediction accuracy with an imbalanced [PITH_FULL_IMAGE:figures/full_fig_p014_8.png] view at source ↗
Figure 9
Figure 9. Figure 9: Top 30 most frequently used APIs in malware with [PITH_FULL_IMAGE:figures/full_fig_p014_9.png] view at source ↗

discussion (0)

Sign in with ORCID, Apple, or X to comment. Anyone can read and Pith papers without signing in.

Reference graph

Works this paper leans on

51 extracted references · 49 canonical work pages · 1 internal anchor

  1. [1]

    https://malwareandstuff.com/deobfuscating-danabots- api-hashing/

    API hashing. https://malwareandstuff.com/deobfuscating-danabots- api-hashing/

    work page

  2. [2]

    https://hex-rays.com/ida-pro/

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

    work page

  3. [3]

    https://www.hex-rays.com/products/ida/support/idapython_docs/

    IDAPython documentation. https://www.hex-rays.com/products/ida/support/idapython_docs/

    work page

  4. [4]

    https://learn.microsoft.com/en-us/windows/win32/api/fileapi/nf-fileapi-createfilew

    Microsoft Documentation. https://learn.microsoft.com/en-us/windows/win32/api/fileapi/nf-fileapi-createfilew

    work page

  5. [5]

    https://virusshare.com/hashfiles/unpacked_hashes.md5

    Unpacked hashes. https://virusshare.com/hashfiles/unpacked_hashes.md5

    work page

  6. [6]

    https://www.virustotal.com

    ViruTotal. https://www.virustotal.com

    work page

  7. [7]

    When mal- ware is packin’heat; limits of machine learning classifiers based on static analy- sis features

    Hojjat Aghakhani, Fabio Gritti, Francesco Mecca, Marti na Lindorfer, Stefano Or- tolani, Davide Balzarotti, Giovanni Vigna, and Christophe r Kruegel. When mal- ware is packin’heat; limits of machine learning classifiers based on static analy- sis features. In Network and Distributed Systems Security (NDSS) Symposium 2020, 2020

    work page 2020

  8. [8]

    Fo recasting malware capabilities from cyber attack memory images

    Omar Alrawi, Moses Ike, Matthew Pruett, Ranjita Pai Kast uri, Srimanta Barua, Taleb Hirani, Brennan Hill, and Brendan Saltaformaggio. Fo recasting malware capabilities from cyber attack memory images. In 30th USENIX Security Sympo- sium (USENIX Security 21) , pages 3523–3540, 2021

    work page 2021

  9. [9]

    O’Reilly Media, Inc

    Steven Bird, Ewan Klein, and Edward Loper. Natural language processing with Python: analyzing text with the natural language toolkit . " O’Reilly Media, Inc. ", 2009

    work page 2009

  10. [10]

    How ai can help reverse engineer malware: Predicting functio n names of code

    Jeff Burt. How ai can help reverse engineer malware: Predicting functio n names of code. https://www.theregister.com/2022/03/26/machine_learning_malware/

    work page 2022

  11. [11]

    Towards paving the way for large-scale windows malware analysis: Generic binary unpacking with orders-of -magnitude perfor- mance boost

    Binlin Cheng, Jiang Ming, Jianmin Fu, Guojun Peng, Ting Chen, Xiaosong Zhang, and Jean-Yves Marion. Towards paving the way for large-scale windows malware analysis: Generic binary unpacking with orders-of -magnitude perfor- mance boost. In Proceedings of the 2018 ACM SIGSAC Conference on Computer and Communications Security, pages 395–411, 2018

    work page 2018

  12. [12]

    {Obfuscation-Resilient} executable payload extrac- tion from packed malware

    Binlin Cheng, Jiang Ming, Erika A Leal, Haotian Zhang, J ianming Fu, Guojun Peng, and Jean-Yves Marion. {Obfuscation-Resilient} executable payload extrac- tion from packed malware. In30th USENIX Security Symposium (USENIX Security 21), pages 3451–3468, 2021

    work page 2021

  13. [13]

    Api deobfuscator: Resolving obfuscated api fun ctions in modern packers

    S Choi. Api deobfuscator: Resolving obfuscated api fun ctions in modern packers. In BlackHat, 2015

    work page 2015

  14. [14]

    Investigating graph embedding methods for cross-platform binary code simi- larity detection

    Victor Cochard, Damian Pfammatter, Chi Thang Duong, an d Mathias Humbert. Investigating graph embedding methods for cross-platform binary code simi- larity detection. In 2022 IEEE 7th European Symposium on Security and Privacy (EuroS&P), pages 60–73. IEEE, 2022

    work page 2022

  15. [15]

    Neural reverse en gineering of stripped binaries using augmented control flow graphs

    Yaniv David, Uri Alon, and Eran Yahav. Neural reverse en gineering of stripped binaries using augmented control flow graphs. Proceedings of the ACM on Pro- gramming Languages, 4(OOPSLA):1–28, 2020

    work page 2020

  16. [16]

    Bert: Pre- training of deep bidirectional transformers for language u nderstanding

    Jacob Devlin, Ming-Wei Chang, Kenton Lee, and Kristina Toutanova. Bert: Pre- training of deep bidirectional transformers for language u nderstanding. arXiv preprint arXiv:1810.04805, 2018

    Pith/arXiv arXiv 2018

  17. [17]

    Asm2vec: Boosting static representation robustness for binary clone search against code obfuscation and compiler optimization

    Steven HH Ding, Benjamin CM Fung, and Philippe Charland . Asm2vec: Boosting static representation robustness for binary clone search against code obfuscation and compiler optimization. In 2019 IEEE Symposium on Security and Privacy (SP) , pages 472–489. IEEE, 2019

    work page 2019

  18. [18]

    Understan ding android obfuscation techniques: A large-scale investigation in th e wild

    Shuaike Dong, Menghao Li, Wenrui Diao, Xiangyu Liu, Jia n Liu, Zhou Li, Feng- hao Xu, Kai Chen, Xiaofeng Wang, and Kehuan Zhang. Understan ding android obfuscation techniques: A large-scale investigation in th e wild. In International conference on security and privacy in communication system s, pages 172–192. Springer, 2018

    work page 2018

  19. [19]

    {DeepReflect}: Discovering malicious functionality through binary recon struction

    Evan Downing, Yisroel Mirsky, Kyuhong Park, and Wenke L ee. {DeepReflect}: Discovering malicious functionality through binary recon struction. In 30th USENIX Security Symposium (USENIX Security 21) , pages 3469–3486, 2021

    work page 2021

  20. [20]

    Dee pbindiff: Learning program-wide code representations for binary diffing

    Yue Duan, Xuezixiang Li, Jinghan Wang, and Heng Yin. Dee pbindiff: Learning program-wide code representations for binary diffing. InNetwork and distributed system security symposium , 2020

    work page 2020

  21. [21]

    The IDA pro book, second eddition

    Chris Eagle. The IDA pro book, second eddition . no starch press, 2011

    work page 2011

  22. [22]

    Mandiant’s Capa

    Google. Mandiant’s Capa. https://github.com/fireeye/capa

    work page

  23. [23]

    Debin: Predicting debug information in stripped binaries

    Jingxuan He, Pesho Ivanov, Petar Tsankov, Veselin Rayc hev, and Martin Vechev. Debin: Predicting debug information in stripped binaries. In Proceedings of the 2018 ACM SIGSAC Conference on Computer and Communications S ecurity, pages 1667–1680, 2018

    work page 2018

  24. [24]

    IDA FLIRT Tec

    Hexrays. IDA FLIRT Tec. https://hex-rays.com/products/ida/tech/flirt/in_depth/

    work page

  25. [25]

    Windows apis to intents by malware

    Hugging Face. Windows apis to intents by malware. https ://malapi.io/. Accessed: 2022-12-19

    work page 2022

  26. [26]

    Symlm : Predicting func- tion names in stripped binaries via context-sensitive exec ution-aware code em- beddings

    Xin Jin, Kexin Pei, Jun Yeon Won, and Zhiqiang Lin. Symlm : Predicting func- tion names in stripped binaries via context-sensitive exec ution-aware code em- beddings. In Proceedings of the 2022 ACM SIGSAC Conference on Computer and Communications Security, pages 1631–1645, 2022

    work page 2022

  27. [27]

    Towards generic deo bfuscation of win- dows api calls

    Vadim Kotov and Michael Wojnowicz. Towards generic deo bfuscation of win- dows api calls. Workshop on Binary Analysis Research (BAR), NDSS , 2018

    work page 2018

  28. [28]

    Abstracting stack to detect obfuscated calls in binaries

    Arun Lakhotia and Eric Uday Kumar. Abstracting stack to detect obfuscated calls in binaries. In Source Code Analysis and Manipulation, Fourth IEEE Interna tional Workshop on, pages 17–26. IEEE, 2004

    work page 2004

  29. [29]

    Palmtree: learning a n assembly language model for instruction embedding

    Xuezixiang Li, Yu Qu, and Heng Yin. Palmtree: learning a n assembly language model for instruction embedding. In Proceedings of the 2021 ACM SIGSAC Con- ference on Computer and Communications Security , pages 3236–3251, 2021

    work page 2021

  30. [30]

    Malgraph: Hierarchical graph neural networ ks for robust win- dows malware detection

    Xiang Ling, Lingfei Wu, Wei Deng, Zhenqing Qu, Jiangyu Z hang, Sheng Zhang, and Tengfei Ma. Malgraph: Hierarchical graph neural networ ks for robust win- dows malware detection. pages 1998–2007, 2022

    work page 1998

  31. [31]

    Research on software s ecurity and compati- bility test for mobile application

    Zhenyu Liu, Yun Hu, and Lizhi Cai. Research on software s ecurity and compati- bility test for mobile application. In Fourth edition of the International Conference on the Innovative Computing Technology (INTECH 2014) , pages 140–145. IEEE, 2014. Muhammad Ejaz Ahmed, Christopher Cody, Muhammad Ikram, Sea n Lamont, Alsharif Abuadbba, Seyit Camtepe, Surya N...

    work page 2014

  32. [32]

    Malware makeover: Breaking ml-based static analysis b y modifying exe- cutable bytes

    Keane Lucas, Mahmood Sharif, Lujo Bauer, Michael K Reit er, and Saurabh Shin- tre. Malware makeover: Breaking ml-based static analysis b y modifying exe- cutable bytes. In Proceedings of the 2021 ACM Asia Conference on Computer and Communications Security, pages 744–758, 2021

    work page 2021

  33. [33]

    Pipelines

    MalAPI.io. Pipelines. https://huggingface.co/docs /transformers/main_classes/pipelines. Accessed: 2022-12-19

    work page 2022

  34. [34]

    M-trends report 2022, 2022

    Google Cloud Mandiant. M-trends report 2022, 2022

    work page 2022

  35. [35]

    Prevalence and impact of low-entrop y packing schemes in the malware ecosystem

    Alessandro Mantovani, Simone Aonzo, Xabier Ugarte-Pe drero, Alessio Merlo, and Davide Balzarotti. Prevalence and impact of low-entrop y packing schemes in the malware ecosystem. In NDSS, 2020

    work page 2020

  36. [36]

    Safe: Self-attentive function embeddi ngs for binary similar- ity

    Luca Massarelli, Giuseppe Antonio Di Luna, Fabio Petro ni, Roberto Baldoni, and Leonardo Querzoni. Safe: Self-attentive function embeddi ngs for binary similar- ity. In Detection of Intrusions and Malware, and Vulnerability Ass essment: 16th International Conference, DIMV A 2019, Gothenburg, Sweden, June 19–20, 2019, Pro- ceedings 16, pages 309–329. Sprin...

    work page 2019

  37. [37]

    sendto function (winsock.h)

    Microsoft. sendto function (winsock.h). https://learn.microsoft.com/en-us/windows/win32/api/winsock/nf-winsock-sendto

    work page

  38. [38]

    Technical documentation

    Microsoft. Technical documentation. https://learn.microsoft.com/en-us/docs/

    work page

  39. [39]

    Smashing the gadgets: Hindering return-oriented programming using in- place code random- ization

    Vasilis Pappas, Michalis Polychronakis, and Angelos D Keromytis. Smashing the gadgets: Hindering return-oriented programming using in- place code random- ization. In 2012 IEEE Symposium on Security and Privacy , pages 601–615. IEEE, 2012

    work page 2012

  40. [40]

    Identifying behavior dispatchers fo r malware anal- ysis

    Kyuhong Park, Burak Sahin, Yongheng Chen, Jisheng Zhao , Evan Downing, Hong Hu, and Wenke Lee. Identifying behavior dispatchers fo r malware anal- ysis. In Proceedings of the 2021 ACM Asia Conference on Computer and Co mmu- nications Security, pages 759–773, 2021

    work page 2021

  41. [41]

    Xfl: Naming func- tions in binaries with extreme multi-label learning

    James Patrick-Evans, Moritz Dannehl, and Johannes Kin der. Xfl: Naming func- tions in binaries with extreme multi-label learning. In 2023 IEEE Symposium on Security and Privacy (SP) , pages 2375–2390. IEEE, 2023

    work page 2023

  42. [42]

    Trex: Learning execution semantics from micro-traces for binary similarity

    Kexin Pei, Zhou Xuan, Junfeng Yang, Suman Jana, and Bais hakhi Ray. Trex: Learning execution semantics from micro-traces for binary similarity. arXiv preprint arXiv:2012.08680, 2020

    Pith/arXiv arXiv 2012

  43. [43]

    Identification of Obfuscated Function Clones in Binaries using Ma- chine Learning

    Michael Pucher. Identification of Obfuscated Function Clones in Binaries using Ma- chine Learning. PhD thesis, Wien, 2022

    work page 2022

  44. [44]

    Software testing techniques and strategies

    Abhijit A Sawant, Pranit H Bari, and PM Chawan. Software testing techniques and strategies. International Journal of Engineering Research and Applica tions (IJERA), 2(3):980–986, 2012

    work page 2012

  45. [45]

    Eureka: A framework for enabling static malware analysis

    Monirul Sharif, Vinod Yegneswaran, Hassen Saidi, Phillip Porras, and Wenke Lee. Eureka: A framework for enabling static malware analysis. I n European Sympo- sium on Research in Computer Security , pages 481–500. Springer, 2008

    work page 2008

  46. [46]

    A museum of api obfuscation on win32

    Masaki Suenaga. A museum of api obfuscation on win32. Symantec Security Re- sponse, 2009

    work page 2009

  47. [47]

    An experimentation framework for evaluating disassembly and decom- pilation tools for c++ and java

    Lori Vinciguerra, Linda Wills, Nidhi Kejriwal, Paul Ma rtino, and Ralph Vin- ciguerra. An experimentation framework for evaluating disassembly and decom- pilation tools for c++ and java. In 10th Working Conference on Reverse Engineer- ing, 2003. WCRE 2003. Proceedings. , pages 14–14. IEEE Computer Society, 2003

    work page 2003

  48. [48]

    A n api deobfusca- tion method combining dynamic and static techniques

    Qi Xi, Tianyang Zhou, Qingxian Wang, and Yongjun Zeng. A n api deobfusca- tion method combining dynamic and static techniques. In Proceedings 2013 Inter- national Conference on Mechatronic Sciences, Electric Eng ineering and Computer (MEC), pages 2133–2138. IEEE, 2013

    work page 2013

  49. [49]

    Hawkeye: cross- platform malware detection with representation learning o n graphs

    Peng Xu, Youyi Zhang, Claudia Eckert, and Apostolis Zar ras. Hawkeye: cross- platform malware detection with representation learning o n graphs. In Interna- tional Conference on Artificial Neural Networks , pages 127–138. Springer, 2021

    work page 2021

  50. [50]

    Order matters: Semantic-aware neural networks for binary code si milarity detection

    Zeping Yu, Rui Cao, Qiyi Tang, Sen Nie, Junzhou Huang, an d Shi Wu. Order matters: Semantic-aware neural networks for binary code si milarity detection. In Proceedings of the AAAI Conference on Artificial Intelligenc e, volume 34, pages 1145–1152, 2020

    work page 2020

  51. [51]

    Neural Machine Translation Inspired Binary Code Similarity Comparison beyond Function Pairs

    Fei Zuo, Xiaopeng Li, Patrick Young, Lannan Luo, Qiang Z eng, and Zhexin Zhang. Neural machine translation inspired binary code sim ilarity comparison beyond function pairs. arXiv preprint arXiv:1808.04706 , 2018. A Ablation study In the ablation study, we investigate the impact on the performance of RINSER in predicting API names under the following thre...

    work page internal anchor Pith review Pith/arXiv arXiv 2018