[Soot-list] Tamiflex reflection log lambda entries

Eric Bodden eric.bodden at uni-paderborn.de
Mon Apr 29 05:26:38 EDT 2019


Dear David,

I am sorry it seems like I misremembered. I thought I had made this configurable through poa.properties, but looking at the code again I can now see that instead those names are still hard coded, see here:
https://github.com/secure-software-engineering/tamiflex/blob/127653932ef1121bb68b0368429687d67363e975/Normalizer/src/de/bodden/tamiflex/normalizer/Hasher.java#L36

A short-term solution would thus be to patch this file. An even better solution would be to make this configurable through an option in poa.properties. If you find the time, I’d be happy to accept a pull request along these lines.

Hope this helps!

Cheers
Eric

> On 27. Apr 2019, at 04:43, David Diepenbrock <ddiepenbrock at pjrcorp.com> wrote:
> 
> Thanks Eric,
> I greatly appreciate your response!  
> 
> When you say the config file, are you talking about the play-out-agent's poa.properties file?  I have not found any configuration options regarding enabling/disabling via "dontNormalize".  Otherwise, I have set the transformations to only enable the first 4 (ClassForName, ClassNewInstance, ConstructorNewInstance and MethodInvoke).
> 
> I'm reviewing the paper again taking special note to the sections on normalization. I have looked it over briefly and it will certainly be helpful. I will follow up after I've studied the paper carefully.
> 
> Best,
> David
> 
> From: Eric Bodden <eric.bodden at uni-paderborn.de>
> Sent: Thursday, April 25, 2019 9:10 AM
> To: David Diepenbrock; soot-list at cs.mcgill.ca
> Subject: Re: [Soot-list] Tamiflex reflection log lambda entries
> 
> Hi David.
> 
> Sorry about the late response. In the paper you should find a section on normalizing names. The names of the classes need to be normalized. To configure which names Tamiflex does normalize, you need to edit the appropriate entries in the config file.
> 
> Does that help?
> 
> Cheers
> Eric
> 
> --
> Sent from my mobile
> Von: David Diepenbrock <ddiepenbrock at pjrcorp.com>
> Gesendet: Dienstag, 16. April 2019 23:56
> An: soot-list at cs.mcgill.ca
> Betreff: [Soot-list] Tamiflex reflection log lambda entries 
> 
> Hello Soot community, 
> 
> I am having an issue with Soot's reflection log processing and I'm hoping someone might be able to provide some information or guidance. I'm using Tamiflex's play-out-agent to generate a reflection log and that seems to work well. However, when importing the log Soot is throwing an exception. It seems the problem I'm having is similar to those described in these older postings, to which I did not find any responses: 
>    https://mailman.cs.mcgill.ca/pipermail/soot-list/2016-October/008587.html 
>    https://mailman.cs.mcgill.ca/pipermail/soot-list/2016-March/008418.html 
> 
> The specific issue is that lambda usage results in a Constructor.newInstance call such as this being added to the reflection log: 
> 
> Constructor.newInstance;<java.awt.GraphicsEnvironment$$Lambda$1.1480010240: void <init>()>;java.lang.invoke.InnerClassLambdaMetafactory.buildCallSite;215;isAccessible=true; 
> 
> Here is an excerpt of the exception during the Soot processing when it attempts to parse the above line of the reflection log (which is the first such Lambda entry). 
> 
> java.lang.RuntimeException: Unknown method for signature: <java.awt.GraphicsEnvironment$$Lambda$1.1480010240: void <init>()> 
> at soot.jimple.toolkits.reflection.ReflectionTraceInfo.<init>(ReflectionTraceInfo.java:113) ~[soot-3.1.0.jar:?] 
> at soot.jimple.toolkits.callgraph.OnFlyCallGraphBuilder$TraceBasedReflectionModel.<init>(OnFlyCallGraphBuilder.java:1038) ~[soot-3.1.0.jar:?] 
> at soot.jimple.toolkits.callgraph.OnFlyCallGraphBuilder$TraceBasedReflectionModel.<init>(OnFlyCallGraphBuilder.java:1025) ~[soot-3.1.0.jar:?] 
> at soot.jimple.toolkits.callgraph.OnFlyCallGraphBuilder.<init>(OnFlyCallGraphBuilder.java:224) ~[soot-3.1.0.jar:?] 
> at soot.jimple.toolkits.callgraph.OnFlyCallGraphBuilder.<init>(OnFlyCallGraphBuilder.java:230) ~[soot-3.1.0.jar:?] 
> at soot.jimple.spark.solver.OnFlyCallGraph.<init>(OnFlyCallGraph.java:75) ~[soot-3.1.0.jar:?] 
> at soot.jimple.spark.builder.ContextInsensitiveBuilder.setup(ContextInsensitiveBuilder.java:81) ~[soot-3.1.0.jar:?] 
> at soot.jimple.spark.SparkTransformer.internalTransform(SparkTransformer.java:93) ~[soot-3.1.0.jar:?] 
> at soot.SceneTransformer.transform(SceneTransformer.java:39) ~[soot-3.1.0.jar:?] 
> ... 
> 
> If I remove all of the lines from the log containing "$$Lambda$" then soot is able to process the reflection log and I do find that the callgraph has edges from reflection that otherwise were missing. In other words, the reflection log is certainly being processed and doing what I was hoping/expecting. 
> 
> As noted in the above exception trace, I'm currently using the soot release version 3.1.0. I have also tried with version 3.3.0 with the same results. 
> 
> I'm wondering if there is some option or setting that I am might be missing, or perhaps there is a general lack of support for lambda (and perhaps other InvokeDynamic related reflection)? 
> 
> Thanks in advance for any information that can be shared on this topic. 
> 
> Best, 
> David 
> _______________________________________________ 
> Soot-list mailing list 
> Soot-list at CS.McGill.CA 
> https://mailman.CS.McGill.CA/mailman/listinfo/soot-list 



More information about the Soot-list mailing list