[Soot-list] dava Error : Could not verify approximated Synch ronized body

Laurie Hendren, Prof hendren at cs.mcgill.ca
Tue Jun 19 16:01:12 EDT 2007


Diana,

Is this the problem that your new analysis will solve?

Laurie

+-----------------------------------------------------------------
| Laurie Hendren --- laurie.hendren at mcgill.ca
| Associate Dean (Academic), Faculty of Science,
| Dawson Hall, McGill University, 853 Sherbrooke St W,
| Montreal QC H3A 2T6 Canada, 514-398-7179, fax 514-398-1774
+----------------------------------------------------------------
| For contact and home page info as Professor, Computer Science:
| http://www.sable.mcgill.ca/~hendren   ---  hendren at cs.mcgill.ca
| Research: http://www.sable.mcgill.ca  http://aspectbench.org
+----------------------------------------------------------------


mbatch at cs.mcgill.ca wrote:
>> How should I interpret the code from jimple ?  (an exemple below)
> 
> Dionne,
> 
> Eric is correct. In this instance, it is simply a problem of the program
> loading an object onto the stack ($r4), storing it to a real register
> position (r2) but then locking (synchronizing) that object using its $r4
> reference (Jimple uses the $ symbol to demark stack position variables).
> The other end of the problem is that the program tries to unlock
> (unsynchronize) the object through reference r2. The result being that
> static analysis like Jad or Dava won't be able to ensure proper
> synchronization blocks if it can't tell that the references are the same.
> As Eric stated, use of Copy-prop or Must-alias should work out fine for
> this problem.
> 
> Good Luck,
> 
> Michael Batchelder
> 
>> -------------- JIMPLE ----------------
>> private void a(com.bridge.feed.server.BFContext) {
>> com.bridge.feed.server.BFDriver r0; com.bridge.feed.server.BFContext r1,
>> $r6;
>> byte[] r2, $r4; java.lang.Throwable r3, $r16; int $i0, $i1, $i2, $i3, $i4,
>> $i5, $i6, $i7, $i8;
>> java.util.Vector $r5, $r8, $r9, $r11, $r15; java.lang.Integer $r7, $r10,
>> $r12, $r14;
>> java.lang.Object $r13; boolean $z0;
>>
>> r0 := @this: com.bridge.feed.server.BFDriver; r1 := @parameter0:
>> com.bridge.feed.server.BFContext; $r4 =
>> r0.<com.bridge.feed.server.BFDriver: byte[] y>;
>> r2 = $r4; entermonitor $r4;
>>
>> label0:
>> $i0 = r1.<com.bridge.feed.server.BFContext: int d>;
>> if $i0 < 0 goto label2;
>>
>> $i1 = r1.<com.bridge.feed.server.BFContext: int d>;
>> $r5 = r0.<com.bridge.feed.server.BFDriver: java.util.Vector z>;
>> $i2 = virtualinvoke $r5.<java.util.Vector: int size()>();
>> if $i1 >= $i2 goto label2;
>>
>> $i3 = r1.<com.bridge.feed.server.BFContext: int d>;
>> $r6 = virtualinvoke r0.<com.bridge.feed.server.BFDriver:
>> com.bridge.feed.server.BFContext a(int)>($i3); if $r6 != r1 goto label2;
>>
>> exitmonitor r2;
>>
>> label1:
>> return;
>>
>> label2:
>> $r7 = r0.<com.bridge.feed.server.BFDriver: java.lang.Integer ab>;
>> if $r7 != null goto label3;
>>
>> $r8 = r0.<com.bridge.feed.server.BFDriver: java.util.Vector z>;
>> $i4 = virtualinvoke $r8.<java.util.Vector: int size()>();
>> r1.<com.bridge.feed.server.BFContext: int d> = $i4;
>> $r9 = r0.<com.bridge.feed.server.BFDriver: java.util.Vector z>;
>> virtualinvoke $r9.<java.util.Vector: void
>> addElement(java.lang.Object)>(r1); goto label4;
>>
>> label3:
>> $r10 = r0.<com.bridge.feed.server.BFDriver: java.lang.Integer ab>;
>> $i5 = virtualinvoke $r10.<java.lang.Integer: int intValue()>();
>> r1.<com.bridge.feed.server.BFContext: int d> = $i5;
>> $r11 = r0.<com.bridge.feed.server.BFDriver: java.util.Vector z>;
>> $r12 = r0.<com.bridge.feed.server.BFDriver: java.lang.Integer ab>;
>> $i6 = virtualinvoke $r12.<java.lang.Integer: int intValue()>();
>> $r13 = virtualinvoke $r11.<java.util.Vector: java.lang.Object
>> elementAt(int)>($i6); $r14 = (java.lang.Integer) $r13;
>> r0.<com.bridge.feed.server.BFDriver: java.lang.Integer ab> = $r14;
>> $r15 = r0.<com.bridge.feed.server.BFDriver: java.util.Vector z>;
>> $i7 = r1.<com.bridge.feed.server.BFContext: int d>;
>> virtualinvoke $r15.<java.util.Vector: void
>> setElementAt(java.lang.Object,int)>(r1, $i7);
>>
>> label4:
>> $z0 = virtualinvoke r0.<com.bridge.feed.server.BFDriver: boolean
>> a()>(); if $z0 == 0 goto label5;
>>
>> $i8 = r1.<com.bridge.feed.server.BFContext: int d>;
>> specialinvoke r0.<com.bridge.feed.server.BFDriver: void
>> b(int,java.lang.String)>($i8, "+++");
>>
>> label5:
>> exitmonitor r2;
>>
>> label6:
>> goto label10;
>>
>> label7:
>> $r16 := @caughtexception;
>>
>>
>> label8:
>> r3 = $r16; exitmonitor r2;
>>
>> label9:
>> throw r3;
>>
>> label10:
>> return;
>>
>> catch java.lang.Throwable from label0 to label1 with label7; catch
>> java.lang.Throwable from label2 to label6 with label7; catch
>> java.lang.Throwable from label8 to label9 with label7; }
>>
>>
>>
>>
>>
>>
>>
>>
>> Sébastien Dionne ing. jr.
>> Financière Banque Nationale
>> Analyste programmeur Senior
>> tel : 514-879-3107 courriel : sebastien.dionne at fbn.ca
>>
>> -----Original Message-----
>> From: eric.bodden at googlemail.com [mailto:eric.bodden at googlemail.com] On
>> Behalf Of Eric Bodden
>> Sent: 2007/06/19 13:37
>> To: Dionne, Sebastien
>> Cc: mbatch at cs.mcgill.ca; soot-list at sable.mcgill.ca
>> Subject: Re: [Soot-list] dava Error : Could not verify approximated Synch
>> ronized body
>>
>> Michael, I think in this particular case, this here is the problem:
>>
>>
>>
>> r2 = $r4; entermonitor $r4; exitmonitor r2;
>>
>>
>> We need to use must-alias analysis in order to tell that $r4 and r2
>> are the same. (Or alternatively, a copy-propagation. I think if we add
>> must-alias, we should eb able to handle this gracefully.
>>
>> @Dionne: I think if that's all you want to do it might be enoough to
>> look at the Jimple output, actually. I find it reasonable easy to read for
>> such purposes.
>>
>> Eric
>>
>>
>> On 19/06/07, Dionne, Sebastien <Sebastien.Dionne at fbn.ca> wrote:
>>
>>> thanks.
>>>
>>> I know that Jad don't decompile perfectly and it's even harder maybe
>>> impossible to correctly decompile an offuscated class.  but in the case
>> it's
>>> not offuscated.
>>>
>>> I just receive a new version of an API and I wanted to know what were
>>> the differences in the code.  I have to know if I can deploy this new
>> librairies
>>> in production without refactoring all our gateways.
>>>
>>> There were concurrency problems in the last API.  Most of the changes
>>> are synchronized block that been added.  I saw them in few classes.
>>>
>>>
>>> Sébastien Dionne ing. jr.
>>> Financière Banque Nationale
>>> Analyste programmeur Senior
>>> tel : 514-879-3107 courriel : sebastien.dionne at fbn.ca
>>>
>>> -----Original Message-----
>>> From: mbatch at cs.mcgill.ca [mailto:mbatch at cs.mcgill.ca]
>>> Sent: 2007/06/19 12:46
>>> To: Dionne, Sebastien
>>> Cc: 'soot-list at sable.mcgill.ca'
>>> Subject: Re: [Soot-list] dava Error : Could not verify approximated
>>> Synchronized body
>>>
>>>
>>> On Tue, June 19, 2007 10:33 am, Dionne, Sebastien wrote:
>>>
>>>> I'm trying to decompile a class but I got an error.  There is a way
>>>> to fix it ?
>>>>
>>>> I try with JAD and I obtain this (if that could help)
>>>>
>>> Dionne,
>>>
>>>
>>> It appears as though the class you are decompiling has some complicated
>>>  control flow containing some synchronized blocks. It is difficult to
>>> identify the exact problem without seeing the class file itself, but
>>> you are basically seeing the same problem with both Jad and Dava. Jad
>>> handles problems by just spitting out the class-level bytecode
>>> instructions if it cannot figure out how to translate them to java
>>> source. This is why you get the line "JVM INSTR monitorexit ;" for
>>> example.
>>>
>>> Dava is just slightly more clear on the problem, by failing with an
>>> exception. It is telling you exactly what the problem is: "Could not
>>> verify approximated Synchronized body".
>>>
>>> While the class may be "correct" bytecode and even verifiable, this
>>> does not guarantee that automatic tools such as Dava or Jad can
>>> necessarily decompile them. This is especially a problem for bytecode
>>> generated by third-party tools such as bytecode instrumenters or other
>>> frameworks that compile their own code with a non-standard compiler.
>>>
>>> I suspect, too, that this code might have been semi-obfuscated, given
>>> the program method and variable names. The entire point of obfuscating
>>> is to complicate decompilation attempts and this might be exactly what
>>> is happening here.
>>>
>>> Michael Batchelder
>>>
>>>
>>>>
>>>>
>>>> private void a(BFContext bfcontext) { label0:
>>>> {
>>>> synchronized(y) { if(bfcontext.d < 0 || bfcontext.d >= z.size() ||
>>>> a(bfcontext.d) != bfcontext) break label0; } return; } if(ab == null) {
>>>> bfcontext.d = z.size(); z.addElement(bfcontext); } else {
>>>> bfcontext.d = ab.intValue(); ab = (Integer)z.elementAt(ab.intValue());
>>>>  z.setElementAt(bfcontext, bfcontext.d); } if(a()) b(bfcontext.d,
>>>> "+++"); abyte0; JVM INSTR monitorexit ;
>>>> goto _L1 exception; throw exception; _L1: }
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>> -------------------------------------------------------------------------
>>
>>>> ---
>>>>
>>>>
>> -------------------------------------------------------------------------
>> -
>>
>>>> --
>>>> ----------------------------------
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> C:\workspace-test\test-soot-bf>java -Xmx400m -classpath
>>>> sootclasses-2.2.4.jar;polyglot.jar;C:\workspace-test\test-soot-b
>>>>
>>>>
>> f\classes;C:\jdk_5\jre\lib\rt.jar;C:\jdk_5\jre\lib\jsse.jar;C:\jdk_5\jre\
>> l
>>>> ib \jce.jar;C:\jdk_5\jre\lib\charsets.jar;C:\jd
>>>>
>> k_5\jre\lib\ext\dnsns.jar;C:\jdk_5\jre\lib\ext\localedata.jar;C:\jdk_5\jr
>> e
>>>> \l
>>>> ib\ext\sunjce_provider.jar;C:\jdk_5\jre\lib\
>>>> ext\sunmscapi.jar;C:\jdk_5\jre\lib\ext\sunpkcs11.jar soot.Main --cp
>>>> sootclasses-2.2.4.jar;polyglot.jar;C:\workspace-test
>>>>
>>>>
>> \test-soot-bf\classes;C:\jdk_5\jre\lib\rt.jar;C:\jdk_5\jre\lib\jsse.jar;C
>> :
>>
>>>> \j
>>>> dk_5\jre\lib\jce.jar;C:\jdk_5\jre\lib\charse
>>>>
>>>>
>> ts.jar;C:\jdk_5\jre\lib\ext\dnsns.jar;C:\jdk_5\jre\lib\ext\localedata.jar
>> ;
>>
>>>> C:
>>>> \jdk_5\jre\lib\ext\sunjce_provider.jar;C:\jd
>>>> k_5\jre\lib\ext\sunmscapi.jar;C:\jdk_5\jre\lib\ext\sunpkcs11.jar
>>>> --process-dir C:\workspace-test\test-soot-bf\classes -d
>>>> C:\workspace-test\test-soot-bf\sootOutput\ -f dava
>>>> Soot started on Tue Jun 19 10:19:28 EDT 2007
>>>> Verifying exception handling.. Warning: using incomplete callgraph
>>>> containing only application classes. [Call Graph] For information on
>> where
>>>> the call graph may be incomplete, use the verbose option to the cg
>> phase.
>>> .
>>>
>>>>
>>>> Decompiling com.bridge.feed.server.BFContext...
>>>> Decompiling com.bridge.feed.server.BFContextAdmin...
>>>> Decompiling com.bridge.feed.server.BFContextLogin...
>>>> Decompiling com.bridge.feed.server.BFContextStartup...
>>>> Decompiling com.bridge.feed.server.BFCrypt...
>>>> Decompiling com.bridge.feed.server.BFDriver...
>>>> Exception in thread "main" java.lang.RuntimeException: Could not
>>>> verify approximated Synchronized body at
>>>>
>> soot.dava.toolkits.base.finders.SynchronizedBlockFinder.find(Synchronized
>>
>>>> Blo
>>>> ckFinder.java:163)
>>>> at soot.dava.DavaBody.<init>(DavaBody.java:331) at
>>>> soot.dava.Dava.newBody(Dava.java:84)
>>>> at soot.PackManager.runBodyPacks(PackManager.java:807) at
>>>> soot.PackManager.runBodyPacks(PackManager.java:451)
>>>> at soot.PackManager.runBodyPacks(PackManager.java:370) at
>>>> soot.PackManager.runPacks(PackManager.java:347)
>>>> at soot.Main.run(Main.java:203) at soot.Main.main(Main.java:146)
>>>>
>>>> Sébastien Dionne ing. jr.
>>>> Financière Banque Nationale
>>>> Analyste programmeur Senior
>>>> tel : 514-879-3107 courriel : sebastien.dionne at fbn.ca
>>>>
>>>>
>>>>
>>>> **************************************************
>>>> AVIS DE NON-RESPONSABILITE: Ce document transmis par courrier
>>>>
>> electronique
>>>> est destine uniquement a la personne ou a l'entite a qui il est
>>>> adresse et peut contenir des renseignements confidentiels et
>>>> assujettis au
>> secret
>>>> professionnel. La confidentialite et le secret professionnel
>>>> demeurent malgre l'envoi de ce document a la mauvaise adresse
>>>> electronique. Si
>> vous
>>>> n'etes pas le destinataire vise ou la personne chargee de remettre ce
>>>>  document a son destinataire, veuillez nous en informer sans delai et
>>>>  detruire ce document ainsi que toute copie qui en aurait ete faite.
>> Toute
>>
>>>> distribution, reproduction ou autre utilisation de ce document est
>>>> strictement interdite. De plus, le Groupe Financiere Banque Nationale
>>>> et ses filiales ne peuvent pas etre tenus responsables des dommages
>>>> pouvant etre causes par des virus ou des erreurs de transmission.
>>>>
>>>> DISCLAIMER: This documentation transmitted by electronic mail is
>>>>
>> intended
>>>> for the use of the individual to whom or the entity to which it is
>>>> addressed and may contain information which is confidential and
>>>> privileged. Confidentiality and privilege are not lost by this
>>>> documentation having been sent to the wrong electronic mail address.
>>>> If
>>>> you are not the intended recipient or the person responsible for
>>>> delivering it to the intended recipient please notify the sender
>>>> immediately and destroy this document as well as any copies of it.
>>>> Any
>>>> distribution, reproduction or other use of this document is strictly
>>>> prohibited. National Bank Financial Group and its affiliates cannot
>>>> be held liable for any damage that may be caused by viruses or
>>>> transmission errors.
>>>> **************************************************
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> Soot-list mailing list
>>>> Soot-list at sable.mcgill.ca
>>>> http://mailman.cs.mcgill.ca/mailman/listinfo/soot-list
>>>>
>>>>
>>>>
>>>
>>>
>>> **************************************************
>>> AVIS DE NON-RESPONSABILITE: Ce document transmis par courrier
>>> electronique
>> est destine uniquement a la personne ou a l'entite a qui il est adresse
>> et peut contenir des renseignements confidentiels et assujettis au secret
>> professionnel. La confidentialite et le secret professionnel demeurent
>> malgre l'envoi de ce document a la mauvaise adresse electronique. Si vous
>>  n'etes pas le destinataire vise ou la personne chargee de remettre ce
>> document a son destinataire, veuillez nous en informer sans delai et
>> detruire ce document ainsi que toute copie qui en aurait ete faite. Toute
>>  distribution, reproduction ou autre utilisation de ce document est
>> strictement interdite. De plus, le Groupe Financiere Banque Nationale et
>> ses filiales ne peuvent pas etre tenus responsables des dommages pouvant
>> etre causes par des virus ou des erreurs de transmission.
>>> DISCLAIMER: This documentation transmitted by electronic mail is
>>> intended
>> for the use of the individual to whom or the entity to which it is
>> addressed and may contain information which is confidential and
>> privileged. Confidentiality and privilege are not lost by this
>> documentation having been sent to the wrong electronic mail address. If
>> you are not the intended recipient or the person responsible for
>> delivering it to the intended recipient please notify the sender
>> immediately and destroy this document as well as any copies of it. Any
>> distribution, reproduction or other use of this document is strictly
>> prohibited. National Bank Financial Group and its affiliates cannot be
>> held liable for any damage that may be caused by viruses or transmission
>> errors.
>>> **************************************************
>>>
>>>
>>>
>>> _______________________________________________
>>> Soot-list mailing list
>>> Soot-list at sable.mcgill.ca
>>> http://mailman.cs.mcgill.ca/mailman/listinfo/soot-list
>>>
>>>
>>
>> --
>> Eric Bodden
>> Sable Research Group
>> McGill University, Montréal, Canada
>>
>>
>> **************************************************
>> AVIS DE NON-RESPONSABILITE: Ce document transmis par courrier electronique
>> est destine uniquement a la personne ou a l'entite a qui il est adresse
>> et peut contenir des renseignements confidentiels et assujettis au secret
>> professionnel. La confidentialite et le secret professionnel demeurent
>> malgre l'envoi de ce document a la mauvaise adresse electronique. Si vous
>> n'etes pas le destinataire vise ou la personne chargee de remettre ce
>> document a son destinataire, veuillez nous en informer sans delai et
>> detruire ce document ainsi que toute copie qui en aurait ete faite. Toute
>> distribution, reproduction ou autre utilisation de ce document est
>> strictement interdite. De plus, le Groupe Financiere Banque Nationale et
>> ses filiales ne peuvent pas etre tenus responsables des dommages pouvant
>> etre causes par des virus ou des erreurs de transmission.
>>
>> DISCLAIMER: This documentation transmitted by electronic mail is intended
>> for the use of the individual to whom or the entity to which it is
>> addressed and may contain information which is confidential and
>> privileged. Confidentiality and privilege are not lost by this
>> documentation having been sent to the wrong electronic mail address. If
>> you are not the intended recipient or the person responsible for
>> delivering it to the intended recipient please notify the sender
>> immediately and destroy this document as well as any copies of it. Any
>> distribution, reproduction or other use of this document is strictly
>> prohibited. National Bank Financial Group and its affiliates cannot be
>> held liable for any damage that may be caused by viruses or transmission
>> errors. **************************************************
>>
>>
>>
>>
> 
> 
> _______________________________________________
> 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