Is there a switch that can disable all the logging outputs? about flowdroid HOT 7 CLOSED

Since version 2.5, FlowDroid uses slf4j for its outputs. Soot has been ported to slf4j as well very recently. If you use the newest development version of Soot and FlowDroid 2.5 or newer, you should be able to configure the output using either a custom slf4j implementation module, or by linking against log4j (slf4j binding for log4j) and then providing a log4j configuration file.

There is only one exception, which is the generated dummy main methods. The current development version prints these methods to the standard output for debugging purposes. This output will be removed before the next release. If you want to use the develop branch, you can just comment it out inside the AbstractComponentEntryPointCreator class.

from flowdroid.

Thank you very much. I will give the newest development version a try.

from flowdroid.

@StevenArzt

Besides the one I've asked before, I came across some other questions (I have asked once in the email list, but got no replies), so I state them here.

1. How to get source filenames in FlowDroid/soot? I want to show names of the sources files to users of my tool, but I have no idea how to get them in FlowDroid/soot. I’ve tried someMethod.getTag(“SourceFileTag”).getName(), but every time I invoked it, a nullpointer got returned. Did I miss some configuration options, or it is a challenge to get the filename just from the analyzed apk?
2. The call graph I got is always incomplete, which leads to the incomplete ICFG, and continually leads to my incomplete static backward slicing. I know that it is impossible to get the complete call graph using static analysis (according to the undecidable problem). But are there some ways to get a backward slicing using FlowDroid or Soot (I've writern my own one, but it is far from my acceptance) ?

Thank u very much!

from flowdroid.

The source file name is only available if the respective debug information was compiled into the target class files by the original compiler. I don't think such information is available for APKs.

Do you have a concrete issue where the interprocedural control flow graph is incomplete? In my experience, this icfg is quite reliable. Since we use SPARK by default, we inherit the requirements of SPARK. We, for example, only get callgraph edges if type information can be propagated from the allocation node of the respective base object to the call site. For cases in which this is not possible, e.g., because the call site is hidden inside a factory method inside the Android framework, FlowDroid relies on explicit library models generated by StubDroid. In fact, we have a (closed source) backward slicer based on FlowDroid and Soot that we have created for a different research project.

from flowdroid.

Thanks for your reply.

Here is my scenario (maybe just as you said, the call site is hidden inside Android Framework, but honestly, I cannot clearly understand what the allocation node of the respective base object is in your reply ;-( ):

I have a BroadcastReceiver (already registered in AndroidManifest.xml) which receives some broadcast (e.g. the net BOOT_COMPLETED) of the system. And inside the lifecycle method onReceive of the receiver, a method android.net.ConnectivityManager.getBackgroundDataSetting is invoked. The following codes shows this scenario:

public class ServiceStarter extends BroadcastReceiver {
        // ...

	@Override
	public void onReceive(Context ctx, Intent intent) {
		// ... 
		startService(ctx, dbAdapter);
		// ...
	}
	
	public static void startService(Context ctx, ParcelDbAdapter dbAdapter) {
		// ...
                startService(ctx, dbAdapter, interval);
	}

	public static void startService(Context ctx, ParcelDbAdapter dbAdapter, long interval) {
		// ...
		@SuppressWarnings("deprecation")
		boolean backgroundDataAllowed = cm.getBackgroundDataSetting();  // here is the call site
                // ...
	}
       
       // ...
}

In the above scenario, the call site I commented in startService cannot be accessed by the call graph (using Scene.v().getCallGraph().edgesInto(<the signature>)) built-in soot. I am quite sure that <the signature> I used is correct, because I traversed all the classes' methods' units and got that call site using <the signature>.

Do u have some suggestions for me?

BTW, I am a novice in soot/FlowDroid, even in java static analysis. And I would appreciate if u can give me some hints on how to implement a relatively precise backward slicer?

from flowdroid.

@StevenArzt As you suggest, I checked out to the development branch, i.e. 2.6-SNAPSHOT, and replaced the output statement with logger.debug in class AbstractComponentEntryPointCreator the very recently (a long time... since I asked you last time). I repackaged it and add it to my local maven repo using the maven install plugin, like,

<execution>
    <id>install-soot-infoflow-android</id>
    <goals>
        <goal>install-file</goal>
    </goals>
    <phase>validate</phase>
    <!-- dependency: soot-infoflow-android -->
    <configuration>
        <groupId>de.tud.sse</groupId>
        <artifactId>soot-infoflow-android</artifactId>
        <version>2.6-SNAPSHOT</version>
        <packaging>jar</packaging>
        <file>${basedir}/dependencies/soot-infoflow-android/soot-infoflow-android.jar</file>
        <generatePom>false</generatePom>
        <pomFile>${basedir}/dependencies/soot-infoflow-android/pom.xml</pomFile>
    </configuration>
</execution>

As shown above, the <pomFile> is the exact pom.xml in your soot-infoflow-android project.

But when I packaged them into a jar-with-dependence file, the following errors are complained,

[main] INFO soot.jimple.infoflow.android.SetupApplication - Initializing Soot...
[main] INFO soot.jimple.infoflow.android.SetupApplication - Loading dex files...
Exception in thread "main" java.lang.NoClassDefFoundError: com/google/common/collect/RangeMap
	at java.lang.Class.getDeclaredMethods0(Native Method)
	at java.lang.Class.privateGetDeclaredMethods(Class.java:2701)
	at java.lang.Class.privateGetMethodRecursive(Class.java:3048)
	at java.lang.Class.getMethod0(Class.java:3018)
	at java.lang.Class.getMethod(Class.java:1784)
	at java.lang.Class.getEnumConstantsShared(Class.java:3311)
	at java.lang.System$2.getEnumConstantsShared(System.java:1249)
	at java.util.EnumMap.getKeyUniverse(EnumMap.java:754)
	at java.util.EnumMap.<init>(EnumMap.java:138)
	at org.jf.dexlib2.Opcodes.<init>(Opcodes.java:90)
	at org.jf.dexlib2.Opcodes.forApi(Opcodes.java:59)
	at soot.dexpler.DexFileProvider.mappingForFile(DexFileProvider.java:161)
	at soot.dexpler.DexFileProvider.updateIndex(DexFileProvider.java:142)
	at soot.dexpler.DexFileProvider.getDexFromSource(DexFileProvider.java:85)
	at soot.dexpler.DexFileProvider.getDexFromSource(DexFileProvider.java:72)
	at soot.DexClassProvider.buildDexIndex(DexClassProvider.java:94)
	at soot.DexClassProvider.ensureDexIndex(DexClassProvider.java:73)
	at soot.DexClassProvider.find(DexClassProvider.java:55)
	at soot.SourceLocator.getClassSource(SourceLocator.java:173)
	at soot.Scene.tryLoadClass(Scene.java:820)
	at soot.Scene.loadBasicClasses(Scene.java:1504)
	at soot.Scene.loadNecessaryClasses(Scene.java:1587)
	at soot.jimple.infoflow.android.SetupApplication.initializeSoot(SetupApplication.java:1115)
	at soot.jimple.infoflow.android.SetupApplication.runInfoflow(SetupApplication.java:1346)
	at soot.jimple.infoflow.android.SetupApplication.runInfoflow(SetupApplication.java:1319)
	at simonlee.elegant.finder.Finder.init(Finder.java:48)
	at simonlee.elegant.finder.Finder.find(Finder.java:23)
	at simonlee.elegant.ELEGANT.run(ELEGANT.java:97)
	at simonlee.elegantcli.CLI.start(CLI.java:170)
	at simonlee.elegantcli.CLI.main(CLI.java:181)
Caused by: java.lang.ClassNotFoundException: com.google.common.collect.RangeMap
	at java.net.URLClassLoader.findClass(URLClassLoader.java:381)
	at java.lang.ClassLoader.loadClass(ClassLoader.java:424)
	at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:349)
	at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
	... 30 more

I've tried to use the google-collect provided in maven as a dependency but it seems that it does not work (another errors on NoSuchMethodException are complained).

Do you have any idea on that?

from flowdroid.

Okay. Today, I rechecked and found the error was caused by conflict version of guava. Closed.

from flowdroid.