Pith. sign in

REVIEW 4 major objections 5 minor 39 references

SATURN -- Software Deobfuscation Framework Based on LLVM

T0 review · 4 major / 5 minor · reviewed 2026-08-14 · deepseek-v4-flash

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

Pith's one-line read This paper claims that obfuscated x86_64 binaries can be deobfuscated generically by lifting them into LLVM-IR and letting LLVM's optimizations, Souper, and the Z3 SMT solver simplify away common obfuscation patterns.

desk verdict A useful practical deobfuscation pipeline whose abstract overclaims, worth serious review with an artifact requirement. read the letter →

arxiv 1909.01752 v2 pith:SWBV7RG2 submitted 2019-09-04 cs.CR cs.SC

Peter Garba , Matteo Favaro This is my paper · ORCID
classification cs.CRcs.SC
keywords reverseengineeringllvmcodeliftingobfuscationdeobfuscationstaticsoftwareanalysisbinaryrecompilationrewriting
verification ladder T0 review T1 audit T2 compute T3 formal

The pith

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

The reading

The paper claims that obfuscated x86_64 binaries can be deobfuscated generically by lifting them into LLVM's intermediate representation and then letting strong compiler optimizations remove the obfuscation, including constant unfolding, arithmetic-based opaque expressions, dead code, bogus control flow, and integer encoding found in public and commercial obfuscators. It presents SATURN, a framework that lifts each basic block with Remill, recovers the control flow graph iteratively, and detects opaque predicates by slicing the instruction-pointer computation and simplifying the slice with LLVM, Souper, and the Z3 SMT solver. The payoff is moving reverse engineering from the binary level back to the compiler level, where the same passes that injected the obfuscation can be turned against it. If the approach works, obfuscated functions can be reduced to readable, recompilable LLVM-IR without hand-written pattern rules.

What carries the argument

The load-bearing mechanism is the sliced instruction pointer. SATURN creates a C helper that mimics Remill's basic-block entry point, seeds a State struct with symbolic register values, concretizes the instruction pointer, calls the candidate opaque block, and returns the value the instruction pointer holds afterwards; LLVM's optimizer is then run on that single return value. If the slice reduces to one constant, the branch is opaque and its true destination is known; if not, Souper turns the slice into an SMT formula and Z3 checks whether exactly one solution exists. Around this core, the iterative CFG construction keeps each lifted basic block in its own LLVM function and connects them through a separate control-flow function, so edges can be added or removed without rewriting PHI nodes, and a constant-promotion pass plus stack-slot allocation give LLVM the pointer aliasing information it needs.

What would settle it

Take a function containing a genuine data-dependent branch, for example a branch on whether a runtime input is even, obfuscate it with the same transformations SATURN targets, and run the pipeline: a true branch cannot fold to a single constant, so if SATURN reports it as opaque and removes it, the genericity claim fails. Complementarily, build an opaque predicate whose condition depends on a memory value read inside the branch, which the instruction-pointer slice cannot see, and check whether the tool misclassifies it as a real branch or stalls.

Watch

Extended reading notes

Core claim

The central discovery is that a lifted binary function becomes ordinary LLVM-IR once the stack pointer is concretized and the basic-block functions are inlined, and in that form most injected obfuscation, constant unfolding, arithmetic-based opaque expressions, dead code, bogus control flow, and integer encoding, is eliminated by LLVM's own optimization passes. For opaque predicates that resist optimization, the paper builds a helper function around Remill's basic-block signature, __saturn_slice_rip, that starts from a symbolic register state, concretizes the instruction pointer, executes the candidate block, and returns the final instruction-pointer value. Running LLVM optimizations on that slice folds it to a single constant whenever the branch is opaque; if it does not fold, Souper converts the slice into an SMT formula and Z3 checks satisfiability and uniqueness of the solution. The paper further claims that the deobfuscated function can be brightened: the Remill State struct is stripped, the original calling convention and stack-passed arguments are recovered, and the clean IR is recompiled and injected back into the binary.

Load-bearing premise

The pipeline assumes Remill's per-instruction semantics are faithful and that LLVM, Souper, and Z3 can always reduce the sliced instruction pointer of an injected opaque predicate to one concrete target; when the SMT query comes back unsatisfiable the paper itself treats the branch as real or unprovable, and the user must supply the constant-pool address ranges by hand.

Editorial extensions

If this is right

  • Opaque predicates that resist constant folding can still be detected by proving that the sliced instruction pointer has exactly one possible value, so the recovered control-flow graph loses the injected edges.
  • The recovered LLVM-IR can be recompiled with any LLVM backend and injected back into the original binary, letting the deobfuscated function run inside the protected program.
  • Anti-symbolic-execution protections such as the FOR and SPLIT tricks are weakened or removed on the lifted IR, and downstream symbolic execution on the cleaned function is dramatically faster.
  • Binary code whose source is unavailable can be recompiled with better CPU options or compiler security features, because the output is standard LLVM-IR.
  • In the paper's tests, the deobfuscated programs were semantically equivalent to the obfuscated originals for datasets #1 and #2, including Tigress-virtualized samples that stayed in a clean readable virtualized form.

Reading between the lines

Editorial extensions of the paper, not claims the author makes directly.

  • Editorial inference: because opaqueness is decided by reducing the instruction-pointer slice to one constant, any opaque predicate whose condition depends on memory contents or values outside that slice lies outside the demonstrated scope; widening the slice to include the relevant loads is the natural stress test.
  • Editorial inference: the cache of Souper queries mentioned in the paper is itself a structured dataset of normalized opaque predicates, so a classifier trained on it could predict which branches will resist LLVM before any SMT call.
  • Editorial inference: the paper's 'no assumptions' phrasing is stronger than its implementation, constant-pool ranges are user-supplied and an unsatisfiable SMT query is treated as a real branch or an unprovable predicate, so the durable claim is broad coverage of injected obfuscation patterns rather than universality.
Share X Bluesky LinkedIn Reddit HN

Editorial analysis

A structured set of objections, weighed in public.

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

Referee Report

4 major / 5 minor

Summary. The paper presents SATURN, an LLVM-based static deobfuscation framework for x86_64 binaries. The pipeline lifts binary code to LLVM-IR using Remill, reconstructs the control flow graph through an iterative exploration algorithm, detects and removes opaque predicates using LLVM optimizations, Souper, and the Z3 SMT solver, recovers stack slots and function arguments, 'brightens' the lifted IR into a vanilla-like form, and optionally recompiles and injects the recovered function into the original binary. The authors claim that the approach is generic and 'does not make any assumptions about the obfuscated code' but relies on strong compiler optimizations and SMT solving. The evaluation covers three datasets: self-authored corner-case programs, programs taken from the anti-symbolic-execution paper [22], and two real-world obfuscated binaries, with results reported in Table 3 for CFG recovery, opaque predicate detection, argument/stack recovery, and semantic equivalence.

Significance. If the central claims hold, SATURN would be a practically useful contribution: it combines binary lifting, iterative CFG recovery, and optimizer/SMT-driven opaque predicate detection in a single pipeline, and it demonstrates that LLVM's optimization passes can simplify away several common obfuscation patterns. The paper's use of external obfuscators (Tigress and the [22] repository) for part of the evaluation is a strength, as is the reported reduction in KLEE solving time on the recovered IR. However, the significance is currently limited by three factors: the evaluation is small and lacks statistical rigor; several key results are explicitly marked as partial, unverified, or failing (op1, obf0_virt, and all dataset #3 recompilations); and the paper does not release the tool, only the results repository. The central 'no assumptions' claim is also stronger than what the described algorithms and experiments support.

major comments (4)
  1. [Section 5.4, step (8)] The opaque-predicate classification is not shown to be sound or complete, and the paper explicitly acknowledges the unresolved case. After the uniqueness query, step (8) states that if the query is unsatisfiable, 'a real conditional branch or an opaque predicate which is not provable by the SMT solver has been found,' but no mechanism is provided to distinguish these two cases. A real input-dependent branch misclassified as opaque would silently drop a reachable path from the recovered CFG, while an unproved opaque predicate left in place would create spurious edges. Since the central claim that SATURN recovers semantically equivalent control flow depends on this classification, the paper must either prove correctness under explicit assumptions or, if the approach is best-effort, weaken the abstract's claim that it 'does not make any assumptions about the obfuscated code' and describe the failure semantics of the pipeline.
  2. [Section 5.1 and Section 5.3.1] The 'no assumptions' claim is contradicted by the user-supplied parameters and heuristics described in the paper. Section 5.1 requires the user to supply the constantPool ranges because the constant binary data sections are not sufficient; Section 5.3.1 introduces solverBBCountJcc and solverBBCountReturn, which control how many preceding basic blocks are included in the slice; and Section 5.2 concretizes the stack pointer rather than treating it symbolically. These are not generic, assumption-free choices: they are tuned heuristics that may depend on the obfuscator being analyzed. The paper should state these as explicit assumptions or limitations and analyze how sensitive the results are to their values.
  3. [Table 3 and Section 8.3] The experimental evaluation does not substantiate the semantic-equivalence claim for the cases that matter most. For dataset #3, Section 8.3 reports that recompiled binaries are not working because of additional anti-tampering checks, and the row for obf0_virt reports that the result 'can't be verified' with an unknown number of original basic blocks. Moreover, equivalence is checked by comparing selected output values of small toy programs, not by exhaustive testing or per-function equivalence checking. Thus RQ5 is only answered for dataset #1 and #2, which are small and mostly self-authored. The paper should either add stronger equivalence verification (e.g., test generation with KLEE, differential testing, or formal equivalence checking) or clearly scope the claim as applying only to the verified samples.
  4. [Table 3, RQ2] The reported opaque-predicate detection rate is incomplete. For dataset #3, the text says that the exact number of opaque predicates is unknown, and the assumption that a missed opaque predicate would lead to a broken LLVM-IR is not a substitute for a detection-rate measurement. Additionally, the table shows that several samples are only partially deobfuscated: op1 is marked 'Partially' with the MBA formula not optimized away, binsec0_virt and binsec1 remain in the Remill State struct, and binsec0_virt has 0/2 arguments recovered. The paper should report per-technique success and failure counts rather than a single binary 'Yes/No' column, and should identify which obfuscation patterns each sample actually contains so that the reader can judge the coverage of the claims.
minor comments (5)
  1. [Section 5.4] Step (5) says that if the first satisfiability query is unsatisfiable, 'something went wrong in the proving process and the pass fails,' but step (8) also handles an unsatisfiable query after the second check. The relationship between these two failure cases should be clarified.
  2. [Table 3] The table uses footnotes 'a' through 'f' and symbols such as '?' without a clear legend in the surrounding text; in particular, the '10/?' and '4' entries in the obf0_virt row need explanation.
  3. [Section 8.2] The names 'Obfuscator0' and 'Obfuscator1' are said to be made up, but it is not stated whether these are commercial products, research prototypes, or obfuscators the authors developed themselves; this information affects the generalizability of the dataset #3 results.
  4. [Section 8.3] The statement that 'for all the programs we verified the output binary obtained by SATURN with the IDA Pro decompiler' only establishes readability, not semantic preservation; this should be separated from the correctness verification claim.
  5. [Section 1.2 and Section 8.2] The paper refers to an online repository for datasets and results, but states that the tool SATURN is not released. Since the contribution is a framework, a release of the implementation, or at least a detailed artifact description, would substantially increase reproducibility.

Circularity Check

0 steps flagged · score 0.0 of 10

No significant circularity: the deobfuscation pipeline is evaluated against external obfuscators and its internal reductions are not assumed into existence.

full rationale

SATURN's derivation chain is a static lifting/deobfuscation pipeline: Remill lifts instructions to LLVM-IR, SATURN slices the instruction pointer of candidate conditional branches, and LLVM, Souper, and Z3 reduce the slice to a concrete destination or prove uniqueness. The claimed capability is tested against external Tigress-obfuscated binaries and the anti-DSE samples from the repository of [22], not against outputs produced by a fitted model. The only user-supplied items, such as the constantPool ranges and the solverBBCount options, are configuration knobs rather than parameters fitted to the evaluation targets; they do not make the deobfuscation results equal to the inputs. Section 5.4's admission that an unsatisfiable query leaves unresolved whether a branch is real or an unprovable opaque predicate is an honest limitation, and the abstract's 'does not make any assumptions' wording is overbroad, but that is a scoping or correctness concern, not circularity. No self-citation chain is load-bearing: the cited external tools (LLVM, Remill, Souper, Z3, Tigress) provide independent functionality. The self-authored Dataset #1 creates an evaluation-bias risk, but no specific reduction from fitted input to claimed prediction is exhibited, so no circular step can be reported.

Assumptions & free parameters 2 free parameters · 4 assumptions · 0 invented entities

The paper introduces no new physical or mathematical entities. The load-bearing assumptions are about the faithfulness of external tools (Remill, LLVM, Souper, Z3) and the determinism of the obfuscation patterns. The user-supplied constantPool and solverBBCount parameters are configuration knobs rather than fitted scientific constants, but they do affect the generality of the claimed results.

free parameters (2)
  • constantPool ranges = user-specified
    The SATURN option constantPool tells the tool where to find obfuscated constant data; if these ranges are wrong, constant promotion and folding may fail (Section 5.1).
  • solverBBCountJcc / solverBBCountReturn = user-specified
    These options control how many predecessor basic blocks are included in a slice before proving opaqueness. The choice affects success rate and performance (Section 5.3.1).
assumptions (4)
  • domain assumption Remill's lifting semantics are correct and complete for the x86_64 instruction subset used by the target binaries.
    The entire recovery starts from Remill's State-struct-based instruction semantics (Listing 1, Section 4.1); a lifting error propagates to the CFG recovery and deobfuscation.
  • domain assumption LLVM, Souper, and Z3 are sound and preserve program semantics when applied as rewrite passes.
    Deobfuscation relies on these tools to fold slices and prove opaqueness (Sections 5.3 and 5.4); any unsoundness would change the recovered function's behavior.
  • domain assumption The attacker has the MATE model assumed in Section 3.1: full access to the binary and no access to source code or an unprotected reference.
    The evaluation and claims are framed around this model; white-box or source-available scenarios are not covered.
  • domain assumption Opaque predicates are deterministic branches whose target can be recovered by evaluating a straight-line slice of the instruction pointer.
    The slicing helper in Listing 7 assumes the branch outcome depends only on the initial State and the concrete RIP; dynamic or stateful predicates may evade this.

how reviews work

0 comments
Cite this review

Pith. "Pith review of SATURN -- Software Deobfuscation Framework Based on LLVM." pith.science (2026). https://pith.science/paper/SWBV7RG2

@misc{pith2026190901752,
  author       = {Pith},
  title        = {Pith review of: SATURN -- Software Deobfuscation Framework Based on LLVM},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/SWBV7RG2}},
  note         = {Machine review of arXiv:1909.01752}
}
read the original abstract

The strength of obfuscated software has increased over the recent years. Compiler based obfuscation has become the de facto standard in the industry and recent papers also show that injection of obfuscation techniques is done at the compiler level. In this paper we discuss a generic approach for deobfuscation and recompilation of obfuscated code based on the compiler framework LLVM. We show how binary code can be lifted back into the compiler intermediate language LLVM-IR and explain how we recover the control flow graph of an obfuscated binary function with an iterative control flow graph construction algorithm based on compiler optimizations and SMT solving. Our approach does not make any assumptions about the obfuscated code, but instead uses strong compiler optimizations available in LLVM and Souper Optimizer to simplify away the obfuscation. Our experimental results show that this approach can be effective to weaken or even remove the applied obfuscation techniques like constant unfolding, certain arithmetic-based opaque expressions, dead code insertions, bogus control flow or integer encoding found in public and commercial obfuscators. The recovered LLVM-IR can be further processed by custom deobfuscation passes that are now applied at the same level as the injected obfuscation techniques or recompiled with one of the available LLVM backends. The presented work is implemented in a deobfuscation tool called SATURN.

Figures

Figures reproduced from arXiv: 1909.01752 by the authors.

Figure 1
Figure 1. Workflow of the SATURN deobfuscation frame [PITH_FULL_IMAGE:figures/full_fig_p001_1.png] view at source ↗
Figure 2
Figure 2. LLVM function that contains the control flow graph of the recovered function at address 1000. The ba￾sic blocks are lifted as LLVM functions themselves and get called according to their usage. The result of the call decides the destination of the branch. With this design decision we can directly optimize the lifted basic block function and achieve a performance improvement in further deobfuscation steps. Applying op… view at source ↗

Discussion (0). Continue with ORCID to comment.

Reference graph

Works this paper leans on

39 extracted references · 27 canonical work pages

  1. [22]

    Mathilde Ollivier, Sébastien Bardin, Richard Bonichon, and Jean-Yves Marion

    work page

  2. [1]

    Remis Balaniuk. 2015. Drill and Join: A Method for Exact Inductive Program Synthesis. In Logic-Based Program Synthesis and Transformation, Maurizio Proietti and Hirohisa Seki (Eds.). Springer International Publishing, Cham, 219–237

    work page 2015

  3. [2]

    Fabrice Bellard. 2005. QEMU, a Fast and Portable Dynamic Translator. In Pro- ceedings of the Annual Conference on USENIX Annual Technical Conference (ATEC ’05). USENIX Association, Berkeley, CA, USA, 41–41. http://dl.acm.org/citation. cfm?id=1247360.1247401

    work page arXiv 2005

  4. [3]

    Fabrizio Biondi, Sébastien Josse, Axel Legay, and Thomas Sirvent. 2017. Effective- ness of Synthesis in Concolic Deobfuscation. Computers and Security 70 (Sept. 2017), 500–515. https://doi.org/10.1016/j.cose.2017.07.006

    work page doi:10.1016/j.cose.2017.07.006 2017

  5. [4]

    Cristian Cadar, Daniel Dunbar, and Dawson Engler. 2008. KLEE: Unassisted and Automatic Generation of High-coverage Tests for Complex Systems Programs. In Proceedings of the 8th USENIX Conference on Operating Systems Design and Implementation (OSDI’08). USENIX Association, Berkeley, CA, USA, 209–224. http://dl.acm.org/citation.cfm?id=1855741.1855756

    work page arXiv 2008

  6. [5]

    2016 [cit

    Marek Chalupa. 2016 [cit. 2019-07-12]. Slicing of LLVM Bitcode [online] . Master’s thesis. Masaryk University, Faculty of Informatics, Brno. https://theses.cz/id/ ok0jh1/

    work page 2016

  7. [6]

    Vitaly Chipounov, Volodymyr Kuznetsov, and George Candea. 2012. The S2E Platform: Design, Implementation, and Applications. ACM Trans. Comput. Syst. 30, 1, Article 2 (Feb. 2012), 49 pages. https://doi.org/10.1145/2110356.2110358

    arXiv 2012

  8. [7]

    Christian Collberg, Clark Thomborson, and Douglas Low. 1997. A Taxonomy of Obfuscating Transformations. Technical Report 148. Department of Computer Sciences, The University of Auckland. http://www.cs.auckland.ac.nz/~collberg/ Research/Publications/CollbergThomborsonLow97a/index.html

    work page 1997

Show all 39 references
  1. [8]

    Rosen, Mark N

    Ron Cytron, Jeanne Ferrante, Barry K. Rosen, Mark N. Wegman, and F. Kenneth Zadeck. 1991. Efficiently Computing Static Single Assignment Form and the Control Dependence Graph. ACM Trans. Program. Lang. Syst. 13, 4 (Oct. 1991), 451–490. https://doi.org/10.1145/115372.115320

    1991

  2. [9]

    Leonardo De Moura and Nikolaj Bjørner. 2008. Z3: An Efficient SMT Solver. In Proceedings of the Theory and Practice of Software, 14th International Con- ference on Tools and Algorithms for the Construction and Analysis of Systems (TACAS’08/ETAPS’08). Springer-Verlag, Berlin, H...

    2008

  3. [10]

    Chris Eagle. 2008. The IDA Pro Book: The Unofficial Guide to the World’s Most Popular Disassembler. No Starch Press, San Francisco, CA, USA

    2008

  4. [11]

    Pascal Junod, Julien Rinaldini, Johan Wehrli, and Julie Michielin. 2015. Obfuscator- LLVM – Software Protection for the Masses. In Proceedings of the IEEE/ACM 1st International Workshop on Software Protection, SPRO’15, Firenze, Italy, May 19th, 2015, Brecht Wyseur (Ed.). IEEE,...

    2015 doi

  5. [12]

    Johannes Kinder and Dmitry Kravchenko. 2012. Alternating Control Flow Re- construction. In Proc. 13th Int. Conf. Verification, Model Checking, and Abstract Interpretation (VMCAI) (LNCS), Vol. 7148. Springer, 267–282

    2012

  6. [13]

    Johannes Kinder and Helmut Veith. 2008. Jakstab: A Static Analysis Platform for Binaries. In Proc. 20th Int. Conf. Computer Aided Verification (CA V) (LNCS), Vol. 5123. Springer, 423–427

    2008

  7. [14]

    Lukas Korencik. 2019. Decompiling Binaries into LLVM IR Using McSema and Dyninst. Master’s thesis. Masaryk University, Faculty of Informatics, Brno. https: //is.muni.cz/th/pxe1j/

    2019

  8. [15]

    Kroustek, P

    J. Kroustek, P. Matula, and P. Zemek. 2017. RetDec: An Open-Source Machine- Code Decompiler. [talk]. Presented at Botconf 2017, Montpellier, FR

    2017

  9. [16]

    Chris Lattner and Vikram Adve. 2004. LLVM: A Compilation Framework for Lifelong Program Analysis & Transformation. In Proceedings of the International Symposium on Code Generation and Optimization: Feedback-directed and Runtime Optimization (CGO ’04) . IEEE Computer Society, W...

    2004

  10. [17]

    LLVM Mailing List. 2019. Optimization Problem. Retrieved July 12, 2019 from http://llvm.1065342.n5.nabble.com/llvm-dev-Optimization-Problem- td127994.html#a127998

    2019

  11. [18]

    Microsoft. 2018. x64 calling convention. Retrieved July 13, 2019 from https: //docs.microsoft.com/en-us/cpp/build/x64-calling-convention?view=vs-2019

    2018

  12. [19]

    Jiang Ming, Dongpeng Xu, Li Wang, and Dinghao Wu. 2015. LOOP: Logic- Oriented Opaque Predicate Detection in Obfuscated Binary Code. In Proceedings of the 22 nd ACM SIGSAC Conference on Computer and Communications Security (CCS ’15). ACM, New York, NY, USA, 757–768. https://doi...

    2015 doi

  13. [20]

    Trail of Bits. 2019. McSema - Framework for lifting X86, AMD64, and AARCH64 program binaries to LLVM bitcode. Retrieved August 24, 2019 from https: //github.com/trailofbits/mcsema

    2019

  14. [21]

    Trail of Bits. 2019. Remill - Library for lifting of x86, amd64, and aarch64 machine code to LLVM bitcode. Retrieved July 10, 2019 from https://github.com/trailofbits/ remill

    2019

  15. [23]

    Quarkslab. 2019. Epona - Epona is a new compiler that integrates innovative soft- ware protection for code integrity, obfuscation, and tamper-proofing. Retrieved August 27, 2019 from https://epona.quarkslab.com/en/

    2019

  16. [24]

    Redislabs. 2019. Redis: open source, in-memory data structure store, used as a database, cache and message broker. Retrieved August 22, 2019 from https: //redis.io

    2019

  17. [25]

    John Regehr. 2019. Souper github - Use ConstantRange analysis to help Constant Synthesis. Retrieved August 24, 2019 from https://github.com/google/souper/ commit/20b20ef8c8883513a9cc388b5c01743b70033fb5

    2019

  18. [26]

    Thomas Reinbacher and Jörg Brauer. 2011. Precise Control Flow Reconstruction Using Boolean Logic. In Proceedings of the Ninth ACM International Conference on Embedded Software (EMSOFT ’11) . ACM, New York, NY, USA, 117–126. https: //doi.org/10.1145/2038642.2038662

    2011

  19. [27]

    Raimondas Sasnauskas, Yang Chen, Peter Collingbourne, Jeroen Ketema, Jubi Taneja, and John Regehr. 2017. Souper: A Synthesizing Superoptimizer. CoRR (2017). http://arxiv.org/abs/1711.04422

    2017 arXiv

  20. [28]

    Sebastian Schrittwieser, Stefan Katzenbeisser, Johannes Kinder, Georg Merz- dovnik, and Edgar Weippl. 2016. Protecting Software Through Obfuscation: Can It Keep Pace with Progress in Code Analysis? ACM Comput. Surv. 49, 1, Article 4 (April 2016), 37 pages. https://doi.org/10.1...

    2016 doi

  21. [29]

    Jiri Slaby. 2016. LLVM Slicer - Static slicer based on the Mark Weiser’s algorithm. Retrieved July 12, 2019 from https://github.com/sdasgup3/llvm-slicer

    2016

  22. [30]

    Clark Taylor and Christian Colberg. 2016. A Tool for Teaching Reverse Engineer- ing. In 2016 USENIX Workshop on Advances in Security Education (ASE 16). USENIX Association, Austin, TX. https://www.usenix.org/conference/ase16/workshop- program/presentation/taylor

    2016

  23. [31]

    Philippe Tillet, H. T. Kung, and David Cox. 2019. Triton: An Intermediate Language and Compiler for Tiled Neural Network Computations. In Proceed- ings of the 3rd ACM SIGPLAN International Workshop on Machine Learning and Programming Languages (MAPL 2019) . ACM, New York, NY, ...

    2019

  24. [32]

    Ramtine Tofighi-Shirazi, Irina Măriuca Asăvoae, Philippe Elbaz-Vincent, and Thanh-Ha Le. 2019. Defeating Opaque Predicates Statically through Machine Learning and Binary Analysis. In 3rd International Workshop on Software PROtec- tion. London, United Kingdom. https://hal.archi...

    2019

  25. [33]

    2011.Engineering A Compiler (2nd ed.)

    Linda Torczon and Keith Cooper. 2011.Engineering A Compiler (2nd ed.). Morgan Kaufmann Publishers Inc., San Francisco, CA, USA

    2011

  26. [34]

    Julien Vanegue, Sean Heelan, and Rolf Rolles. 2012. SMT Solvers for Software Security. In Proceedings of the 6th USENIX Conference on Offensive Technologies (WOOT’12). USENIX Association, Berkeley, CA, USA, 9–9. http://dl.acm.org/ citation.cfm?id=2372399.2372412

    2012

  27. [35]

    Shuai Wang, Pei Wang, and Dinghao Wu. 2015. Reassembleable Disassembling. In Proceedings of the 24th USENIX Conference on Security Symposium (SEC’15) . USENIX Association, Berkeley, CA, USA, 627–642. http://dl.acm.org/citation. cfm?id=2831143.2831183

    2015

  28. [36]

    Bharadwaj Yadavalli and Aaron Smith

    S. Bharadwaj Yadavalli and Aaron Smith. 2019. Raising Binaries to LLVM IR with MCTOLL (WIP Paper). In Proceedings of the 20th ACM SIGPLAN/SIGBED International Conference on Languages, Compilers, and Tools for Embedded Systems (LCTES 2019) . ACM, New York, NY, USA, 213–218. htt...

    2019

  29. [37]

    Yadegari, B

    B. Yadegari, B. Johannesmeyer, B. Whitely, and S. Debray. 2015. A Generic Ap- proach to Automatic Deobfuscation of Executable Code. In 2015 IEEE Symposium on Security and Privacy . 674–691. https://doi.org/10.1109/SP.2015.47

    2015 doi

  30. [38]

    Yingzhou Zhang. 2019. SymPas: Symbolic Program Slicing. CoRR (2019). http: //arxiv.org/abs/1903.05333

    2019 arXiv

  31. [2019]

    CoRR (2019)

    How to Kill Symbolic Deobfuscation for Free; or Unleashing the Potential of Path-Oriented Protections. CoRR (2019). http://arxiv.org/abs/1908.01549

    2019 arXiv

Pith tools

Reviewed August 14, 2026 · model on record in the stance chip above.