From fd4d6fa239f78db764bbaf497a8aa634dce7b7e7 Mon Sep 17 00:00:00 2001 From: Jean-Marie Mineau Date: Sat, 19 Jul 2025 23:01:15 +0200 Subject: [PATCH] start modifying contrib section --- 3_rasta/1_related_work.typ | 11 +- 3_rasta/2_methodology.typ | 11 +- 3_rasta/3_experiments.typ | 38 +- 3_rasta/4_discussion.typ | 91 +- papers/3_rasta/0_intro.typ | 55 + papers/3_rasta/1_related_work.typ | 119 + papers/3_rasta/2_methodology.typ | 274 ++ papers/3_rasta/3_experiments.typ | 394 ++ papers/3_rasta/4_discussion.typ | 440 ++ papers/3_rasta/5_conclusion.typ | 14 + papers/3_rasta/X_lib.typ | 22 + papers/3_rasta/X_var.typ | 37 + papers/3_rasta/data/average_mem-final.csv | 4 + .../data/average_number_of_error_by_exec.csv | 7 + papers/3_rasta/data/average_time-final.csv | 4 + papers/3_rasta/data/data-final.csv | 27 + ...bytecode-size-of-apks-detected-in-2022.svg | 774 ++++ ...tecode-size-between-4-08-mb-and-5-2-mb.svg | 782 ++++ ...tecode-size-between-4-08-mb-and-5-2-mb.svg | 1087 +++++ ...bytecode-size-of-apks-detected-in-2022.svg | 616 +++ ...tecode-size-between-4-08-mb-and-5-2-mb.svg | 574 +++ ...tecode-size-between-4-08-mb-and-5-2-mb.svg | 872 ++++ .../exit-status-for-the-drebin-dataset.svg | 2111 ++++++++++ ...for-the-rasta-dataset-goodware-malware.svg | 3582 +++++++++++++++++ .../exit-status-for-the-rasta-dataset.svg | 2140 ++++++++++ ...shing-rate-by-year-of-java-based-tools.svg | 1005 +++++ ...g-rate-by-year-of-non-java-based-tools.svg | 678 ++++ ...repartition-of-error-types-among-tools.svg | 2092 ++++++++++ papers/3_rasta/figs/running.svg | 225 ++ papers/3_rasta/main.typ | 12 + papers/4_class_loader/0_intro.typ | 64 + papers/4_class_loader/1_related_work.typ | 54 + papers/4_class_loader/2_classloading.typ | 205 + papers/4_class_loader/3_obfuscation.typ | 284 ++ papers/4_class_loader/4_in_the_wild.typ | 279 ++ papers/4_class_loader/5_ttv.typ | 13 + papers/4_class_loader/6_conclusion.typ | 16 + papers/4_class_loader/X_var.typ | 43 + papers/4_class_loader/data/redef_sdk_16.csv | 11 + .../4_class_loader/data/redef_sdk_7minus.csv | 11 + papers/4_class_loader/data/redef_sdk_8.csv | 11 + papers/4_class_loader/data/results_50k.csv | 5 + papers/4_class_loader/data/results_only.csv | 5 + .../figs/architecture_SDK-crop.svg | 704 ++++ .../figs/call_graph_expected.svg | 506 +++ papers/4_class_loader/figs/call_graph_obf.svg | 506 +++ .../4_class_loader/figs/classloaders-crop.svg | 608 +++ .../figs/redef_sdk_relative_min_sdk.svg | 1281 ++++++ papers/4_class_loader/main.typ | 13 + 49 files changed, 22629 insertions(+), 88 deletions(-) create mode 100644 papers/3_rasta/0_intro.typ create mode 100644 papers/3_rasta/1_related_work.typ create mode 100644 papers/3_rasta/2_methodology.typ create mode 100644 papers/3_rasta/3_experiments.typ create mode 100644 papers/3_rasta/4_discussion.typ create mode 100644 papers/3_rasta/5_conclusion.typ create mode 100644 papers/3_rasta/X_lib.typ create mode 100644 papers/3_rasta/X_var.typ create mode 100644 papers/3_rasta/data/average_mem-final.csv create mode 100644 papers/3_rasta/data/average_number_of_error_by_exec.csv create mode 100644 papers/3_rasta/data/average_time-final.csv create mode 100644 papers/3_rasta/data/data-final.csv create mode 100644 papers/3_rasta/figs/decorelation/finishing-rate-of-java-based-tool-by-bytecode-size-of-apks-detected-in-2022.svg create mode 100644 papers/3_rasta/figs/decorelation/finishing-rate-of-java-based-tool-by-discovery-year-of-apks-with-a-bytecode-size-between-4-08-mb-and-5-2-mb.svg create mode 100644 papers/3_rasta/figs/decorelation/finishing-rate-of-java-based-tool-by-min-sdk-of-apks-with-a-bytecode-size-between-4-08-mb-and-5-2-mb.svg create mode 100644 papers/3_rasta/figs/decorelation/finishing-rate-of-non-java-based-tool-by-bytecode-size-of-apks-detected-in-2022.svg create mode 100644 papers/3_rasta/figs/decorelation/finishing-rate-of-non-java-based-tool-by-discovery-year-of-apks-with-a-bytecode-size-between-4-08-mb-and-5-2-mb.svg create mode 100644 papers/3_rasta/figs/decorelation/finishing-rate-of-non-java-based-tool-by-min-sdk-of-apks-with-a-bytecode-size-between-4-08-mb-and-5-2-mb.svg create mode 100644 papers/3_rasta/figs/exit-status-for-the-drebin-dataset.svg create mode 100644 papers/3_rasta/figs/exit-status-for-the-rasta-dataset-goodware-malware.svg create mode 100644 papers/3_rasta/figs/exit-status-for-the-rasta-dataset.svg create mode 100644 papers/3_rasta/figs/finishing-rate-by-year-of-java-based-tools.svg create mode 100644 papers/3_rasta/figs/finishing-rate-by-year-of-non-java-based-tools.svg create mode 100644 papers/3_rasta/figs/repartition-of-error-types-among-tools.svg create mode 100644 papers/3_rasta/figs/running.svg create mode 100644 papers/3_rasta/main.typ create mode 100644 papers/4_class_loader/0_intro.typ create mode 100644 papers/4_class_loader/1_related_work.typ create mode 100644 papers/4_class_loader/2_classloading.typ create mode 100644 papers/4_class_loader/3_obfuscation.typ create mode 100644 papers/4_class_loader/4_in_the_wild.typ create mode 100644 papers/4_class_loader/5_ttv.typ create mode 100644 papers/4_class_loader/6_conclusion.typ create mode 100644 papers/4_class_loader/X_var.typ create mode 100644 papers/4_class_loader/data/redef_sdk_16.csv create mode 100644 papers/4_class_loader/data/redef_sdk_7minus.csv create mode 100644 papers/4_class_loader/data/redef_sdk_8.csv create mode 100644 papers/4_class_loader/data/results_50k.csv create mode 100644 papers/4_class_loader/data/results_only.csv create mode 100644 papers/4_class_loader/figs/architecture_SDK-crop.svg create mode 100644 papers/4_class_loader/figs/call_graph_expected.svg create mode 100644 papers/4_class_loader/figs/call_graph_obf.svg create mode 100644 papers/4_class_loader/figs/classloaders-crop.svg create mode 100644 papers/4_class_loader/figs/redef_sdk_relative_min_sdk.svg create mode 100644 papers/4_class_loader/main.typ diff --git a/3_rasta/1_related_work.typ b/3_rasta/1_related_work.typ index bd1fabe..d02f133 100644 --- a/3_rasta/1_related_work.typ +++ b/3_rasta/1_related_work.typ @@ -59,12 +59,11 @@ Reaves #etal also report that real world applications are more challenging to an We will confirm and expand this result in this paper with a larger dataset than only 16 real-world applications. // Indeed, a more diverse dataset would assess the results and give more insight about the factors impacting the performances of the tools. -// PAS LA PLACE ! -// Finally, our approach is similar to the methodology employed by Mauthe #etal for decompilers@mauthe_large-scale_2021. -// To assess the robustness of android decompilers, Mauthe #etal used 4 decompilers on a dataset of 40 000 applications. -// The error messages of the decompilers were parsed to list the methods that failed to decompile, and this information was used to estimate the main causes of failure. -// It was found that the failure rate is correlated to the size of the method, and that a consequent amount of failure are from third parties library rather than the core code of the application. -// They also concluded that malware are easier to entirely decompile, but have a higher failure rate, meaning that the one that are hard to decompile are substantially harder to decompile than goodware. +Finally, our approach is similar to the methodology employed by Mauthe #etal for decompilers@mauthe_large-scale_2021. +To assess the robustness of android decompilers, Mauthe #etal used 4 decompilers on a dataset of 40 000 applications. +The error messages of the decompilers were parsed to list the methods that failed to decompile, and this information was used to estimate the main causes of failure. +It was found that the failure rate is correlated to the size of the method, and that a consequent amount of failure are from third parties library rather than the core code of the application. +They also concluded that malware are easier to entirely decompile, but have a higher failure rate, meaning that the one that are hard to decompile are substantially harder to decompile than goodware. /* diff --git a/3_rasta/2_methodology.typ b/3_rasta/2_methodology.typ index e7d4fd6..3ead2f7 100644 --- a/3_rasta/2_methodology.typ +++ b/3_rasta/2_methodology.typ @@ -254,12 +254,11 @@ Probleme 2: pour sampler, on utilise les deciles de taille d'apk, mais pour nos */ -// Two datasets are used in the experiments of this section. -// The first one is *Drebin*@Arp2014, from which we extracted the malware part (5479 samples that we could retrieved) for comparison purpose only. -// It is a well known and very old dataset that should not be used anymore because it contains temporal and spatial biases@Pendlebury2018. -// We intend to compare the rate of success on this old dataset with a more recent one. -// The second one, -We built a dataset named *Rasta* to cover all dates between 2010 to 2023. +Two datasets are used in the experiments of this section. +The first one is *Drebin*@Arp2014, from which we extracted the malware part (5479 samples that we could retrieved) for comparison purpose only. +It is a well known and very old dataset that should not be used anymore because it contains temporal and spatial biases@Pendlebury2018. +We intend to compare the rate of success on this old dataset with a more recent one. +The second one, *Rasta*, we built to cover all dates between 2010 to 2023. This dataset is a random extract of Androzoo@allixAndroZooCollectingMillions2016, for which we balanced applications between years and size. For each year and inter-decile range of size in Androzoo, 500 applications have been extracted with an arbitrary proportion of 7% of malware. This ratio has been chosen because it is the ratio of goodware/malware that we observed when performing a raw extract of Androzoo. diff --git a/3_rasta/3_experiments.typ b/3_rasta/3_experiments.typ index fb2c369..2fcb67c 100644 --- a/3_rasta/3_experiments.typ +++ b/3_rasta/3_experiments.typ @@ -1,4 +1,4 @@ -#import "../lib.typ": todo, highlight, num, paragraph +#import "../lib.typ": todo, highlight, num, paragraph, SDK #import "X_var.typ": * #import "X_lib.typ": * @@ -55,8 +55,7 @@ For the tools that we could run, #resultratio of analysis are finishing successf //(those with less than 50% of successful execution and including the two tools that we were unable to build). ] -/* -== RQ2: temporal evolution +=== RQ2: Size, #SDK and Date Influence #todo[alt text for fig rasta-exit-evolution-java and rasta-exit-evolution-not-java] @@ -120,17 +119,7 @@ sqlite> SELECT apk1.first_seen_year, (COUNT(*) * 100) / (SELECT 20 * COUNT(*) ``` */ -#highlight()[ -*RQ2 answer:* For the #nbtoolsselected tools that can be used partially, a global decrease of the success rate of tools' analysis is observed over time. -Starting at 78% of success rate, after five years, tools have 61% of success; after ten years, 45% of success. -] -*/ - - -=== RQ2: Size, SDK and Date Influence - -To measure the influence of the date, SDK version and size of applications, we fixed one parameter while varying an other. -For the sake of clarity, we separated Java based / non Java based tools. +To compare the influence of the date, #SDK version and size of applications, we fixed one parameter while varying an other. #todo[Alt text for fig rasta-decorelation-size] #figure(stack(dir: ltr, @@ -209,21 +198,25 @@ We observe that 9 tools over 12 have a finishing rate dropping below 20% for Jav caption: [Non Java based tools], supplement: [Subfigure], ) ] - ), caption: [Finishing rate by min SDK with a bytecode size $in$ [4.08, 5.2] MB] + ), caption: [Finishing rate by min #SDK with a bytecode size $in$ [4.08, 5.2] MB] ) -We performed similar experiments by variating the min SDK and target SDK versions, still with a fixed bytecode size between 4.08 and 5.2 MB, as shown in @fig:rasta-rate-evolution-java-decile-min-sdk and @fig:rasta-rate-evolution-non-java-decile-min-sdk. -We found that contrary to the target SDK, the min SDK version has an impact on the finishing rate of Java based tools: 8 tools over 12 are below 50% after SDK 16. -It is not surprising, as the min SDK is highly correlated to the year. +We performed similar experiments by variating the min #SDK and target #SDK versions, still with a fixed bytecode size between 4.08 and 5.2 MB, as shown in @fig:rasta-rate-evolution-java-decile-min-sdk and @fig:rasta-rate-evolution-non-java-decile-min-sdk. +We found that contrary to the target #SDK, the min #SDK version has an impact on the finishing rate of Java based tools: 8 tools over 12 are below 50% after #SDK 16. +It is not surprising, as the min #SDK is highly correlated to the year. #highlight()[ *RQ2 answer:* -The success rate varies based on the size of bytecode and SDK version. +For the #nbtoolsselected tools that can be used partially, a global decrease of the success rate of tools' analysis is observed over time. +Starting at 78% of success rate, after five years, tools have 61% of success; after ten years, 45% of success. +The success rate varies based on the size of bytecode and #SDK version. The date is also correlated with the success rate for Java based tools only. ] -=== RQ3: Malware vs Goodware +=== RQ3: Malware vs Goodware + +#todo[complete @sec:rasta-mal-vs-good by commenting the new figures] /* ``` @@ -256,7 +249,6 @@ sqlite> SELECT vt_detection == 0, COUNT(DISTINCT sha256) FROM apk WHERE dex_size */ -/* #todo[Alt text for rasta-exit-goodmal] #figure( image( @@ -266,8 +258,6 @@ sqlite> SELECT vt_detection == 0, COUNT(DISTINCT sha256) FROM apk WHERE dex_size ), caption: [Exit status comparing goodware and malware for the Rasta dataset], ) -*/ - /* [15:25] Jean-Marie Mineau @@ -295,7 +285,6 @@ sqlite> SELECT AVG(apk_size) FROM apk WHERE vt_detection != 0; */ -/* #figure({ show table: set text(size: 0.80em) table( @@ -329,7 +318,6 @@ sqlite> SELECT AVG(apk_size) FROM apk WHERE vt_detection != 0; )}, caption: [Average size and date of goodware/malware parts of the Rasta dataset], ) -*/ #figure({ diff --git a/3_rasta/4_discussion.typ b/3_rasta/4_discussion.typ index 42af10e..87f781c 100644 --- a/3_rasta/4_discussion.typ +++ b/3_rasta/4_discussion.typ @@ -4,51 +4,6 @@ == Discussion -=== State-of-the-art comparison - -Our finding are consistent with the numerical results of Pauck #etal that showed that #mypercent(106, 180) of DIALDroid-Bench@bosuCollusiveDataLeak2017 real-world applications are analyzed successfully with the 6 evaluated tools@pauckAndroidTaintAnalysis2018. -Six years after the release of DIALDroid-Bench, we obtain a lower ratio of #mypercent(40.05, 100) for the same set of 6 tools but using the Rasta dataset of #NBTOTALSTRING applications. -We extended this result to a set of #nbtoolsvariationsrun tools and obtained a global success rate of #resultratio. We confirmed that most tools require a significant amount of work to get them running@reaves_droid_2016. -// Our investigations of crashes also confirmed that dependencies to older versions of Apktool are impacting the performances of Anadroid, Saaf and Wognsen #etal in addition to DroidSafe and IccTa, already identified by Pauck #etal. - -Investigating the reason behind tools' errors is a difficult task and will be investigated in a future work. -For now, our manual investigations show that the nature of errors varies from one analysis to another, without any easy solution for the end user for fixing it. - -=== Recommendations - -Finally, we summarize some takeaways that developers should follow to improve the success of reusing their developed software. - -For improving the reliability of their software, developers should use classical development best practices, for example continuous integration, testing, code review. -For improving the reusability developers should write a documentation about the tool usage and provide a minimal working example and describe the expected results. -Interactions with the running environment should be minimized, for example by using a docker container, a virtual environment or even a virtual machine. -Additionally, a small dataset should be provided for a more extensive test campaign and the publishing of the expected result on this dataset would ensure to be able to evaluate the reproducibility of experiments. - -Finally, an important remark concerns the libraries used by a tool. -We have seen two types of libraries: -- internal libraries manipulating internal data of the tool; -- external libraries that are used to manipulate the input data (APKs, bytecode, resources). -We observed by our manual investigations that external libraries are the ones leading to crashes because of variations in recent APKs (file format, unknown bytecode instructions, multi-DEX files). -We believe that the developer should provide enough documentation to make possible a later upgrade of these external libraries. -//: for example, old versions of apktool are the top most libraries raising errors. - -=== Threats to validity - - -Our application dataset is biased in favor of Androguard, because Androzoo have already used Androguard internally when collecting applications and discarded any application that cannot be processed with this tool. - -Despite our best efforts, it is possible that we made mistakes when building or using the tools. -It is also possible that we wrongly classified a result as a failure. -To mitigate this possible problem we contacted the authors of the tools to confirm that we used the right parameters and chose a valid failure criterion. -// Before running the final experiment, we also ran the tools on a subset of our dataset and looked manually the most common errors to ensure that they are not trivial errors that can be solved. - -The timeout value, amount of memory are arbitrarily fixed. -For mitigating their effect, a small extract of our dataset has been analyzed with more memory/time for measuring any difference. - -Finally, the use of VirusTotal for determining if an application is a malware or not may be wrong. -For limiting this impact, we used a threshold of at most 5 antiviruses (resp. no more than 0) reporting an application as being a malware (resp. goodware) for taking a decision about maliciousness (resp. benignness). -/* -== Discussion - #figure({ show table: set text(size: 0.50em) show table.cell.where(y: 0): it => if it.x == 0 { it } else { rotate(-90deg, reflow: true, it) } @@ -139,8 +94,6 @@ For limiting this impact, we used a threshold of at most 5 antiviruses (resp. no ) - - In this section, we investigate the reasons behind the high ratio of failures presented in @sec:rasta-xp. @tab:rasta-avgerror reports the average number of errors, the average time and memory consumption of the analysis of one APK file. We also compare our conclusions to the ones of the literature. @@ -254,7 +207,7 @@ Anadroid: DONE SELECT AVG(cnt), MAX(cnt) FROM (SELECT COUNT(*) AS cnt FROM error WHERE tool_name = 'anadroid' AND msg='Could not decode arsc file' GROUP BY sha256); */ -#paragraph[Androguard and Androguard_dad])[ +#paragraph[Androguard and Androguard_dad][ Surprisingly, while Androguard almost never fails to analyze an APK, the internal decompiler of Androguard (DAD) fails more than half of the time. The analysis of the logs shows that the issue comes from the way the decompiled methods are stored: each method is stored in a file named after the method name and signature, and this file name can quickly exceed the size limit (255 characters on most file systems). It should be noticed that Androguard_dad rarely fails on the Drebin dataset. @@ -398,9 +351,13 @@ We believe that it is explained by the fact that the complexity of the code incr 58.88 */ -Second, our finding are consistent with the numerical results of Pauck #etal that showed that #mypercent(106, 180) of DIALDroid-Bench 30 real-world applications are analyzed successfully with the 6 evaluated tools@pauckAndroidTaintAnalysis2018. + +=== State-of-the-art comparison + +Our finding are consistent with the numerical results of Pauck #etal that showed that #mypercent(106, 180) of DIALDroid-Bench@bosuCollusiveDataLeak2017 real-world applications are analyzed successfully with the 6 evaluated tools@pauckAndroidTaintAnalysis2018. Six years after the release of DIALDroid-Bench, we obtain a lower ratio of #mypercent(40.05, 100) for the same set of 6 tools but using the Rasta dataset of #NBTOTALSTRING applications. -We extended this result to our set of #nbtoolsvariationsrun tools and obtained a global success rate of #resultratio. +We extended this result to a set of #nbtoolsvariationsrun tools and obtained a global success rate of #resultratio. +We confirmed that most tools require a significant amount of work to get them running@reaves_droid_2016. Our investigations of crashes also confirmed that dependencies to older versions of Apktool are impacting the performances of Anadroid, Saaf and Wognsen #etal in addition to DroidSafe and IccTa, already identified by Pauck #etal. /* @@ -436,5 +393,37 @@ We confirmed that most tools require a significant amount of work to get them ru We encounter similar issues with libraries and operating system incompatibilities, and noticed that, with time, dependencies issues may impact the build process. For instance we encountered cases where the repository hosting the dependencies were closed, or cases where maven failed to download dependencies because the OS version did not support SSL, now mandatory to access maven central. //, and even one case were the could not find anywhere the compiled version of sbt used to build a tool. -*/ + +=== Recommendations + +Finally, we summarize some takeaways that developers should follow to improve the success of reusing their developed software. + +For improving the reliability of their software, developers should use classical development best practices, for example continuous integration, testing, code review. +For improving the reusability developers should write a documentation about the tool usage and provide a minimal working example and describe the expected results. +Interactions with the running environment should be minimized, for example by using a docker container, a virtual environment or even a virtual machine. +Additionally, a small dataset should be provided for a more extensive test campaign and the publishing of the expected result on this dataset would ensure to be able to evaluate the reproducibility of experiments. + +Finally, an important remark concerns the libraries used by a tool. +We have seen two types of libraries: +- internal libraries manipulating internal data of the tool; +- external libraries that are used to manipulate the input data (APKs, bytecode, resources). +We observed by our manual investigations that external libraries are the ones leading to crashes because of variations in recent APKs (file format, unknown bytecode instructions, multi-DEX files). +We believe that the developer should provide enough documentation to make possible a later upgrade of these external libraries. +//: for example, old versions of apktool are the top most libraries raising errors. + +=== Threats to validity + + +Our application dataset is biased in favor of Androguard, because Androzoo have already used Androguard internally when collecting applications and discarded any application that cannot be processed with this tool. + +Despite our best efforts, it is possible that we made mistakes when building or using the tools. +It is also possible that we wrongly classified a result as a failure. +To mitigate this possible problem we contacted the authors of the tools to confirm that we used the right parameters and chose a valid failure criterion. +// Before running the final experiment, we also ran the tools on a subset of our dataset and looked manually the most common errors to ensure that they are not trivial errors that can be solved. + +The timeout value, amount of memory are arbitrarily fixed. +For mitigating their effect, a small extract of our dataset has been analyzed with more memory/time for measuring any difference. + +Finally, the use of VirusTotal for determining if an application is a malware or not may be wrong. +For limiting this impact, we used a threshold of at most 5 antiviruses (resp. no more than 0) reporting an application as being a malware (resp. goodware) for taking a decision about maliciousness (resp. benignness). diff --git a/papers/3_rasta/0_intro.typ b/papers/3_rasta/0_intro.typ new file mode 100644 index 0000000..6e784a0 --- /dev/null +++ b/papers/3_rasta/0_intro.typ @@ -0,0 +1,55 @@ +#import "../lib.typ": etal +#import "X_var.typ": * + +== Introduction + +Android is the most used mobile operating system since 2014, and since 2017, it even surpasses Windows all platforms combined#footnote[https://gs.statcounter.com/os-market-share#monthly-200901-202304]. +The public adoption of Android is confirmed by application developers, with 1.3 millions apps available in the Google Play Store in 2014, and 3.5 millions apps available in 2017#footnote[https://www.statista.com/statistics/266210]. +Its popularity makes Android a prime target for malware developers. // For example, various applications have been shown to steal personal information@shanSelfhidingBehaviorAndroid2018. +Consequently, Android has also been an important subject for security research. +In the past fifteen years, the research community released many tools to detect or analyze malicious behaviors in applications. Two main approaches can be distinguished: static and dynamic analysis@Li2017. +Dynamic analysis requires to run the application in a controlled environment to observe runtime values and/or interactions with the operating system. +For example, an Android emulator with a patched kernel can capture these interactions but the modifications to apply are not a trivial task. +// Such approach is limited by the required time to execute a limited part of the application with no guarantee on the obtained code coverage. +// For malware, dynamic analysis is also limited by evading techniques that may prevent the execution of malicious parts of the code. // To explain better if we restore these sentences about malware + evading. +As a consequence, a lot of efforts have been put in static approaches, which is the focus of this paper. + +The usual goal of a static analysis is to compute data flows to detect potential information leaks@weiAmandroidPreciseGeneral2014 @titzeAppareciumRevealingData2015 @bosuCollusiveDataLeak2017 @klieberAndroidTaintFlow2014 @DBLPconfndssGordonKPGNR15,@octeauCompositeConstantPropagation2015,@liIccTADetectingInterComponent2015 by analyzing the bytecode of an Android application. +The associated developed tools should support the Dalvik bytecode format, the multiplicity of entry points, the event driven architecture of Android applications, the interleaving of native code and bytecode, possibly loaded dynamically, the use of reflection, to name a few. +All these obstacles threaten the research efforts. +When using a more recent version of Android or a recent set of applications, the results previously obtained may become outdated and the developed tools may not work correctly anymore. + + +In this paper/*#footnote[This work was supported by the ANR Research under the Plan France 2030 bearing the reference ANR-22-PECY-0007.]*/, we study the reusability of open source static analysis tools that appeared between 2011 and 2017, on a recent Android dataset. +The scope of our study is *not* to quantify if the output results are accurate for ensuring reproducibility, because all the studied static analysis tools have different goals in the end. +On the contrary, we take as hypothesis that the provided tools compute the intended result but may crash or fail to compute a result due to the evolution of the internals of an Android application, raising unexpected bugs during an analysis. +This paper intends to show that sharing the software artifacts of a paper may not be sufficient to ensure that the provided software would be reusable. + +Thus, our contributions are the following. +We carefully retrieved static analysis tools for Android applications that were selected by Li #etal@Li2017 between 2011 and 2017. +We contacted the authors, whenever possible, for selecting the best candidate versions and to confirm the good usage of the tools. +We rebuild the tools in their original environment and we plan to share our Docker images with this paper. +We evaluated the reusability of the tools by measuring the number of successful analysis of applications taken /*in the Drebin dataset@Arp2014 and */ in a custom dataset that contains more recent applications (#NBTOTALSTRING in total). +The observation of the success or failure of these analysis enables us to answer the following research questions: + +/ RQ1: What Android static analysis tools that are more than 5 years old are still available and can be reused without crashing with a reasonable effort? +/ RQ2: How the reusability of tools evolved over time, especially when analyzing applications that are more than 5 years far from the publication of the tool? +/ RQ3: Does the reusability of tools change when analyzing goodware compared to malware? + +/* +As a summary, the contributions of this paper are the following: + +- We provide containers with a compiled version of all studied analysis tools, which ensures the reproducibility of our experiments and an easy way to analyze applications for other researchers. Additionally receipts for rebuilding such containers are provided. +- We provide a recent dataset of #NBTOTALSTRING applications balanced over the time interval 2010-2023. +- We point out which static analysis tools of Li #etal SLR paper@Li2017 can safely be used and we show that #resultunusable of evaluated tools are unusable (considering that a tool that fails more than 50% of time is unusable). In total, the success rate of the tools we could run is #resultratio on our dataset. +- We discuss the effect of applications features (date, size, SDK version, goodware/malware) on static analysis tools and the nature of the issues we found by studying statistics on the errors captured during our experiments. +*/ + +The paper is structured as follows. +@sec:rasta-soa presents a summary of previous works dedicated to Android static analysis tools. +@sec:rasta-methodology presents the methodology employed to build our evaluation process and @sec:rasta-xp gives the associated experimental results. +// @sec:rasta-discussion investigates the reasons behind the observed failures of some of the tools. +@sec:rasta-discussion discusses the limitations of this work and gives some takeaways for future contributions. +@sec:rasta-conclusion concludes the paper. + + diff --git a/papers/3_rasta/1_related_work.typ b/papers/3_rasta/1_related_work.typ new file mode 100644 index 0000000..bd1fabe --- /dev/null +++ b/papers/3_rasta/1_related_work.typ @@ -0,0 +1,119 @@ +#import "../lib.typ": etal, eg, ie +#import "X_var.typ": * + +== Related Work + +// Research contributions often rely on existing datasets or provide new ones in order to evaluate the developed software. +// Raw datasets such as Drebin@Arp2014 contain few information about the provided applications. +// As a consequence, dataset suites have been developed to provide, in addition to the applications, meta information about the expected results. +// For example, taint analysis datasets should provide the source and expected sink of a taint. +// In some cases, the datasets are provided with additional software for automatizing part of the analysis. +// Thus, +We review in this section the past existing datasets provided by the community and the papers related to static analysis tools reusability. + +=== Application Datasets + +Computing if an application contains a possible information flow is an example of a static analysis goal. +Some datasets have been built especially for evaluating tools that are computing information flows inside Android applications. +One of the first well known dataset is DroidBench, that was released with the tool Flowdroid@Arzt2014a. +Later, the dataset ICC-Bench was introduced with the tool Amandroid@weiAmandroidPreciseGeneral2014 to complement DroidBench by introducing applications using Inter-Component data flows. +These datasets contain carefully crafted applications containing flows that the tools should be able to detect. +These hand-crafted applications can also be used for testing purposes or to detect any regression when the software code evolves. +Contrary to real world applications, the behavior of these hand-crafted applications is known in advance, thus providing the ground truth that the tools try to compute. +However, these datasets are not representative of real-world applications@Pendlebury2018 and the obtained results can be misleading. +//, especially for performance or reliability evaluation. + +Contrary to DroidBench and ICC-Bench, some approaches use real-world applications. +Bosu #etal@bosuCollusiveDataLeak2017 use DIALDroid to perform a threat analysis of Inter-Application communication and published DIALDroid-Bench, an associated dataset. +Similarly, Luo #etal released TaintBench@luoTaintBenchAutomaticRealworld2022 a real-world dataset and the associated recommendations to build such a dataset. +These datasets confirmed that some tools such as Amandroid@weiAmandroidPreciseGeneral2014 and Flowdroid@Arzt2014a are less efficient on real-world applications. +These datasets are useful for carefully spotting missing taint flows, but contain only a few dozen of applications. +// A larger number of applications would be more suitable for our goal, #ie evaluating the reusability of a variety of static analysis tools. + + +Pauck #etal@pauckAndroidTaintAnalysis2018 used those three datasets to compare Amandroid@weiAmandroidPreciseGeneral2014, DIAL-Droid@bosuCollusiveDataLeak2017, DidFail@klieberAndroidTaintFlow2014, DroidSafe@DBLPconfndssGordonKPGNR15, FlowDroid@Arzt2014a and IccTA@liIccTADetectingInterComponent2015 -- all these tools will be also compared in this paper. +To perform their comparison, they introduced the AQL (Android App Analysis Query Language) format. +AQL can be used as a common language to describe the computed taint flow as well as the expected result for the datasets. +It is interesting to notice that all the tested tools timed out at least once on real-world applications, and that Amandroid@weiAmandroidPreciseGeneral2014, DidFail@klieberAndroidTaintFlow2014, DroidSafe@DBLPconfndssGordonKPGNR15, IccTA@liIccTADetectingInterComponent2015 and ApkCombiner@liApkCombinerCombiningMultiple2015 (a tool used to combine applications) all failed to run on applications built for Android API 26. +These results suggest that a more thorough study of the link between application characteristics (#eg date, size) should be conducted. +Luo #etal@luoTaintBenchAutomaticRealworld2022 used the framework introduced by Pauck #etal to compare Amandroid@weiAmandroidPreciseGeneral2014 and Flowdroid@Arzt2014a on DroidBench and their own dataset TaintBench, composed of real-world android malware. +They found out that those tools have a low recall on real-world malware, and are thus over adapted to micro-datasets. +Unfortunately, because AQL is only focused on taint flows, we cannot use it to evaluate tools performing more generic analysis. + +=== Static Analysis Tools Reusability + +Several papers have reviewed Android analysis tools produced by researchers. +Li #etal@Li2017 published a systematic literature review for Android static analysis before May 2015. +They analyzed 92 publications and classified them by goal, method used to solve the problem and underlying technical solution for handling the bytecode when performing the static analysis. +In particular, they listed 27 approaches with an open-source implementation available. +Nevertheless, experiments to evaluate the reusability of the pointed out software were not performed. +We believe that the effort of reviewing the literature for making a comprehensive overview of available approaches should be pushed further: an existing published approach with a software that cannot be used for technical reasons endanger both the reproducibility and reusability of research. + +A first work about quantifying the reusability of static analysis tools was proposed by Reaves #etal@reaves_droid_2016. +Seven Android analysis tools (Amandroid@weiAmandroidPreciseGeneral2014, AppAudit@xiaEffectiveRealTimeAndroid2015, DroidSafe@DBLPconfndssGordonKPGNR15, Epicc@octeau2013effective, FlowDroid@Arzt2014a, MalloDroid@fahlWhyEveMallory2012 and TaintDroid@Enck2010) were selected to check if they were still readily usable. +For each tool, both the usability and results of the tool were evaluated by asking auditors to install and use it on DroidBench and 16 real world applications. +The auditors reported that most of the tools require a significant amount of time to setup, often due to dependencies issues and operating system incompatibilities. +Reaves #etal propose to solve these issues by distributing a Virtual Machine with a functional build of the tool in addition to the source code. +Regrettably, these Virtual Machines were not made available, preventing future researchers to take advantage of the work done by the auditors. +Reaves #etal also report that real world applications are more challenging to analyze, with tools having lower results, taking more time and memory to run, sometimes to the point of not being able to run the analysis. +We will confirm and expand this result in this paper with a larger dataset than only 16 real-world applications. +// Indeed, a more diverse dataset would assess the results and give more insight about the factors impacting the performances of the tools. + +// PAS LA PLACE ! +// Finally, our approach is similar to the methodology employed by Mauthe #etal for decompilers@mauthe_large-scale_2021. +// To assess the robustness of android decompilers, Mauthe #etal used 4 decompilers on a dataset of 40 000 applications. +// The error messages of the decompilers were parsed to list the methods that failed to decompile, and this information was used to estimate the main causes of failure. +// It was found that the failure rate is correlated to the size of the method, and that a consequent amount of failure are from third parties library rather than the core code of the application. +// They also concluded that malware are easier to entirely decompile, but have a higher failure rate, meaning that the one that are hard to decompile are substantially harder to decompile than goodware. + + +/* +luoTaintBenchAutomaticRealworld2022 (TaintBench): + - micro dataset app 'bad' (over adapted, perf drop with real world app) but + no found truth for real world apk: provide real world apk with ground truth + - provide a dataset framework for taint analysis on top of reprodroid + - /!\ compare current and previously evaluated version of AmAndroid and Flowdroid: + -> Up to date version of both tools are less accurate than predecessor <- + - timeout 20min: AmAndroid 11 apps, unsuccessfull exits 9 + +pauckAndroidTaintAnalysis2018 (ReproDroid): + - Introduce AQL (Android app analysis query language): standard langage to describe input + and output of a taint analysis tool, it allows to compare two taint analysis tools + - Introduce BREW (dataset refinement and execution wizard), a dataset framework + - Reproducible comparison of AmAndroid, DIAL-Droid, DidFail, DroidSafe, FlowDroid and IccTA + on Droid-Bench, ICC-Bench and DIALDroid-Bench(30 large real world app) + 18 custom apps + - real workd app test: 30 min timeout, all tools timedout/failled(?) at least once + - support for newer Android version: AmAndroid, DidFail, DroidSafe, IccTA, ApkCombiner fails + to run on apk build for API 26 + +reaves_droid_2016 (*Droid): + - assessment of apk analysis tools and challenges + - Test 7 tools to see if usable by dev and auditors (conclusion: challenging to use, difficult + to interpret output) + - AmAndroid: only run on small apk + - AppAudit: failled on 11/16 real world app (due to native code in 4 of those cases) + - DroidSafe: Fails every times due to memory leak + - Epicc: no pb, everage time < 20min for real world apks + - FlowDroid: Failled to analyse real world apks with default settings, and even with + 64GB of ram could only analyse 1/6 apk of a real world category (mobile money app) + - MalloDroid: no pb + - TaintDroid: 7 crashes for 16 real worlds apks, probably due to native code + - **Found that those tools are frustrating to use, partly because of dependency issues and + OS incompatibility.** Ask for a full working VM as artifact. + +Arzt2014a (DroidBench, same paper as flowdroid) + - hand crafted Android apps with test cases for interesting static-analysis problems like + field sensitivity, object sensitivity, access-path lengths, application life cycle, + async callback, ui interaction + + + A Large-Scale Empirical Study of Android App Decompilation + Noah Mauthe, Ulf Kargen, Nahid Shahmehri + + + +TaintBench@luoTaintBenchAutomaticRealworld2022 +ReproDroid@pauckAndroidTaintAnalysis2018 +*droid@reaves_droid_2016 +DroidBench@Arzt2014a +*/ diff --git a/papers/3_rasta/2_methodology.typ b/papers/3_rasta/2_methodology.typ new file mode 100644 index 0000000..e7d4fd6 --- /dev/null +++ b/papers/3_rasta/2_methodology.typ @@ -0,0 +1,274 @@ +#import "../lib.typ": todo, etal, eg +#import "X_var.typ": * +#import "X_lib.typ": * + +== Methodology + +=== Collecting Tools + +#figure({ + show table: set text(size: 0.80em) + show "#etal": etal + let show_citekeys(keys) = [ + #keys.split(",").map( + citekey => cite(label(citekey))).join([] + ) (#keys.split(",").map( + citekey => cite(label(citekey), form: "year") + ).join([])) + ] + table( + columns: 7, + inset: (x: 0% + 5pt, y: 0% + 2pt), + stroke: none, + align: center+horizon, + table.hline(), + table.header( + table.cell(colspan: 7, inset: 3pt)[], + table.cell(rowspan:2)[*Tool*], + table.vline(end: 3), + table.vline(start: 4), + table.cell(colspan:3)[*Availability*], + table.vline(end: 3), + table.vline(start: 4), + [*Repo*], + table.vline(end: 3), + table.vline(start: 4), + table.cell(rowspan:2)[*Decision*], + table.vline(end: 3), + table.vline(start: 4), + table.cell(rowspan:2)[*Comments*], + + [Bin], + [Src], + [Doc], + [type], + ), + table.cell(colspan: 7, inset: 3pt)[], + table.hline(), + table.cell(colspan: 7, inset: 3pt)[], + ..rasta_tool_data + .map(entry => ( + [#entry.tool #show_citekeys(entry.citekey)], + str2sym(entry.binary), + str2sym(entry.source), + str2sym(entry.documentation), + link(entry.url, entry.repo), + str2sym(entry.decision), + entry.why, + )).flatten(), + table.cell(colspan: 7, inset: 3pt)[], + table.hline(), + table.cell(colspan: 7, inset: 3pt)[], + table.hline(), + ) + [ + *binaries, sources*: #nr: not relevant, #ok: available, #bad: partially available, #ko: not provided\ + *documentation*: #okk: excellent, MWE, #ok: few inconsistencies, #bad: bad quality, #ko: not available\ + *decision*: #ok: considered; #bad: considered but not built; #ko: out of scope of the study + ]}, + caption: [Considered tools@Li2017: availability and usage reliability], +) + +We collected the static analysis tools from@Li2017, plus one additional paper encountered during our review of the state-of-the-art (DidFail@klieberAndroidTaintFlow2014). +They are listed in @tab:rasta-tools, with the original release date and associated paper. +We intentionally limited the collected tools to the ones selected by Li #etal@Li2017 for several reasons. +First, not using recent tools enables to have a gap of at least 5 years between the publication and the more recent APK files, which enables to measure the reusability of previous contribution with a reasonable gap of time. +Second, collecting new tools would require to describe these tools in depth, similarly to what have been performed by Li #etal@Li2017, which is not the primary goal of this paper. +Additionally, selection criteria such as the publication venue or number of citations would be necessary to select a subset of tools, which would require an additional methodology. +These possible contributions are left for future work. + +Some tools use hybrid analysis (both static and dynamic): A3E@DBLPconfoopslaAzimN13, A5@vidasA5AutomatedAnalysis2014, Android-app-analysis@geneiatakisPermissionVerificationApproach2015, StaDynA@zhauniarovichStaDynAAddressingProblem2015. +They have been excluded from this paper. +We manually searched the tool repository when the website mentioned in the paper is no longer available (#eg when the repository have been migrated from Google code to GitHub) and for each tool we searched for: + +- an optional binary version of the tool that would be usable as a fall back (if the sources cannot be compiled for any reason); +- the source code of the tool; +- the documentation for building and using the tool with a MWE (Minimum Working Example). + +In @tab:rasta-tools we rated the quality of these artifacts with "#ok" when available but may have inconsistencies, a "#bad" when too much inconsistencies (inaccurate remarks about the sources, dead links or missing parts) have been found, a "#ko" when no documentation have been found, and a double "#okk" for the documentation when it covers all our expectations (building process, usage, MWE). +Results show that documentation is often missing or very poor (#eg Lotrack), which makes the rebuild process very complex and the first analysis of a MWE. + + +We finally excluded Choi #etal@CHOI2014620 as their tool works on the sources of Android applications, and Poeplau #etal@DBLPconfndssPoeplauFBKV14 that focus on Android hardening. +As a summary, in the end we have #nbtoolsselected tools to compare. +Some specificities should be noted. +The IC3 tool will be duplicated in our experiments because two versions are available: the original version of the authors and a fork used by other tools like IccTa. +For Androguard, the default task consists of unpacking the bytecode, the resources, and the Manifest. +Cross-references are also built between methods and classes. +Because such a task is relatively simple to perform, we decided to duplicate this tool and ask to Androguard to decompile an APK and create a control flow graph of the code using its decompiler: DAD. +We refer to this variant of usage as androguard_dad. + For Thresher and Lotrack, because these tools cannot be built, we excluded them from experiments. + + Finally, starting with #nbtools tools of @tab:rasta-tools, with the two variations of IC3 and Androguard, we have in total #nbtoolsselectedvariations static analysis tools to evaluate in which two tools cannot be built and will be considered as always failing. + +=== Source Code Selection and Building Process + +#figure({ + show table: set text(size: 0.80em) + show "#etal": etal + let show_citekeys(keys) = [ + #keys.split(",").map( + citekey => cite(label(citekey))).join([] + ) + ] + table( + columns: 8, + inset: (x: 0% + 5pt, y: 0% + 2pt), + stroke: none, + align: center+horizon, + table.hline(), + table.header( + table.cell(colspan: 8, inset: 3pt)[], + table.cell(rowspan:2)[*Tool*], + table.vline(end: 3), + table.vline(start: 4), + table.cell(colspan:2)[*Origin*], + table.vline(end: 3), + table.vline(start: 4), + table.cell(colspan:2)[*Alive Forks*], + table.vline(end: 3), + table.vline(start: 4), + table.cell(rowspan:2)[*Last Commit \ Date*], + table.vline(end: 3), + table.vline(start: 4), + table.cell(rowspan:2)[*Authors \ Reached*], + table.vline(end: 3), + table.vline(start: 4), + [*Environment*], + + [Stars], + [Alive], + [Nb], + [Usable], + [Language -- OS], + ), + table.cell(colspan: 8, inset: 3pt)[], + table.hline(), + table.cell(colspan: 8, inset: 3pt)[], + ..rasta_tool_data + .filter(entry => entry.exclude != "EXCLUDE") + .map(entry => ( + [#entry.tool #show_citekeys(entry.citekey)], + entry.stars, + str2sym(entry.alive), + entry.nbaliveforks, + str2sym(entry.forkusable), + entry.selecteddate, + str2sym(entry.authorconfirmed), + [#entry.lang -- #entry.os] + )).flatten(), + table.cell(colspan: 8, inset: 3pt)[], + table.hline(), + table.cell(colspan: 8, inset: 3pt)[], + table.hline(), + ) + [#ok: yes, #ko: no, UX.04: Ubuntu X.04]}, + caption: [Selected tools, forks, selected commits and running environment], +) + +In a second step, we explored the best sources to be selected among the possible forks of a tool. +We reported some indicators about the explored forks and our decision about the selected one in @tab:rasta-sources. +For each source code repository called "Origin", we reported in @tab:rasta-sources the number of GitHub stars attributed by users and we mentioned if the project is still alive (#ok in column Alive when a commit exist in the last two years). +Then, we analyzed the fork tree of the project. +We searched recursively if any forked repository contains a more recent commit than the last one of the branch mentioned in the documentation of the original repository. +If such a commit is found (number of such commits are reported in column Alive Forks Nb), we manually looked at the reasons behind this commit and considered if we should prefer this more up-to-date repository instead of the original one (column "Alive Forks Usable"). +As reported in @tab:rasta-sources, we excluded all forks, except IC3 for which we selected the fork JordanSamhi/ic3, because they always contain experimental code with no guarantee of stability. +For example, a fork of Aparecium contains a port for Windows 7 which does not suggest an improvement of the stability of the tool. +For IC3, the fork seems promising: it has been updated to be usable on a recent operating system (Ubuntu 22.04 instead of Ubuntu 12.04 for the original version) and is used as a dependency by IccTa. +We decided to keep these two versions of the tool (IC3 and IC3_fork) to compare their results. + +Then, we self-allocated a maximum of four days for each tool to successfully read and follow the documentation, compile the tool and obtain the expected result when executing an analysis of a MWE. +We sent an email to the authors of each tool to confirm that we used the more suitable version of the code, that the command line we used to analyze an application is the most suitable one and, in some cases, requested some help to solve issues in the building process. +We reported in @tab:rasta-sources the authors that answered our request and confirmed our decisions. + +From this building phase, several observations can be made. +Using a recent operating system, it is almost impossible in a reasonable amount of time to rebuild a tool released years ago. +Too many dependencies, even for Java based programs, trigger compilation or execution problems. +Thus, if the documentation mentions a specific operating system, we use a Docker image of this OS. +// For example, Dare is a dependency of several tools (Didfail, IC3) and depends on 32 bits libraries such as lib32stdc++ and ia32-libs. +// Those libraries are only available on Ubuntu 12 or previous versions. +// +Most of the time, tools require additional external components to be fully functional. +It could be resources such as the android.jar file for each version of the SDK, a database, additional libraries or tools. +Depending of the quality of the documentation, setting up those components can take hours to days. +This is why we automatized in a Dockerfile the setup of the environment in which the tool is built and run#footnote[To guarantee reproducibility we published the results, datasets, Dockerfiles and containers: https://github.com/histausse/rasta, https://zenodo.org/records/10144014, https://zenodo.org/records/10980349 and on Docker Hub as `histausse/rasta-:icsr2024`] + +=== Runtime Conditions + +#figure( + image( + "figs/running.svg", + width: 80%, + alt: "A diagram representing the methodology. The word 'Tool' is linked to a box labeled 'Docker image' by an arrow labeled 'building'. The box 'Docker image' is linked to a box labeled 'Singularity image' by an arrow labeled 'conversion'. The box 'Singularity image' is linked to a box labeled 'Execution monitoring' by a dotted arrow labeled 'Manuel tests' and to an image of a server labeled 'Singularity cluster' by an arrow labeled deployment. An image of three android logo labeled 'apks' is also linked to the 'Singularity cluster' by an arrow labeled 'running the tool analysis'. The 'Singularity cluster' image is linked to the 'Execution monitoring' box by an arrow labeled 'log capture'. The 'Execution monitoring' box linked to the words 'Exit status' by an unlabeled arrow.", + ), + caption: [Methodology overview], +) + +As shown in @fig:rasta-overview, before benchmarking the tools, we built and installed them in a Docker containers for facilitating any reuse of other researchers. +We converted them into Singularity containers because we had access to such a cluster and because this technology is often used by the HPC community for ensuring the reproducibility of experiments. +//The Docker container allows a user to interact more freely with the bundled tools. +//Then, we converted this image to a Singularity image. +We performed manual tests using these Singularity images to check: + +- the location where the tool is writing on the disk. For the best performances, we expect the tools to write on a mount point backed by an SSD. Some tools may write data at unexpected locations which required small patches from us. +- the amount of memory allocated to the tool. We checked that the tool could run a MWE with a #ramlimit limit of RAM. +- the network connection opened by the tool, if any. We expect the tool not to perform any network operation such as the download of Android SDKs. Thus, we prepared the required files and cached them in the images during the building phase. In a few cases, we patched the tool to disable the download of resources. + +A campaign of tests consists in executing the #nbtoolsvariationsrun selected tools on all APKs of a dataset. +The constraints applied on the clusters are: + +- No network connection is authorized in order to limit any execution of malicious software. +- The allocated RAM for a task is #ramlimit. +- The allocated maximum time is 1 hour. +- The allocated object space / stack space is 64 GB / 16 GB if the tool is a Java based program. + +For the disk files, we use a mount point that is stored on a SSD disk, with no particular limit of size. +Note that, because the allocation of #ramlimit could be insufficient for some tool, we evaluated the results of the tools on 20% of our dataset (described later in @sec:rasta-dataset) with 128 GB of RAM and #ramlimit of RAM and checked that the results were similar. +With this confirmation, we continued our evaluations with #ramlimit of RAM only. + + +=== Dataset + +/* +DATASET + +first seen year: pas dans les BDD officielles d'Androzoo: min added dans AndroZoo et date de VT analysis + +année: 2010 et 2023 + +7% de malware + +0 detection dans VT: good +5+ => malware +0-5 detection: exclu + + +Les tranches de taille sont des déciles de d'androzoo (- les 1% extreme) +pour chaque année, pour chaque tranche de taille, on selectionne randomly 500 applications (avec bonne proporotion de malware) = bucket. + +Probleme: Ce n'est pas représentatif de la population: il n'y a propablement pas 7% de malware and chaque décile d'androzoo pour chaque année +Probleme 2: pour sampler, on utilise les deciles de taille d'apk, mais pour nos plot on utiliser les deciles de taille de dex file. + +500*10*14=70000 + + +*/ + +// Two datasets are used in the experiments of this section. +// The first one is *Drebin*@Arp2014, from which we extracted the malware part (5479 samples that we could retrieved) for comparison purpose only. +// It is a well known and very old dataset that should not be used anymore because it contains temporal and spatial biases@Pendlebury2018. +// We intend to compare the rate of success on this old dataset with a more recent one. +// The second one, +We built a dataset named *Rasta* to cover all dates between 2010 to 2023. +This dataset is a random extract of Androzoo@allixAndroZooCollectingMillions2016, for which we balanced applications between years and size. +For each year and inter-decile range of size in Androzoo, 500 applications have been extracted with an arbitrary proportion of 7% of malware. +This ratio has been chosen because it is the ratio of goodware/malware that we observed when performing a raw extract of Androzoo. +For checking the maliciousness of an Android application we rely on the VirusTotal detection indicators. +If more than 5 antiviruses have flagged the application as malicious, we consider it as a malware. +If no antivirus has reported the application as malicious, we consider it as a goodware. +Applications in between are dropped. + +For computing the release date of an application, we contacted the authors of Androzoo to compute the minimum date between the submission to Androzoo and the first upload to VirusTotal. +Such a computation is more reliable than using the DEX date that is often obfuscated when packaging the application. + +// #todo[Transition] // plus de place :-( diff --git a/papers/3_rasta/3_experiments.typ b/papers/3_rasta/3_experiments.typ new file mode 100644 index 0000000..fb2c369 --- /dev/null +++ b/papers/3_rasta/3_experiments.typ @@ -0,0 +1,394 @@ +#import "../lib.typ": todo, highlight, num, paragraph +#import "X_var.typ": * +#import "X_lib.typ": * + +== Experiments + + +=== RQ1: Re-Usability Evaluation + + +#todo[alt text for figure rasta-exit / rasta-exit-drebin] +#figure( + image("figs/exit-status-for-the-drebin-dataset.svg", width: 80%), + caption: [Exit status for the Drebin dataset], +) + +#figure( + image("figs/exit-status-for-the-rasta-dataset.svg", width: 80%), + caption: [Exit status for the Rasta dataset], +) + + +@fig:rasta-exit-drebin and @fig:rasta-exit compare the Drebin and Rasta datasets. +They represent the success/failure rate (green/orange) of the tools. +We distinguished failure to compute a result from timeout (blue) and crashes of our evaluation framework (in grey, probably due to out of memory kills of the container itself). +Because it may be caused by a bug in our own analysis stack, exit status represented in grey (Other) are considered as unknown errors and not as failure of the tool. +#todo[We discuss further errors for which we have information in the logs in /*@*/sec:rasta-failure-analysis.] + +Results on the Drebin datasets shows that 11 tools have a high success rate (greater than 85%). +The other tools have poor results. +The worst, excluding Lotrack and Tresher, is Anadroid with a ratio under 20% of success. + +On the Rasta dataset, we observe a global increase of the number of failed status: #resultunusablenb tools (#resultunusable) have a finishing rate below 50%. +The tools that have bad results with Drebin are of course bad result on Rasta. +Three tools (androguard_dad, blueseal, saaf) that were performing well (higher than 85%) on Drebin surprisingly fall below the bar of 50% of failure. +7 tools keep a high success rate: Adagio, Amandroid, Androguard, Apparecium, Gator, Mallodroid, Redexer. +Regarding IC3, the fork with a simpler build process and support for modern OS has a lower success rate than the original tool. + +Two tools should be discussed in particular. +//Androguard and Flowdroid have a large community of users, as shown by the numbers of GitHub stars in @tab:rasta-sources. +Androguard has a high success rate which is not surprising: it used by a lot of tools, including for analyzing application uploaded to the Androzoo repository. +//Because of that, it should be noted that our dataset is biased in favour of Androguard. // Already in discution +Nevertheless, when using Androguard decompiler (DAD) to decompile an APK, it fails more than 50% of the time. +This example shows that even a tool that is frequently used can still run into critical failures. +Concerning Flowdroid, our results show a very low timeout rate (#mypercent(37, NBTOTAL)) which was unexpected: in our exchanges, Flowdroid's author were expecting a higher rate of timeout and fewer crashes. + +As a summary, the final ratio of successful analysis for the tools that we could run +// and applications of Rasta dataset +is #mypercent(54.9, 100). When including the two defective tools, this ratio drops to #mypercent(49.9, 100). + +#highlight()[ +*RQ1 answer:* +On a recent dataset we consider that #resultunusable of the tools are unusable. +For the tools that we could run, #resultratio of analysis are finishing successfully. +//(those with less than 50% of successful execution and including the two tools that we were unable to build). +] + +/* +== RQ2: temporal evolution + +#todo[alt text for fig rasta-exit-evolution-java and rasta-exit-evolution-not-java] + +#figure(stack(dir: ltr, + [#figure( + image( + "figs/finishing-rate-by-year-of-java-based-tools.svg", + width: 48%, + alt: "" + ), + caption: [Java based tools], + supplement: [Subfigure], + ) ], + [#figure( + image( + "figs/finishing-rate-by-year-of-non-java-based-tools.svg", + width: 48%, + alt: "", + ), + caption: [Non Java based tools], + supplement: [Subfigure], + ) ] + ), caption: [Exit status evolution for the Rasta dataset] +) + +For investigating the effect of application dates on the tools, we computed the date of each APK based on the minimum date between the first upload in AndroZoo and the first analysis in VirusTotal. +Such a computation is more reliable than using the dex date that is often obfuscated when packaging the application. +Then, for the sake of clarity of our results, we separated the tools that have mainly Java source code from those that use other languages. +Among the ones that are Java based programs, most of them use the Soot framework which may correlate the obtained results. +@fig:rasta-exit-evolution-java (resp. @fig:rasta-exit-evolution-not-java) compares the success rate of the tools between 2010 and 2023 for Java based tools (resp. non Java based tools). +For Java based tools, a clear decrease of finishing rate can be observed globally for all tools. +For non-Java based tools, 2 of them keep a high success rate (Androguard, Mallodroid). +The result is expected for Androguard, because the analysis is relatively simple and the tool is largely adopted, as previously mentioned. +Mallodroid being a relatively simple script leveraging Androgard, it benefit from Androguard resilience. +It should be noted that Saaf keeps a high success ratio until 2014 and then quickly decreases to less than 20% after 2014. This example shows that, even with an identical source code and the same running platform, a tool can change of behavior among time because of the evolution of the structure of the input files. + +An interesting comparison is the specific case of Ic3 and Ic3_fork. Until 2019, the success rate is very similar. After 2020, ic3_fork is continuing to decrease whereas Ic3 keeps a success rate of around 60%. + +/* +``` +sqlite> SELECT apk1.first_seen_year, (COUNT(*) * 100) / (SELECT 20 * COUNT(*) +(x1...> FROM apk AS apk2 WHERE apk2.first_seen_year = apk1.first_seen_year +(x1...> ) +...> FROM exec JOIN apk AS apk1 ON exec.sha256 = apk1.sha256 +...> WHERE exec.tool_status = 'FINISHED' OR exec.tool_status = 'UNKNOWN' +...> GROUP BY apk1.first_seen_year ORDER BY apk1.first_seen_year; +2010|78 +2011|78 +2012|76 +2013|70 +2014|66 +2015|61 +2016|57 +2017|54 +2018|49 +2019|47 +2020|45 +2021|42 +2022|40 +2023|39 +``` +*/ + +#highlight()[ +*RQ2 answer:* For the #nbtoolsselected tools that can be used partially, a global decrease of the success rate of tools' analysis is observed over time. +Starting at 78% of success rate, after five years, tools have 61% of success; after ten years, 45% of success. +] +*/ + + +=== RQ2: Size, SDK and Date Influence + +To measure the influence of the date, SDK version and size of applications, we fixed one parameter while varying an other. +For the sake of clarity, we separated Java based / non Java based tools. + +#todo[Alt text for fig rasta-decorelation-size] +#figure(stack(dir: ltr, + [#figure( + image( + "figs/decorelation/finishing-rate-of-java-based-tool-by-bytecode-size-of-apks-detected-in-2022.svg", + width: 48%, + alt: "" + ), + caption: [Java based tools], + supplement: [Subfigure], + ) ], + [#figure( + image( + "figs/decorelation/finishing-rate-of-non-java-based-tool-by-bytecode-size-of-apks-detected-in-2022.svg", + width: 48%, + alt: "", + ), + caption: [Non Java based tools], + supplement: [Subfigure], + ) ] + ), caption: [Finishing rate by bytecode size for APK detected in 2022] +) + +#paragraph([Fixed application year. (#num(5000) APKs)])[ +We selected the year 2022 which has a good amount of representatives for each decile of size in our application dataset. +@fig:rasta-rate-evolution-java-2022} (resp. @fig:rasta-rate-evolution-non-java-2022) shows the finishing rate of the tools in function of the size of the bytecode for Java based tools (resp. non Java based tools) analyzing applications of 2022. +We can observe that all Java based tools have a finishing rate decreasing over years. 50% of non Java based tools have the same behavior. +] + +#todo[Alt text for fig rasta-decorelation-size] +#figure(stack(dir: ltr, + [#figure( + image( + "figs/decorelation/finishing-rate-of-java-based-tool-by-discovery-year-of-apks-with-a-bytecode-size-between-4-08-mb-and-5-2-mb.svg", + width: 48%, + alt: "" + ), + caption: [Java based tools], + supplement: [Subfigure], + ) ], + [#figure( + image( + "figs/decorelation/finishing-rate-of-non-java-based-tool-by-discovery-year-of-apks-with-a-bytecode-size-between-4-08-mb-and-5-2-mb.svg", + width: 48%, + alt: "", + ), + caption: [Non Java based tools], + supplement: [Subfigure], + ) ] + ), caption: [Finishing rate by discovery year with a bytecode size $in$ [4.08, 5.2] MB] +) + +#paragraph([Fixed application bytecode size. (#num(6252) APKs)])[We selected the sixth decile (between 4.08 and 5.20 MB), which is well represented in a wide number of years. +@fig:rasta-rate-evolution-java-decile-year (resp. @fig:rasta-rate-evolution-non-java-decile-year) represents the finishing rate depending of the year at a fixed bytecode size. +We observe that 9 tools over 12 have a finishing rate dropping below 20% for Java based tools, which is not the case for non Java based tools. +] + +#todo[Alt text for fig rasta-decorelation-min-sdk] +#figure(stack(dir: ltr, + [#figure( + image( + "figs/decorelation/finishing-rate-of-java-based-tool-by-min-sdk-of-apks-with-a-bytecode-size-between-4-08-mb-and-5-2-mb.svg", + width: 48%, + alt: "" + ), + caption: [Java based tools], + supplement: [Subfigure], + ) ], + [#figure( + image( + "figs/decorelation/finishing-rate-of-non-java-based-tool-by-min-sdk-of-apks-with-a-bytecode-size-between-4-08-mb-and-5-2-mb.svg", + width: 48%, + alt: "", + ), + caption: [Non Java based tools], + supplement: [Subfigure], + ) ] + ), caption: [Finishing rate by min SDK with a bytecode size $in$ [4.08, 5.2] MB] +) + +We performed similar experiments by variating the min SDK and target SDK versions, still with a fixed bytecode size between 4.08 and 5.2 MB, as shown in @fig:rasta-rate-evolution-java-decile-min-sdk and @fig:rasta-rate-evolution-non-java-decile-min-sdk. +We found that contrary to the target SDK, the min SDK version has an impact on the finishing rate of Java based tools: 8 tools over 12 are below 50% after SDK 16. +It is not surprising, as the min SDK is highly correlated to the year. + +#highlight()[ +*RQ2 answer:* +The success rate varies based on the size of bytecode and SDK version. +The date is also correlated with the success rate for Java based tools only. +] + + +=== RQ3: Malware vs Goodware + +/* +``` +sqlite> SELECT vt_detection == 0, COUNT(exec.sha256) FROM exec INNER JOIN apk ON exec.sha256 = apk.sha256 WHERE tool_status = 'FINISHED' AND dex_size_decile = 6 GROUP BY vt_detection == 0; +0|2971 % malware +1|60455 % goodware +sqlite> SELECT vt_detection == 0, COUNT(DISTINCT sha256) FROM apk WHERE dex_size_decile = 6 GROUP BY vt_detection == 0; +0|243 +1|6009 +``` +``` +>>> 61.13168724279835 +0.4969812257050699 +>>> 60455/6009/20 * 100 +50.30371110001665 +``` + + rate goodware rate malware avg size goodware (MB) avg size malware (MB) + decile 1: 85.42 82.02 0.13 0.11 + decile 2: 74.46 72.34 0.54 0.55 + decile 3: 63.38 65.67 1.37 1.25 + decile 4: 57.21 62.31 2.41 2.34 + decile 5: 53.36 59.27 3.56 3.55 + decile 6: 50.3 61.13 4.61 4.56 + decile 7: 46.76 56.54 5.87 5.91 + decile 8: 42.57 56.23 7.64 7.63 + decile 9: 39.09 57.94 11.39 11.26 + decile 10: 33.34 45.86 24.24 21.36 + total: 54.28 64.82 6.29 4.14 +*/ + + +/* +#todo[Alt text for rasta-exit-goodmal] +#figure( + image( + "figs/exit-status-for-the-rasta-dataset-goodware-malware.svg", + width: 80%, + alt: "", + ), + caption: [Exit status comparing goodware and malware for the Rasta dataset], +) +*/ + + +/* +[15:25] Jean-Marie Mineau + +moyenne de la taille total des dex: 6464228.10027989 + +[15:26] Jean-Marie Mineau + +(tout confondu) + +[15:26] Jean-Marie Mineau + +goodware: 6598464.94224066 + +malware: 4337376.97252155 + +``` +sqlite> SELECT AVG(apk_size) FROM apk; +16918107.6526989 +sqlite> SELECT AVG(apk_size) FROM apk WHERE vt_detection = 0; +16897989.4472311 +sqlite> SELECT AVG(apk_size) FROM apk WHERE vt_detection != 0; +17236860.8903556 +``` +*/ + + +/* +#figure({ + show table: set text(size: 0.80em) + table( + columns: 4, + inset: (x: 0% + 5pt, y: 0% + 2pt), + stroke: none, + align: center+horizon, + table.hline(), + table.header( + table.cell(colspan: 4, inset: 3pt)[], + table.cell(rowspan:2)[*Rasta part*], + table.vline(end: 3), + table.vline(start: 4), + table.cell(colspan:2)[*Average size*], + table.vline(end: 3), + table.vline(start: 4), + table.cell(rowspan:2)[*Average date*], + [*APK*], + [*DEX*], + ), + table.cell(colspan: 4, inset: 3pt)[], + table.hline(), + table.cell(colspan: 4, inset: 3pt)[], + + [*goodware*], num(16897989), num(6598464), [2017], + [*malware*], num(17236860), num(4337376), [2017], + [*total*], num(16918107), num(6464228), [2017], + + table.cell(colspan: 4, inset: 3pt)[], + table.hline(), + )}, + caption: [Average size and date of goodware/malware parts of the Rasta dataset], +) +*/ + + +#figure({ + show table: set text(size: 0.80em) + table( + columns: 7, + inset: (x: 0% + 5pt, y: 0% + 2pt), + stroke: none, + align: center+horizon, + table.hline(), + table.header( + table.cell(colspan: 7, inset: 3pt)[], + table.cell(rowspan: 2)[*Decile*], + table.vline(end: 3), + table.vline(start: 4), + table.cell(colspan:2)[*Average DEX size (MB)*], + table.vline(end: 3), + table.vline(start: 4), + table.cell(colspan:2)[* Finishing Rate: FR*], + table.vline(end: 3), + table.vline(start: 4), + [*Ratio Size*], + table.vline(end: 3), + table.vline(start: 4), + [*Ratio FR*], + [Good], [Mal], + [Good], [Mal], + [Good/Mal], [Good/Mal], + ), + table.cell(colspan: 7, inset: 3pt)[], + table.hline(), + table.cell(colspan: 7, inset: 3pt)[], + + num(1), num(0.13), num(0.11), num(0.85), num(0.82), num(1.17), num(1.04), + num(2), num(0.54), num(0.55), num(0.74), num(0.72), num(0.97), num(1.03), + num(3), num(1.37), num(1.25), num(0.63), num(0.66), num(1.09), num(0.97), + num(4), num(2.41), num(2.34), num(0.57), num(0.62), num(1.03), num(0.92), + num(5), num(3.56), num(3.55), num(0.53), num(0.59), num(1.00), num(0.90), + num(6), num(4.61), num(4.56), num(0.50), num(0.61), num(1.01), num(0.82), + num(7), num(5.87), num(5.91), num(0.47), num(0.57), num(0.99), num(0.83), + num(8), num(7.64), num(7.63), num(0.43), num(0.56), num(1.00), num(0.76), + num(9), num(11.39), num(11.26), num(0.39), num(0.58), num(1.01), num(0.67), + num(10), num(24.24), num(21.36), num(0.33), num(0.46), num(1.13), num(0.73), + + table.cell(colspan: 7, inset: 3pt)[], + table.hline(), + )}, + caption: [DEX size and Finishing Rate (FR) per decile], +) + +We compared the finishing rate of malware and goodware applications for evaluated tools. +Because, the size of applications impacts this finishing rate, it is interesting to compare the success rate for each decile of bytecode size. +@tab:rasta-sizes-decile reports the bytecode size and the finishing rate of goodware and malware in each decile of size. +We also computed the ratio of the bytecode size and finishing rate for the two populations. +We observe that the ratio for the finishing rate decreases from 1.04 to 0.73, while the ratio of the bytecode size is around 1. +We conclude from this table that analyzing malware triggers less errors than for goodware. + + +#highlight()[ +*RQ3 answer:* +Analyzing malware applications triggers less errors for static analysis tools than analyzing goodware for comparable bytecode size. +] diff --git a/papers/3_rasta/4_discussion.typ b/papers/3_rasta/4_discussion.typ new file mode 100644 index 0000000..42af10e --- /dev/null +++ b/papers/3_rasta/4_discussion.typ @@ -0,0 +1,440 @@ +#import "../lib.typ": todo, etal, paragraph +#import "X_var.typ": * +#import "X_lib.typ": * + +== Discussion + +=== State-of-the-art comparison + +Our finding are consistent with the numerical results of Pauck #etal that showed that #mypercent(106, 180) of DIALDroid-Bench@bosuCollusiveDataLeak2017 real-world applications are analyzed successfully with the 6 evaluated tools@pauckAndroidTaintAnalysis2018. +Six years after the release of DIALDroid-Bench, we obtain a lower ratio of #mypercent(40.05, 100) for the same set of 6 tools but using the Rasta dataset of #NBTOTALSTRING applications. +We extended this result to a set of #nbtoolsvariationsrun tools and obtained a global success rate of #resultratio. We confirmed that most tools require a significant amount of work to get them running@reaves_droid_2016. +// Our investigations of crashes also confirmed that dependencies to older versions of Apktool are impacting the performances of Anadroid, Saaf and Wognsen #etal in addition to DroidSafe and IccTa, already identified by Pauck #etal. + +Investigating the reason behind tools' errors is a difficult task and will be investigated in a future work. +For now, our manual investigations show that the nature of errors varies from one analysis to another, without any easy solution for the end user for fixing it. + +=== Recommendations + +Finally, we summarize some takeaways that developers should follow to improve the success of reusing their developed software. + +For improving the reliability of their software, developers should use classical development best practices, for example continuous integration, testing, code review. +For improving the reusability developers should write a documentation about the tool usage and provide a minimal working example and describe the expected results. +Interactions with the running environment should be minimized, for example by using a docker container, a virtual environment or even a virtual machine. +Additionally, a small dataset should be provided for a more extensive test campaign and the publishing of the expected result on this dataset would ensure to be able to evaluate the reproducibility of experiments. + +Finally, an important remark concerns the libraries used by a tool. +We have seen two types of libraries: +- internal libraries manipulating internal data of the tool; +- external libraries that are used to manipulate the input data (APKs, bytecode, resources). +We observed by our manual investigations that external libraries are the ones leading to crashes because of variations in recent APKs (file format, unknown bytecode instructions, multi-DEX files). +We believe that the developer should provide enough documentation to make possible a later upgrade of these external libraries. +//: for example, old versions of apktool are the top most libraries raising errors. + +=== Threats to validity + + +Our application dataset is biased in favor of Androguard, because Androzoo have already used Androguard internally when collecting applications and discarded any application that cannot be processed with this tool. + +Despite our best efforts, it is possible that we made mistakes when building or using the tools. +It is also possible that we wrongly classified a result as a failure. +To mitigate this possible problem we contacted the authors of the tools to confirm that we used the right parameters and chose a valid failure criterion. +// Before running the final experiment, we also ran the tools on a subset of our dataset and looked manually the most common errors to ensure that they are not trivial errors that can be solved. + +The timeout value, amount of memory are arbitrarily fixed. +For mitigating their effect, a small extract of our dataset has been analyzed with more memory/time for measuring any difference. + +Finally, the use of VirusTotal for determining if an application is a malware or not may be wrong. +For limiting this impact, we used a threshold of at most 5 antiviruses (resp. no more than 0) reporting an application as being a malware (resp. goodware) for taking a decision about maliciousness (resp. benignness). +/* +== Discussion + +#figure({ + show table: set text(size: 0.50em) + show table.cell.where(y: 0): it => if it.x == 0 { it } else { rotate(-90deg, reflow: true, it) } + show table.cell.where(x: 0): it => text(size: 1.2em, it) + show "sigma": $sigma$ + let time_num(n) = num(calc.round(float(n), digits: 0)) + table( + columns: (auto, auto, ..for i in range(20) { (1fr,) }), + //inset: (x: 0% + 5pt, y: 0% + 2pt), + stroke: none, + align: center+horizon, + table.header( + [*Exit status*], [], + [adagio], [amandroid], [anadroid], [androguard], + [androguard_dad], [apparecium], [blueseal], [dialdroid], + [didfail], [droidsafe], [flowdroid], [gator], [ic3], + [ic3_fork], [iccta], [mallodroid], [perfchecker], + [redexer], [saaf], [wognsen_et_al], + ), + ..for i in range(2, 22) { + (table.vline(x: i, end: 3), + table.vline(x: i, start: 4)) + }, + + table.cell(colspan: 22, inset: 3pt)[], + table.hline(), + table.cell(colspan: 22)[*Average number of errors (and standard deviation)*], + table.hline(), + table.cell(colspan: 22, inset: 3pt)[], + + ..rasta_avg_nb_error_by_exec + .map(e => { + let row = ([#e.type], + num(e.adagio), num(e.amandroid), num(e.anadroid), num(e.androguard), + num(e.androguarddad), num(e.apparecium), num(e.blueseal), num(e.dialdroid), + num(e.didfail), num(e.droidsafe), num(e.flowdroid), num(e.gator), num(e.ic), + num(e.icfork), num(e.iccta), num(e.mallodroid), num(e.perfchecker), + num(e.redexer), num(e.saaf), num(e.wognsenetal) + ) + if e.first != "" { row.insert(0, table.cell(rowspan:2)[*#e.first*]) } + row + }).flatten(), + + table.cell(colspan: 22, inset: 3pt)[], + table.hline(), + table.cell(colspan: 22)[*Average time (s)*], + table.hline(), + table.cell(colspan: 22, inset: 3pt)[], + + ..rasta_avg_time + .map(e => { + let row = ([*#e.first*], + time_num(e.adagio), time_num(e.amandroid), time_num(e.anadroid), time_num(e.androguard), + time_num(e.androguarddad), time_num(e.apparecium), time_num(e.blueseal), time_num(e.dialdroid), + time_num(e.didfail), time_num(e.droidsafe), time_num(e.flowdroid), time_num(e.gator), time_num(e.ic), + time_num(e.icfork), time_num(e.iccta), time_num(e.mallodroid), time_num(e.perfchecker), + time_num(e.redexer), time_num(e.saaf), time_num(e.wognsenetal) + ) + if e.type != "" { row.insert(1, table.cell(rowspan:3)[*#e.type*]) } + row + }).flatten(), + + table.cell(colspan: 22, inset: 3pt)[], + table.hline(), + table.cell(colspan: 22)[*Average Memory (GB)*], + table.hline(), + table.cell(colspan: 22, inset: 3pt)[], + + ..rasta_avg_mem + .map(e => { + let row = ([*#e.first*], + num(e.adagio), num(e.amandroid), num(e.anadroid), num(e.androguard), + num(e.androguarddad), num(e.apparecium), num(e.blueseal), num(e.dialdroid), + num(e.didfail), num(e.droidsafe), num(e.flowdroid), num(e.gator), num(e.ic), + num(e.icfork), num(e.iccta), num(e.mallodroid), num(e.perfchecker), + num(e.redexer), num(e.saaf), num(e.wognsenetal) + ) + if e.type != "" { row.insert(1, table.cell(rowspan:3)[*#e.type*]) } + row + }).flatten(), + + table.cell(colspan: 22, inset: 3pt)[], + table.hline(), + ) + [ + ]}, + caption: [Average number of errors, analysis time, memory per unitary analysis -- compared by exit status], +) + + + + +In this section, we investigate the reasons behind the high ratio of failures presented in @sec:rasta-xp. +@tab:rasta-avgerror reports the average number of errors, the average time and memory consumption of the analysis of one APK file. +We also compare our conclusions to the ones of the literature. + +=== Failures Analysis + +/* +capture erreurs +fichiers +stdout, stderr +(only 4%) +android.jar en version 9 qui génère des erreurs +*/ + +During the running of our experiments we parse the standard output and error to capture: + +- Java errors and stack traces +- Python errors and stack traces +- Ruby errors and stack traces +- Log4j messages with a "ERROR" or "FATAL" level +- XSB error messages +- Ocaml errors + +For example, Dialdroid reports in average #num(55.9) errors for one successful analysis. +On the contrary, some tools such as Blueseal report very few error at a time, making it easier to identify the cause of the failure. + +Because some tools send back a high number of errors in our logs (up to #num(46698) for one execution), we tried to determine the error that is linked to the failed status. +Unfortunately, our manual investigations confirmed that the last error of a log output is not always the one that should be attributed to the global failure of the analysis. +The error that seems to generate the failure can occur in the middle of the execution, be caught by the code and then other subsequent parts of the code may generate new errors as consequences of the first one. +Similarly, the first error of a log is not always the cause of a failure. +Sometimes errors successfully caught and handled are logged anyway. +Thus, it is impossible to extract accurately the error responsible for a failed execution. +Therefore, we investigated the nature of errors globally, without distinction between error messages in a log. + +#todo()[alt text for rasta-heatmap] + +#figure( + image( + "figs/repartition-of-error-types-among-tools.svg", + width: 80%, + alt: "", + ), + caption: [Heatmap of the ratio of errors reasons for all tools for the Rasta dataset], +) + +@fig:rasta-heatmap draws the most frequent error objects for each of the tools. +A black square is an error type that represents more than 80% of the errors raised by the considered tool.In between, gray squares show a ratio between 20% and 80% of the reported errors. + +First, the heatmap helps us to confirm that our experiments is running in adequate conditions. +Regarding errors linked to memory, two errors should be investigated: `OutOfMemoryError` and `StackOverflowError`. +The first one only appears for gator with a low ratio. +Several tool have a low ratio of errors concerning the stack. +These results confirm that the allocated heap and stack is sufficient for running the tools with the Rasta dataset. +Regarding errors linked to the disk space, we observe few ratios for the exception `IOException`, `FileNotFoundError` and `FileNotFoundException`. +Manual inspections revealed that those errors are often a consequence of a failed apktool execution. + +Second, the black squares indicate frequent errors that need to be investigated separately. +In the rest of this section, we manually analyzed, when possible, the code that generates this high ratio of errors and we give feedback about the possible causes and difficulties to write a bug fix. + +/* +Dialdroid: TODO + com.google.common.util.concurrent.ExecutionError -> memory error: java.lang.StackOverflowError, java.lang.OutOfMemoryError: Java heap space, java.lang.OutOfMemoryError: GC overhead limit exceeded +%% java.lang.RuntimeException: 'No call graph present in Scene. Maybe you want Whole Program mode (-w).', 'There were exceptions during IFDS analysis. Exiting.' 'Could not find method' + + +Didfail: DONE ? + java.lan.RuntimeException: "Could not find method" (1603), "not found: java.io.Serializable" (1362) ?, mostly originate from somewhere in soot + null pointer: mostly originate from somewhere in soot + File not found: error raised after a previous tool failed + +Gator: DONE + java.lang.RuntimeException: 'error: expected 1 element for annotation Deprecated. Got 1 instead.' (106 occ), misuse of `soot.dexpler.DexAnnotation.addAnnotation` ? as usual, buried under long list of call to soot, hard to pinpoint the cause. + java.lang.OutOfMemoryError: + java.io.IOException: No space left on device (169 occurences) + brut.androlib.AndrolibException: 198, various apktool, some ppb linked to java.io.IOException No space left on device + FileNotFoundError: ppb consequence of java.io.IOException: No such file or directory: '/tmp/gator-zxkd65ty/apktool.yml + +perfchecker: Done + java.lang.VerifyError: "Expecting a stackmap frame at branch target ", internet propose that it could be caused by Dexguard obfuscation + link error: probably problems with android.jar? + +redexer: + "File "src/ext/logging.ml", line 712, characters 12-17: Pattern matching failed": suspicious pattern matching but I don't know caml enough to debug. + +saaf: DONE + brut.androlib.AndrolibException: apktoool 1.5.2, "Could not decode arsc file" + de.rub.syssec.saaf.model.analysis.AnalysisException: encapsulate the apktool error + java.io.IOException: 'Expected: 0x001c0001, got: 0x00000000', still apktool + 38635 failures over the total of 38710 failures raise a 'brut.androlib.AndrolibException' apktool error. + +wognsen_et_al: + brut.androlib.AndrolibException: apktool 1.5.2, "Could not decode arsc file" + java.io.IOException: "Expected: 0x001c0001, got: 0x00000000|38598", apktool + java.lang.ArithmeticException: divide by zero, from apktool 'org.jf.dexlib.Code.Format.ArrayDataPseudoInstruction.getElementCount' + +Amandroid: TODO + mainly java.lang.NullPointerException at org.argus.jawa.flow.pta.rfa.ReachingFactsAnalysis.process, line 68, don't speak scala well enought to understand what is null + +Anadroid: DONE + subprocess.calledProcessError: subprocess.check_call([APK_TOOL, \"d\" , \"-f\", \"--no-src\", apk_fp, prj_d]) + java.io.IOException: somewhere in brut.androlib.res.decoder.ARSCDecoder.decode + brut.androlib.AndrolibException: raise by brut.androlib.res.decoder.ARSCDecoder.decode, somewhere in brut.apktool.Main.main + + main error msg for brut.androlib.AndrolibException is "Could not decode arsc file" + + Apktool v1.4.3, released December 8, 2011: two months after the parution of sdk 15 + min_sdk 9 to 13 ~50% of exec failled with "Could not decode arsc file", min_sdk 14 81%, 15 94%, >15 >=98%. + + SELECT min_sdk, COUNT(*)*100/(SELECT COUNT(*) FROM apk AS apk2 WHERE apk2.min_sdk = apk.min_sdk) FROM error INNER JOIN apk ON error.sha256 = apk.sha256 WHERE tool_name = 'anadroid' AND msg='Could not decode arsc file' GROUP BY min_sdk ORDER BY min_sdk; + SELECT min_sdk, COUNT(*)*100/(SELECT COUNT(*) FROM apk AS apk2 WHERE apk2.min_sdk = apk.min_sdk) FROM exec INNER JOIN apk ON exec.sha256 = apk.sha256 WHERE tool_name = 'anadroid' AND tool_status = 'FAILED' GROUP BY min_sdk ORDER BY min_sdk; + SELECT AVG(cnt), MAX(cnt) FROM (SELECT COUNT(*) AS cnt FROM error WHERE tool_name = 'anadroid' AND msg='Could not decode arsc file' GROUP BY sha256); +*/ + +#paragraph[Androguard and Androguard_dad])[ +Surprisingly, while Androguard almost never fails to analyze an APK, the internal decompiler of Androguard (DAD) fails more than half of the time. +The analysis of the logs shows that the issue comes from the way the decompiled methods are stored: each method is stored in a file named after the method name and signature, and this file name can quickly exceed the size limit (255 characters on most file systems). +It should be noticed that Androguard_dad rarely fails on the Drebin dataset. +This illustrate the importance to test tools on real and up-to-date APKs: even a bad handling of filenames can influence an analysis. +] + +/* +Androguard: Done + 35 error total, no real pattern, stuff like unexpected ID, uncrowned instructions, ect + +Androguard Dad: DONE + All 33819 OSError are '[Errno 36] File name too long: ': the tool try to create files with the name AND SIGNATURE of the disassembled methods, by the file name can be too long: + '/mnt/out/in/android/vyapar/paymentgateway/model/PaymentGatewayResponseModel$Data$AccountDetails/PaymentGatewayResponseModel$Data$AccountDetails copy$default (PaymentGatewayResponseModel$Data$AccountDetails String String String String String String String String String String String String String String List I Object)PaymentGatewayResponseModel$Data$AccountDetails.ag' +NullPointerException +dad: SError +*/ + +#paragraph([Mallodroid and Apparecium])[ +Mallodroid and Apparecium stand out as the tools that raised the most errors in one run. +They can raise more than #num(10000) error by analysis. +However, it happened only for a few dozen of APKs, and conspicuously, the same APKs raised the same hight number of errors for both tools. +The recurring error is a `KeyError` raise by Androguard when trying to find a string by its identifier. +Although this error is logged, it seems successfully handled and during a manual analysis of the execution, both tools seemingly perform there analysis without issue. +This hight number of occurrences may suggest that the output is not valid. +Still, the tools claim to return a result, so, from our perspective, we consider those analysis as successful. +For other numerous errors, we could not identify the reason why those specific applications raise so many exceptions. +However we noticed that Mallodroid and Apparecium use outdated version of Androguard (respectively the version 3.0 and 2.0), and neither Androguard v3.3.5 nor DAD with Androguard v3.3.5 raise those exceptions. +This suggest the issue has been fixed by Androguard and that Mallodroid and Apparecium could benefit from a dependency upgrade. +] + +/* +Apparecium: DONE + The KeyError is raised from androguard when a non existing string is queried. It happens for only a few apks (~60), + but a lot of times. UnicodeEncodeError happened more frequently (2740 apks), also originate from androguard. + androguard version 2.0 + +mallodroid: Done + KeyError: from androguard `get_raw_string`, but do not lead to crash, 33 crash from androguard parsing xml. (androguard 3.0) +Instruction10x% +*/ + +#paragraph([Blueseal])[ +Because Blueseal rarely log more than one error when crashing, it is easy to identify the relevant error. +The majority of crashes comes from unsupported Android versions (due to the magic number of the DEX files not being supported by the version of back smali used by Blueseal) and methods whose implementation are not found (like native methods). +] + +/* +Blueseal: Done + Majority of runtimes error: 'No method source set for method ' are raised from soot.SceneTransformer.transform() called by edu.buffalo.cse.blueseal.BSFlow.CgTransformer.getDynamicEntryPoints(). + No idea how to fix. Update soot? version unclear ('trunk'...), but copyright up to 2010 so 2010? +*/ + +#paragraph([Droidsafe and SAAF])[ +Our investigation of the most common errors raised by Droidsafe and SAAF showed that they are often preceded by an error from apktool. +Indeed, #num(28654) runs of Droidsafe and #num(38635) runs of SAAF failed after raising at least one of `brut.androlib.AndrolibException` or `brut.androlib.err.UndefinedResObject`, suggesting that those tools would benefit from an upgrade of apktool. +] + +/* +Droidsafe: + UnknownHostException: 'normal', due to network isolation(?), from sfl4j, no impact on the reste of the tool + droidsafe.utils.CannotFindMethodException: 'Cannot find or resolve ' (eg: android.view.ViewTreeObserver: void removeOnGlobalLayoutListener), + mostly related to android API. First guest 'normal' as droidsafe model the android API and is not updated since ~SDK 19, but the error is replaced by an + apktool error for min sdk > 19.: 2.0.0rc2 + eg: android.view.ViewTreeObserver.removeOnGlobalLayoutListener: exist un android.jar for sdk 18 and 18, but no in droidsafe model + the error does not look fatals (it occurred in finished execution) but is more common on failed execution. (1 to 16 ratio) + TODO: conclusion? + +28957 apk with an apktool error +CannotFindMethodException +*/ + +#paragraph([Ic3 and Ic3_fork])[ +We compared the number of errors between Ic3 and Ic3_fork. +Ic3_fork reports less errors for all types of analysis which suggests that the author of the fork have removed the outputed errors from the original code: the thrown errors are captured in a generic `RuntimeException` which removes the semantic, making it harder our investigations. +Nevertheless, Ic3_fork has more failures than Ic3: the number of errors reported by a tool is not correlated to the final success of its analysis. +] + +/* +ic3: DONE + jas.jasError: "Missing arguments for instruction ldc" or "Badly formatted number", old soot or bad dare? + 3778 / 10480 (~30) fails without error logged, probable that we don't capture dare failures. + +ic3_fork: DONE + java.lang.RuntimeException: "This operation requires resolving level SIGNATURES but is at resolving level DANGLING", and "Could not find method". Yet another case of error lost in a sea of soot + only 38 failures without error logged + +IccTa: Done + java.lang.RuntimeException: same number of "This operation requires resolving level SIGNATURES..." as ic3_fork, + lots of "No method source set for method ", half the time this occurs the exec failed (and ~30% of the time it finishes) + "Could not find method": fail every time, in edu.psu.cse.siis.ic3.SetupApplication.calculateSourcesSinksEntrypoints (and again, a lot of soot stack) +jasError +*/ + +#paragraph([Flowdroid])[ +Our exchanges with the authors of Flowdroid led us to expect more timeouts from too long executions than failed run. +#todo[Deja dit? : Surprisingly we only got #mypercent(37,NBTOTAL) of timeout, and a hight number of failures.] +We tried to detect recurring causes of failures, but the complexity of Flowdroid make the investigation difficult. +Most exceptions seems to be related to concurrency. //or display a generic messages. +Other errors that came up regularly are `java.nio.channels.ClosedChannelException` which is raised when Flowdoid fails to read from the APK, although we did not find the reason of the failure, null pointer exceptions when trying to check if a null value is in a `ConcurrentHashMap` (in `LazySummaryProvider.getClassFlows()`) and `StackOverflowError` from `StronglyConnectedComponentsFast.recurse()`. +We randomly selected 20 APKs that generated stack overflows in Flowdroid and retried the analysis with 500G of RAM allocated to the JVM. +18 of those runs still failed with a stack overflow without using all the allocated memory, the other two failed after raising null pointer exceptions from `getClassFlows`. +This shows that the lack of memory is not the primary cause of those failures. +] + +/* +Flowdroid: TODO java.nio.channels.ClosedChannelException cause or consequence? + java.nio.channels.ClosedChannelException: mosly the zip file reader that refuse an access (after another crash? hard to check) + java.lang.StackOverflowError: + java.lang.RuntimeException: mostly "There were exceptions during IFDS analysis. Exiting." + java.lang.NullPointerException: soot.jimple.infoflow.collect.ConcurrentHashSet.contains, from soot.jimple.infoflow.methodSummary.data.provider.LazySummaryProvider.getClassFlows + com.google.common.util.concurrent.ExecutionError: "java.lang.StackOverflowError" + + +No hidden timeout, what do we believe? avg(time) = 80s, 30s when finished, 137 when failed, max(time) = 3639s when failed, 3284 when finished, 72% of the failures took less than a minute, 93% less than 10, 92% of failed exception raised a NullPointerException. + +Pauck: Flowdroid avg 2m on DIALDroid-Bench (real worlds apks) +*/ + +As a conclusion, we observe that a lot of errors can be linked to bugs in dependencies. +Our attempts to upgrade those dependencies led to new errors appearing: we conclude that this is a no trivial task that require familiarity with the inner code of the tools. + +=== State of the art comparison + +Luo #etal released TaintBench@luoTaintBenchAutomaticRealworld2022 a real-world benchmark and the associated recommendations to build such a benchmark. +These benchmarks confirmed that some tools such as Amandroid and Flowdroid are less efficient on real-world applications. +// Pauck #etal@pauckAndroidTaintAnalysis2018 +// Reaves #etal@reaves_droid_2016 + +We finally compare our results to the conclusions and discussions of previous papers@luoTaintBenchAutomaticRealworld2022 @pauckAndroidTaintAnalysis2018 @reaves_droid_2016. +First we confirm the hypothesis of Luo #etal that real-world applications lead to less efficient analysis than using hand crafted test applications or old datasets@luoTaintBenchAutomaticRealworld2022. +Even if Drebin is not hand-crafted, it is quite old and we obtained really good results compared to the Rasta dataset. +When considering real-world applications, the size is rather different from hand crafted application, which impacts the success rate. +We believe that it is explained by the fact that the complexity of the code increases with its size. + +/* +30*6 +180 +21+20+27+2+18+18 +106 +106/180*100 +58.88 +*/ + +Second, our finding are consistent with the numerical results of Pauck #etal that showed that #mypercent(106, 180) of DIALDroid-Bench 30 real-world applications are analyzed successfully with the 6 evaluated tools@pauckAndroidTaintAnalysis2018. +Six years after the release of DIALDroid-Bench, we obtain a lower ratio of #mypercent(40.05, 100) for the same set of 6 tools but using the Rasta dataset of #NBTOTALSTRING applications. +We extended this result to our set of #nbtoolsvariationsrun tools and obtained a global success rate of #resultratio. +Our investigations of crashes also confirmed that dependencies to older versions of Apktool are impacting the performances of Anadroid, Saaf and Wognsen #etal in addition to DroidSafe and IccTa, already identified by Pauck #etal. + +/* +Pauck: 235 micro bench, 30 real* +Confirm didfail failled for min_sdk >= 19, all successful run (only 4%) indicated "Only phantom classes loaded, skipping analysis..." + +SELECT tool_status, COUNT(*), AVG(dex_size) FROM exec INNER JOIN apk on exec.sha256 = apk.sha256 WHERE min_sdk >= 19 AND tool_name = 'didfail' GROUP BY tool_status; +FAILED|16651|13139071.2363221 +FINISHED|694|6617861.33717579 +TIMEOUT|98|6048999.2244898 +SELECT msg, COUNT(*) FROM (SELECT DISTINCT exec.sha256, msg FROM exec INNER JOIN apk on exec.sha256 = apk.sha256 INNER JOIN error ON exec.sha256 = error.sha256 AND exec.tool_name = error.tool_name WHERE min_sdk >= 19 AND exec.tool_name = 'didfail' AND exec.tool_status = 'FINISHED') GROUP BY msg; +|77 +Only phantom classes loaded, skipping analysis...|694 + +DroidSafe and IccTa Failled for SDK > 19 because of old apktool + +We obsered: (nb success < 2000 for min_skd >= 20) + ['anadroid', 'blueseal', 'dialdroid', 'didfail', 'droidsafe', 'ic3_fork', 'iccta', 'perfchecker', 'saaf', 'wognsen_et_al'] +anadroid|0 +blueseal|521 +dialdroid|812 +didfail|343 +droidsafe|35 +ic3_fork|1393 +iccta|612 +perfchecker|1921 +saaf|1588 +wognsen_et_al|386 +*/ + +Third, we extended to #nbtoolsselected different tools the work done by Reaves #etal on the usability of analysis tools (4 tools are in common, we added 16 new tools and two variations). +We confirmed that most tools require a significant amount of work to get them running. +We encounter similar issues with libraries and operating system incompatibilities, and noticed that, with time, dependencies issues may impact the build process. +For instance we encountered cases where the repository hosting the dependencies were closed, or cases where maven failed to download dependencies because the OS version did not support SSL, now mandatory to access maven central. +//, and even one case were the could not find anywhere the compiled version of sbt used to build a tool. +*/ + diff --git a/papers/3_rasta/5_conclusion.typ b/papers/3_rasta/5_conclusion.typ new file mode 100644 index 0000000..c797b60 --- /dev/null +++ b/papers/3_rasta/5_conclusion.typ @@ -0,0 +1,14 @@ +#import "@local/template-thesis-matisse:0.0.1": etal +#import "X_var.typ": * + +== Conclusion + +This paper has assessed the suggested results of the literature@luoTaintBenchAutomaticRealworld2022 @pauckAndroidTaintAnalysis2018 @reaves_droid_2016 about the reliability of static analysis tools for Android applications. +With a dataset of #NBTOTALSTRING applications we established that #resultunusable of #nbtoolsselectedvariations tools are not reusable, when considering that a tool that has more than 50% of time a failure is unusable. +In total, the analysis success rate of the tools that we could run for the entire dataset is #resultratio. +The characteristics that have the most influence on the success rate is the bytecode size and min SDK version. Finally, we showed that malware APKs have a better finishing rate than goodware. + +In future works, we plan to investigate deeper the reported errors of the tools in order to analyze the most common types of errors, in particular for Java based tools. +We also plan to extend this work with a selection of more recent tools performing static analysis. + +Following Reaves #etal recommendations@reaves_droid_2016, we publish the Docker and Singularity images we built to run our experiments alongside the Docker files. This will allow the research community to use directly the tools without the build and installation penalty. diff --git a/papers/3_rasta/X_lib.typ b/papers/3_rasta/X_lib.typ new file mode 100644 index 0000000..8796d3a --- /dev/null +++ b/papers/3_rasta/X_lib.typ @@ -0,0 +1,22 @@ +#let ok = text(fill: olive, sym.checkmark) +#let okk = text(fill: olive, tracking: -5pt, sym.checkmark+sym.checkmark) + +#let bad = text(fill: orange, sym.circle.stroked.small) +#let ko = text(fill: maroon, sym.crossmark) +#let nr = sym.dash.en + +#let str2sym(s) = { + if s == "ok" { + ok + } else if s == "okk" { + okk + } else if s == "bad" { + bad + } else if s == "ko" { + ko + } else if s == "nr" { + nr + } else { + s + } +} diff --git a/papers/3_rasta/X_var.typ b/papers/3_rasta/X_var.typ new file mode 100644 index 0000000..c863929 --- /dev/null +++ b/papers/3_rasta/X_var.typ @@ -0,0 +1,37 @@ +#import "../lib.typ": num, mypercent + +#let NBTOTAL = 62525 +#let NBTOTALSTRING = num(NBTOTAL) + +#let nbtools = 26 +#let nbtoolsselected = 20 +#let nbtoolsselectedvariations = 22 +#let nbtoolsvariationsrun = 20 +#let resultunusablenb = 12 //\xspace +#let resultunusable = mypercent(resultunusablenb, nbtoolsselectedvariations) // \xspace +#let resultratio = mypercent(54.9, 100) // \xspace +#let ramlimit = [64 GB] //\xspace + +#let rasta_tool_data = csv( + "data/data-final.csv", + delimiter: ";", + row-type: dictionary, +) + +#let rasta_avg_nb_error_by_exec = csv( + "data/average_number_of_error_by_exec.csv", + delimiter: ",", + row-type: dictionary, +) + +#let rasta_avg_time = csv( + "data/average_time-final.csv", + delimiter: ",", + row-type: dictionary, +) + +#let rasta_avg_mem = csv( + "data/average_mem-final.csv", + delimiter: ",", + row-type: dictionary, +) diff --git a/papers/3_rasta/data/average_mem-final.csv b/papers/3_rasta/data/average_mem-final.csv new file mode 100644 index 0000000..69705b1 --- /dev/null +++ b/papers/3_rasta/data/average_mem-final.csv @@ -0,0 +1,4 @@ +first,type,adagio,amandroid,anadroid,androguard,androguarddad,apparecium,blueseal,dialdroid,didfail,droidsafe,flowdroid,gator,ic,icfork,iccta,mallodroid,perfchecker,redexer,saaf,wognsenetal +FINISHED,memory,0.6,4.5,12.8,0.6,0.3,1.3,2.7,15.9,17.6,9.9,2,2,15.3,5,5,0,0,1,3,3 +FAILED,,0.3,4.9,2.8,0.4,1,0.6,1.7,3.9,68.3,14.8,5,41.5,130.9,5,12,0,1,1,1,1 +TIMEOUT,,0,19,82.6,0,68.1,2.1,15.4,37.2,99.8,0.2,20.2,1.1,81.1,20,2,0,1,0,9,0 diff --git a/papers/3_rasta/data/average_number_of_error_by_exec.csv b/papers/3_rasta/data/average_number_of_error_by_exec.csv new file mode 100644 index 0000000..0c14393 --- /dev/null +++ b/papers/3_rasta/data/average_number_of_error_by_exec.csv @@ -0,0 +1,7 @@ +first,type,adagio,amandroid,anadroid,androguard,androguarddad,apparecium,blueseal,dialdroid,didfail,droidsafe,flowdroid,gator,ic,icfork,iccta,mallodroid,perfchecker,redexer,saaf,wognsenetal +FINISHED,errors,0.0,0.9,0.02,0.0,0.0,3.33,0.0,55.88,1.13,7.17,1.04,0.0,1.22,0.32,14.3,4.37,0.28,1.29,0.22,2.13 +,sigma,0.0,3.23,0.19,0.0,0.0,261.92,0.05,63.73,3.94,37.87,26.32,0.04,23.1,2.73,71.74,277.0,1.77,1.28,0.83,66.5 +FAILED,errors,0.0,2.79,2.34,1.35,1.0,21.63,1.02,33.79,6.6,12.53,14.64,0.32,3.66,1.29,17.34,1.0,1.15,3.45,6.35,4.11 +,sigma,0.0,8.7,0.94,0.48,0.02,466.97,0.21,108.56,31.56,74.01,49.07,0.78,18.06,0.71,42.81,0.0,4.7,4.52,22.97,48.81 +TIMEOUT,errors,0,9.78,0.01,0,0.0,4.3,0.01,60.94,1.06,26.64,0.75,0.0,2.13,0.91,3.68,0,1.24,0,91.29,1.31 +,sigma,0.0,9.76,0.11,0.0,0.0,79.98,0.11,101.73,2.98,97.18,1.72,0.0,5.19,3.19,15.33,0.0,4.3,0.0,353.75,3.42 diff --git a/papers/3_rasta/data/average_time-final.csv b/papers/3_rasta/data/average_time-final.csv new file mode 100644 index 0000000..15656fb --- /dev/null +++ b/papers/3_rasta/data/average_time-final.csv @@ -0,0 +1,4 @@ +first,type,adagio,amandroid,anadroid,androguard,androguarddad,apparecium,blueseal,dialdroid,didfail,droidsafe,flowdroid,gator,ic,icfork,iccta,mallodroid,perfchecker,redexer,saaf,wognsenetal +FINISHED,time,17.19,405.02,149.29,15.59,26.56,97.54,158.38,767.67,270.1,676.08,29.11,33.19,156.19,158.7,90.2,27.79,4.31,16.16,56.44,696.09 +FAILED,,8.38,760.52,4.8,13.64,62.67,21.68,12.15,68.47,444.74,442.79,136.95,924.46,535.39,28.6,201.74,5.21,10.24,16.61,5.73,55.58 +TIMEOUT,,0,3600.84,3600.83,0,3603.59,3600.23,3600.73,3604.0,3600.02,3600.08,3601.18,3600.56,3601.03,3600.92,3600.38,0,3600.04,0,3602.02,3600.55 diff --git a/papers/3_rasta/data/data-final.csv b/papers/3_rasta/data/data-final.csv new file mode 100644 index 0000000..9f653f1 --- /dev/null +++ b/papers/3_rasta/data/data-final.csv @@ -0,0 +1,27 @@ +tool;citekey;binary;source;url;repo;documentation;decision;exclude;why;forkusable;authorconfirmed;lang;licences;os;origin;stars;alive;date;selected;selectedstars;selecteddate;nbaliveforks;remark;urlselected +A3E ;DBLPconfoopslaAzimN13;nr;ok;https://github.com/tanzirul/a3e;github;ok;ko;EXCLUDE;Hybrid tool (static/dynamic);ko;;;;;tanzirul/a3e;40;ko;2016-09-15;origin;40;2016-09-15;1;auto;https://github.com/tanzirul/a3e +A5 ;vidasA5AutomatedAnalysis2014;nr;ok;https://github.com/tvidas/a5;github;ko;ko;EXCLUDE;Hybrid tool (static/dynamic);ko;;;;;tvidas/a5;12;ko;2014-07-31;origin;12;2014-07-31;0;auto;https://github.com/tvidas/a5 +Adagio ;gasconStructuralDetectionAndroid2013;nr;ok;https://github.com/hgascon/adagio;github;ok;ok;;;ko;ok;Python;GPL 2.0;U20.04;hgascon/adagio;74;ok;2022-11-17;origin;74;2022-11-17;0;auto;https://github.com/hgascon/adagio +Amandroid ;weiAmandroidPreciseGeneral2014;ok;ok;https://github.com/arguslab/Argus-SAF;github;ok;ok;;;ko;ok;Scala;Apache 2.0;U22.04;arguslab/Argus-SAF;161;ko;2021-11-10;origin;161;2021-11-10;2;auto;https://github.com/arguslab/Argus-SAF +Anadroid ;liangSoundPreciseMalware2013;ko;ok;https://github.com/maggieddie/pushdownoo;github;ok;ok;;;ko;ko;Scala/Java/Python;CRAPL 2012;U22.04;maggieddie/pushdownoo;10;ko;2014-06-18;origin;10;2014-06-18;0;auto;https://github.com/maggieddie/pushdownoo +Androguard ;desnos:adnroguard:2011;nr;ok;https://github.com/androguard/androguard;github;okk;ok;;;ko;ko;Python;Apache 2.0;Python 3.11 slim;androguard/androguard;4430;ok;2023-02-01;origin;4430;2023-02-01;3;auto;https://github.com/androguard/androguard +Android-app-analysis;geneiatakisPermissionVerificationApproach2015;ko;ok;https://code.google.com/archive/p/android-app-analysis-tool/source/default/source;google;okk;ko;EXCLUDE;Hybrid tool (static/dynamic);;;;;;android-app-analysis-tool;40;ko;2014-06-25;origin;;2014-06-25;;Android-app;https://code.google.com/archive/p/android-app-analysis-tool/source/default/source +Apparecium ;titzeAppareciumRevealingData2015;ok;ok;https://github.com/askk/apparecium;github;ko;ok;;;ko;ko;Python;MIT;U22.04;askk/apparecium;0;ko;2014-11-07;origin;0;2014-11-07;1;auto;https://github.com/askk/apparecium +BlueSeal ;shenInformationFlowsPermission2014;ko;ok;https://github.com/ub-rms/blueseal;github;bad;ok;;;ko;ok;Java;No licence;U14.04;ub-rms/blueseal;0;ko;2018-07-04;origin;0;2018-07-04;0;auto;https://github.com/ub-rms/blueseal +Choi #etal ;CHOI2014620;ko;ok;https://github.com/kwanghoon/javaAnalysis;github;bad;ko;EXCLUDE;Works on source files only;ko;;;;;kwanghoon/JavaAnalysis;1;ok;2022-01-09;origin;1;2022-01-09;0;auto;https://github.com/kwanghoon/JavaAnalysis +DIALDroid ;bosuCollusiveDataLeak2017;ok;ok;https://github.com/dialdroid-android/DIALDroid;github;ok;ok;;;ko;ko;Java;GPL 3.0;U18.04;dialdroid-android/DIALDroid;16;ko;2018-04-17;origin;16;2018-04-17;1;auto;https://github.com/dialdroid-android/DIALDroid +DidFail ;klieberAndroidTaintFlow2014;ok;ok;https://bitbucket.org/wklieber/didfail/src/master/;bitbucket;bad;ok;;;;ok;Java/Python;3-Clause BSD;U12.04;lori\_flynn/didfail;4;ko;2015-06-17;origin;;2015-06-17;;DidFail;https://bitbucket.org/wklieber/didfail/src/master/ +DroidSafe ;DBLPconfndssGordonKPGNR15;ko;ok;https://github.com/MIT-PAC/droidsafe-src;github;ok;ok;;;ko;ok;Java/Python;GPL 2.0;U14.04;MIT-PAC/droidsafe-src;92;ko;2017-04-17;origin;92;2017-04-17;3;auto;https://github.com/MIT-PAC/droidsafe-src +Flowdroid ;Arzt2014a;ok;ok;https://github.com/secure-software-engineering/FlowDroid;github;okk;ok;;;ko;ok;Java;LGPL 2.1;U22.04;secure-software-engineering/FlowDroid;868;ok;2023-05-07;origin;868;2023-05-07;1;auto;https://github.com/secure-software-engineering/FlowDroid +Gator ;rountevStaticReferenceAnalysis2014,yangStaticControlFlowAnalysis2015;ko;ok;http://web.cse.ohio-state.edu/presto/software/gator/;edu;okk;ok;;;;ok;Java/Python;3-Clause BSD;U22.04;web;;;2019-09-09;origin;;2019-09-09;;Gator;http://web.cse.ohio-state.edu/presto/software/gator/ +IC3 ;octeauCompositeConstantPropagation2015;ok;ok;https://github.com/siis/ic3;github;bad;ok;;;ok;ko;Java;Apache 2.0;U12.04 / 22.04;siis/ic3;32;ko;2015-09-17;JordanSamhi/ic3;4;2022-12-06;3;auto;https://github.com/JordanSamhi/ic3 +IccTA ;liIccTADetectingInterComponent2015;ok;ok;https://github.com/lilicoding/soot-infoflow-android-iccta;github;ok;ok;;;ko;ok;Java;LGPL 2.1;U22.04;lilicoding/soot-infoflow-android-iccta;83;ko;2016-02-21;origin;83;2016-02-21;0;auto;https://github.com/lilicoding/soot-infoflow-android-iccta +Lotrack ;lillackTrackingLoadtimeConfiguration2014;ko;ok;https://github.com/MaxLillack/Lotrack;github;ko;bad;;Authors ack. a partial doc.;ko;ok;Java;Apache 2.0;?;MaxLillack/Lotrack;5;ko;2017-05-11;origin;5;2017-05-11;2;auto;https://github.com/MaxLillack/Lotrack +MalloDroid ;fahlWhyEveMallory2012;nr;ok;https://github.com/sfahl/mallodroid;github;ok;ok;;;ko;ko;Python;LGPL 3.0;U16.04;sfahl/mallodroid;64;ko;2013-12-30;origin;64;2013-12-30;10;auto;https://github.com/sfahl/mallodroid +PerfChecker ;liuCharacterizingDetectingPerformance2014;ko;ko;http://castle.cse.ust.hk/perfchecker/tool_obtain.php;request;bad;ok;;Binary obtained from authors;;ok;Java;Proprietary;U14.04;authors;;ko;--;origin;;--;;Perfchecker;??? +Poeplau #etal;DBLPconfndssPoeplauFBKV14; ko ;bad;https://github.com/sebastianpoeplau/android-whitelists;github;ko;ko;EXCLUDE;Related to Android hardening;ko;;;;;sebastianpoeplau/android-whitelists;1;ko;2014-03-14;origin;1;2014-03-14;0;auto;https://github.com/sebastianpoeplau/android-whitelists +Redexer ;jeonDrAndroidMr2012;ko;ok;https://github.com/plum-umd/redexer;github;ok;ok;;;ko;ok;Ocaml/Ruby;3-Clause BSD;U22.04;plum-umd/redexer;153;ko;2021-05-20;origin;153;2021-05-20;0;auto;https://github.com/plum-umd/redexer +SAAF ;hoffmannSlicingDroidsProgram2013;ok;ok;https://github.com/SAAF-Developers/saaf;github;ok;ok;;;ko;ok;Java;GPL 3.0;U14.04;SAAF-Developers/saaf;35;ko;2015-09-01;origin;35;2015-09-01;5;auto;https://github.com/SAAF-Developers/saaf +StaDynA ;zhauniarovichStaDynAAddressingProblem2015; ko ;ok;https://github.com/zyrikby/StaDynA;request;ok;ko;EXCLUDE;Hybrid tool (static/dynamic);;;;;;authors;;;2020-02-14;origin;;2020-02-14;;Stadyna;https://github.com/zyrikby/StaDynA +Thresher ;blackshearThresherPreciseRefutations2013;ko;ok;https://github.com/cuplv/thresher;github;ok;bad;;Not built with author’s help;ko;ok;Java;Apache 2.0;U14.04;cuplv/thresher;31;ko;2014-10-25;origin;31;2014-10-25;1;auto;https://github.com/cuplv/thresher +Wognsen #etal;wognsenFormalisationAnalysisDalvik2014;nr;ok;https://bitbucket.org/erw/dalvik-bytecode-analysis-tool/src/master/;bitbucket;ko;ok;;;ko;ko;Python/Prolog;No licence;U22.04;erw/dalvik-bytecode-analysis-tool;;;2022-06-27;origin;;2022-06-27;;Wognsen;??? diff --git a/papers/3_rasta/figs/decorelation/finishing-rate-of-java-based-tool-by-bytecode-size-of-apks-detected-in-2022.svg b/papers/3_rasta/figs/decorelation/finishing-rate-of-java-based-tool-by-bytecode-size-of-apks-detected-in-2022.svg new file mode 100644 index 0000000..4aa388e --- /dev/null +++ b/papers/3_rasta/figs/decorelation/finishing-rate-of-java-based-tool-by-bytecode-size-of-apks-detected-in-2022.svg @@ -0,0 +1,774 @@ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + diff --git a/papers/3_rasta/figs/decorelation/finishing-rate-of-java-based-tool-by-discovery-year-of-apks-with-a-bytecode-size-between-4-08-mb-and-5-2-mb.svg b/papers/3_rasta/figs/decorelation/finishing-rate-of-java-based-tool-by-discovery-year-of-apks-with-a-bytecode-size-between-4-08-mb-and-5-2-mb.svg new file mode 100644 index 0000000..18625a9 --- /dev/null +++ b/papers/3_rasta/figs/decorelation/finishing-rate-of-java-based-tool-by-discovery-year-of-apks-with-a-bytecode-size-between-4-08-mb-and-5-2-mb.svg @@ -0,0 +1,782 @@ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + diff --git a/papers/3_rasta/figs/decorelation/finishing-rate-of-java-based-tool-by-min-sdk-of-apks-with-a-bytecode-size-between-4-08-mb-and-5-2-mb.svg b/papers/3_rasta/figs/decorelation/finishing-rate-of-java-based-tool-by-min-sdk-of-apks-with-a-bytecode-size-between-4-08-mb-and-5-2-mb.svg new file mode 100644 index 0000000..b1d09a1 --- /dev/null +++ b/papers/3_rasta/figs/decorelation/finishing-rate-of-java-based-tool-by-min-sdk-of-apks-with-a-bytecode-size-between-4-08-mb-and-5-2-mb.svg @@ -0,0 +1,1087 @@ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + diff --git a/papers/3_rasta/figs/decorelation/finishing-rate-of-non-java-based-tool-by-bytecode-size-of-apks-detected-in-2022.svg b/papers/3_rasta/figs/decorelation/finishing-rate-of-non-java-based-tool-by-bytecode-size-of-apks-detected-in-2022.svg new file mode 100644 index 0000000..89998d4 --- /dev/null +++ b/papers/3_rasta/figs/decorelation/finishing-rate-of-non-java-based-tool-by-bytecode-size-of-apks-detected-in-2022.svg @@ -0,0 +1,616 @@ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + diff --git a/papers/3_rasta/figs/decorelation/finishing-rate-of-non-java-based-tool-by-discovery-year-of-apks-with-a-bytecode-size-between-4-08-mb-and-5-2-mb.svg b/papers/3_rasta/figs/decorelation/finishing-rate-of-non-java-based-tool-by-discovery-year-of-apks-with-a-bytecode-size-between-4-08-mb-and-5-2-mb.svg new file mode 100644 index 0000000..4aef518 --- /dev/null +++ b/papers/3_rasta/figs/decorelation/finishing-rate-of-non-java-based-tool-by-discovery-year-of-apks-with-a-bytecode-size-between-4-08-mb-and-5-2-mb.svg @@ -0,0 +1,574 @@ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + diff --git a/papers/3_rasta/figs/decorelation/finishing-rate-of-non-java-based-tool-by-min-sdk-of-apks-with-a-bytecode-size-between-4-08-mb-and-5-2-mb.svg b/papers/3_rasta/figs/decorelation/finishing-rate-of-non-java-based-tool-by-min-sdk-of-apks-with-a-bytecode-size-between-4-08-mb-and-5-2-mb.svg new file mode 100644 index 0000000..b110510 --- /dev/null +++ b/papers/3_rasta/figs/decorelation/finishing-rate-of-non-java-based-tool-by-min-sdk-of-apks-with-a-bytecode-size-between-4-08-mb-and-5-2-mb.svg @@ -0,0 +1,872 @@ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + diff --git a/papers/3_rasta/figs/exit-status-for-the-drebin-dataset.svg b/papers/3_rasta/figs/exit-status-for-the-drebin-dataset.svg new file mode 100644 index 0000000..fb4ab19 --- /dev/null +++ b/papers/3_rasta/figs/exit-status-for-the-drebin-dataset.svg @@ -0,0 +1,2111 @@ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + diff --git a/papers/3_rasta/figs/exit-status-for-the-rasta-dataset-goodware-malware.svg b/papers/3_rasta/figs/exit-status-for-the-rasta-dataset-goodware-malware.svg new file mode 100644 index 0000000..94828b8 --- /dev/null +++ b/papers/3_rasta/figs/exit-status-for-the-rasta-dataset-goodware-malware.svg @@ -0,0 +1,3582 @@ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + diff --git a/papers/3_rasta/figs/exit-status-for-the-rasta-dataset.svg b/papers/3_rasta/figs/exit-status-for-the-rasta-dataset.svg new file mode 100644 index 0000000..7684e8d --- /dev/null +++ b/papers/3_rasta/figs/exit-status-for-the-rasta-dataset.svg @@ -0,0 +1,2140 @@ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + diff --git a/papers/3_rasta/figs/finishing-rate-by-year-of-java-based-tools.svg b/papers/3_rasta/figs/finishing-rate-by-year-of-java-based-tools.svg new file mode 100644 index 0000000..c192b18 --- /dev/null +++ b/papers/3_rasta/figs/finishing-rate-by-year-of-java-based-tools.svg @@ -0,0 +1,1005 @@ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + diff --git a/papers/3_rasta/figs/finishing-rate-by-year-of-non-java-based-tools.svg b/papers/3_rasta/figs/finishing-rate-by-year-of-non-java-based-tools.svg new file mode 100644 index 0000000..094319c --- /dev/null +++ b/papers/3_rasta/figs/finishing-rate-by-year-of-non-java-based-tools.svg @@ -0,0 +1,678 @@ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + diff --git a/papers/3_rasta/figs/repartition-of-error-types-among-tools.svg b/papers/3_rasta/figs/repartition-of-error-types-among-tools.svg new file mode 100644 index 0000000..0c0c699 --- /dev/null +++ b/papers/3_rasta/figs/repartition-of-error-types-among-tools.svg @@ -0,0 +1,2092 @@ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + diff --git a/papers/3_rasta/figs/running.svg b/papers/3_rasta/figs/running.svg new file mode 100644 index 0000000..bb977fc --- /dev/null +++ b/papers/3_rasta/figs/running.svg @@ -0,0 +1,225 @@ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + diff --git a/papers/3_rasta/main.typ b/papers/3_rasta/main.typ new file mode 100644 index 0000000..d6a91ba --- /dev/null +++ b/papers/3_rasta/main.typ @@ -0,0 +1,12 @@ +#import "../lib.typ": todo + += RASTA + +#todo[Bring back element from previous version of rasta] + +#include("0_intro.typ") +#include("1_related_work.typ") +#include("2_methodology.typ") +#include("3_experiments.typ") +#include("4_discussion.typ") +#include("5_conclusion.typ") diff --git a/papers/4_class_loader/0_intro.typ b/papers/4_class_loader/0_intro.typ new file mode 100644 index 0000000..e807463 --- /dev/null +++ b/papers/4_class_loader/0_intro.typ @@ -0,0 +1,64 @@ +#import "../lib.typ": etal, ie +#import "X_var.typ": * + +== Introduction + +/* +When building an application with Android Studio, the source codes of applications are compiled to Java bytecode, which is then converted to Dalvik bytecode. +Dalvik bytecode is then put in a zip archive with other resources such as the application manifest, and the zip archive is then signed. +All this process is handled by Android Studio, behind the scene. +At runtime, the Dalvik bytecode is either interpreted by the Dalvik virtual machine or compiled by ART in order to execute native code and it is up to these components to handle the loading of the classes. +Both behaviors are possible at the same time for a single application, and it is up to Android to choose which part of an application is compiled in native code. +*/ + +Android applications are distributed using markets of applications. +The market maintainers have the difficult task to discover suspicious applications and delete them if they are effectively malicious applications. +For such a task, some automated analysis is performed, but sometimes, a manual investigation is required. +A reverser is in charge of studying the application: they usually perform a static analysis and a dynamic analysis. +The reverser uses in the first phase static analysis tools in order to access and review the code of the application. +If this first phase is not accurately driven, for example if they fail to access a critical class, they may decide that a malicious application is safe. +Additionally, as stated by Li #etal@Li2017 in their conclusions, such a task is complexified by dynamic code loading, reflective calls, native code, and multi-threading which cannot be easily handled statically. +Nevertheless, even if we do not consider these aspects, determining statically how the regular class loading system of Android is working is a difficult task. + +Class loading occurs at runtime and is handled by the components of Android Runtime (ART), even when the application is partially or fully compiled ahead of time. +Nevertheless, at the development stage, Android Studio handles the resolution of the different classes that can be internal to the application. +When building, the code is linked to the standard library i.e. the code contained in `android.jar`. +In this article, we call these classes "Development SDK classes". +`android.jar` is not added to the application because its classes will be available at runtime in others `.jar` files. +To distinguish those classes found at runtime from Dev SDK classes, we call them #Asdkc. +When releasing the application, the building process of Android Studio can manage different versions of the #Asdk, reported in the Manifest as the "SDK versions". +Indeed, some parts of the core #Asdkc can be embedded in the application, for retro compatibility purposes: by comparing the specified minimum SDK version and the target SDK version, the code of extra #Asdkc is stored in the APK file. +As a consequence, it is frequent to find inside applications some classes that come from the `com.android` packages. +At runtime each smartphone runs a unique version of Android, but, as the application is deployed on multiple versions of Android, it is difficult to predict which classes will be loaded from the #Asdkc or from the APK file itself. +This complexity increases with the multi-DEX format of recent APK files that can contain several bytecode files. + +Going back to the problem of a reverser studying a suspicious application statically, the reverser uses tools to disassemble the application@mauthe_large-scale_2021 and track the flows of data in the bytecode. +As an example, for a spyware potentially leaking personal information, the reverser can unpack the application with Apktool and, after manually locating a method that they suspect to read sensitive data (by reading the unpacked bytecode), they can compute with FlowDroid@Arzt2014a if there is a flow from this method to methods performing HTTP requests. +During these steps, the reverser faces the problem of resolving statically, which class is loaded from the APK file and the #Asdkc. +If they, or the tools they use, choose the wrong version of the class, they may obtain wrong conclusions about the code. +Thus, the possibility of shadowing classes could be exploited by an attacker in order to obfuscate the code. + +In this paper, we study how Android handles the loading of classes in the case of multiple versions of the same class. +Such collision can exist inside the APK file or between the APK file and #Asdkc. +We intend to understand if a reverser would be impacted during a static analysis when dealing with such an obfuscated code. +Because this problem is already enough complex with the current operations performed by Android, we exclude the case where a developer recodes a specific class loader or replace a class loader by another one, as it is often the case for example in packed applications@Duan2018. +We present a new technique that "shadows" a class #ie embeds a class in the APK file and "presents" it to the reverser instead of the legitimate version. +The goal of such an attack is to confuse them during the reversing process: at runtime the real class will be loaded from another location of the APK file or from the #Asdk, instead of the shadow version. +This attack can be applied to regular classes of the #Asdk or to hidden classes of Android@he_systematic_2023 @li_accessing_2016. +We show how these attacks can confuse the tools of the reverser when he performs a static analysis. +In order to evaluate if such attacks are already used in the wild, we analyzed #nbapk applications from 2023 that we extracted randomly from AndroZoo@allixAndroZooCollectingMillions2016. +Our main result is that #shadowsdk of these applications contain shadow collisions against the SDK and #shadowhidden against hidden classes. +Our investigations conclude that most of these collisions are not voluntary attacks, but we highlight one specific malware sample performing strong obfuscation revealed by our detection of one shadow attack. + +The paper is structured as follows. +@sec:cl-soa reviews the state of the art about loading of Android classes and the tools to perform reverse engineering on applications. +Then, @sec:cl-loading investigates the internal mechanisms about class loading and presents how a reverser can be confused by these mechanisms. +In @sec:cl-obfuscation, we design obfuscation techniques and we show their effect on static analysis tools. +Finally, @sec:cl-wild evaluates if these obfuscation techniques are used in the wild, by searching inside #nbapk APKs if they exploit these techniques. +@sec:cl-ttv discusses the limits of this work and @sec:cl-conclusion concludes the paper. + +// In addition to the public #Asdk of `android.jar`, other internal classes are also available for the Android Runtime. +// Those classes are called hidden #Asdkc@li_accessing_2016, and are not supposed to be used by applications. +// In reality their use is tolerated and many applications use them to access some of Android features. +// This tolerance is one of the key point that lead to confusion attacks that we describe later in the paper. + diff --git a/papers/4_class_loader/1_related_work.typ b/papers/4_class_loader/1_related_work.typ new file mode 100644 index 0000000..3a67305 --- /dev/null +++ b/papers/4_class_loader/1_related_work.typ @@ -0,0 +1,54 @@ +#import "../lib.typ": etal, paragraph, DEX +#import "X_var.typ": * + +== State of the Art + +#paragraph([Class loading])[ +Class loading mechanisms have been studied in the general context of the Java language. +Gong@gong_secure_1998 describes the JDK 1.2 class loading architecture and capabilities. +One of the main advantages of class loading is the type safety property that prevents type spoofing. +As explained by Liang and Bracha@liang_dynamic_1998, by capturing events at runtime (new loaders, new class) and maintaining constraints on the multiple loaders and their delegation hierarchy, authors can avoid confusion when loading a spoofed class. +This behavior is now implemented in modern Java virtual machines. +Later Tazawa and Hagiya@tozawa_formalization_2002 proposed a formalization of the Java Virtual Machine supporting dynamic class loading in order to ensure type safety. +Those works ensure strong safety for the Java Virtual Machine, in particular when linking new classes at runtime. +Although Android has a similar mechanism, the implementation is not shared with the JVM of Oracle. +Additionally, in this paper, we do not focus on spoofing classes at runtime, but on confusion that occurs when using a static analyzer used by a reverser that tries to understand the code loading process offline. + +Contributions about Android class loading focus on using the capabilities of class loading to extend Android features or to prevent reverse engineering of Android applications. +For instance, Zhou #etal@zhou_dynamic_2022 extend the class loading mechanism of Android to support regular Java bytecode and Kritz and Maly@kriz_provisioning_2015 propose a new class loader to automatically load modules of an application without user interactions. + +Regarding reverse engineering, class loading mechanisms are frequently used by packers for hiding all or parts of the code of an application@Duan2018. +The problem to be solved consists in locating secondary #dexfiles that can be unciphered just before being loaded. +Dynamic hook mechanisms should be used to intercept the bytecode at load time. +These techniques can be of some help for the reverser, but they require to instrument the source code of AOSP or the application itself. +The engineering cost is high and anti-debugging techniques can slow down the process. +Thus, a reverser always starts by studying statically an application using static analysis tools@Li2017, and will eventually go to dynamic analysis@Egele2012 if further costly extra analysis is needed (for example, if they spot the use of a custom class loader). +Performing a static analysis of an application can be time consuming if the programmer uses obfuscation techniques such as native code, packing techniques, value encryption, or reflection. +Such techniques can partially hide the Java bytecode from a static analysis investigation as they modify it at runtime. +For example, packers exploits the class loading capability of Android to load new code. +They also combine the loading with code generation from ciphered assets or code modification from native code calls@liao2016automated to increase the difficulty of recovery of the code. +Because parts of the original code will be only available at runtime, deobfuscation approaches propose techniques that track #DEX structures when manipulated by the application@zhang2015dexhunter @xue2017adaptive @wong2018tackling. All those contributions are directly related to the class loading mechanism of Android. + +Deobfuscating an application is the first problem the reverse engineer has to solve. Nevertheless, even, if all classes of the code are recovered by the reverse engineer, understanding what are the classes that are really loaded by Android brings an additional problem. +The reverse engineer can have the feeling that what he sees in the bytecode is what is loaded at runtime, whereas the system can choose alternative implementations of a class. +Our goal is to show that tools mentioned in the literature@Li2017 can suffer from attacks exploiting confusion inside regular class loading mechanisms of Android. +] + +#paragraph([Hidden APIs])[ +Li #etal did an empirical study of the usage and evolution of hidden APIs@li_accessing_2016. +They found that hidden APIs are added and removed in every release of Android, and that they are used both by benign and malicious applications. +More recently, He #etal @he_systematic_2023 did a systematic study of hidden service API related to security. +They studied how the hidden API can be used to bypass Android security restrictions and found that although Google countermeasures are effective, they need to be implemented inside the system services and not the hidden API due to the lack of in-app privilege isolation: the framework code is in the same process as the user code, meaning any restriction in the framework can be bypassed by the user. +] + +#paragraph([Static analysis tools])[ +Static analysis tools are used to perform operations on an APK file, for example extracting its bytecode or information from the Manifest file. +Because of the complexity of Android, few tools have followed all the evolutions of the file format and are robust enough to analyze all applications without crashing@mineau_evaluating_2024. +The tools can share the backend used to manipulate the code. +For example, Apktool is often called in a subprocess to extracte the bytecode. +Another example is Soot@Arzt2013, a Java framework that allows to manipulate the bytecode from an object representation of instructions. +This framework enables advanced features such as inserting or removing bytecode instructions but can require a lot of memory and time to perform its operations. +The most known tool built on top of Soot is FlowDroid@Arzt2014a, which enables to compute information flows statically into the code. + +Because these tools are used by reversers, we will evaluate the accuracy of the provided results in the case of an application developer exploits the possible confusions that brings the class loading mechanisms of Android. +] diff --git a/papers/4_class_loader/2_classloading.typ b/papers/4_class_loader/2_classloading.typ new file mode 100644 index 0000000..52765cf --- /dev/null +++ b/papers/4_class_loader/2_classloading.typ @@ -0,0 +1,205 @@ +#import "../lib.typ": todo, ie, etal, num, DEX +#import "X_var.typ": * + +== Analyzing the Class Loading Process + +For building obfuscation techniques based on the confusion of tools with class loaders, we manually studied the code of Android that handles class loading. +In this section, we report the inner workings of ART and we focus on the specificities of class loading that can bring confusion. +Because the class loading implementation has evolved over time during the multiple iterations of the Android operating system, we mainly describe the behavior of ART from Android version 14 (SDK 34). + +=== Class Loaders + +When ART needs to access a class, it queries a `ClassLoader` to retrieve its implementation. +Each class has a reference to the `ClassLoader` that loaded it, and this class loader is the one that will be used to load supplementary classes used by the original class. +For example in @lst:cl-expl-cl-loading, when calling `A.f()`, the ART will load `B` with the class loader that was used to load `A`. + +#figure( + ```java + class A { + public static void f() { + B b = new B(); + b.do_something(); + }} + ```, + caption: [Class instantiation], +) + +This behavior has been inherited from Java and most of the core classes regarding class loaders have been kept in Android. +Nevertheless, the Android implementation has slight differences and new class loaders have been added. +For example, the java class loader `URLClassLoader` is still present in Android, but contrary to the official documentation, most of its methods have been removed or replaced by a stub that just raises an exception. +Moreover, rather than using the Java class loaders `SecureClassLoader` or `URLClassLoader`, Android has several new class loaders that inherit from `ClassLoader` and override the appropriate methods. + +The left part of @fig:cl-class_loading_classes shows the different class loaders specific to Android in white and the stubs of the original Java class loaders in grey. +The main difference between the original Java class loaders and the ones used by Android is that they do not support the Java bytecode format. +Instead, the Android-specific class loaders load their classes from (many) different file formats specific to Android. +Usually, when used by a programmer, the classes are loaded from memory or from a file using the DEX format (`.dex`). +When used directly by ART, the classes are usually stored in an application file (`.apk`) or in an optimized format (`OAR/ODEX`). + +#todo[Alt text for cl-class_loading_classes] +#figure([ + #image( + "figs/classloaders-crop.svg", + width: 80%, + alt: "" + ) + gray -- Java-based, white -- Android-based + ], + caption: [The class loading hierarchy of Android] +) + +=== Delegation + +The order in which classes are loaded at runtime requires special attention. +All the specific Android class loaders (`DexClassLoader`, `InMemoryClassLoader`, etc.) have the same behavior (except `DelegateLastClassLoader`) but they handle specificities for the input format. +Each class loader has a delegate class loader, represented in the right part of @fig:cl-class_loading_classes by black plain arrows for an instance of `PathClassLoader` and an instance of `DelegateLastClassLoader` (the other class loaders also have this delegate). +This delegate is a concept specific to class loaders and has nothing to do with class inheritance. +By default, class loaders will delegate to the singleton class `BootClassLoader`, except if a specific class loader is provided when instantiating the new class loader. +When a class loader needs to load a class, except for `DelegateLastClassLoader`, it will first ask the delegate, i.e. `BootClassLoader`, and if the delegate does not find the class, the class loader will try to load the class on its own. +This behavior implements a priority and avoids redefining by error a core class of the system, for example redefining `java.lang.String` that would be loaded by a child class loader instead of its delegates. +`DelegateLastClassLoader` behaves slightly differently: it will first delegate to `BootClassLoader` then, it will check its files and finally, it will delegate to its actual delegate (given when instantiating the `DelegateLastClassLoader`). +This behavior is useful for overriding specific classes of a class loader while keeping the other classes. +A normal class loader would prioritize the classes of its delegate over its own. + +#figure( + ```python + def get_mutli_dex_classses_dex_name(index: int): + if index == 0: + return "classes.dex" + else: + return f"classes{index+1}.dex" + + def load_class(class_name: str): + if is_platform_class(class_name): + return load_from_boot_class_loader(class_name) + else: + index = 0 + dex_file = get_mutli_dex_classses_dex_name(index) + while file_exists_in_apk(dex_file) and \ + not class_found_in_dex_file(class_name, dex_file): + index += 1 + if file_exists_in_apk(dex_file): + return load_from_file(dex_file, class_name) + else: + raise ClassNotFoundError() + ```, + caption: [Default Class Loading Algorithm for Android Applications], +) + +At runtime, Android instantiates for each application three instances of class loaders described previously: `bootClassLoader`, the unique instance of `BootClassLoader`, and two instances of `PathClassLoader`: `systemClassLoader` and `appClassLoader`. +`bootClassLoader` is responsible for loading Android *#platc*. +It is the direct delegate of the two other class loaders instantiated by Android. +`appClassLoader` points to the application `.apk` file, and is used to load the classes inside the application +`systemClassLoader` is a `PathClassLoader` pointing to `'.'`, the working directory of the application, which is `'/'` by default. +The documentation of `ClassLoader.getSystemClassLoader` reports that this class loader is the default context class loader for the main application thread. +In reality, the #platc are loaded by `bootClassLoader` and the classes from the application are loaded from `appClassLoader`. +`systemClassLoader` is never used. + +In addition to the class loaders instantiated by ART when starting an application, the developer of an application can use class loaders explicitly by calling to ones from the #Asdk, or by recoding custom class loaders that inherit from the `ClassLoader` class. +At this point, modeling accurately the complete class loading algorithm becomes impossible: the developer can program any algorithm of their choice. +For this reason, this case is excluded from this paper and we focus on the default behavior where the context class loader is the one pointing to the `.apk` file and where its delegate is `BootClassLoader`. +With such a hypothesis, the delegation process can be modeled by the pseudo-code of method `load_class` given in . + +In addition, it is important to distinguish the two types of #platc handled by `BootClassLoader` and that both have priority over classes from the application at runtime: + +- the ones available in the *#Asdk* (normally visible in the documentation); +- the ones that are internal and that should not be used by the developer. We call them *#hidec*@he_systematic_2023 @li_accessing_2016 (not documented). + +As a preliminary conclusion, we observe that a priority exists in the class loading mechanism and that an attacker could use it to prioritize an implementation over another one. +This could mislead the reverser if they use the one that has the lowest priority. +To determine if a class is impacted by the priority given to `BootClassLoader`, we need to obtain the list of classes that are part of Android #ie the #platc. +We discuss in the next section how to obtain these classes from the emulator. + +=== Determining Platform Classes + +#figure( + image( + "figs/architecture_SDK-crop.svg", + width: 80%, + alt: "" + ), + caption: [Location of SDK classes during development and at runtime] +) + +@fig:cl-archisdk shows how classes of Android are used in the development environment and at runtime. +In the development environment, Android Studio uses `android.jar` and the specific classes written by the developer. +After compilation, only the classes of the developer, and sometimes extra classes computed by Android Studio are zipped in the APK file, using the multi-dex format. +At runtime, the application uses `BootClassLoader` to load the #platc from Android. +Until our work, previous works@he_systematic_2023 @li_accessing_2016 considered both #Asdk and #hidec to be in the file `/system/framework/framework.jar` found in the phone itself, but we found that the classes loaded by `bootClassLoader` are not all present in `framework.jar`. +For example, He #etal @he_systematic_2023 counted 495 thousand APIs (fields and methods) in Android 12, based on Google documentation on restriction for non SDK interfaces#footnote[https://developer.android.com/guide/app-compatibility/restrictions-non-sdk-interfaces]. +However, when looking at the content of `framework.jar`, we only found #num(333) thousand APIs. +Indeed, classes such as `com.android.okhttp.OkHttpClient` are loaded by `bootClassLoader`, listed by Google, but not in `framework.jar`. + +For optimization purposes, classes are now loaded from `boot.art`. +This file is used to speed up the start-up time of applications: it stores a dump of the C++ objects representing the *#platc* (#Asdk and #hidec) so that they do not need to be generated each time an application starts. +Unfortunately, this format is not documented and not retro-compatible between Android versions and is thus difficult to parse. +An easier solution to investigate the #platc is to look at the `BOOTCLASSPATH` environment variable in an emulator. +This variable is used to load the classes without the `boot.art` optimization. +We found 25 `.jar` files, including `framework.jar`, in the `BOOTCLASSPATH` of the standard emulator for Android 12 (SDK 32), 31 for Android 13 (SDK 33), and 35 for Android 14 (SDK 35), containing respectively a total of #num(499837), #num(539236) and #num(605098) API methods and fields. +@tab:cl-platform_apis) summarizes the discrepancies we found between Google's list and the #platc we found in Android emulators. +Note also that some methods may also be found _only_ in the documentation. +Our manual investigations suggest that the documentation is not well synchronized with the evolution of the #platc and that Google has almost solved this issue in API 34. + + +#figure({ + show table: set text(size: 0.80em) + table( + columns: 5, + //inset: (x: 0% + 5pt, y: 0% + 2pt), + stroke: none, + align: center+horizon, + table.hline(), + table.header( + table.cell(colspan: 5, inset: 3pt)[], + table.cell(rowspan: 2)[*SDK version*], + table.vline(end: 3), + table.vline(start: 4), + table.cell(colspan: 4)[*Number of API methods*], + [Documented], [In emulator], [Only documented], [Only in emulator], + ), + table.cell(colspan: 5, inset: 3pt)[], + table.hline(), + table.cell(colspan: 5, inset: 3pt)[], + + [32], num(495713), num(499837), num(1060), num(5184), + [33], num(537427), num(539236), num(1258), num(3067), + [34], num(605106), num(605098), num(26), num(18), + + table.cell(colspan: 4, inset: 3pt)[], + table.hline(), + )}, + + caption: [Comparison for API methods between documentation and emulators], +) + +We conclude that it can be dangerous to trust the documentation and that gathering information from the emulator or phone is the only reliable source. +Gathering the precise list of classes and the associated bytecode is not a trivial task. + +=== Multiple #DEX Files + +For the application class files, Android uses its specific format called DEX: all the classes of an application are loaded from the file `classes.dex`. +With the increasing complexity of Android applications, the need arrised to load more methods than the DEX format could support in one #dexfile. +To solve this problem, Android started storing classes in multiple files named `classesX.dex` as illustrated by the @lst:cl-dexname that generates the filenames read by class loaders. +Android starts loading the file `GetMultiDexClassesDexName(0)` (`classes.dex`), then `GetMultiDexClassesDexName(1)` (`classes2.dex`), and continues until finding a value `n` for which `GetMultiDexClassesDexName(n)` does not exist. +Even if Android emits a warning message when it finds more than 100 #dexfiles, it will still load any number of #dexfiles that way. +This change had the unintended consequence of permitting two classes with the same name but different implementations to be stored in the same `.apk` file using two #dexfiles. + +Android explicitly performs checks that prevent several classes from using the same name inside a #dexfile. +However, this check does not apply to multiple #dexfiles in the same `.apk` file, and a `.dex` can contain a class with a name already used by another class in another #dexfile of the application. +Of course, such a situation should not happen when multiple #dexfiles have been generated by properly Android Studio. +Nevertheless, for an attacker controlling the process, this issue raises the question of which class is selected when several classes sharing the same name are present in `.apk` files. + +We found that Android loads the class whose implementation is found first when looking in the order of multiple `dexfiles`, as generated by the method `GetMultiDexClassesDexName`. +We will show later in @sec:cl-evaltools that this choice is not the most intuitive and can lead to fool analysis tools when reversing an application. +As a conclusion, we model both the multi-dex and delegation behaviors in the pseudo-code of @lst:cl-loading-alg. + +#figure( + ```C++ + std::string DexFileLoader::GetMultiDexClassesDexName(size_t index) { + return (index == 0) ? + "classes.dex" : + StringPrintf("classes%zu.dex", index + 1); + } + ```, + caption: [The method generating the .dex filenames from the AOSP] +) + diff --git a/papers/4_class_loader/3_obfuscation.typ b/papers/4_class_loader/3_obfuscation.typ new file mode 100644 index 0000000..4224721 --- /dev/null +++ b/papers/4_class_loader/3_obfuscation.typ @@ -0,0 +1,284 @@ +#import "../lib.typ": eg, todo, paragraph +#import "X_var.typ": * + +== Obfuscation Techniques + +In this section, we present new obfuscation techniques that take advantage of the complexity of the class loading process. +Then, in order to evaluate their efficiency, we reviewed some common Android reverse analysis tools to see how they behave when collisions occur between classes of the APK or between a class of the APK and classes of Android (#Asdk or #hidec). +We call this collision "*class shadowing*", because the attacker version of the class shadows the one that will be used at runtime. +To evaluate if such shadow attacks are working, we handcrafted three applications implementing shadowing techniques to test their impact on static analysis tools. +Then, we manually inspected the output of the tools in order to check its consistency with what Android is really doing at runtime. +For example, for Apktool, we look at the output disassembled code, and for Flowdroid@Arzt2014a, we check that a flow between `Taint.source()` and `Taint.sink()` is correctly computed. + + +/* +shadow: faie une collision de classe +hidden: utiliser une classe de l'API cachée + +on peut shadow une classe de l'apk +on peut shadow une classe du SDK +on peut shadow une classe hidden +*/ + + +=== Obfuscation Techniques + +From the results presented in @sec:cl-loading, three approaches can be designed to hide the behavior of an application. + +/* +#paragraph([Hidden classes])[ +Applications both malicious and benign have been known to use hidden API to access advance features #todo[ref ?]. +Using #hidec can have an impact on the accuracy of analysis tools because they may not have access to the code of these classes. +] +#todo[Google blacklist/greylist/ect, ref to paper that says this can be bypass] + +#todo[Compare classes in android.jar, framework.jar and other, are they hidden whitelisted classes?] + +The two previous attacks have a few issue. +Basic shadowing imply to have several class with the same name in the application, which can be detected by some tools. +On the other hand, using #hidec leave classes without implementation in the application, which can also be detected. +*/ + +#paragraph([*Self shadow*: shadowing a class with another from APK])[ +This method consists in hiding the implementation of a class with another one by exploiting the possible collision of class names, as described in @sec:cl-collision with multiple #dexfiles. +If reversers or tools ignore the priority order of a multi-dex file, they can take into account the wrong version of a class. +] + +//priorité aux classes SDK meme si une shadow classe est définie dans l'APK (tout ca a cause de Boot) +#paragraph([*SDK shadow*: shadowing a SDK class])[ +This method consists in presenting to the reverser a fake implementation of a class of the SDK. +This class is embedded in the APK file and has the same name as the one of the SDK. +Because `BootClassLoader` will give priority to the #Asdk at runtime, the reverser or tool should ignore any version of a class that is contained in the APK. +The only constraint when shadowing an SDK class is that the shadowing implementation must respect the signature of real classes. +Note that, by introducing a custom class loader, the attacker could inverse the priority, but this case is out of the scope of this paper. +] + +// priorité aux classes hidden (car du SDK) meme si une shadow classe est définie dans l'APK +#paragraph([*Hidden shadow*: shadowing an hidden class])[ +This method is similar to the previous one, except the class that is shadowed is a #hidecsingular. +Because ART will give priority to the internal version of the class, the version provided in the APK file will be ignored. +Such shadow attacks are more difficult to detect by a reverser, that may not know the existence of this specific hidden class in Android. +] + +=== Impact on Static Analysis Tools + +#figure( + ```java + public class Main { + public static void main(Activity ac) { + String personal_data = Taint.source(); + String obfuscated_personal_data = Obfuscation.hide_flow(personal_data); + Taint.sink(ac, obfuscated_personal_data); + } + } + public class Obfuscation { // customized for each obfuscation technique + public static String hide_flow(String personal_data) { ... } + ```, + caption: [Main body of test apps] +) + + +We selected tools that are commonly used to unpack and reverse Android applications: Jadx#footnote[https://github.com/skylot/jadx], a decompiler for Android applications, Apktool#footnote[https://apktool.org/], a disassembler/repackager of applications, Androguard#footnote[https://github.com/androguard/androguard], one of the oldest Python package for manipulating Android applications, and Flowdroid@Arzt2014a that performs taint flow analysis. + +For evaluating the tools, we designed a single application that we can customize for different tests. +@lst:cl-testapp shows the main body implementing: +- a possible flow to evaluate FlowDroid: a flow from a method `Taint.source()` to a method `Taint.sink(Activity, String)` through a method `Obfuscation.hide_flow(String)`; +- a possible use of a SDK or hidden class inside the class `Obfuscation` to evaluate #platc shadowing for other tools. + +The first application we released is a control application that does not do anything special. +It will be used for checking the expecting result of tools. +The second implements self shadowing: the class `Obfuscation` is duplicated: one is the same as the in the control app (`Obfuscation.hide_flow(String)` returns its arguments), and the other version returns a constant string. +These two versions are embedded in several DEX of a multi-dex application. +The third application tests SDK shadowing and needs an existing class of the SDK. +We used `Pair` that we try to shadow. +We put data in a `Pair` and reread the data from the `Pair`. The colliding `Pair` discards the data and returns null. +The last application tests for Hidden API shadowing. +Like for the third one, we similarly store data in `com.android.okhttp.Request` and then retrieve it. +Again, the shadowing implementation discards the data. + +We found that these static analysis tools do not consider the class loading mechanism, either because the tools only look at the content of the application file (#eg a disassembler) or because they consider class loading to be a dynamic feature and thus out of their scope. +In @tab:cl-results, we report on the types of shadowing that can be tricked each tool. +A plain circle is a shadow attack that leads to a wrong result. +A white circle indicates a tool emitting warnings or that displays the two versions of the class. +A cross is a tool not impacted by a shadow attack. +We explain in more detail in the following the results for each considered tool. + +#figure({ + table( + columns: 5, + stroke: none, + align:(left+horizon, center+horizon, center+horizon, center+horizon, center+horizon), + table.hline(), + table.header( + table.cell(colspan: 5, inset: 3pt)[], + table.cell(rowspan: 2)[Tool], + table.cell(rowspan: 2)[Version], + table.vline(end: 3), + table.vline(start: 4), + table.cell(colspan: 3)[Shadow Attack], + [Self], [SDK], [Hidden], + ), + table.cell(colspan: 5, inset: 3pt)[], + table.hline(), + table.cell(colspan: 5, inset: 3pt)[], + + [Jadx], [1.5.0], [#warn], [#ok], [#ok], + [Apktool], [2.9.3], [#warn], [#ok], [#ok], + [Androguard], [4.1.2], [#warn], [#ok], [#ok], + [Flowdroid], [2.13.0], [#ok], [#ko], [#ok], + + table.cell(colspan: 5, inset: 3pt)[], + table.hline(), + ) + [#ok: working \ #warn: works but producing warning or can be seen by the reverser \ #ko: not working] + }, + caption: [Working attacks against static analysis tools] +) + +==== Jadx + +Jadx is a reverse engineering tool that regenerates the Java source code of an application. +It processes all the classes present in the application, but only save/display one class by name, even if two versions are present in multiple #dexfiles. +Nevertheless, when multiple classes with the same name are found, Jadx reports it in a comment added to the generated Java source code. +This warning stipulates that a possible collision exists and lists the files that contain the different versions of the class. +Unfortunately, after reviewing the code of Jadx, we believe that the selection of the displayed class is an undefined behavior. +At least for the version 1.5.0 that we tested, we found that Jadx selects the wrong implementation when a class with the same name is present. +For example in `classes2.dex` and `classes3.dex`. +We report it with a "#warn" because warnings are issued. + +//Using #hidec does not affect Jadx beyond the fact that #hidec are not decompiled, which is to be expected by the user anyway. + +Shadowing #Asdk and #hidec is possible in Jadx: there is only one implementation of the class in the application and Jadx does not have a list of the internal classes of Android: no warning is issued to the reverser that the displayed class is not the one used by Android. + +==== Apktool + +Apktool generates Smali files, an assembler language for DEX bytecode. +Apktool will store the disassembled classes in a folder that matches the #dexfile that stores the bytecode. +This means that when shadowing a class with two versions in two #dexfiles, the shadow implementations will be disassembled into two directories. +No indication is displayed that a collision is possible. +It is up to the reverser to have a chance to open the good one. + +Similarly to Jadx, using an #Asdk or #hidecsingular will not be detected by the tool that will unpack the fake shadow version. + +==== Androguard + +Androguard has different usages, with different levels of analysis. +The documentation highlights the analysis commands that compute three types of objects: an APK object, a list of DEX objects, and an Analysis object. +The APK and the list of #dexfiles are a one-to-one representation of the content of an application, and have the same issues that we discussed with Apktool: they provide the different versions of a shadow class contained in multiple #dexfiles. + +The Analysis object is used to compute a method call graph and we found that this algorithm may choose the wrong version of a shadowed class when using the cross references that are computed. +This leads to an invalid call graph as shown in @fig:cl-andro_obf_cg: the two methods `doSomething()` are represented in the graph, but the one linked to `main()` on the graph is the one calling the method `good()` when in fact the method `bad()` is called when running the application. + +Androguard has a method `.is_external()` to detect if the implementation of a class is not provided inside the application and a method `.is_android_api()` to detect if the class is part of the Android API. +Regrettably, the documentation of `.is_android_api()` explains that the method is still experimental and just checks a few package names. +This means that although those methods are useful, the only indication of the use of an #Asdk or #hidec is the fact that the class is not in the APK file. +Because of that, like for Apktool and Jadx, Androguard has no way to warn the reverser that the shadow of an #Asdk or #hidec is not the class used when running the application. + +#todo[alt text androguard_call_graph] + +#figure({ + set align(center) + stack(dir: ltr,[ + #figure( + image( + "figs/call_graph_expected.svg", + width: 45%, + alt: "" + ), + supplement: [Subfigure], + caption: [Expected Call Graph] + ) ],[ + #figure( + image( + "figs/call_graph_obf.svg", + width: 45%, + alt: "" + ), + supplement: [Subfigure], + caption: [Call Graph Computed by Androguard] + ) + ]) + h(1em)}, + caption: [Call Graphs of an application calling `Main.bad()` from a shadowed `Obfuscation` class.], +) + +==== Flowdroid + +Flowdroid@Arzt2014a is used to detect if an application can leak sensitive information. +To do so, the analyst provides a list of source and sink methods. +The return value of a method marked as source is considered sensitive and the argument of a method marked as sink is considered to be leaked. +By analyzing the bytecode of an application, Flowdroid can detect if data emitted by source methods can be exfiltrated by a sink method. +Flowdroid is built on top of the Soot@Arzt2013 framework that handles, among other things, the class selection process. + +We found that when selecting the classes implementation in a multi-dex APK, Soot uses an algorithm close to what ART is performing: +Soot sorts the `.dex` bytecode file with a specified `prioritizer` (a comparison function that defines an order for #dexfiles) and selects the first implementation found when iterating over the sorted files. +Unfortunately, the `prioritizer` used by Soot is not exactly the same as the one used by the ART. +The Soot `prioritizer` will give priority to `classes.dex` and then give priority to files whose name starts with `classes` over other files and finally will use the alphabetical order. +This order is good enough for application with a small number of #dexfiles generated by Android Studio, but because it uses the alphabetical order and does not check the exact format used by Android, a malicious developer could hide the implementation of a class in `classes2.dex` by putting a false implementation in `classes0.dex`, `classes1.dex` or `classes12.dex`. + +// TODO This could use more investigation +In addition to self shadowing, Flowdroid is sensitive to the use of #platc, as it needs the bytecode of those classes to be able to track data flows. +This is solved for SDK classes by providing `android.jar` to Flowdroid. +Flowdroid gives priority to the classes from the SDK over the classes implemented in the application, thus defeating SDK shadow attacks. +Unfortunately, `android.jar` only contains classes from the #Asdk, meaning that using #hidec breaks the flow tracking. +Solving this issue would require finding the bytecode of all the platform classes of the Android version targeted and as we said previously it requires extracting this information from the emulator. + +=== Countermeasures + +Countermeasures against shadow attacks depend on each tool and its objectives. +The first important recommendation is to implement the class selection algorithm according to the algorithm described in Listing @lst:cl-loading-alg. +It should solve any case of self-shadowing, except for tools like Apktool, which do not have to select a class for computing the result but show the whole application's content. +For those tools, a clear warning should be added, pointing out that multiple implementations have been found and displaying the one that will be used at runtime. + +Countermeasures against SDK shadow and Hidden shadow attacks are more complex to handle: it requires the list of platform classes on the target smartphone. +The list of SDK classes can be extracted easily from android.jar, but hidden classes need to be obtained by another means. +They could be listed directly from the AOSP tree of the Android source code, or obtained from Android documentation, or extracted from the phone itself. +The first approach requires statically analyzing the source code, which can be difficult to achieve as several programming languages are used, and the code base is large andd fragmented. +As discussed earlier in the paper, the documentation can lack some classes. +Consequently, the most reliable source is the smartphone itself. +It should be noted that none of these methods can be generalized for all possible versions of Android, as the exact list will depend on the exact targeted device, possibly modified by the manufacturer. +Thus, to conter Shadow attaks, the static analysis tools that we evaluated need to embed multiple lists of platform classes, one for each Android version. +Then, the best heuristic would be to use the list of platform classes that is closest to the target SDK of the analyzed application. + +Some tools like Flowdroid would require additional countermeasures: to compute the exact flow of data, Flowdroid also needs to analyze the code of platform classes. +For the SDK classes, Flowdroid has already analyzed them, but the hidden classes have not. +In addition to the data flow in hidden classes, Flowdroid needs a list of data sources and sinks from those classes. +%Other analysis tools may require additional data from platform classes, which may be too difficult to obtain. + +We believe that analysis tools can handle shadow attacks to some degree. +The implementation of the solution will differ depending on the nature tool and may not always require the same implementation effort. + +=== Relation with Obfuscation Techniques + +As described in the state of the art, reverse engineers face other techniques of obfuscation such as packers or native code. +These techniques rely on custom class loaders that load new parts of the application from ciphered assets or from the network. +The reverse engineers have to study the application dynamically, to recover new classes, and eventually go back to a static phase to understand the behavior of the application. +In this section, we compare shadow attacks with these techniques and we discuss how they interact with them. + +Advanced obfuscation techniques relying on packers have a higher impact on the difficulty of performing a static analysis compared to shadow attacks. +Most of the time, the reverse engineer cannot deobfuscate the application without performing a dynamic analysis. +For this reasons, approaches have been designed to assist the capture of the bytecode that is loaded dynamically, after the precise time where the deobfuscation methods have been executed@zhang2015dexhunter @xue2017adaptive @wong2018tackling. +On the contrary, a shadow attack can be easily defeated by implementing our algorithm in the static analysis tool, as discussed earlier in @sec:cl-countermeasures. +Nevertheless, shadow attacks are stealthier than packers or native code. +Packers can be easily spotted by artifacts left behind in the application or by detecting classes implementing a custom class loading mechanism. +On the contrary, an extra class implementing a shadow attack, that would not be executed, could contain voluntarily few code, compared to the executed class of Android. +Such attack would be more discrete than a packer that adds in the application a lot of possibly native code + +Combining regular obfuscation techniques with shadow attacks can be achieved in two ways. + +First, the attacker could hide the code of a packer or a native call by using a shadow attack. +For example, by colliding a class of the SDK, a control flow analysis could be wrongly computed, leading to consider that part of the code is dead, which would mislead the reverse engineer about the use of this part that contains a packer. +At runtime, this code would be triggered, unpacking new code. + +Second, the attacker could use a packer to unpack code at runtime in a first phase. +The reverse engineer would have to perform a dynamic analysis, for example uising a tool such as Dexhunter@zhang2015dexhunter, to recover new DEX files that are loaded by a custom class loader. +Then, the reverse engineer would go back to a new static analysis and could have the problem of solving shadow attacks, for example, if a class is defined multiple times in the loaded DEX files. + +Because the interaction between shadow attacks and other obfuscations techniques often rely on a loading mechanism implemented by the developer, investigating these cases require to analyze the Java bytecode that is handling the loading. +This problem is left as future work. + + +//\medskip + +We have seen that tools can be impacted by shadow attacks. In the next section, we will investigate if these attacks are used in the wild. + diff --git a/papers/4_class_loader/4_in_the_wild.typ b/papers/4_class_loader/4_in_the_wild.typ new file mode 100644 index 0000000..ed767d7 --- /dev/null +++ b/papers/4_class_loader/4_in_the_wild.typ @@ -0,0 +1,279 @@ +#import "../lib.typ": num, todo, paragraph +#import "X_var.typ": * + +== Shadow Attacks in the Wild + +In this section, we evaluate in the wild if applications that can be found in the Play store or other markets use one of the shadow techniques. +Our goal is to explore the usage of shadow techniques in real applications. +Because we want to include malicious applications (in case such techniques would be used to hide malicious code), we selected #num(50000) applications randomly from AndroZoo@allixAndroZooCollectingMillions2016 that appeared in 2023. +Malicious applications are spot in our dataset by using a threshold of 3 over the number of antivirus reporting an application as a malware. +Some few applications over the total cannot be retrieved or parsed leading to a final dataset of #nbapk applications. +We automatically disassembled the applications to obtain the list of included classes. +Then, we check if any shadow attack occurs in the APK itself or with #platc of SDK 34. + +=== Results + +/* +id code +on prend les classes des platform classes et +comparé à SDK 32 33 34: si la shadow class match, alors match +*/ + + +#todo[cl-shadow] +#figure({ + show table: set text(size: 0.80em) + table( + columns: 9, + stroke: none, + align: center+horizon, + inset: (x: 0% + 5pt, y: 0% + 2pt), + table.hline(), + table.header( + table.cell(colspan: 9, inset: 3pt)[], + [], + table.vline(end: 3), + table.vline(start: 4), + table.cell(colspan: 3)[*Number of apps*], + table.vline(end: 3), + table.vline(start: 4), + table.cell(colspan: 4)[*Average*], + table.vline(end: 3), + table.vline(start: 4), + table.cell(rowspan: 2)[*Identical Code*], + + [], + [], [*%*], [*% malware*], + [*Shadow classes*], [*Median*], [*Target SDK*], [*Min SDK*], + + ), + table.cell(colspan: 9, inset: 3pt)[], + table.hline(), + table.cell(colspan: 9)[For all applications of the dataset], + table.hline(), + table.cell(colspan: 9, inset: 3pt)[], + + ..scan_50k.map(e => ( + [*#e.method*], + num(e.nbapp), [#e.ratioapp%], [#e.ratiomal%], + num(e.avgshadow), num(e.median), num(e.avgtargetsdk), num(e.avgminsdk), + [#e.id%] + )).flatten(), + + table.cell(colspan: 9, inset: 3pt)[], + table.hline(), + table.cell(colspan: 9)[For applications with at least 1 shadow case], + table.hline(), + table.cell(colspan: 9, inset: 3pt)[], + + ..scan_only_shadow.map(e => ( + [*#e.method*], + num(e.nbapp), [#e.ratioapp%], [#e.ratiomal%], + num(e.avgshadow), num(e.median), num(e.avgtargetsdk), num(e.avgminsdk), + [#e.id%] + )).flatten(), + + table.cell(colspan: 9, inset: 3pt)[], + table.hline(), + )}, + caption: [Shadow classes compared to SDK 34 for a dataset of #nbapk applications] +) + +//The metadata provided by AndroZoo helps to have the flags reported by antiviruses used by VirusTotal#footnote[https://www.virustotal.com]. + + +We report in the upper part of @tab:cl-shadow the statistics about the whole dataset and the three shadow attacks: "self" when a class shadows another one in the APK, "SDK" when a class of the SDK shadows one of the APK, and "Hidden" when a hidden class of Android shadows one of the APK. +We observe that, on average, a few classes are shadowed by another class. +Note that the median value is 0 meaning that few apps shadow a lot of classes, but the majority of apps do not shadow anything. +The number of applications shadowing a hidden API is low, which is an expected result as these classes should not be known by the developer. +We observe a consequent number of applications, 23.52%, of applications that perform SDK shadowing. +It can be explained by the fact that some classes that newly appear are embedded in the APK for end users that have old versions of Android: it is suggested by the average value of Min SDK which is 21.7 for the whole dataset: on average, an application can be run inside a smartphone with API 21, which would require to embed all new classes from 22 to 34. +This hypothesis about missing classes is further investigated later in this section. + +In the bottom part of @tab:cl-shadow, we give the same statistics but we excluded applications that do not perform any shadowing. +For those pairs of shadow classes, we disassembled them using Apktool to perform a comparison using instructions represented in the Smali language. +For self-shadow, we compare the pair. +For the shadowing of the SDK or Hidden class, we compare the code found in the APK with implementations found in the emulator and `android.jar` of SDK 32, 33, and 34. + +#paragraph([Self-shadowing])[ +We observe a low number of applications doing self-shadow attacks. +For each class that is shadowed, we compared its bytecode with the shadowed one. +We observe that 74.8% are identical which suggests that the compilation process embeds the same class multiple times but makes variations in headers or metadata values. +We investigate later in @sec:cl-malware the case of malicious applications. +] + +#figure( + image( + "figs/redef_sdk_relative_min_sdk.svg", + width: 100%, + alt: "" + ), + caption: [Redefined SDK classes, sorted by the first SDK they appeared in.] +) + +#paragraph([SDK shadowing])[ +For the shadowing of SDK classes, we observe a low ratio of identical classes. +This result could lead to the wrong conclusion that developers embed malicious versions of the SDK classes, but our manual investigation shows that the difference is slight and probably due to compiler optimization. +To go further in the investigation, in @fig:cl-classes_by_first_sdk we represent these redefined classes with the following rules: + +- The class is classified on the X abscissa in the figure according to the SDK it first appeared in. +- The class is counted as "green" (solid) if it first appeared in the SDK *after* the APK min SDK (retro compatibility purpose). +- The class is counted as "red" (hatched) if it first appeared in the SDK *before* the APK min SDK (which is useless for the application as the SDK version is always available). + +We observe that the majority of classes are legitimate retro-compatibility additions of classes, especially after SDK 21 (which is the average min SDK, cf. @tab:cl-shadow). +Abnormal cases are observed for classes that appeared in API versions 7 and before, 8, and 16. +@tab:cl-topsdk reports the top ten classes that shadow the SDK for the three mentioned versions. +For SDK before 7, it mainly concerns HTTP classes: for example, the class `HttpParams` is an interface, containing limited bytecode that mostly matches the class already present on the emulator (98.03% of shadowed classes are identical). +`HttpConnectionParams` on the other hand differs from the platform class and we observe only 4.99% of identical classes. +Manual inspection of some applications revealed that the two main reasons are: + + +- instead of checking if the methods attributes are null inline like Android does, applications use the method `org.apache.http.util.Args.notNull()`. According to comments in the source code of Android#footnote[https://cs.android.com/android/platform/superproject/main/+/main:frameworks/base/core/java/org/apache/http/params/HttpConnectionParams.java;drc=3bdd327f8532a79b83f575cc62e8eb09a1f93f3d?], the class was forked in 2007 from Apache 'httpcomponents' project. Looking at the history of the project, the use of `Args.notNull()` was introduced in 2012#footnote[https://github.com/apache/httpcomponents-core/commit/9104a92ea79e338d876b1b60f5cd2b243ba7069f?]. This shows that applications are embedding code from more recent version of this library without realizing their version will not be the used one. +- very small changes that we found can be attributed to the compilation process (e.g. swapping registers: `v0` is used instead of `v1` and `v1` instead of `v0`), but even if we consider them different, they are very similar. + +The remaining 4.99% of classes that are identical to the Android version are classes where the body of the methods is replaced by stubs that throw `RuntimeException("Stub!")`. +This code corresponds to what we found in android.jar but not the code we found in the emulator, which is surprising. +Nevertheless, we decided to count them as identical, because `android.jar` is the official jar file for developer, and stubs are replaced in the emulator: it is intended by Google developers. + +Other results of @tab:cl-topsdk can be similarly discussed: either they are identical with a high ratio, or they are different because of small variations. +When substantial differences appear it is mainly because different versions of the same library have been used or an SDK class is embedded for retro-compatibility. +] + +#figure({ + show table: set text(size: 0.80em) + table( + columns: 3, + stroke: none, + align: (left, right, right), + inset: (x: 0% + 5pt, y: 0% + 2pt), + table.hline(), + table.header( + table.cell(colspan: 3, inset: 2pt)[], + [*Class*], [*Occurrences*], [*Identical ratio*], + ), + table.cell(colspan: 3, inset: 2pt)[], + table.hline(), + table.cell(colspan: 3, inset: 2pt)[], + [redefined for SDK $<=$ 7], [], [], + table.hline(), + table.cell(colspan: 3, inset: 2pt)[], + ..redef_sdk_7minus.map(e => ( + raw(e.class), num(e.occ), [#e.idper%], + )).flatten(), + + table.cell(colspan: 3, inset: 2pt)[], + table.hline(), + table.cell(colspan: 3, inset: 2pt)[], + [redefined for SDK $=$ 8], [], [], + table.cell(colspan: 3, inset: 2pt)[], + table.hline(), + table.cell(colspan: 3, inset: 2pt)[], + ..redef_sdk_8.map(e => ( + raw(e.class), num(e.occ), [#e.idper%], + )).flatten(), + + table.cell(colspan: 3, inset: 2pt)[], + table.hline(), + table.cell(colspan: 3, inset: 2pt)[], + [redefined for SDK $=$ 16], [], [], + table.cell(colspan: 3, inset: 2pt)[], + table.hline(), + table.cell(colspan: 3, inset: 2pt)[], + ..redef_sdk_16.map(e => ( + raw(e.class), num(e.occ), [#e.idper%], + )).flatten(), + + + table.cell(colspan: 3, inset: 2pt)[], + table.hline(), + )}, + caption: [Shadow classes compared to SDK 34 for a dataset of #nbapk applications] +) + +#paragraph([Hidden shadowing])[ +For applications redefining hidden classes, on average, 16.1 classes are redefined (cf bottom part of @tab:cl-shadow). +The top 3 packages whose code actually differs from the ones found in Android are `java.util.stream`, `org.ccil.cowan.tagsoup` and `org.json`: + +- stream: when looking in more detail, we found that `java.util.stream` was only redefined by 6 applications, but the large number of classes redefined artificially puts the package at the top of the list. // It is explained by the fact that developers have included this library containing a lot of classes colliding with Android. +- tagsoup: `TagSoup` is a library for parsing HTML. // Developers do not know that it is part of Android as hidden classes. +- json: there is only one hidden class in `org.json`, redefined by #num(821) applications: `JSONObject$1`. + `org.json` is a package in Android SDK, not a hidden one. + However, `JSONObject$1` is an anonymous class not provided by `android.jar` because its class `JSONObject` is an empty stub, and thus, does not use `JSONObject$1`. + Thus, this class falls in the category of hidden #platc. +All these hidden shadow classes are libraries included by the developers who probably did not know that they were already embedded in Android. +] + +=== Shadowing in Malware Applications + +#figure( + ```java + public class Reflection { + private static final int ERROR_SET_APPLICATION_FAILED = -20; + private static final String TAG = "Reflection"; + // ... + + static { + try { + Method declaredMethod = Class.class.getDeclaredMethod("forName", String.class); + Method declaredMethod2 = Class.class.getDeclaredMethod("getDeclaredMethod", String.class, Class[].class); + Class cls = (Class) declaredMethod.invoke(null, "dalvik.system.VMRuntime"); + Method method = (Method) declaredMethod2.invoke(cls, "getRuntime", null); + setHiddenApiExemptions = (Method) declaredMethod2.invoke(cls, "setHiddenApiExemptions", new Class[]{String[].class}); + sVmRuntime = method.invoke(null, new Object[0]); + } catch (Throwable th) { Log.e(TAG, "reflect bootstrap failed:", th); } + System.loadLibrary("free-reflection"); + // ... + } + // ... + } + ```, + caption: [Implementation of Reflection found un classes11.dex (shadows @lst:cl-refl1)], +) + +#figure( + ```java + public class Reflection { + private static final String DEX = "ZGV4CjAzNQCl4EprGS2pXI/v3OwlBrlfRnX5rmkKVdN0CwAAcA ... AoAAA=="; + private static final String TAG = "Reflection"; + + private static native int unsealNative(int i); + + public static int unseal(Context context) { + return (Build.VERSION.SDK_INT < 28 || BootstrapClass.exemptAll() || unsealByDexFile(context)) ? 0 : -1; + } + + private static boolean unsealByDexFile(Context context) { + // Decode DEX from base64 and load it as bytecode. + // ... + } + // ... + } + ```, + caption: [Implementation of Reflection executed by ART (shadowed by @lst:cl-refl2], +) + +The last column of @tab:cl-shadow shows the proportion of applications considered as malware because we arbitrarily fixed a threshold of 3 positive detections from VirusTotal reports. +For the whole dataset, we have 0.53% of applications considered as malware. +We can see that an application that uses self-shadowing is 10 times more likely to be a malware, when the proportion of malware among application shadowing #platc is the same as in the rest of the dataset. +Thus, we manually reversed self-shadowing malware, and found that the self-shadowing does not look to be voluntary. +The colliding classes are often the same implementation, occasionally with minor differences, like different versions of a library. +Additionally, we noticed multiple times internal classes from `com.google.android.gms.ads` colliding with each other, but we believe that it is due to bad processing during the compilation of the application. + +// Nom de l'app: ShareCRM, mais ca a l'air d'exister sur le store donc on va eviter un process et pas la nommer +// https://play.google.com/store/apps/details?id=com.facishare.fsplay&hl=en + +The most notable case we found was an application that still exists on the Google Play Store with the same package name#footnote[SHA256: `C46A65EA1A797119CCC03C579B61C94FE8161308A3B6A8F55718D6ADAD112546`]. This application contains a self-shadow class `me.weishu.reflection.Reflection` that can be found in github, in the repository `tiann/FreeReflection`#footnote[https://github.com/tiann/FreeReflection]. This class is used to disable Android restrictions on hidden API. +At first glance, we believed the shadowing to be done voluntarily for obfuscation purposes. + The shadow class that would be seen by a reverser is given in @lst:cl-refl2: it contains some Java bytecode performing reflection and loading a native library named "free-reflection" (the associated `.so` is missing). + The shadowed class that is really executed is summarized in @lst:cl-refl1. + It contains a more obfuscated code: a `DEX` field storing base64 encoded DEX bytecode that is later used to load some new code. + When looking at this new code stored in the field, we found that it does almost the same thing as the code in the shadow class. + Thus, we believe that the developer has upgraded their obfuscation techniques, replacing a native library by inline base64 encoded bytecode. + The shadow attack could be unintentional, but it strengthens the masking of the new implementation. + + +As a conclusion, we observed that: +- SDK shadowing is performed by #shadowsdk of applications but are unintentional: these classes are embedded for retro-compatibility purpose or because the developer added a library already present in Android; +- Hidden shadowing rarely occurs and is mainly due to the usage of libraries that Android already contains; +- Malware perform more self-shadowing than goodware applications, and we found a sample where self-shadowing would clearly mislead the reverser. + diff --git a/papers/4_class_loader/5_ttv.typ b/papers/4_class_loader/5_ttv.typ new file mode 100644 index 0000000..a6eeb87 --- /dev/null +++ b/papers/4_class_loader/5_ttv.typ @@ -0,0 +1,13 @@ +== Threat to Validity + +During the analysis of the ART internals, we made the hypothesis that its different operating modes are equivalent: we analyzed the loading process for classes stored as non-optimized `.dex` format, and not for the pre-compiled `.oat`. +It is a reasonable hypothesis to suppose that the two implementations have been produced from the same algorithm using two compilation workflows. +Similarly, we assumed that the platform classes stored in `boot.art` are the same as the ones in `BOOTCLASSPATH`. +We confirm empirically our hypothesis on an Android Emulator, but we may have missed some edge cases. + +The comparison of Smali code can lead to underestimated values, for example, if the compilation process performs minor modifications such as instruction reordering. +The ratios reported in this study for the comparison of code are thus a lower bound and would be higher with a more precise comparison. +In addition, platform classes are stored differently in older versions of Android and could not be easily retrieved. +For this reason, we did not compared the classes found in applications to their versions older than SDK 32 to avoid producing unreliable statistics for those versions. + + diff --git a/papers/4_class_loader/6_conclusion.typ b/papers/4_class_loader/6_conclusion.typ new file mode 100644 index 0000000..363eb87 --- /dev/null +++ b/papers/4_class_loader/6_conclusion.typ @@ -0,0 +1,16 @@ +#import "X_var.typ": * + +== Conclusion + +This paper has presented three shadow attacks that allow malware developers to fool static analysis tools when reversing an Android application. +By including multiple classes with the same name or by using the same name as a class of the #Asdk, the developer can mislead a reverser or impact the result of a flow analysis, such as the ones of Androguard or Flowdroid. + +We explored if such shadow attacks are present in as dataset of #nbapk applications . +We found that on average, #shadowsdk of applications are shadowing the SDK, mainly for retro-compatibility purposes and library embedding. +More suspiciously, #shadowhidden of applications are shadowing a hidden class, which could lead to unexpected execution as these classes can appear/disappear with the evolution of Android internals. +Investigations for applications that defined classes multiple times suggest that the compilation process or the inclusion of different versions of the same library is the main explanation. +Finally, when investigating malware samples, we found a specific sample containing a shadow attack that would hide a part of the critical code from a reverser studying the application. + +Future work concerns the correctness of bytecode analysis. +For now, we rely on the Smali representation of the bytecode but the compilation process makes this comparison difficult. +We intend to better parse the bytecode to summarize it and be able to have a more reliable comparison method. diff --git a/papers/4_class_loader/X_var.typ b/papers/4_class_loader/X_var.typ new file mode 100644 index 0000000..b825056 --- /dev/null +++ b/papers/4_class_loader/X_var.typ @@ -0,0 +1,43 @@ +#import "../lib.typ": num + +#let Asdkc = [Android SDK classes] +#let Asdk = [Android SDK] +#let nbapk = num(49975) +#let hidec = [hidden classes] +#let hidecsingular = [hidden class] +#let platc = [platform classes] +#let dexfile = [`.dex` file] +#let dexfiles = [`.dex` files] +#let shadowsdk = [23.52%] +#let shadowhidden = [3.11%] + +#let ko = sym.times +#let ok = sym.circle.filled +#let warn = sym.circle.stroked.small + +#let scan_50k = csv( + "data/results_50k.csv", + delimiter: ",", + row-type: dictionary, +) +#let scan_only_shadow = csv( + "data/results_only.csv", + delimiter: ",", + row-type: dictionary, +) + +#let redef_sdk_7minus = csv( + "data/redef_sdk_7minus.csv", + delimiter: ",", + row-type: dictionary, +) +#let redef_sdk_8 = csv( + "data/redef_sdk_8.csv", + delimiter: ",", + row-type: dictionary, +) +#let redef_sdk_16 = csv( + "data/redef_sdk_16.csv", + delimiter: ",", + row-type: dictionary, +) diff --git a/papers/4_class_loader/data/redef_sdk_16.csv b/papers/4_class_loader/data/redef_sdk_16.csv new file mode 100644 index 0000000..470d177 --- /dev/null +++ b/papers/4_class_loader/data/redef_sdk_16.csv @@ -0,0 +1,11 @@ +class,occ,id,idper +Landroid/annotation/SuppressLint;,2634,2594,98.48 +Landroid/annotation/TargetApi;,2634,2594,98.48 +Landroid/media/MediaCodec$CryptoException;,11,2,18.18 +Landroid/media/MediaCryptoException;,10,2,20.0 +Landroid/view/accessibility/AccessibilityNodeProvider;,9,0,0.0 +Landroid/view/ActionProvider$VisibilityListener;,8,1,12.5 +Landroid/app/Notification$BigTextStyle;,7,0,0.0 +Landroid/app/Notification$Style;,7,0,0.0 +Landroid/util/LongSparseArray;,7,0,0.0 +Landroid/media/MediaPlayer$TrackInfo;,7,0,0.0 diff --git a/papers/4_class_loader/data/redef_sdk_7minus.csv b/papers/4_class_loader/data/redef_sdk_7minus.csv new file mode 100644 index 0000000..cd8e28c --- /dev/null +++ b/papers/4_class_loader/data/redef_sdk_7minus.csv @@ -0,0 +1,11 @@ +class,occ,id,idper +Lorg/apache/http/params/HttpParams;,1318,1292,98.03 +Lorg/apache/http/params/HttpConnectionParams;,1202,60,4.99 +Lorg/apache/http/conn/ConnectTimeoutException;,1200,420,35.0 +Lorg/apache/http/params/CoreConnectionPNames;,1190,1189,99.92 +Lorg/xmlpull/v1/XmlPullParser;,1111,584,52.57 +Lorg/apache/http/conn/scheme/SocketFactory;,1074,940,87.52 +Lorg/apache/http/conn/scheme/HostNameResolver;,1072,939,87.59 +Lorg/apache/http/conn/scheme/LayeredSocketFactory;,963,861,89.41 +Lorg/json/JSONException;,945,0,0.0 +Lorg/apache/http/conn/ssl/X509HostnameVerifier;,886,7,0.79 diff --git a/papers/4_class_loader/data/redef_sdk_8.csv b/papers/4_class_loader/data/redef_sdk_8.csv new file mode 100644 index 0000000..a4e1f3d --- /dev/null +++ b/papers/4_class_loader/data/redef_sdk_8.csv @@ -0,0 +1,11 @@ +class,occ,id,idper +Ljavax/xml/namespace/QName;,297,0,0.0 +Ljavax/xml/namespace/NamespaceContext;,226,222,98.23 +Landroid/net/http/SslError;,221,70,31.67 +Lorg/w3c/dom/UserDataHandler;,82,76,92.68 +Ljavax/xml/transform/TransformerConfigurationException;,73,51,69.86 +Ljavax/xml/transform/TransformerException;,73,0,0.0 +Lorg/w3c/dom/ls/LSException;,61,39,63.93 +Lorg/w3c/dom/TypeInfo;,54,48,88.89 +Lorg/w3c/dom/DOMConfiguration;,54,25,46.3 +Ljavax/xml/transform/TransformerFactoryConfigurationError;,52,0,0.0 diff --git a/papers/4_class_loader/data/results_50k.csv b/papers/4_class_loader/data/results_50k.csv new file mode 100644 index 0000000..8aa2949 --- /dev/null +++ b/papers/4_class_loader/data/results_50k.csv @@ -0,0 +1,5 @@ +method,nbapp,avgshadow,median,id,avgtargetsdk,avgminsdk,ratioapp,ratiomal +Self,49975,2.1,0,74.8,32.1,21.7,100.0,0.53 +Sdk,49975,6.5,0,8.04,32.1,21.7,100.0,0.53 +Hidden,49975,0.5,0,17.42,32.1,21.7,100.0,0.53 +Total,49975,9.0,0,23.76,32.1,21.7,100.0,0.53 diff --git a/papers/4_class_loader/data/results_only.csv b/papers/4_class_loader/data/results_only.csv new file mode 100644 index 0000000..e675a69 --- /dev/null +++ b/papers/4_class_loader/data/results_only.csv @@ -0,0 +1,5 @@ +method,nbapp,avgshadow,median,id,avgtargetsdk,avgminsdk,ratioapp,ratiomal +Self,234,438.1,18,74.8,31.4,22.4,0.47,5.98 +Sdk,11755,27.6,5,8.04,32.4,22.0,23.52,0.38 +Hidden,1556,16.1,1,17.42,32.1,22.2,3.11,0.71 +Total,12301,36.7,6,23.76,32.4,22.0,24.61,0.42 diff --git a/papers/4_class_loader/figs/architecture_SDK-crop.svg b/papers/4_class_loader/figs/architecture_SDK-crop.svg new file mode 100644 index 0000000..9d2e7e0 --- /dev/null +++ b/papers/4_class_loader/figs/architecture_SDK-crop.svg @@ -0,0 +1,704 @@ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + diff --git a/papers/4_class_loader/figs/call_graph_expected.svg b/papers/4_class_loader/figs/call_graph_expected.svg new file mode 100644 index 0000000..8e68e94 --- /dev/null +++ b/papers/4_class_loader/figs/call_graph_expected.svg @@ -0,0 +1,506 @@ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + diff --git a/papers/4_class_loader/figs/call_graph_obf.svg b/papers/4_class_loader/figs/call_graph_obf.svg new file mode 100644 index 0000000..7a32a3b --- /dev/null +++ b/papers/4_class_loader/figs/call_graph_obf.svg @@ -0,0 +1,506 @@ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + diff --git a/papers/4_class_loader/figs/classloaders-crop.svg b/papers/4_class_loader/figs/classloaders-crop.svg new file mode 100644 index 0000000..8479330 --- /dev/null +++ b/papers/4_class_loader/figs/classloaders-crop.svg @@ -0,0 +1,608 @@ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + diff --git a/papers/4_class_loader/figs/redef_sdk_relative_min_sdk.svg b/papers/4_class_loader/figs/redef_sdk_relative_min_sdk.svg new file mode 100644 index 0000000..f3d32dd --- /dev/null +++ b/papers/4_class_loader/figs/redef_sdk_relative_min_sdk.svg @@ -0,0 +1,1281 @@ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + diff --git a/papers/4_class_loader/main.typ b/papers/4_class_loader/main.typ new file mode 100644 index 0000000..413b5eb --- /dev/null +++ b/papers/4_class_loader/main.typ @@ -0,0 +1,13 @@ +#import "../lib.typ": todo, epigraph + += Class Loaders in the Middle: Confusing Android Static Analyzers + +#epigraph("Esmerelda Weatherwax, Wyrd Sisters, Terry Pratchett")[Things that try to look like things often do look more like things than things.] + +#include("0_intro.typ") +#include("1_related_work.typ") +#include("2_classloading.typ") +#include("3_obfuscation.typ") +#include("4_in_the_wild.typ") +#include("5_ttv.typ") +#include("6_conclusion.typ")