pith. sign in

arxiv: 1907.01445 · v2 · pith:SK5F47CYnew · submitted 2019-07-02 · 💻 cs.CR

Extended Report on the Obfuscated Integration of Software Protections

Jens Van den Broeck , Bart Coppens , Bjorn De Sutter This is my paper

Pith reviewed 2026-05-25 11:02 UTC · model grok-4.3

classification 💻 cs.CR
keywords software protectionobfuscationreverse engineeringman-at-the-end attacksopaque predicatescode layout randomizationcode factoringmodule boundary obfuscation
0
0 comments X

The pith

Combining code layout randomization, interprocedurally coupled opaque predicates, and code factoring with control flow idioms blurs module boundaries to slow reverse engineering of protected software.

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

Software protections often require linked support modules, but attackers exploit their modular boundaries to speed up identification of code, assets, and protections. The paper proposes to counter this by combining three cross-boundary techniques that thwart disassembly and function reconstruction. Extensive experiments and sensitivity analysis on realistic use cases with state-of-the-art tools show the combined method is potent and resilient to advanced attacks. A sympathetic reader would care because it directly addresses a known weakness in modular software protections against man-at-the-end attacks.

Core claim

To counter exploitation of the modular nature of applications and their protections at different levels of granularity, the boundaries between the modules in the program need to be obfuscated by combining three cross-boundary protection techniques: code layout randomization, interprocedurally coupled opaque predicates, and code factoring with intraprocedural control flow idioms. Elaborate experimental evaluation and extensive sensitivity analysis on realistic use cases and state-of-the-art tools demonstrate the technique's potency and resilience to advanced attacks.

What carries the argument

The combination of code layout randomization, interprocedurally coupled opaque predicates, and code factoring with intraprocedural control flow idioms to obfuscate module boundaries and thwart disassembly.

If this is right

  • Attackers can no longer exploit modular boundaries to speed up the identification and comprehension process of relevant code, assets, and applied protections.
  • The modular nature of applications and protections becomes less exploitable at different levels of granularity.
  • The disassembly process and in particular the reconstruction of functions is thwarted.
  • The protections demonstrate potency and resilience through sensitivity analysis on realistic use cases.

Where Pith is reading between the lines

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

  • The same boundary obfuscation approach could be tested on protection techniques not covered in the original experiments.
  • Protection tool designers might adopt these three techniques as a standard cross-boundary layer in future releases.
  • The method could reduce the effectiveness of automated binary analysis pipelines that rely on clear module separation.

Load-bearing premise

The chosen state-of-the-art tools and realistic use cases adequately represent the capabilities and scenarios of real-world attackers attempting to exploit modular boundaries in protected software.

What would settle it

An experiment in which a new attacker tool or different use case successfully reconstructs functions and identifies assets faster despite the combined protections would disprove the claimed resilience.

Figures

Figures reproduced from arXiv: 1907.01445 by Bart Coppens, Bjorn De Sutter, Jens Van den Broeck.

Figure 1
Figure 1. Figure 1: Example of coupled opaque predicates limited to coupling pairs of opaque predicates mutually, we can easily couple more in larger cycles. A local code comprehension task for the attacker then becomes a global one; the effort needed to undo the protection grows. A similar reasoning holds for fully automated analyses. Had the opaque predicates not been mutually coupled in the example of [PITH_FULL_IMAGE:fig… view at source ↗
Figure 3
Figure 3. Figure 3: Branch function on the protections presented so far in the next section to also make some dynamic attacks less effective. 5 CODE FACTORING To prevent that some of the stronger attacks can reconstruct the CFGs of a program’s functions completely by identifying fake edges that can never be executed, we need to insert control flow transfers with more than one true outgoing edge. In line with what we discussed… view at source ↗
Figure 4
Figure 4. Figure 4: Code factoring for obfuscation Blocks B and E are identical in the original code. If both of them can actually be executed in the original program, both edges coming out of the factored block BE will be executable in the transformed program. So the transfer at the end of block BE will show variable behavior. Moreover, the code in BE will be executed on data from two different contexts, and hence also displ… view at source ↗
Figure 5
Figure 5. Figure 5: Factoring candidate slices in bold in their respective [PITH_FULL_IMAGE:figures/full_fig_p008_5.png] view at source ↗
Figure 6
Figure 6. Figure 6: Split factoring candidate slices contexts from which the factored fragment was extracted, the dispatcher is then controlled by semantically relevant data originating from more than one execution context. The invariants that held in those original contexts in isolation likely do not hold in the merged context after factoring. We conjecture that this makes code comprehension harder. It also ensures that de-o… view at source ↗
Figure 7
Figure 7. Figure 7: Factored slices thermore, factoring a set of fragments changes the data flow properties in the surrounding code, e.g., by making previously dead registers containing non-zero or constant data live, so one factoring can impact the potential of another candidate one. The order in which we select and apply actual factorings is therefore important. The selection order also needs to strike a balance be￾tween th… view at source ↗
Figure 8
Figure 8. Figure 8: Transformation with dynamic switch tables [PITH_FULL_IMAGE:figures/full_fig_p011_8.png] view at source ↗
Figure 9
Figure 9. Figure 9: Relative archive sizes and their individual coverage in the benchmarks, plus overall coverage per benchmark [PITH_FULL_IMAGE:figures/full_fig_p013_9.png] view at source ↗
Figure 10
Figure 10. Figure 10: Fraction of all instructions that get factored from within the indicated number of archives [PITH_FULL_IMAGE:figures/full_fig_p015_10.png] view at source ↗
Figure 11
Figure 11. Figure 11: Fraction of all instructions that get factored from within the indicated number of object files [PITH_FULL_IMAGE:figures/full_fig_p015_11.png] view at source ↗
Figure 12
Figure 12. Figure 12: Fraction of all instructions that get factored from within the indicated number of functions [PITH_FULL_IMAGE:figures/full_fig_p015_12.png] view at source ↗
Figure 13
Figure 13. Figure 13: Fraction of all instructions that get factored from within the indicated number of covered slices/sequences [PITH_FULL_IMAGE:figures/full_fig_p016_13.png] view at source ↗
Figure 14
Figure 14. Figure 14: Fraction of covered instructions that get factored from within the indicated number of covered slices/sequences [PITH_FULL_IMAGE:figures/full_fig_p016_14.png] view at source ↗
Figure 15
Figure 15. Figure 15: Heatmap dissecting the applicability of factoring on the SLM benchmark, showing the number of fragments [PITH_FULL_IMAGE:figures/full_fig_p016_15.png] view at source ↗
Figure 16
Figure 16. Figure 16: Heatmap dissecting the applicability of factoring on the DRM benchmark, showing the number of fragments [PITH_FULL_IMAGE:figures/full_fig_p017_16.png] view at source ↗
Figure 17
Figure 17. Figure 17: Heatmap dissecting the applicability of factoring on the 436.cactusADM benchmark, showing the number of [PITH_FULL_IMAGE:figures/full_fig_p017_17.png] view at source ↗
Figure 18
Figure 18. Figure 18: Heatmap dissecting the applicability of factoring on the 445.gobmk benchmark, showing the number of fragments [PITH_FULL_IMAGE:figures/full_fig_p018_18.png] view at source ↗
Figure 19
Figure 19. Figure 19: Heatmap dissecting the applicability of factoring on the 454.calculix benchmark, showing the number of [PITH_FULL_IMAGE:figures/full_fig_p018_19.png] view at source ↗
Figure 20
Figure 20. Figure 20: Instructions reachable from function entry points in different numbers of archives/object files/functions, [PITH_FULL_IMAGE:figures/full_fig_p024_20.png] view at source ↗
Figure 21
Figure 21. Figure 21: Variability of dispatcher execution paths [PITH_FULL_IMAGE:figures/full_fig_p025_21.png] view at source ↗
Figure 24
Figure 24. Figure 24: The measured run times are averages of 5 runs. [PITH_FULL_IMAGE:figures/full_fig_p025_24.png] view at source ↗
Figure 24
Figure 24. Figure 24: Overhead versus factored code fragments Parameter Value 1. main RNG seed 0xDEADDEADDEADDEAD 2. code layout random seed 1 3. predicate insertion probability 20% 4. fake edge cycle size 4 5. fake edge cycle insertion probability 100% 6. fake edge fall-through probability 50% 7. fake table entry probability 30% 8. factoring transformation probability 100% 9. enabled dispatchers all types 10. fraction of hott… view at source ↗
Figure 25
Figure 25. Figure 25: Sensitivity analysis on the factoring transformation probability (X-axis) [PITH_FULL_IMAGE:figures/full_fig_p027_25.png] view at source ↗
Figure 26
Figure 26. Figure 26: Sensitivity analysis on the probability to create cycles of coupled obfuscations (X-axis) [PITH_FULL_IMAGE:figures/full_fig_p028_26.png] view at source ↗
Figure 27
Figure 27. Figure 27: Sensitivity analysis on the size of coupled obfuscation cycles (X-axis) [PITH_FULL_IMAGE:figures/full_fig_p029_27.png] view at source ↗
Figure 28
Figure 28. Figure 28: Sensitivity analysis on the fake switch entry insertion probability (X-axis) [PITH_FULL_IMAGE:figures/full_fig_p030_28.png] view at source ↗
Figure 29
Figure 29. Figure 29: Sensitivity analysis on the probability that fake edges are fall-through (X-axis) [PITH_FULL_IMAGE:figures/full_fig_p031_29.png] view at source ↗
Figure 30
Figure 30. Figure 30: Sensitivity analysis on the opaque predicate insertion probability (X-axis) [PITH_FULL_IMAGE:figures/full_fig_p032_30.png] view at source ↗
Figure 31
Figure 31. Figure 31: Effect of the probability to apply code factoring (X-axis) on the fraction of broken pairs (Y-axis) [PITH_FULL_IMAGE:figures/full_fig_p033_31.png] view at source ↗
read the original abstract

To counter man-at-the-end attacks such as reverse engineering and tampering, software is often protected with techniques that require support modules to be linked into the application. It is well-known, however, that attackers can exploit the modular nature of applications and their protections to speed up the identification and comprehension process of the relevant code, the assets, and the applied protections. To counter that exploitation of modularity at different levels of granularity, the boundaries between the modules in the program need to be obfuscated. We propose to do so by combining three cross-boundary protection techniques that thwart the disassembly process and in particular the reconstruction of functions: code layout randomization, interprocedurally coupled opaque predicates, and code factoring with intraprocedural control flow idioms. By means of an elaborate experimental evaluation and an extensive sensitivity analysis on realistic use cases and state-of-the-art tools, we demonstrate our technique's potency and resilience to advanced attacks. All relevant code is publicly available online.

Editorial analysis

A structured set of objections, weighed in public.

Desk editor's note, referee report, simulated authors' rebuttal, and a circularity audit. Tearing a paper down is the easy half of reading it; the pith above is the substance, this is the friction.

Referee Report

0 major / 2 minor

Summary. The paper proposes obfuscating module boundaries in software protections against man-at-the-end attacks by combining code layout randomization, interprocedurally coupled opaque predicates, and code factoring with intraprocedural control flow idioms. It supports the claims of potency and resilience via an elaborate experimental evaluation and sensitivity analysis on realistic use cases with state-of-the-art tools, and makes all relevant code publicly available.

Significance. If the empirical results hold, the work offers a practical cross-boundary obfuscation method that directly addresses exploitation of modularity in protected applications. The public code release is a clear strength, enabling reproducibility and independent validation of the experiments on the described use cases.

minor comments (2)
  1. Abstract: The phrase 'elaborate experimental evaluation' is imprecise; specifying the number of use cases, tools, and key metrics (e.g., success rates or attack times) would improve clarity without altering the central claim.
  2. The manuscript would benefit from an explicit limitations subsection discussing the scope of the chosen attack tools, even if the primary claims are scoped to the tested scenarios.

Simulated Author's Rebuttal

0 responses · 0 unresolved

We thank the referee for the positive assessment of our work, the recognition of its practical contributions to cross-boundary obfuscation, and the recommendation for minor revision. The public code release and experimental evaluation on realistic use cases are indeed central strengths.

Circularity Check

0 steps flagged

No significant circularity

full rationale

The paper is an empirical report on combining three obfuscation techniques (code layout randomization, coupled opaque predicates, code factoring) and evaluating them experimentally on use cases with state-of-the-art tools. No derivation chain, equations, predictions, or first-principles results are claimed or present in the abstract or described approach. The central claim rests on experimental demonstration rather than any reduction of outputs to fitted inputs or self-citations by construction. The evaluation is self-contained against external benchmarks (public code, realistic use cases, independent tools), with no load-bearing self-referential steps.

Axiom & Free-Parameter Ledger

0 free parameters · 0 axioms · 0 invented entities

No free parameters, axioms, or invented entities are identifiable from the abstract alone; the work relies on standard assumptions in software security research such as the representativeness of chosen attack tools.

pith-pipeline@v0.9.0 · 5697 in / 1059 out tokens · 25917 ms · 2026-05-25T11:02:19.391647+00:00 · methodology

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

54 extracted references · 54 canonical work pages · 1 internal anchor

  1. [1]

    Understanding the behaviour of hackers while performing attack tasks in a professional setting and in a public challenge,

    M. Ceccato, P . Tonella, C. Basile, P . Falcarin, M. Torchiano, B. Cop- pens, and B. De Sutter, “Understanding the behaviour of hackers while performing attack tasks in a professional setting and in a public challenge,” Empirical Software Engineering, vol. 24, no. 1, pp. 240–286, 2019

    work page 2019

  2. [2]

    Software protection with code mobility,

    A. Cabutto, P . Falcarin, B. Abrath, B. Coppens, and B. De Sutter, “Software protection with code mobility,” in Proc. of the Second ACM Workshop on Moving Target Defense, 2015, pp. 95–103

    work page 2015

  3. [3]

    Barrier slicing for remote software trusting,

    M. Ceccato, M. Dalla Preda, J. Nagra, C. Collberg, and P . Tonella, “Barrier slicing for remote software trusting,” in Seventh IEEE Int’l Working Conf. on Source Code Analysis and Manipulation , 2007, pp. 27–36

    work page 2007

  4. [4]

    Reactive attestation: Automatic detection and re- action to software tampering attacks,

    A. Viticchi ´e, C. Basile, A. Avancini, M. Ceccato, B. Abrath, and B. Coppens, “Reactive attestation: Automatic detection and re- action to software tampering attacks,” in Proc. of the 2016 ACM Workshop on Software PROtection, 2016, pp. 73–84

    work page 2016

  5. [5]

    Tightly-coupled self-debugging software protection,

    B. Abrath, B. Coppens, S. Volckaert, J. Wijnant, and B. De Sutter, “Tightly-coupled self-debugging software protection,” in Proc. of the 6th Workshop on Software Security, Protection, and Reverse Engi- neering, 2016, p. 7

    work page 2016

  6. [6]

    A secure and robust ap- proach to software tamper resistance,

    S. Ghosh, J. D. Hiser, and J. W. Davidson, “A secure and robust ap- proach to software tamper resistance,” in Proc. of the Int’l Workshop on Information Hiding, 2010, pp. 33–47

    work page 2010

  7. [7]

    Nagra and C

    J. Nagra and C. Collberg, Surreptitious Software: Obfuscation, Wa- termarking, and Tamperproofing for Software Protection . Pearson Education, 2009

    work page 2009

  8. [8]

    Cognitive complexity of software and its measure- ment,

    Y. Wang, “Cognitive complexity of software and its measure- ment,” in 2006 5th IEEE Int’l Conf. on Cognitive Informatics , vol. 1, July 2006, pp. 226–235

    work page 2006

  9. [9]

    A measure of control flow complexity in program text,

    M. R. Woodward, M. A. Hennell, and D. Hedley, “A measure of control flow complexity in program text,” IEEE Trans. Softw. Eng., vol. 5, no. 1, pp. 45–50, Jan. 1979

    work page 1979

  10. [10]

    Obfuscation of executable code to improve resistance to static disassembly,

    C. Linn and S. Debray, “Obfuscation of executable code to improve resistance to static disassembly,” in Proc. of the 10th ACM Conf. on Computer and Communications Security, 2003, pp. 290–299

    work page 2003

  11. [11]

    Diablo: a reliable, retargetable and extensible link-time rewriting framework,

    L. Van Put, D. Chanet, B. De Bus, B. De Sutter, and K. De Bosschere, “Diablo: a reliable, retargetable and extensible link-time rewriting framework,” in Proc. of the Fifth IEEE Int’l Symposium on Signal Processing and Information Technology, 2005., 2005, pp. 7–12

    work page 2005

  12. [12]

    Compiler techniques for code compaction,

    S. K. Debray, W. Evans, R. Muth, and B. De Sutter, “Compiler techniques for code compaction,” ACM Transactions on Program- ming languages and Systems (TOPLAS) , vol. 22, no. 2, pp. 378–415, 2000

    work page 2000

  13. [13]

    Muchnick et al., Advanced compiler design implementation

    S. Muchnick et al., Advanced compiler design implementation . Mor- gan kaufmann, 1997

    work page 1997

  14. [14]

    Feedback-driven binary code diversification,

    B. Coppens, B. De Sutter, and J. Maebe, “Feedback-driven binary code diversification,” ACM Transactions on Architecture and Code Optimization (TACO), vol. 9, no. 4, p. 24, 2013

    work page 2013

  15. [15]

    Address space layout permutation (ASLP): Towards fine-grained randomization of commodity software,

    C. Kil, J. Jun, C. Bookholt, J. Xu, and P . Ning, “Address space layout permutation (ASLP): Towards fine-grained randomization of commodity software,” in Proc. 22nd Annual Computer Security Applications Conf., 2006, pp. 339–348

    work page 2006

  16. [16]

    Binary code is not easy,

    X. Meng and B. P . Miller, “Binary code is not easy,” in Proc. of the 25th Int’l Symposium on Software Testing and Analysis , 2016, pp. 24–35

    work page 2016

  17. [17]

    Detecting large number of infeasible paths through recognizing their patterns,

    M. N. Ngo and H. B. K. Tan, “Detecting large number of infeasible paths through recognizing their patterns,” in Proc. of the the 6th 33 0 10 20 30 40 50 60 70 80 90 100 1 10 25 50 75 100 fraction of broken pairs % (a) 436.cactusADM 0 10 20 30 40 50 60 70 80 90 100 1 10 25 50 75 100 fraction of broken pairs % (b) 445.gobmk 0 10 20 30 40 50 60 70 80 90 100 ...

    work page 2007

  18. [18]

    Opaque predicates detection by abstract interpretation,

    M. Dalla Preda, M. Madou, K. De Bosschere, and R. Giacobazzi, “Opaque predicates detection by abstract interpretation,” in Int’l Conf. on Algebraic Methodology and Software Technology , 2006, pp. 81–95

    work page 2006

  19. [19]

    Symbolic execution of obfuscated code,

    B. Yadegari and S. Debray, “Symbolic execution of obfuscated code,” in Proc. of the 22nd ACM SIGSAC Conf. on Computer and Communications Security, 2015, pp. 732–744

    work page 2015

  20. [20]

    A generic approach to automatic deobfuscation of executable code,

    B. Yadegari, B. Johannesmeyer, B. Whitely, and S. Debray, “A generic approach to automatic deobfuscation of executable code,” in IEEE Symposium on Security and Privacy, May 2015, pp. 674–691

    work page 2015

  21. [21]

    Application security through program obfuscation,

    M. Madou, “Application security through program obfuscation,” 2006

    work page 2006

  22. [22]

    Manufacturing cheap, resilient, and stealthy opaque constructs,

    C. S. Collberg, C. D. Thomborson, and D. Low, “Manufacturing cheap, resilient, and stealthy opaque constructs,” in POPL, 1998

    work page 1998

  23. [23]

    Constant propagation with con- ditional branches,

    M. N. Wegman and F. K. Zadeck, “Constant propagation with con- ditional branches,” ACM Transactions on Programming Languages and Systems (TOPLAS), vol. 13, no. 2, pp. 181–210, 1991

    work page 1991

  24. [24]

    Software tamper resistance: Obstructing static analysis of programs,

    C. Wang, J. Hill, J. Knight, and J. Davidson, “Software tamper resistance: Obstructing static analysis of programs,” Technical Report CS-2000-12, University of Virginia, 12 2000, Tech. Rep., 2000

    work page 2000

  25. [25]

    Compiler techniques for code compression,

    S. Debray, W. Evans, and R. Muth, “Compiler techniques for code compression,” in Workshop on Compiler Support for System Software, 1999, pp. 117–123

    work page 1999

  26. [26]

    Sifting out the mud: low level C++ code reuse,

    B. De Sutter, B. De Bus, and K. De Bosschere, “Sifting out the mud: low level C++ code reuse,” in ACM SIGPLAN Notices , vol. 37, no. 11, 2002, pp. 275–291

    work page 2002

  27. [27]

    [Online]

    (2018, May) /OPT (Optimizations) — Microsoft Docs. [Online]. Available: https://docs.microsoft.com/en-us/cpp/ build/reference/opt-optimizations?view=vs-2019

    work page 2018

  28. [28]

    Sifting out the mud: low level c++ code reuse,

    B. De Sutter, B. De Bus, and K. De Bosschere, “Sifting out the mud: low level c++ code reuse,” in Proc. of the 17th ACM SIGPLAN Conf. on Object-oriented programming, systems, languages, and applications (OOPSLA), vol. 37, no. 11, 2002, pp. 275–291

    work page 2002

  29. [29]

    Exploiting function similarity for code size reduction,

    T. J. Edler von Koch, B. Franke, P . Bhandarkar, and A. Dasgupta, “Exploiting function similarity for code size reduction,” ACM SIGPLAN Notices, vol. 49, no. 5, pp. 85–94, 2014

    work page 2014

  30. [30]

    Function merging by sequence alignment,

    R. C. Rocha, P . Petoumenos, Z. Wang, M. Cole, and H. Leather, “Function merging by sequence alignment,” in Proc. of the 2019 IEEE/ACM Int’l Symposium on Code Generation and Optimization , 2019, pp. 149–163

    work page 2019

  31. [31]

    A survey of program slicing techniques,

    F. Tip, “A survey of program slicing techniques,” Journal of pro- gramming languages, vol. 3, no. 3, pp. 121–189, 1995

    work page 1995

  32. [32]

    Bidirectional liveness analysis, or how less than half of the alphas registers are used,

    B. De Sutter, B. De Bus, and K. De Bosschere, “Bidirectional liveness analysis, or how less than half of the alphas registers are used,” Journal of Systems Architecture , vol. 52, no. 10, pp. 535–548, 2006

    work page 2006

  33. [33]

    Compiler tech- niques for code compaction,

    S. K. Debray, W. Evans, R. Muth, and B. De Sutter, “Compiler tech- niques for code compaction,” ACM Transactions on Programming Languages and Systems, vol. 22, no. 2, pp. 378–415, 3 2000

    work page 2000

  34. [34]

    Alias analysis of executable code,

    S. Debray, R. Muth, and M. Weippert, “Alias analysis of executable code,” in Proc. ACM POPL, 1998, pp. 12–24

    work page 1998

  35. [35]

    D5.11 ASPIRE Framework Report,

    C. Basile, “D5.11 ASPIRE Framework Report,” POLITO,” techreport, Nov. 2016. [Online]. Available: https://aspire-fp7.eu/ sites/default/files/D5.11-ASPIRE-Framework-Report.pdf

    work page 2016

  36. [36]

    Code obfuscation against symbolic execution at- tacks,

    S. Banescu, C. Collberg, V . Ganesh, Z. Newsham, and A. Pretschner, “Code obfuscation against symbolic execution at- tacks,” in Proc. of the 32nd Annual Conf. on Computer Security Applications, 2016, pp. 189–200

    work page 2016

  37. [37]

    SPEC CPU 2006,

    Standard Performance Evaluation Corporation, “SPEC CPU 2006,” Jan. 2018. [Online]. Available: https://www.spec.org/cpu2006/

    work page 2006

  38. [38]

    Home — Aspire-FP7,

    “Home — Aspire-FP7,” Sept. 2018. [Online]. Available: https: //aspire-fp7.eu/

    work page 2018

  39. [39]

    D1.06 ASPIRE Validation,

    B. De Sutter, “D1.06 ASPIRE Validation,” Ghent University,” techreport, Jan. 2016. [Online]. Available: https://aspire-fp7.eu/ sites/default/files/D1.06-ASPIRE-Validation-v1.01.pdf

    work page 2016

  40. [40]

    Dhont, Feb

    G. Dhont, Feb. 2019. [Online]. Available: http://www.dhondt.de/ ccx 2.15.test.tar.bz2

    work page 2019

  41. [41]

    Optimizing large applications

    M. Li ˇska, “Optimizing large applications,” arXiv preprint arXiv:1403.6997, 2014

    work page internal anchor Pith review Pith/arXiv arXiv 2014

  42. [42]

    (2014, June) [PATCH 3/5] IPA ICF pass

    mliska. (2014, June) [PATCH 3/5] IPA ICF pass. [On- line]. Available: https://gcc.gnu.org/ml/gcc-patches/2014-06/ msg01246.html

    work page 2014

  43. [43]

    Safe ICF: Pointer safe and unwinding aware identical code folding in gold,

    S. Tallam, C. Coutant, I. L. Taylor, X. D. Li, and C. Demetriou, “Safe ICF: Pointer safe and unwinding aware identical code folding in gold,” 2010

    work page 2010

  44. [44]

    R. Ueyama. (2016, Feb.) Elf: Implement icf. [Online]. Available: https://reviews.llvm.org/rL261912 34

    work page 2016

  45. [45]

    Protecting software through obfuscation: Can it keep pace with progress in code analysis?

    S. Schrittwieser, S. Katzenbeisser, J. Kinder, G. Merzdovnik, and E. Weippl, “Protecting software through obfuscation: Can it keep pace with progress in code analysis?” ACM Computing Surveys (CSUR), vol. 49, no. 1, p. 4, 2016

    work page 2016

  46. [46]

    A taxonomy of obfus- cating transformations,

    C. Collberg, C. Thomborson, and D. Low, “A taxonomy of obfus- cating transformations,” Department of Computer Science, The University of Auckland, New Zealand, Tech. Rep., 1997

    work page 1997

  47. [47]

    Software watermarking via opaque predicates: Implementation, analysis, and attacks,

    G. Myles and C. Collberg, “Software watermarking via opaque predicates: Implementation, analysis, and attacks,” Electronic Com- merce Research, vol. 6, no. 2, pp. 155–171, 2006

    work page 2006

  48. [48]

    Manufacturing opaque pred- icates in distributed systems for code obfuscation,

    A. Majumdar and C. Thomborson, “Manufacturing opaque pred- icates in distributed systems for code obfuscation,” in Proc. of the 29th Australasian Computer Science Conf.-Volume 48 , 2006, pp. 187– 196

    work page 2006

  49. [49]

    Manufacturing resilient bi-opaque predicates against symbolic execution,

    H. Xu, Y. Zhou, Y. Kang, F. Tu, and M. Lyu, “Manufacturing resilient bi-opaque predicates against symbolic execution,” in 2018 48th Annual IEEE/IFIP Int’l Conf. on Dependable Systems and Networks (DSN), June 2018, pp. 666–677

    work page 2018

  50. [50]

    Indistinguishable predicates: A new tool for obfuscation

    L. Zobernig, S. D. Galbraith, and G. Russello, “Indistinguishable predicates: A new tool for obfuscation.” IACR Cryptology ePrint Archive, vol. 2017, p. 787, 2017

    work page 2017

  51. [51]

    When Are Opaque Predicates Useful?

    ——, “When Are Opaque Predicates Useful?” 2019, to appear

    work page 2019

  52. [52]

    Obfuscation through simplicity,

    M. R. Asghar, S. D. Galbraith, and G. Russello, “Obfuscation through simplicity,” 2016

    work page 2016

  53. [53]

    The tigress diversifying c virtualizer,

    C. Collberg, S. Martin, J. Myers, and B. Zimmerman, “The tigress diversifying c virtualizer,” 2015

    work page 2015

  54. [54]

    Obfuscator- LLVM – software protection for the masses,

    P . Junod, J. Rinaldini, J. Wehrli, and J. Michielin, “Obfuscator- LLVM – software protection for the masses,” in Proc. of the IEEE/ACM 1st Int’l Workshop on Software Protection, SPRO’15, Firenze, Italy, May 19th, 2015 , B. Wyseur, Ed. IEEE, 2015, pp. 3–9. Jens Van den Broeck is a PhD student at Ghent University in the Computer Systems Lab. He ob- tained ...

    work page 2015