1. On the Effectiveness of API-Level Access Control Using Bytecode Rewriting in Android Presenter: Lu Gong

2. Authors Students: Hao Hao, Vicky Singh Professor: Wenliang (Kevin) Du Dept. of EE & CS, Syracuse University, New York 1

3. The Conference AsiaCCS: –ACM Symposium on Information, Computer and Communications Security Rank C in the CCF recommendation list –Network and Information Security 2

4. The paper The first systematic study on the effectiveness of using bytecode rewriting for API-level access control Cited by: –Structural detection of android malware using embedded call graphs (AISec ’13) –Compac: Enforce Component-Level Access Control in Android (ACM CodaSpy ’14) 3

5. Background (1/3) Bytecode rewriting –Use static analysis to identify sensitive API calls –Instrument bytecode to control access –Aim at implement fine-grained access control 4

6. Background (2/3) API-Level Access Control 5

7. Background (3/3) Method invocation instructions: –invoke-virtual: used to invoke a normal virtual method –invoke-direct: used to invoke either a private instance method or a constructor –invoke-static: used to invoke a static method –invoke-interface: used to invoke an interface method on an object whose concrete class is not known –invoke-super: used to invoke the closest superclass’ virtual method 6

8. Scoping (1/5) Two kinds of byte-code rewrite mechanisms: 1.Put the reference monitor in another service 2.Put the reference monitor within the application Only focus on the second approach –Because the first one is fail-safe 7

9. Scoping (2/5) Assumption –The application either do not have native code or their native code is blocked from being executed Reasons –Native code is running in the same process space as DVM –With native code, the app can easily tamper the DVM state, thus byte-code rewriting is useless 8

10. Scoping (3/5) Privileged resources –Hardware devices –Kernel data –Data from another process space Ways to access them –System calls –Inter-process communication 9

11. Scoping (4/5) 10

12. Scoping (5/5) Concealing API usage (the 4 th attack) is possible –Java reflection –Dynamic binding 11

13. Prelude (1/2) Byte-code rewriting for a non-final class 12

14. Prelude (2/2) Byte-code rewriting for a final class 13

15. Methodology 1.Study all possible attacks against bytecode rewriting 2.Give deeper insight into the attacks 3.Make recommendations on how to defend against these attacks 14

16. Exploit JNI Naming Convention 15

17. The JNI naming convention 16

18. Dynamic binding 17

19. The problem Java_MyClass_my_1Func MyClass.my.1Func() MyClass.my_Func() 18

20. Case study 19

21. Recommendations If any names starts with numbers, bytecode rewriter should remove the digit as it is illegal. 20

22. Exploit Java Class Reloading 21

23. Example 22

24. Case Study (1/2) 23

25. Case Study (2/2) 24

26. 25

27. Recommendations Stop application’s Java code from reloading preloaded Android core classes –BaseDexClassLoader.findClass() –DexFile.loadClass() 26

28. Exploit Customized RPC stubs 27

29. Case Study (1/2) 28

30. Case Study (2/2) 29

31. 30

32. Recommendation Apply API-level access control on android.os.ServiceManager.getService() Alternative: rewrite android.os.Binder 31

33. Conclusion Although all problems are fixable, more static analysis and dynamic checking should be performed while byte-code rewriting 32

34. Thank you