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

Bodden, Eric eric.bodden at sit.fraunhofer.de
Fri Apr 10 09:59:57 EDT 2015 

Hmm, I just tried this command line:

-allow-phantom-refs -include-all  -d /tmp -process-dir /Library/Java/JavaVirtualMachines/jdk1.8.0_11.jdk/Contents/Home/jre/lib/rt.jar -cp /Library/Java/JavaVirtualMachines/jdk1.8.0_11.jdk/Contents/Home/jre/lib/jce.jar:/Library/Java/JavaVirtualMachines/jdk1.8.0_11.jdk/Contents/Home/jre/lib/jsse.jar


This is not giving me the error you describe but a different one ;-)

Writing to /tmp/java/time/format/DateTimeFormatterBuilder$ReducedPrinterParser.class
java.lang.RuntimeException: invalid fromType java.time.format.DateTimeParseContext
	at soot.baf.internal.BPrimitiveCastInst$1.defaultCase(BPrimitiveCastInst.java:96)
	at soot.TypeSwitch.caseRefType(TypeSwitch.java:76)
	at soot.RefType.apply(RefType.java:156)
	at soot.baf.internal.BPrimitiveCastInst.getName(BPrimitiveCastInst.java:92)
	at soot.baf.internal.BPrimitiveCastInst.toString(BPrimitiveCastInst.java:193)
	at soot.baf.JasminClass$1.casePrimitiveCastInst(JasminClass.java:1446)
	at soot.baf.internal.BPrimitiveCastInst.apply(BPrimitiveCastInst.java:199)
	at soot.baf.JasminClass.emitInst(JasminClass.java:331)
	at soot.baf.JasminClass.emitMethodBody(JasminClass.java:269)
	at soot.AbstractJasminClass.emitMethod(AbstractJasminClass.java:769)
	at soot.AbstractJasminClass.<init>(AbstractJasminClass.java:648)
	at soot.baf.JasminClass.<init>(JasminClass.java:95)
	at soot.PackManager.writeClass(PackManager.java:1038)
	at soot.PackManager.writeOutput(PackManager.java:619)
	at soot.PackManager.writeOutput(PackManager.java:528)
	at soot.Main.run(Main.java:246)

Seems like the bytecode generation is still not as stable as we would like it to be in some cases. Having said that, we are currently testing a new ASM-based backend. That might improve things.

About your particular problem I am not sure. It seems to be hard to produce without using the very same JAR files.

Cheers,
Eric


> On 10.04.2015, at 15:02, christian.grosse at comhem.se wrote:
> 
> 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
> 
> _______________________________________________
> Soot-list mailing list
> Soot-list at CS.McGill.CA
> https://mailman.CS.McGill.CA/mailman/listinfo/soot-list

--
Prof. Eric Bodden, Ph.D., http://sse.ec-spride.de/ http://bodden.de/
Head of Secure Software Engineering at Fraunhofer SIT, TU Darmstadt and EC SPRIDE
Tel: +49 6151 16-75422    Fax: +49 6151 869-127
Room B5.11, Fraunhofer SIT, Rheinstraße 75, 64295 Darmstadt

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 841 bytes
Desc: Message signed with OpenPGP using GPGMail
Url : https://mailman.CS.McGill.CA/pipermail/soot-list/attachments/20150410/9a8d20c1/attachment.bin

More information about the Soot-list mailing list