-
Notifications
You must be signed in to change notification settings - Fork 0
/
Copy pathPublications.html
434 lines (412 loc) · 37.5 KB
/
Publications.html
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
<!DOCTYPE HTML>
<html>
<head>
<title>Publications</title>
<meta http-equiv="content-type" content="text/html; charset=utf-8" />
<script src="/js/jquery.min.js"></script>
<script src="/js/skel.min.js"></script>
<script src="/js/skel-layers.min.js"></script>
<script src="/js/init.js"></script>
<script src="/js/highlight.pack.js"></script>
<link rel="stylesheet" href="/css/highlight/github.css" />
<noscript>
<link rel="stylesheet" href="/css/skel.css" />
<link rel="stylesheet" href="/css/style.css" />
<link rel="stylesheet" href="/css/style-xlarge.css" />
</noscript>
</head>
<body id="top">
<header id="header" class="skel-layers-fixed">
<h2><a href="/"><img src="/OPALLogo.png" width="25" height="25"> OPAL Project</a></h2>
<nav id="nav">
<ul>
<li><a href="/Publications.html">Publications</a></li>
<li><a href="/library/api/SNAPSHOT/org/opalj/index.html">ScalaDoc</a></li>
<li><a href="https://github.com/opalj/OPAL">Repository</a></li>
<li><a href="https://search.maven.org/#search%7Cga%7C1%7Cg%3A%22de.opal-project%22">Maven Central</a></li>
</ul>
</nav>
</header>
<section id="one" class="wrapper style1">
<div class="container">
<div class="row">
<div class="3u">
<nav>
<a href="/UsingOPAL.html">Using OPAL</a><br>
<br><b>Getting Started</b><br>
<a href="/tutorial/FixedPointAnalyses.html">Writing Fixed-Point Analyses</a><br>
<a href="/tutorial/CollaborativeAnalyses.html">Collaborative Analyses</a><br>
<a href="/tutorial/Lattices.html">Lattices</a><br>
<a href="/tutorial/Results.html">Results</a><br>
<a href="/tutorial/Schedulers.html">Schedulers</a><br>
<br><b>Further Tutorials</b><br>
<a href="/examples/ReadingClassFiles.html">Reading Class Files</a><br>
<a href="/examples/Projects.html">Loading Java Projects</a><br>
<a href="/examples/ClassHierarchy.html">Using the Class Hierarchy</a><br>
<a href="/examples/BytecodeEngineering.html">Engineering Java Bytecode</a><br>
<a href="/examples/TAC.html">3-Address Code/SSA Code</a><br>
<a href="/examples/WritingAnalyses.html">Writing Analyses</a><br>
<br><b>Tools</b><br>
<a href="/DeveloperTools.html">Developers Tools</a><br>
<a href="/Hermes.html">Hermes</a><br>
<a href="/Opium.html">OPIUM</a><br>
<br><b>Showcases</b><br>
<a href="/UselessBoxing.html">Detecting Useless Boxings</a><br>
<a href="/JDK8Dependencies.html">Package Dependencies in JDK8</a><br>
<a href="/JDK8Complexity.html">Complexity of the JDK8</a><br>
<br><b>Artifacts</b><br>
<a href="/Artifacts.html">Research Artifacts</a><br>
</nav>
<hr/>
<div class="hide-at-medium">
Please, report issues or problems in the documentation using <a href="https://github.com/opalj/OPAL/issues">OPAL's issue tracker</a>, by going to the <a href="https://gitter.im/OPAL-Project/Lobby?utm_source=share-link&utm_medium=link&utm_campaign=share-link">OPAL gitter chat room</a> or by writing an email to <a href="mailto:opal_at_st.informatik.tu-darmstadt.de">opal(at)st.informatik.tu-darmstadt.de</a>.
</div>
</div>
<div class="9u">
<h1 id="publications">Publications</h1>
<p>This page lists publications around OPAL, both <a href="#core-papers">core contributions</a> to the framework as well as <a href="#research-using-opal">further research</a> that uses OPAL.
There are also links to <a href="#related-presentations">related presentations</a> below.</p>
<h2 id="core-papers">Core Papers</h2>
<blockquote>
<p><a href="https://link.springer.com/chapter/10.1007/978-3-031-57267-8_14"><strong>A Modular Soundness Theory for the Blackboard Analysis Architecture</strong></a><br />
ESOP 2024<br />
<em>Sven Keidel, Dominik Helm, Tobias Roth, Mira Mezini</em></p>
<details><summary>Abstract</summary>
Sound static analyses are an important ingredient for compiler optimizations and program verification tools.
However, mathematically proving that a static analysis is sound is a difficult task due to two problems.
First, soundness proofs relate two complicated program semantics (the static and the dynamic semantics) which are hard to reason about.
Second, the more the static and dynamic semantics differ, the more work a soundness proof needs to do to bridge the impedance mismatch.
These problems increase the effort and complexity of soundness proofs.
Existing soundness theories address these problems by deriving both the dynamic and static semantics from the same artifact, often called generic interpreter.
A generic interpreter provides a common structure along which a soundness proof can be composed, which avoids having to reason about the analysis as a whole.
However, a generic interpreter restricts which analyses can be derived, as all derived analyses must roughly follow the program execution order.
<p>To lift this restriction, we develop a soundness theory for the blackboard analysis architecture, which is capable of describing backward, demand-driven, and summary-based analyses.
The architecture describes static analyses with small independent modules, which communicate via a central store.
Soundness of a compound analysis follows from soundness of all of its modules.
Furthermore, modules can be proven sound independently, even though modules depend on each other.
We evaluate our theory by proving soundness of four analyses: a pointer and call-graph analysis, a reflection analysis, an immutability analysis, and a demand-driven reaching definitions analysis.</details></p>
</blockquote>
<blockquote>
<p><a href="https://2020.esec-fse.org/details/fse-2020-papers/191"><strong>Modular Collaborative Program Analysis in OPAL</strong></a><br />
ESEC/FSE 2020<br />
<em>Dominik Helm, Florian Kübler, Michael Reif, Michael Eichberg, Mira Mezini</em></p>
<p><strong>If you use OPAL, please cite this publication!</strong></p>
<details><summary>Abstract</summary>
Current approaches combining multiple static analyses deriving different, independent properties focus either on modularity or performance.
Whereas declarative approaches facilitate modularity and automated, analysis-independent optimizations, imperative approaches foster manual, analysis-specific optimizations.
<p>In this paper, we present a novel approach to static analyses that leverages the modularity of blackboard systems and combines declarative and imperative techniques.
Our approach allows exchangeability, and pluggable extension of analyses in order to improve sound(i)ness, precision, and scalability and explicitly enables the combination of otherwise incompatible analyses.
With our approach integrated in the OPAL framework, we were able to implement various dissimilar analyses, including a points-to analysis that outperforms an equivalent analysis from Doop, the state-of-the-art points-to analysis framework.</details></p>
</blockquote>
<blockquote>
<p><a href="https://conf.researchr.org/details/issta-2020/issta-2020-papers/18/A-Programming-Model-for-Semi-implicit-Parallelization-of-Static-Analyses"><strong>A Programming Model for Semi-implicit Parallelization of Static Analyses</strong></a><br />
ISSTA 2020<br />
<em>Dominik Helm, Florian Kübler, Jan Thomas Kölzer, Philipp Haller, Michael Eichberg, Guido Salvaneschi, Mira Mezini</em></p>
<details><summary>Abstract</summary>
Parallelization of static analyses is necessary to scale to real-world programs, but it is a complex and difficult task and, therefore, often only done manually for selected high-profile analyses.
In this paper, we propose a programming model for semi-implicit parallelization of static analyses which is inspired by reactive programming.
Reusing the domain-expert knowledge on how to parallelize analyses encoded in the programming framework, developers do not need to think about parallelization and concurrency issues on their own.
The programming model supports stateful computations, only requires monotonic computations over lattices, and is independent of specific analyses.
Our evaluation shows the applicability of the programming model to different analyses and the importance of user-selected scheduling strategies.
We implemented an IFDS solver that was able to outperform a state-of-the-art, specialized parallel IFDS solver both in absolute performance and scalability.</details>
</blockquote>
<blockquote>
<p><a href="https://pldi20.sigplan.org/details/SOAP-2020-papers/1"><strong>TACAI: An Intermediate Representation based on Abstract Interpretation</strong></a><br />
SOAP 2020<br />
<em>Michael Reif, Florian Kübler, Dominik Helm, Ben Hermann, Michael Eichberg, Mira Mezini</em></p>
<details><summary>Abstract</summary>
To facilitate the easier development of static analyses, most Java static analysis frameworks provide an intermediate representation of Java bytecode.
While such representations are often based on three-address code, the transformation itself is a great, yet too little used opportunity to apply optimizations to the transformed code, such as constant propagation.
<p>In this paper, we propose TACAl, a refinable intermediate representation that is based on abstract interpretation results of a method’s bytecode.
Exchanging the underlying abstract interpretation domains enables the creation of various intermediate representations of different precision levels.
Our evaluation shows that TACAI can be efficiently computed and provides slightly more precise receiver-type information than Soot’s Shimple representation.
Furthermore, we show how exchanging the underlying abstract domains directly impacts the generated representation.</details></p>
</blockquote>
<blockquote>
<p><a href="https://conf.researchr.org/details/ecoop-issta-2018/SOAP-2018-papers/6/Lattice-Based-Modularization-of-Static-Analyses"><strong>Lattice Based Modularization of Static Analyses</strong></a><br />
SOAP 2018<br />
<em>Michael Eichberg, Florian Kübler, Dominik Helm, Michael Reif, Guido Salvaneschi, Mira Mezini</em></p>
<details><summary>Abstract</summary>
Today, static analyses for, e.g., class immutability or method purity are developed as standalone analyses.
Complementary information that could improve the analyses is either ignored by making a sound over-approximation or it is also computed by the analyses but at a rudimentary level.
For example, an immutability analysis requires field mutability information, alias/escape information, and information about the concurrent behavior of methods to correctly classify classes such as java.lang.String or java.util.BigDecimal.
As a result, without properly supporting the integration of independently developed, mutually benefiting analysis, many analyses will not correctly classify relevant entities.
<p>In this paper, we propose to use explicitly reified lattices that encode the information about a source code element’s properties (e.g., a method’s purity or a class’ immutability) as the sole interface between mutually dependent analyses enabling composition of multiple analyses.
Our case study shows that using such an approach enables highly scalable, lightweight implementations of modularized static analyses.</details></p>
</blockquote>
<blockquote>
<p><a href="/articles/[email protected]"><strong>Assessment and Creation of Effective Test Corpora</strong></a><br />
SOAP 2018<br />
<em>Michael Reif, Michael Eichberg, Ben Hermann, Mira Mezini</em></p>
<details><summary>Abstract</summary>
An integral part of developing a new analysis is to validate the correctness of its implementation and to demonstrate its usefulness when applied to real-world code.
As a foundation for addressing both challenges developers typically use custom or well-established collections of Java projects.
The hope is that the collected projects are representative for the analysis’ target domain and therefore ensure a sound evaluation.
But, without proper means to understand how and to which degree the features relevant to an analysis are found in the projects, the evaluation necessarily remains inconclusive.
Additionally,it is likely that the collection contains many projects which are – w.r.t. the developed analysis – basically identical and therefore do not help the overall evaluation/testing of the analysis, but still cost evaluation time.
<p>To overcome these limitations we propose Hermes, a framework that enables the systematic assessment of given corpora and the creation of new corpora of Java projects.
To show the usefulness ofHermes, we used it to comprehend the nature of the projects belonging to the Qualitas Corpus(QC) and then used it to compute a minimal subset of all QC projects useful for generic data- and control-flow analyses.
This subset enables effective and efficient integration test suites.</details></p>
</blockquote>
<blockquote>
<p><a href="https://doi.acm.org/10.1145/2950290.2950312"><strong>Call Graph Construction for Java Libraries</strong></a><br />
FSE 2016<br />
<em>Michael Reif, Michael Eichberg, Ben Hermann, Johannes Lerch, Mira Mezini</em></p>
<details><summary>Abstract</summary>
Today, every application uses software libraries.
Yet, while a lot of research exists w.r.t. analyzing applications, research that targets the analysis of libraries independent of any application is scarce.
This is unfortunate, because, for developers of libraries, such as the Java Development Kit (JDK), it is crucial to ensure that the library behaves as intended regardless of how it is used.
To fill this gap, we discuss the construction of call graphs for libraries that abstract over all potential library usages.
Call graphs are particularly relevant as they are a precursor of many advanced analyses, such as inter-procedural data-flow analyses.
<p>We show that the current practice of using call graph algorithms designed for applications to analyze libraries leads to call graphs that, at the same time, lack relevant call edges and contain unnecessary edges.
This motivates the need for call graph construction algorithms dedicated to libraries.
Unlike algorithms for applications, call graph construction algorithms for libraries must take into consideration the goals of subsequent analyses.
Specifically, we show that it is essential to distinguish between the scenario of an analysis for potential exploitable vulnerabilities from the scenario of an analysis for general software quality attributes, e.g., dead methods or unused fields.
This distinction affects the decision about what constitutes the library-private implementation, which therefore, needs special treatment.
Thus, building one call graph that satisfies all needs is not sensical.
Overall, we observed that the proposed call graph algorithms reduce the number of call edges up to 30% when compared to existing approaches.</details></p>
</blockquote>
<blockquote>
<p><a href="https://doi.acm.org/10.1145/2614628.2614630"><strong>A software product line for static analyses: the OPAL framework</strong></a><br />
SOAP 2014<br />
<em>Michael Eichberg, Ben Hermann</em></p>
<details><summary>Abstract</summary>
Implementations of static analyses are usually tailored toward a single goal to be efficient, hampering reusability and adaptability of the components of an analysis.
To solve these issues, we propose to implement static analyses as highly-configurable software product lines (SPLs).
Furthermore, we also discuss an implementation of an SPL for static analyses—called OPAL—that uses advanced language features offered by the Scala programming language to get an easily adaptable and (type-)safe software product line.
<p>OPAL is a general purpose library for static analysis of Java Bytecode that is already successfully used.
We present OPAL and show how a design based on software produce line engineering benefits the implementation of static analyses with the framework.</details></p>
</blockquote>
<h2 id="research-using-opal">Research Using OPAL</h2>
<blockquote>
<p><a href="/articles/[email protected]"><strong>Total Recall? How Good are Static Call Graphs Really?</strong></a><br />
ISSTA 2024<br />
<em>Dominik Helm, Sven Keidel, Anemone Kampkötter, Johannes Düsing, Tobias Roth, Ben Hermann, Mira Mezini</em></p>
<details><summary>Abstract</summary>
Static call graphs are a fundamental building block of program analysis.
However, differences in call-graph construction and the use of specific language features can yield unsoundness and imprecision.
Call-graph analyses are evaluated using measures of precision and recall, but this is hard when a ground truth for real-world programs is generally unobtainable.
<p>In this work, we propose to use carefully constructed dynamic baselines based on fixed entry points and input corpora.
The creation of this dynamic baseline is posed as an approximation of the ground truth—an optimization problem.
We use manual extension and coverage-guided fuzzing for creating suitable input corpora.</p>
<p>With these dynamic baselines, we study call-graph quality of multiple algorithms and implementations using four real-world Java programs.
We find that our methodology provides valuable insights into call-graph quality and how to measure it.
With this work, we provide a novel methodology to advance the field of static program analysis as we assess the computation of one of its core data structures—the call graph.</details></p>
</blockquote>
<blockquote>
<p><a href="/articles/[email protected]"><strong>Unimocg: Modular Call-Graph Algorithms for Consistent Handling of Language Features</strong></a><br />
ISSTA 2024<br />
<em>Dominik Helm, Tobias Roth, Sven Keidel, Michael Reif, Mira Mezini</em></p>
<details><summary>Abstract</summary>
Traditional call-graph construction algorithms conflate the computation of possible runtime types with the actual resolution of (virtual) calls.
This tangled design impedes supporting complex language features and APIs and making systematic trade-offs between precision, soundness, and scalability.
It also impedes implementation of precise downstream analyses that rely on type information.
<p>To address the problem, we propose Unimocg, a modular architecture for call-graph construction that decouples the computation of type information from resolving calls.
Due to its modular design, Unimocg can combine a wide range of different call-graph algorithms with algorithm-agnostic modules to support individual language features.
Moreover, these modules operate at the same precision as the chosen call-graph algorithm with no further effort.
Additionally, Unimocg allows other analyses to easily reuse type information from the call-graph construction at full precision.</p>
<p>We demonstrate how Unimocg enables a framework of call-graph algorithms with different precision, soundness, and scalability trade-offs from reusable modules.
Unimocg currently supports ten call-graph algorithms from vastly different families, such as CHA, RTA, XTA, and <em>k</em>-<em>l</em>-CFA.
These algorithms show consistent soundness without sacrificing precision or performance.
We also show how an immutability analysis is improved using Unimocg.</details></p>
</blockquote>
<blockquote>
<p><a href="/articles/[email protected]"><strong>AXA: Cross-Language Analysis through Integration of Single-Language Analyses</strong></a><br />
ASE 2024<br />
<em>Tobias Roth, Julius Näumann, Dominik Helm, Sven Keidel, Mira Mezini</em></p>
<details><summary>Abstract</summary>
Modern software is often implemented in multiple interacting programming languages.
When performing static analysis of such software, it is desirable to reuse existing single-language analyses to allow access to the results of decades of implementation effort.
<p>However, there are major challenges for this approach.
In this paper, we analyse them and present AXA, an architecture that addresses them and enables cross-language analysis by integrating single-language analyses.</p>
<p>To evaluate AXA, we implemented a cross-language points-to analysis for Java applications that interact with native code via Java Native Interface (JNI) and with JavaScript code via Java’s ScriptEngine.
The evaluation shows that AXA enables significant reuse of existing static analyses.
It also shows that AXA supports complex interactions and significantly increased recall of reused analyses without compromising precision.</details></p>
</blockquote>
<blockquote>
<p><a href="/articles/[email protected]"><strong>CiFi: Versatile Analysis of Class and Field Immutability</strong></a><br />
ASE 2021<br />
<em>Tobias Roth, Dominik Helm, Michael Reif, Mira Mezini</em></p>
<details><summary>Abstract</summary>
Reasoning about immutability is important for pre-venting bugs, e.g., in multi-threaded software.
So far, static analysis to infer immutability properties has mostly focused on individual objects and references.
Reasoning about fields and entire classes, while significantly simpler, has gained less attention.
Even a consistently used terminology is missing, which makes it difficult to implement analyses that rely on immutability information.
We propose a model for class and field immutability that unifies terminology for immutability flavors considered by previous work and covers new levels of immutability to handle lazy initialization and immutability dependent on generic type parameters.
Using the OPAL static analysis framework, we implement CiFi, a set of modular, collaborating analyses for different flavors of immutability, inferring the properties defined in our model.
Additionally, we propose a benchmark of representative test cases for class and field immutability.
We use the benchmark to showcase CiFi’s precision and recall in comparison to state of the art and use CiFi to study the prevalence of immutability in real-world libraries, showcasing the practical quality and relevance of our model.</details>
</blockquote>
<blockquote>
<p><a href="https://dl.acm.org/doi/10.1145/3320269.3384745"><strong>Hidden in Plain Sight: Obfuscated Strings Threatening Your Privacy</strong></a><br />
ASIA-CCS 2020<br />
<em>Leonid Glanz, Patrick Müller, Lars Baumgärtner, Michael Reif, Sven Amann, Pauline Anthonysamy, Mira Mezini</em></p>
<details><summary>Abstract</summary>
String obfuscation is an established technique used by proprietary, closed-source applications to protect intellectual property.
Furthermore, it is also frequently used to hide spyware or malware in applications.
In both cases, the techniques range from bit-manipulation over XOR operations to AES encryption.
However, string obfuscation techniques/tools suffer from one shared weakness:
They generally have to embed the necessary logic to deobfuscate strings into the app code.
In this paper, we show that most of the string obfuscation techniques found in malicious and benign applications for Android can easily be broken in an automated fashion.
We developed StringHound, an open-source tool that uses novel techniques that identify obfuscated strings and reconstruct the originals using slicing.
We evaluated StringHound on both benign and malicious Android apps
In summary, we deobfuscate almost 30 times more obfuscated strings than other string deobfuscation tools.
Additionally, we analyzed 100,000 Google Play Store apps and found multiple obfuscated strings that hide vulnerable cryptographic usages,
insecure internet accesses, API keys, hard-coded passwords, and exploitation of privileges without the awareness of the developer.
Furthermore, our analysis reveals that not only malware uses string obfuscation but also benign apps make extensive use of string obfuscation.</details>
</blockquote>
<blockquote>
<p><a href="https://conf.researchr.org/details/issta-2019/issta-2019-Technical-Papers/24/Judge-Identifying-Understanding-and-Evaluating-Sources-of-Unsoundness-in-Call-Grap"><strong>Judge: Identifying, Understanding, and Evaluating Sources of Unsoundness in Call Graphs</strong></a><br />
ISSTA 2019<br />
<em>Michael Reif, Florian Kübler, Michael Eichberg, Dominik Helm, Mira Mezini</em></p>
<details><summary>Abstract</summary>
Call graphs are widely used; in particular for advanced control- and data-flow analyses.
Even though many call graph algorithms with different precision and scalability properties have been proposed, a comprehensive understanding of sources of unsoundness, their relevance, and the capabilities of existing call graph algorithms in this respect is missing.
<p>To address this problem, we propose Judge, a toolchain that helps with understanding sources of unsoundness and improving the soundness of call graphs.
In several experiments, we use Judge and an extensive test suite related to sources of unsoundness to (a) compute capability profiles for call graph implementations of Soot, WALA, DOOP, and OPAL, (b) to determine the prevalence language features and APIs that affect soundness in modern Java Bytecode, (c) to compare the call graphs of Soot, WALA, DOOP, and OPAL, highlighting important differences in their implementations, and (d) to evaluate the necessary effort to achieve project-specific reasonable sound call graphs.</p>
<p>We show that soundness-relevant features/APIs are frequently used and that support for them differs vastly, up to the point where comparing call graphs computed by the same base algorithms (e.g., RTA) but different frameworks is bogus.
We also show that Judge can support users in establishing the soundness of call graphs with reasonable effort.</details></p>
</blockquote>
<blockquote>
<p><a href="https://2018.splashcon.org/event/splash-2018-oopsla-algebraic-effects-for-the-masses"><strong>Algebraic Effects for the Masses</strong></a><br />
OOPSLA 2018<br />
<em>Jonathan Immanuel Brachthäuser, Philipp Schuster, Klaus Ostermann</em></p>
<details><summary>Abstract</summary>
Algebraic effects are a program structuring paradigm with rising popularity in the functional programming language community.
Algebraic effects are less wide-spread in the context of imperative, object oriented languages.
We present a library to program with algebraic effects in Java.
Our library consists of three core components:
A type selective CPS transformation via JVM bytecode transformation, an implementation of delimited continuations on top of the bytecode transformation and finally a library for algebraic effects in terms of delimited continuations.</details>
</blockquote>
<blockquote>
<p><a href="https://ieeexplore.ieee.org/abstract/document/9000061"><strong>A Unified Lattice Model and Framework for Purity Analyses</strong></a><br />
ASE 2018<br />
<em>Dominik Helm, Florian Kübler, Michael Eichberg, Michael Reif, Mira Mezini</em></p>
<details><summary>Abstract</summary>
Analyzing methods in object-oriented programs whether they are side-effect free and also deterministic, i.e., mathematically pure, has been the target of extensive research.
Identifying such methods helps to find code smells and security related issues, and also helps analyses detecting concurrency bugs.
Pure methods are also used by formal verification approaches as the foundations for specifications and proving the pureness is necessary to ensure correct specifications.
However, so far no common terminology exists which describes the purity of methods.
Furthermore, some terms (e.g., pure or side-effect free) are also used inconsistently.
Further, all current approaches only report selected purity information making them only suitable for a smaller subset of the potential use cases.
In this paper, we present a fine-grained unified lattice model which puts the purity levels found in the literature into relation and which adds a new level that generalizes existing definitions.
We have also implemented a scalable, modularized purity analysis which produces significantly more precise results for real-world programs than the best-performing related work.
The analysis shows that all defined levels are found in real-world projects.</details>
</blockquote>
<blockquote>
<p><a href="http://michael-reif.name/publications/JCG.pdf"><strong>Systematic Evaluation of the Unsoundness of Call Graph Construction Algorithms for Java</strong></a><br />
SOAP 2018<br />
<em>Michael Reif, Florian Kübler, Michael Eichberg, and Mira Mezini</em></p>
<details><summary>Abstract</summary>
Call graphs are at the core of many static analyses ranging from the detection of unused methods to advanced control-and data-flow analyses.
Therefore, a comprehensive under-standing of the precision and recall of the respective graphs is crucial to enable an assessment which call-graph construction algorithms are suited in which analysis scenario.
For example, malware is often obfuscated and tries to hide its intent by using Reflection.
Call graphs that do not represent reflective method calls are, therefore, of limited use when analyzing such apps.
<p>In general, the precision is well understood, but the recall is not, i.e., in which cases a call graph will not contain any call edges.
In this paper, we discuss the design of a comprehensive test suite that enables us to compute a fingerprint of the unsoundnes sof the respective call-graph construction algorithms.
This suite also enables us to make a comparative evaluation of static analysis frameworks.
Comparing Soot and WALA shows that WALA currently has better support for new Java 8 features and also for Java Reflection.
However, in some cases both fail to include expected edges.</details></p>
</blockquote>
<blockquote>
<p><a href="http://www.st.informatik.tu-darmstadt.de/artifacts/codematch/"><strong>CodeMatch: Obfuscation won't Conceal your Repackaged App</strong></a><br />
ESEC/FSE 2017<br />
<em>Leonid Glanz, Sven Amann, Michael Eichberg, Michael Reif, Ben Hermann, Johannes Lerch, Mira Mezini</em></p>
<details><summary>Abstract</summary>
An established way to steal the income of app developers, or to trick users into installing malware, is the creation of repackaged apps.
These are clones of – typically – successful apps.
To conceal their nature, they are often obfuscated by their creators.
But, given that it is a common best practice to obfuscate apps, a trivial identification of repackaged apps is not possible.
The problem is further intensified by the prevalent usage of libraries.
In many apps, the size of the overall code base is basically determined by the used libraries.
Therefore, two apps, where the obfuscated code bases are very similar, do not have to be repackages of each other.
<p>To reliably detect repackaged apps, we propose a two step approach which first focuses on the identification and removal of the library code in obfuscated apps.
This approach – LibDetect – relies on code representations which abstract over several parts of the underlying bytecode to be resilient against certain obfuscation techniques.
Using this approach, we are able to identify on average 70% more used libraries per app than previous approaches.
After the removal of an app’s library code, we then fuzzy hash the most abstract representation of the remaining app code to ensure that we can identify repackaged apps even if very advanced obfuscation techniques are used.
This makes it possible to identify repackaged apps.
Using our approach, we found that ≈15% of all apps in Android app stores are repackages.</details></p>
</blockquote>
<blockquote>
<p><a href="https://doi.acm.org/10.1145/2786805.2786865"><strong>Hidden Truths in Dead Software Paths</strong></a><br />
ESEC/FSE 2015<br />
<em>Michael Eichberg, Ben Hermann, Leonid Glanz, Mira Mezini</em></p>
<details><summary>Abstract</summary>
Approaches and techniques for statically finding a multitude of issues in source code have been developed in the past.
A core property of these approaches is that they are usually targeted towards finding only a very specific kind of issue and that the effort to develop such an analysis is significant.
This strictly limits the number of kinds of issues that can be detected.
In this paper, we discuss a generic approach based on the detection of infeasible paths in code that can discover a wide range of code smells ranging from useless code that hinders comprehension to real bugs.
Code issues are identified by calculating the difference between the control-flow graph that contains all technically possible edges and the corresponding graph recorded while performing a more precise analysis using abstract interpretation.
We have evaluated the approach using the Java Development Kit as well as the Qualitas Corpus (a curated collection of over 100 Java Applications) and were able to find thousands of issues across a wide range of categories.</details>
</blockquote>
<blockquote>
<p><a href="https://doi.acm.org/10.1145/2786805.2786829"><strong>Getting to know you... Towards a Capability Model for Java</strong></a><br />
ESEC/FSE 2015<br />
<em>Ben Hermann, Michael Reif, Michael Eichberg, Mira Mezini</em></p>
<details><summary>Abstract</summary>
Developing software from reusable libraries lets developers face a security dilemma:
Either be efficient and reuse libraries as they are or inspect them, know about their resource usage, but possibly miss deadlines as reviews are a time consuming process.
In this paper, we propose a novel capability inference mechanism for libraries written in Java.
It uses a coarse-grained capability model for system resources that can be presented to developers.
We found that the capability inference agrees by 86.81% on expectations towards capabilities that can be derived from project documentation.
Moreover, our approach can find capabilities that cannot be discovered using project documentation.
It is thus a helpful tool for developers mitigating the aforementioned dilemma.</details>
</blockquote>
<h2 id="related-presentations">Related Presentations</h2>
<blockquote>
<p><a href="/articles/Your_JDK-Entwicklertag2015.pdf"><strong>Your JDK 8</strong></a><br />
<em>Michael Eichberg</em></p>
</blockquote>
<blockquote>
<p><a href="/articles/[email protected]"><strong>Lattice Based Modularization of Static Analyses</strong></a><br />
<em>Michael Eichberg</em></p>
</blockquote>
</div>
</div>
</div>
</section>
<footer id="footer">
<div class="container">
<div class="row double">
<div class="6u">
<h3>Stay connected and get help!</h3>
<ul class="icons">
<li><a href="https://twitter.com/intent/follow?original_referer=http%3A%2F%2Fwww.opal-project.de%2F&ref_src=twsrc%5Etfw®ion=follow_link&screen_name=TheOpalProject&tw_p=followbutton" class="icon fa-twitter"><span class="label">Twitter</span></a></li>
<li><a href="https://gitter.im/OPAL-Project/Lobby?utm_source=share-link&utm_medium=link&utm_campaign=share-link" class="icon fa-users"><span class="label">Gitter</span></a></li>
<li><a href="https://trello.com/theopalproject" class="icon fa-trello"><span class="label">Trello</span></a></li>
<li><a href="https://stackoverflow.com/questions/tagged/opal-framework" class="icon fa-stack-overflow"><span class="label">Stackoverflow</span></a></li>
<li><a href="https://hub.docker.com/r/opalj/sbt_scala_opal" class="icon fa-cloud"><span class="label">Docker</span></a></li>
</ul>
<h3>Related</h3>
<ul class="alt">
<li><a href="https://www.openhub.net/p/OPAL-Project">OPAL on OpenHub</a></li>
</ul>
</div>
<div class="6u">
<h3>Supported By</h3>
<ul class="alt">
<li><a href="https://www.yourkit.com/"><img src="/images/yklogo.png" width="139", height="33"></a><br>
YourKit supports open source projects with its full-featured Java Profiler.
YourKit, LLC is the creator of <a href="https://www.yourkit.com/java/profiler/">YourKit Java Profiler</a>
an innovative and intelligent tool for profiling Java applications.
</li>
</ul>
</div>
</div>
<ul class="copyright">
<li>© The OPAL Project. All rights reserved.</li>
<li><a href="https://raw.githubusercontent.com/stg-tud/opal/master/LICENSE">License (BSD 2 Clause)</a></li>
<li><img src="/Athene.png" height="27" style="vertical-align:middle"></li>
<li>Design: <a href="https://templated.co">TEMPLATED</a></li>
</ul>
</div>
</footer>
</body>
<script>
hljs.configure({
tabReplace: ' ', // 4 spaces
languages: ["scala","java"]
})
hljs.highlightAll()
</script>
</html>