khanhqhi / elsim Goto Github PK

two apks with elsim, results as following:
1 elsim.exe in windows
warning: compressor SNAPPY is not supported (use zlib default compressor)
Elements:
     IDENTICAL: 1408
     SIMILAR:   514
     NEW:       76
     DELETED:   1
     SKIPPED:   0
warning: compressor SNAPPY is not supported (use zlib default compressor)
    --> methods: 92.890752% of similarities

2 elsim in linux with snappy
Elements:
     IDENTICAL: 1408
     SIMILAR:   437
     NEW:       64
     DELETED:   78
     SKIPPED:   0
    --> methods: 91.919089% of similarities

3 elsim in linux with ZLIB
Elements:
     IDENTICAL: 1408
     SIMILAR:   484
     NEW:       40
     DELETED:   31
     SKIPPED:   0
    --> methods: 92.338823% of similarities

4 elsim in linux with BZ2
Elements:
     IDENTICAL: 1408
     SIMILAR:   502
     NEW:       43
     DELETED:   13
     SKIPPED:   0
    --> methods: 91.555399% of similarities

because the two apks are similar but one is obfuscated in code.
so seems the windows elsim.exe with zlib is a best result.

Why? Why 1 and 3 different since both use zlib? 

What steps will reproduce the problem?
1. Run $ ./androsim.py -i 
RuFraud_angry.Birds_95a04cfc5ed03c54d4749310ba29dda9.apk RuFraud_SuiConFo.apk -d

What is the expected output? What do you see instead?
Output:
warning: compressor SNAPPY is not supported (use zlib default compressor)
Elements:
     IDENTICAL: 1
     SIMILAR:   1
     NEW:       1
     DELETED:   44
     SKIPPED:   0
warning: compressor SNAPPY is not supported (use zlib default compressor)
    --> methods: 33.333333% of similarities
[...]
IDENTICAL methods:
    Lcom/Angry/Birds/R$attr; <init> ()V 4
        --> Lcom/magicsms/own/MagicSMSActivity; <init> ()V 4
[...]

I expect androsim, to differ an R*.class from a normal class-Method by default. 
The SMALI Code shows, that the both methods looks pretty the same, except for 
the class of the called <init> method:

Sample 1 = RuFraud_angry.Birds_95a04cfc5ed03c54d4749310ba29dda9.apk
sha256 = e45caa25f87531cff2ee2803374ac78de0757941dd1311e3411ce4cdf6d5d942
-------------
  1 .class public final Lcom/Angry/Birds/R$attr;
[...]
 17 # direct methods
 18 .method public constructor <init>()V
 19     .locals 0
 20 
 21     .prologue
 22     .line 11
 23     invoke-direct {p0}, Ljava/lang/Object;-><init>()V
 24 
 25     return-void
 26 .end method

Sample 2 = SuiConFu.apk
sha256 = 98a402d885cdb941dca8b45a4bbcbbe7f44ba62910d519bc1c2161dba117ebd2
-------------
  1 .class public Lcom/magicsms/own/MagicSMSActivity;
[...]
  6 # direct methods
  7 .method public constructor <init>()V
  8     .locals 0
  9 
 10     .prologue
 11     .line 11
 12     invoke-direct {p0}, Landroid/app/Activity;-><init>()V
 13 
 14     return-void
 15 .end method

I does not know, if this is a BUG or a problem of your algorithm. Perhaps you 
have to make a explicit exception for the R*.java files.
Nevertheless androsim/elsim is an awesome feature. Thanks!

What version of the product are you using? On what operating system?
- Androguard 1.6 Revision 411 from the Repository (Oct 08 15:41:27 2012 +0200)
- Ubuntu ....

Please provide any additional information below.

I reported issue here:
http://code.google.com/p/androguard/issues/detail?id=81

You describe in Bulding Androguard 
(http://code.google.com/p/androguard/wiki/Installation#Building), that people 
that have problem with muParser.h should modify the Makefile in a specific 
subfolder. Because this does not work in my case and I have to edit another 
Makefile(elsim/elsign/libsign/Makefile), I found a smarter solution:

Do not include "muParser.h", include instead "muParser/muParser.h" in the 
formular.h . With this patch, you can erase the helping part for muParser in 
your manual.