Argus-SAF
Argus-SAF copied to clipboard
the processing time is very long
Hi, I'm using your tool to get some idfg, but it takes me especially long time to process a normal apk... I just load apk and do things as your code of taint analysis:
val fileUri = FileUtil.toUri(args(0))
val outputUri = FileUtil.toUri(args(1))
val reporter = new DefaultReporter
val yard = new ApkYard(reporter)
val layout = DecompileLayout(outputUri)
val strategy = DecompileStrategy(new DefaultLibraryAPISummary(AndroidGlobalConfig.settings.third_party_lib_file), layout)
val settings = DecompilerSettings(debugMode = false, forceDelete = true, strategy, reporter)
val apk = yard.loadApk(fileUri, settings, collectInfo = true)
ComponentBasedAnalysis.prepare(Set(apk))(2 minutes)
val cba = new ComponentBasedAnalysis(yard)
cba.phase1(Set(apk))
println("Component based analysis done.")
This code runs for more than 5 hours to analyze an apk that is only 12.4M, and ends with "java.lang.OutOfMemoryError: Java heap space"... My computer is 32G ram and i7-4790K. I'm very confused by this, am I missing something? By the way, if I'm only interested in some classes' idfg, can I customize the entry point to generate a idfg?
If you can give me the apk to test, that will be helpful for me to see why it take that much time. Yes, you can customize the entry points. The code at: https://github.com/arguslab/Argus-SAF/blob/68f87fd596a06f5a6b2f6a4303bbc709005df3cd/org.argus.amandroid/src/main/scala/org/argus/amandroid/alir/componentSummary/ComponentBasedAnalysis.scala#L49 will give you some idea of how to obtain idfg directly for an entry point.
Very sorry for the late reply... This apk was tested for more than 8 hours with the code above... https://www.dropbox.com/s/p0b58a0xc62dos0/news_and_magazines-1Mobile%20Market%20Lite_v6.6.4_apkpure.com.apk?dl=0 Thank you for your kind help!
Yeah, it takes quite some time due to it's component size. One possible solution is to first filter out non-interesting components, only perform analysis on those interested ones.
Some idea of doing that you can get from issue #16
The new data-flow solver is under implementation, that will reduce this performance issue dramatically.
Yes, I've already seen the solution of that issue, that seems the best solution right now. Expect next version of your great work, thank you~