[Soot-list] Missing Nodes in CFG
Dennis Titze
dennis.titze at googlemail.com
Fri Mar 14 03:59:55 EDT 2014
Hi Steven,
yes, I am aware that these framework functions are just
stub-implementations, but the calls to these functions should be visible
in the CFG.
To generate the CFG I tried:
TransitiveTargets tgs = new TransitiveTargets(Scene.v().getCallGraph());
Iterator<MethodOrMethodContext> tgtIt = tgs.iterator(main);
while (tgtIt.hasNext()) { ... }
I tried this after the runInfoflow (which finds the flow to this
function), but also if I try this CFG-Generation directly after the
entrypointgeneration, it also does not find the function in the CFG.
Since I want to do more analysis on the CFG, the result from the
infoflow is unfortunately not enough.
Thanks for your help!
Dennis
On 10.03.2014 11:37, Steven Arzt wrote:
> Hi Dennis,
>
> from the Jimple file you have sent, it looks as if you are using the normal
> Android JAR files shipped with the Android SDK as you can download it from
> Google. This very file only contains stub implementations. If you look at
> your Jimple file in detail, you will find that every single method in the
> file does nothing more than raising an exception. There is no actual method
> implementation logic. As I said, this is however perfectly fine since it
> does not impact the call edge into the respective method at all.
>
> If you find the data flow, there must also be the call edge in the CFG or
> otherwise FlowDroid would not have been able to recognize the call to the
> source method getLine1Number() either. How did you print out the CFG?
> FlowDroid constructs the CFG multiple times when it iteratively collects the
> callbacks in the APK. Maybe you have just looked at one of the interim CFGs
> which was still incomplete.
>
> If the data flow results are all you need, you need not worry about the CFG
> at all since FlowDroid takes care of it.
>
> Best regards,
> Steven
>
> -----Ursprüngliche Nachricht-----
> Von: soot-list-bounces at sable.mcgill.ca
> [mailto:soot-list-bounces at sable.mcgill.ca] Im Auftrag von Dennis Titze
> Gesendet: Freitag, 7. März 2014 09:01
> An: soot-list at sable.mcgill.ca
> Cc: Steven Arzt; "=?ISO-8859-1?Q?=27Marc-Andr=E9_?="@cs.mcgill.ca
> Betreff: Re: [Soot-list] Missing Nodes in CFG
>
> Hi Marc-André, hi Steven,
>
> thank you for your reply!
>
> @Marc-André: I get the same results when looking at the CFG using the
> default android-infoflow setup.
>
> @Steven: Actually I did not know about any stub implementations, are these
> in the git, or where can I find them?
> Currently I am using the original Android jars, and the Telephonymanager
> looks quite good in soot (see attachment)
>
> What is quite strange, that although the getLine1Number does not appear in
> the CFG, a data flow from getLine1Number e.g. to a Log statement is found.
> Any idea why this could be?
>
> Best regards,
> Dennis
>
>
> On 06.03.2014 18:15, Steven Arzt wrote:
>> Hi Dennis and Marc-André,
>>
>> I don't think the stub JAR is a problem here. If you cann
>> getLine1Number(), this is an existing method in the Android stub JAR
>> and thus there will be a call edge in the CFG. We always tell people
>> to use FlowDroid with the stub JARs since it's quite a lot faster and
>> consumes way less memory - and our call edges to API functions are all
>> there. Maybe your Android JAR file is not only a stub, but incomplete
>> (i.e., broken)? Which one do you use and where did you get it from?
>>
>> It would also be good to look at the Android classes such as
>> TelephonyManager? Do they look ok or are these phantom classes that
>> Soot could not resolve at all? If the latter is the case, there's
>> something wrong with your classpath. If you have set a custom
>> classpath, be sure to add your Android JAR file on the new classpath -
>> otherwise you'll exactly see the issues you have described.
>>
>> Best regards,
>> Steven
>>
>> -----Ursprüngliche Nachricht-----
>> Von: soot-list-bounces at sable.mcgill.ca
>> [mailto:soot-list-bounces at sable.mcgill.ca] Im Auftrag von Marc-André
>> Laverdière
>> Gesendet: Donnerstag, 6. März 2014 15:50
>> An: soot-list at sable.mcgill.ca
>> Betreff: Re: [Soot-list] Missing Nodes in CFG
>>
>> Hallo Dennis,
>>
>> Disclaimer: I haven't tried on Android yet.
>>
>> Have you tried with plain Spark settings? Is there a difference?
>>
>> IIRC, VTA relies on new XYZ statements. If you use an Android jar stub
>> that lacks the object creation statements, then you will have some
>> parts missing for sure. That being said, I'd have expected Spark to
> default to CHA.
>>
>> Marc-André Laverdière-Papineau
>> Doctorant - PhD Candidate
>>
>> On 03/06/2014 03:02 AM, Dennis Titze wrote:
>>> Hi,
>>>
>>> I stumbled over the following problem, but I am not sure if I am
>>> doing something wrong:
>>>
>>> After running an Android-Infoflow Analysis, I want to look at the
>>> generated CFG (using VTA). But it seems as if some nodes are missing.
>>> E.g. for the following jimple:
>>>
>>> private java.lang.String get_phone()
>>> {
>>> com.example.android.skeletonapp.SkeletonActivity $r0;
>>> java.lang.Object $r1;
>>> java.lang.String $r2;
>>> android.telephony.TelephonyManager $r3;
>>>
>>> $r0 := @this: com.example.android.skeletonapp.SkeletonActivity;
>>> $r1 = virtualinvoke
>>> $r0.<com.example.android.skeletonapp.SkeletonActivity:
>>> java.lang.Object getSystemService(java.lang.String)>("phone");
>>> $r3 = (android.telephony.TelephonyManager) $r1;
>>> $r2 = virtualinvoke $r3.<android.telephony.TelephonyManager:
>>> java.lang.String getLine1Number()>();
>>> return $r2;
>>> }
>>>
>>> the call to getLine1Number does not appear in the CFG.
>>>
>>> When looking at the Sparktransformer, the CFG looks quite fine after
>>> final PAG pag = b.setup( opts );
>>> b.build();
>>>
>>> But once the CFG is built again using the pag
>>> CallGraphBuilder cgb = new CallGraphBuilder( pag );
>>> cgb.build();
>>>
>>> the mentioned node is not in the CFG anymore.
>>>
>>> Problem seems to be, that p2set for this line in public void build()
>>> is empty. If I add something like if (p2set.isEmpty()) {
>>> ofcgb.addType( receiver, momc.context(), receiver.getType(), null
>>> ); }
>>>
>>> the node appears in the CFG.
>>>
>>>
>>> Could you explain a bit, what the PointsToSet is in that context, and
>>> why it is needed?
>>>
>>> Can you think of some configuration I missed, which results in this
>> problem?
>>>
>>>
>>> Thank you very much in advance!
>>>
>>> Dennis Titze
>>> _______________________________________________
>>> Soot-list mailing list
>>> Soot-list at sable.mcgill.ca
>>> http://mailman.cs.mcgill.ca/mailman/listinfo/soot-list
>>>
>> _______________________________________________
>> Soot-list mailing list
>> Soot-list at sable.mcgill.ca
>> http://mailman.cs.mcgill.ca/mailman/listinfo/soot-list
>>
>> _______________________________________________
>> Soot-list mailing list
>> Soot-list at sable.mcgill.ca
>> http://mailman.cs.mcgill.ca/mailman/listinfo/soot-list
>>
>
> _______________________________________________
> Soot-list mailing list
> Soot-list at sable.mcgill.ca
> http://mailman.cs.mcgill.ca/mailman/listinfo/soot-list
>
More information about the Soot-list
mailing list