dataesr/scientific-paragraphs-categorization huggingface dataset:
From CG to Jimple for a Unified Model A call-graph is a useful model, but it is still limited because it does not contain enough information to perform static analysis (e. g. , data flow analysis). Indeed, important information such as the statements present in each method is missing (i. e. , the control flow graph (CFG)). A tool such as FlowDroid provides the CFG for each bytecode method where the method behavior is represented with Jimple statements. We will now explain how JuCify adds Jimple statements in specific native functions in a best-effort mode. After this step, for a given APK, we obtain the Jimple representation of the apk with both bytecode and native code unified. Native functions generation: JuCify relies on a DummyBina-ryClass whose purpose is to incorporate any newly imported native function in the Soot representation.
Let consider  is defined in a Java class named MyClass. In line 1, JuCify starts with the empty method foo(). Then: Step 1 in Listing 3: If the bytecode method  should return a value, JuCify generates a new local variable with the same type as the method's return type (line 4). Step 2 in Listing 3: JuCify generates the declaration of a variable of type MyClass, the class in which  is defined (line 8). In line 9, JuCify creates a new MyClass instance (if there is not one usable as a base for the bytecode call). Step 3 in Listing 3: Regarding the parameters that should be used for the invocation of , JuCify scans foo() for local variables and parameters whose types match the types of the parameters of. If, for a given type, no local variable, nor parameter of foo() is found, JuCify generates one (e.
EVALUATION We investigate the following research questions to assess the importance of our contributions: RQ1: What is the proportion and evolution of native code usage in both real-world benign and malicious apps? RQ2: To what extent our bytecode-native invocation extraction step (named NativeDiscloser) yields better results than the state-of-the-art ? RQ3: Can JuCify boost existing static data flow analyzers? RQ4: How does JuCify behave in the wild? We address this question both at the quantitative and qualitative levels: • RQ4. a: To what extent can JuCify augment apps' callgraphs and reveal previously unreachable Java methods? • RQ4. b: Can JuCify reveal previously unreachable data leaks that pass through native code in real-world apps?.
RQ1: Native code usage in the wild This section presents general statistics about the usage of native code in both benign and malicious Android apps. We also perform an evolutionary study of this usage. Dataset: We rely on the AndroZoo repository  [3]  to build a dataset of 2 641 194 benign apps (where we consider an app as benign if no Antivirus in VirusTotal  [65]  has flagged it -score 0); and a dataset of 174 342 malicious apps (where we consider an app as malicious when at least 10 Antivirus engines in VirusTotal have flagged it). Both datasets contain all the apps from 2015 to 2020 that we were able to collect from AndroZoo with the mentioned VirusTotal constraints. Empirical study: Android programming with the Native Development Kit (NDK) suggests developers to integrate native libraries (i.
Goodware Regarding usage evolution in benign apps, the rate increases until 2018 to reach a plateau at around 60%. The trend regarding malware is much more erratic (with sharp decreases in 2017 and 2020). However, for each year, malicious apps use significantly more native code than benign apps. RQ1 answer: Native code is definitely pervasive in Android apps. While both benign and malicious code leverage native code, native invocations are substantially more common in malware (70% vs. 43%). These results indicate that ignoring native code is a serious threat to validity in Android static code analysis.
RQ2: Bytecode-Native Invocation Extraction Comparison Identifying native-to-bytecode and bytecode-to-native code invocations are key steps towards code unification. Our objective is to estimate to what extent the corresponding building block in JuCify is effective against a benchmark and against the state of the art. Native to Bytecode: Fourtounis et al. [15]  proposed an approach to detect exit invocations (i. e. , native to bytecode invocations, c. f. , Section 3. 1) in native code via binary scanning. Their tool named Native-Scanner  [46]  has been developed as a plugin of a framework called DOOP  [45]. Briefly, their tool scans binary files for string constants that match Java method names and Java VM type signatures and follows their propagation. In this way, they consider all matches as new entry points back to bytecode.
Limitations of Angr could cause this in parsing pointer of pointers. Overall, compared to Native-Scanner, NativeDiscloser obtains significantly higher precision and recall. Bytecode to native: We were unable to compare NativeDiscloser with Native-Scanner. Unlike our tool, Native-Scanner does not investigate (1) bytecode to native entry invocations and (2) the relations mapping between entry and exit invocations. Note, however, that on our benchmark of 16 apps, NativeDiscloser yields 100% precision in finding both the entry invocations and the entry-to-exit relations and achieves a recall of 95. 59% and 89. 19% respectively.
Then, we apply the state-of-the-art FlowDroid taint-analysis engine before and after applying JuCify in our benchmark apps, to show that FlowDroid can, likewise in  [56] , be boosted. FlowDroid detects paths from well-defined sources (e. g. , getDeviceId()) and sinks (e. g. , sendTextMessage()) methods in Android apps. Benchmark construction: We identified 4 cases on which we built our 11 benchmark apps to assess the ability of tools in detecting data leak via native code: a) Getter: Source in native code and sink in Java code b) Leaker: Source in Java code and sink in native code c) Proxy: Source in Java code and sink in Java code d) Delegation: Source in native code and sink in native code Note that "Source/Sink in native code" means that the call to a sensitive method is actually performed in native code, but the sensitive method is always a method from the Android framework accessed with JNI (e.
g. , calling with JNI the getDeviceId() from the native code). For each of these cases, at least one step happens in native. Figure  3  illustrates these four cases. The red dots represent tainted information from a source method, and the red arrows represent how this information flows in the program. The Getter use-case allows developers to get sensitive data from the native code to leak it in the Java world. The Leaker use-case allows developers to get sensitive data from the Java world to leak it in the native world. Regarding the Proxy use-case, the sensitive information is retrieved in the Java world, sent to the native world to "break" the flow, and sent back to the Java world to be leaked. Concerning the Delegation use-case, a simple native function is called from the Java world, and the sensitive information is retrieved and leaked in the native world.
Number of binary functions in the augmented call-graph: Newly added nodes can be explained by the binary functions (i. e. , functions in the native code part) that are now considered in the unified call graph yielded by JuCify. Figure  4  details the distributions of the number of binary functions for both datasets. We notice that benign apps tend to have more added binary function nodes (median = 172, and mean = 269. 7) in the call-graph than malicious apps (median = 162, and mean = 197. 2). Both distributions are significantly different, as confirmed by a Mann-Whitney-Wilcoxon (MWW) test  [41]  (significance level set at 0. 05).
Number of native-to-bytecode call-graph edges: Newly added edges can also originate from bytecode methods invoked in native functions (i. e. , exit invocations with reflection-like mechanisms as explained in Section 2. 1. 2). The median of number of edges is significantly low for both goodware and malware. Indeed, the median of native-to-bytecode edges is equal to 3 for both datasets, the distribution is available in Figure  6. Overall, JuCify reveals a total of 261 native-to-bytecode invocations in the entire goodware set and 4288 in the malware set. The conclusion that can be drawn from these results is the following: the low numbers of native-to-bytecode edges in goodware shows that benign apps make little use of reflection-like mechanisms to invoke Java methods from native code, compared to malware.
Results indicate that in 82. 7% of the cases, the native function Java_mono_android_-Runtime_register is invoked from the bytecode in goodware. In fact, most of the top invoked native functions in goodware are from the mono framework, which is used by Xamarin  [74]. The same method is, however, not found in the malware dataset. The top invoked native functions in malware is composed of different elements such as Java_com_seleuco_mame4all_Emulator_-setPadData, Java_com_shunpay210_sdk_CppAdapter210_pay, or more suspicious functions: Java_iqqxF_TZfff_ggior and Java_-glrrx_efgnp_twCJN. From native to bytecode, we note some interesting insights: while benign apps invoke from the native code, in the majority of cases, bytecode methods like Context. getPackageName (14. 2%), or ThreadLocal. get (8.
For each of these 1800 apps, we set a 1-hour timeout (30 min for the symbolic execution and 30 min for FlowDroid). Findings: Among the 1800 malicious apps, 1460 contained Java native methods declaration(s) in the code. In total, JuCify was able to augment the call-graph of 1066 (i. e. , 73%) of the 1460 apps that contain both. so files and Java native method declaration in bytecode. From these 1460 apps, FlowDroid revealed sensitive data leaks that take advantage of the native code in 14 apps. These 14 apps were manually checked and confirmed to contain sensitive data leaks that goes through the native code. Note that this number is highly linked to the source and sink methods used. In the following, we discuss two case studies where JuCify was able to reveal sensitive data leaks that pass through native code.
Getter-Scenario Case Study. In Figure  3a  we illustrated an example of how malware developers can rely on native code to hide, from static analyzers, the retrieval of sensitive data from static analyzers. JuCify revealed an Android malware 2  implementing this specific behavior. JuCify reconstructed the A() native method from the com. y class as the following: "<DummyBinaryClass: java-. lang. String Java_com_y_A(android. content. Context)>". In this native function, the IMEI number of the device is obtained via the JNI interface and returned as a result. This reconstructed method is called in method b() of class com. cance. b. q to store the IMEI number. The resulting IMEI number is then wrapped and transferred to a method to log it. After examining the VirusTotal report of this app, we found that the flags raised by antiviruses refer to Trojan behavior and explicitly mention the retrieval of sensitive information from the device as well as the use of native code in the implementation of the malicious behaviour.
Leaker-Scenario Case Study. In Figure  3b , we illustrated how app developers can rely on native code to hide the leakage of sensitive data. JuCify revealed an Android malware 3  with this behavior. First, the IMEI number is obtained in the getOperator() method of the com. umeng. adutils. AppConnect class and stored in the imei field of the same class. Then, in the processReplyMsg() method of this class (method which is triggered when an SMS is received), the IMEI number is wrapped in another string and sent to the native method "stringFromJNI()" as a parameter. JuCify's instrumentation engine constructed the following method from this native method: "<DummyBinaryClass: java. lang. String Java_com_umeng_adutils_SdkUtils_stringFromJNI(android. app. PendingIntent,java. lang. String,java. lang.
String)>". This latter has been populated with the information given by the symbolic execution and revealed that the sendTextMessage() method from the android. telephony. SmsManager class is called with the valued derived from the IMEI number as parameter. To summarize, a value derived from the IMEI number is sent out of the device using an SMS through the native code. Doing so, the leak would have remained undetected without JuCify. As in the previous case study, we examined the VirusTotal report of this app. In their majority, antiviruses flag it as a Trojan app. Some reports even explicit tag the use of getDeviceId() and of native code for the malicious operations. Thus, with JuCify we enabled an existing analyzer to uncover a leak being performed through native code. RQ4. b answer: JuCify is effective for highlighting data flows across native code that were previously unseen.
Therefore, as described in Section 4. 4. 1, the call-graph of some Android apps was not augmented due to the symbolic execution that did not return native-bytecode links and/or due to the timeout. Third, a major limitation of JuCify lies in the fact that it does not yet reconstruct native functions behavior with high precision. Indeed, as described in Section 3. 2, for the native functions that represent Java native function, JuCify considers a partial list of statements: it employs opaque predicates to guide static analyzers into considering every possible path during analyses. Moreover, JuCify overlooks native functions that are not explicitly targeted by JNI Java calls since it cannot approximate their behavior in the current implementation. As a result, JuCify cannot generate native functions' control flow graphs with Jimple statements that cover the full behavior of functions.
THREATS TO VALIDITY Manual Checking. To check the correctness of the results, we manually checked a hundred Android apps. To do so, we relied on Java bytecode decompilers and native code decompilers such as Jadx  [58]  and RetDec  [29]. Although native code manual checking is challenging, we were able to confirm that the native nodes added by JuCify matched the nodes from the native callgraph constructed by NativeDiscloser. Regarding bytecode-to-native links, as the symbols were always available for the apps we checked (since native methods were statically registered), we were able to confirm the correctness of those links in the callgraph generated by JuCify. We reverse-engineered these apps and were able to reach the same conclusions. Regarding native-to-bytecode links, the method names are represented as strings, which are not directly available in the native code.
Given these fundamental usages of static analysis, it is essential to take into account all code that implements any part of the app behavior. Therefore, the fact that many analyses are reduced to focus on the bytecode (while leaving out native code within app packages) constitutes a severe threat to validity in many studies. Binary analysis. Binary analysis techniques have been applied for different platforms, using static  [7, 9, 12, 21] , dynamic  [6, 8, 37] , hybrid  [11, 22, 54]  and machine-learning-based  [32, 39, 68, 71]  approaches. A recent work  [15]  tackles the challenging task of analyzing binaries by combining declarative static analysis (using Datalog declarative logic-based programming language) with reverse-engineering techniques to perform x-refs analysis in native libraries using Radare2 [51].
In the Android realm, analysis of binaries can be essential to cope with obfuscation  [24]. Cross-language analysis. Several researchers have also acknowledged the presence of native code alongside bytecode in their analysis of Android apps. For instance, in 2016, Alam et al. [2]  presented DroidNative which can perform Android malware detection considering both the bytecode and the native code. NDroid  [50]  and TaintArt  [61]  were proposed for dynamic taint analysis to track sensitive information flowing through JNI. JN-SAF  [69]  is also proposed as an inter-language static analysis framework to detect sensitive data leaks in Android apps, taking into account native code. All the aforementioned tools, however, are task-specific. They also, typically, perform their analyses separately for bytecode and native code, and later post-process and merge the outputs to present unified analysis results.
In contrast, JuCify proposes to unify the representation before task-specific analyses. This enables other analyses to be built upon the output of JuCify. For experimental assessment of JuCify representation for data flow analysis (RQ-5), we envisioned a comparison with JN-SAF. Unfortunately, two co-authors independently failed to run the tool. Overall, there are various approaches and studies  [1, 31, 53, 60]  in the literature that investigate the possibility to analyze apps by account for the different language-specific artifacts in the package. Although the approaches described are promising for cross-language analysis, they do not generally offer a practical framework to unify the representation of both the bytecode and the native code into a single model that standard static analysis pipelines can leverage.
CONCLUSION We contribute in the ambitious research agenda of unifying bytecode and native code to support comprehensive static analysis of Android apps. We presented JuCify, as a significant step towards this unification: it generates a native call-graph that is merged with the bytecode call-graph based on links retrieved via symbolic execution. In this model (i. e. , the unified call-graph), we are able to heuristically populate specific native functions with Jimple statements. The Jimple intermediate representation was selected to readily support existing static analysers based on the Soot framework. We first empirically showed that JuCify significantly improves Android apps call-graphs, which are augmented (to include native code nodes) and enhanced (to reveal previously unreachable methods).
ACKNOWLEDGMENT This work was partly supported (1) by the  Luxembourg National Research Fund (FNR) , under projects Reprocess  C21/IS/16344458  the AFR grant  14596679 , (2) by the  SPARTA  project, which has received funding from the  European Union 's  Horizon 2020 research and innovation program  under grant agreement No  830892 , (3) by the  NATURAL  project, which has received funding from the  European Research Council  under the European Union's  Horizon 2020 research and innovation programme  (grant  N°949014 ), and (4) by the  INTER Mobility project Sleepless@Seattle   No 13999722.
In 2007, 9. 5% of cereal samples tested in Europe by the European Food Safety Authority (EFSA) contained glyphosate. A study carried out in Switzerland on foods purchased in supermarkets found the highest levels of glyphosate in cereals and in pasta  (Zoller et al. 2018). Glyphosate was also detected in beverages; in Germany, 6 out of 14 beers tested positive for glyphosate. All wines and fruit juices tested in Switzerland contained glyphosate  (Zoller et al. 2018). Human exposure to glyphosate, either by food and water intake or via external exposure, has been extensively studied. However, because of differences in methodology between studies, direct data comparison is difficult  (Connolly et al. 2020a ). In the general population, the main route of exposure appears to be food, with higher levels of exposure in developing countries  (Acquavella et al.
Participants, sample, and data collection The study was designed by the Campagne Glyphosate France Association (Foix, France). Participant recruitment was organized and conducted by French local committees between June 2018 and January 2020. One hundred and seventy-five sessions were organized in 63 French districts. All subjects gave written informed consent to participate in the study prior to sample collection. No exclusion criteria were used to exclude potential participants. A total of 6848 participants were recruited. Participants were asked not to urinate, drink, eat, or smoke at least 6 h before urine collection. Prior to urine collection, a written questionnaire was filled in by each participant providing self-reported socio-demographic and lifestyle information. Collected data included age, gender, height and weight, employment status, place of residence, smoking status, physical activity practice, general dietary information (organic food consumption; beer and fruit juice consumption; tap, bottled, spring (well or natural source) or filtered water consumption).
(Krüger et al. 2014)  based on ELISA and GC-MS assay data comparison on human urine samples. All assays were performed by a single laboratory Biocheck GmbH. ELISA was performed according to the manufacturer's protocol intended for human urine samples. Briefly, 500 µl of urine sample were filtered with a 3 K VWR Centrifugal filter at 3000 × g for 10 min and the upper layer was transferred to a new tube and analyzed according to the Glyphosate Plate ELISA Kit user's guide. Samples with glyphosate concentrations higher than 4 ng/ml were diluted at a 1:5 ratio with the Glyphosate Sample Diluent provided in the kit and reanalyzed. Measurements were performed on a Sunrise Microplate Reader automate (Tecan, Switzerland). Standard deviation measured by intra-day and inter-day samples reported by Biocheck GmbH is 0.
Statistical analyses and data interpretation The participant data used in this study have been anonymized in the database. Glyphosate measurements and self-reported participant data on socio-demographic and lifestyle characteristics are reported as numbers, percentages or mean with range or standard deviation (SD). Geographical data are plotted on a map. Glyphosate measurements were adjusted according body mass index (BMI, calculated as weight/height 2 ) as proposed in  (Boeniger et al. 1993). Differences in glyphosate concentrations according to each variable (age, gender, employment status, place of residence, smoking status, physical activity, dietary information) were assessed using ANOVA or Kruskal-Wallis tests. All analyses were performed using R Environment for statistical computing (RCoreTeam 2020).
Glyphosate is detected in 99. 8% of the samples and is higher during spring and summer Glyphosate was quantitatively detected in 6781 urine samples out of 6795 (99. 8%). In association analysis, measurements below the LOQ (0. 075 ng/ml) were considered to be Fig. 1  Geographical location of participants' residence. Plot sizes are proportional to the number of participants equal to 0. 0 ng/ml. BMI-adjusted glyphosate mean level was 1. 19 ng/ml + / -0. 84, with a range  [< 0. 075; 7. 36]. Data from the 5800 questionnaires were used to evaluate glyphosate levels according to the season of collection. Urine samples collected between May and September showed significantly higher glyphosate levels than those collected between October and April (Table  2 ; p < 0. 001). Some urine collection sessions were repeated in the same geographical district: 1796 samples collected at least at 4 different times of the year in the same geographical district were available.
Discussion France is an important agricultural country, with half of its surface area dedicated to farming. During the last decades, the dominant French agricultural model evolved towards more intensive agriculture with an increased use of chemicals; France is among the top ten pesticide-consuming countries worldwide and is number one in the EU  (Sharma et al. 2019). Glyphosate has been extensively used since its commercialization in the 1970s in countries with intensive farming (reviewed in  (Sharma et al. 2019) ). Several methods have been developed and validated to measure glyphosate levels (reviewed in  (Valle et al. 2019) ). However, comparison of datasets needs to be carried out with caution, because of differences in sampling strategy, urinary dilution adjustments, or detection/quantification methods and limits  (Connolly et al.