Alexandre Bartel

Jacques Klein

Kevin Allix

Yves Le Traon

Martin Monperrus
email: martin.monperrus@univ-lille1.fr

Improving Privacy on Android Smartphones Through In-Vivo Bytecode Instrumentation

In this paper we claim that a widely applicable and efficient means to fight against malicious mobile Android applications is: 1) to perform runtime monitoring 2) by instrumenting the application bytecode and 3) in-vivo, i.e. directly on the smartphone. We present a tool chain to do this and present experimental results showing that this tool chain can run on smartphones in a reasonable amount of time and with a realistic effort. Our findings also identify challenges to be addressed before running powerful runtime monitoring and instrumentations directly on smartphones. We implemented two use-cases leveraging the tool chain: FineGPolicy, a fine-grained user centric permission policy system and AdRemover an advertisement remover. Both prototypes improve the privacy of Android systems thanks to in-vivo bytecode instrumentation.

INTRODUCTION

Android is one of the most widespread mobile operating system in the world accounting 48% market share [START_REF]Android takes almost 50% share of worldwide smart phone market[END_REF]. More than 300 000 Android applications available on dozens of application markets can be installed by end users. On the official market of Google (Google Play, formerly AndroidMarket), more than 10 000 new applications are available every month. 1 For the end user, downloading an application on his smartphone is similar to choosing an apple on an apple tree: he only sees the surface and has no evidence that there is no worm in it. Unfortunately there are many worms of different kinds waiting for entering smartphones such as malware leaking private data and adware calling premium-rate numbers.

In this paper we claim that a widely applicable and efficient mean to fight against malicious mobile applications is: 1) to perform runtime monitoring and interception; 2) by instrumenting the application bytecode and 3) in-vivo, i.e. directly on the smartphone. We present a tool chain to do this and present experimental results showing that this tool chain can run on smartphones in a reasonable amount of time and with a realistic effort. Before further introducing our contribution let us defend our key claim.

Why performing runtime monitoring and interception? Runtime 1 http://www.appbrain.com/stats/number-of-android-apps monitoring consists of observing the behavior of an application during execution, for instance by collecting certain metrics, or by intercepting all exchanges at the interface between the application and the rest of the system. Runtime monitoring is often used to achieve better privacy and security. Privacy can be improved for instance by tainting sensitive data [START_REF] Enck | Taintdroid: An information-flow tracking system for realtime privacy monitoring on smartphones[END_REF], or for Android, by enforcing a finer-grained permission model. Security can be improved for instance by detecting anomalies in I/O behavior [START_REF] Hofmeyr | Intrusion detection using sequences of system calls[END_REF]. In this paper, we discuss two case-studies involving runtime monitoring and interception, including an implementation of a fine-grained permission model on top of the Android software stack as proposed in [START_REF] Stavrou | Building security into off-the-shelf smartphones[END_REF] in order to maximize privacy. Why performing bytecode instrumentation? There are at least two manners to perform runtime monitoring and interception: modification of the Android software stack or bytecode instrumentation. Modification of the software execution stack consists of altering the operating system or the core libraries to intercept the required information. On Android, it means changing the underlying kernel, the Dalvik virtual machine or the Android framework. Unless convincing the Android consortium, this is rather limited in deployment since normal end-users have neither the rights (jailed phones) nor the ability to do so. Bytecode instrumentation is one of the lightest way to perform runtime monitoring on top of execution platform that can not be modified. In the context of a fine-grain policy enforcement for improving privacy, we are able -thanks to bytecode instrumentation -to enforce a fine-grained permission model of applications already deployed on Android smartphones without any modification of the Android software stack.

Why performing in-vivo instrumention directly on smartphones? Bytecode instrumentation can be done inside an app market, on a PC or even in the cloud. All of them have fundamental limitations. A key point of the success of Android is the sheer diversity of Android markets. Why should users bind themselves on apps of a single market and trust a single monopolistic instrumentation and detection process? About a PC-based instrumentation process, are users able to transfer an app and instrument it on their own PCs? would they be ready to wait hours or days for getting the instrumentation PC before safely using an instrumented app? We think that these are key blocking factors. Let us now consider a cloud-based service providing bytecode instrumentation. This may sound great but this solution is very much hampered by legal considerations: many countries forbid distributing binary applications to third-party services (e.g. France), similarly to certain terms of service of several markets (e.g. Google Play for Android). To us, an instrumentation process that is installed once and directly runs on smartphones is a way to overcome all these issues at once. However, to our knowledge, there is no proposal of such an instrumentation process on Android nor there is a study describing whether it is feasible to run it on real apps in a reasonable amount of time. This is the contribution of this paper:

• Section 2 describes a tool chain for instrumenting Android applications directly on smartphones.

• Section 3 describes the design and concrete implementation of kinds of bytecode instrumentation for the security and privacy of smartphones.

• Section 4 demonstrates the feasibility of running the whole tool chain in a reasonable amount of time.

• Section 5 discusses the related work and Section 6 concludes the paper.

TOOLCHAIN FOR IN-VIVO BYTECODE INSTRUMENTATION

This section presents a toolchain for performing bytecode instrumentation of Android apps in vivo, i.e. directly on smartphones.

Android Apps in a Nutshell

Android applications are written in Java, compiled into Java bytecode and finally converted to Dalvik bytecode, a bytecode format optimized for embedded devices. An Android application is a signed zip file (called apk or AndroidPacKage file) containing the Dalvik executable, the AndroidManifest.xml (application metadata), data (e.g. images), and the public key needed to check the provided signatures of all files.

Requirements

Instrumenting and repackaging an Android application so that it can run again is not straightforward. It consists of extracting the executable code from the application code, analyzing and instrumenting it, rebuilding a new working android application and signing it again, since the OS requires code to be signed.

We now devise a toolchain for this, based on the following requirements:

1. The Android OS must be unmodified (for the sake of a broad applicability, see intro);

2. The Dalvik virtual machine that runs Android applications must be unmodified, in particular in terms of configuration values such as the maximum heap size (for the sake of a broad applicability, see introduction);

3. The hardware that is used to instrument bytecode must be representative of common smartphones on the market.

Toolchain

To execute a whole analysis process of Android applications on smartphones, one needs to: 1) Extract code from Android application apk files; 2) Modify the extracted code with bytecode manipulation tools; 3) Rebuild a new Android application containing the modified code. Each step of this process requires a certain amount of time to be performed.

Those three steps can decomposed in five elementary steps, as shown on Figure 1 i) Extracting the Dalvik bytecode.. The first step, as shown in Fig. 1.(a-b), is to extract the classes .dex file from the apk file and convert it to Java bytecode classes that can be analyzed with standard unmodified Java bytecode analysis toolkits. For this step, we use the tool dex2jar2 .

ii) Instrumenting the bytecode.. In this step, we experiment with two different tools. ii.a) Soot. Classes are transformed to Jimple with the Soot analysis toolkit. Soot [START_REF] Vallée-Rai | Soot -a java optimization framework[END_REF] is an open-source analysis toolkit for Java programs. It operates either on Java source code or bytecode. It allows to analyze and transform programs. For instance, an intraprocedural flow analysis could determine if a variable can be null at some point in the code. Soot can also perform different callgraph analyzes, useful for specific bytecode instrumentation. Most analyses and transformations in Soot use an internal representation called Jimple. Jimple is a simple stack-less representation of Java bytecode We ported Soot for Android system by converting its Java bytecode to Dalvik and creating a wrapper Android application.

ii.b) ASM. We experienced that Soot is sometimes slow and requires a lot of resources (especially memory). Thus, we also run ASM for bytecode instrumentation. ASM [START_REF] Bruneton | ASM 3.0, a Java bytecode engineering library[END_REF] is a Java bytecode engineering library. One of its characteristics is that it is lightweight hence more suitable for running on systems constrained in term of memory or processing resource. It is primarily designed to manipulate and transform bytecode although it can also be used to perform some program analysis. It features a core API to perform simple transformations as well as a tree API to perform more complex bytecode transformations (which requires more CPU processing and memory space).

iii) Translating the modified bytecode back to Dalvik bytecode..

Once the classes are analyzed and modified by the analysis toolkit, they are transformed back into Dalvik bytecode using dx3 which generates the classes.dex file from Java class files. This step is illustrated in Fig. 1 as the edge c-d. iv) Rebuilding application..

As presented in Fig. 1.(d-e), after the fourth step, a new Andoid application is built. The newly generated classes.dex, the data and the Android manifest from the original application are inserted in a new zip4 file. v) Signing the modified application.. Android requires applications to bear a cryptographic signature. Hence, all files of the generated zip file are signed using a newly created couple of public/private keys (not represented on the figure), and the new public key is added to the zip (not represented on the figure). For this, we used the keytool and jarsigner Java programs on the Android platform (Fig. 1.(e-f)).

Recapitulation

We have devised a bytecode manipulation process on Android using standard tools. The following presents the design and implementation of two concrete bytecode instrumentations and an evaluation of the time required to run the whole process on real applications.

USE CASES

There are different scenarios in which it would be beneficial to manipulate and analyse Android applications (more specifically the bytecode of the application) directly on smartphone devices. In this Section we present two scenarios we implemented: AdRemover and FineGPolicy.

Advertisement removal

Android enforces a per-application policy-based security model: Either all parts of an application benefit from a given permission, or none of its parts. Furthermore, Android applications are distributed as self-sufficient packages, bundling together both specifically developed code and the third-party libraries they may need, such as binary-only advertisement modules.

Put together, these two facts mean that when a user grants permissions to an application, she actually grants permissions to components potentialy written by different entities, with different goals and different security levels. If this user does not want, or is forbiden by her organization's policy to transmit her location to advertisement companies, she is not offered a way to express that, for example, a newspaper app is allowed to send her location back to the app publisher so that she is presented with local news, but this app is not allowed to send location data to a third-party. In such a case, the user faces a dilemma: She has to either reduce her security and/or privacy level expectation, or refrain from using an otherwise valuable application.

Several Ad libraries have been shown to use the dynamic code loading facilities provided by Android to download code from the Internet [START_REF] Grace | Unsafe exposure analysis of mobile in-app advertisements[END_REF]. This raises potential security issues, since it may enable an attacker to inject malicious code that could leverage permissions granted to the host application.

Advertisement libraries also have a significant impact on mobile handsets stamina. Indeed, third-party advertisement modules can be held responsible for up to 65%-75% of energy spent in free applications [START_REF] Pathak | Where is the energy spent inside my app?: fine grained energy accounting on smartphones with eprof[END_REF].

Despite these issues, nearly half of the Android applications embeds third-party code to handle in-app advertisement [START_REF] Pearce | AdDroid: Privilege separation for applications and advertisers in Android[END_REF]. A significant proportion of ad-supported apps include at least two advertising libraries [START_REF] Shekhar | Adsplit: Separating smartphone advertising from applications[END_REF].

Overview

Static analysis can be used to detect privacy and security issues of Android applications [START_REF] Grace | Unsafe exposure analysis of mobile in-app advertisements[END_REF][START_REF] Grace | Systematic detection of capability leaks in stock Android smartphones[END_REF]. Our tool chain allows these kind of static analysis to be performed, and provides a framework for implementing mitigation of the privacy and security threats detected by static analysis.

To demonstrate sub-application granularity possibilities offered by our program manipulation tool chain, we devised a method to prevent an application subset (i.e. a library or a set of libraries) from performing potentialy privacy-violating or security-breaching actions.

In order to avoid the need to reverse engineer every code module one might want to inhibit, we propose a generic, heuristics-based approach to hinder a library's operations. We then employ this approach to remove advertisement from Android applications.

Implementation

Our AdRemover tool currently focuses on two widely used Android advertisement modules. We collected the Java package names used by these libraries and we configured AdRemover to operate only on classes that are part of those packages.

Potentialy dangerous code often requires IO operations, Network data transfer for data leakage, GPS polling for location tracking or phone network for sending short messages.

Unlike regular local and repeatable computation, developers should expext IO operations to fail on a regular basis, depending on unpredictable context. For example, all kind of communication will be impossible if the device has no network coverage whatsoever.

Building on this observation, we make the assumption that potentialy dangerous code have been placed by developers inside a Try/Catch block to cater for exceptions raised by IO failures.

As a first step, our tool leverages this assumption and inhibits every Try/Catch5 section of the targeted packages of the application. For every Try/Catch block it encounters, our tool obtains the type of the handled exception, creates such an exception object, and inserts an instruction that throws this exception at the very begining of the block.

To further hinder the third-party module's operations, our tool then renders inoperant a collection of utility methods. Our tool searches for every methods in targeted packages whose return type is either void or String (respectively), and replaces the body of the method by either a return; statement or a return(""); statement (respectively).

We produced two implementations of AdRemover: One using Soot and one using ASM.

Fine-Grained Permission Policy

Android framework relies on a permission-based model and follows an "all or nothing" policy. At installation time, users must accept or reject permissions requested by application developers. An application is installed only if all the requested permissions are accepted. There is no way to accept certain permissions (such as accessing the geolocalization data) and refuse others (such as connecting to the Internet) not directly related to the main functionalities of the application. Users are doomed to completely trust the application developers. Enck et al. [START_REF] Enck | On lightweight mobile phone application certification[END_REF] have pointed out that an application with several sensitive permissions is a real security threat. For instance if an application requests the permission to send SMS and to read the contact list, the contact list could potentialy be sent to a remote phone by writing it in a text message and sending this message by SMS. Enforcing a finer-grained permission model is a efficient way to achieve a higher level of privacy for the user.

We propose to give users the ability to specify their own set of admissible permissions (according to their own usage) and that a system enforces this user-defined policy. Running such user-level security policy is possible on unmodified Android systems by manipulating the application bytecode at installation time.

Overview

For a user-centric policy to exist, we need to instrument the bytecode of every application one whishes to control. All API calls which require one or more permissions are redirected to a policy service which allows or not the call.

When the instrumented application runs, the user-defined policy is enforced by the policy service. Indeed, for every instrumented method, the running instrumented application calls the policy service and the policy is checked. If the policy allows the original API method call, the API call is performed. Otherwise, a fake implementation is executed and returns a fake default value.

Implementation

Our tool enforces a user-defined policy at the user level (also called application level). It allows users which can not modify the system policy to enforce their own policy for a set of applications.

Instrumenting the Application.

The first step is to instrument the bytecode of an application one whishes to control to limit its permissions. This is illustrated in Figure 2 where application X is represented as a graph of method calls starting from node s. All method calls which require one or more permissions [START_REF] Felt | Android permissions demystified[END_REF][START_REF] Bartel | Automatically securing permission-based software by reducing the attack surface: An application to android[END_REF] are wrapped with code which:

1. asks the policy service if the application is authorized to call the method 2. according to the answer from the policy service either invokes the original method or the the fake method.

For instance, the getLocation(p1) method invocation of node 7 (which requires permission GPS) has been wrapped in the figure by a call to the policy service. If this call returs null the original getLocation(p1) is executed, otherwise a fake method is invoked.

There are N instrumentations where N is the number of API calls under consideration present in the application bytecode.

Defining the Policy.

The next step, as shown in Figure 3, is to define the policy regarding the instrumented applications. The user defines a set of allowed methods for each application. In Figure 3, only method getLocation() is allowed for application X .

Note that this step could be performed first to instrument only method calls which are not authorized by the policy. However, instrumenting every API method calls which requires one or more permissions makes it possible to change the policy at runtime.

Policy Service.

Finally, when the instrumented application runs, the policy is enforced by the Policy service as shown in Figure 4. For every instrumented method (here the original/instrumented method is get Location and its associated permission GPS) the running application calls policyCheck() (step A) and the policy is checked by calling policyHas() (step B). Method policyCheck() returns null if the policy allows the original method, a stub service reference otherwise. If the original method is allowed in the policy, the original method is called (this is the case in Figure 4, since step C returns null). Otherwise, the stub method corresponding to the original method is executed: step D would return a reference to the stub service 2 which implements the fake getLocation method. Here, stub 2 handling method getLocation is not executed .

Conclusion

AdRemover.

We implemented our advertisement removal tool with both soot and ASM. The whole application modification process takes less than 15 seconds on a recent PC laptop with the soot implementation and is even quicker with the ASM implementation.

We tested that our tool is functional by manually selecting one application from the dataset described in section 4.3. We made sure that the test application was using one of the two advertisement modules currently handled by AdRemover.

First we ran the unmodified test application on an Android devices, and confirmed that it was a working application, and that it displayed advertisements.

We then sent this application through our tool chain (with the soot implementation) running on a PC, and tested the modified application and confirmed it was still functional, and that no more advertisements were displayed. We monitored the network connection during the modified application test, and we found that it did not send any ad request anymore.

Finally, we processed the unmodified application again, this time running the bytecode manipulation directly on the smartphone. Running this modified application yielded the same results as with the application modified on a standard PC.

FineGPolicy.

We implemented the policy service as an Android service and the instrumentation code as a plugin for the static analysis tool Soot. We tested methods of two stub services we implementeted (ActivityManager, LocationManager) on one Android application on a desktop computer. The application is first instrumented and then repackaged into a new application which is then signed.

We ran the instrumented application on an Android device, and tested it with different policies. We were able to validate that the user-supplied policy was enforced as expected.

Those two implemented scenarios are further evaluated in Section 4.

EMPIRICAL RESULTS

In this section we present the results of applying the instrumentation process presented in section 2 and summarized in Fig. 1. The goal is to know: 1) whether it is possible to manipulate bytecode on smartphones given the restricted resources of the hardware. 2) whether it takes a reasonable amount of time.

Measures

We measured the execution time of the five steps of the instrumentation process on a set of 130 Android applications. This Android applications set is described in Section 4.3. We run the instrumentation process on three different Android smartphones whose configurations are presented in Section 4.2.

The feasibility of the whole process is measured by the time to pass every step of the toolchain (1: dex2jar, 2: Soot/ASM , 3: dx, 4: customZip, 5: signature). Moreover, the time to run each step is measured as well as the number of applications that successfully go through the step.

For the second step of the process (Step: Instrumenting the bytecode), we evaluate both ASM and Soot. For ASM , we measure the time required to instrument Java bytecode on the AdRemover case study. The AdRemover transformation leverages the ASM tree API and parses all classes to transform specific methods returning String or void as well as try/catch blocks. Soot is evaluated by measuring the time it requires to generate Java classes on both AdRemover and FineGPolicy case studies.

Experimental Material

We conducted the experiment on three Android-based smartphone devices. Their configuration is detailed in Table 1. Indeed, it is a parameter that influences the results of bytecode manipulation tools which are memory demanding. The main differences are the processor clock speed (0.8, 1.2 and 1.4GHz), the total amount of main memory (512, 768 and 1024MiB), the Android version (2.2, 2.3.4 and 4.0.3) and the maximum heap size of the Dalvik virtual machine (24, 32 and 48). Since the heap size controls the maximum memory that can be allocated it also controls the maximum number of objects that can be allocated simultaneously.

The number of cores also differs. However, we do not take advantage of multiple cores during the experiments. This hardware complies with requirement #3 mentioned in 2.2.

Dataset

The choice of a dataset is important because it reflects real world applications. Choosing a poor dataset may yield to better results (for instance if the code within applications is always small) but non useful results since they are non applicable on most real world applications. We apply the whole experimental protocol on a set of 130 Android applications randomly selected among the top 500 applications from the Android market 6 . They span various domains such as finance, games, communications, multimedia, system or news.

To give a better overview on these applications, Fig. 5 shows the key application metrics as boxplots. They indicate that most (75%) of Android applications have less than 614KiB of Dalvik bytecode, less than 602 classes, an average method degree smaller than 3. These applications also have less than 48 calls to a method of the Android API which require a permission. The most important results are the two former. Indeed, one of our hypothesis is that the processing time of a bytecode manipulation is highly dependent on the size of the bytecode. The other states that the time to create a new apk file from an original apk file also depends on the size of the original apk file. Hence, the lower the code and application size, the lower the processing time.

Dalvik to Java Bytecode Conversion

The conversion time from the Dalvik executable code to Java bytecode using dex2jar is shown in Fig. 6.

Observation 1 The classes.dex file size ranges from 7 to 4061 KiB. All dex files can be successfully converted to Java classes using a desktop computer. However, smartphone1 is unable to process any dex file. When using smartphone2 and tablet1, 26 and 11 dex files, respectively, caused the conversion Android applica- smartphone1 result is explained by the hard-coded maximum heap size of Android (32MiB or 48MiB). For the two other devices, crashes are to be attributed to the default 8KiB stack size. In total, 104 (80%) Android applications were successfully converted to a jar file on smartphone2 and 119 (91%) on tablet1.

Observation 2 We notice that the conversion time is linear with the size of the dex file (of the form a • X + b) for a Dalvik bytecode size less than 4000KiB. Using linear regression, we find that for smartphone2 a equals 0.069 and b equals 0.3. For tablet1 we have, 0.049 and -0.4.

Observation 3

The time to convert dex files to jar does not exceed 60 seconds on smartphone2 and tablet1 for most of the applications (75%).

Observation 4

The application with the biggest dex file (4000KiB) was successfully converted both on smartphone2 and on tablet1.

Conclusion 1

Converting Dalvik bytecode to Java bytecode is feasible and realistic since the conversion time does not exceed 250 seconds on our dataset of Android applications. Furthermore, there is a linear relation between the conversion time and the size of the Dalvik bytecode which enables us to theoretically predict the necessary amount of time to convert any size of Dalvik bytecode (if we extrapolate for size bigger than 4000KiB). For instance, the time to process the Android application with 10MiB of Dalvik bytecode would be 700 seconds for smartphone2 and 500 seconds for tablet1.

As we can see by looking at the result from smartphone1, the heap size has a real impact on the result and dex2jar needs a minimum heap size (24 < minSize <= 32) to process dex files. Since Android devices become more and more powerful the default heap size of the Android system grows. Indeed, in Android 2.2 the heap size is 24MiB, in Android 2.3.4 32MiB and in Android 3.0 48MiB. This continued growth allows to convert Android applications which have bigger Dalvik bytecode size.

Last but not least, the size of dex files is not the only factor which impacts the correct processing of dex2jar (the biggest application of our dataset was correctly processed), but its complexity also plays

Bytecode Manipulation and Use Cases Evaluation

Manipulation With ASM

Transformation time of Java bytecode using ASM is represented Fig. 7. In this experiment ASM does the AdRemover transformation described in 3.1. This transformation is based on the ASM tree API.

Observation 5 All 104 applications that were successfully transformed with dex2jar on smartphone2 were successfully processed by ASM. It processes every jar (up to 4MiB in size) in less than 60 seconds.

Observation 6 We notice that the transformation time is linear with the size of the jar files (of the form a • X + b) for a Dalvik bytecode size less than 4000KiB. Using linear regression, we find that for smartphone2 a equals 0.146. For tablet1 we have, 0.025.

Conclusion 2

Manipulating bytecode on smartphones using ASM is feasible. For all the bytecode analyzes and transformations that can be implemented with ASM, this is a promising result.

Manipulation With Soot

Recall that Soot was ported on the smartphone without any modification and that it was not designed to run on such platforms.

Observation 7 Out of the 130 Android applications 3 are correctly processed by Soot on smartphone2 and 19 on tablet1.

Observation 8 It takes less than 30 seconds to convert any jar which size is less or equal to 20KiB on smartphone2 whereas it takes less than 18 minutes to convert any jar which size is less or equal to 80.5KiB.

Conclusion 3

Using Soot directly on smartphones is feasible only for the smallest applications. However, when it successfully runs on a jar file it means that all classes of the jar files are loaded within Soot and that their bytecode can be manipulated. Soot successfully established the hierarchical relations between classes enabling ad- We assume that the heap size is the main blocking factor of using Soot on smartphones directly. To check this assumption, we conducted an experiment on a desktop computer consisting of analyzing our dataset of Android applications with different maximal heap sizes (from 5Mib to 50Mib by steps of 5Mib). Results are presented Fig. 8. Soot was able to process 67 applications with a heap size of 50Mib. Those results clearly indicate that maximum half of the Android applications could be processed with a heap size of 50MiB. Under the assumption that the heap usage (hence the maximum required size) is similar on the Java and Dalvik virtual machines, it means that the memory is actually the main blocking factor of using Soot on Android.

We also notice that Soot takes much more time on tablet1 which is running Android 4 than on smartphone2 which is running Android 2. We hypothesise that the problem emerges because of different implementations and/or configurations of the heap and memory management of the Dalvik virtual machine between different Android versions.

Java Bytecode to Dalvik Conversion

Once an instrumented application has been produced at the Java Conversion time from Java classes to the dex file using the dx tool is shown in Fig. 9.

Observation 9 Java Bytecode of 33 and 39 applications on smart-phone2 and tablet1, respectively, have been successfully converted to Dalvik bytecode.

Observation 10 Conversion time for jar files ranging from 20 to 400KiB does not exceed 80 seconds.

Conclusion 4

The Dx tool is one bottleneck. It can only correctly process 25 to 30% of the applications. This tool is used off the shelf and can be optimized to run on devices where resources are limited. For instance, instead of puting every Java classes in memory it could process class after class to limit memory consumption.

Creating a New apk File

The time taken to create an apk file from the instrumented Dalvik bytecode is shown in Fig. 10. Note that for this step, the input set is not the output of the previous step. For applications where the Java bytecode can not be converted to Dalvik code, we take as input the original dex file of the application. In this way, the problems of the previous step do not interfere with the results of this fourth step.

Observation 11 Nearly all 130 inputs were successfully processed. There is no clear relation between the size of the previous apk file and the creation time of the new apk. Some applications generate an exception because their size is too big and can thus not be processed by the zip utility.

Observation 12 For 95% of the applications it takes less than five seconds regardless of the device and of the size of the original apk file. There is no significant difference in the computation time between applications as it is the case in Fig. 6 and9.

Conclusion 5

It is feasible to create apk files on smartphones. The time to create a new apk file is negligible compared to the time to convert bytecode or to manipulate bytecode with Soot. The difference in the computation time only reflects the difference of CPU speed. Signing time of applications is represented in Fig. 11.

Signing the Generated apk

Observation 13 Almost all 130 Android applications were successfully processed. There is no clear relation between the size of the apk file and the signature time of the apk file. Some applications generate an exception because their size is too big and can thus not be processed (14 on smartphone2 10 on tablet1).

Observation 14 For 95% of the applications a maximum of 12 seconds is required to sign the application regardless of the device and the size of the apk file.

Conclusion 6

It is feasible to sign apk files on smartphones. Similarly to the apk file creation step, the computation time is negligible. The difference observed between smartphone1 and smart-phone2 reflects the difference in their CPU clock frequencies.

Conclusion

Feasibility

Those experiments show that it is feasible to manipulate bytecode directly on Android devices. The most expensive steps of the process are the conversion of Dalvik to Java bytecode and vice versa, and the Soot bytecode manipulation step. However, depending on the manipulation to be made on the bytecode, ASM could be sufficient. Table 3 is a summary of all the experiments for smart-phone2 and highlights the feasibility of the whole approach. Values for the sum of all steps for the Soot and ASM version are computed from the application that successfully passed through all steps. For an ASM-based instrumentation it takes a median time of 120 seconds to process an application. We think that users would agree with waiting 2 minutes before starting using an application, if they are provided more guarantees with this instrumentation process enabling e.g. malware detection. For the biggest application, it takes 952 seconds, i.e. less than 16 minutes which also seems reasonable to us, given that the vast majority of Android application are much shorter and therefore need less time to be processed.

Blocking Factors and Optimization Opportunities

According to our analysis, the main blocking factors which can be overcome are the following.

The maximum heap size required to analyze and transform applications is an issue for many transformation steps. We think that this issue will be easily solved by 1) the next generation of more powerful hardware and 2) the upcoming versions of the Android OS and virtual machines which will likely have a significantly higher maximum heap size (e.g. Android 4 heap size is set to 48MiB).

Actually, Dalvik to Java conversion and Java to Dalvik conversion are two very time expensive steps. They are required to use unmodified versions of Soot and ASM. However, those steps could be skipped if we had either 1) an ASM-like library for manipulating Dalvik bytecode or 2) a bi-directional transformation directly from Dalvik bytecode to Jimple bytecode which are both register based. We are now studying the required effort to design and implement such tools.

Last but not least, we have used tools in a completely unmodified version (in particular dex2jar, Soot). Most of these tools were not meant to run on platforms with limited resources and were never optimized as such. In other terms, we believe that there are probably many optimization opportunities in terms of CPU and memory consumption.

To sum up, our results show that we can reasonably imagine to manipulate the bytecode on 100% of our dataset applications within at most minutes.

Threats to Validity

Let us now discuss the threats to validity of our experimental results.

Implementation Bug: Our results hold as far as there is no serious bug in the implementation of any of the five programs involved in the five steps, as well as in the glue and measurement code we wrote.

Dataset Generalizability: Our dataset may not be representative of the Android applications used in the real-world.

Linear Extrapolation: The linear relations we establish for the Dalvik to Java and the Java to Dalvik conversions holds for bytecode size less or equal to 300KiB. It may not hold for bytecode whose size is bigger. In the presence of non-linear singularities, it may not be possible to analyze large applications.

Bytecode Manipulation Time: Our results on the bytecode manipulation time were obtained with relatively simple transformations. It may be the case that complex transformations are not of the same order of magnitude. However, for the use cases presented in Section 3, the instrumentation that is needed is mostly monitoring and proxying. We see no reason why this may take a much longer time.

RELATED WORK Monitoring applications.

The idea of monitoring smartphone applications at runtime recently emerged, due to the explosion of "mobile" malware and the increasing sophistication of mobile OS.

Bose et al. [START_REF] Bose | Behavioral detection of malware on mobile handsets[END_REF] aimed at detecting malware based on their behavior at runtime. For this, they added hooks in the Symbian OS emulator to track OS and API calls. In other words, malware detection is only achieved in the emulator, in vitro. On the contrary, we aim malware detection in live user environments, in vivo and showed in this paper that is it is feasible in the mid-term.

Step Enck et al. [START_REF] Enck | Taintdroid: An information-flow tracking system for realtime privacy monitoring on smartphones[END_REF] presented a runtime monitoring framework called TaintDroid, which allows taint tracking and analysis to track privacy leaks in Android. Their prototype is based on a modified version of the Dalvik virtual machine which runs Android applications. Similarly, Costa et al. [START_REF] Costa | Runtime monitoring for next generation java me platform[END_REF] extends the Java virtual machine for mobile devices (Java ME) for adding runtime monitoring capabilities. On the contrary, our feasibility study indicates that it is possible to achieve runtime monitoring in an unmodified Android system.

Recently, Burgera et al. [START_REF] Burguera | Crowdroid: behavior-based malware detection system for android[END_REF] presented an approach to detect malware based on collected operating system calls. Runtime monitoring can be done at different granularity levels. While the approach described by Burgera et al. is at the OS call grain, we aim at providing runtime monitoring at the API call level, i.e. much more fine-grained and closer to the application domain of mobile applications.

Davis et al. [START_REF] Davis | I-arm-droid: A rewriting framework for in-app reference monitors for android applications[END_REF] presented an Android Application rewriting framework prototype, and discussed its use for monitoring an application, and for implementing fine-grained Access Control.

Finally, Shabtai et al. detects malware based on the collection and analysis of various system metrics, such as CPU usage, number of packets sent through the Wi-Fi, etc. This is an indirect way of detecting malware behavior. Again, by monitoring API calls, we observe the application behavior directly. The empirical results presented in this paper shows that this is actually possible.

Advertisement Permissions separation.

Shekhar et al. [START_REF] Shekhar | Adsplit: Separating smartphone advertising from applications[END_REF] proposed a new Android advertisement system that would allow to have an application and its advertisement module to run in different processes, and hence have a different permission set. This new system has to be manually inserted into the application during the development phase, since no automated application modification is provided.

Pearce et al. [START_REF] Pearce | AdDroid: Privilege separation for applications and advertisers in Android[END_REF] made the case for a Advertisement framework that would be integrated inside the Android platform. Every developer would be able to use the custom-built API that would be available on Android devices. This approach requires a modification of the Android framework, and that a given user has a device with a Android version embeding this advertisement system.

Permission Policy.

Reddy et al. [START_REF] Reddy | Application-centric security policies on unmodified android[END_REF] claim that security of the Android platform would be improved by creating "application-centric permissions" i.e. permissions expressing what an application can do rather than current Android permissions that express what ressource an application can use. They wrote a library that allows the 'applicationcentric permissions" to be managed. In addition, they started developing a tool called "redexer" whose aim is to automatically rewrite existing applications in order for them to use these new permissions.

Nauman et al. [START_REF] Nauman | Apex: extending android permission model and enforcement with user-defined runtime constraints[END_REF] extended the Android policy-based security model so that it can enforce constraints at runtime. The tool they created, called Apex, allows a user to express limits imposed to an application's use of any permission: For example, it becomes possible with Apex to grant the SEND_SMS permission to any given application while ensuring that this application will not be able to send more than a user-defined amount a text message each day. The user also has the possibility to change her mind, and to totally prevent the application from sending short messages; This is an important improvement over the stock Android OS because it allows users to specify a much finer-grained policy, instead of having to choose between either granting an application every permission it may request at installation time or not installing this application. However, this approach requires modifications deep inside the Android framework, and hence would need to be backed by Google and integrated into future versions of Android if it was to be widely used.

CONCLUSION

The toolchain we propose and evaluate in this paper is a milestone that respond to the recent claim of Stravou et al. [START_REF] Stavrou | Building security into off-the-shelf smartphones[END_REF] about the urgent need for bytecode analysis to perform in-vivo security checks on mobile phones. We have 1) proposed a tool chain allowing the manipulation, instrumentation and analysis of Android bytecode and 2) shown that it is possible to run the tool chain in a reasonable amount of time directly on unmodified smartphones with unmodified Android software stack. Concretely, our experiment shows that with ASM, 39 (30%) applications of our dataset can be instrumented in less than 952 seconds (with a median time of 120s). Moreover, we discuss specific limitations that we observed, such as the hardcoded heap size of Android systems.

We believe that those various limitations could be quickly overcome, at least for two main reasons. First, we used off-the-shelf Java tools that are not optimized to run on environments where resources (memory/CPU) are limited, and there may be possibilities of significant optimization. Second, the hardware and OS evolution of smartphones will make it possible to process ever bigger Android applications (for instance, on Android 4, the default size of the heap is twice as large as in the previous version).

We are currently working on other use cases. In particular, we are implementing a behavioral malware detection approach that is set up and run on the smartphone. This approach involves instrumenting the bytecode to redirect API method calls to stubs responsible for detecting malicious behavior.

  : i) Extracting and converting the Dalvik bytecode into Java bytecode(step a-b), ii) Manipulating the bytecode (steps b-c), iii) Translating this representation back to Dalvik bytecode (step c-d), iv) Rebuilding a new apk file (step d-e) and v) Finally signing all files with a new private key (step e-f). Let us now discuss the tools that are used in each step.

Figure 1 :

 1 Figure 1: Process to Generate New Apk

  (getLocation); if (stub == null) r = obj.getLocation(p1); else r = stub.getLocation(p1); step1 X app. X app.

Figure 2 :Figure 4 :

 24 Figure 2: Step 1: Instrumenting Application Bytecode

Figure 5 :

 5 Figure 5: Descriptive Statistics of our Dataset (boxplots)

Figure 6 :

 6 Figure 6: Dalvik to Java Bytecode Conversion Time.

Figure 7 :

 7 Figure 7: Transformation Time of Java Bytecode with ASM

  on the Number of Correctly Processed Applications

Figure 8 :Figure 9 :

 89 Figure 8: Influence of the Heap Size on Jimple Transformation

Figure 10 :

 10 Figure 10: Creation Time of a New apk File

File

Figure 11 :

 11 Figure 11: Signing the Generated Apk File

Table 1 :

 1 The Hardware used in our Experiment

	Name	Processor	Memory Android Heap Size
	smartphone1 ARM 800MHz, 1 core 512MiB 2.2	24MiB
	smarthpone2 ARM 1.2GHz, 2 cores 768MiB 2.3.4	32MiB
	tablet1	ARM 1.4GHz, 4 cores	1GiB 4.0.3	48MiB
	2.8
	2.6
	2.4
	2.2
	2

Table 2 :

 2 Summary (for Smartphone2)

	Name	Min.	Avg.	Median	Max.	App.	Feasibility
		Time	Time	Time	Time
		(s)	(s)	(s)	(s)
	Conversion .dex to .jar (a-b)	0.22	43.76	28.9	250.2	104/130 (80%)
	Analyzing .jar with Soot(b-c)	25.8	76	26	187.7	3/130 (2.3%)
	Analyzing .jar with ASM(b-c)	1.55	90.45	65.1	594.67	129/130 (99.2%)
	Conversion class to dex (c-d)	0.09	28.07	22.8	71	39/130 (30%)
	Creating new .apk (d-e)	0.06	1.89	0.87	15.1	119/130 (91.5%)
	Signing new .apk (e-f)	0.71	3.85	3.0	21.67	116/130 (89.2%)
	All Steps with Soot (a-b-c-d-e-f)	26.88	153.57	81.57	545.67	3/130 (2.3%)
	All Steps with ASM (a-b-c-d-e-f) 2.63	168.02	120.67	952.64	39/130 (30%)
	Step Name	Min.	Avg.	Median	Max.	App.	Feasibility
		Time	Time	Time	Time
		(s)	(s)	(s)	(s)
	Conversion .dex to .jar (a-b)	0.19	25.6	17.85	158.9	119/130 (91.5%)
	Analyzing .jar with Soot(b-c)	24.2	76	352	1054	19/130 (14.6%)
	Analyzing .jar with ASM(b-c)	1.55	11.3	7.06	65.5	119/130 (91.5%)
	Conversion class to dex (c-d)	0.09	29.5	20.2	80.2	33/130 (25.3%)
	Creating new .apk (d-e)	0.03	1.6	0.5	20.9	121/130 (93.1%)
	Signing new .apk (e-f)	0.4	3.4	1.91	27.3	120/130 (92.3%)
	All Steps with Soot (a-b-c-d-e-f)	24.91	136.1	392.46	1341.3	19/130 (14.6%)
	All Steps with ASM (a-b-c-d-e-f) 2.26	71.4	47.52	352.8	33/130 (25.3%)

Table 3 :

 3 Summary (for Tablet1)

http://code.google.com/p/dex2jar/

using com.android.dx.command.Main.class from the Android SDK

using the java.util.zip library

Although the soot implementation of AdRemover performs manipulation in the Jimple language, we stick here to Java terminology for simplicity

http://play.google.com


Chouki Tibermacine
email: chouki.tibermacine@lirmm.fr

Mohamed Lamine Kerdoudi
email: lamine.kerdoudi@gmail.com

Migrating Component-based Web Applications to Web Services: towards considering a "Web Interface as a Service"

Keywords: Web Component, Web Service, Code Migration and Java EE

Web component-based development is a challenging development paradigm, whose attraction to practitioners is increasing more and more. One of the main advantages of this paradigm is the ability to build customizable and composable web application modules as independent units of development, and to share them with other developers by publishing them in libraries as COTS (Commercial Off The Shelf) or free components. In parallel, since many years, Web services confirmed their status of one of the most pertinent solutions for a service provider, like Google or Amazon, to open its solutions for third party development. In this paper, we present an approach to migrate existing web componentbased applications to a set of primitive and composite Web services and deploy them on a web service provider. This transformation helps server-side web application developers in transforming their "user interface"-based web components into a set of web services intended for remote code extensions. We implemented our solution on a collection of Java-related technologies. Java EE components are the input of the proposed implementation, and a set of Java Web services with their WSDL interfaces, choreographies and orchestrations of these services are provided at output.

I. INTRODUCTION: CONTEXT AND MOTIVATION

Since the end of the nineties, Web component-based development has emerged as a new solution which aims at decoupling Web application code modules, and making them reusable and customizable software entities. Indeed, a step has been taken forward in modularizing Web applications and thus separating business logic code, from view, data model and operational control one. One of the technologies leading this field is Java EE and its numerous frameworks like Struts or JSF. Web modules in such technologies are entities that can be used and reused in different applications and customized according to the application requirements. Many libraries in the Internet provide access to Web COTS (Commercial Off The Shelf) like ComponentSource R 1 or free Web components like RichFaces from JBoss or Apache's MyFaces.

These technologies are currently one of the most interesting solutions for developing large and complex applications 1 ComponentSource Website: http://www.componentsource.com/index.html with highly critical requirements on maintainability and portability. However, after deploying a Web componentbased application within an application server, there is no means to directly publish some services of the application for third party development. Even if stubs can be generated and provided for client applications, these stubs are generally language-dependent (only Java clients can use stubs generated for EJBs) and cannot be published, as they are, in libraries of services. Recently, the EJB 3.x specification introduced some annotations to enable developers to publish some methods in a bean as services. However, this is possible only for individual methods, and not for compositions of them which we found in real-world business logic. In addition, this solution is well suited for new software, but not for legacy one, whose source code is not always accessible. The same observations can be made on Eclipse tools (WTP project), which allow to generate Web services starting from individual methods in Java classes.

Besides, since many years, Web services have confirmed their status of one of the most pertinent solutions for a given service provider, like eBay (auction and shopping), Amazon (retail) or FedEx (logistics), to open their solutions for third party software development. Web services are functionalities based on standards which are "programming language"and "execution platform"-independent, like WSDL or SOAP. New applications with thin or thick clients can be built and can access these functionalities, by simply formulating requests, which embed XML-based (SOAP) messages, to the chosen Web service providers. The same kind of messages are returned back to these applications, containing the results (answers to their requests). Upon these results, more actions can be performed by these new applications in order to implement some new business-logic.

In this paper, we present an approach (Section III) to build Web service-oriented architectures starting from existing Web component-based applications and deploy them on a Web service provider. In this way, developers of Web components can offer the opportunity to other developers to build extensions of the services provided by their artifacts. This transformation goes through several steps, starting from the parsing of Web components' contents and formatting Web interfaces as operations embedded in services, and compositions of these services, and ending by deploying and indexing the generated services.

We implemented our solution (Section IV) on a collection of Java-related technologies. Java EE components are the input artifacts of the proposed implementation, and a set of Java Web services and choreographies/orchestrations of these services are provided at output. We illustrate this approach on a simple example of a simulated version of a real-world Web application (Section V). Before concluding and presenting the ongoing and future work at the end of this paper, we make a summary of the related work (Section VI). In the next section, we introduce a simple example of a Web component that is used in the remaining of the paper to illustrate our proposals.

II. ILLUSTRATIVE EXAMPLE

We consider here a simple Web component, which is composed of the following subcomponents:

• a BMI_Calculator calculates the Body Mass Index (BMI) starting from the values entered by the user via the Web interface implemented in this component. These values are the mass and the height of the person 2 .

• a DietaryAdvisor asks the user to enter her/his age and gender, and to check some boxes representing the dietary habits and the eating disorders of the person (excessive meat eating, mid-night hungers, ...). It provides a summary of the dietary guidelines.

• an EMailer asks the user to enter her/his e-mail address and sends her/him an e-mail with a detailed list of dietary guidelines. The Web component in this example is a Java EE EAR (Enterprise ARchive) which contains some Web and EJB modules. The Web modules are implemented using the JSF (JavaServer Faces) framework, which binds the input values got from the HTML forms (rendered by some JSF components) to JavaBeans. The EJB modules connect to a database via JPA (Java Persistence API) to get the stored information about the dietary guidelines. They also use javax.mail to send e-mails via an SMTP server.

Suppose now that a third-tier developer would like to implement a more sophisticated application based on the component services introduced above. This developer would like to provide a solution to sell diet nutrition and dietary recipes. She/he wants to use the output given by the DietatyAdvisor to advertise her/his products before sending the e-mail to the user.

In order to implement this solution, the third-tier developer should either: i) re-develop the business logic implemented in the Web components introduced above, ii) ask the provider of these components for the binaries (or

2 BM I = mass(kg) height 2 (m 2 )
source packages of these components) and deploy them on the same name space of her/his solutions, iii) or ask for a remote access to these components. It is evident that the first alternative is not realistic for this developer (a time consuming task). The other two alternatives are not good choices neither. The original developers of the Web components would certainly not give access to their software artifacts (binaries or sources) for many technical reasons (security, data inconsistency, etc.).

One of the best solutions for this third-party development is to transform the previous Web component-based architecture to obtain a set of Web services which are described below3 :

• DietaryAdvising: a Web service composed of three operations :

-calculateBMI which receives as input two messages of type Integer (the height in centimeters and the mass in grams) and returns a float value which represents the BMI. -getBMI_Category which receives as input the BMI value and returns the BMI category: Underweight, Normal Weight, Overweight, or Obesity. -provideSummaryDG which receives as input four messages: a message of type integer for the age, a boolean message for the gender, a float one for the BMI and a complex XML schema type for the dietary habits. This operation returns a summary of the dietary guidelines.

• MailSending: a Web service with a single operation for sending an e-mail. This operation declares four messages: three input strings for the e-mail address, the subject and the body of the message, and a boolean output message which represents the message sending success or failure. As stated in the introduction, since many years Web services have confirmed their status of highly secure, portable and flexible solutions for distributed service computing. In this way, the application extension scenario introduced above can easily be implemented by remotely invoking the Web service operations. The extension of the Healthy Diet application can be built as a BPEL (Business Process Execution Language) process invoking successively the three operations of the first service. It then adds the corresponding advertisement information, and at last invokes the MailSending service.

The transformation process which allows the generation of the Web services above is presented in detail in the next section. We explain, among other issues, how the different operations in Web components are extracted and grouped in Web services. In addition, we show how elements in Web interfaces are formatted as SOAP messages, and how

III. PROPOSED APPROACH

The transformation of Web components into Web services is a six-step process. This is illustrated in Figure 1 and each step is detailed in the following subsections.

A. Operation Extraction

First, a recursive parsing of the different Web component elements is performed to extract the potential set of Web services. All operations in classes and other structured code elements are saved. In addition, the code present in programs executed at the server side (JSP pages, for example) is grouped within new operations and formatted to be executed as stand-alone code. For example, all code present in scriptlets of JSP pages is grouped and formated within a single operation. In the next subsection, we explain how this formatting is performed.

B. Input and Output Message Identification

The input and output messages related to each operation in Web services are extracted starting from the parsed elements in the Web components. For operations in classes and other structured code elements, the parameters and the returned values are formatted as (respectively, input and output) SOAP messages. The code present in the other programs (like JSP pages) is parsed to extract the input values received in the HTTP requests (by identifying statements getting values from HTTP requests). Their types are deduced from the parsed code by analyzing type casts and other conversion statements. The contents produced by theses programs, which are viewed at the client side (like JSP expressions or out.println(...) statments), are considered as returned values. The types of these values are extracted from the code and defined in the generated SOAP messages.

For example, in the BMI_Calculator component of the previous section, two messages are defined starting from the request.getParameter(...) statements in the JSP file. They correspond to the mass and height of a person. At the beginning, these inputs are defined as variables of type String. But, after parsing the JSP (Java) code that extracts these values, we deduce the final data type, which is int (integer). Nevertheless, the conversion, the cast and the request.getParameter(...) statements will be deleted from the new code. The returned value is the result calculated by a JavaBean method getBMI() bound to the Web interface using a JSP expression. This is used to create an output SOAP double message.

C. Operation Filtering

After that, the non-pertinent operations of the Web services are eliminated from the starting set according to a collection of filtering constraints. These constraints are boolean expressions which are represented by OCL (Object Constraint Language [START_REF] Omg | Object constraint language specification, version 2.0[END_REF]) expressions that can be added, modified or removed by developers. The OCL expressions are limited to invariants. They navigate in a simple MOF [START_REF] Omg | Meta object facility (mof) 2.0 core specification[END_REF] metamodel, which is a simplified excerpt of the UML metamodel (related to operations) extended with some basic features. All expressions have, as a context, an instance of the Operation metaclass. OCL has been chosen because of its simplicity [START_REF] Briand | An experimental investigation of formality in umlbased development[END_REF] and the existence of a good tool support (OCL Toolkit [START_REF] Dresden | Ocl compiler web site[END_REF], Eclipse MDT/OCL [START_REF]Model development tools website[END_REF], ...).

An example of a filtering constraint is given below. This OCL constraint states that operations which use the session standard script variable must not be selected.

not (self.body.usedType ->includes(t | t.name='HTTPSession'))

At the end of this step, the developer is asked to choose among the selected operations those which are not pertinent as parts of the published Web services.

D. Operation Distribution

The extracted operations are distributed on multiple Web services based on the following criteria:

1) Spreading Criterion: Similar extracted operations are spread out in different Web services. This ensures some level of reliability and correctness in the published Web services. On the one hand, if a Web service does not provide correct quality requirements (like availability or efficiency) for users of an operation within this service, another service containing a similar operation can be found (reliability). On the other hand, a service should not conceptually (from a correctness perspective in the description of a Web service) provide two or more similar operations (operations that provide the same functionality).

Similar operations are identified following some similarity measures. In the current implementation, a solution based on operation signatures has been defined. It compares the operations' names, returned type and parameters.

2) Grouping Criterion: In this step, the highly coupled operations are grouped together in a single Web service. This grouping increases at the same time the performance and helps developers in the evolution and maintenance of the generated services. In order to group operations into a single Web service, we measure the coupling between operations by analyzing the static invocations between operations.

E. Composite Web Service Creation

In this step, the potential dependencies between the different selected operations in the Web services are identified. There are two kinds of dependencies between operations: operation invocation dependencies and Web navigation relationships. The first kind of dependencies gives rise to Web service choreographies and the second to Web service orchestrations. These are detailed below:

1) Web Service Choreography Creation.: All calls between operations in the code are captured. If the called operations are published in the same Web service of the caller operation, nothing is done, the calls are left as method invocations. If the called operations are present in the other published Web services, we check if these services are deployed remotely or in the same server, and if they run in the same virtual machine, as the caller service. If the services run in the same execution context, method invocations are left as they are. Otherwise, these operation dependencies are replaced by Web service requests.

In this way, we build composite Web services as codelevel choreographies.

In the example presented in Section II, the operation calculateBMI() calls some other operations to make arithmetic calculations. These operations (power(n,m), division(x,y), mass and height conversion) are extracted and assembled in two different Web services: calculationWS and conversionWS. The calculateBMI() operation starts first by invoking the mass conversion operation of the conversionWS to transform grams into kilograms. This is done through the call to the division operation of calculationWS. Then the centimeters are transformed into meters using the height conversion operation (based on the same calculation operation). At last the operations power(...) and division(...) are called to get the BMI's value. This is a simple but illustrative example of a choreography created starting from the BMI_Calculator Web component.

2) Web Service Orchestration Creation.: Navigation documents such as JSF faces-config files and their navigation rules are parsed. This allows the identification of the different relationships between Web pages, and potential collaborations of the different Web services extracted from these pages. This task is implemented according to the following algorithm: In this algorithm, we first create a process, and for each navigation rule in the Web navigation document of the parsed Web component, we identify the source operation (Line (04)). The source operation corresponds to the operation that has been generated starting from the navigation's source Web page. The same thing is done for the destination Web page (Line (19)).

As specified in the algorithm, a navigation rule contains three elements: i) a source view (Line (04)), which represents the Web page(s) from which the navigation started (e.g., the page presenting the form for calculating the BMI in the example introduced previously: bmi.jsp); ii) a destination view (Line (19)) that corresponds to the Web page(s) to which the user will be automatically directed (e.g., the Web page presenting the interface of the Web component DietaryAdvisor: diet.jsp); and iii) an execution condition (Lines ( 14) and ( 17)) which contains an expression and a value (e.g., the expression is the call to the JavaBean operation for getting the BMI category in the Web component: #{diet.getBMI_Category}, and the value is "Obesity").

For each navigation rule, we first test if the source operation has already been called in the process while parsing another navigation rule (Line (05)). This ensures that operation invocations are not duplicated. In the case of an operation which has already been invoked in the process, we just get the returned value (Line [START_REF]Oasis consortium website[END_REF]). This kind of values are stored after each operation invocation (see Lines (09) and ( 23)). Then, we compare the value obtained after invoking the operation defined in the expression of the condition and the value of this condition (lines ( 16) and ( 17)). If the two values are equal, then we invoke the corresponding destination operation (Lines (19) to ( 22)).

In the example presented in Section II, we generate a BPEL (Business Process Execution Language [START_REF]Oasis consortium website[END_REF]) process (HealthyDietProcess). In its description, the process first invokes the calculateBMI operation of the first service. Then, it stores the result into a variable and invokes the second operation of the same service to get the BMI category, using the content of the variable as a message. If the returned value, stored in a second variable, is different from "Normal Weight" (is equal to the other three possible BMI categories), the third operation is invoked, using the stored BMI category and other information (dietary habits and eating disorders), to get the corresponding dietary guideline. At last, it invokes the sendMail operation with the necessary data.

In orchestration creation, before each operation invocation (see Line (21) in the algorithm above), we prepare the list of parameters. A matching of the variables' names in the orchestration and the arguments of the operation to be invoked is performed. This ensures that arguments are passed in the correct order.

At last, the two Web services, together with the BPEL process, which is exported as a Web service, are deployed in a server and indexed in the Seekda Web service search engine 4 .

F. Web Service Deployment and Indexing

All the generated Web services are made available for other developers on the Internet. The validated set of Web services (composite and primitive ones) are deployed on an application server chosen by the developer/administrator of the Web component-based application. All system configuration parameters should be specified in order to perform this activity. This can be fully supported by the prototype tool we developed. The next task in this step is an assistance activity where the developer is asked to log in or sign up for a new account in the Seekda search engine. The services are then indexed in Seekda Web server.

IV. TOOL-SUPPORT FOR THE PROPOSED APPROACH

We implemented the proposed solution as a prototype tool called WSGen: Web Service Generator. The components parsed by WSGen are Java Enterprise archives: EARs (Java Enterprise Archives), JARs (Java Archives) and WARs (Web Archives). JSPs, Servlets, JavaBeans, Enterprise JavaBeans and traditional Java classes in these archives are extracted. These files are analyzed to identify the different methods which will represent the potential future operations of the generated Web services. A particular processing is performed on JSPs and servlets to generate new operations. Starting from request.getParameter(...) statements, input parameters are generated, and starting from out.print(...) and JSP scriptlet expressions, output parameters are created. All tasks related to the parsing and code generation have been implemented upon the JaxMe Java Source5 , HTML Parser6 and JspC7 tools. Besides, MDT OCL has been used for OCL interpretation. OCL constraints are checked on an Ecore instance (representing the metamodel defined for operations) created starting from the parsed operations' code.

Finally WGen uses a Tomcat server associated with the Apache implementation support for Web services, Axis. Using the generated deployment files WSGen deploys the desired Web services.

V. WSGEN BY EXAMPLE

This section illustrates the application of the approach on a larger example. We explain how to create a Web service-oriented solution starting from a simulated version of a real-world Web application. The later represents the Web service search engine Seekda, which indexes a large set of public Web services in the Internet. In its simulated version, this application is considered as a set of interacting Web components. Each one gives a different view on the application.

• The login component: allows client's authentication.

It asks a user via a form to enter an email and a password.

• The new_account component: allows a new user to register in the application. The user is asked to enter an email, a password and re-type the password for validation.

• The password_recovery component: asks the user to enter the email address that she/he used to register in Seekda, and a new password. This component sends then an email that allows the user to activate the new password.

• The web_services_search component: asks the user to enter keywords for searching Web services. This component provides as a result a list of Web services. Each service is described by the following information: country name, provider name, WSDL URL, WSDL Cache, monitoring date, server name, availability, documentation, tags and user rating.

• The advanced_web_services_search component: allows the user to enter search keywords and other search criteria such as: country name, provider name, some specific tags, the number and order of results.

A. Generated Primitive Web services

The transformation of this Web component generates the following set of primitive Web services8 :

• AccountService: a Web service composed of the following operations:

-The _service_login operation: receives as input two messages of type String (the email and the password of the user). This operation performs the authentification action. -The _service_new_account operation: receives as input three messages of type String (the email, the password and the repeated password). This operation performs the creation of new client's account. -The _service_password_recovery operation: has three messages of type String (the email, the new password, the repeated password). It returns a message that indicates to the client that she/he will receive an email containing a link to activate the new password.

• SearchingService: a Web service composed of the following operations:

-The _service_BasicSearch operation: receives a message of type String (search keyword). This operation is used to search web services. -The _service_AdvancedSearch operation: is used for an advanced search. It receives as input a message of complex type, the elements of this complex type are of type String (search keyword, country name, provider name, some specific tags). -The _searchResult operation: returns to the client a message of complex type composed of elements of String type. These elements represent the information about the searched Web service (country name, provider name, etc.).

B. Generated Composite Web service

Figure 2 depicts the navigation rules between the different views of the Seekda Web application. These relations between Web views are converted to orchestrations of the previous Web services. First, all navigation paths are calculated from the web navigation document. As illustrated in Figure 2 there are sixteen 9 navigation paths for the seekda web application. For each navigation path, a BPEL process is generated using the previous algorithm. Figure 3 shows an excerpt of a generated BPEL process from the navigation path : WelcomeSeekda → new account → advancedSearch → searchResult. This process represents an orchestration of the corresponding generated services. The interface of the new BPEL composite Web service uses a set of port types, through which it provides operations to clients. The tool generates first, the WSDL file for this interface and their port types. As depicted in Figure 3, the partner link at the left side represents a client of the service provided by the BPEL process. The partner links at the right side represent the Web services (AccountService and SearchingService) that participate in the BPEL process. We start the process with a "receive" activity to receive requests from external clients. These clients represent others applications or Web services that consume the service provided by the BPEL process. We have then an "invoke" activity to call the _service_new_account operation of the AccountService. After invoking this operation, we have in the process another "invoke" activity to thenewAccountAction operation, which performs the creation of a new account in Seekda web application. This returns one of two values "newAccountPass" or "newAccountFail", which represent respectively, success or failure of the registration. After that, we have an "if" activity, in which, we test whether the returned value is equal to the value newAccountPass or not. This value as depicted in Figure 2 represents the value of the condition in the navigation rule. Based on this test, the process invokes the _service_AdvancedSearch operation or not. Before invoking this operation,there is a "receive" activity which gets from the client the search keywords and other search criteria such as: country and provider names. The next activity in this process is an invoke to the advancedSearchAction operation. We have then, an "if" activity in which, we compare the returned value of the operation with "searchPass" value. If they are equal, the process invokes the _searchResult operation. Finally, the returned message from this operation is sent to the client using the "reply" activity.

In this way, developers can directly use the services generated from the Seekda search engine application, either for creating new accounts or for searching Web services. They can build extensions of these services to provide more sophisticated solutions. For example, in the tools implemented by our team [START_REF] Azmeh | Selection of Composable Web Services Driven by User Requirements[END_REF], we classify hierarchically the result set of Web services obtained from Seekda, in order to make search and browsing easier. The set of Web services returned by the Seekda application consists of HTML pages. Instead of building an HTML parser "from scratch" to analyze each HTML page, we can consider here these tools as extensions to the functionalities provided by the Web interfaces of Seekda application accessed through our generated Web services. In this way, these tools can simply send requests to the Web service SearchingService and based on the obtained result, they classify Web services.

VI. RELATED WORK

In [START_REF] Lee | A framework for dynamically converting components to web services[END_REF], Roger Lee et al. developed an approach for converting functionalities implemented in software components into Web services. [START_REF] Marinho | Extending a Software Component Repository to Provide Services[END_REF] adopt an extensible mechanism to transform components implemented in different programming languages. These two works allow to a client to specify a request for searching a given functionality in components developed with different programming languages (C++ or Java) and deployed in a Web server or located in repository. As an answer to this request, services are generated automatically for the desired functionalities. Compared to these reactive systems, WSGen is proactive. It does not react to a client request, but it allows a web application engineer during the deployment of her/his component-based system to anticipate the export of some functionalities to third party developers as Web services. In addition, in WSGen we deal with Web interface conversion into stateless Web services. However in [START_REF] Lee | A framework for dynamically converting components to web services[END_REF] and [START_REF] Marinho | Extending a Software Component Repository to Provide Services[END_REF], only business functionalities implemented in software components are transformed.

Wike [START_REF] Han | Wike: A web information/knowledge extraction system for web service generation[END_REF] generates virtual Web services by the extraction of information from Web pages. Users can define patterns which are used to extract partial information from Web pages. The extraction function can be used to generate a Web service that returns the result of the extraction process. Content-based Web pages are not the main concern in our approach. Indeed in our process, Web components including Web interfaces and business logic implementation are the artifacts concerned by Web service generation. Wike is however a complementary solution to our work. Web services that are generated using our approach starting from Web components, which produce to users during execution a large quantity of content, can be enhanced with new operations that return only partial information (texts, images, ...) using Wike. Invocations to these new operations can be added to the orchestrations generated by WSGen.

Many works in the literature proposed some model-driven techniques to generate Web service-oriented applications. Bauer and Müller [START_REF] Bauer | Mda applied: From sequence diagrams to web service choreography[END_REF] applied MDA10 to provide a mapping of elements from UML2 sequence diagrams (considered as PlMs -Platform Independent Models) to a representation of compositions of Web services using BPEL (considered as PSMs -Platform Specific Models). This approach aims in particular at reducing the complexity of building BPEL specifications manually. [START_REF] Gronmo | Modeldriven web services development[END_REF] proposed a model-driven process for building Web service compositions. This process transforms WSDL descriptions into UML models. These models are integrated by the developer to form composite Web services, which contain interface and workflow descriptions. Interface models are described using stereotyped UML class diagrams and workflow models are represented by stereotyped activity diagrams. The resulting composite services are exported at last as WSDL descriptions. This work provides means for making forward engineering (UML to WSDL and BPEL) and reverse engineering (WSDL to UML) by specifying bidirectional transformation rules. Another model-driven approach for creating service-oriented solutions has been proposed in [START_REF] Johnson | A model-driven development approach to creating service-oriented solutions[END_REF]. In this work, a UML profile has been defined for service-oriented applications.

All these works are complementary to our approach. In our work the transformations are made from PSM to PSM. Web components, which are models specific to a given platform (in the current implementation, Java EE), are converted into Web services, which are considered as another platform-specific model (WSDL, Java and BPEL, in the actual version of WSGen). The UML profile presented in [START_REF] Johnson | A model-driven development approach to creating service-oriented solutions[END_REF] can be used to define high-level models of the generated Web services. The other approaches can be used to make a reverse engineering of the generated Web services or orchestrations and obtain more understandable models (compared to code). In addition, all these related works focus on UML modeling and generating new Web services starting from models of a high level of abstraction. In our approach, we worked on the transformation of existing Web code.

VII. CONCLUSION AND FUTURE WORK

Recent research in software and information systems engineering emphasizes the need for the proposition of new languages, methods, and tools for building systems by shifting from a product-centric to a service-oriented view [START_REF] Finkelstein | Software engineering: a roadmap[END_REF]. In this paper, we present a process for the transformation of Web component-based applications into Web serviceoriented ones. Web components are seen here as software artifacts embedding business logic code and exporting Web interfaces. This kind of modules are analyzed, the different elements that compose them are extracted to identify different Web services and possible collaborations of these services. All of the resulting services are deployed on the Internet in order to allow third party development. In our work, we consider these deployed artifacts (embedding Web interfaces) as remote APIs (as services) that offer the opportunity for developers to extend the functionality provided by these services and exploit the resources used by them. Some enhancements will be made on the transformation process implemented in WSGen. We are now working on the implementation of more sophisticated techniques for grouping complementary operations in Web services, based on "text-mining" of Web components' documentation. At the conceptual level, we plan to study the formalization of the performed transformation as a set of high level declarative rules. We then define such rules in a MOF/QVT-compliant language [START_REF] Omg | Meta object facility (mof) 2.0 query/view/ transformation specification[END_REF] and thus integrate our solution in a Model-Driven Engineering process. At the tool level, we plan to work on the generation of high-level specifications of choreographies in "WS-CDL"-compliant languages starting from collaborations of the generated Web services' operations. Experimenting in depth our approach by measuring its scalability and performance on large Web applications is another perspective of our work.

Figure 1 .

 1 Figure 1. The Transformation Process

Figure 2 .

 2 Figure 2. Navigation Rules in the simulated Seekda Web Application

Figure 3 .

 3 Figure 3. Excerpt of the generated BPEL Process

Application Server Web service Search Engine Web Component Developer or Deployer is involved in

	Operation Extraction	Set of operations
	Input and Output Message Identification	Set of operations with messages
			Reduced set
		Operation Filtering	of operations
			Reorganized set
		Operations Distribution	of operations
			Set of Web
			Composite Service Creation	services (primitive & composite)
			Web Service
		is involved in	Deployment & Indexing

This is not an exhaustive list. Some other generated operations will be introduced in the following section.

Seekda Website: http://webservices.seekda.com/

Apache Website: http://ws.apache.org/jaxme/js/index.html

HTML Parser at SourceForge: http://htmlparser.sourceforge.net/

Apache Website: http://tomcat.apache.org/download-70.cgi

This is not an exhaustive list. Some other generated operations will be introduced in the following subsection.

Some of them are duplicated and have different sources.

OMG's Website: http://www.omg.org/mda/specs.htm