Can SPARK ignore library class？ #584

moonZHH · 2016-04-29T14:35:05Z

@StevenArzt
Hi!
As I see, cg.cha has the phase option "AppOnly" to reduce the call graph edges within library classes. But it seems that there is not any similar options in cg.spark to implement the same function as "AppOnly" does, am I right?

StevenArzt · 2016-04-29T14:36:16Z

You can use the -no-bodies-for-excluded option to ensure that Soot never loads the bodies of the excluded classes. In that case, SPARK cannot look into them either.

moonZHH · 2016-04-29T14:56:06Z

@StevenArzt
The initializeSoot() function in soot-infoflow-android/.../SetupApplication.java already set the -no-bodies-for-excluded option through "Options.v().set_no_bodies_for_excluded(true);", but actually the call graph still contains some edges within library classes, such as:
VIRTUAL edge: $r1 = virtualinvoke $r0.android.support.v7.app.AppCompatActivity: android.support.v7.app.AppCompatDelegate getDelegate()() in android.support.v7.app.AppCompatActivity: void onDestroy() ==> android.support.v7.app.AppCompatActivity: android.support.v7.app.AppCompatDelegate getDelegate()
CLINIT edge: $r1 = staticinvoke android.support.v7.app.AppCompatDelegate: android.support.v7.app.AppCompatDelegate create(android.app.Activity,android.support.v7.app.AppCompatCallback)($r0, $r0) in android.support.v7.app.AppCompatActivity: android.support.v7.app.AppCompatDelegate getDelegate() ==> android.support.v7.app.AppCompatDelegate: void clinit()
STATIC edge: $r1 = staticinvoke android.support.v7.app.AppCompatDelegate: android.support.v7.app.AppCompatDelegate create(android.app.Activity,android.support.v7.app.AppCompatCallback)($r0, $r0) in android.support.v7.app.AppCompatActivity: android.support.v7.app.AppCompatDelegate getDelegate() ==> android.support.v7.app.AppCompatDelegate: android.support.v7.app.AppCompatDelegate create(android.app.Activity,android.support.v7.app.AppCompatCallback)
......

moonZHH · 2016-04-29T14:59:24Z

Here is the apk file.
Library23Check.zip

StevenArzt · 2016-04-29T16:15:57Z

These are not actually library classes according to Soot's definition. They are rather application classes, because these support classes are compiled into the APK file. I have an idea on what to do there. I will commit it together with a couple of other things I'm currently improving once that's ready.

moonZHH · 2016-04-30T01:06:04Z

@StevenArzt
Thanks! I am looking forward to your commitment.

StevenArzt · 2016-04-30T22:24:42Z

Can you try the new version? It should ignore the android classes now.

moonZHH · 2016-05-01T06:25:13Z

@StevenArzt
Hi!
Thanks, but it seenms that library classes still remains in the call graph.
Here is my test apk and its call graph.
Library23Check.zip
CallGraph2.txt

StevenArzt · 2016-05-02T11:50:53Z

That was indeed tougher than I first thought. Please update Soot and soot-infoflow-android. When computing the callgraph, make sure to set the appropriate options. The following code snippet works for me with the new version:

        SetupApplication app = new SetupApplication
                    ("D:/Tools/adt-bundle-windows-x86_64-20140321/sdk/platforms",
                    "D:\\Arbeit\\APKs\\Library23Check.apk");
        app.calculateSourcesSinksEntrypoints("D:/Arbeit/Android Analyse/soot-infoflow-android/SourcesAndSinks.txt");

        soot.G.reset();

        Options.v().set_src_prec(Options.src_prec_apk);
                Options.v().set_process_dir(Collections.singletonList("D:\\Arbeit\\APKs\\Library23Check.apk"));
        Options.v().set_android_jars("D:/Tools/adt-bundle-windows-x86_64-20140321/sdk/platforms");
        Options.v().set_whole_program(true);
        Options.v().set_allow_phantom_refs(true);
        Options.v().set_output_format(Options.output_format_none);
        Options.v().setPhaseOption("cg.spark", "on");
        new SootConfigForAndroid().setSootOptions(Options.v());

        Scene.v().loadNecessaryClasses();
        SootMethod entryPoint = app.getEntryPointCreator().createDummyMain();
        entryPoint.getActiveBody().validate();

        Options.v().set_main_class(entryPoint.getSignature());
        Scene.v().setEntryPoints(Collections.singletonList(entryPoint));

        PackManager.v().runPacks();
        CallGraph cg = Scene.v().getCallGraph();
        for (Iterator<Edge> edgeIt = cg.iterator(); edgeIt.hasNext(); ) {
            Edge e = edgeIt.next();
            System.out.println(e);
        }

StevenArzt · 2016-05-02T15:31:13Z

The soot-infoflow also needs to be updated.

moonZHH · 2016-05-02T17:21:39Z

@StevenArzt
Hi！Thanks a lot, I will try it as soon as possible.
I have got another problem. Why the methods in class "br.com.easytaxi.ui.au" have no active body?
Here is the apk file.
Easy Taxi Book Taxi Cab App.zip

StevenArzt · 2016-05-03T10:24:45Z

This can happen if these methods are not reachable from any entry point. In that case, you need to manually load the bodies using SootMethod.retrieveActiveBody().

StevenArzt · 2016-05-03T11:26:19Z

Update: I tested it and I do have method bodies if I use the code from above and then access that class. So you shouldn't need to manually load it. Did you update soot, soot-infoflow, and soot-infoflow-android?

moonZHH · 2016-05-04T07:19:54Z

@StevenArzt
Hi!
Thanks for your reply! I find that in this issue
(https://github.com/secure-software-engineering/soot-infoflow-android/commit/1231aaa8f657059ecd1db871ac7ee1c74f712de2), you just fix the problem in AndroidSourceSinkManager.java, but the problem still remained in AccessPathBasedSourceSinkManager.java

StevenArzt · 2016-05-04T09:53:24Z

Should be fixed with secure-software-engineering/soot-infoflow-android@397ddb94f8f13358fd01d1b0e47f76af8ce30d62. Thanks for reporting!

moonZHH · 2016-05-04T14:25:58Z

@StevenArzt
Hi!
I am confused why the call graph constructed in file https://gist.github.com/njupt-moon/388ff6fd9ecdf1b4c8b2bfb741f71468 (from line 436 to line 446) is different from the call graph constructed in file https://gist.github.com/njupt-moon/f960a0dafa1866e4329af55497fbb7ea (from line 222 to 232). The test file is https://github.com/Sable/soot/files/245574/Easy.Taxi.Book.Taxi.Cab.App.zip

StevenArzt · 2016-05-04T15:54:45Z

Slight differences are expected, because the Infoflow class also patches some classes to add support for threads, handlers, etc. These aspects are not yet considered in what SetupApplication computes. Aside from that, the two callgraphs should be similar. Is there anything concrete missing from one of the se callgraphs that is present in the other one?

moonZHH · 2016-05-05T01:48:15Z

@StevenArzt
Here is the two call graph. File (https://gist.github.com/njupt-moon/0f2cb82c5f8fbb246db34f8015971180) is generated by the SetupApplication.java, and file (https://gist.github.com/njupt-moon/b278e93a09345e19245d1e3becd45b35) is generated by the Infoflow.java. I found that the edge STATIC edge: $i1 = staticinvoke android.support.v4.app.ActivityCompat: int checkSelfPermission(android.content.Context,java.lang.String) ($r0, $r2) in br.com.easytaxi.ui.WelcomeActivity: boolean b() ==> android.support.v4.content.ContextCompat: int checkSelfPermission(android.content.Context,java.lang.String) in Callgraph_SetupApplication.txt is a bit different from the edge STATIC edge: $i1 = staticinvoke android.support.v4.app.ActivityCompat: int checkSelfPermission(android.content.Context,java.lang.String) ($r0, $r2) in br.com.easytaxi.ui.WelcomeActivity: boolean b() ==> android.support.v4.app.ActivityCompat: int checkSelfPermission(android.content.Context,java.lang.String). Actually these two edges need to be the same. Here class android.support.v4.app.ActivityCompat is inherented from class android.support.v4.content.ContextCompat, so the function android.support.v4.app.ActivityCompat: int checkSelfPermission(android.content.Context,java.lang.String) is an inherent function.

moonZHH · 2016-05-08T15:14:27Z

@StevenArzt
Hi!
FlowDroid does not consider fragment's lifecycle, is it right?

StevenArzt · 2016-05-12T20:34:33Z

@njupt-moon FlowDroid currently does not support fragments, but we will hopefully add this feature soon. Concerning the callgraphs, I have to look into it more closely before I can give you an answer.

moonZHH · 2016-05-20T15:10:04Z

@StevenArzt
Thanks, it will help me a lot.
Btw, I want to retrieve all the class in android sdk (it does not means the android APIs used by an application, but all the APIs in android.jar which is loaded by Options.v().set_android_jars() function). Firstly, I generate an almost blank apk with only onCreate() function, then I use Flowdroid to analyze it. I try to get all the classes by using Scene.v().getClasses() after Scene.v().loadNecessaryClasses() has been executed, but unfortunately the classes I get do not cover all the classes in android.jar. Does it means that loadNecessaryClasses() only loads parts of the APIs in android.jar?

StevenArzt · 2016-06-02T14:28:33Z

If you just want to enumerate all the Android API methods in the android.jar file, why don't you just run Soot on the JAR alone as a normal Java library? You don't need the Dalvik frontend in this case since you are only interested in the library which is pure Java. Just put it in the process-dir and change the src-prec to Java classes.

gianlucascoccia · 2016-11-04T17:53:21Z

I would like to do the exact opposite, find all classes that call a method in android.support.v4.app.ActivityCompat. Still, it seems to me that soot does not list this class neither in Scene.v().getLibraryClasses() or Scene.v().getApplicationClasses() .
Any way I can fix this?
@StevenArzt

pavanupb · 2020-07-27T12:41:50Z

@njupt-moon Please re-open if this is still relevant.

StevenArzt added the question label Apr 29, 2016

pavanupb closed this as completed Jul 27, 2020

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Can SPARK ignore library class？ #584

Can SPARK ignore library class？ #584

moonZHH commented Apr 29, 2016

StevenArzt commented Apr 29, 2016

moonZHH commented Apr 29, 2016 •

edited

moonZHH commented Apr 29, 2016

StevenArzt commented Apr 29, 2016

moonZHH commented Apr 30, 2016

StevenArzt commented Apr 30, 2016

moonZHH commented May 1, 2016

StevenArzt commented May 2, 2016

StevenArzt commented May 2, 2016

moonZHH commented May 2, 2016 •

edited

StevenArzt commented May 3, 2016

StevenArzt commented May 3, 2016

moonZHH commented May 4, 2016

StevenArzt commented May 4, 2016

moonZHH commented May 4, 2016 •

edited

StevenArzt commented May 4, 2016

moonZHH commented May 5, 2016 •

edited

moonZHH commented May 8, 2016

StevenArzt commented May 12, 2016

moonZHH commented May 20, 2016

StevenArzt commented Jun 2, 2016

gianlucascoccia commented Nov 4, 2016 •

edited

pavanupb commented Jul 27, 2020

Can SPARK ignore library class？ #584

Can SPARK ignore library class？ #584

Comments

moonZHH commented Apr 29, 2016

StevenArzt commented Apr 29, 2016

moonZHH commented Apr 29, 2016 • edited

moonZHH commented Apr 29, 2016

StevenArzt commented Apr 29, 2016

moonZHH commented Apr 30, 2016

StevenArzt commented Apr 30, 2016

moonZHH commented May 1, 2016

StevenArzt commented May 2, 2016

StevenArzt commented May 2, 2016

moonZHH commented May 2, 2016 • edited

StevenArzt commented May 3, 2016

StevenArzt commented May 3, 2016

moonZHH commented May 4, 2016

StevenArzt commented May 4, 2016

moonZHH commented May 4, 2016 • edited

StevenArzt commented May 4, 2016

moonZHH commented May 5, 2016 • edited

moonZHH commented May 8, 2016

StevenArzt commented May 12, 2016

moonZHH commented May 20, 2016

StevenArzt commented Jun 2, 2016

gianlucascoccia commented Nov 4, 2016 • edited

pavanupb commented Jul 27, 2020

moonZHH commented Apr 29, 2016 •

edited

moonZHH commented May 2, 2016 •

edited

moonZHH commented May 4, 2016 •

edited

moonZHH commented May 5, 2016 •

edited

gianlucascoccia commented Nov 4, 2016 •

edited