StevenArzt
commented
1 week ago This is indeed a highly interesting topic. We have worked on the integration of static and dynamic analysis in a framework built on top of Soot and FlowDroid as part of a recent paper: https://dl.acm.org/doi/pdf/10.1145/3589250.3596146.
By default, FlowDroid relies on the SPARK classgraph constructed by Soot, which performs an under-approximation of the CG. SPARK values precision over recall. You can change the FlowDroid configuration to use CHA instead if you want a coarse over-approximation.
SPARK works by propagating types from allocation sites to call sites. Take the following example:
List l = new ArrayList();
l.add(x);In this example, the declared type at the call site for add is List. This type is an interface, i.e., there is no method implementation List.add(). CHA would now assume that the add methods in all concrete classes that implement List may be potential callees. SPARK, on the other hand, propagates the actual type ArrayList to the call site and restricts the callees to ArrayList.add().
While this approach is quite precise, it may lead to false negatives when the type is unknown, e.g., because the allocation site is in a factory method that is unavailable. For example, when obtaining an Android system service such as TelephonyManager, there is no allocation site in the codebase that is available to Soot. Hence, calls to methods such as getDeviceId() will be missing from the callgraph. FlowDroid deals with the incomplete CG using its StubDroid summaries. In other word, it doesn't matter much that thee CG is incomplete. If there is no callee for a call, but there is a data flow summary, the data flow tracking still works.
KyleLeith-007
Dear developers,
I hope this message finds you well. Firstly, I would like to express my appreciation for your excellent work on the Soot-FlowDroid module. It has been instrumental in my recent analysis tasks.
I have encountered several challenges related to the call graph constructed by Flowdroid. Specifically, I am facing difficulties in utilizing dynamic analysis results to enhance the static analysis performed by Flowdroid.
My objective is to capture certain function call relationships through dynamic analysis and subsequently integrate these call edges into the call graph generated by Flowdroid, potentially enriching the information provided. To achieve this, I have developed a dynamic analyzer that captures the call stack of sensitive APIs invoked during the dynamic runtime of an APK. For instance, for a sensitive function SAPI, I obtained the following call stack: main_func1 -> main_func2 -> tpl-func3 -> SAPI (where 'main' denotes functions within the main program, and 'tpl' indicates functions within a third-party library).
My next step involves incorporating the call chain information into the call graph constructed by Flowdroid. Specifically, I aim to add all the call edges from the aforementioned call chain into the Flowdroid call graph. However, I have encountered an issue: many call edges captured dynamically do not appear in the call graph derived from static analysis, and numerous function nodes are missing from the call graph. I am particularly interested in understanding the reasons behind this discrepancy, especially for nodes that should be present in the call graph.
I seek guidance on how to dynamically add these missing nodes and edges to the Flowdroid call graph. Could you kindly advise me on the best approach to achieve this?
Thank you for your attention to this matter. I appreciate your efforts in developing and maintaining such a valuable tool.
Best regards