[Soot-list] setapp(true) causes dexopt failed error and instrumenting trycatchblock

Fri Apr 25 16:15:53 EDT 2014

Hi Aditya,

As I wrote, if you enable application mode, all classes in your process directory will be written into the output APK file. If you do not explicitly specify a Soot classpath, Soot will automatically create a default classpath containing your Android JAR file when running in Android mode. This has the consequence that Android’s internal classes (or at least the stub implementations thereof which are contained in the android.jar files shipped with the SDK) get written into the APK file where they definitely don’t belong. This apparently leads to bogus annotations and the reported dexopt problem. Please either remove the set_app(true) – of which I still don’t know why you should ever need it when working with Android apps – or set a custom Soot classpath.

Best regards,

  Steven

Von: Satyaditya Munipalle [mailto:satyadit at buffalo.edu] 
Gesendet: Freitag, 25. April 2014 20:28
An: Steven Arzt
Betreff: Re: [Soot-list] setapp(true) causes dexopt failed error and instrumenting trycatchblock

Hi Mr Steven,

                      Thank you for super quick response ! This is  the logcat output which i got . I attached the sample application for your reference. The attached application  implements locationlistener and sensor listener and  android support v4 library  is present in the classpath. All the  appropriate permission set in the manifest . When the set_app(true) is set the dexopt fails .I used forceResolve(classname,level.Signatures) to load external classes into the scene. 

D/AndroidRuntime( 5003): >>>>>> AndroidRuntime START
com.android.internal.os.RuntimeInit <<<<<<
D/AndroidRuntime( 5003): CheckJNI is OFF
D/dalvikvm( 5003): Trying to load lib libjavacore.so 0x0
D/dalvikvm( 5003): Added shared lib libjavacore.so 0x0
D/dalvikvm( 5003): Trying to load lib libnativehelper.so 0x0
D/dalvikvm( 5003): Added shared lib libnativehelper.so 0x0
D/AndroidRuntime( 5003): Calling main entry
com.android.commands.pm.Pm <http://com.android.commands.pm.pm/> <http://com.android.commands.pm.pm/>
W/ActivityManager(  258): *No content provider found for permission
revoke:*file:///data/local/tmp/SootTestAppsAligned.apk
W/ActivityManager(  258): No content provider found for permission revoke:
 <file:///\\data\local\tmp\SootTestAppsAligned.apk> file:///data/local/tmp/SootTestAppsAligned.apk
I/PackageManager(  258): Running *dexopt* on: com.example.soottestapps
E/dalvikvm( 5014): Out-of-order encoded_annotation name_idx: 0x220e then
0x188eiz 
E/dalvikvm( 5014): Bogus encoded_array value
E/dalvikvm( 5014): Trouble with item 420 @ offset 0x11add9
E/dalvikvm( 5014): Swap of section type 2004 failed
E/dalvikvm( 5014): ERROR: Byte swap + verify failed
E/dalvikvm( 5014): Optimization failed
W/installd(   91): DexInv: --- END
'/data/app/com.example.soottestapps-1.apk' --- status=0xff00, process failed
E/installd(   91): dexopt failed on '/data/dalvik-cache/data at app <http://mailman.cs.mcgill.ca/mailman/listinfo/soot-list> 
@com.example.soottestapps-1.apk at classes.dex <http://mailman.cs.mcgill.ca/mailman/listinfo/soot-list> ' res = 65280
W/PackageManager(  258): Package couldn't be installed in
/data/app/com.example.soottestapps-1.apk

On Fri, Apr 25, 2014 at 2:13 PM, Steven Arzt <Steven.Arzt at cased.de> wrote:

Hi aditya,

I’m not Eric, but I can try to answer your questions as well.

1.       What is the reason for enabling application mode using set_app(true)? This will make all classes in your process dir application classes and will thus write all of them out into your final APK file. Without knowing more about your code and configuration, it’s hard to tell whether that is a problem or not. In any case, using this option together with Android is usually unnecessary unless you have a very specific use case.
If the problem still persists without set_app(true), please provide a small code sample that helps us reproduce the issue. Also the details of the dexopt error (which you will see in logcat right before you get the dexopt error in adb) would be very helpful.

2.       A good example on how to move around traps can be found in Soot’s TrapSplitter class. It checks for overlapping traps and splits them which shows how new traps can be created, existing ones can be removed, and start/end units of traps can be changed. Note that labels only exist in pretty-print. In a Jimple body, trap start and end units are always units, there is no concept of a label in Jimple. It only gets inserted to make life easier when reading Jimple code.

Best regards,

  Steven

M.Sc. M.Sc. Steven Arzt

Secure Software Engineering Group (SSE)

European Center for Security and Privacy by Design (EC SPRIDE) 

Mornewegstraße 32

D-64293 Darmstadt

Phone: +49 61 51 16-75426 <tel:%2B49%2061%2051%2016-75426> 

Fax: +49 61 51 16-72118 <tel:%2B49%2061%2051%2016-72118> 

eMail:  <mailto:steven.arzt at ec-spride.de> steven.arzt at ec-spride.de

Web: http://sse.ec-spride.de <http://sse.ec-spride.de/> 

Von: soot-list-bounces at CS.McGill.CA [mailto:soot-list-bounces at CS.McGill.CA] Im Auftrag von Satyaditya Munipalle
Gesendet: Freitag, 25. April 2014 20:04
An: soot-list at cs.mcgill.ca
Betreff: [Soot-list] setapp(true) causes dexopt failed error and instrumenting trycatchblock

Hi Mr. Eric,

                   While instrumentation of android apps I had noticed that when the external classes are set as application classes when loaded via  forceload method or tryloadclass method  if the options.v().set_app(true) is used with whole-program-mode enabled ,  the validation succeeds while running soot ,but the  android OS throws [dex_opt_failed] error . Can you tell me why this option causes the dex optimzation to fail?

2.how to  change the position of the try statement in the function block, I am not able to match the try 'label' with any type of statements defined in the  soot? though  I am able to create a new label using the setBeginUnit method declared in the trap interface, I was not able to remove the existing try statement.

Regards,

aditya

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.CS.McGill.CA/pipermail/soot-list/attachments/20140425/019dcb11/attachment-0001.html 