Presented by Xiaohui (Amy) Lin Harvesting Runtime Values in Android Applications That Feature Anti-Analysis Techniques Siegfried Rasthofer, Steven Arzt, Marc Miltenberger, 2016 Presented by Xiaohui (Amy) Lin

Introduction Malware can be highly obfuscated -> how to distinguish malicious apps from the benign ones? Inspecting runtime values (targets of reflective method calls, what databases are being used, URL which data is being sent to) Limitations of static analysis Many current static analyses can’t handle reflection Can’t handle runtime (dynamically computed) values either Limitations of dynamic analysis Malware can trick dynamic analyses by suppressing malicious activity if the app detects it is executing within an analysis environment 1. Runtime values Another dynamic analysis limitation: 1. You have to find the execution path that actually triggers the method call. Furthermore, malware may only be triggered when a user clicks on a certain button, so analysis tools would have to perform all user interactions required to reach that button.

Introducing… Harvester An automation tool for extracting runtime values from obfuscated malware code Addresses the limitations of Static and Dynamic analysis tools What does this code on the right do? FakeInstaller has tried to hide its method calls in an encrypted format which can only be decrypted at runtime At runtime, the analysis discovers that it is calling SMSManager.sendTextMessage() Harvester reports the telephone numbers messages are being sent to and the bodies of the SMS messages sent Real life Malicious code from FakeInstaller

How it works from the user’s perspective Provide the .apk to get runtime values for Pick a provided category you want to extract runtime values for Generic categories available: URL, shell commands, SMS number, SMS text, File, reflection, Webview Harvester does the rest For example, if I chose the SMS number category, Harvester would return all the SMS numbers that are computed/used during app execution time

How Harvester works 1. Static Backward Slicing 2. Dynamic Execution of Reduced APK 3. Runtime Value Injection (optional) In the last step, Runtime Value Injection, it can restart the Harvesting process again. We will look at this in depth late

1. Static Backward Slicing Fig 2: A simplified example “A program slice is obtained from a program, P by removing statements such that the slice replicates behavior P with respect to the slicing criterion” Slicing criterion is the values of interested selected by the user Clazz, method and messageText are our slicing criterion Line 6/7 is also known as the logging point Gets rid of code that are not of interest

1. Static Backward Slicing (cont.) Fig. 2: A simplified example No data dependency between the slicing criterion and the emulator check means we can replace predicates with a global Boolean flag This break the dependency between an app’s execution and it’s execution environment In general, Harvester only replaces conditions that are environment- dependent This if statement has a check that detects if the malicious app is being run in a testing environment. Recall that one of the limitations of dynamic analysis tools is that it may never execute malicious code due to these checks. But since there is no data dependency between the slicing criterion and the if statement, we can replace the predicate with a Boolean flag. This breaks the dependency between an app’s execution and it’s execution environment. Harvester would have to explore every possible combination of branches to retrieve all values of interest. However, can’t replace stuff like if ( i< 3) else we could get infinite looping, or return incorrect values, can get pass this by setting out a time out value

2. Dynamic Execution of APK Returns all values of interest Combine slices computed from the previous step together into a new single method The new reduced APK does not contain any GUI from the original application Addresses another limitation of dynamic analysis 3. Runtime Value Injection (optional) B. If a button triggers some method calls, a user or an automated test driver would need to manually click the button themselves. Instead, Harvester removes all GUI components and instead executes these methods calls directly. C. Programs such as FlowDroid can analyze apps with ease as they don’t need to handle the reflection themselves. For example, Flowdroid detected only 9 leaking's of private data, but when used with Harvester they detected 26 leaks Is for helping existing analysis tools They do this by removing the reflective calls with direct calls to the API

3. Runtime Value Injection (cont.) Logging point can not be identified for some highly obfuscated cases Harvester can be configured to run again First retrieve targets of all reflective method calls Then retrieve the telephone number and/or text messages for the invoked calls So continuing on with runtime value injection, this stage can actually loop back to the static backward slicing

So how effective is Harvester? Tested with 12 malware samples from some of the most sophisticated malware families (FakeInstaller, Pincer, GinMaster) Precision 86.6% accuracy 100% recall - all values extracted were runtime values Only aborted in less than 1% of cases (timeout value of 10 minutes) Efficiency On average takes 2 ½ minutes to run per .apk sophisticated because thy rely heavily on reflection to hide their method calls. 86.6% = % of detected values out of all logging points specified

Weaknesses as identified by the article Hiding the logging point If method calls are called using native code e.g. sendTextMessage(), it can not be used as a logging point Values of interest contained in program slices that span multiple Android components (e.g. Activities) are not supported Attacking the completeness of Values of Interests If values of interest are computed from external resources such as a server, Harvester assumes this data to be static 1. Therefore it may not be able to return the values of interest. 2. So if a value computed in one activity is sent to the second activity which contains the logging point, the value of interest would be lost. 3. However, in reality this data may be changing. For example, target phone numbers for an SMS messaging scam can change every day. Harvester would only be able to recover the phone number for that present day.

My Criticism #1 Overall, I would use Harvester because it automates the process for me and I don’t need to do much to use the program. However… How to prove the correctness of the runtime values being returned? GUI: didn’t provide any examples of user interfaces Is it a command line tool or does it come with a GUI? Are the runtime values returned presented in a user friendly manner? This article met my expectations as it gave an in-depth review of how Harvest works on the inside… You could just return some numbers which makes it hard for the user to read.

My Criticism #2 Experiments: didn’t specify a reason as to why they set the timeout value as 10 minutes Attackers can just purposely add even more code which means the timeout threshold would be met and the program would just stop 2.5 minutes to run per .APK: very generic as it didn’t specify the file sizes of these .APK I would also suggest to them that they make the timeout threshold modifiable

Thank you for listening  Questions?