[Soot-list] Android instrumentation: No main class given. Inferred [..] as main class.

[José Leal Domingues Neto]

But the problem itself was solved.

I'm not really sure about all the necessary Packs for transforming an
Android application, cause I didn't have the time to actually read about
everything. But as far as I understood, without running the packs, the
output is not written successfully.

What I've done in this case, is simply add a custom entryPoint. This way,
not *everything* was being loaded in memory. One particular thing though,
for some arbitrary methods as entryPoint, it was showing me some strange
stack errors which I was not fully understanding.
With:

        SootClass c =
Scene.v().forceResolve("br.com.lealdn.client.ClientMain", SootClass.BODIES);
        c.setApplicationClass();
        Scene.v().loadNecessaryClasses();
        SootMethod m = c.getMethods().get(0);

It is working. That is, only with this first method - don't know why =/.
For DEX output, is it necessary to run the packs?

Best,
José

José Leal Domingues Neto <dominguesn at gmail.com> schrieb am Di., 12. Mai
2015 um 09:06 Uhr:

> Hi Eric,
>
> Thank you for the answer. WIthout the -w options I receive the following:
>
> Exception in thread "main" java.lang.RuntimeException: This operation
> requires resolving level SIGNATURES but
> android.animation.PropertyValuesHolder is at resolving level HIERARCHY
> If you are extending Soot, try to add the following call before calling
> soot.Main.main(..):
> Scene.v().addBasicClass(android.animation.PropertyValuesHolder,SIGNATURES);
> Otherwise, try whole-program mode (-w).
>
> If I add the above, it keeps complaining about other classes.
>
> Best,
> José
>
> Bodden, Eric <eric.bodden at sit.fraunhofer.de> schrieb am Di., 12. Mai 2015
> um 03:45 Uhr:
>
>> Hi Jose.
>>
>> Is there any reason for why you enable whole-program mode (using -w)?
>> This instructs Soot to compute a call-graph and all, which takes up a lot
>> of memory. For pure instrumentation this should be unnecessary.
>>
>> Cheers,
>> Eric
>>
>>
>>
>> > On 11.05.2015, at 17:43, José Leal Domingues Neto <dominguesn at gmail.com>
>> wrote:
>> >
>> > Hello everyone,
>> >
>> > I'm trying to modify an android apk and everything was working fine
>> until now. I suppose that the apk has grown too big (actually is not that
>> much), and now I'm receive a Java Heap space error or a GC error even after
>> giving more memory to soot:
>> > - Caused by: java.lang.OutOfMemoryError: GC overhead limit exceeded
>> >
>> > I suppose that Soot is trying to analyse *everything* inside the app,
>> which uses a lot of Libs. How can I avoid this? I've tried setting the
>> entry point (http://www.bodden.de/2012/07/26/soot-custom-entry-points/)
>> of the jtp transformation, but it still gives me the same error.
>> >
>> > Furthermore, I now noticed that its inferring a main-class from a lib
>> I'm using: "No main class given. Inferred
>> org.apache.commons.math3.util.FastMath' as main class.", how can I set this
>> correctly? Is the error related?
>> >
>> > This is my command-line: java -Xmx1024M -Xms1024M -XX:PermSize=2048m
>> -XX:MaxPermSize=2048m -cp "~/TestingSoot/lib/*:../../*:."
>> AndroidInstrument -pp -android-jars
>> /home/neto/adt-bundle-linux-x86_64-20140702/sdk/platforms/android-20
>> -process-dir ~/ClientSide/bin/ClientMain-debug.apk -allow-phantom-refs -w
>> >
>> > Thank you for your help,
>> > José
>> > _______________________________________________
>> > 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 --------------
An HTML attachment was scrubbed...
URL: https://mailman.CS.McGill.CA/pipermail/soot-list/attachments/20150512/dfa67c5d/attachment.html