Best Practice: Dynamic Analysis

  1. Go over Static Results(What permissions are we looking for, etc)
    1. The first step in the dynamic analysis is compiling the results of your static analysis. The static analysis process is the key to setting up a proper test case for the application. After static analysis, you should have, at the least, the following items:
      1. List of Permissions
      2. Code snippets of suspect code
      3. Notes including any other interesting findings
  2. Based on Code Analysis, what do you expect to see happen?
    1. Once you have all of the data compiled from the static analysis process, it’s time to start thinking about how the application is going to run. Looking at the code of the application is the best way to see how an application is going to behave. Once you have a good idea on how the application is going to behave, the next step is designing a test scenario to confirm your findings.
  3. Design "test" scenario(How many devices? What will you need to install? Etc)
    1. Now that you have compiled your static analysis results and examined the code of the application, you can begin to set up a test scenario to confirm your hypothesis. Based on the results so far, you can plan a test that will confirm your findings.
    2. For example, if you have an application you think is stealing sms messages sent to a device, a smart test would be to boot up 2 Android Virtual Devices and test their interaction. This was the case with the Trusteer Rapport application. (More Information: http://osaf-community.org/threatindex.html)(external link) We tested our hypothesis by sending sms messages to an infected device from a clean device, and the sms messages were never received. This confirmed our hypothesis and allowed us to confidently say that this application was a Severe
    3. For more information on using Android Virtual Devices, a crucial part of Dynamic Analysis, see our How To on AVD Basics: http://osaf-community.org/wiki/tiki-index.php?page=Android+Virtual+Device+Basics(external link)
  4. Execute "test" scenario paying special attention to results
    1. With the test scenario planned, it’s time to actually run the application in a sandboxed environment to confirm your hypothesis! Before you begin it is important that you properly document everything that happens during the test. Many times you will find interesting things about the application in places you didn’t even think were crucial to the test. For example, even if you do not expect any network activity from an application, it’s still important to always have Wireshark running during a test.
  5. Record results(Notes, screenshots, etc)
    1. Once your test has completed, and you have gathered as much evidence as possible, it is time to compile and report on the application. Once you are confident that your investigation is complete, you can submit it to the OSAF Team at https://docs.google.com/spreadsheet/viewform?pli=1&formkey=dEtSMjFMazQxOXllUlUtVlBxZENhQ1E6MQ#gid=0(external link)
    2. Once we review the report, your investigation will be posted on the OSAF website for others to learn from!