Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

How to import additional jar files #789

Open
lzl-l opened this issue Dec 25, 2024 · 4 comments
Open

How to import additional jar files #789

lzl-l opened this issue Dec 25, 2024 · 4 comments

Comments

@lzl-l
Copy link

lzl-l commented Dec 25, 2024

Dear developers @StevenArzt @t1mlange

I used the Options.v().set_soot_classpath() and config.getAnalysisFileConfig().setAdditionalClasspath() to import the jar files of apps except the apk package into the framework. However, when FlowDroid builds CallGraph and does taint analysis, he analysis results appear to be the same as when only the apk was imported. The jar files I imported seems to be useless, may I ask why? How can I fix it?

My code:

public static void main(String[] args){
        InfoflowAndroidConfiguration conf = new InfoflowAndroidConfiguration();
        conf.getAnalysisFileConfig().setAndroidPlatformDir(new File(androidPlatformPath));
        conf.getAnalysisFileConfig().setTargetAPKFile(new File(appPath));
        conf.getCallbackConfig().setCallbacksFile(AndroidCallbacks.txt");
        String additionalClasspath = jarFile + ";" + jdkRtJarPath + ";" + "android.jar";
        conf.getAnalysisFileConfig().setAdditionalClasspath(additionalClasspath);
        conf.setMergeDexFiles(true);
        conf.getAnalysisFileConfig().setOutputFile(outputFile);
        conf.setEnableLineNumbers(true);
        conf.setLogSourcesAndSinks(true);
        conf.getAnalysisFileConfig().setSourceSinkFile(new File(sourceSinkPath));
        conf.setMergeDexFiles(true);
        conf.getAccessPathConfiguration().setAccessPathLength(-1);
        conf.getSolverConfiguration().setMaxAbstractionPathLength(-1);
        SetupApplication app = new SetupApplication(conf);
        soot.G.reset();

        Options.v().set_soot_classpath(androidPlatformPath+ ";" + appPath + ";" + jdkRtJarPath + ";" + "android.jar"+ ";" + jarFile + ";" + libFile);
        Options.v().set_process_dir(Collections.singletonList("jar/"));
        Options.v().set_process_multiple_dex(true);

        Options.v().set_whole_program(true);
        Options.v().set_allow_phantom_refs(false);

        Scene.v().loadNecessaryClasses();

        app.setCallbackFile(CGGenerator_test2.class.getResource("/AndroidCallbacks.txt").getFile());
        app.constructCallgraph();
        System.out.println(cg.toString());

        Scene.v().setCallGraph(cg);
        InfoflowAndroidConfiguration config = app.getConfig();
        config.setTaintAnalysisEnabled(true);
        config.setSootIntegrationMode(InfoflowAndroidConfiguration.SootIntegrationMode.UseExistingCallgraph);
         app.setTaintWrapper(new EasyTaintWrapper(taintWrapperFilePath));
         app.runInfoflow();
}
@StevenArzt
Copy link
Member

You only put additional JAR files on the classpath. If your APK file references classes from these JAR files, they will be analyzed together with the app. However, FlowDroid will build its dummy main method from the APK and will only consider the app's lifecycle including callbacks as entry points. If a method in the JAR is never called from the APK, it won't be analyzed.

I'm generally not sure what your intended semantics of combining an APK with a JAR file are.

@lzl-l
Copy link
Author

lzl-l commented Dec 26, 2024

Thank you for your explanation. As some apps are packed, I manually dump the dynamically loaded DEX files during runtime, and convert them to JAR files and then combine them with the APK file for a more complete analysis of the app. As you said, only when the APK calls the methods in the jar will they be analyzed. Can I achieve this purpose?

@StevenArzt
Copy link
Member

I understand your goal, but it won't be easy. The APK dynamically loads the additional DEX files and uses a special class loader and reflection to transfer the control flow into the additional classes that were loaded. The normal callgraph doesn't capture this behavior. The target classes and methods are part of the Soot scene, but the calls still use reflection. You would need to re-write the Jimple code to replace the class loading and reflective calls with proper method calls before building the callgraph.

@lzl-l
Copy link
Author

lzl-l commented Dec 26, 2024

Thank you for your reply. Rewriting the Jimple code is difficult for me. If I simply add additional JAR files to the classpath and put edges of the classes in the JAR files into the CallGraph, will the classes/method from the JAR files appear in the final output leak path? will they participate in the taint analysis?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants