[Soot-list] Use SOOT to analyse Java library.

christian.grosse at comhem.se christian.grosse at comhem.se
Fri Apr 10 09:02:02 EDT 2015


Hi Johannes,

I am currently working on a Java to C code translator and I would like to try the process on the Java library, this would be a great way of testing my translator. I tried this simple program:

public class Test 
{
    public static void main(String[] args)
    {
        String newargs[] = {
        "-whole-program",
        "-include-all",
        "-p","cg","all-reachable:true",
        "-cp","C:\\Program Files (x86)\\Java\\jre1.8.0_31",
        "-d", "c:\\Temp",
        "-process-dir","C:\\Program Files (x86)\\Java\\jre1.8.0_31\\lib\\jce.jar",
        "-process-dir","C:\\Program Files (x86)\\Java\\jre1.8.0_31\\lib\\jsse.jar",
        "-process-dir","C:\\Program Files (x86)\\Java\\jre1.8.0_31\\lib\\rt.jar"};
    
        soot.Main.main(newargs);        
    }
}

But I got this error:

Transforming java.awt.SplashScreen$1... 
Transforming java.awt.SystemColor... 
soot.SootMethodRefImpl$ClassResolutionFailedException: Class soot.dummy.InvokeDynamic doesn't have method updateSystemColors([]) : sun.awt.AWTAccessor$SystemColorAccessor; failed to resolve in superclasses and interfacesLooking in soot.dummy.InvokeDynamic which has methods []

    at soot.SootMethodRefImpl.resolve(SootMethodRefImpl.java:164)
    at soot.SootMethodRefImpl.resolve(SootMethodRefImpl.java:109)
    at soot.jimple.internal.AbstractInvokeExpr.getMethod(AbstractInvokeExpr.java:67)
    at soot.jimple.validation.InvokeArgumentValidator.validate(InvokeArgumentValidator.java:34)
    at soot.jimple.JimpleBody.validate(JimpleBody.java:117)
    at soot.jimple.JimpleBody.validate(JimpleBody.java:102)
    at soot.baf.BafBody.<init>(BafBody.java:63)
    at soot.baf.Baf.newBody(Baf.java:560)
    at soot.PackManager.convertJimpleBodyToBaf(PackManager.java:976)
    at soot.PackManager.runBodyPacks(PackManager.java:932)
    at soot.PackManager.runBodyPacks(PackManager.java:608)
    at soot.PackManager.runBodyPacks(PackManager.java:507)
    at soot.PackManager.runPacksNormally(PackManager.java:484)
    at soot.PackManager.runPacks(PackManager.java:391)
    at soot.Main.run(Main.java:244)
    at soot.Main.main(Main.java:152)
    at Test.main(Test.java:27)

I looked into the rt.jar and the sun.awt.AWTAccessor$SystemColorAccessor class file is present in the jar file, so I am not sure what I did wrong. Do you have any ideas?

Best regards,
Christian G



From: Johannes Lerch 
Sent: Friday, April 10, 2015 10:17 AM
To: Bodden, Eric ; christian.grosse at comhem.se 
Cc: SOOT mailing list 
Subject: Re: [Soot-list] Use SOOT to analyse Java library.

Hi Christian,

the options that will be of interest for you are the following:

-cp and -process-dir to provide paths to the jar files of the jre. You probably want to include all jars inside JAVA_HOME/lib/, but at the very least the rt.jar file.

-include-all to remove the default filter for java packages.

-whole-program to set it to a whole program analysis, i.e., there is no main method.

-allow-phantom-refs is required if you will not include all jars and even if, there might be some platform specific classes missing.

-p cg all-reachable:true as Eric already explained.

-p jb use-original-names:true to use the original local variable names (if information is provided: analyze a jdk instead of a jre to have debug information!)

More information about each option can be found here: https://ssebuild.cased.de/nightly/soot/doc/soot_options.htm

Regards,
Johannes



Am 10.04.2015 um 07:44 schrieb Bodden, Eric:

Hi Christian.

How do I get SOOT to load & parse (so I can get Jimple bodies) for say the entire java 1.x library.

Do I have to supply SOOT with the classes (or source code) as arguments in the call to Main.main(args) (see code below)?

Do I have to create a main class to get it to work? Or can SOOT analyze all classes I provide as arguments to Main.main(args) call without a main class & method?
This really depends on what you want to do. If you want to do intra-procedural analysis then it should be “just” a matter of giving Soot the right command line to parse all the classes faithfully. I have a PhD student who is currently analyzing the JDK for vulnerabilities and I have asked him to provide more info on which command line he uses.

If you want to do inter-procedural analysis then it’s more tricky. The problem is that you need a call graph and this, in turn, requires some entry points. You can use "-p cg all-reachable:true” to instruct Soot to consider _all_ methods as entry points during call-graph construction. If you combine this with using CHA then this should typically give you a call graph that is sound but may be very imprecise. We are currently working towards more precise analyses of libraries but it’s a hard problem to solve.

Best wishes,
Eric

   

_______________________________________________
Soot-list mailing list
Soot-list at CS.McGill.CA
https://mailman.CS.McGill.CA/mailman/listinfo/soot-list

-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://mailman.CS.McGill.CA/pipermail/soot-list/attachments/20150410/2c38df05/attachment.html 


More information about the Soot-list mailing list