SEA: String Executability Analysis by Abstract Interpretation

TL;DR

SEA is an abstract interpretation framework that soundly analyzes string executability in dynamic languages with reflection, using finite automata to approximate dynamically generated code for improved static analysis accuracy.

Contribution

It introduces a novel abstract interpreter that combines program analysis with string executability analysis using finite automata, enabling sound analysis of self-modifying code.

Findings

Soundly approximates dynamically generated code structures

Efficient analysis of reflection and code generation in dynamic languages

Maintains soundness while handling self-modifying programs

Abstract

Dynamic languages often employ reflection primitives to turn dynamically generated text into executable code at run-time. These features make standard static analysis extremely hard if not impossible because its essential data structures, i.e., the control-flow graph and the system of recursive equations associated with the program to analyse, are themselves dynamically mutating objects. We introduce SEA, an abstract interpreter for automatic sound string executability analysis of dynamic languages employing bounded (i.e, finitely nested) reflection and dynamic code generation. Strings are statically approximated in an abstract domain of finite state automata with basic operations implemented as symbolic transducers. SEA combines standard program analysis together with string executability analysis. The analysis of a call to reflection determines a call to the same abstract interpreter over a code which is synthesised directly from the result of the static string executability analysis at that program point. The use of regular languages for approximating dynamically generated code structures allows SEA to soundly approximate safety properties of self modifying programs yet maintaining efficiency. Soundness here means that the semantics of the code synthesised by the analyser to resolve reflection over-approximates the semantics of the code dynamically built at run-rime by the program at that point.

Equations

$${\mathfrak{T}}_{{\mathcal{T}}(A)}(\mathbf{a})=\left\{\begin{array}[]{ll}\mathbf{a}&\mbox{if }\mathbf{a}\in\mathscr{L}(A)\\ \emptyset&\mbox{otherwise}\end{array}\right.$$

$${\mathfrak{T}}_1\diamond {\mathfrak{T}}_2\triangleq \lambda \mathbf{b}.\bigcup _{\mathbf{a}\in {\mathfrak{T}}_1(\mathbf{b})}{\mathfrak{T}}_2(\mathbf{a})$$

$$\mathrm{Exp}\ni \mathtt{e}$$

$$\mathrm{AExp}\ni \mathtt{a}$$

$$\mathtt{a}+\mathtt{a}\mid \mathtt{a}-\mathtt{a}\mid \mathtt{a}\ast \mathtt{a}(\text{mbox}wheren\in \mathbb{Z})$$

$$\mathrm{BExp}\ni \mathtt{b}$$

$$\mathrm{SExp}\ni \mathtt{s}$$

$$(\text{mbox}where\sigma \in \Sigma )$$

$$\mathrm{Comm}\ni \mathtt{c}$$

$$\text{while}b\{\mathtt{c}\};\mid \text{mbox}\mathbf{reflect}(\mathtt{s});\mid x:=\text{mbox}\mathbf{reflect}(\mathtt{s});$$

$$\mathrm{DImp}\ni \mathtt{P}$$

$$\mathsf{Id}\ni x$$

$$\mathsf{Int}{(}^{l.}\text{mbox}\mathbf{reflect}(\mathtt{s}){;}^{l^{\prime }.}\mathtt{Q},\text{m})$$

$${}^{1.}x:={}^{\prime }\text{mbox}\mathbf{reflect}(x);\text{mbox}{\$}^{\prime };{}^{2.}\text{mbox}\mathbf{reflect}(x);{}^{3.}\text{mbox}\$$$

$${\mathcal{F}}(\tt P,{\mathcal{I}})=\left\{\operatorname{\mathbb{c}}_{0}\operatorname{\mathbb{c}}_{1}\ldots\operatorname{\mathbb{c}}_{n}\left|\begin{array}[]{l}\operatorname{\mathbb{c}}_{0}\in{\mathcal{I}},\ \forall i<n.\;\operatorname{\mathbb{c}}_{i}\leadsto\operatorname{\mathbb{c}}_{i+1}\end{array}\right.\right\}$$

$$\begin{array}[]{ll}\mathtt{F}_{\tt P,{\mathcal{I}}}\triangleq&\lambda X.\>{\mathcal{I}}\>\cup\left\{\operatorname{\mathbb{c}}_{0}\operatorname{\mathbb{c}}_{1}\ldots\operatorname{\mathbb{c}}_{i}\operatorname{\mathbb{c}}_{i+1}\left|\begin{array}[]{l}\operatorname{\mathbb{c}}_{0}\operatorname{\mathbb{c}}_{1}\ldots\operatorname{\mathbb{c}}_{i}\in X\!\!\\ \operatorname{\mathbb{c}}_{i}\leadsto\operatorname{\mathbb{c}}_{i+1}\!\!\end{array}\right.\right\}\end{array}$$

$$\langle\!|\tt P|\!\rangle\operatorname{\mathbb{s}}\triangleq\left\{\operatorname{\mathbb{s}}\operatorname{\mathbb{s}}^{1}\ldots\operatorname{\mathbb{s}}^{n}\left|\begin{array}[]{l}\exists\operatorname{\mathbb{c}}_{0}\operatorname{\mathbb{c}}_{1}\ldots\operatorname{\mathbb{c}}_{n}\in{\mathcal{F}}(\tt P,\{\operatorname{\mathbb{s}}\}).\>\operatorname{\mathbb{c}}_{0}=\langle\tt P,\operatorname{\mathbb{s}}\rangle\\ \wedge\ \forall i\in[1,n].\>\exists\tt P_{i}\in\operatorname{\textsf{DImp}}.\>\operatorname{\mathbb{c}}_{i}=\langle\tt P_{i},\operatorname{\mathbb{s}}^{i}\rangle\end{array}\right.\right\}$$

$$\begin{array}[]{ll}\mathtt{F}^{\sharp}_{\tt P,{\mathcal{I}}^{\sharp}}\triangleq\lambda X.\>{\mathcal{I}}^{\sharp}\>\cup\left\{\operatorname{\mathbb{c}}_{0}^{\sharp}\ldots\operatorname{\mathbb{c}}_{i}^{\sharp}\operatorname{\mathbb{c}}_{i+1}^{\sharp}\left|\begin{array}[]{l}\operatorname{\mathbb{c}}_{0}^{\sharp}\ldots\operatorname{\mathbb{c}}_{i}^{\sharp}\in X,\ \operatorname{\mathbb{c}}_{i}^{\sharp}\leadsto^{\sharp}\operatorname{\mathbb{c}}_{i+1}^{\sharp}\!\!\end{array}\right.\right\}\end{array}$$

$$\mathsf{Str}\triangleq\left\{x\in(\Sigma\smallsetminus\{\mbox{\small$;,\{,\},\mbox{\tt\$}$}\})^{*}\left|\begin{array}[]{l}\exists\ \mbox{path}\ \pi\ \mbox{in}\ \mathtt{T_{A}}\ \mbox{such that}\\ x\ \mbox{ maximal substring of}\ \pi\end{array}\right.\right\}.$$

$$\operatorname{\textsf{DImp}}^{-}\triangleq\left\{\begin{array}[]{l}\mbox{\bf skip};,x:={\tt e};,\textbf{if}~{}{\tt b}~{}\{,\textbf{while}~{}{\tt b}~{}\{,\\ \mbox{\bf reflect}({\tt s});,x:=\mbox{\bf reflect}({\tt s});,\},\mbox{\tt\$}\end{array}\right\}$$

$$\mathtt{Tokens}\triangleq\left\{\begin{array}[]{l}\texttt{id},\texttt{const}_{{\tt s}},\texttt{const}_{{\tt a}},\texttt{const}_{{\tt b}},\texttt{aop},\texttt{bop},\texttt{uop},\\ \texttt{num},\texttt{len},\texttt{conc}_{\delta},\texttt{substr},\texttt{relop},\texttt{if},\texttt{while},\\ \texttt{assign},\texttt{skip},\texttt{reflect},\texttt{rand}\end{array}\right\}$$

$${\mathfrak{T}}_{\mathtt{Lex}}(\mathbf{a})\triangleq\left\{\begin{array}[]{ll}\mathbf{a}^{0}\texttt{T}^{0}\texttt{p}^{0}\mathbf{a}^{1}\texttt{T}^{1}\texttt{p}^{1}\dots\mathbf{a}^{n}\texttt{T}^{n}\texttt{p}^{n}&\mbox{if }\mathbf{a}=\mathbf{a}^{0}\cdot\mathbf{a}^{1}\cdot...\cdot\mathbf{a}^{n}\in\Sigma^{\ast}\\ &\forall i\in[0,n]:\,\mathbf{a}^{i}\in\mathscr{L}(T_{\texttt{T}^{i}}),\\ &\texttt{T}_{i}\in\mathtt{Tokens},\texttt{p}^{i}\in\mathfrak{P}^{\ast}\\ \emptyset&\mbox{otherwise}\\ \end{array}\right.$$

$$\begin{array}[]{rl}\lbag{\tt d}\rbag=&{\tt d}_{;}\mbox{ if }{\tt d}\in\operatorname{\textsf{DImp}}^{-}\\ \lbag{\tt r}\mbox{\tt\$}\rbag=&\lbag{\tt r}\rbag;\\ \vspace{.1cm}\lbag{\tt r}_{1}{\tt r}_{2}\rbag=&\lbag{\tt r}_{1}\!\rbag;\lbag{\tt r}_{2}\rbag;\\ \vspace{.1cm}\lbag\textbf{\large(}{\tt r}\textbf{\large)}^{*}\rbag=&\left[\begin{array}[]{l}g:=\mbox{\bf rand}();\\ \mbox{\bf while}\ g=1\ \{\lbag{\tt r}\rbag;g:=\mbox{\bf rand}();\};\end{array}\right.\\ \vspace{.0cm}\lbag{\tt r}_{1}\textbf{\large+}{\tt r}_{2}\rbag=&\left[\begin{array}[]{l}g:=\mbox{\bf rand}();\\ \textbf{if }g=1\,\{\lbag{\tt r}_{1}\rbag;\};\textbf{if }g=2\,\{\lbag{\tt r}_{2}\rbag;\};\end{array}\right.\end{array}$$

$$\begin{array}[]{l}\forall{\tt c}\in{\llparenthesis\hskip 0.77498pt{\tt s}\hskip 0.77498pt\rrparenthesis}\operatorname{\mathbb{s}}_{l}\cap\overline{\operatorname{\textsf{DImp}}}.\\ \langle\!|{\tt c}|\!\rangle\operatorname{\mathbb{s}}^{\prime}\subseteq\langle\!|\mathtt{ProgSyn}(\mathtt{Regex}(\mathtt{Lex}\diamond\mathtt{Parser}(\mathtt{StmSyn}(\mathtt{A}_{{\tt s}}^{l}))))|\!\rangle\operatorname{\mathbb{s}}^{\prime}.\end{array}$$

Full text

††thanks: Email: \normalshapevincenzo.arceri@univr.it††thanks: Email: \normalshapemila.dallapreda@univr.it††thanks: Email: \normalshaperoberto.giacobazzi@univr.it††thanks: Email: \normalshapeisabella.mastroeni@univr.it

1 Introduction

Motivation.

The possibility of dynamically build code instructions as the result of text manipulation is a key aspect in dynamic programming languages. With reflection, programs can turn text, which can be built at run-time, into executable code [32]. These features are often used in code protection and tamper resistant applications, employing camouflage for escaping attack or detection [29], in malware, in mobile code, in web servers, in code compression, and in code optimisation, e.g., in Just-in-Time (JIT) compilers employing optimised run-time code generation.

While the use of dynamic code generation may simplify considerably the art and performance of programming, this practice is also highly dangerous, making the code prone to unexpected behaviour and malicious exploits of its dynamic vulnerabilities, such as code/object-injection attacks for privilege escalation, data-base corruption, and malware propagation. It is clear that more advanced and secure functionalities based on reflection could be permitted if we better master how to safely generate, analyse, debug, and deploy programs that dynamically generate and manipulate code.

There are lots of good reasons to analyse when a program builds strings that can be later executed as code. Consider the code in Fig. 1. This is a template of a ransomware that calls a method (“open”) by manipulating an obfuscated string which is built in the code. Analysing the flow of the strings corresponds here to approximate the set of strings that may be turned into code at run-time. This possibility would provide important benefits in the analysis of dynamic languages, without ignoring reflection, in automated deobfuscation of dynamic obfuscators, and in the analysis of code injection and XSS attacks.

The problem.

A major problem in dynamic code generation is that static analysis becomes extremely hard if not even impossible. This because program’s essential data structures, such as the control-flow graph and the system of recursive equations associated with the program to analyse, are themselves dynamically mutating objects. In a sentence: ”You can’t check code you don’t see” [5].

The standard way for treating dynamic code generation in programming is to prevent or even banish it, therefore restricting the expressivity of our development tools. Other approaches instead tries to combine static and dynamic analysis to predict the code structures dynamically generated [41, 7]. Because of this difficulty, most analyses of dynamic languages do not consider reflection [3], thus being inherently unsound for these languages, or implement ad-hoc or pattern driven transformations in order to remove reflection [26]. The design and implementation of a sound static analyser for self mutating programs is still nowadays an open challenge for static program analysis.

Contribution.

In this paper we solve this problem by treating the code as any other dynamic structure that can be statically analysed by abstract interpretation [13]. We introduce SEA, a proof of concept for a fully automatic sound-by-construction abstract interpreter for string executability analysis of dynamic languages employing finitely nested (bounded) reflection and dynamic code generation. SEA carries a generic standard numerical analysis, in our case a well-known interval analysis, together with a new string executability analysis. Strings are approximated in an abstract domain of finite state automata (FA) with basic operations implemented as symbolic transducers and widening for enforcing termination.

The idea in SEA is to re-factor reflection into a program whose semantics is a sound over-approximation of the semantics of the dynamically generated code. This allows us to continue with the standard analysis when the reflection is called on an argument that evaluates to code. In order to recognise whether approximated strings correspond to executable instructions, we approximate a parser as a symbolic transducer and, in case of success, we synthesise a program from the FA approximation of the computed string. The static analysis of reflection determines a call to the same abstract interpreter over the code synthesised from the result of the static string executability analysis at that program point. The choice of regular languages for approximating code structures provides efficient implementations of both the analysis and the code generation at analysis time. The synthesised program reflects most of the structures of the code dynamically generated, yet loosing some aspects such as the number of iterations of loops.

Soundness here means that, if the approximated code extracted by the abstract interpreter is accepted by the parser, then the program may dynamically generate executable code at run-time. Moreover, because of the approximation of dynamically generated code structures in a regular language of instructions, any sound and terminating abstract interpretation for safety (i.e., prefix closed) properties of the synthesised code, over-approximates the concrete semantics of the dynamically generated code. This means that a sound over-approximation of the concrete semantics of programs dynamically generating and executing code by reflection is possible for safety properties by combining string analysis and code synthesis in abstract interpretation. Even if nested reflection is not a common practice, the case of potentially unbound nested reflections, which may lead to non termination the analysis, can be handled as in [26] by fixing a maximal degree of nesting allowed. In this case, for programs exceeding the maximal degree of nested reflections, we may lose soundness. We briefly discuss how in SEA we may achieve an always sound analysis also for unbound reflection based on a widening with threshold over the recursive applications of the abstract interpreter.

2 Related Works

The analysis of strings is nowadays a relatively common practice in program analysis due to the widespread use of dynamic scripting languages. Examples of analyses for string manipulation are in [20, 10, 40, 34, 30, 28]. The use of symbolic (grammar-based) objects in abstract domains is also not new (see [15, 23, 36]) and some works explicitly use transducers for string analysis in script sanitisation, see for instance [25] and [40], all recognising that specifying the analysis in terms of abstract interpretation makes it suitable for being combined with other analyses, with a better potential in terms of tuning in accuracy and costs. None of these works use string analysis for analysing executability of dynamically generated code. In [26], the authors introduce an automatic code rewriting techniques removing eval constructs in JavaScript applications. This work has been inspired by the work of Richards et al. [32] showing that eval is widely used, nevertheless in many cases its use can be simply replaced by JavaScript code without eval. In [26] the authors integrate a refactoring of the calls to eval into the TAJS data-flow analyzer. TAJS performs inter-procedural data-flow analysis on an abstract domain of objects capturing whether expressions evaluate to constant values. In this case eval calls can be replaced with an alternative code that does not use eval. It is clear that code refactoring is possible only when the abstract analysis recognises that the arguments of the eval call are constants. Moreover, they handle the presence of nested eval by fixing a maximal degree of nesting, but in practice they set this degree to $1$, since, as they claim, it is not often encountered in practice. The solution we propose allows us to go beyond constant values and refactor code also when then arguments of eval are elements of a regular language of strings. While this can be safely used for analysing safety properties of dynamically generated code, the use of our method for code refactoring has to take into account non-terminating code introduced by widening and regular language approximation. A more detailed comparison with TAJS is discussed in Sect. 7.

Static analysis for a static subset of PHP (i.e., ignoring eval-like primitives) has been developed in [6]. Static taint analysis keeping track of values derived from user inputs has been developed for self-modifying code by partial derivation of the Control-Flow-Graph [38]. The approach is limited to taint analysis, e.g., for limiting code-injection attacks. Staged information flow for JavaScript in [11] with holes provides a conditional (a la abduction analysis in [22]) static analysis of dynamically evaluated code. Symbolic execution-based static analyses have been developed for scripting languages, e.g., PHP, including primitives for code reflection, still at the price of introducing false negatives [39].

We are not aware of effective general purpose sound static analyses handling self-modifying code for high-level scripting languages. On the contrary, a huge effort was devoted to bring static type inference to object-oriented dynamic languages (e.g., see [3] for an account in Ruby) but with a different perspective: Bring into dynamic languages the benefits of static ones – well-typed programs don’t go wrong. Our approach is different: Bring into static analysis the possibility of handling dynamically mutating code. A similar approach is in [4] and [16] for binary executables. The idea is that of extracting a code representation which is descriptive enough to include most code mutations by a dynamic analysis, and then reform analysis on a linearization of this code. On the semantics side, since the pioneering work on certifying self-modifying code in [9], the approach to self-modifying code consists in treating machine instructions as regular mutable data structures, and to incorporate a logic dealing with code mutation within a la Hoare logics for program verification. TamiFlex [7] also synthesises a program at every eval call by considering the code that has been executed during some (dynamically) observed execution traces. The static analysis can then proceed with the so obtained code without eval. It is sound only with respect to the considered execution traces, producing a warning otherwise.

3 Preliminaries

Mathematical Notation.

$S^{*}$ is the set of all finite sequences of elements in $S$. We often use bold letters to denote them. If $\mathbf{s}=s_{1}\dots s_{n}\in S^{\ast}$, $s_{i}\in S$ is the $i$-th element and $|\mathbf{s}|\in\mathbb{N}$ its length. If $\mathbf{s}_{1},\mathbf{s}_{2}\in\Sigma^{\ast}$, $\mathbf{s}_{1}\cdot\mathbf{s}_{2}\in\Sigma^{\ast}$ is their concatenation.

A set $L$ with ordering relation $\leq$ is a poset and it is denoted as $\langle L,\leq\rangle$. Lattices $L$ with ordering $\leq$, least upper bound (lub) $\vee$, greatest lower bound (glb) $\wedge$, greatest element (top) $\top$, and least element (bottom) $\bot$ are denoted $\langle L,\leq,\vee,\wedge,\top,\bot\rangle$. Given f:S\mbox{\raisebox{0.0pt}[4.30554pt][4.30554pt]{\mathrel{\mathop{\hskip 1.0pt\longrightarrow\hskip 1.0pt}\limits^{,{}{\mbox{\tiny}}}}}}T and g:T\mbox{\raisebox{0.0pt}[4.30554pt][4.30554pt]{\mathrel{\mathop{\hskip 1.0pt\longrightarrow\hskip 1.0pt}\limits^{,{}{\mbox{\tiny}}}}}}Q we denote with g\circ f:S\mbox{\raisebox{0.0pt}[4.30554pt][4.30554pt]{\mathrel{\mathop{\hskip 1.0pt\longrightarrow\hskip 1.0pt}\limits^{,{}{\mbox{\tiny}}}}}}Q their composition, *i.e., *$g\circ f=\lambda x.g(f(x))$. For f,g:L\mbox{\raisebox{0.0pt}[4.30554pt][4.30554pt]{\mathrel{\mathop{\hskip 1.0pt\longrightarrow\hskip 1.0pt}\limits^{,{}{\mbox{\tiny}}}}}}D on complete lattices $f\sqcup g$ denotes the point-wise least upper bound, *i.e., *$f\sqcup g=\lambda x.f(x)\vee g(x)$. $f$ is additive (co-additive) if for any $Y\subseteq L,f(\vee_{L}Y)=\vee_{D}f(Y)$ ($f(\wedge_{L}Y)=\wedge_{D}f(Y))$. The additive lift of a function f:L\mbox{\raisebox{0.0pt}[4.30554pt][4.30554pt]{\mathrel{\mathop{\hskip 1.0pt\longrightarrow\hskip 1.0pt}\limits^{,{}{\mbox{\tiny}}}}}}D is the function \lambda X\subseteq L.\;\{f(x)~{}|~{}x\in X\}\in\wp(L)\mbox{\raisebox{0.0pt}[4.30554pt][4.30554pt]{\mathrel{\mathop{\hskip 1.0pt\longrightarrow\hskip 1.0pt}\limits^{,{}{\mbox{\tiny}}}}}}\wp(D). We will often identify a function and its additive lift. Continuity holds when $f$ preserves lubs’s of chains. For a continuous function $f$: ${\sf lfp\/}(f)=\bigwedge\{x~{}|~{}x=f(x)\}=\bigvee_{n\in{\rm Nature}}f^{n}(\bot)$ where $f^{0}(\bot)=\bot$ and $f^{n+1}(\bot)=f(f^{n}(\bot))$.

Abstract Interpretation.

Abstract interpretation establishes a correspondence between a concrete semantics and an approximated one called abstract semantics [13, 14]. In a Galois Connection (GC) framework, if $C$ and $A$ are complete lattices, a pair of monotone functions \alpha:C\mbox{\raisebox{0.0pt}[4.30554pt][4.30554pt]{\mathrel{\mathop{\hskip 1.0pt\longrightarrow\hskip 1.0pt}\limits^{,{}{\mbox{\tiny}}}}}}A and \gamma:A\mbox{\raisebox{0.0pt}[4.30554pt][4.30554pt]{\mathrel{\mathop{\hskip 1.0pt\longrightarrow\hskip 1.0pt}\limits^{,{}{\mbox{\tiny}}}}}}C forms a GC between $C$ and $A$ if for every $x\in C$ and $y\in A$ we have $\alpha(x)\leq_{A}y\Leftrightarrow x\leq_{C}\gamma(y)$. $\alpha$ (resp. $\gamma$) is the abstraction (resp. concretisation) and it is additive (resp. co-additive). Weaker forms of correspondence are possible, e.g., when $A$ is not a complete lattice or when only $\gamma$ exists. In all cases, relative precision in $A$ is given by comparing the meaning of abstract objects in $C$, i.e., $x_{1}\leq_{A}x_{2}$ if $\gamma(x_{1})\leq_{C}\gamma(x_{2})$. If f:C\mbox{\raisebox{0.0pt}[4.30554pt][4.30554pt]{\mathrel{\mathop{\hskip 1.0pt\longrightarrow\hskip 1.0pt}\limits^{,{}{\mbox{\tiny}}}}}}C is a continuous function and $A$ is an abstraction of $C$ by means of the GC $\langle\alpha,\gamma\rangle$, then $f$ always has a best correct approximation in $A$, $f^{A}:A\longrightarrow A$, defined as $f^{A}\triangleq\alpha\circ f\circ\gamma$. Any approximation f^{\sharp}:A\mbox{\raisebox{0.0pt}[4.30554pt][4.30554pt]{\mathrel{\mathop{\hskip 1.0pt\longrightarrow\hskip 1.0pt}\limits^{,{}{\mbox{\tiny}}}}}}A of $f$ in $A$ is sound if $f^{A}\sqsubseteq f^{\sharp}$. In this case we have the fix-point soundness $\alpha({\sf lfp\/}f)\leq{\sf lfp\/}(f^{A})\leq{\sf lfp\/}(f^{\sharp})$ (cf. [13]). $A$ satisfies the ascending chain condition (ACC) if all ascending chains are finite. When $A$ is not ACC or when it lacks the limits of chains, convergence to the limit of the fix-point iterations can be ensured through widening operators. A widening operator $\triangledown:A\times A\rightarrow A$ approximates the lub, i.e., $\forall x,y\in A.x,y\leq_{A}(x\triangledown y)$ and it is such that for any increasing chain $x_{1}\leq x_{2}\leq\dots\leq x_{n}\leq\dots$ the increasing chain $w^{0}=\bot$ and $w^{i+1}=w^{i}\triangledown x_{i}$ is finite.

Finite State Automata (FA).

A FA $A$ is a tuple $(Q,\delta,q_{0},F,\Sigma)$, where $Q$ is the set of states, $\delta\subseteq Q\times\Sigma\times Q$ is the transition relation, $q_{0}\in Q$ is the initial state, $F\subseteq Q$ is the set of final states and $\Sigma$ is the finite alphabet of symbols. An element $(q,\sigma,q^{\prime})\in\delta$ is called transition and is denoted $q^{\prime}\in\delta(q,\sigma)$. Let $\omega\in\Sigma^{\ast}$, $\hat{\delta}:Q\times\Sigma^{\ast}\rightarrow\wp(Q)$ is the transitive closure of $\delta$: $\hat{\delta}(q,\epsilon)=\{q\}$ and $\hat{\delta}(q,\omega\sigma)=\bigcup_{q^{\prime}\in\hat{\delta}(q,\omega)}\delta(q^{\prime},\sigma)$. $\omega\in\Sigma^{\ast}$ is accepted by $A$ if $\hat{\delta}(q_{0},\omega)\cap F\neq\varnothing$. The set of all these strings defines the language $\mathscr{L}(A)$ accepted by $A$. Given an FA $A$ and a partition $\pi$ over its states, we denote as $A/\pi=(Q^{\prime},\delta^{\prime},q_{0}^{\prime},F^{\prime},\Sigma)$ the quotient automaton [19].

Symbolic Finite Transducers (SFT).

We follow [35] in the definition of SFTs and of their background structure. Consider a background universe ${\mathcal{U}}_{\tau}$ of elements of type $\tau$, we denote with $\mathbb{B}$ to denote the elements of boolean type. Terms and formulas are defined by induction over the background language and are well-typed. Terms of type $\mathbb{B}$ are treated as formulas. $t:\tau$ denotes a term $t$ of type $\tau$, and $\mathit{FV}(t)$ denotes the set of its free variables. A term $t:\tau$ is closed when $\mathit{FV}(t)=\emptyset$. Closed terms have semantics $\llbracket t\rrbracket$. As usual $t[x/v]$ denotes the substitution of a variable $x:\tau$ with a term $v:\tau$. A $\lambda$-term $f$ is an expression of the form $\lambda x.t$ where $x:\tau^{\prime}$ is a variable and $t:\tau^{\prime\prime}$ is a term such that $\mathit{FV}(t)\subseteq\{x\}$. The $\lambda$-term $f$ has type $\tau^{\prime}\rightarrow\tau^{\prime\prime}$ and its semantics is a function $\llbracket f\rrbracket:{\mathcal{U}}_{\tau^{\prime}}\rightarrow{\mathcal{U}}_{\tau^{\prime\prime}}$ that maps $a\in{\mathcal{U}}_{\tau^{\prime}}$ to $\llbracket t[x/a]\rrbracket\in{\mathcal{U}}_{\tau^{\prime\prime}}$. Let $f$ and $g$ range over $\lambda$-terms. A $\lambda$-term of type $\tau\rightarrow\mathbb{B}$ is called a $\tau$-predicate. Given a $\tau$-predicate $\varphi$, we write $a\in\llbracket\varphi\rrbracket$ for $\llbracket\varphi\rrbracket(a)=\mathit{true}$. Moreover, $\llbracket\varphi\rrbracket$ can be seen as the subset of ${\mathcal{U}}_{\tau}$ that satisfies $\varphi$. $\varphi$ is unsatisfiable when $\llbracket\varphi\rrbracket=\emptyset$ and satisfiable otherwise. A label theory [35] for $\tau^{\prime}\rightarrow\tau^{\prime\prime}$ is associated with an effectively enumerable set of $\lambda$-terms of type $\tau^{\prime}\rightarrow\tau^{\prime\prime}$ and an effectively enumerable set of $\tau^{\prime}$-predicates that is effectively closed under Boolean operations and relative difference, i.e., $\llbracket\varphi\wedge\psi\rrbracket=\llbracket\varphi\rrbracket\cap\llbracket\psi\rrbracket$, and $\llbracket\neg\varphi\rrbracket={\mathcal{U}}_{\tau^{\prime}}\smallsetminus\llbracket\varphi\rrbracket$. Let $\tau^{\ast}$ be the type of sequences of elements of type $\tau$. A Symbolic Finite Transducer [35] (SFT) $T$ over $\tau^{\prime}\rightarrow\tau^{\prime\prime}$ is a tuple $T=\langle Q,q^{0},F,R\rangle$, where $Q$ is a finite set of states, $q^{0}\in Q$ is the initial state, $F\subseteq Q$ is the set of final states and $R$ is a set of rules $(p,\varphi,\mathbf{f},q)$ where $p,q\in Q$, $\varphi$ is a $\tau^{\prime}$-predicate and $\mathbf{f}$ is a sequence of $\lambda$-terms over a given label theory for $\tau^{\prime}\rightarrow\tau^{\prime\prime}$. A rule $(p,\varphi,\mathbf{f},q)$ of an SFT $T$ is denoted as $p\stackrel{{\scriptstyle\varphi/\mathbf{f}}}{{\longrightarrow}}q$. The sequence of $\lambda$-terms $\mathbf{f}:(\tau^{\prime}\rightarrow\tau^{\prime\prime})^{\ast}$ can be treated as a function $\lambda x.[\mathbf{f}_{0}(x),\dots,\mathbf{f}_{k}(x)]$ where $k=|\mathbf{f}|-1$. Concrete transitions are represented as rules. Let $p,q\in Q$, $a\in{\mathcal{U}}_{\tau^{\prime}}$ and $\mathbf{b}\in{\mathcal{U}}_{\tau^{\prime\prime}}^{\ast}$ then: $\stackrel{{\scriptstyle a/\mathbf{b}}}{{\longrightarrow_{T}}}q\;\Leftrightarrow\;p\stackrel{{\scriptstyle\varphi/\mathbf{f}}}{{\longrightarrow_{T}}}q\in R:a\in\llbracket\varphi\rrbracket\,\wedge\,\mathbf{b}=\llbracket\mathbf{f}\rrbracket(a)$ Given two sequences $\mathbf{a}\in{\mathcal{U}}_{\tau^{\prime}}^{\ast}$ and $\mathbf{b}\in{\mathcal{U}}_{\tau^{\prime\prime}}^{\ast}$, we write $q\stackrel{{\scriptstyle\mathbf{a}/\mathbf{b}}}{{\twoheadrightarrow}}p$ when there exists a path of transitions from $q$ to $p$ in $T$ with input sequence $\mathbf{a}=\mathbf{a}_{0}\mathbf{a}_{1}\cdots\mathbf{a}_{n}$ and output sequence $\mathbf{b}=\mathbf{b}^{0}\mathbf{b}^{1}\cdots\mathbf{b}^{n}$, $n=|\mathbf{a}|-1$ and $\mathbf{b}^{i}$ denoting a subsequence of $\mathbf{b}$, such that: $p=p_{0}\stackrel{{\scriptstyle\mathbf{a}_{0}/\mathbf{b}^{0}}}{{\longrightarrow}}p_{1}\stackrel{{\scriptstyle\mathbf{a}_{1}/\mathbf{b}^{1}}}{{\longrightarrow}}p_{2}\dots p_{n}\stackrel{{\scriptstyle\mathbf{a}_{n}/\mathbf{b}^{n}}}{{\longrightarrow}}p_{n+1}=q$. SFT can have $\varepsilon$-transitions and they can be eliminated following a standard procedure. We assume $p\stackrel{{\scriptstyle\varepsilon/\varepsilon}}{{\longrightarrow}}p$ for all $p\in Q$. The transduction of an SFT $T$ [35] over $\tau^{\prime}\rightarrow\tau^{\prime\prime}$ is a function ${\mathfrak{T}}_{T}:{\mathcal{U}}_{\tau^{\prime}}^{\ast}\rightarrow\wp({\mathcal{U}}_{\tau^{\prime\prime}}^{\ast})$ where: ${\mathfrak{T}}_{T}(\mathbf{a})\triangleq\{\mathbf{b}\in{\mathcal{U}}_{\tau^{\prime\prime}}^{\ast}~{}|~{}\exists q\in F:q^{0}\stackrel{{\scriptstyle\mathbf{a}/\mathbf{b}}}{{\twoheadrightarrow}}q\}$

SFT as FA Transformers.

In the following, we will consider SFTs producing only one symbol in output for each symbol read in input. Namely, we consider SFTs with rules $(q,\varphi,f,q)$ where $f$ is a single $\lambda$-term of type $\tau^{\prime}\rightarrow\tau^{\prime\prime}$. Moreover, we consider SFTs and FA over finite alphabets, where the symbolic representation of SFT is useful for having more compact language transformers.

In this section we show how, under these assumptions, SFTs can be seen as FA transformers. In particular, given an FA $A$ such that $\mathscr{L}(A)\in\wp({\mathcal{U}}^{\ast}_{\tau^{\prime}})$ and an SFT $T$ over $\tau^{\prime}\rightarrow\tau^{\prime\prime}$, we want to build the FA recognizing the language of strings in ${\mathcal{U}}_{\tau^{\prime\prime}}^{\ast}$ obtained by modifying the strings in $\mathscr{L}(A)$, according to the SFT $T$. To this end, we define the input language \mbox{\hbox{\mathscr{L}}{}{{\mathcal{I}}}}(T) of an SFT $T$ as the set of strings producing an output when processed by $T$, and the output language \mbox{\hbox{\mathscr{L}}{}{{\mathcal{O}}}}(T) as the set of strings generated by $T$. Formally: \mbox{\hbox{\mathscr{L}}{}{{\mathcal{I}}}}(T)\triangleq\{\mathbf{a}\in{\mathcal{U}}_{\tau^{\prime}}^{\ast}~{}|~{}{\mathfrak{T}}_{T}(\mathbf{a})\neq\emptyset\} and \mbox{\hbox{\mathscr{L}}{}{{\mathcal{O}}}}(T)\triangleq\{\mathbf{b}\in{\mathcal{U}}_{\tau^{\prime\prime}}^{\ast}~{}|~{}\mathbf{b}\in{\mathfrak{T}}_{T}(\mathbf{a}),\mathbf{a}\in\mbox{\hbox{\mathscr{L}}{}_{{\mathcal{I}}}}(T)\}.

Consider $T=\langle Q,q^{0},F,R\rangle$ over $\tau^{\prime}\rightarrow\tau^{\prime\prime}$, with ${\mathcal{U}}_{\tau^{\prime}}$ and ${\mathcal{U}}_{\tau^{\prime\prime}}$ finite alphabets, and rules $(q,\varphi,f,p)\in R$ such that $f$ are $\lambda$-terms of type $\tau^{\prime}\rightarrow\tau^{\prime\prime}$. According to [17] it is possible to build an FA \mbox{\sc fa{}{{\mathcal{O}}}}(T) recognising the output language of $T$, i.e., \mathscr{L}(\mbox{\sc fa{}{{\mathcal{O}}}}(T))=\mbox{\hbox{\mathscr{L}}{}{{\mathcal{O}}}}(T). In particular, \mbox{\sc fa{}{{\mathcal{O}}}}(T)\triangleq(Q,\delta,q_{0},F,{\mathcal{U}}_{\tau^{\prime\prime}}) where $\delta=\{(q,b,p)~{}|~{}(q,\varphi,f,p)\in R,b\in\llbracket f(\varphi)\rrbracket\}$. Observe that $\llbracket f(\varphi)\rrbracket$ is finite since $\varphi$ is a predicate over a finite alphabet. We can associate an SFT ${\mathcal{T}}(A)$ to an FA $A$, where the input and output languages of ${\mathcal{T}}(A)$ are the ones recognized by the FA $A$. Formally, given an FA $A=(Q,\delta,q_{0},F,{\mathcal{U}}_{\tau})$, we define the output SFT over $\tau\rightarrow\tau$ as ${\mathcal{T}}(A)\triangleq\langle Q,q_{0},F,R^{\texttt{id}}\rangle$ where $R^{\texttt{id}}\triangleq\{(p,\sigma,\mathit{id},q)~{}|~{}(p,\sigma,q)\in\delta\}$111We denote by $\sigma$ the predicate requiring the symbol to be equal to $\sigma$. and the transduction is:

[TABLE]

These definitions allow us to associate FAs with SFTs and vice-versa and. According to [35], we define the composition of two transductions ${\mathfrak{T}}_{1}$ and ${\mathfrak{T}}_{2}$ as:

[TABLE]

Observe that the composition $\diamond$ applies first ${\mathfrak{T}}_{1}$ and then ${\mathfrak{T}}_{2}$. It has been proved that if $T_{1}$ and $T_{2}$ are SFTs over composable label theories, then there exists an SFT $T_{1}\diamond T_{2}$ that is obtained effectively from $T_{1}$ and $T_{2}$ such that ${\mathfrak{T}}_{T_{1}\diamond T_{2}}={\mathfrak{T}}_{1}\diamond{\mathfrak{T}}_{2}$ (see [35, 24] for details). At this point, given an FA $A$ with $\mathscr{L}(A)\in\wp({\mathcal{U}}_{\tau^{\prime}}^{\ast})$ and an SFT $T$ over $\tau^{\prime}\rightarrow\tau^{\prime\prime}$, we can model the application of $T$ to $\mathscr{L}(A)$ as the composition ${\mathcal{T}}(A)\diamond T$ where the language recognized by the FA $A$ becomes the input language of the SFT $T$. ${\mathfrak{T}}_{{\mathcal{T}}(A)\diamond T}={\mathfrak{T}}_{T}(\mathbf{b})$ if $\mathbf{b}\in\mathscr{L}(A)$, it is $\emptyset$ otherwise. Observe that, the FA recognizing the output language of ${\mathcal{T}}(A)\diamond T$ is the FA obtained by transforming $A$ with $T$. Indeed, \mathscr{L}(\mbox{\sc fa{}{{\mathcal{O}}}}({\mathcal{T}}(A)\diamond T))=\{\mathbf{b}\in\Gamma^{\ast}~{}|~{}\mathbf{b}\in{\mathfrak{T}}_{T}(\mathbf{a}),\mathbf{a}\in\mathscr{L}(A)\}. Thus, we can say that an SFT $T$ transforms an FA $A$ into the FA \mbox{\sc fa{}{{\mathcal{O}}}}({\mathcal{T}}(A)\diamond T).

4 A Core Dynamic Programming Language

4.1 The dynamic language

We introduce a core imperative deterministic dynamic language $\operatorname{\textsf{DImp}}$, in the style of Imp for its imperative fragment and of dynamic languages, such as PHP or JavaScript, as far as string manipulation is concerned, with basic types integers in ${\mathbb{Z}}$, booleans, and strings of symbols over a finite alphabet $\Sigma$. Programs $\tt P$ are labeled commands in $\operatorname{\textsf{DImp}}$ built as in Figure 2, on a set of variables Var and line of code labels $\operatorname{\textsf{PLines}}_{\tt P}$ with typical elements $l\in\operatorname{\textsf{PLines}}_{\tt P}$.

We assume that all terminal and non terminal symbols of $\operatorname{\textsf{DImp}}$ are in $\Sigma_{\operatorname{\textsf{DImp}}}\subseteq\Sigma^{*}$. Thus, the language recognized by the context free grammar (CFG) of $\operatorname{\textsf{DImp}}$ is an element of $\wp((\Sigma_{\operatorname{\textsf{DImp}}})^{\ast})$, i.e., $\operatorname{\textsf{DImp}}\subseteq(\Sigma_{\operatorname{\textsf{DImp}}})^{\ast}$. Given $\tt P\in\operatorname{\textsf{DImp}}$ we associate with each statement a program line $l\in\operatorname{\textsf{PLines}}_{\tt P}$. In order to simplify the presentation of the semantics, we suppose that any program is ended by a termination symbol $, labeled with the last program line denoted$l_{e}$. When a statement${\tt c}$belongs to a program$\tt P$we write${\tt c}\in\tt P$, then we define the auxiliary functions$\mbox{\sf Stm${}_{\tiny\tt P}$}:\operatorname{\textsf{PLines}}{\tt P}\rightarrow\operatorname{\textsf{DImp}}$be such that$\mbox{\sf Stm${}_{\tiny\tt P}$}(l)={\tt c}$if${\tt c}$is the statement in$\tt P$at program line$l$(in the following denoted${}^{l.}{\tt c}$) and$\mbox{\sf Pl${}_{\tiny\tt P}$}=\mbox{\sf Stm${}_{\tiny\tt P}$}^{-1}:\operatorname{\textsf{DImp}}\rightarrow\operatorname{\textsf{PLines}}{\tt P}$with the simple extension to blocks of$\tt P$instructions$\mbox{\sf Pl${}_{\tiny\tt P}$}({\tt c}{1}{\tt c}{2})=\mbox{\sf Pl${}_{\tiny\tt P}$}({\tt c}_{1})$. In general, we denote by PlP the set of all the program lines in$\tt P$222Note that, by definition a statement, or a block,${\tt c}$ ends always with ;..

Let M\triangleq\textsf{Var}\mbox{\raisebox{0.0pt}[4.30554pt][4.30554pt]{\mathrel{\mathop{\hskip 1.0pt\longrightarrow\hskip 1.0pt}\limits^{,{}{\mbox{\tiny}}}}}}\mathbb{Z}\cup\{\operatorname{\textbf{tt}},\operatorname{\textbf{ff}}\}\cup\Sigma^{*} be the set of memory maps, ranged over by $m$, that assign values (integers, booleans or strings) to variables. {\llparenthesis\hskip 0.86108pt{\tt s}\hskip 0.86108pt\rrparenthesis}:M\mbox{\raisebox{0.0pt}[4.30554pt][4.30554pt]{\mathrel{\mathop{\hskip 1.0pt\longrightarrow\hskip 1.0pt}\limits^{,{}{\mbox{\tiny}}}}}}\Sigma^{*} denotes the semantics of string expressions. For strings ${\tt s}_{1},{\tt s}_{2}\in\Sigma^{*}$, symbol $\delta\in\Sigma$ and values $n_{1},n_{2}\in{\mathbb{Z}}$ we have that ${\llparenthesis\hskip 0.86108pt{\tt s}_{1}\centerdot\delta\hskip 0.86108pt\rrparenthesis}m$ returns the concatenation of the string ${\llparenthesis\hskip 0.86108pt{\tt s}_{1}\hskip 0.86108pt\rrparenthesis}m$ with the symbol $\delta\in\Sigma$, i.e., ${\llparenthesis\hskip 0.86108pt{\tt s}_{1}\hskip 0.86108pt\rrparenthesis}m\cdot\delta$. We abuse notation and use ${\tt s}_{1}\centerdot{\tt s}_{2}$ for string concatenation. The semantics ${\llparenthesis\hskip 0.86108pt\textbf{substr}({\tt s},n_{1},n_{2})\hskip 0.86108pt\rrparenthesis}m$ returns the sub-string of the string ${\llparenthesis\hskip 0.86108pt{\tt s}\hskip 0.86108pt\rrparenthesis}m$ given by the $n_{2}$ consecutive symbols starting from the $n_{1}$-th one (we suppose $n_{1}\geq 0$)333The choice of considering only concatenation and substring derives form the fact that most of the operations on strings can be obtained as by using these two operations.. We denote with {\llparenthesis\hskip 0.86108pt{\tt a}\hskip 0.86108pt\rrparenthesis}:M\mbox{\raisebox{0.0pt}[4.30554pt][4.30554pt]{\mathrel{\mathop{\hskip 1.0pt\longrightarrow\hskip 1.0pt}\limits^{,{}_{\mbox{\tiny}}}}}}\mathbb{Z} the semantics of arithmetic expressions where ${\llparenthesis\hskip 0.86108pt\textbf{len}({\tt s})\hskip 0.86108pt\rrparenthesis}m$ returns the length of the string ${\llparenthesis\hskip 0.86108pt{\tt s}\hskip 0.86108pt\rrparenthesis}m$, and ${\llparenthesis\hskip 0.86108pt\textbf{num}({\tt s})\hskip 0.86108pt\rrparenthesis}m$ returns the integer denoted by the string ${\llparenthesis\hskip 0.86108pt{\tt s}\hskip 0.86108pt\rrparenthesis}m$ (suppose it returns the empty set if ${\llparenthesis\hskip 0.86108pt{\tt s}\hskip 0.86108pt\rrparenthesis}m$ is not a number). The semantics of the other arithmetic expressions is defined as usual. Analogously, ${\llparenthesis\hskip 0.86108pt{\tt b}\hskip 0.86108pt\rrparenthesis}:M\rightarrow\{\operatorname{\textbf{tt}},\operatorname{\textbf{ff}}\}$ denotes the semantics of Boolean expressions where, given ${\tt s}_{1},{\tt s}_{2}\in\Sigma^{*}$, ${\tt s}_{2}<{\tt s}_{1}$ is true iff ${\tt s}_{2}\preceq{\tt s}_{1}$ (prefix order). The semantics of the other Boolean expressions is defined as usual.

The update of memory $m$, for a variable $x$ with value $v$, is denoted $m[x/v]$. The semantics of $\mbox{\bf reflect}({\tt s})$ evaluates the string ${\tt s}$: if it is a program in $\operatorname{\textsf{DImp}}$ it executes it, otherwise the execution proceeds with the next command. Observe that ${\tt s}\in\Sigma^{\ast}$ while $\operatorname{\textsf{DImp}}\in\wp((\Sigma_{\operatorname{\textsf{DImp}}})^{\ast})$, for this reason we define $\overline{\operatorname{\textsf{DImp}}}\triangleq\{\mathbf{a}\in\Sigma^{\ast}~{}|~{}\mathbf{a}=\mathbf{a}_{1}\cdot\mathbf{a}_{2}\cdot\ldots\cdot\mathbf{a}_{n},\mathbf{a}_{1}\mathbf{a}_{2}\ldots\mathbf{a}_{n}\in\operatorname{\textsf{DImp}}\}$ as the set of sequences in $\Sigma^{\ast}$ that can be obtained by concatenating the sequences $\mathbf{a}^{i}$ that act like symbols in a program in $\operatorname{\textsf{DImp}}$. We denote with $\overline{{\tt c}}$ the sequence of $\Sigma^{\ast}$ that corresponds to the sequence ${\tt c}\in(\Sigma_{\operatorname{\textsf{DImp}}})^{\ast}$. At this point, before computing the semantics of $\overline{{\tt c}}$, we need to recognize which statements it denotes, building the corresponding string ${\tt c}\in\operatorname{\textsf{DImp}}$, and then to label this statements by using the function $\textsf{lab}(\cdot)$, assigning an integer label to each statement in {\tt c}\mbox{\tt\}$from$1$to the final program point$l_{e}$. In the following, we say that${\tt s}$evaluates to${\tt c}$when it assumes a value$\overline{{\tt c}}\in\overline{\operatorname{\textsf{DImp}}}$corresponding to the concatenation of the sequences that are symbols of${\tt c}$. The semantics of$x:=\mbox{\bf reflect}({\tt s})$evaluates expression${\tt s}$and if it is${\tt c}$in$\operatorname{\textsf{DImp}}$it proceeds by assigning$>{}^{\prime};{}^{\prime}$to$x$and executes${\tt c}$, otherwise it behaves as a standard assignment. Formally, let$\mathsf{Int}:\operatorname{\textsf{DImp}}\times M\mbox{\raisebox{0.0pt}[4.30554pt][4.30554pt]{$\mathrel{\mathop{\hskip 1.0pt\longrightarrow\hskip 1.0pt}\limits^{\,{}_{\mbox{\tiny}}}}$}}M$denote the semantics of programs, and${\llparenthesis\hskip 0.86108pt\cdot\hskip 0.86108pt\rrparenthesis}m$the evaluation of an expression in the memory$m$, then:

[TABLE]

We can observe that the way in which we treat the commands ${}^{l.}\mbox{\bf reflect}({\tt s})$ and ${}^{l.}x:=\mbox{\bf reflect}({\tt s})$ mimics the classical semantic model and implementation of reflection and reification as introduced in Smith [33], see [37, 18] for details. In particular, when string ${\tt s}$ evaluates to a program ${\tt c}$, the program control starts the execution of ${\tt c}$ before returning to the original code. The problem is that ${\tt c}$ may contain other reflect statements leading to the execution of new portions of code. Hence, each nested reflect is an invocation of the interpreter which can be seen as a new layer in the tower of interpretations: When a layer terminates the execution the control returns to the previous layer with the actual state. Hence, the state $\mathsf{Int}(^{l.}\mbox{\bf reflect}({\tt s});^{l^{\prime}.}\tt Q,\textit{m})$, when string ${\tt s}$ evaluates to a program ${\tt c}$, starts a new computation of $\textsf{lab}({\tt c})$ from $m$. Once the execution of the tower derived from ${\tt c}$ terminates, the execution comes back to the continuation $\tt Q$, in the memory resulting from the execution of ${\tt c}$. It is known that in general the construction of the tower of interpreters may be infinite leading to a divergent semantics.

Example 4.1**.**

Consider the following program fragment $\tt P$:

[TABLE]

Suppose the initial memory is $m_{\bot}$ (associating the undefined value to each variable, in this case $x$). After the execution of the first assignment we have the memory $m_{1}=[x/\>^{\prime}\!\mbox{\bf reflect}(x)^{\prime}]$, on which we execute the $\mbox{\bf reflect}(x)$ statement. Since now, $\mbox{\bf reflect}(x)$ is executed starting from $m_{1}$, hence each $\mbox{\bf reflect}(x)$ activates a tower layer executing the statement in $x$, which is again $\mbox{\bf reflect}(x)$ starting from the same memory. Hence the tower has infinite height.

4.2 Flow-sensitive Collecting Semantics

Collecting semantics models program execution by computing, for each program point, the set of all the values that each variables may have. In order to deal with reflection we need to define an interpreter collecting values for each program point which, at each step of computation, keeps trace not only of the collection of values after the last executed program point $p$, but also of the values collected in all the other program points, both already executed and not executed yet. In other words, we define a flow sensitive semantics which, at the end of the computation, observes the trace of collections of values holding at each program point. In order to model this semantics, we model the concrete state not simply as a memory – the current memory, but as the tuple of memories holding at each program point. It is clear that, at each step of computation, only the memory in the last executed program point will be modified. First, we define a collecting memory $\operatorname{\mathbb{m}}$, associating with each variable a set of values instead of a single value. We define the set \mathbb{M}\triangleq\textsf{Var}\mbox{\raisebox{0.0pt}[4.30554pt][4.30554pt]{\mathrel{\mathop{\hskip 1.0pt\longrightarrow\hskip 1.0pt}\limits^{,{}_{\mbox{\tiny}}}}}}\wp(\mathbb{Z})\cup\mathsf{Bool}\cup\wp(\Sigma^{*}) with meta-variable $\operatorname{\mathbb{m}}$, where $\mathsf{Bool}=\wp(\{\operatorname{\textbf{ff}},\operatorname{\textbf{tt}}\})$. We define two particular memories, $\operatorname{\mathbb{m}}_{\varnothing}$ associating $\varnothing$ to any variable, and $\operatorname{\mathbb{m}}_{\top}$ associating the set of all possible values to each variable. The update of memory $\operatorname{\mathbb{m}}$ for a variable $x$ with set of values $v$ is denoted $\operatorname{\mathbb{m}}[x/v]$. Finally, lub and glb of memories are $\operatorname{\mathbb{m}}_{1}\sqcup\operatorname{\mathbb{m}}_{2}(x)=\operatorname{\mathbb{m}}_{1}(x)\cup\operatorname{\mathbb{m}}_{2}(x)$ and $\operatorname{\mathbb{m}}_{1}\sqcap\operatorname{\mathbb{m}}_{2}(x)=\operatorname{\mathbb{m}}_{1}(x)\cap\operatorname{\mathbb{m}}_{2}(x)$.

Then, in order to make the semantics flow-sensitive, we introduce a new notion of flow-sensitive store (in the following called store) \operatorname{\mathbb{S}}\triangleq\operatorname{\textsf{PLines}}_{\tt P}\mbox{\raisebox{0.0pt}[4.30554pt][4.30554pt]{\mathrel{\mathop{\hskip 1.0pt\longrightarrow\hskip 1.0pt}\limits^{,{}_{\mbox{\tiny}}}}}}\mathbb{M} associating with each program line a memory. We represent a store $\operatorname{\mathbb{s}}\in\operatorname{\mathbb{S}}$ at a given line $l\in\operatorname{\textsf{PLines}}_{\tt P}$ as a tuple $\langle x_{1}/v_{x_{1}},\ldots,x_{n}/v_{x_{n}}\rangle$, where $v_{x_{i}}$ is the set of possible values of variable $x_{i}$. We use $\operatorname{\mathbb{s}}_{l}$ to denote $\operatorname{\mathbb{s}}(l)$, namely the memory at line $l$. Given a store $\operatorname{\mathbb{s}}$, the update of memory $\operatorname{\mathbb{s}}_{l}$ with a new collecting memory $\operatorname{\mathbb{m}}$ is denoted $\operatorname{\mathbb{s}}[\operatorname{\mathbb{s}}_{l}\leftarrow\operatorname{\mathbb{m}}]$ and provides a new store $\operatorname{\mathbb{s}}^{\prime}$ such that $\operatorname{\mathbb{s}}^{\prime}_{l}=\operatorname{\mathbb{s}}_{l}\sqcup\operatorname{\mathbb{m}}$ while $\forall l^{\prime}\neq l$ we have $\operatorname{\mathbb{s}}^{\prime}_{l^{\prime}}=\operatorname{\mathbb{s}}_{l^{\prime}}$.

We abuse notation by denoting with ${\llparenthesis\hskip 0.86108pt\cdot\hskip 0.86108pt\rrparenthesis}$, not only the concrete, but also the collecting semantics of expressions, all defined as additive lift of the expression semantics. In particular, we denote by ${\llparenthesis\hskip 0.86108pt{\tt b}\hskip 0.86108pt\rrparenthesis}^{\operatorname{\textbf{tt}}}$ the maximal collecting memory making ${\tt b}$ true, i.e., it is $\bigsqcup\{m\in M~{}|~{}{\llparenthesis\hskip 0.86108pt{\tt b}\hskip 0.86108pt\rrparenthesis}m=\operatorname{\textbf{tt}}\}\in\mathbb{M}$ (analogous for ${\llparenthesis\hskip 0.86108pt{\tt b}\hskip 0.86108pt\rrparenthesis}^{\operatorname{\textbf{ff}}}$). Hence, by $\operatorname{\mathbb{m}}\sqcap{\llparenthesis\hskip 0.86108pt{\tt b}\hskip 0.86108pt\rrparenthesis}^{\operatorname{\textbf{tt}}}$ we denote the memory $\operatorname{\mathbb{m}}^{\prime}\triangleq\operatorname{\mathbb{m}}[x\in\textsf{vars}({\tt b})/\operatorname{\mathbb{m}}(x)\cap{\llparenthesis\hskip 0.86108pt{\tt b}\hskip 0.86108pt\rrparenthesis}^{\operatorname{\textbf{tt}}}(x)]$, where $\textsf{vars}({\tt b})$ is the set of variables of ${\tt b}$. For instance if $\operatorname{\mathbb{m}}=[x/\{1,2,3\},y/\{1,2\}]$ and ${\tt b}=(x<3)$, then ${\llparenthesis\hskip 0.86108pt{\tt b}\hskip 0.86108pt\rrparenthesis}^{\operatorname{\textbf{tt}}}=[x/\{1,2\},y/\top]$, hence $\operatorname{\mathbb{m}}\sqcap{\llparenthesis\hskip 0.86108pt{\tt b}\hskip 0.86108pt\rrparenthesis}^{\operatorname{\textbf{tt}}}=[x/\{1,2\},y/\{1,2\}]$. Finally, let $V\subseteq\textsf{Var}$, by $\operatorname{\mathbb{s}}_{V}$ we denote the store where for each program point $l$, the memory $\operatorname{\mathbb{s}}_{l}$ is restricted only on the variables in $V$, by ${\sf lfp\/}_{V}f(\operatorname{\mathbb{s}})$ we denote the computation of the fix point only on the variables $V$, i.e., we compute $\operatorname{\mathbb{s}}$ such that $\operatorname{\mathbb{s}}_{V}=f(\operatorname{\mathbb{s}})_{V}$.

We follow [12] in the usual definition of the concrete collecting trace semantics of a transition system $\langle\operatorname{\mathbb{C}},\leadsto\rangle$ associated with programs in $\operatorname{\textsf{DImp}}$, where $\operatorname{\mathbb{C}}=\operatorname{\textsf{DImp}}\times\operatorname{\mathbb{S}}$ is the set of states in the transition system with typical elements $\operatorname{\mathbb{c}}\in\operatorname{\mathbb{C}}$ and $\leadsto\subseteq\operatorname{\mathbb{C}}\times\wp(\operatorname{\mathbb{C}})$ is a transition relation. The state space in the transition system is the set of all pairs $\langle{\tt c},\operatorname{\mathbb{s}}\rangle$ with ${\tt c}\in\operatorname{\textsf{DImp}}$ and $\operatorname{\mathbb{s}}\in\operatorname{\mathbb{S}}$ representing the store computed by having executed the first statement in ${\tt c}$ and having its continuation still to execute. The transition relation generated by a program ${\tt c}\in\operatorname{\textsf{DImp}}$ is in Appendix. The axiom \langle^{l_{e}.}\mbox{\tt\},\operatorname{\mathbb{s}}\rangle$identifies the final blocking states${\mathcal{B}}$. When the next command to execute is${}^{l.}\mbox{\bf reflect}({\tt s})$, we need to verify whether the evaluation of the string${\tt s}$at program line$l$returns a set of sequences of symbols of$\Sigma$that contains sequences representing programs in$\operatorname{\textsf{DImp}}$. If this is the case, we proceed by executing the programs corresponding to${\llparenthesis\hskip 0.86108pt\tt s\hskip 0.86108pt\rrparenthesis}\operatorname{\mathbb{s}}{l}$with initial memory (at the first program line of${\tt c}$) the memory holding at program line$l$, while the memories for all the other program points in${\tt c}$are initialized to$\operatorname{\mathbb{m}}{\varnothing}$. When the next command to execute is an assignment of the form${}^{l.}x:=\mbox{\bf reflect}({\tt s})$we need to verify whether string${\tt s}$evaluates to a simple set of strings or to strings corresponding to programs in$\operatorname{\textsf{DImp}}$. If the evaluation of the strings in${\llparenthesis\hskip 0.86108pt\tt s\hskip 0.86108pt\rrparenthesis}\operatorname{\mathbb{s}}{l}$does not contain programs we proceed as for standard assignments. If${\llparenthesis\hskip 0.86108pt\tt s\hskip 0.86108pt\rrparenthesis}\operatorname{\mathbb{s}}{l}$returns programs in$\operatorname{\textsf{DImp}}$then the assignment becomes an assignment of$>{}^{\prime};{}^{\prime}$to variable$x$and the execution of the programs corresponding to${\llparenthesis\hskip 0.86108pt\tt s\hskip 0.86108pt\rrparenthesis}\operatorname{\mathbb{s}}{l}$. Observe that, in order to verify whether the possible values assumed by a string${\tt s}$at a program point$l$are programs in$\operatorname{\textsf{DImp}}$, we check if the intersection${\llparenthesis\hskip 0.86108pt{\tt s}\hskip 0.86108pt\rrparenthesis}\operatorname{\mathbb{s}}{l}\cap\overline{\operatorname{\textsf{DImp}}}is not empty. Unfortunately, this step is in general undecidable, for this reason, in Section [6](#S6), we provide a constructive methodology for deciding the executability of{\llparenthesis\hskip 0.86108pt{\tt s}\hskip 0.86108pt\rrparenthesis}\operatorname{\mathbb{s}}_{l}$ and for synthesizing a program that can be executed in order to proceed with the analysis and obtain a sound result. The other rules model standard transitions.

Given a program $\tt P\in\operatorname{\textsf{DImp}}$ and a set of initial stores $I$, we denote by ${\mathcal{I}}\triangleq\{\operatorname{\mathbb{c}}~{}|~{}\operatorname{\mathbb{c}}=\langle\tt P,\operatorname{\mathbb{s}}\rangle,\operatorname{\mathbb{s}}\in I\}$ the set of initial states. In sake of simplicity, we consider a partial collecting trace semantics observing only the finite prefixes of finite and infinite execution traces:

[TABLE]

It is known that ${\mathcal{F}}(\tt P,{\mathcal{I}})$ expresses precisely invariant properties of program executions and it can be obtained by fix-point of the following trace set transformer \mathtt{F}:\wp(\operatorname{\mathbb{C}}^{*})\mbox{\raisebox{0.0pt}[4.30554pt][4.30554pt]{\mathrel{\mathop{\hskip 1.0pt\longrightarrow\hskip 1.0pt}\limits^{,{}_{\mbox{\tiny}}}}}}\wp(\operatorname{\mathbb{C}}^{*}), starting form the set ${\mathcal{I}}$ of initial configurations, such that ${\mathcal{F}}(\tt P,{\mathcal{I}})={\sf lfp\/}(\mathtt{F}_{\tt P,{\mathcal{I}}})$.

[TABLE]

Finally, we can define the store projection of the partial collecting trace semantics (in the following simply called trace semantics) of a program $\tt P$ form an initial store $\operatorname{\mathbb{s}}\in I$ as

[TABLE]

Example 4.2**.**

Consider the following $\operatorname{\textsf{DImp}}$ program $\tt P$ implementing an iterative count by dynamic code modification.

[TABLE]

At each step of computation, let us denote by $\tt P$ the continuation of the program. A portion of the iterative computation of the collecting semantics, starting from the store $\operatorname{\mathbb{s}}^{0}$ such that, for each $l\in[1,6],\>\operatorname{\mathbb{s}}^{0}_{l}=\operatorname{\mathbb{m}}_{\varnothing}$, is reported in Fig. 3. Note that, $\operatorname{\mathbb{s}}_{1}=\operatorname{\mathbb{m}}_{\varnothing}$ at each step of computation, while $\operatorname{\mathbb{s}}_{2}=[x/\{1\},\mathit{str}/\varnothing]$ after the execution of the first statement. Moreover, in sake of brevity, we will denote as $\>{}^{\prime}\!s^{\prime}$ the string $\>{}^{\prime}\!x:=x+1^{\prime}$.

With a different color, we highlight the execution of reflect activating a new analysis computation, and the memory $\operatorname{\mathbb{s}}_{3}$ computed by the statements executed by the reflect. In particular, the first execution of $\mathbf{reflect}(\mathit{str})$ is such that {\llparenthesis\hskip 0.86108pt\mathit{str}\hskip 0.86108pt\rrparenthesis}\operatorname{\mathbb{s}}_{5}\cap\operatorname{\textsf{DImp}}=\{x:=x+1;\mbox{\tt\}}$*. Moreover, the initial store *$\operatorname{\mathbb{s}}^{\iota}$* for the execution of ***reflect*** is such that *$\operatorname{\mathbb{s}}^{\iota}{1}=\operatorname{\mathbb{s}}{5}$*, and *$\forall 1<l\leq l_{e}$* *$\operatorname{\mathbb{s}}{l}=\operatorname{\mathbb{m}}{\varnothing}$*. *$\textsf{lab}(x:=x+1;\mbox{\tt$})=^{1.}x:=x+1;^{2.}\mbox{\tt$}$*, with *$l_{e}=2$*. Now, the computation of *$\textsf{lab}(x:=x+1;\mbox{\tt$})$* is given in Fig. **4** on the left. In this case *$\operatorname{\mathbb{s}}^{e}{l{e}}=[x/{2},\mathit{str}/{>^{\prime};{}^{\prime},>^{\prime}!s^{\prime}}]$*, hence the new *$\operatorname{\mathbb{s}}{3}$* is the least upper bound between this *$\operatorname{\mathbb{s}}^{e}{l_{e}}$* and the previous *$\operatorname{\mathbb{s}}{3}$*, which is *$[x/{1,2},\mathit{str}/{>^{\prime};{}^{\prime},>^{\prime}!s^{\prime}}]$*. The second time ***reflect*** is executed, we have *${\llparenthesis\hskip 0.86108pt\mathit{str}\hskip 0.86108pt\rrparenthesis}\operatorname{\mathbb{s}}{5}\cap\operatorname{\textsf{DImp}}={x:=x+1^{\prime};\mbox{\tt$},x:=x+1;x:=x+1;\mbox{\tt$}}$*. The calling memory is *$\operatorname{\mathbb{s}}^{\iota}{1}=\operatorname{\mathbb{s}}{5}=[x/{1,2},\mathit{str}/{>^{\prime};{}^{\prime},>^{\prime}!s^{\prime},>^{\prime}!s;s^{\prime}}]$*. Similarly to the previous case, the execution of *${}^{1.}x:=x+1;^{2.}\mbox{\tt$}$* returns the least upper bound between *$\operatorname{\mathbb{s}}{3}$* and *$[x/{2,3},\mathit{str}/{>^{\prime};{}^{\prime},>^{\prime}!s^{\prime},>^{\prime}!s;s^{\prime}}]$* which is *$[x/{1,2,3},\mathit{str}/{>^{\prime};{}^{\prime},>^{\prime}!s^{\prime},>^{\prime}!s;s^{\prime}}]$*. Finally, the execution of *${}^{1.}x:=x+1;^{2.}x:=x+1;^{3.}\mbox{\tt$}$* is given in Fig. **4** (on the right). In this case, the resulting memory is the least upper bound between *$\operatorname{\mathbb{s}}{3}$* and *$[x/{3,4},\mathit{str}/{>^{\prime};{}^{\prime},>^{\prime}!s^{\prime},>^{\prime}!s;s^{\prime}}]$*, which is *$[x/{1,2,3,4},\mathit{str}/{>^{\prime};{}^{\prime},>^{\prime}!s^{\prime},>^{\prime}!s;s^{\prime}}]$*, which is also the least upper bound of all the resulting memories, i.e., the new *$\operatorname{\mathbb{s}}_{3}$.

5 Abstract Interpretation of Strings

5.1 The abstract domain

Let $\operatorname{\mathbb{C}}^{\sharp}=\operatorname{\textsf{DImp}}\times\operatorname{\mathbb{S}}^{\sharp}$ be the domain of abstract states, where \operatorname{\mathbb{S}}^{\sharp}:\operatorname{\textsf{PLines}}_{\tt P}\mbox{\raisebox{0.0pt}[4.30554pt][4.30554pt]{\mathrel{\mathop{\hskip 1.0pt\longrightarrow\hskip 1.0pt}\limits^{,{}{\mbox{\tiny}}}}}}\mathbb{M}^{\sharp} denotes abstract stores ranged over $\operatorname{\mathbb{s}^{\sharp}}$, and \mathbb{M}^{\sharp}:\textsf{Var}\mbox{\raisebox{0.0pt}[4.30554pt][4.30554pt]{\mathrel{\mathop{\hskip 1.0pt\longrightarrow\hskip 1.0pt}\limits^{,{}{\mbox{\tiny}}}}}}\textsf{AbstVal} denotes the set of abstract memory maps ranged over by $\operatorname{\mathbb{m}^{\sharp}}$. The domain of abstract values for expressions is $\textsf{AbstVal}\triangleq\{\top,\mathsf{Interval},\mathsf{Bool},\mathsf{FA}_{/\equiv},\bot\}$444Note that, we do not consider here implicit type conversion statements, namely each variable, during execution can have values of only one type, nevertheless we consider the reduced product of possible abstract values in order to define only one abstract domain.. It is composed by $\mathsf{Interval}$, the standard GC-based abstract domain encoding the interval abstraction of $\wp(\mathbb{Z})$, by $\mathsf{Bool}$, the powerset domain of Boolean values, and by $\mathsf{FA}_{/\equiv}$ denoting the domain of FAs up to language equivalence. Given two FA $A_{1}$ and $A_{2}$ we have that $A_{1}\equiv A_{2}$ iff $\mathscr{L}(A_{1})=\mathscr{L}(A_{2})$. Hence, the elements of the domain $\mathsf{FA}_{/\equiv}$ are the equivalence classes of FAs recognizing the same language ordered wrt language inclusion $\mathsf{FA}_{/\equiv}=\langle[A]_{\equiv},\leq_{\mathit{FA}}\rangle$, where $[A_{1}]_{\equiv}\leq_{\mathit{FA}}[A_{2}]_{\equiv}$ iff $\mathscr{L}(A_{1})\subseteq\mathscr{L}(A_{2})$. Here concretization is the language recognized $\mathscr{L}$. By the Myhill-Nerode theorem [19] the domain is well defined and we can use the minimal automata to represent each equivalence class, moreover, the ordering relation is well defined since it does not depend on the choice of the FA used to represent the equivalence class. In particular, we consider the domain $\mathsf{FA}_{/\equiv}$ defined over the finite alphabet $\Sigma$, thus, given $A\in\mathsf{FA}_{/\equiv}$, we have that $\mathscr{L}(A)\in\wp(\Sigma^{\ast})$. FAs are closed for finite language intersection and union. They do not form a Galois connection with $\wp(\Sigma^{\ast})$. The finite lub $\sqcup_{\textsf{AbstVal}}$ and glb $\sqcap_{\textsf{AbstVal}}$ among elements of AbstVal are defined as expected: the lub of two abstract values of the same type is given by the lub of the corresponding domain, while the lub between abstract values of different types is $\top$. This means that, for example, the lub of two intervals is the standard lub over intervals, while the lub between an interval and a FA is $\top$. Analogously, for the glb returning $\bot$ if applied to different types.

Since $\mathsf{Interval}$ and $\mathsf{FA}_{/\equiv}$ are not ACC, and, in particular, $\mathsf{FA}_{/\equiv}$ is not closed by lubs of infinite chains, AbstVal is also not ACC and not closed. Therefore, we need to define a widening operator $\triangledown$ on AbstVal. The widening operator among elements of different types returns $\top$, the widening operator of Boolean elements is the standard lub, $\mathsf{Bool}$ being ACC, the widening operator between elements of the interval domain is the standard widening operator on $\mathsf{Interval}$ [14]. Finally, the widening operator on $\mathsf{FA}_{/\equiv}$ is defined in terms of the widening operator $\triangledown_{R}$ over finite automata introduced in [21].

Let us consider two FA $A_{1}=(Q^{1},\delta^{1},q_{0}^{1},F^{1},\Sigma^{1})$ and $A_{2}=(Q^{2},\delta^{2},q_{0}^{2},F^{2},\Sigma^{2})$ such that $\mathscr{L}(A_{1})\subseteq\mathscr{L}(A_{2})$: the widening between $A_{1}$ and $A_{2}$ is formalized in terms of a relation $R\subseteq Q^{1}\times Q^{2}$ between the set of states of the two automata. The relation $R$ is used to define an equivalence relation $\equiv_{R}\subseteq Q^{2}\times Q^{2}$ over the states of $A_{2}$, such that $\equiv_{R}=R\circ R^{-1}$. The widening between $A_{1}$ and $A_{2}$ is then given by the quotient automata of $A_{2}$ wrt the partition induced by $\equiv_{R}$: $A_{1}\triangledown_{R}A_{2}=A_{2}/\!\equiv_{R}$. Thus, the widening operator merges the states of $A_{2}$ that are in equivalence relation $\equiv_{R}$. By changing the relation $R$, we obtain different widening operators [21]. It has been proved that convergence is guaranteed when the relation $R_{n}\subseteq Q^{1}\times Q^{2}$, such that $(q_{1},q_{2})\in R_{n}$ if $q_{1}$ and $q_{1}$, recognizes the same language of strings of length at most $n$ [21]. Thus, the parameter $n$ tunes the length of the strings determining the equivalence of states and therefore used for merging them in the widening. It is worth noting that, the smaller is $n$, the more information will be lost by widening automata. In the following, given two FA $A_{1}$ and $A_{2}$ with no constraints on the languages they recognize, we define the widening operator parametric on $n$ on $\mathsf{FA}_{/\equiv}$ as follows: $A_{1}\triangledown_{n}A_{2}\triangleq A_{1}\triangledown_{R_{n}}(A_{1}\sqcup A_{2})$.

5.2 Abstract semantics of expressions

In this section, we model string operations, and in particular we observe that they can be expressed as SFTs, namely as symbolic transformers of a language of strings over $\Sigma$. The SFTs that correspond to symbol concatenation ${\tt s}\centerdot\sigma$ and to substring extraction $\textbf{substr}({\tt s},{\tt a}_{1},{\tt a}_{2})$ are given in Fig. 5, where $\sigma$ ranges over the alphabet $\Sigma$.

In particular, for symbol concatenation we have an SFT $T^{C}_{\delta}$ for each symbol $\delta\in\Sigma$. Each SFT $T^{C}_{\delta}$ adds the considered symbol $\delta$ at the end of any string (note that if non deterministically we follow the $\varepsilon$ edge in the middle of a string then we cannot terminate in a final state anymore, meaning that the input string is not recognized and therefore no output is produced). As far as the sub-string operation is concerned, we have an SFT $T^{S}_{n,m}$ for each pair of non-negative values $n$ and $m$, which reads $n-1$ symbols in the input string without producing outputs, then it reads $m$ symbols from the $n$-th, releasing the symbol also in output, and finally it reads all the remaining symbols without producing outputs. It is clear that, if the string ends before reaching the starting point $n$, or before reading $m$ symbols, then the string is not accepted and no output is produced. Namely, if ${\tt s}$ is the input string, the transformation works correctly only if $n+m\leq\textbf{len}({\tt s})$.

We can now define the abstract semantics of expressions as {\llparenthesis\hskip 0.86108pt\operatorname{Exp}\hskip 0.86108pt\rrparenthesis}^{\sharp}=\mathbb{M}^{\sharp}\mbox{\raisebox{0.0pt}[4.30554pt][4.30554pt]{\mathrel{\mathop{\hskip 1.0pt\longrightarrow\hskip 1.0pt}\limits^{,{}_{\mbox{\tiny}}}}}}\textsf{AbstVal} as the best correct approximation of the collecting concrete semantics. For instance, in Fig. LABEL:fig-aexpr we specify the abstract semantics for string expressions. When we perform operations between expressions of the wrong type then we return $\top$, for example if we add an interval to an FA.

5.3 Abstract Program Semantics

We can now define the abstract transition relation $\leadsto^{\sharp}\subseteq\operatorname{\mathbb{C}}^{\sharp}\times\operatorname{\mathbb{C}}^{\sharp}$ among abstract states. The rules defining the abstract transition relation can be obtained from the rules of the concrete transition relation given in Fig. LABEL:fig:rules, by replacing the collecting semantics of expressions ${\llparenthesis\hskip 0.86108pt\cdot\hskip 0.86108pt\rrparenthesis}$ with the abstract one, and by modifying the assignment rules and the executability test. In particular, in the abstract transition, the memory update of the assignment rules uses the widening operator over AbstVal instead of the least upper bound. The executability test in the reflection rules is now $\mathscr{L}({\llparenthesis\hskip 0.86108pt{\tt s}\hskip 0.86108pt\rrparenthesis}^{\sharp}\operatorname{\mathbb{s}}_{l}^{\sharp})\cap\overline{\operatorname{\textsf{DImp}}}$. This allows us to compute the partial abstract collecting trace semantics ${\mathcal{F}}^{\sharp}(P,{\mathcal{I}}^{\sharp})$ of the abstract transition system $\langle\operatorname{\mathbb{C}}^{\sharp},\leadsto^{\sharp}\rangle$. Given a set of abstract initial states ${\mathcal{I}}^{\sharp}\subseteq\operatorname{\mathbb{C}}^{\sharp}$, we define the abstract fix-point function F^{\sharp}:(\operatorname{\mathbb{C}}^{\sharp})^{\ast}\mbox{\raisebox{0.0pt}[4.30554pt][4.30554pt]{\mathrel{\mathop{\hskip 1.0pt\longrightarrow\hskip 1.0pt}\limits^{,{}{\mbox{\tiny}}}}}}\wp((\operatorname{\mathbb{C}}^{\sharp})^{\ast}), starting from ${\mathcal{I}}^{\sharp}$, such that {\mathcal{F}}^{\sharp}(\tt P,{\mathcal{I}}^{\sharp})={\sf lfp\/}(\mbox{\mathtt{F}^{\sharp}{\tt P,{\mathcal{I}}^{\sharp}}}):

[TABLE]

Theorem 5.1**.**

${\mathcal{F}}^{\sharp}(\tt P,{\mathcal{I}}^{\sharp})$* is a sound approximation of ${\mathcal{F}}(\tt P,{\mathcal{I}})$.*

Example 5.2**.**

Consider the following program fragment $P$

[TABLE]

where $ds:=\textsl{deobf}(os)$ is a syntactic sugar for the string transformer in Fig. 6 In Fig. 6-(a) is the FA, namely the abstract value, of $ds$ at program line $8$, computed by the proposed static analysis, wrt $\triangledown_{3}$.

It is worth noting that, even in the approximate computation, we have the problem of decidability of the executability of ${\llparenthesis\hskip 0.86108pt{\tt s}\hskip 0.86108pt\rrparenthesis}^{\sharp}\operatorname{\mathbb{s}}_{l}^{\sharp}$. Indeed, it is still in general undecidable to compute the intersection $\mathscr{L}({\llparenthesis\hskip 0.86108pt{\tt s}\hskip 0.86108pt\rrparenthesis}^{\sharp}\operatorname{\mathbb{s}}_{l}^{\sharp})\cap\overline{\operatorname{\textsf{DImp}}}$ between a possibly infinite language modeling the possible values of a string expression ${\tt s}$ in a certain program point and a context free grammar (CFG) modeling the language. This means that, our implementation of the analysis needs to approximate the set of executable strings collected during the abstract computation for the arguments of reflection instructions.

6 The SEA Analyzer

The SEA analyser implements both a new string analysis domain and it performs an executability analysis in presence of a reflection statement. SEA is indeed a prototype implementation with the ambition of providing a general language-independent sound-by-construction architecture for the static analysis of self modifying code, where only some components are language-dependent, in our case the abstract interpreter for $\operatorname{\textsf{DImp}}$.

The first feature of SEA consists in the implementation of the interpreter based on the flow-sensitive collecting semantics proposed in Sect. 5. The main original contribution is in the way the reflection analysis is handled. In particular, we provide an algorithmic approach for approximating in a decidable way the executability test $\mathscr{L}({\llparenthesis\hskip 0.86108pt{\tt s}\hskip 0.86108pt\rrparenthesis}^{\sharp}\operatorname{\mathbb{s}}^{\sharp}_{l})\cap\overline{\operatorname{\textsf{DImp}}}$ and for building a program in $\operatorname{\textsf{DImp}}$ that soundly approximates the executable programs, i.e., whose semantics soundly approximates the semantics of the code that may be executed in a reflection statement. Our idea is first to filter the automaton collecting the string analysis in order to keep only an over-approximation of the executable strings and then to synthesise a code fragment whose possible executions over-approximate the possible concrete executions. In Fig. 7 we show how SEA works, and we explain the architecture on a running example.

In Ex. 5.2 we showed the execution of $\mathsf{Int}^{\#}(P,\operatorname{\mathbb{s}})$, where $\operatorname{\mathbb{s}}$ starts with any value for $x$, up to program line $8$. Now, we can explain how the analysis works. In particular, following the execution structure in Fig. 7, at line $8$ we call the execution of $\mathsf{Exe}^{\#}$ on $A^{8}_{ds}$ given in Fig. 6 and in the following simply denoted $\overline{A}$.

The first step consists in reducing the number of states of the automaton, by over-approximating every string recognized as a statement, or partial statement, in $\operatorname{\textsf{DImp}}$.

StmSyn.

The idea is to consider the automaton computed by the collecting semantics $\mathtt{A}$, and to collapse all the consecutive edges up to any punctuation symbol in \{\mbox{\small;,{,},\mbox{\tt$}}\}. In particular, any executable statement will end with ;, while $\{$ and $\}$ allow to split strings when the body of a while or of an if begins or ends, finally recognises the end of a program. Hence, we design the procedure Build, computed by Alg. [2](#alg2), and recursively called by Alg. [1](#alg1) that returns an automaton on a finite subset of the alphabet:\Sigma_{\tt\tiny Syn}={>\mbox{\small\},\mbox{\tt\}}\}\cup\{x;~{}|~{}x\in\Sigma^{*}\}\cup\{x\mbox{\small{}~{}|~{}x\in\Sigma^{*}\}. In particular, given the parsing tree $\mathtt{T_{A}}$ of the automaton $\mathtt{A}$, obtained by performing a depth first visit on $\mathtt{A}$, we define

[TABLE]

Hence, the finite alphabet of the resulting automaton is \Sigma^{\mathtt{A}}_{\tt\tiny Syn}=\{\>\mbox{\small},\mbox{\tt$}}\}\cup\{x;~{}|~{}x\in\mathsf{Str}\}\cup\{x\mbox{\small{}~{}|~{}x\in\mathsf{Str}\}.

The idea of the algorithm is first to reach $q_{0}^{\prime}$ from $q_{0}$ reading the symbol ′, and then to perform, starting from $q_{0}^{\prime}$, a visit of the states recursively identified by Algorithm 2 and to recursively replace the sequences of edges that recognize a symbol in $\Sigma^{\mathtt{A}}_{\tt\tiny Syn}$ with a single edge labeled by the corresponding string. In particular, from $q_{0}^{\prime}$ we reach the states computed by $\textsc{Build}(q_{0}^{\prime})$, and the corresponding read words. Recursively, we apply Build to these states, following only those edges that we have not already visited. It is clear that, in this phase all the non-executable strings not ending with a symbol in \{\mbox{\small;,{,},\mbox{\tt$}}\} are erased from the automata, hence we have a reduction of non executable strings. For instance, in Fig. 8 we have the computation of $\texttt{StmSyn}(\overline{A})$, denoted $\overline{A}_{\mbox{\tt\tiny d}}$.

From the computational point of view, we can observe that the procedure $\textsc{Build}(A,q)$ executes a number of recursive-call sequences equal to the number of maximal acyclic paths starting from $q$ on $A$. The number of these paths can be computed as $\sum_{q\in Q}(\mathit{outDegree}(q)-1)+1$, where $\mathit{outDegree}(q)$ is the number of outgoing edges from $q$. The worst case depth of a recursive-call sequence is $|Q|$. Thus, the worst case complexity of Build (when $\mathit{outDegree}(q)=|Q|\times|\Sigma|$ for all $q\in Q$) is $O(|Q|^{3})$. As far as StmSyn is concerned, we can observe that in the worst case we keep in StmSyn(A) all the $|Q|$ states of $A$, hence in this case we launch $|Q|$ times the procedure Build, and therefore the worst case complexity of StmSyn is $O(|Q|^{4})$.

Next step consists in verifying whether the labels of each edge in $\texttt{StmSyn}(\mathtt{A})$ are potentially executable, or portion of an executable statement.

Lex-Parser.

In order to proceed with the analysis, we need to synthesize a program from $\mbox{\tt A}_{\mbox{\tt\tiny d+}}$ approximating the set of executable string values assumed by string ${\tt s}$ at program line $l$ where reflection is executed. This would allow us to replace the argument of the reflect with the synthesized program and use the same analyser (abstract interpreter) for the analysis of the generated code. Hence, we have to check whether each label in $\mbox{\tt A}_{\mbox{\tt\tiny d}}=\texttt{StmSyn}(\mathtt{A})$ is in particular in the alphabet $\operatorname{\textsf{DImp}}^{-}\subseteq\Sigma^{\mathtt{A}}_{\tt\tiny Syn}$ of (partial) statements of $\operatorname{\textsf{DImp}}$ statements:

[TABLE]

where ${\tt s},{\tt e},{\tt b}$ are expressions in the language $\operatorname{\textsf{DImp}}$. Hence, we need a parser for the language $\operatorname{\textsf{DImp}}^{-}$. This parser can me modelled as the composition of two SFTs. The first one, $\mathtt{Lex}$, has to recognises the lexemes in the language by identifying the language tokens. We consider the following set of tokens for $\operatorname{\textsf{DImp}}^{-}$. These tokens correspond to the terminals of $\operatorname{\textsf{DImp}}^{-}$ except for the punctuation symbols \mathfrak{P}\triangleq\{\mbox{\small;,{,},),\mbox{\tt$}}\} that will be directly handled by the parser.

[TABLE]

For each token $\texttt{T}\in\mathtt{Tokens}$, it is possible to define an SFT that recognises its possible lexemes and outputs the lexemes followed by the token name. Let us denote with $T_{\texttt{T}}$ the SFT that recognises the lexemes of the token $\texttt{T}\in\mathtt{Tokens}$, so, for example, $T_{\texttt{id}}$ is the SFT corresponding to the token id. The transduction is ${\mathfrak{T}}_{\mathtt{Lex}}:\Sigma^{\ast}\longrightarrow(\Sigma\cup\mathtt{Tokens})^{\ast}$ defined as:

[TABLE]

In order to build the $\mathtt{Parser}$, we design also the SFT recognising the correct sequences of lexemes and tokens that build respectively arithmetic, boolean and string expressions, and which correctly combines them in order to obtain objects in the language $\operatorname{\textsf{DImp}}^{-}$. Hence, $\mathtt{Parser}$ should implement the transduction function ${\mathfrak{T}}_{\mathtt{Parser}}:(\Sigma\cup\mathtt{Tokens})^{\ast}\rightarrow\Sigma^{*}$ is such that: $\mathbf{a}\in\operatorname{\textsf{DImp}}^{-}\;\Rightarrow\;{\mathfrak{T}}_{\mathtt{Parser}}({\mathfrak{T}}_{\mathtt{Lex}}(\mathbf{a}))=\mathbf{a}$. This means that the composition $\mathtt{Lex}\diamond\mathtt{Parser}$ allows sequences of $\Sigma^{\mathtt{A}}_{\tt\tiny Syn}$ which are in $\operatorname{\textsf{DImp}}^{-}$. The other implication does not hold since $\mathtt{Parser}$ allows also sequences of commands of $\operatorname{\textsf{DImp}}^{-}$ that contain syntactic errors due an erroneous number of punctuation symbols in $\mathfrak{P}$. This means that for example the sequence \>{}^{\prime}\!x\texttt{id}:=\texttt{assign}x\texttt{id}+\texttt{aop}1\texttt{const{}_{\mbox{\tt a}}};;;\mathit{skip}\texttt{skip}^{\prime} is allowed by $\mathtt{Parser}$ and given in output as it is. In Fig. 9 we can find the automaton $\overline{A}_{\mbox{\tt\tiny d+}}$, which is $\overline{A}_{\mbox{\tt\tiny d+}}$ where all the sequences which are not in $\operatorname{\textsf{DImp}}^{-}$ are erased.

This module is implemented in SEA using JavaCC [1]: given in input a BNF-style definition of a grammar $G$ it returns as output the parser for $G$.

Regex.

The so far obtained automaton can be used to synthesize a program by extracting the regular expression corresponding to the language it recognizes [8]. Let RE be the domain of regular expressions over $\operatorname{\textsf{DImp}}^{-}$, and $\mathtt{Regex}:\mbox{FA}\rightarrow\textsl{RE}$ be such an extractor. For instance, in the running example, $\overline{R}_{\mbox{\tt\tiny exp}}=\mathtt{Regex}(\overline{A}_{\mbox{\tt\tiny d+}})$ is the following regular expression (with standard operators in boldface):

[TABLE]

SEA implements the Brzozowski algebraic method [8] to convert an automaton to an equivalent regular expression.

ProgSyn.

Finally, we define $\mathtt{ProgSyn}$ implementing the function $\lbag\cdot\rbag_{\tt P}:\textsl{RE}\rightarrow\operatorname{\textsf{DImp}}$ that, given a regular expression ${\tt r}\in\textsl{RE}$, translates it into a program in $\operatorname{\textsf{DImp}}$. This is defined in terms of a translation function $\lbag\cdot\rbag:\textsl{RE}\rightarrow\operatorname{Comm}$ (erasing $) inductively defined on the structure of the regular expression${\tt r}$: Let us denote by${\tt d}{;}$the symbol${\tt d}$without the last ; (e.g.,$(x:=x+1;){;}=x:=x+1$)

[TABLE]

and \lbag{\tt r}\rbag_{\tt P}=\textsf{lab}(\lbag{\tt r}\rbag\mbox{\tt\})$. Hence, in our running example, the synthesis from the regular expression$\overline{R}{\mbox{\tt\tiny exp}}$, i.e.,$\overline{P}{\mbox{\tt\tiny syn}}=\mathtt{ProgSyn}(\overline{R}_{\mbox{\tt\tiny exp}})$, is the program

${}^{1.}g1:=\mbox{\bf rand}();$

${}^{2.}\mbox{\bf if}\ g1=1\ \{^{3.}x:=x+1;\};$

${}^{4.}\mbox{\bf if}\ g1=2\ \{$

    ${}^{5.}g2:=\mbox{\bf rand}();$

    ${}^{6.}\mbox{\bf if}\ g2=1\ \{^{7.}\mbox{\bf while}\ x>5\ \{^{8.}x:=x+1;^{9.}y:=x;\};\};$

    ${}^{10.}\mbox{\bf if}\ g2=2\ \{$

      ${}^{11.}x:=x+1;^{12.}y:=10;^{13.}g3=\mbox{\bf rand}();$

      ${}^{14.}\mbox{\bf while}\ g3=1\ \{^{14.}x:=x+1;^{15.}y:=10;$

                   ${}^{16.}g3=\mbox{\bf rand}();\};$

      ${}^{17.}x:=x+1;\};$

    \};^{18.}\mbox{\tt\}$

Soundness.

Next theorem proves the soundness of the approximate program synthesis. Safety (i.e., prefix closed) properties of dynamically generated code are soundly approximated by the synthesized program output of our analysis.

Theorem 6.1**.**

Let $\tt P\in\operatorname{\textsf{DImp}}$ containing ${}^{l.}\mbox{\bf reflect}({\tt s})$, and let $\operatorname{\mathbb{s}}\in\operatorname{\mathbb{S}}$ be the store on which $\tt P$ is executed. Then, for any $\operatorname{\mathbb{s}}^{\prime}\in\operatorname{\mathbb{S}}$ such that $\operatorname{\mathbb{s}}^{\prime}_{1}=\operatorname{\mathbb{s}}_{l}$ the partial semantics of any statement in the evaluation of ${\tt s}$ executed from $\operatorname{\mathbb{s}}^{\prime}$ is contained the partial semantics of the synthesized program, formally

[TABLE]

Termination.

As observed in Example 4.1, the use of reflection suffers from the potential divergence of unbounded nested reflection which goes beyond the control of widening. In this case, the divergence comes directly from the meaning of reflection and cannot be controlled by the semantics once we execute the reflect statement, hence also our analysis in this situation would diverge. SEA ensures soundness until a maximal degree of nested calls to reflect.

In order to keep soundness beyond a maximal degree of nested reflections, we can introduce a widening with threshold, i.e., the widening acts after a given number of calls to the abstract interpreter. This corresponds to fix a maximal allowed height of towers, fixing the degree of precision in observing the nesting of reflect statements. Given a tower height threshold $\tilde{\tau}$ such that, any tower higher than $\tilde{\tau}$ is approximated as computing any possible value for the program variables whose name is a substring of the string evaluated at $\tilde{\tau}$, therefore guaranteeing soundness. In order to check the height of towers, we need to enrich the store by including a new numerical variable $\tau$ counting the nesting level of reflection. Let $\operatorname{\mathbb{S}}^{\tilde{\tau}}:\operatorname{\textsf{PLines}}\rightarrow\mathbb{M}^{\tilde{\tau}}$ be this enriched domain, where $\mathbb{M}^{\tilde{\tau}}:\textsf{Var}\cup\{\tau\}\rightarrow\wp(\mathbb{Z})\cup\mathsf{Bool}\cup\wp(\Sigma^{*})\cup\mathbb{Z}$. Hence, we can define a new partial trace semantics $\langle\!|\cdot|\!\rangle^{\tilde{\tau}}$ on the transition system $\langle\operatorname{\mathbb{C}}^{\tilde{\tau}},\leadsto^{\tilde{\tau}}\rangle$ associated with programs in $\operatorname{\textsf{DImp}}$, where $\operatorname{\mathbb{C}}^{\tilde{\tau}}=\operatorname{\textsf{DImp}}\times\operatorname{\mathbb{S}}^{\tilde{\tau}}$ is the set of states in the transition system and $\leadsto^{\tilde{\tau}}\subseteq\operatorname{\mathbb{C}}^{\tilde{\tau}}\times\wp(\operatorname{\mathbb{C}}^{\tilde{\tau}})$ is the transition relation. Note that, the semantics of all statements does not change (supposing that $\operatorname{\mathbb{m}}_{\varnothing}\in\mathbb{M}^{\tilde{\tau}}$ associates [math] to $\tau$) except for reflect, whose new rule should count the number of recursive interpreter $\mathsf{Int}^{\#}$ calls.

7 Evaluation

SEA is a proof of concept, showing that it is possible to design and implement an efficient sound-by-construction static analyser based on abstract interpretation for self modifying code written in high-level script-like languages. It was not in the intention of SEA to be optimal and directly applicable to existing script dynamic languages, such as PHP or JavaScript. We implemented SEA in Java 1.8 and we tested it on some significant code examples in order to highlight the strengths and the weaknesses of the analyser presented. In particular, we evaluate the precision of our string abstract domain as compared to TAJS [27, 31, 2] (version 0.9-8), which is one of the best static analyser available for JavaScript based on abstract interpretation. To the best of our knowledge TAJS is the only tool statically analysing string-to-code primitives such as eval. This approach basically consist of a sound transformation of a JavaScript program $P_{\mbox{\tt\tiny eval}}$, containing eval, in another JavaScript program $P_{\mbox{\tt\tiny uneval}}$ where the eval statement is substituted with its argument, obviously converted in executable code, when this is possible, namely when the code to execute can be statically extracted as a constant form $P_{\mbox{\tt\tiny eval}}$. All examples in the next sections have been compiled from $\operatorname{\textsf{DImp}}$ into a semantics-equivalent JavaScript program, in order to perform the comparison with TAJS.

7.1 Precision

We performed more than 100 tests on programs of variable length, 70 of them are used to test the SEA performances and will be addressed in Sect. 7.2. We observed that the results can be classified in three different classes depending on some features of the analysed program. We report three significant examples in Fig. 10 where we also compare SEA with TAJS.

The first class of tests consists in all the programs where the string variables collect only one value during execution, i.e., they are constant string variables. A toy example in this class of programs is provided in the first row of Fig. 10, where the string value contained in $y$ is hard-coded and constant. In this case, both SEA and TAJS are precise and no loss of information occurs during the analyses. By using the value of $y$ in SEA as input of reflect, we obtain exactly the statement $x:=x+1;$ since $\mathtt{Exe}^{\sharp}$ behaves as the identity function. TAJS performs the uneval transformation and executes the same statement.

The second class of tests consists in all the programs where there are no constant string variables, namely variables whose value before the reflection is not precisely known being a set of potential string values. As toy example of this class of programs, consider the snippet of code in the second row of Fig. 10, a simplification of Example 5.2. In this case, since we don’t have any information about $x$ we must consider both the branches, which means that before the reflection we only know that $y$ is one value between ${}^{\prime}a:=a+1^{\prime}$ and ${}^{\prime}b:=b+1^{\prime}$.

If we analyse this program in TAJS, we observe that, after the if statement, the value of $y$ is identified as a string, since TAJS does not perform a collecting semantics and when it loses the constant information it loses the whole value. Unfortunately, this loss of precision, in the analysis of $y$, makes the TAJS analysis stuck, producing an exception when the reflection statement is called on the non constant variable. On the other hand, SEA computes the collecting semantics and therefore it keeps the least upper bound of the stores computed in each branch, obtaining the abstract value for $y$ modelled by the automaton $A_{y}$ in the second row equivalent to the regular expression $\>{}^{\prime}\!a:=a+1;^{\prime}+\>^{\prime}\!b:=b+1;^{\prime}$. Afterwards, the SEA analyser returns and analyse the sound approximation of the program passed to the reflection statement reported in the second row, which is the result of $\mathsf{Exe}^{\#}(A_{y})$.

In the last class of examples, the string that will be executed is not constant and it is dynamically built during execution. In the simple example provided in Fig. 10 the dynamically generated statement is $\>{}^{\prime}\!x:=x+1;x:=x+1;^{\prime}$. In this case, as it happened before, TAJS loses the value of $y$ (which is a set of potential strings) and can only identify $y$ as a string. This means that, again, the reflection statement makes the analysis stuck, throwing an exception. On the other hand, SEA performs a sound over-approximation of the set of values computed in $y$. In particular, the analysis, in order to guarantee termination and therefore decidability, computes widening instead of least upper bound between automata inside the loop. This clearly introduces imprecision, since it makes us lose the control on the number of iterations. In particular, instead of computing the precise automaton containing only and all the possible string values for $y$ (as in the previous case) we compute an automaton strictly containing the concrete set of possible string values. The computed automaton is reported in the third row and it is equivalent to the regular expression $\>{}^{\prime}x:=x+1;(x:=x+1;)^{*}\;{}^{\prime}$. The presence of possible infinite sequences of $\>{}^{\prime}\!x:=x+1;^{\prime}$ is due to the over-approximation induced by the widening operator $\triangledown_{3}$ on automata. Nevertheless, note that the widening parameter can be chosen by the user in order to tune the desired precision degree of the analysis: the higher is the parameter the more precise and costly is the analysis. It should be clear that, the introduced loss of precision increases the imprecision in any further analyses which uses the synthesised code. The synthesis of the program from the abstract value of $y$ returns the code reported in the third row: due to widening, as observed above, the command $\>{}^{\prime}\!x:=x+1^{\prime}$ can diverges.

A final observation on precision concerns the analysis of programs with unknown inputs. SEA considers an unknown input as a variable that may assume any possible string value. It is clear that in this kind of situations, TAJS necessarily get stuck whenever something depending on this unknown input is executed. Instead, SEA can keep some information since the abstract value consisting in any possible value is modelled by the automaton recognising $\Sigma^{*}$. In this way SEA can trace the string manipulations (substring and concatenation) on the unknown input, occurring during the execution.

7.2 Performances

We have tested the performances of SEA on a benchmark of 70 increasingly complex programs. Each program manipulates an automaton and finally it reflects the string value. The benchmark can be clustered in four families depending on the kind of string operations considered in the programs, determining the kind of automata manipulations performed by the analysis: add (programs where the manipulation of strings adds always new whole statements, this corresponds, in our analysis, to adding completely new paths in the automaton), concat (programs where the manipulation of strings concatenates new paths to those in the automaton), mixed (programs performing both the manipulations), code (programs in the add family, where we have added statements not manipulating strings, i.e., standard code not affecting strings).

Fig. 11-top, shows the results obtained from the benchmark concerning the string analysis without reflection: increasing the lines of code as well as the number of the automaton states, the execution time increases with an almost linear trend.

In Fig 11-bottom, we show the results due to string executability analysis. The total execution time increases more quickly of both than the length code and the automata dimension. But, it is worth noting that most of the time increase is due to the execution of the code generated by $\mathsf{Exe}^{\#}$ (the top black portion of the bars in Fig. 11-bottom), while the time cost of the analysis still increases with an almost linear trend. This outcome tells us that the string and executability analysis scale quite well on the source original code, but it gets worse on the code generated by $\mathsf{Exe}^{\#}$. We believe that this is due to the implementation of the synthesised code, which does not optimise the code generated by $\mathsf{Exe}^{\#}$. The optimisation of the generated code is a future work that deserves further investigation.

7.3 Analysis limitations and conclusions

SEA attacks an extremely hard problem in static program analysis, providing the very first proof of concept in sound static analysis for self-modifying code based on bounded reflection in a high-level script-like language. The main limitations of SEA are two: the simplicity of the programming language analysed, missing some important language features such as procedure calls and objects, and the fact that $\operatorname{\textsf{DImp}}$ is not a real script language. The choice of keeping the language as simple as possible is due to the aim of designing a core analyser focusing mainly on string executability analysis. We are conscious that, in order to implement a real-world static analyser we will have to integrate in our language several more sophisticated language features, but this is beyond this proof of concept. For instance, an extension would be the possibility of allowing implicit type conversion statements provided by many modern languages, such as PHP, JavaScript or Python.

As far as the second limitation is concerned, we already observed that this choice is due to the ambition of providing the most general possible architecture for executability string analysis. We believe that SEA is a step towards an implementation of a sound-by-construction analyser for reflection in real dynamic languages, since its design is fully language independent. In particular, the SEA architecture is invariant on the choice of the string abstraction, in our case FA, as well as the other state abstractions, in our case intervals, and on the language features, provided that their formal semantics is given.