1. 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

2. 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.

3. 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

4. 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

5. 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

6. 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

7. 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

8. 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

9. 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

10. 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

11. 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.

12. 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.

13. 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

14. Thank you for listening 
Questions?