How to obtain source component and target component for ICC methods

[tanjina12]

How can I extract the source and target component of an ICC method with FlowDroid?
Currently, I have a call graph, which I can traverse in order to retrieve the source and destination Soot method.

Here is my code :

I want to extract source and target component for all ICC methods and store them into a file for further processing. But, how to extract the communication between different components of ICC based methods? For example, If Activity1 contains an ICC method called startActivity which will trigger a second activity called Activity2, how can I obtain the source and target components(i.e. Activity1, Activty2) in this case? Is it possible to get this information from the call graph or do I need something else?

I checked the classes in the iccta directory but could not figure out a way.
Could you please give me some example.

Thank you.

[StevenArzt]

FlowDroid takes the inter-component mappings an external input (the "ICC model"). Therefore, your question is on data that FlowDroid does not generate, but which it rather consumes. The mapping between Activity1 and Activity2 in your example is defined in the iccModelPath file that you supply in line 59.

FlowDroid uses this data to extend its callgraph such that the call to startActivity() also triggers the lifecycle dummy main method of the target component. In other words, FlowDroid transforms ICC calls into normal method calls to then run its normal data flow propagation over an interprocedural control flow graph (ICFG).

[tanjina12]

Thank you for the detailed explanation. I utilized the IC3 tool to generate the ICC model with the option --protobuf, which is required by FlowDroid for inter-component analysis.

And FlowDroid uses ICCTA to perform inter-component data flow analysis. Whereas ICCTA, leverages IC3 tool to obtain ICC methods and their parameter values. Then, IccTA identifies the target components(Activity, Service, Content Provider, Broadcast Receiver) by simply analyzing the Manifest file and/or the bytecode. After that, it performs the matching of ICC methods with their target components. So, does that mean the entire process of ICC link extraction(including the mapping) for IccTA can be done by utilizing IC3?

I was wondering maybe the the mapping for component transition is done solely by IccTA using the information from the generated ICC model. Hence, if I need to retrieve the component transition information using Flowdroid(with IccTA) will it be suffice to use the ICC model?

Thank you once again.

[StevenArzt]

IC3 extracts Intent data from Android apps. For each intent that is sent inside the app, it tries to discover the values of all fields inside the intent that are relevant for dispatch. In the case of an explicit intent, this looks as follows:

  exit_points {
    instruction {
      statement: "virtualinvoke r0.<edu.mit.icc_service_messages.ActivityMessenger: boolean bindService(android.content.Intent,android.content.ServiceConnection,int)>($r1, $r2, 1)"
      class_name: "edu.mit.icc_service_messages.ActivityMessenger"
      method: "<edu.mit.icc_service_messages.ActivityMessenger: void onStart()>"
      id: 5
    }
    kind: SERVICE
    intents {
      attributes {
        kind: CLASS
        value: "edu/mit/icc_service_messages/MessengerService"
      }
      attributes {
        kind: PACKAGE
        value: "edu.mit.icc_service_messages"
      }
    }
  }

For an implicit intent, there is no target class name, but rather an action or type:

  exit_points {
    instruction {
      statement: "virtualinvoke r0.<edu.mit.icc_action_string_operations.OutFlowActivity: void startActivity(android.content.Intent)>(r8)"
      class_name: "edu.mit.icc_action_string_operations.OutFlowActivity"
      method: "<edu.mit.icc_action_string_operations.OutFlowActivity: void onCreate(android.os.Bundle)>"
      id: 12
    }
    kind: ACTIVITY
    intents {
      attributes {
        kind: ACTION
        value: "(.*)"
      }
      attributes {
        kind: EXTRA
        value: "DroidBench"
      }
    }
  }

What you then need is a resolving algorithm that maps the intent properties to the component and intent filter definitions inside the app. This mapping is nontrivial, and you might want to reuse the existing ICCTA code from class soot.jimple.infoflow.android.iccta.App, especially method Intent.resolve(). This also saves you from having to implement your own parser for the IC3 file format, because everything is already in the FlowDroid code. Still, it's individual components you need to combine, because you don't need all the other data flow-related stuff that FlowDroid provides.

[tanjina12]

Thank you for your answer. Yes, I was thinking about implementing a mapping algorithm to resolve the components from the ICC model. Thanks for pointing me out where to look at. It will be really helpful. I will have a look into it.

[tanjina12]

Hi @StevenArzt, I was wondering as IccTA provides support for Content Provider, how to identify the target component in case of content provider related methods(e.g. query)? Because I tried to retrieve the source and target component of ICC method call and was able to do so for Activities, Services and Receivers as well but couldn't get to retrieve Content Provider yet!

First, I included the required classes of iccta package(e.g. App, IC3ResultLoader etc.) into my own project.
In order to resolve the components when I tried to extract the ICCLinks using getIccLinks() of Ic3Provider class, it always gives null value from this SootMethod fromSM = Scene.v().grabMethod(intent.getLoggingPoint().getCallerMethodSignature()) SootMethod. Probably, it is because I am not using the callgraph or any dummy main method as an entry point but I don't know exactly! I am also getting null value from this Scene.v().getSootClassUnsafe(targetComp.getName()) function as well. So, I modified the getIccLinks() method using the following code snippet instead of calling the Soot methods for constructing the ICC Link. Is it okay to do so?

String callerMethod = intent.getLoggingPoint().getCallerMethodSignature();
String callerComp = callerMethod.substring(1, callerMethod.indexOf(":"));
String calleeMethod = intent.getLoggingPoint().getCalleeMethodSignature();
String iccMethod = calleeMethod.substring(calleeMethod.indexOf(":") + 1, calleeMethod.indexOf(">"));
String calleeComp = targetComp.getName();
ComponentTransition componentTransition = new ComponentTransition(callerComp, iccMethod, calleeComp);
componentTransitions.add(componentTransition);

It worked fine though and I was able to detect caller component and callee component names for Activities, Services and Receivers. However I couldn't identify the target component for content provider.

While checking out the codes I noticed that in the Ic3ResultLoader.load(iccModelPath) method, it iterates over the ExitPoint IntentList in this for (ExitPoint.Intent intent : exitPoint.getIntentsList()) for loop which will fail to detect the ExitPoint.Uri for the following iccModel as it did not extract the exitPoint.getUrisList(). Do you have the checking for ExitPoint Uri in somewhere else? Or am I missing something because I know it has lots of dependency!

exit_points {
    instruction {
      statement: "r3 = virtualinvoke r4.<android.content.ContentResolver: android.database.Cursor query(android.net.Uri,java.lang.String[],java.lang.String,java.lang.String[],java.lang.String)>(r2, null, null, null, null)"
      class_name: "lu.uni.serval.icc_query1.OutFlowActivity"
      method: "<lu.uni.serval.icc_query1.OutFlowActivity: void onCreate(android.os.Bundle)>"
      id: 6
    }
    kind: PROVIDER
    uris {
      attributes {
        kind: URI
        value: "content://lu.uni.serval.icc_query1/deviceid"
      }
    }
  }

I generated the iccModels using Ic3 for InterCompCommunication_query1 and InterCompCommunication_insert1 apk from Droidbench-iccta github repo. But apparently, they don't have any intent-filter values to match. Along with this, I also tried to test it using the iccModel for ContentProvider1 from Droidbench-master repo. But could not resolve the target component. Do you have any sample iccModel that is already being tested and can successfully resolve the Content Providers? Or should I need to include something else as well to retrieve all four types of Components correctly?

Thanks in advance.