Add an option to enable partial code analyzing which doesn't require full class path

[GoogleCodeExporter]

Baksmali enables code analyzing when deodexing and/or using an -r option. I 
think deodexing requires full analyzing of classes to work correctly, but 
printing registers is just to help people read smali code, so it doesn't have 
to be 100% perfect. Sometimes it may be more useful to print inaccurate info 
about registers, but without a need of supplying boot class dexes.

Actually it's very easy to do that. Just treat all unresolved classes as empty 
classes extending java.lang.Object - that's all.

Let's get for example:

1. We have classes: A, B->A and C->A.
2. There is a method with 2 branches of code joining into one. First set v0 to 
B type, second to C type.
3. A class is missing.

Currently you wouldn't be able to print reg info, because A is unresolved. But 
if you generate A as empty class extending Object, then above code would be 
decoded perfectly fine. We're still able to find out that v0 from these 2 
branches join into A - even if we don't know this type.

Of course you can't always decode everything. E.g.:

1. Classes: A, B->A, C->A, D->C.
2. Branches of code set B and D.
3. A and C is missing.

C is unresolved, so analyzer can't know B and D have common ancestor - A. So it 
will be decoded as Object. It's better than nothing though.

I have a proof-of-concept that it works: http://pastebin.com/4BX84gqN . It's a 
hack, not a final solution: changes aren't optional and generated Object class 
is missing toString() method, etc.

There is also a small bug. You have rewritten ClassPath, so it decodes classes 
in two phases: TempClassInfo first and then ClassDef. But still you use 
javaLangObjectClassDef which is set somewhere in the second phase. It's 
possible you will try to use javaLangObjectClassDef before it's set.

Original issue reported on code.google.com by Brut.alll on 22 Nov 2011 at 9:24

[GoogleCodeExporter]

Hmm. This sounds feasible to do. I'll take a look at it

Original comment by bgruv@google.com on 22 Nov 2011 at 9:48

• Changed state: Accepted

[GoogleCodeExporter]

I haven't tested this, but I think this is now supported in the 2.0 release, as 
a side-effect of some changes I made to increase the robustness of the method 
analyzer. Feel free to give it a shot if you're still interested.

Original comment by jesusfreke@jesusfreke.com on 7 May 2013 at 8:20

• Changed state: Fixed