# Unifying Pointer Analyses for Polyglot Inter-operations through Summary
Specialization

Jyoti Prakash<EMAIL_ADDRESS>University of PassauPassauGermany ,
Abhishek Tiwari<EMAIL_ADDRESS>University of PassauPassauGermany
and  Christian Hammer<EMAIL_ADDRESS>University of
PassauPassauGermany

###### Abstract.

Modular analysis of polyglot applications is challenging because heap object
flows across language boundaries must be resolved. The state-of-the-art
analyses for polyglot applications have two fundamental limitations. First,
they assume explicit boundaries between the host and the guest language to
determine inter-language dataflows. Second, they rely on specific analyses of
the host and guest languages. The former assumption is impractical concerning
recent advancements in polyglot programming techniques, while the latter
disregards advances in pointer analysis of the underlying languages. In this
work, we propose to extend existing pointer analyses with a novel summary
specialization technique so that points-to set across language boundaries can
be unified. Our novel technique leverages various combinations of host and
guest analyses with minor modifications. We demonstrate the efficacy and
generalizability of our approach by evaluating it with two polyglot language
models: Java-C communication via Android’s NDK and Java-Python communication
in GraalVM.

Multilingual programming, Modular static program analysis

##  1\. Introduction

Developers are rapidly adopting the polyglot programming model. Recent
advancements in runtime systems such as GraalVM, paired with innovations in
programming languages and models, have accelerated the adoption of the
polyglot paradigm model (Kochhar et al., 2016; Grichi et al., 2020; Exchange,
2022; Li et al., 2021; rcp, 2022; rpy, 2022; Lee and Ryu, 2019; Lee et al.,
2016; Tiwari et al., 2019b; Samhi et al., 2021; Bae et al., 2019).
Undoubtedly, the polyglot programming model is frequently advantageous to
developers. They can reuse or repackage existing modules written in any
language into new applications. Unfortunately, the potential for misuse
increases simultaneously: With a limited understanding of language
interoperability, developers may introduce major flaws or even vulnerabilities
(Kochhar et al., 2016; Grichi et al., 2020; Li et al., 2021). Consequently, it
has become critical to develop tools and practices that facilitate polyglot
development.

Static program analysis supports development of such tools. A modular
technique, in which each language module is studied independently and the
findings combined for a whole-program analysis, appears to be promising for
scalability and precision (Cousot and Cousot, 2002). Recent years have seen a
surge in research towards modular program analysis, with a multitude of new
techniques being developed for popular languages (Nielsen et al., 2021;
Schubert et al., 2021). However, a modular analysis for polyglot applications
is still in its infancy. A modular approach to inter-language analysis can
benefit from a language’s models and optimizations (Lee et al., 2020).
However, numerous obstacles avert this goal.

Integrating analysis results of several language models in a modular style is
one of the main obstacles. Existing approaches, such as Lee  _et al._ (Lee et
al., 2020) translate data-flow summaries of the guest language’s operations to
the host language. After injecting these summaries into the host program, this
program is analyzed. However, there are two primary disadvantages to this
approach. First, due to the complexity of modern languages’ syntax and
semantics, translating all conceivable consequences of the guest language to
the host language is a complex and potentially error-prone undertaking. It
entails modeling every language aspect of the guest language and transforming
them into the host language’s semantics. Lee  _et al._ (Lee et al., 2020)
consequently only convert a _subset_ of the guest language’s semantics to the
host. Second, the translated program is analyzed using the host language’s
model and thus cannot take advantage of the guest language’s unique
characteristics, preventing language-specific optimizations for a most
appropriate result of the guest module.

Another drawback of present techniques is that they rely on explicit host-
guest language boundaries (Monat et al., 2021). These boundaries are
identified via explicit syntactic markers, which are typically predefined
function calls, signatures, or data structures involved in interlanguage
communication. Static analyses can detect these predefined syntactic
structures and define models that replicate their behavior in the host
language. However, current polyglot programming environments such as _GraalVM_
or Android’s _WebView_ allow code from both languages to be mixed, blurring
these explicit boundaries. For instance, WebViews allows messages from the
guest to the host as well, which are not linked to explicit syntactic markers
but communicate via a shared object. Prior research demonstrated that these
functionalities are widespread in contemporary applications (Tiwari et al.,
2020). Furthermore, it is unavoidable that future multilingual programming
environments will offer similar patterns, making it impractical to rely
entirely on static language boundaries.

##### Our Approach

We propose a novel strategy to address these challenges. Our modular technique
is oblivious of the particular language models: It can instantiate various
combinations of host and guest analyses to take advantage of the language-
specific models, thereby inheriting the precision, scalability, and soundness
improvements of the underlying analyses. Notably, our technique extends
existing host and guest language analyses to include essential information
concerning call and data flows to their counterparts. Given a polyglot model,
our analysis finds the communication endpoints and features (shared
classes/functions) of a host that a guest can use. With this information, an
_interlanguage call graph_ is created by joining the missing call flow edges
in the host’s and guest’s individual call graphs. Next, our technique builds
an intra-procedural function summary of all the interoperating functions
discovered in the interlanguage call graph. The function summaries are
determined using intra-procedural points-to-analysis according to an _Andersen
style_ (Sridharan and Fink, 2009) constraint scheme. Next, these summaries are
resolved such that the points-to sets of variables shared across languages
contain the correct and complete references. To this end we propose innovative
_summary specialization_ and _unification_ techniques. Unification is an
alias-aware technique that unifies the variables’ must-aliases across host and
guest. The resolved summaries are then translated to be consistent with the
host and guest’s analysis models. With the resolved call edges and unified
points-to set, the analysis is performed as a whole by merging the host and
guest results independently.

$\begin{array}[]{lll}m\in\mathit{host\leavevmode\nobreak\
methods}&:=&m_{1}\mid m_{2}\mid m_{3}\mid\cdots\mid m_{n}\\\
i\in\mathit{InterfaceVars}&:=&i_{1}\mid\cdots\mid i_{n}\\\
v\in\mathit{variables}&:=&v_{1}\mid v_{2}\mid v_{3}\mid\cdots\mid
v_{n}\mid\mathit{InterfaceVars}\\\ g\in\mathit{fields}&:=&g_{1}\mid g_{2}\mid
g_{3}\mid\cdots\mid g_{n}\\\
s\in\mathit{statements}&:=&v=\mathbf{new}\leavevmode\nobreak\ T()\mid
i=\mathbf{new}\leavevmode\nobreak\ T()\mid\\\ &&v^{\prime}=v.m()\mid
v^{\prime}=v.g\mid v^{\prime}.g=v\mid\mathbf{if}\leavevmode\nobreak\
(e)\leavevmode\nobreak\ \\{s\\}[\mathbf{else}\leavevmode\nobreak\ \\{s\\}]\\\
&&v=\mathbf{eval}(program)\mid\mathbf{op}\leavevmode\nobreak\
s_{1}\leavevmode\nobreak\ s_{2}\mid
s_{1};s_{2}\mid\mathbf{while}\leavevmode\nobreak\ (e)\leavevmode\nobreak\
\\{s\\}\\\ \end{array}$

Host Language

0.5pt1mm

$\begin{array}[]{lll}f\in\mathit{guest\leavevmode\nobreak\
methods}&:=&f_{1}\mid f_{2}\mid f_{3}\mid\cdots\mid f_{n}\\\
w\in\mathit{variables}&:=&v_{1}\mid v_{2}\mid v_{3}\mid\cdots\mid
v_{n}\mid\mathit{InterfaceVars}\\\ h\in\mathit{fields}&:=&h_{1}\mid h_{2}\mid
h_{3}\mid\cdots\mid h_{n}\\\
t\in\mathit{statements}&::=&v=\mathbf{new}\leavevmode\nobreak\ T()\mid
w^{\prime}=w.f()\mid\\\ &&w^{\prime}=i.m()\mid
w^{\prime}=w.h\mid\mathbf{if}\leavevmode\nobreak\ (e)\leavevmode\nobreak\
\\{t\\}[\mathbf{else}\leavevmode\nobreak\ \\{t\\}]\\\
&&w^{\prime}.h=w\mid\mathbf{op}\leavevmode\nobreak\ t_{1}\leavevmode\nobreak\
t_{2}\mid t_{1};t_{2}\mid\mathbf{while}\leavevmode\nobreak\
(e)\leavevmode\nobreak\ \\{t\\}\\\ \end{array}$

Guest Language

Figure 1. Host and guest language model

We implemented our approach into a tool called  _Conflux_. To evaluate the
efficacy and generalizability of our approach, we applied _Conflux_ to two
polyglot language models; 1) Java-C communication via the Android NDK (and,
2022) and 2) Java-Python communication in GraalVM (gra, 2022). _Conflux_
outperforms the previous state-of-the-art and successfully analyzed 31 out of
39 apps using Java-C communication in Android NDK. Besides, _Conflux_
successfully analyzed two of three Java-Python apps using GraalVM APIs. To the
best of our knowledge, _Conflux_ is the first polyglot analysis tool that can
be applied to multiple multilingual language models.

To summarize, this paper makes the following contributions:

  1. (i)

_Modular analysis using summary specialization._ We present a novel modular
analysis framework to analyze multiple polyglot language models. Our framework
can be employed on combinations of host and guest analyses to take advantage
of the language-specific models.

  2. (ii)

_Polyglot analysis tool._ We implement our approach into a tool called
_Conflux_. _Conflux_ supports two widely used polyglot models, and it can be
easily extended to analyze additional multilingual language models. _Conflux_
is publicly available (Anonymous, 2022) for experiments and extensions.

  3. (iii)

_Extensive evaluation._ We evaluate _Conflux_ on multiple apps from two
polyglot language models and demonstrate its efficacy and generalizability.

##  2\. Modular Inter-language Analysis

##### A core polyglot model

There are various polyglot language models, e.g. Java-C, Java-Javascript,
Java-python, Javascript-wasm, Java-Javascript-wasm, and communication
settings. In this work, we propose the first modular analysis framework for
handling multiple polyglot language models. To this end, we define a language
model sufficiently abstracted from the general polyglot model’s semantics to
ease the presentation and explanation of our approach. Our language model,
depicted in Fig. 1, incorporates the semantics required for host-to-guest and
guest-to-host communication in a polyglot model following the foreign function
interface (FFI) model111Other potential communication facilities, such as
middleware-based remote method invocation, have been covered by previous
research (Section 6) and are thus out of scope of this approach.. This
language is based on an in-depth examination of existing polyglot programming
environments, specifically GraalVM and Android hybrid apps. The host and guest
languages have been defined as standard imperative/OO programs with the
addition of inter-language communication constructs. Standard details such as
class and field syntax are omitted to concentrate on the analysis.

Listing 1: Host language code

⬇

1foo() {

2 i = new BridgeClass(); // obj@iface

3 eval("set()"); // invoke the guest code

4 // do some computation

5 x = eval("getAndLeak()");

6 return x;

7}

8BridgeClass.setSecret(secret) {

9 this.secret = secret;

10}

11BridgeClass.getSecret() {

12 return this.secret;

13}

Listing 2: Guest language example

⬇

15set() {

16 v = new Secret(); //obj@sec

17 i.setSecret(v);

18}

19getAndLeak() {

20 g = i.getSecret();

21 leak(g);

22 return g;

23}

The functions, variables, field variables, and statements in both the host and
guest languages are equivalent. _Interface variables_ (_InterfaceVars_) and
_eval_ are the two key features that make it possible for the host and guest
to communicate with each other. The host language construct _eval_ executes a
guest language program or expression and returns the corresponding result to
the host. The host language defines _InterfaceVars_ for the guest to access
host functionalities. InterfaceVars are host objects that the guest can send
messages to. Technically, they are ordinary objects that serve as a bridge
between a host’s class and the guest. Polyglot environments that allow a
subset of the host language features to be accessed by the guest are a
specific instance of this premise. LABEL:lst:toyexample:host and
LABEL:lst:toyexample:guest employ our language constructs to exemplify a
simplified polyglot model. Line 2 declares an interface variable _i_ of the
host class _BridgeClass_ , granting the guest language access to its methods.
In Lines 3 and 5, the host uses the _eval_ method to invoke guest language
code. In turn at Line 17 and 20 in the guest, the _BridgeClass_ ’s _setSecret_
and _getSecret_ functions are accessed.

##### Analysis Overview

Figure 2. Analysis Overview

Fig. 2 depicts the components of our analysis based on the aforementioned
language constructs. The framework builds upon a scalable context-sensitive
pre-analysis for the host and guest languages. It then computes other building
blocks of the analysis, a call graph (constructed with a modular analysis,
Section 2.2) and intra-procedural function summaries (Section 2.3.1). Next we
elaborate on our bottom-up analysis strategy. First, we visualize our analysis
for bridge calls initiated within a single method (Section 2.1–Section 2.3.3).
Then, we extend our approach to model bridge function calls in multiple
methods (Section 2.3.5).

###  2.1. Pre-analysis

In our approach, the _pre-analysis_ module leverages points-to and callgraph
analyses computed independently for the host and guest languages (i.e., modulo
the foreign function interfaces). This module provides flexibility in
establishing the sensitivity levels of the underlining analysis for individual
languages. As a result, it may adopt the most precise and scalable analyses
specific to the particular languages. Next, we describe the pre-analysis model
and exemplify it for the example in LABEL:lst:toyexample:host and
LABEL:lst:toyexample:guest.

The pre-analysis is depicted in Fig. 3. It includes a set of variables $V$, a
set of heap objects $H$, and a collection of contexts $C$. $C$ can be modeled
in various notions; by using objects as contexts (object sensitive), by
invoking function call sites (call-site sensitive), and many others. Context
set $C$ improves the analysis by removing unrealizable paths (such as paths
from unmatched function calls). A context $\mathit{ctxt}$ is a string that is
constructed using elements from $C$. For the sake of presentation we may
choose to omit contexts in the sequel.

$V:\text{Set of variables}$ | $C:\text{Set of contexts}$
---|---
$H:\text{Set of heap objects}$ | $\mathit{Ctxt}^{j}\subseteq c_{1}^{j}\times c_{2}^{j}\times\ldots\times c_{n}^{j},\leavevmode\nobreak\ c_{i}^{j}\in C$
Figure 3. Pre-analysis model

A points-to analysis generates a mapping from variables to a set of heap
objects, referred here as variable points-to set (under a context
$\mathit{ctxt}$). A variable points-to mapping,
$\mathit{VarPointsTo}:V\mapsto\mathcal{P}(H)$, is a mapping from the set of
variables to heap objects. A points-to set for a variable $v\in V$ is a set of
heap objects $h\subseteq H$. In the presence of fields in a programming
language, one adds one more resolution by mapping object and field pairs to
sets of heap objects, referred to as field points-to set. If $f$ is a field
for a heap object $o_{i}$, its points-to set is the set of heap objects,
$O_{\mathit{if}}$, referred through the field $f$ of the heap object $o_{i}$.
A field points-to mapping,
$\mathit{FldPointsTo}:H\times\mathit{Field}\mapsto\mathcal{P}(H)$ maps each
pair of a heap object and a field to a set of heap objects.

$\langle i,ctx\rangle$ $\mapsto$ $\\{\texttt{obj@iface}\\}$
---
$\langle x,ctx\rangle$ $\mapsto$ $\emptyset$
[3pt/1pt] $\langle g,ctx^{\prime}\rangle$ $\mapsto$ $\emptyset$
$\langle v,ctx^{\prime}\rangle$ $\mapsto$ $\\{\texttt{obj@sec}\\}$
(a) Points-to analysis

$\langle\mathit{foo},\mathit{ctx}\rangle\rightarrow\langle\mathit{bar},\mathit{ctx}\rangle$
---
[3pt/1pt] $\langle\mathit{set},\mathit{ctx^{\prime}}\rangle$ $\rightarrow$
$\langle\mathit{setSecret},\mathit{ctx^{\prime}}\rangle$
$\langle\mathit{get},\mathit{ctx^{\prime}}\rangle$ $\rightarrow$
$\langle\mathit{getSecret},,\mathit{ctx^{\prime}}\rangle$
$\langle\mathit{get},\mathit{ctx^{\prime}}\rangle$ $\rightarrow$
$\langle\mathit{leak},,\mathit{ctx^{\prime}}\rangle$
(b) Callgraph analysis

Figure 4. Pre-analysis of host and guest language

In the example in LABEL:lst:toyexample:host and LABEL:lst:toyexample:guest, a
pre-analysis of the host language infers that $i$ and $v$ under some contexts
refer to obj@iface and obj@sec, respectively (Fig. 4(a)). Since $x$ captures
an FFI call’s return value, the analysis ignores this operation. Similarly, in
the guest language, $g$ captures the value of an FFI call, which is also
ignored. As expected, the pre-analysis result is incomplete and misses crucial
data flows. LABEL:lst:toyexample:host and LABEL:lst:toyexample:guest show that
the methods set and get are reachable from foo. Section 2.2 extends the pre-
analysis to resolve these edges by constructing an inter-language callgraph.
Further, the guest object obj@sec defined at Line 16 is written to the
BridgeClass’s field secret through the bridge invocation at Line 17. At Line
20, it reads from this field into $g$ and at the end returns it to the
variable $x$ in foo. Therefore, $g$ and $x$ should refer to obj@sec. We
resolve these dataflows with our modular callgraph construction and summary
specialization approach (Section 2.3.3).

###  2.2. Modular Call-Graph Construction

The modular call-graph construction determines the edges for inter-language
function calls happening through _eval_ and interface variables. It builds
upon the incomplete call-graphs obtained from the pre-analysis phase. The
process begins with an incomplete host call graph and expands it to include
all bridge class methods; our analysis assumes that all bridge class methods
can be invoked from the guest. Initially, the extended host call-graph
($G_{host}$) includes potentially disconnected nodes (we include methods of
the bridge class even if the host code does not invoke them). The next
objective is to complete the missing edges in the host and guest call graphs
($G_{guest}$), i.e., to add the corresponding edges from host to guest (via
_eval_) and vice versa (via _interface variables_).

Figure 5. Call-graph for program in LABEL:lst:toyexample:host and
LABEL:lst:toyexample:guest

1

Input: Host and guest call graph $G_{host}$, $G_{guest}$

Output: Interlanguage callgraph $G$

Output: Set of bridge callgraphs $B_{m_{h}},m_{h}\in G_{host}$

2 $G\leftarrow G_{host}\cup G_{guest}$

_3_ foreach  _$\mathbf{eval}(m_{g})\in m_{h}$ where _

_4_ __ $m_{g}\in G_{guest}$ // guest method

5 __ $m_{h}\in G_{host}$ /* host method */ do

6 Extend G to include an edge $(m_{h},m_{g})$

7 if  _$v\in\mathit{InterfaceVar(m_{h})}$ // v is defined in $m_{h}$ and
$\mathit{v\in use(m_{g})}$ // v used in some expression in $m_{g}$_ then

8 $G,B_{m_{h}}\leftarrow\mathit{DiscoverBridgeCalls}(v,m_{h},m_{g})$

9

10 end if

11

12 end foreach

Algorithm 1 Modular Callgraph Analysis

Algorithm 1 describes the modular call graph generation. At first we merge the
independent host and guest call graphs. The next step identifies guest methods
invoked via _eval_ in a host method (Algorithm 1), for which an edge is added
from the host to the guest method (Algorithm 1). The guest language can also
access the host’s methods via interface objects. Such flows are added at
Algorithm 1 (explained in Algorithm 2). The key idea is to search the guest
methods for invocations of bridged host methods via interface variables. If
such a call exists, edges between the corresponding guest and host methods are
added together with edges from the original host method to the bridged host
methods. The latter edges are referred to as _bridge call edges_. They denote
the indirect call relationship to host language methods through bridge objects
in the guest language.

###### Definition 0 (Bridge call edge.).

Let $i$ be an interface variable shared from a host method $m_{h}\in
G_{host}$, $m_{g}\in G_{guest}$ such that $m_{g}$ invokes a bridged method
$m_{b}\in G_{host}$ via the interface variable $i$ (or its aliases). Then, a
bridge call edge, denoted as $E_{bc}$, is a transitive call edge from $m_{h}$
to $m_{b}$ in the interlanguage call graph $G$.

Figure 5 shows the transitions involved in creating an interlanguage call
graph for the example in LABEL:lst:toyexample:host. Step 0 depicts the call
graph obtained during the pre-analysis phase. Initially, $G_{host}$ has no
edges originating from _foo_ as the pre-analyses is oblivious to edges from
foreign function calls. The host call graph is extended to include the bridge
methods (step 1). The call graph is expanded further to include edges that
perform indirect invocation of guest methods through eval (step 2). In the
last step, the call graph is extended to include the bridge call edges (step
3); _setSecret_ and _getSecret_ are called via the interface variable _i_.
Therefore, bridge call edges (_foo_ , _setSecret_) and (_foo, getSecret_) are
added to $G$. Bridge call edges are used to determine the methods required for
summary-specialization and unification in our analysis. We define the notion
of bridge callgraph as an directed graph formed by bridge edges and nodes in
Definition 2.2.

###### Definition 0 (Bridge callgraph).

A bridge callgraph $B_{m_{h}}(N^{\prime},E_{bc})$ is a connected intra-
language graph such that $E_{bc}$ comprises all bridge call edges originating
in $m_{h}\in N^{\prime}$.

Input: Interface variable $v$, host language method $m_{h}$, guest language
method $\mathit{m_{g}}$

Output: Interlanguage callgraph $G$

Output: Bridge call graph $B_{m_{h}}$

_1_ foreach  _invocation x. $m()$ in $m_{g}$ where $x\in\textit{MayAlias}(v)$
_

2 _and_ $m\in M_{b}$ /* $M_{b}$ is set of bridge class methods */ do

3 add edge $(m_{g},m)$ to $G$

4 add bridge call edge $(m_{h},m)$ to $B_{m_{h}}$

5 end foreach

6//$\mathit{alias}$ as a parameter to another guest function

7 foreach  _invocation $m_{g}^{\prime}(*,x,*)$ in $m_{g}$ where
$x\in\textit{MayAlias}(v)$_ do

8 $\mathit{DiscoverBridgeCalls}(x,m_{h},m_{g}^{\prime})$

9 end foreach

10

Algorithm 2 DiscoverBridgeCalls

The shaded part of Fig. 5 (step 4) shows the bridge callgraph originating in
_foo()_ for the example in LABEL:lst:toyexample:host and
LABEL:lst:toyexample:guest. An indirect call from _foo_ to _setSecret_ and
_getSecret_ happens through the bridge object $i$. The bridge callgraphs are
the core data structures used in summary specialization, unification, and
injection.

###  2.3. Modular Analysis Framework

We now present the analysis’s core pillar – summary specialization. Summary
specialization resolves the dataflows occurring in the bridge callgraph from
the guest to the host and vice versa. The procedure is divided into three
steps. Initially, it computes function summaries leveraging the information
gained during the pre-analysis. The function summaries are determined using an
intra-procedural points-to-analysis. The second step involves merging and
propagating these intra-procedural summaries to the functions engaged in the
bridge callgraph to resolve the dataflows occurring via the bridge. At this
stage, the analysis has identified the dataflows from guest to host through
interface variables. These resolved summaries are injected into the
corresponding guest methods in the third step. Once we have inserted summaries
into the bridge methods, the analysis naturally shifts to the whole program
analysis. These techniques are described in detail in SpecializeSummary,
Unification, and InjectSummary.

####  2.3.1. Function Summary

$\inferrule[\textbf{Assign}]{x=y}{[y]\subseteq[x]}$
$\inferrule[\textbf{Load}]{v=x.f}{[x.f]\subseteq[v]}$
$\inferrule[\textbf{Store}]{\texttt{x.f = v}}{[v]\subseteq[x.f]}$
$\inferrule[\textbf{New}]{\texttt{v = new Obj()}\\\
pts(v)=\mathcal{P}(v,\mathit{ctxt})\\\
\mathit{ctxt}=\mathit{CallContext}(v)}{\forall o_{i}\in
pts(v):\\{o_{i}\\}\subseteq[v]}$ $\inferrule[\textbf{Func}]{\texttt{x =
func(args)}\\\ pts(x)=\mathcal{P}(x,\mathit{ctxt})\\\
\mathit{ctxt}=\mathit{CallContext}(x)}{\forall o_{i}\in
pts(x):\\{o_{i}\\}\subseteq[x]}$

Figure 6. Constraint system ($\mathcal{C}_{s}$) for intra-procedural function
summaries

Function summaries in our analysis are obtained through a light-weight intra-
procedural pointer analysis. Our function summaries have the form
$\mathcal{AP}\mapsto H\cup\emptyset$, where $H$ symbolizes the collection of
heap objects, $\mathcal{AP}$ signifies the set of access-paths, and
$\emptyset$ indicates that the associated summary has not been resolved. An
access path consists of the base variable (quintessentially a local variable)
followed by a sequence of field accesses (denoted as x.f.g.h). We choose the
access path representation because it inherently models field-sensitivity
(Lerch et al., 2015) and is bounded, making it suited for data-flow analysis
(Khedker et al., 2007).

The analysis is based on a straightforward constraint-based approach in which
the constraints are reinforced with resolved values from the pre-analysis. We
create the function summaries using constraints of an Andersen’s style
analysis (i.e., inclusion-based) (Sridharan and Fink, 2009). These constraints
have been shown to be precise, and they have become the de-facto
representation for pointer analysis in programming languages that support heap
manipulation (Sridharan et al., 2013). In general, inclusion-based constraints
face scalability issues due to the cubic time and quadratic space complexity
on the number of variables; yet, the function summaries in this phase are
calculated intra-procedurally and hence confined to a small number of
variables.

Input: Bridge callgraph $B_{m_{h}}(N^{\prime},E_{bc})$

Input: Guest pre-analysis $\mathcal{P}_{g}$

Output: Function summary constraints $\mathcal{F}$

1 foreach  _function node $N_{i}\in N^{\prime}$ _ do

2 $\triangleright$ Generate constraints from constraint system in Fig. 6

3
$\mathcal{C}^{N}_{i}\leftarrow\mathit{MakeConstraints(N_{i},\mathcal{C}_{s})}$

4 foreach  _guest function node $N_{g}$ invoking $N_{i}(\bar{q})$ (calling
bridge method) /* $\bar{q}$ is list of formal parameters */_ do

5 let $N_{i}(\bar{t})$ be the function invocation in $N_{g}$ // $\bar{t}$ is
the list of actual parameters

6 add $\mathcal{P}_{g}(t_{j})\subseteq[q_{j}]$ to $\mathcal{C}^{N}_{i}$ where
$t_{j}\in\bar{t},q_{j}\in\bar{q}$

7

8 end foreach

9 foreach  _$c_{i}\in\mathcal{C}^{N}_{i}$_ do

10 if  _$c_{i}$ contains this.fld_ then

11 replace this in $c_{i}$ by the interface variable $b$

12 end if

13

14 end foreach

15

16 $\mathcal{F}^{N}_{i}=\mathit{{\textsc{CubicSolver}}(\mathcal{C}^{N}_{i})}$

17 $\mathcal{F}=\mathcal{F}\cup\mathcal{F}^{N}_{i}$

18 end foreach

$\textsc{UnifySummary}(\mathcal{F},B_{m_{h}})$

Algorithm 3 SpecializeSummary

Fig. 6 shows the constraint system to generate a function summary. We use the
symbol $[var]$ to denote the constraint variable for $var$, $\mathcal{P}$
denotes the pre-analysis, and $pts(var)$ denotes the points-to set for
variable $var$. Assign, Store, and Load are standard Andersen style
constraints. The rule New queries the points-to set of the variable from the
pre-analysis and constructs a constraint for each heap object. In the case of
function calls Func directly obtains the points-to set of the result-variable
(capturing the return value) from the pre-analysis, which already contains
inter-procedural analysis. The collected constraints are then resolved to
function summaries. Algorithm 3 illustrates the procedure to acquire function
summary constraints. Given a bridge callgraph and the pre-analysis, it first
generates the function summary constraints for the bridge callgraph’s function
nodes. Note that (except for the root) the function nodes in a bridge
callgraph comprise the (bridged) functions of the host, which provide
functionality to the guest. After obtaining the constraints for these
functions, the next step is to map their formal parameters to the actual
invocations’ parameters in the guest. Fig. 7 illustrates the procedure from
Algorithm 3 to Algorithm 3. These constraints are then sent into a cubic
solver, which generates the actual function summary constraints.

Figure 7. Function summary constraints for setSecret Function | Constraints | Function Summary
---|---|---
foo | $\\{\mathit{obj@iface}\\}\in[\mathit{i}]$ | $[\mathit{i}]\mapsto\\{\mathit{obj@iface}\\}$
| $\emptyset\subseteq[x]$ | $[\mathit{x}]\mapsto\emptyset$
setSecret | $[\mathit{secret}]\subseteq[\mathit{i.secret}]$ | $[\mathit{i.secret}]\mapsto\\{\mathit{obj@sec}\\}$
| $\\{\mathit{obj@sec}\\}\in[\mathit{secret}]$ |
getSecret | $[\mathit{i.secret}]\subseteq[\mathit{\$ret}]$ | $[\mathit{i.secret}]\mapsto\emptyset$
|  | $[\mathit{\$ret}]\mapsto\emptyset$
Figure 8. Summary constraints and resolved summaries

Fig. 8 shows the constraints and function summaries generated for our example
program. The second column shows the constraints and the third column the
resolved summaries after the cubic solver. In the function foo, we have a
single constraint $\\{\mathit{obj@iface}\\}\subseteq[\mathit{i}]$ which is
resolved to $[\mathit{i}]\mapsto\\{\mathit{obj@iface}\\}$. In the function
setValue, we have two constraints $\\{\mathit{obj@sec}\\}\in[\mathit{secret}]$
and $[\mathit{secret}]\subseteq[\mathit{i.secret}]$; they are resolved to
$[\mathit{i.secret}]\mapsto\\{\mathit{obj@sec}\\}$. In the function getValue,
we have a single constraint $[\mathit{i.secret}]\subseteq[\mathit{\$ret}]$
resolved to $[\mathit{\$ret}]\mapsto\emptyset$ and
$[\mathit{i.secret}]\mapsto\emptyset$.

####  2.3.2. Unification

As evident in Fig. 8, in the setSecret function i.secret corresponds to the
guest object _obj@sec_ ; however, in the getSecret function, i.secret remains
unknown, despite the fact that the access paths are identical based on the
same interface variable $i$. To address this, we combine these summaries
according to the access path.

Two summaries with the same access path are combined by a union operation,
i.e., if $ap\mapsto\phi_{1}$ and $ap\mapsto\phi_{2}$, then the unification
results in $ap\mapsto\phi_{1}\cup\phi_{2}$. The unification is also alias-
aware, i.e., aliases of the base variable in $ap$ are also unified. For
simplicity, we assume that the access paths are not nested. This is a fair
assumption since most dataflow analyses are performed on an intermediate
language, which simplifies the language to such a syntax for analysis. Fig. 9
shows the result of unification for the bridge callgraph shown in Fig. 5. This
step unifies the summaries based on the access paths and aliased access paths.
First, the analysis resolves the data flow across bridge functions by
comparing the access paths, and then it updates the corresponding points-to
sets. Therefore, $\mathit{i.secret}$ points to the guest object
$\mathit{obj@sec}$ across all functions participating in the bridge callgraph.

Figure 9. Unification for the bridge callgraph in Fig. 5

####  2.3.3. Summary Injection

After summary unification, the analysis has resolved the data flows across the
bridge callgraph. The analysis, in particular, resolved the operations in
bridge methods, i.e., host language functions called from the guest interface.
Two tasks remain: First, translating the analysis summaries to be compatible
with the analysis models adopted by the host and guest languages. Second,
propagating the translated summaries to the invoking functions at the guest
side.

The summaries obtained via unification are in the access path format; however,
we need to translate them to the host and guest languages’ analysis models to
reuse them in the host and guest. Notably, we translate the access path format
to their native format. The two levels of sensitivities involved in the
underlying analysis, calling context and field sensitivity, are of particular
relevance. Since the bridge functions are invoked through interface variables
in the guest applications, the context of the host method is assigned in the
bridge callgraph. Following that, we classify field sensitivity according to
how the underlying analysis handles field operations; as field-sensitive,
field-based, or field-insensitive. The analysis determines the appropriate
field sensitivity representation depending on the type of underlying analysis.

Considering the running example, the analysis resolves that the getSecret
function returns obj@sec. The return value is captured by the variable $g$ in
getAndLeak; however, at this stage $g$ has not been resolved and still points
to $\emptyset$. Consequently, the analysis misses that $g$ exposes a sensitive
value at Line 21. Summary injection performs this step by retrofitting the
pre-analysis with the unified summary. First, the unified summary information
is translated to the host language’s analysis model. The pre-analysis updates
cause an incremental update of the variables impacted by the injected
dataflows. Next, these updates (translated summaries) are propagated to the
affected guest functions.

Input: Projection $\mathcal{R}^{f}$, pre-analysis $\mathcal{P}$

Input: Function Summary $\mathcal{F}^{f}$ of a function $f$

Output: updated pre-Analysis $\mathcal{P}_{modular}$

1 $\mathit{changedVars}\leftarrow\emptyset$

2 Updated Projection $\mathcal{R}^{f}_{\Delta}\leftarrow\emptyset$

3 forall  _$(\mathit{accesspath},\mathit{heap})\in\mathcal{F}^{f}$_ do

4 if  _$\mathit{accesspath}$ is a simple variable $\mathit{var}$_ then

5
$\mathcal{R}^{f}_{\Delta}=\mathcal{R}^{f}_{\Delta}\cup\\{(\mathit{var},\mathit{heap},\mathit{ctxt})\\}$
for any $\mathit{ctxt}\in\mathcal{R}^{f}$

6

7 end if

8 if  _$\mathit{accesspath}$ is a field access x.f_ then

9

10 case  _FieldSensitive analysis_ do

11
$\mathcal{R}^{f}_{\Delta}=\mathcal{R}^{f}_{\Delta}\cup\\{(o_{i},f,heap)\mid\forall
o_{i}\in\mathcal{P}(x)$}

12

13 end case

14 case  _FieldBased analysis_ do

15 $\mathcal{R}^{f}_{\Delta}=\mathcal{R}^{f}_{\Delta}\cup\\{(f,heap)\\}$

16

17 end case

18 case  _FieldInsensitive analysis_ do

19
$\mathcal{R}^{f}_{\Delta}=\mathcal{R}^{f}_{\Delta}\cup\\{(o_{i},heap)\mid\forall
o_{i}\in\mathcal{P}(x)\\}$

20

21 end case

22

23 end if

24
$\mathit{changedVars}\leftarrow\mathit{changedVars}\cup\\{\mathit{accesspath}\\}$

25

26 end forall

27 // Update the guest projection to include resolved host projection

28 foreach  _$f^{\prime}\in G_{\mathit{guest}}$ invoking $f$, which is a
bridge method_ do

29 // Propagate host function’s ($f$) return variable to guest ($f^{\prime}$),
adapting variable name.

30
$\mathcal{R}^{f^{\prime}}=\mathcal{R}^{f^{\prime}}\cup\mathcal{R}^{f}_{\Delta}[\$\mathit{ret}]$

31

32 end foreach

33

$\mathcal{P}_{modular}=\mathcal{P}\cup\mathcal{R}^{f^{\prime}}$

Algorithm 4 InjectSummary

Algorithm 4 shows the steps for summary injection. For a given function $f$,
it takes the analysis snapshot of $f$ as an input. We denote this snapshot as
a _projection_ of a function. Formally, we define the _projection_ as:

###### Definition 0 (Projection).

A projection
$\mathcal{R}^{f}=\bigcup_{v\in\mathit{def}(f)}\\{(v,h,\mathit{ctxt})\mid
h=\mathit{pointsTo}(v,\mathit{ctxt})\\}$ for a function $f$ is a set of
points-to sets for the variables defined in the function $f$ under a context
$\mathit{ctxt}$.

For the function $f$ in the bridge graph, our analysis gets the function’s
context and produces a projection of the analysis. Intuitively, projection is
the points-to sets of the variables defined in the function for a context
ctxt. Algorithm 4 uses the projection of the analysis to inject the dataflow
facts obtained from unification. Along with the projection, the algorithm
accepts the function summary of a function $f$ in access-path format, and
information on how the function handles field operations — either
FieldSensitive or FieldBased or FieldInsensitive. Earlier research (Sridharan
and Fink, 2009; Feldthaus et al., 2013; Späth et al., 2019; Grech and
Smaragdakis, 2017; Bravenboer and Smaragdakis, 2009; Milanova et al., 2005)
shows that these are the primary techniques for handling field operations, and
hence, we confine our algorithm to those. Algorithm 4 to 4 translate the
obtained summary information in access-path representation to the analysis-
supported representation. In Algorithm 4, the translated points-to-set for the
simple variables are added to the projection. Algorithm 4 incorporates the
translated points-to-set for field-sensitive analysis, Algorithm 4 for the
field-based variables, and Algorithm 4 for the field-insensitive variables. In
the following step, the modified host projection (of the bridge method) is
propagated to the calling guest method (connected via bridge method edge in
bridge graph). Finally, the pre-analyses are revised and translated
projections are included. With these revisions, the analysis has successfully
resolved all key operations for (one) bridge callgraph’s inter-language
operation.

(a) Summary Injection in methods

Method Before Summary Injection After Summary Injection foo $\langle
i,ctx\rangle\mapsto\\{\texttt{obj@iface}\\}$ $\langle
i,ctx\rangle\mapsto\\{\texttt{obj@iface}\\}$ $\langle
x,ctx\rangle\mapsto\emptyset$ $\langle
x,ctx\rangle\mapsto\\{\texttt{obj@sec}\\}$ setSecret $\langle
i.secret,ctx^{\prime}\rangle\mapsto\\{\texttt{obj@sec}\\}$ $\langle
i,secret,ctx\rangle\mapsto\\{\texttt{obj@sec}\\}$ getSecret $\langle
i.secret,ctx^{\prime}\rangle\mapsto\\{\texttt{obj@sec}\\}$ $\langle
i,secret,ctx\rangle\mapsto\\{\texttt{obj@sec}\\}$ $\langle\mathdollar
ret,ctx^{\prime}\rangle\mapsto\\{\texttt{obj@sec}\\}$ $\langle\mathdollar
ret,ctx\rangle\mapsto\\{\texttt{obj@sec}\\}$ set $\langle
v,ctx^{\prime}\rangle\mapsto\\{\texttt{obj@sec}\\}$ $\langle
i.secret,ctx^{\prime}\rangle\mapsto\\{\texttt{obj@sec}\\}$ getAndLeak
$\centering\emptyset\@add@centering$ $\langle
g,ctx^{\prime}\rangle\mapsto\\{\texttt{obj@sec}\\}$

(b) Analysis before and after summary injection

Figure 10. Summary Injection for LABEL:lst:toyexample:host and
LABEL:lst:toyexample:guest

Fig. 10 summarizes the output of the summary injection to the pre-analysis.
The second and third columns depict a snapshot of the analysis prior to and
following the summary injection. The return value of the getSecret method has
been updated to $\\{\texttt{obj@sec}\\}$ as a result of the summary
unification. Since getAndLeak invokes the function getSecret, the summary
injection automatically propagates the updated return value to getAndLeak, and
the points-to set of g now contains $\\{\texttt{obj@sec}\\}$. The bridge
callgraph includes the connection from getAndLeak to foo, and consequently,
the $\\{\texttt{obj@sec}\\}$ is propagated to the variable x.

####  2.3.4. Overall Workflow

Algorithm 5 shows the workflow of the algorithms mentioned before. Our
algorithm runs by computing the call graphs and unifying the pre-analysis via
summary specialization until it no longer changes, i.e., achieves a fixed
point.

Input: $\mathcal{P}$ Pre-analyses

Input: $G_{\mathit{host}},G_{\mathit{guest}}$ host and guest language
callgraphs

Output: Analysis $\mathcal{P}_{\mathit{modular}}$

1

2repeat

3
$G,B\leftarrow\textsc{ModularCallgraphAnalysis}(G_{\mathit{host}},G_{\mathit{guest}})$

4 $\mathcal{F}\leftarrow\textsc{SpecializeSummary}(B,\mathcal{P}_{g})$

5 forall  _$f\in\mathit{functions(B)}$_ do

6 $\mathcal{R}^{f}\leftarrow\mathit{Projection}(f)$

7
$\mathcal{P}_{\mathit{modular}}\leftarrow{\textsc{InjectSummary}}(\mathcal{R}^{f},\mathcal{P},\mathcal{F}^{f})$

8

9 end forall

10

11until  _$\mathcal{P}_{\mathit{modular}}$ is unchanged (i.e., reaches a fixed
point)_;

Algorithm 5 PointerAnalysisSummarySpecialization

####  2.3.5. Multiple Bridge Calls

Figure 11. Multiple Bridge callgraphs

As is, bridge calls originating from different host functions will produce
multiple bridge callgraphs, thus, (potentially) generating a list of
disconnected bridge callgraphs, as illustrated in Fig. 11. To aid in the pre-
analysis of actual data flow across bridge callgraphs, resolved summaries
across each bridge callgraph should propagate in the correct sequence to
others. In our approach, we use the traditional topological ordering, i.e.,
the execution order as generated by the pre-analysis. In Fig. 11, for example,
analysis resolves the data flow for the bridge callgraph $B_{i}$, and then,
summary injection propagates the modifications down the call-graph (to $B_{j}$
and subsequently to $B_{k}$).

####  2.3.6. A Typical Dataflow Analysis

Given a traditional security lattice, the core part of our framework works
with the points-to set where variables are annotated with the security labels.
Once the annotated points-to-sets have been resolved, a taint analysis can
query those for the alias sets and subsequently use them for taint propagation
(Späth et al., 2016; Das et al., 2022; Grech and Smaragdakis, 2017). A
detailed information flow/taint analysis is accompanied as supplementary
material.

##  3\. Limitations

Figure 1 only allows programs as parameters to eval, so no dynamically
computed target. In practice this is not a restriction in contemporary
programs but could be lifted with additional analysis (Grech et al., 2018;
Arceri and Mastroeni, 2021). Our approach uses may aliases of the interface
object on the guest side. Thus, our analysis may yield imprecise results when
a bridge method has the same name and arity as the guest method. However, this
is a general limitation of static analysis; besides, we have not seen such
occurrences in our dataset. The language assumes that _bridge interfaces_ are
specified and their type is known to the analysis to identify _InterfaceVars_.
This is a fair assumption as modern languages specify the syntax and semantics
of these markers, e.g., Android defines WebView APIs for bridge interface.
Considering this, our analysis assumes that methods invoked via interface
objects are statically resolved, i.e., dynamic binding is not applicable to
the bridge class’s methods invoked via interface objects. Our analysis obtains
these statically resolved interface objects from the pre-analysis.

##  4\. Implementation

We developed a prototype implementation of our approach called  _Conflux_.
_Conflux_ currently supports analysis of Java-C programs and Java-Python
programs. _Conflux_ is implemented in Java, consists of about 5k lines of
code, and builds on top of the WALA analysis framework (Center, 2022) for
analyzing Java and Python. For analyzing C/C++ programs, we choose SVF (Sui
and Xue, 2016; Sui et al., 2014), a popular tool for C/C++ dataflow analysis.

Extensibility: At the time of writing this paper,  _Conflux_ supports WALA-SVF
and Java-Python analysis in Wala. However, _Conflux_ is extensible to other
language combinations (with some implementation efforts for language
bindings). _Conflux_ provides a set of interfaces (Adaptors) to extend to
other analysis frameworks. A detailed API document containing the Interface
details will be open-sourced along with _Conflux_.

For analyzing Android NDK programs, _Conflux_ takes the android apk file as
input. It uses the _retdec_ decompiler (Avast, 2022) to lift the NDK libraries
bundled in the apk file to LLVM. It takes the Java jar files and Python
sources as input for Graal Polyglot APIs.

##  5\. Evaluation

We empirically evaluate  _Conflux_ ’s efficacy in resolving the inter-language
operations in polyglot applications. To demonstrate the generalizability of
_Conflux_ to other inter-operable languages, we evaluate  _Conflux_ on two
polyglot language models: (1) Java-C communication in Android NDK apps and (2)
Java-Python applications using GraalVM. Java-C communication is manifested in
Java (or Android) applications that use system-level features for various
reasons, such as performance or interfacing with the hardware. Java-Python
applications in our dataset use the GraalVM Polyglot API. In particular, our
evaluation is designed to address the following research questions:

  1. RQ1

How does  _Conflux_ compare to the state-of-the-art polyglot analyses in terms
of precision and scalability?

  2. RQ2

Can  _Conflux_ generalize to multiple polyglot language models?

All the experiments were performed on a laptop running macOS Monterey with a
10-Core M1 Pro processor and 32 GB RAM.

###  5.1. RQ1: Comparison to the state-of-the-art

Recent years have seen a few research tools (Lee et al., 2020; Monat et al.,
2021; Wei et al., 2018a; Buro et al., 2020) to address the analysis of
polyglot apps. C-summary (Lee et al., 2020) is the most recent multilingual
analysis tool, and it is shown to overcome various limitations of previous
works. Thus, we compare the effectiveness of  _Conflux_ with C-summary (Lee,
2022).

Subject apps. To evaluate the first research question, our criteria for
selecting the subject apps is dictated by two aims: (1) include apps from the
C-summary dataset to avoid selection bias, and (2) evaluate  _Conflux_ on
various Java and C communication patterns. Considering these two choices, we
compiled 23 Android JNI apps from the widely used NativeFlowBench (ArgubLab,
[n. d.]; Wei et al., 2018a) and 16 popular apps from the Google play store.
NativeFlowBench is an Android app benchmark that includes various inter-
language communication features. Each app in this benchmark has a ground
truth.

Next, we assess all tools on the following parameters: (1) whether it can
discover the callgraph edges from the host-to-guest language and vice-versa,
and (2) whether it can discover the reachable methods in the guest language to
generate a whole-program call-graph.

Table 1. Analysis of JNI from benchmark from NativeFlowBench microbenchmark
(ArgubLab, [n. d.]) and Real-world JNI Apps. T means that the the underlying
tool synthesizes an imprecise program such as Java.Top(). $\square$ denotes
that the tool gives empty programs.

Benchmark C-Summary Conflux Generated Analyze $N_{J}$ $E_{J}$ $N_{C}$ $E_{C}$
IL Time (in sec) NativeFlowBench complexdata $\square$ ✓ 364 940 8 10 2 $<1$
complexdata stringop ✗ ✓ 5802 13015 9 10 1 $<1$ dynamic register multiple ✗ ✓
382 979 9 13 3 $<1$ heap modify $\square$ ✓ 6889 15272 11 12 1 $<1$ icc
javatonative ✗ ✗ 366 895 13 14 0 $<1$ icc nativetojava $\square$ ✓ 7865 14891
8 9 1 $<1$ leak $\square$ ✓ 367 894 3 4 1 $<1$ leak array $\square$ ✓ 383 968
4 5 1 $<1$ leak dynamic register $\square$ ✓ 367 895 9 11 1 $<1$ method
overloading $\square$ ✓ 307 751 3 5 2 $<1$ multiple interactions $\square$ ✓
384 980 11 13 2 $<1$ multiple libraries $\square$ ✓ 382 978 3 5 1 $<1$ noleak
$\square$ ✓ 367 894 1 2 1 $<1$ noleak array $\square$ ✓ 5795 13008 4 5 1 $<1$
nosource $\top$ ✓ 306 746 1 2 1 $<1$ pure ✗ ✗ 6581 14686 39 42 0 $<1$ pure
direct ✗ ✗ 6581 14686 30 48 0 $<1$ pure direct customized ✗ ✗ 380 958 30 48 0
$<1$ set field from arg $\top$ ✓ 373 908 4 5 1 $<1$ set field from arg field
$\top$ ✓ 314 763 4 5 1 $<1$ set field from native $\top$ ✓ 310 762 14 15 1
$<1$ source $\top$ ✓ 6892 15271 7 8 1 $<1$ source clean $\top$ ✓ 385 985 4 5 1
$<1$ Google PlayStore Apps Airmessage - ✓ 53987 30886 169 141 4 30 Apple Music
- ✓ 51867 28760 8334 3055 8 72 Arte - ✗ 57224 31237 74 31 0 480 ClearScore - ✗
50834 31063 344 321 0 30 CommonsLab - ✓ 28817 16576 447 348 14 15 FPLayAndroid
$\top$ ✓ 5052 2316 294 238 14 240 FairEMail $\top$ ✓ 59766 40214 3854 1116 5
85 JioMoney - ✓ 50002 22904 299 232 2 27 NetGuard - ✓ 12159 6448 333 168 2 5
PCAPdroid $\top$ ✓ 54270 28835 613 303 3 29 Proton VPN $\top$ ✓ 56217 31253
56217 8 1 54 Spotify - ✗ 59690 33736 439 177 0 600 Spotify Lite - ✓ 51728
31234 843 434 8 390 TermOne $\top$ ✗ 47352 24365 48 30 0 22 Termux $\top$ ✓
15656 9603 77 36 6 6 TimidityAE $\top$ ✓ 15278 8275 187 127 6 1

Table 1 contains the subject apps and shows the evaluation results of
_Conflux_ and C-Summary on them. The first column shows the subject apps’
name, and the second includes the analysis results obtained from C-summary.
The columns $N_{C}$ and $E_{C}$ denote the number of nodes and edges in call
graph of the native component, column $\mathit{IL}$ for each tool lists the
number of edges in the call graph that go from the host language to the guest
language. _Conflux_ was configured for one-callsite-sensitive and field-
sensitive analysis for Java and field-sensitive context-insensitive analysis
for C/C++.

##### Our Experience with C-summary

Table 1 uses a few symbols to denote the evaluation results of  _Conflux_ and
C-summary. The symbol $\square$ indicates that the analysis was able to detect
the function signature but failed to synthesize the function definition. In
our experiments, in 11 out of 19 apps, C-summary failed to synthesize a
function definition. This happens when a program has complex pointer
operations (such as pointer arithmetics) or method overloading; for example,
programs use string library operations such as strcpy, which do not have the
source code. The symbol $\top$ indicates the tool could identify the function
signature but generated an empty program such as Java.Top(), which essentially
returns the set of all heap allocations (imprecise analysis result). In six
out of 19 apps, C-summary generated an empty program. This happens when object
field load and store methods are accessed in native code. For example, in the
benchmark app _complexdata_stringop_ , C-summary generates an empty program
for the Java methods GetFieldID and GetObjectClass. The symbol ✗ indicates
that a tool could neither identify the function signature nor synthesize the
program. In six out of 19 apps, C-summary showed this behavior. This happens
in two cases: (1) intent operations over native classes and (2) operations not
handled by C-summary such as arrays or global variables, which are reported
limitations of their framework (Lee et al., 2020). Thus, C-summary could not
synthesize the required program for further analysis by Android analysis
tools, thus hiding the functions reachable through the bridge interfaces. In
many cases it could only identify the function definitions used to find
reachable native functions from the Java (Android) side.

#####  _Conflux_ ’s Results

_Conflux_ uses SVF (for C/C++) and Wala (for Java) as the pre-analyses. We
configured SVF to run with the entrypoints defined in the host language
analysis. Based on the entrypoints, it triggers SVF to analyze the guest
functions in the environment and collects the results. Consequently, SVF
identifies the reachable functions in the guest language and _Conflux_
combines the analysis result with those obtained from Wala to build an inter-
language call graph. The columns $N_{J}$ and $E_{J}$ show the number of call
graph nodes and edges identified by the respective pre-analyses. The numbers
are significantly high considering the size of the benchmarks because Wala
includes a number of libraries by default (Prakash et al., 2021), which
increases the call graph size. The column IL reports the interlanguage edges
in the call graph, i.e., the edges which go from Java to C and vice-versa.
Column $E_{C}$ shows the edges identified by SVF. In our evaluation, _Conflux_
is able to identify the inter-language edges in 19 out of 23 benchmarks, i.e.,
it identifies the methods which would have been previously reported
unreachable with Wala. In the remaining four cases, _Conflux_ does not
identify the entry point where native code is invoked via intents, which is
expected as middleware-based inter-language communication is out of the scope
of this study. Intent resolution tools (Li et al., 2015; Wei et al., 2018b;
Tiwari et al., 2019a) could supplement _Conflux_ to resolve these entrypoints.

RQ1(a): In 19 out of 23 subjects, _Conflux_ builds the complete inter-language
call graph. _Conflux_ leverages the strength of individual analyses and maps
required call edges from host-to-guest and vice-versa.

##### Scalability

To evaluate the efficacy of  _Conflux_ on real-world apps, we downloaded 50
popular and recent apps from the Google play store. To filter out NDK apps, we
vetted their decompiled code for the presence of shared object files,
resulting in 16 apps. These apps include popular apps such as Spotify, and
Apple Music. We share a few apps in our dataset with those evaluated by
C-summary.

The first part of the bottom half of Table 1 shows the results obtained on
these apps from C-Summary. Since C-summary is designed to run on source code,
we ran it on seven apps that are open-source. In all of these apps, C-summary
synthesized imprecise programs (statement containing Java.Top()).

The second part of Table 1 shows the results of our analysis on these apps.
Our analysis scales for many popular apps and analyzes relatively large apps
such as _Spotify_ within 10 minutes (median around 2 minutes). Among these,
_Conflux_ was able to identify inter-language call graph edges in 12 out of 16
apps. Again, in the other four apps, guest functions were called through
intents, which are out of scope. To validate the number of inter-language
edges, we scanned the decompiled files for the presence of native markers in
the binary. Two authors independently validated these results.

RQ1(b): In 12 out of 16 large apps, _Conflux_ successfully builds the
interlanguage call graph in about 2 minutes on average. It demonstrates that
combining the individual analyses via  _Conflux_ is a promising direction for
a scalable dataflow analysis in polyglot applications.

###  5.2. RQ2: Analysis of Java-Python programs with GraalVM

To evaluate the generalizability of our approach, we applied _Conflux_ to
Java-Python-based GraalVM programs. GraalVM’s Polyglot API is relatively new,
and we could not find many projects using Java-Python-based communication on
GitHub. To curate the apps, we selected projects with the keyword graalpython
and those importing the class (or subclasses) of org.graalvm.polyglot.Context.
Out of the seven results we obtained on Github, we searched for the presence
of Python code snippets and files. Finally, we confirmed two applications with
Java as the host language and Python as the guest (Table 2). We also develop
an additional microbenchmark for analysis, in total, having three micro-
benchmarks for study. In BM-1 (bm1, 2022), Java setter and getter methods are
invoked from Python. BM-2 (bm2, 2022) invokes Java library methods from
Python. In BM-3 (bm3, 2022), Java methods are called from Python (as host).

Table 2. Java-Python apps in GraalVM  Benchmark | Wala-Java | Wala-Python | Conflux
---|---|---|---
BM-1 | ✓ | ✓ | ✓
BM-2 | ✓ | ✓ | ✓
BM-3 | ✗ | ✓ | ✗

_Conflux_ leverages the Wala framework as the pre-analysis, configured to one-
callsite-sensitive and field-sensitive for both languages, to obtain the
analysis of Java and Python programs. _Conflux_ successfully analyzed BM-1 and
BM-2, and the inter-language function calls are correctly resolved. BM3 uses
Java as the guest language and Python as the host. Therefore, Wala-Java failed
to analyze the program as it requires a main method, whereas the guest
language is used as a library.

RQ2:  _Conflux_ can be configured to multiple polyglot frameworks. To
exemplify, _Conflux_ is configured to analyze GraalVM programs, and
successfully resolves the bridge interfaces in two of three Java-Python apps.

##  6\. Related Work

##### Modular polyglot analysis.

Lee  _et al._ (Lee et al., 2020) proposed a modular semantic summary
extraction technique for analyzing Java-C/C++ interoperations. Monët  _et al._
(Monat et al., 2021) used abstract interpretation for analyzing Python and C
programs. JN-SAF (Wei et al., 2018a) by Wei  _et al._ used a function summary
based bottom-up dataflow analysis for analyzing Java Native applications. All
these works rely on explicit boundaries between the host and guest. Also,
these works are tied to particular host and guest languages, while our work is
language-agnostic. Buro  _et al._ proposed an abstract interpretation-based
framework (Buro et al., 2020) for analyzing multilingual programs by combining
analysis of while and expression language. In contrast to their work, our work
combines languages with more complex operations.

##### Monolithic Polyglot Analysis

JET (Li and Tan, 2011), Li and Tan (Siliang and Gang, 2009), Kondoh and
Onodera (Kondoh and Onodera, 2008) analyze bugs occurring at Java JNI
interfaces. Fourtounis  _et al._ (Fourtounis et al., 2020) scanned native
binaries to extract the dataflow facts use it for the analysis in Java.
Compared to them, our approach is generic and not restricted to the JNI calls.
Bae  _et al._ (Bae et al., 2019), (Lee et al., 2016), Lee  _et al._ (Lee and
Ryu, 2019) proposed techniques to analyze Android WebViews (Java-Javascript)
programs. Samhi  _et al._ (Samhi et al., 2021) mapped the native code to Soot
IR for a unified analysis. Turcotte  _et al._ (Turcotte et al., 2019)
implement a type checker for correctness of types for Lua-C programs. Brucker
and Herzberg (Brucker and Herzberg, 2016) proposed a static analysis to detect
security vulnerabilities in Cordova (Java-Javascript) based applications. In
contrast to these works on multilingual program analysis, our work defines a
modular program analysis combining existing analysis.

##### Modular Analysis of monolingual applications

It is orthogonal to our work, yet these form the backbone of our analysis as
pre-analysis. JAM (Nielsen et al., 2021) by Nielsen  _et al._ proposed a
modular call-graph construction for analysis of _Node.js_ applications. Tiwari
_et al._ (Tiwari et al., 2019a) used persistent summaries for resolving inter-
component communication in Android. ModAnalyzer by Schubert  _et al._
(Schubert et al., 2021) leverages the pattern used by C++ developers to
perform a modular analysis of C++ applications and libraries. Dilling  _et
al._ (Dillig et al., 2011) and Whaley and Rinard (Whaley and Rinard, 1999)
proposed compositional pointer analyses for C and Java respectively. Illous
_et al._ (Illous et al., 2020) proposed a separation logic based technique for
compositional shape analysis.

##  7\. Conclusion

In this work, we leveraged existing language analyses for analyzing
multilingual programs. We proposed a series of algorithms for the same and
demonstrated our approach’s efficacy with a prototype implementation called
_Conflux_. Our analysis neither requires us to remodel the analysis for
polyglot applications nor translate the existing semantics of the guest
language to the host languages, consequently saving a lot of effort in this
process.

## References

  * (1)
  * and (2022) 2022\.  https://developer.android.com/ndk
  * gra (2022) 2022\.  https://www.graalvm.org
  * bm1 (2022) 2022\.  https://github.com/vpaz11/python-graal-java
  * bm2 (2022) 2022\.  https://github.com/shelajev/graalpython-java-example
  * bm3 (2022) 2022\.  https://github.com/vspaz/graalvm-java-python-interoperation/tree/main/src/main/java/org/vspaz
  * rcp (2022) 2022\.  Rcpp for Seamless R and C++ Integration.  http://www.rcpp.org
  * rpy (2022) 2022\.  Rpy2: Python in R.  https://rpy2.github.io/doc/v2.9.x/html/index.html
  * Anonymous (2022) Anonymous. 2022\.  Conflux Artefacts.  https://figshare.com/s/872fc296f1a0827352ac
  * Arceri and Mastroeni (2021) Vincenzo Arceri and Isabella Mastroeni. 2021.  Analyzing Dynamic Code: A Sound Abstract Interpreter for Evil Eval.  _ACM Trans. Priv. Secur._ 24, 2, Article 10 (jan 2021), 38 pages.  https://doi.org/10.1145/3426470
  * ArgubLab ([n. d.]) ArgubLab. [n. d.].  NativeFlowBench.  https://github.com/arguslab/NativeFlowBench
  * Avast (2022) Avast. 2022.  Avast/RETDEC: Retdec is a retargetable machine-code decompiler based on LLVM.  https://github.com/avast/retdec
  * Bae et al. (2019) Sora Bae, Sungho Lee, and Sukyoung Ryu. 2019.  Towards Understanding and Reasoning About Android Interoperations. In _2019 IEEE/ACM 41st International Conference on Software Engineering (ICSE)_. 223–233.  https://doi.org/10.1109/ICSE.2019.00038
  * Bravenboer and Smaragdakis (2009) Martin Bravenboer and Yannis Smaragdakis. 2009.  Strictly Declarative Specification of Sophisticated Points-to Analyses. In _Proceedings of the 24th ACM SIGPLAN Conference on Object Oriented Programming Systems Languages and Applications_ (Orlando, Florida, USA) _(OOPSLA ’09)_. ACM, New York, NY, USA, 243–262.  https://doi.org/10.1145/1640089.1640108
  * Brucker and Herzberg (2016) Achim D. Brucker and Michael Herzberg. 2016.  On the Static Analysis of Hybrid Mobile Apps. In _Engineering Secure Software and Systems_ , Juan Caballero, Eric Bodden, and Elias Athanasopoulos (Eds.). Springer International Publishing, Cham, 72–88.
  * Buro et al. (2020) Samuele Buro, Roy L. Crole, and Isabella Mastroeni. 2020\.  On Multi-language Abstraction. In _Static Analysis_ , David Pichardie and Mihaela Sighireanu (Eds.). Springer International Publishing, Cham, 310–332.
  * Center (2022) IBM T.J. Watson Research Center. 2022\.  Wala T.J. watson libraries for analysis.  https://github.com/wala/WALA.
  * Cousot and Cousot (2002) Patrick Cousot and Radhia Cousot. 2002.  Modular Static Program Analysis. In _Compiler Construction_ , R. Nigel Horspool (Ed.). Springer Berlin Heidelberg, Berlin, Heidelberg, 159–179.
  * Das et al. (2022) Dipanjan Das, Priyanka Bose, Aravind Machiry, Sebastiano Mariani, Yan Shoshitaishvili, Giovanni Vigna, and Christopher Kruegel. 2022\.  Hybrid Pruning: Towards Precise Pointer and Taint Analysis. In _Detection of Intrusions and Malware, and Vulnerability Assessment_ , Lorenzo Cavallaro, Daniel Gruss, Giancarlo Pellegrino, and Giorgio Giacinto (Eds.). Springer International Publishing, Cham, 1–22.
  * Dillig et al. (2011) Isil Dillig, Thomas Dillig, Alex Aiken, and Mooly Sagiv. 2011\.  Precise and Compact Modular Procedure Summaries for Heap Manipulating Programs. In _Proceedings of the 32nd ACM SIGPLAN Conference on Programming Language Design and Implementation_ (San Jose, California, USA) _(PLDI ’11)_. Association for Computing Machinery, New York, NY, USA, 567–577.  https://doi.org/10.1145/1993498.1993565
  * Exchange (2022) Stack Exchange. 2022\.  Why are multiple programming languages used in the development of one product or piece of software?  https://softwareengineering.stackexchange.com/questions/370135/why-are-multiple-programming-languages-used-in-the-development-of-one-product-or/370146#370146
  * Feldthaus et al. (2013) Asger Feldthaus, Max Schäfer, Manu Sridharan, Julian Dolby, and Frank Tip. 2013.  Efficient Construction of Approximate Call Graphs for JavaScript IDE Services. In _ICSE_.  https://doi.org/10.1109/ICSE.2013.6606621
  * Fourtounis et al. (2020) George Fourtounis, Leonidas Triantafyllou, and Yannis Smaragdakis. 2020.  Identifying Java Calls in Native Code via Binary Scanning. Association for Computing Machinery, New York, NY, USA.  https://doi.org/10.1145/3395363.3397368
  * Grech et al. (2018) Neville Grech, George Kastrinis, and Yannis Smaragdakis. 2018\.  Efficient Reflection String Analysis via Graph Coloring. In _32nd European Conference on Object-Oriented Programming (ECOOP 2018)_ _(Leibniz International Proceedings in Informatics (LIPIcs), Vol. 109)_ , Todd Millstein (Ed.). Schloss Dagstuhl–Leibniz-Zentrum fuer Informatik, Dagstuhl, Germany, 26:1–26:25.  https://doi.org/10.4230/LIPIcs.ECOOP.2018.26
  * Grech and Smaragdakis (2017) Neville Grech and Yannis Smaragdakis. 2017.  P/Taint: Unified Points-to and Taint Analysis.  _Proc. ACM Program. Lang._ 1, OOPSLA, Article 102 (Oct. 2017), 28 pages.  https://doi.org/10.1145/3133926
  * Grichi et al. (2020) Manel Grichi, Ellis E. Eghan, and Bram Adams. 2020.  On the Impact of Multi-language Development in Machine Learning Frameworks. In _2020 IEEE International Conference on Software Maintenance and Evolution (ICSME)_. 546–556.  https://doi.org/10.1109/ICSME46990.2020.00058
  * Illous et al. (2020) Hugo Illous, Matthieu Lemerre, and Xavier Rival. 2020\.  Interprocedural Shape Analysis Using Separation Logic-Based Transformer Summaries. In _Static Analysis_ , David Pichardie and Mihaela Sighireanu (Eds.). Springer International Publishing, Cham, 248–273.
  * Khedker et al. (2007) Uday P. Khedker, Amitabha Sanyal, and Amey Karkare. 2007\.  Heap Reference Analysis Using Access Graphs.  _ACM Trans. Program. Lang. Syst._ 30, 1 (nov 2007), 1–es.  https://doi.org/10.1145/1290520.1290521
  * Kochhar et al. (2016) Pavneet Singh Kochhar, Dinusha Wijedasa, and David Lo. 2016\.  A Large Scale Study of Multiple Programming Languages and Code Quality. In _2016 IEEE 23rd International Conference on Software Analysis, Evolution, and Reengineering (SANER)_ , Vol. 1. 563–573.  https://doi.org/10.1109/SANER.2016.112
  * Kondoh and Onodera (2008) Goh Kondoh and Tamiya Onodera. 2008.  Finding Bugs in Java Native Interface Programs. In _Proceedings of the 2008 International Symposium on Software Testing and Analysis_ (Seattle, WA, USA) _(ISSTA ’08)_. Association for Computing Machinery, New York, NY, USA, 109–118.  https://doi.org/10.1145/1390630.1390645
  * Lee (2022) Sungho Lee. 2022\.  C-Summary Artifacts.  https://github.com/SunghoLee/c-summary
  * Lee et al. (2016) Sungho Lee, Julian Dolby, and Sukyoung Ryu. 2016.  HybriDroid: Static Analysis Framework for Android Hybrid Applications. In _Proceedings of the 31st IEEE/ACM International Conference on Automated Software Engineering_ (Singapore, Singapore) _(ASE 2016)_. Association for Computing Machinery, New York, NY, USA, 250–261.  https://doi.org/10.1145/2970276.2970368
  * Lee et al. (2020) Sungho Lee, Hyogun Lee, and Sukyoung Ryu. 2020.  Broadening Horizons of Multilingual Static Analysis: Semantic Summary Extraction from C Code for JNI Program Analysis. In _Proceedings of the 35th IEEE/ACM International Conference on Automated Software Engineering_ (Virtual Event, Australia) _(ASE ’20)_. Association for Computing Machinery, New York, NY, USA, 127–137.  https://doi.org/10.1145/3324884.3416558
  * Lee and Ryu (2019) Sungho Lee and Sukyoung Ryu. 2019.  _Adlib: Analyzer for Mobile Ad Platform Libraries_.  Association for Computing Machinery, New York, NY, USA, 262–272.  https://doi.org/10.1145/3293882.3330562
  * Lerch et al. (2015) Johannes Lerch, Johannes Späth, Eric Bodden, and Mira Mezini. 2015.  Access-Path Abstraction: Scaling Field-Sensitive Data-Flow Analysis with Unbounded Access Paths. In _Proceedings of the 30th IEEE/ACM International Conference on Automated Software Engineering_ (Lincoln, Nebraska) _(ASE ’15)_. IEEE Press, 619–629.  https://doi.org/10.1109/ASE.2015.9
  * Li et al. (2015) Li Li, Alexandre Bartel, Tegawendé F. Bissyandé, Jacques Klein, Yves Le Traon, Steven Arzt, Siegfried Rasthofer, Eric Bodden, Damien Octeau, and Patrick McDaniel. 2015\.  IccTA: Detecting Inter-Component Privacy Leaks in Android Apps. In _2015 IEEE/ACM 37th IEEE International Conference on Software Engineering_ , Vol. 1. 280–291.  https://doi.org/10.1109/ICSE.2015.48
  * Li and Tan (2011) Siliang Li and Gang Tan. 2011.  JET: Exception Checking in the Java Native Interface. In _Proceedings of the 2011 ACM International Conference on Object Oriented Programming Systems Languages and Applications_ (Portland, Oregon, USA) _(OOPSLA ’11)_. Association for Computing Machinery, New York, NY, USA, 345–358.  https://doi.org/10.1145/2048066.2048095
  * Li et al. (2021) Zengyang Li, Xiaoxiao Qi, Qinyi Yu, Peng Liang, Ran Mo, and Chen Yang. 2021\.  Multi-Programming-Language Commits in OSS: An Empirical Study on Apache Projects. In _2021 IEEE/ACM 29th International Conference on Program Comprehension (ICPC)_. 219–229.  https://doi.org/10.1109/ICPC52881.2021.00029
  * Milanova et al. (2005) Ana Milanova, Atanas Rountev, and Barbara G. Ryder. 2005\.  Parameterized Object Sensitivity for Points-to Analysis for Java.  _ACM Trans. Softw. Eng. Methodol._ 14, 1 (Jan. 2005), 1–41.  https://doi.org/10.1145/1044834.1044835
  * Monat et al. (2021) Raphaël Monat, Abdelraouf Ouadjaout, and Antoine Miné. 2021.  A Multilanguage Static Analysis of Python Programs with Native C Extensions. In _Static Analysis_ , Cezara Drăgoi, Suvam Mukherjee, and Kedar Namjoshi (Eds.). Springer International Publishing, Cham, 323–345.
  * Nielsen et al. (2021) Benjamin Barslev Nielsen, Martin Toldam Torp, and Anders Møller. 2021.  Modular Call Graph Construction for Security Scanning of Node.js Applications. In _Proc. 30th International Symposium on Software Testing and Analysis (ISSTA)_.
  * Prakash et al. (2021) Jyoti Prakash, Abhishek Tiwari, and Christian Hammer. 2021\.  Effects of Program Representation on Pointer Analyses — An Empirical Study. In _Fundamental Approaches to Software Engineering_ , Esther Guerra and Mariëlle Stoelinga (Eds.). Springer International Publishing, Cham, 240–261.
  * Samhi et al. (2021) Jordan Samhi, Jun Gao, Nadia Daoudi, Pierre Graux, Henri Hoyez, Xiaoyu Sun, Kevin Allix, Tegawendé F. Bissyandé, and Jacques Klein. 2021\.  JuCify: A Step Towards Android Code Unification for Enhanced Static Analysis.  arXiv:2112.10469 [cs.SE]
  * Schubert et al. (2021) Philipp Dominik Schubert, Ben Hermann, and Eric Bodden. 2021\.  Lossless, Persisted Summarization of Static Callgraph, Points-To and Data-Flow Analysis. In _35th European Conference on Object-Oriented Programming (ECOOP 2021)_ _(Leibniz International Proceedings in Informatics (LIPIcs), Vol. 194)_ , Anders Møller and Manu Sridharan (Eds.). Schloss Dagstuhl – Leibniz-Zentrum für Informatik, Dagstuhl, Germany, 2:1–2:31.  https://doi.org/10.4230/LIPIcs.ECOOP.2021.2
  * Siliang and Gang (2009) Li Siliang and Tan Gang. 2009.  Finding Bugs in Exceptional Situations of JNI Programs. In _Proceedings of the 16th ACM Conference on Computer and Communications Security_ (Chicago, Illinois, USA) _(CCS ’09)_. Association for Computing Machinery, New York, NY, USA, 442–452.  https://doi.org/10.1145/1653662.1653716
  * Späth et al. (2019) Johannes Späth, Karim Ali, and Eric Bodden. 2019\.  Context-, flow-, and field-sensitive data-flow analysis using synchronized Pushdown systems.  _Proc. ACM Program. Lang._ 3, POPL (2019), 48:1–48:29.  https://doi.org/10.1145/3290361
  * Späth et al. (2016) Johannes Späth, Lisa Nguyen Quang Do, Karim Ali, and Eric Bodden. 2016.  Boomerang: Demand-Driven Flow- and Context-Sensitive Pointer Analysis for Java. In _30th European Conference on Object-Oriented Programming (ECOOP 2016)_ _(Leibniz International Proceedings in Informatics (LIPIcs), Vol. 56)_ , Shriram Krishnamurthi and Benjamin S. Lerner (Eds.). Schloss Dagstuhl–Leibniz-Zentrum fuer Informatik, Dagstuhl, Germany, 22:1–22:26.  https://doi.org/10.4230/LIPIcs.ECOOP.2016.22
  * Sridharan et al. (2013) Manu Sridharan, Satish Chandra, Julian Dolby, Stephen J. Fink, and Eran Yahav. 2013.  _Alias Analysis for Object-Oriented Programs_.  Springer Berlin Heidelberg, Berlin, Heidelberg, 196–232.  https://doi.org/10.1007/978-3-642-36946-9_8
  * Sridharan and Fink (2009) Manu Sridharan and Stephen J. Fink. 2009.  The Complexity of Andersen’s Analysis in Practice. In _Static Analysis_ , Jens Palsberg and Zhendong Su (Eds.). Springer Berlin Heidelberg, Berlin, Heidelberg, 205–221.
  * Sui and Xue (2016) Yulei Sui and Jingling Xue. 2016.  SVF: Interprocedural Static Value-Flow Analysis in LLVM. In _Proceedings of the 25th International Conference on Compiler Construction_ (Barcelona, Spain) _(CC 2016)_. Association for Computing Machinery, New York, NY, USA, 265–266.  https://doi.org/10.1145/2892208.2892235
  * Sui et al. (2014) Yulei Sui, Ding Ye, and Jingling Xue. 2014.  Detecting memory leaks statically with full-sparse value-flow analysis.  _IEEE Transactions on Software Engineering_ 40, 2 (2014), 107–122.
  * Tiwari et al. (2019a) Abhishek Tiwari, Sascha Groß, and Christian Hammer. 2019a.  IIFA: Modular Inter-app Intent Information Flow Analysis of Android Applications. In _Security and Privacy in Communication Networks_ , Songqing Chen, Kim-Kwang Raymond Choo, Xinwen Fu, Wenjing Lou, and Aziz Mohaisen (Eds.). Springer International Publishing, Cham, 335–349.
  * Tiwari et al. (2019b) A. Tiwari, J. Prakash, S. GroB, and C. Hammer. 2019b.  LUDroid: A Large Scale Analysis of Android—Web Hybridization. In _2019 IEEE 19th International Working Conference on Source Code Analysis and Manipulation (SCAM)_. IEEE Computer Society, Los Alamitos, CA, USA, 256–267.  https://doi.org/10.1109/SCAM.2019.00036
  * Tiwari et al. (2020) Abhishek Tiwari, Jyoti Prakash, Sascha Groß, and Christian Hammer. 2020.  A Large Scale Analysis of Android — Web Hybridization.  _Journal of Systems and Software_ 170 (2020), 110775.  https://doi.org/10.1016/j.jss.2020.110775
  * Turcotte et al. (2019) Alexi Turcotte, Ellen Arteca, and Gregor Richards. 2019\.  Reasoning About Foreign Function Interfaces Without Modelling the Foreign Language. In _33rd European Conference on Object-Oriented Programming (ECOOP 2019)_ _(Leibniz International Proceedings in Informatics (LIPIcs), Vol. 134)_ , Alastair F. Donaldson (Ed.). Schloss Dagstuhl–Leibniz-Zentrum fuer Informatik, Dagstuhl, Germany, 16:1–16:32.  https://doi.org/10.4230/LIPIcs.ECOOP.2019.16
  * Wei et al. (2018a) Fengguo Wei, Xingwei Lin, Xinming Ou, Ting Chen, and Xiaosong Zhang. 2018a.  JN-SAF: Precise and Efficient NDK/JNI-Aware Inter-Language Static Analysis Framework for Security Vetting of Android Applications with Native Code. In _Proceedings of the 2018 ACM SIGSAC Conference on Computer and Communications Security_ (Toronto, Canada) _(CCS ’18)_. Association for Computing Machinery, New York, NY, USA, 1137–1150.  https://doi.org/10.1145/3243734.3243835
  * Wei et al. (2018b) Fengguo Wei, Sankardas Roy, Xinming Ou, and Robby. 2018b.  Amandroid: A Precise and General Inter-Component Data Flow Analysis Framework for Security Vetting of Android Apps.  _ACM Trans. Priv. Secur._ 21, 3, Article 14 (apr 2018), 32 pages.  https://doi.org/10.1145/3183575
  * Whaley and Rinard (1999) John Whaley and Martin Rinard. 1999.  Compositional Pointer and Escape Analysis for Java Programs. In _Proceedings of the 14th ACM SIGPLAN Conference on Object-Oriented Programming, Systems, Languages, and Applications_ (Denver, Colorado, USA) _(OOPSLA ’99)_. Association for Computing Machinery, New York, NY, USA, 187–206.  https://doi.org/10.1145/320384.320400