Some issues regarding the call graph constructed by flowdroid #748
Comments
|
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: In this example, the declared type at the call site for 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 |
Thank you very much for your response, which has greatly enhanced my understanding of the operating principles of FlowDroid. I will also diligently study the paper you provided in the link. While awaiting your reply, I attempted to modify the parameter configuration of FlowDroid to alter the generated call graph. Based on the cgalgo parameter in the code, I tried using RTA mode to run FlowDroid (I avoided using CHA mode due to the excessive number of edges in the call graph constructed by CHA mode). However, I encountered an issue during this process. FlowDroid produced the following error when analyzing many APKs in RTA mode (though it completed successfully in SPARK mode). Especially when analyzing larger APKs, this issue is more likely to occur. I am very confused about this issue, may it be due to insufficient memory? I would be extremely honored if I could receive your guidance on this issue(Some error logs are as follows): [main] INFO soot.jimple.infoflow.android.SetupApplication$InPlaceInfoflow - Callgraph construction took 0 seconds |
|
CHA and RTA are less commonly used in FlowDroid du to the large number of false positives they produce in the data flow analysis. Your use case is special, so it makes sense to use RTA. When FlowDroid starts, it creates a map between all Jimple units the Jimple bodies in which they are contained. When propagating taints, FlowDroid needs to check whether a given statement is an exit point for its respective method. This requires FlowDroid to obtain the method's control flow graph. In your call stack, the unit at hand is not part of this mapping between units and bodies, which is strange. In line 152 of |
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
The text was updated successfully, but these errors were encountered: