Xây dựng đồ thị luồng điều khiển từ mã nhị phân ứng dụng android

ĐẠI HỌC QUỐC GIA TP HCM TRƯỜNG ĐẠI HỌC BÁCH KHOA NGUYỄN HỮU HOÀNG XÂY DỰNG ĐỒ THỊ LUỒNG ĐIỀU KHIỂN TỪ MÃ NHỊ PHÂN ỨNG DỤNG ANDROID Ngành: KHOA HỌC MÁY TÍNH Mã số: 60.48.01 LUẬN VĂN THẠC SĨ TP HỒ CHÍ MINH, tháng 12 năm 2016 ĐẠI HỌC QUỐC GIA TP HCM TRƯỜNG ĐẠI HỌC BÁCH KHOA NGUYỄN HỮU HOÀNG XÂY DỰNG ĐỒ THỊ LUỒNG ĐIỀU KHIỂN TỪ MÃ NHỊ PHÂN ỨNG DỤNG ANDROID Ngành: KHOA HỌC MÁY TÍNH Mã số: 60.48.01 LUẬN VĂN THẠC SĨ TP HỒ CHÍ MINH, tháng 12 năm 2016 CƠNG TRÌNH ĐƯỢC HỒN THÀNH TẠI TRƯỜNG ĐẠI HỌC BÁCH KHOA - ĐHQG - HCM Chữ ký Cán hướng dẫn khoa học: PGS TS Quản Thành Thơ Cán chấm nhận xét 1: TS Võ Thị Ngọc Châu Cán chấm nhận xét 2: PGS TS Lê Trung Quân Luận văn thạc sĩ bảo vệ Trường Đại học Bách Khoa, ĐHQG Tp HCM ngày 30 tháng 12 năm 2016 Thành phần Hội đồng đánh giá luận văn thạc sĩ gồm: PGS TS Dương Tuấn Anh TS Nguyễn Đức Dũng TS Võ Thị Ngọc Châu PGS TS Lê Trung Quân PGS TS Đỗ Phúc Xác nhận Chủ tịch Hội đồng đánh giá luận văn Trưởng Khoa quản lý chuyên ngành sau luận văn chỉnh sửa (nếu có) CHỦ TỊCH TRƯỞNG KHOA Hội đồng Khoa học Kỹ thuật Máy tính PGS TS Dương Tuấn Anh ĐẠI HỌC QUỐC GIA TP.HCM TRƯỜNG ĐẠI HỌC BÁCH KHOA —————- CỘNG HÒA XÃ HỘI CHỦ NGHĨA VIỆT NAM Độc lập - Tự - Hạnh phúc —————- NHIỆM VỤ LUẬN VĂN THẠC SĨ Họ tên học viên: Nguyễn Hữu Hoàng MSHV: 7140234 Ngày, tháng, năm sinh: 21-01-1990 Nơi sinh: Đồng Tháp Chuyên ngành: Mã ngành: 60.48.01 Khoa học Máy tính I TÊN ĐỀ TÀI: Xây dựng đồ thị luồng điều khiển từ mã nhị phân ứng dụng Android II NHIỆM VỤ VÀ NỘI DUNG: Luận văn có nhiệm vụ nghiên cứu việc xây dựng đồ thị luồng điều khiển từ mã nhị phân Android Luận văn đề xuất hướng tiếp cận tập trung xây dựng đồ thị luồng điều khiển cho hệ thống ứng dụng Android, từ khai thác để tìm rò rỉ bảo mật hệ điều hành Bên cạnh đó, giúp lập trình viên nắm bắt cách thức giao tiếp hệ thống ứng dụng Android III NGÀY GIAO NHIỆM VỤ: ngày 11 tháng 01 năm 2016 IV NGÀY HOÀN THÀNH NHIỆM VỤ: ngày 02 tháng 12 năm 2016 V CÁN BỘ HƯỚNG DẪN: PGS TS Quản Thành Thơ Tp HCM, ngày tháng năm 2017 CÁN BỘ HƯỚNG DẪN TRƯỞNG KHOA (Họ tên chữ ký) Khoa học Kỹ thuật Máy tính (Họ tên chữ ký) PGS TS Quản Thành Thơ Lời cảm ơn Trong trình nghiên cứu, tơi nhận nhiều giúp đỡ đóng góp từ giáo sư hướng dẫn, đồng nghiệp, bạn bè thành viên đình Khi gặp khó khăn cơng việc, họ ln cho lời khuyên chân thành hiệu để giúp tơi hồn thành tốt nghiên cứu Tơi vơ biết ơn PGS TS Quản Thành Thơ PGS TS JIANG Lingxiao Các giáo sư hướng dẫn ý tưởng khuyến khích tơi xa nghiên cứu Họ hỗ trợ cho nguồn lực tạo cho điều kiện đến thực tập trường Singapore Management University trình thực luận văn Tôi muốn gửi lời cảm ơn tới anh Nguyễn Minh Hải, anh Đoàn Thành Nam, anh Hoàng Văn Đức Thơng, TS Hồng Tuấn Anh, La Thành Tâm, Phạm Hồng Quang Họ vừa bạn vừa đồng nghiệp tơi q trình tơi thực tập, làm việc trường Đại học Bách khoa Tp HCM Singapore Management University Họ giúp đỡ cho lời khun hữu ích suốt q trình nghiên cứu Tôi muốn gửi lời cảm ơn chân thành đến PGS TS Rajesh Krishna BALAN đồng nghiệp Livelabs Singapore Management University Họ hỗ trợ cung cấp thiết bị, tài nguyên tốt cho làm việc phịng thí nghiệm Cuối cùng, tơi xin cảm ơn gia đình tơi ln bên cạnh ủng hộ tạo điều kiện tốt để tơi tập trung cho việc nghiên cứu Tp HCM, ngày 02 tháng 12 năm 2016 Nguyễn Hữu Hoàng Abstract Android has become the most popular mobile system Millions of applications, including many malwares, haven been developed for it Since Android itself evolves constantly with changing features and higher complexities, it is challenging for application developers to keep up with the changes and maintain the compatibility of their apps across Android versions; and it is challenging for application analysis tools to accurately model and analyze app behaviors across Android versions Even though the overall system architecture of Android and many APIs are documented, many other APIs and implementation details are not, not to mention potential bugs and vulnerabilities Techniques and tool supports are thus needed to automatically extract information from different versions of Android to help programmers understand system behaviors and APIs across different versions This paper aims to address the need It performs whole-system analysis for different versions of Android by using both backward and forward static analysis of intra-procedural and inter-procedural control-flow and data-flow graphs It can collect information about functions in Android that can be invoked by applications, which are referred to as publicly accessible functions in this paper Such information can help programmers better understand the ways in which their applications utilize system functions We have analyzed Android versions 4.1.1, 4.2.2, 4.3, 4.4.4, 5.1.0, 6.0.1, and show basic statistics about the publicly accessible functions in different Android versions We also use an example to illustrate that the information about publicly accessible functions can be useful in identifying unprotected system functions whose invocations may not be protected by proper permissions and may lead to security and privacy violations Tóm tắt Android trở thành hệ thống di động phổ biến Hàng triệu ứng dụng kể loại mã độc phát triển cho Bởi Android liên tục phát triển với thay đổi tính ngày phức tạp hơn, trở thành thách thức cho nhà phát triển để theo kịp với thay đổi trì khả tương thích ứng dụng họ phiên Android khác nhau; thách thức cho công cụ phân tích ứng dụng, nhằm mơ xác đồng thời phân tích hành vi ứng dụng phiên Android Mặc dù kiến trúc tổng thể nhiều hàm API cung cấp tài liệu, nhiều API khác lại khơng có tài liệu chi tiết, chưa kể đến lỗi lỗ hỏng tiềm ẩn Do đó, cần thiết có kỹ thuật cơng cụ để tự động trích xuất thơng tin từ phiên Android khác để giúp lập trình viên hiểu hành vi hệ thống API khác Nghiên cứu nhằm giải nhu cầu đó, thực phân tích tồn hệ thống phiên Android khác nhau, cách sử dụng hai phân tích tĩnh ngược xi dịng intra-procedural inter-procedural dựa đồ thị luồng điều khiển liệu Đồng thời thu thập thông tin hàm gọi ứng dụng, gọi hàm truy cập công khai nghiên cứu Những thơng tin giúp lập trình viên hiểu rõ cách thức ứng dụng họ sử dụng chức hệ thống Chúng tơi phân tích phiên Android 4.1.1, 4.2.2, 4.3, 4.4.4, 5.1.0, 6.0.1 đưa số liệu thống kê hàm truy cập công khai phiên Chúng tơi dùng ví dụ để minh họa thơng tin hàm truy cập cơng khai hữu ích việc xác định hàm hệ thống không bảo vệ quyền truy cập thích hợp dẫn đến hành vi xâm phạm bảo mật riêng tư Lời cam đoan Tôi xin cam đoan nghiên cứu luận văn hồn tồn tơi xây dựng ghi nhận q trình tơi học tập Khoa Khoa học Kỹ thuật Máy tính, trường Đại học Bách Khoa, Đại học Quốc gia Việt Nam TP HCM q trình tơi thực tập Livelabs, School of Information Systems, Singapore Management University Một phần nghiên cứu công bố hai báo cáo khoa học đây: Poster: Android Whole-System Control Flow Analysis for Accurate Application Behavior Modeling In Proceedings of the 14th Annual International Conference on Mobile Systems, Applications, and Services Companion (MobiSys ’16 Companion) ACM, New York, NY, USA, 30-30 DOI: http://dx.doi.org/10.1145/2938559.2948874 Whole-System Analysis For Understanding Publicly Accessible Functions In Android In Proceedings of the 11th South East Asean Technical University Consortium Symposium (SEATUC 2017) Ho Chi Minh City, Vietnam March 2017 Nguyễn Hữu Hoàng Mục lục Giới thiệu 1.1 Lí nghiên cứu 1.2 Mục tiêu nghiên cứu Cơ sở lý thuyết 2.1 Tổng quan Android 2.2 Các dịch vụ hệ thống 2.3 Cấu trúc Android Package định dạng DEX Nghiên cứu liên quan 11 3.1 Các bước xây dựng phân tích đồ thị gọi 11 3.2 Công cụ framework phân tích bytecode 12 3.3 Các mục đích nghiên cứu 14 3.4 Phương pháp phân tích 16 Hướng tiếp cận 19 4.1 Tổng quan hướng tiếp cận 19 4.2 Những thách thức 20 4.3 Hàm truy cập công khai 21 4.4 Hiểu hàm hệ thống Android kiểm tra quyền truy cập 22 Đánh giá 24 5.1 Thiết lập 24 5.2 Tóm tắt kết 24 5.3 Thảo luận 31 Kết luận 32 Tài liệu 33 Phụ lục 39 8.1 Các báo công bố 39 8.2 Lý lịch trích ngang 51 GIỚI THIỆU Giới thiệu 1.1 Lí nghiên cứu Ra đời năm 2007, hệ điều hành Android đạt phát triển nhanh chóng, năm 2016 Android chiếm 80% thị phần hệ điều hành di động toàn cầu [19] Hệ điều hành có triệu nhà phát triển ứng dụng tính tới năm 2014 [18] Do đó, để giúp lập trình viên, đặc biệt người làm quen, phát triển ứng dụng cách nhanh chóng nắm bắt kiến trúc hệ điều hành tất API cung cấp việc cần thiết Khi đó, nhà phát triển hiểu cách thức mà hệ điều hành quản lý ứng dụng gọi chức muốn sử dụng thông qua API Mặc dù kiến trúc hệ thống Android số API cung cấp tài liệu, nhiên Android phát triển trải dài từ phiên 1.0 đến Nougat 7.0, gây khơng tương thích phiên thiếu quán hành vi mã thực tế với tài liệu Ngoài cịn có API khơng cơng bố tài liệu sử dụng từ ứng dụng, bên cạnh cịn có lỗi lỗ hỏng hệ điều hành bị ứng dụng khai thác với mục đích xấu Việc hiểu hành vi hệ thống API trở nên khó khăn với phân mảnh hệ điều hành Android: có 1000 thương hiệu 24.000 loại điện thoại vào năm 2015 [38]; nhà sản xuất tùy chỉnh hệ thống Android theo cách khác thường khơng cung cấp đủ tài liệu cho lập trình viên Việc theo dõi hiểu mối quan hệ API hệ thống khác việc đọc tài liệu duyệt thủ công mã nguồn tốn thời gian dễ phát sinh lỗi Những yêu cầu cần phải hỗ trợ cơng cụ hoạt động phần hệ thống phiên Android khác Trong lĩnh vực phân tích tĩnh hệ thống ứng dụng Android, có nhiều nghiên cứu tập trung vào phân tích ứng dụng Android [8, 28, 41, 47], nghiên cứu đòi hỏi kiến thức chuyên sâu mơ hình hệ thống Android vịng đời callbacks sử dụng để quản lý activity ứng dụng [1], back stack sử dụng hệ thống để quản lý activity thực TÀI LIỆU [36] D Octeau, P McDaniel, S Jha, A Bartel, E Bodden, J Klein, and Y Le Traon, “Effective inter-component communication mapping in android: An essential step towards holistic security analysis,” in Presented as part of the 22nd USENIX Security Symposium (USENIX Security 13), 2013, pp 543–558 [37] Open Handset Alliance, “Industry leaders announce open platform for mobile devices,” http://www.openhandsetalliance.com/press_110507 html, Nov 2007 [38] OpenSignal, “Android fragmentation visualized,” http://opensignal com/reports/2015/08/android-fragmentation/, August 2015 [39] B Pan, “Dex2jar,” https://github.com/pxb1988/dex2jar, Sep 2014 [40] É Payet and F Spoto, “Static analysis of android programs,” Information and Software Technology, vol 54, no 11, pp 1192–1201, 2012 [41] S Rasthofer, S Arzt, and E Bodden, “A machine-learning approach for classifying and categorizing android sources and sinks,” in 21st Annual Network and Distributed System Security Symposium, NDSS, 2014 [42] S Rasthofer, S Arzt, E Lovat, and E Bodden, “Droidforce: enforcing complex, data-centric, system-wide policies in android,” in Availability, Reliability and Security (ARES), 2014 Ninth International Conference on IEEE, 2014, pp 40–49 [43] Sable Research Group, “Soot: A framework for analyzing and transforming java and android applications,” https://sable.github.io/soot/, 2016 [44] R Vallée-Rai, P Co, E Gagnon, L Hendren, P Lam, and V Sundaresan, “Soot-a java bytecode optimization framework,” in Proceedings of the 1999 conference of the Centre for Advanced Studies on Collaborative research IBM Press, 1999, p 13 [45] K Yaghmour, “Internals primer,” in Embedded Android O’Reilly Media, Mar 2013, pp 25–78 37 TÀI LIỆU [46] D Yan, G Xu, and A Rountev, “Rethinking Soot for summary-based whole-program analysis,” in ACM SIGPLAN International Workshop on the State Of the Art in Java Program Analysis @ PLDI, 2012, pp 9–13 [47] S Yang, D Yan, H Wu, Y Wang, and A Rountev, “Static control-flow analysis of user-driven callbacks in Android applications,” in International Conference on Software Engineering, 2015, pp 89–99 [48] Z Yang, M Yang, Y Zhang, G Gu, P Ning, and X S Wang, “Appintent: Analyzing sensitive data transmission in android for privacy leakage detection,” in Proceedings of the 2013 ACM SIGSAC conference on Computer & communications security ACM, 2013, pp 1043–1054 [49] M Zhang and H Yin, “Appsealer: Automatic generation of vulnerability-specific patches for preventing component hijacking attacks in android applications.” in NDSS, 2014 38 PHỤ LỤC Phụ lục 8.1 Các báo cơng bố Trong q trình xây dựng luận văn, công bố hai báo khoa học hội nghị quốc tế MobiSys’16 Companion SEATUC 2017 Poster: Android Whole-System Control Flow Analysis for Accurate Application Behavior Modeling • Paper name: Poster: Android Whole-System Control Flow Analysis for Accurate Application Behavior Modeling • Author: Nguyen Huu Hoang • Conference: 14th Annual International Conference on Mobile Systems, Applications, and Services Companion (MobiSys ’16 Companion) • Conference day: June 2016 • Location: Singapore • Publisher: ACM, New York, NY, USA 39 Poster: Android Whole-System Control Flow Analysis for Accurate Application Behavior Modeling NGUYEN Huu Hoang School of Information Systems, Singapore Management University hhnguyen@smu.edu.sg ABSTRACT (2) We model interactions between system and apps through GUI elements, callbacks, and system calls, from both system and application bytecode; (3) We design algorithms for analyzing the whole-system graphical representations of the system and app code to identify points of interest more accurately, such as private data leaks Our approach is based-on Soot framework with call graph construction systems such as Spark and the incremental BDD propagation algorithm [3] Android, the modern operating system for smartphones, together with its millions of apps, has become an important part of human life There are many challenges to analyzing them It is important to model the mobile systems in order to analyze the behaviors of apps accurately These apps are built on top of interactions with Android systems We aim to automatically build abstract models of the mobile systems and thus automate the analysis of mobile applications and detect potential issues (e.g., leaking private data, causing unexpected crashes, etc.) The expected results will be the accuracy models of actual various versions of Android system and apps for top apps selected from Google Play Store EVALUATION We evaluate our approach on recent major different versions of Android systems and top apps from Google Play Store First, we focus on the comprehensiveness and accuracy of the abstract models for Android systems, such as various event handlers and thread handlers Second, we measure the coverage and precision of the models for apps when analyzed together with system models Third, we measure test coverages and issue exposition rates for crashes and private data leaks in apps, and compare analysis results against other tools, such as Flow Droid [1] CCS Concepts • Software and its engineering~Automated static analysis Keywords Android system; Android application; whole-system analysis; control flow; data flow; static analysis; modeling INTRODUCTION Android users were able to choose millions of apps The analysis of these application becomes necessary There are some approaches were released such as Flow Droid [1], GATOR [4], IccTA [2] However, these approaches just analyze the control/data flow inside Android apps Different from many studies on mobile application analysis built on top of manually constructed and assumed to be correct behavior models of the system (e.g., lifecycle APIs for Android apps, asynchronous task APIs, etc.) RELATED WORK We aim to automatically build the models for the Android systems and identify its interaction points with any mobile application Then, we carry out mobile application analysis based on combined models of the system and the app We build a prototype system that can construct and visualize the interaction model between the system and apps Our system models whole-system control flow for accurate app behaviors With automatically built models, we can deal with various versions of the systems We don't have to assume the availability and the correctness of the system models In addition, we aim to enable a grey-box directed testing of apps that can reveal application behaviors more comprehensively to detect app crashes and private data leaks more accurately This research is supported by the NRF, Prime Minister’s Office, Singapore under its IDM Futures Funding Initiative Static analysis the accurate behavior is essential for modeling the control flow of Android applications There are some approaches such as GATOR [4], a control-flow analysis of user-event-driven callbacks, or IccTA [2], detecting inter-component privacy leaks in Android apps CONCLUSIONS ACKNOWLEDGMENTS REFERENCES [1] Arzt, S., Rasthofer, S., Fritz, C., Bodden, E., Bartel, A., Klein, J., & APPROACH [2] Our approach focuses on whole-system modeling of Android system and application code We follow the steps as (1) We model Android system behaviors involving system bootstrapping, application start-up, event handling, to automatically construct whole-system control-flow and call graphs; McDaniel, P (2014, June) Flowdroid: Precise context, flow, field, object-sensitive and lifecycle-aware taint analysis for android apps In ACM SIGPLAN Notices (Vol 49, No 6, pp 259-269) Li, L., Bartel, A., Bissyandé, T F., Klein, J., Le Traon, Y., Arzt, S., & McDaniel, P (2015, May) IccTA: Detecting inter-component privacy leaks in Android apps In Proceedings of the 37th International Conference on Software Engineering-Volume (pp 280-291) IEEE Press [3] Vallée-Rai, R., Co, P., Gagnon, E., Hendren, L., Lam, P., & Sundaresan, Permission to make digital or hard copies of part or all of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation on the first page Copyrights for third-party components of this work must be honored For all other uses, contact the Owner/Author Copyright is held by the owner/author(s) MobiSys'16 Companion, June 25-30, 2016, Singapore, Singapore ACM 978-1-4503-4416-6/16/06 http://dx.doi.org/10.1145/2938559.2948874 [4] 30 V (1999, November) Soot-a Java bytecode optimization framework In Proceedings of the 1999 conference of the Centre for Advanced Studies on Collaborative research (p 13) IBM Press Yang, S., Yan, D., Wu, H., Wang, Y., & Rountev, A (2015, May) Static control-flow analysis of user-driven callbacks in Android applications InProceedings of the 37th International Conference on Software Engineering-Volume (pp 89-99) IEEE Press Android Whole-System Control Flow Analysis for Accurate Application Behavior Modeling NGUYEN Huu Hoang School of Information Systems, Singapore Management University Motivation Whole-system call graph • Android, the modern operating system for smartphones, together with its millions of apps, has become an important part of human life • These apps are built on top of interactions with Android systems • Analysis of these application becomes necessary • It is important to model the mobile systems in order to analyze the behaviors of apps accurately Approach • • • • • Our approach focuses on whole-system modeling of Android system and application code We model Android system behaviors involving system bootstrapping, application start-up, event handling We model interactions between system and apps through GUI elements, callbacks, system calls The model could be used to identify points of interest more accurately, such as private data leaks, unwanted purchases Our approach has the challenges in the analysis such as scalability in handling huge graphs via summary-based call graph analysis Call graph of word card app Interactions of system and callbacks Evaluation • We evaluate our approach on Android ICS 4.0 to Marshmallow 6.0 and top apps from Google Play Store • We focus on the comprehensiveness and accuracy of the abstract models for Android systems • We measure the coverage and precision of the models for apps when analyzed together with system models • We measure test coverages and issue exposition rates for crashes and private data leaks in apps, and compare analysis results against other tools Reference [1] Arzt, S., Rasthofer, S., Fritz, C., Bodden, E., Bartel, A., Klein, J., & McDaniel, P (2014, June) Flowdroid: Precise context, flow, field, objectsensitive and lifecycle-aware taint analysis for android apps In ACM SIGPLAN Notices (Vol 49, No 6, pp 259-269) [2] Yang, S., Yan, D., Wu, H., Wang, Y., & Rountev, A (2015, May) Static control-flow analysis of user-driven callbacks in Android applications In Proceedings of the 37th International Conference on Software EngineeringVolume (pp 89-99) IEEE Press PHỤ LỤC Whole-System Analysis For Understanding Publicly Accessible Functions In Android • Paper name: Whole-System Analysis For Understanding Publicly Accessible Functions In Android • Authors: Nguyen Huu Hoang, Lingxiao Jiang, Quan Thanh Tho • Conference: 11th South East Asean Technical University Consortium Symposium (SEATUC 2017) • Conference day: March 2017 • Location: Ho Chi Minh City, Vietnam 42 The 11th SEATUC Symposium WHOLE-SYSTEM ANALYSIS FOR UNDERSTANDING PUBLICLY ACCESSIBLE FUNCTIONS IN ANDROID * Nguyen Huu Hoang (1) (2) , Lingxiao Jiang (2), Quan Thanh Tho (1) (1) Ho Chi Minh City University of Technology, Viet Nam (2) School of Information Systems, Singapore Management University, Singapore Email: hhnguyen@smu.edu.sg ABSTRACT Android has become the most popular mobile system Millions of applications, including many malwares, haven been developed for it Since Android itself evolves constantly with changing features and higher complexities, it is challenging for application developers to keep up with the changes and maintain the compatibility of their apps across Android versions; and it is challenging for application analysis tools to accurately model and analyze app behaviors across Android versions Even though the overall system architecture of Android and many APIs are documented, many other APIs and implementation details are not, not to mention potential bugs and vulnerabilities Techniques and tool supports are thus needed to automatically extract information from different versions of Android to help programmers understand system behaviors and APIs across different versions This paper aims to address the need It performs whole-system analysis for different versions of Android by using both backward and forward static analysis of intra-procedural and inter-procedural control-flow and data-flow graphs It can collect information about functions in Android that can be invoked by applications, which are referred to as publicly accessible functions in this paper Such information can help programmers better understand the ways in which their applications utilize system functions We have analyzed Android versions 4.1.1, 4.2.2, 4.3, 4.4.4, 5.1.0, 6.0.1, and show basic statistics about the publicly accessible functions in different Android versions We also use an example to illustrate that the information about publicly accessible functions can be useful in identifying unprotected system functions whose invocations may not be protected by proper permissions and may lead to security and privacy violations * This work is done when the first author is a visiting student in the School of Information Systems at Singapore Management University KEYWORDS: android, call graph, control flow analysis, data flow analysis, program comprehension, permission check INTRODUCTION Android now accounts for more than 80% of the global smartphone operating system (OS) market [8] There have been more than million mobile application programmers worldwide in 2014 [7] To help programmers, especially novice ones, to develop applications for a mobile OS quickly, often a first step is to get them become familiar with the architecture of the mobile OS and all APIs available in the OS so that programmers can structure their apps according to the ways in which the OS manages apps and be able to invoke needed OS functionalities via the APIs Even though the overall system architecture of Android and many of its APIs are documented, many APIs have evolved much across different versions of the Android system from API level to API level 24 for Nougat 7.0, exhibiting different behaviors and causing incompatibility across versions and inconsistencies between actual code behaviors and the documentations There are also many undocumented APIs in the system that could be invoked by apps, not to mention many potential bugs and vulnerabilities that can be exploited by apps too Understanding system behaviors and APIs becomes even more challenging when Android faces the fragmentation problem: there are over 1000 brands and more than 24000 models of Android phones in 2015 [15]; the manufacturers of the brands and models often customize the Android system for their phones in different ways without sufficient documentations for programmers Manually going through documents and source code to track and understand the relations among different system APIs and behaviors is very time-consuming and errorprone; such tasks should be facilitated by tools (e.g., code navigation via Android X Ref [6]) that can work across different versions and fragments of the system The 11th SEATUC Symposium Designed by Freepik.com SystemServer.main Code Code in various  Android in various  languages System languages Code (1) Construction of  call graphs and  control‐flow graphs (2) Understanding publicly  accessible functions (Intra‐ and inter‐procedural  control‐ and data‐flow analysis) Relations  among  objects and  functions (3) Application on  verifying permission  checks for system APIs Fig Approach Overview In the area of static analysis of Android systems and applications, much work [4,12,16,19] that focuses on analyzing Android applications require expert knowledge and models of the Android systems, such as the lifecycle callbacks used by the system to manage individual app activities [1], the back stack used in the system to manage sets of running activities [2], etc Such expert (and manual) modelling of the systems cannot keep up with the evolution and fragmentation of the systems, leading to inaccurate models and analysis results So, there are also needs to automate the modeling of various versions of the Android system, and more generally, to automate the modeling of large-scale frameworks and libraries used for application development, so that analysis of apps can be more accurate The ultimate goal of this work is to achieve automated modeling of Android systems and facilitate programmers to understand system behaviors and APIs One way towards this goal is to perform whole-program analysis of a version of Android together with an application, so as to avoid the need to manually construct a behavior model of the system before analyzing the app This way has been considered in the literature and comes with many challenges (e.g., [18]) This paper takes a first step to analyze whole Android systems in different versions, to automatically curate Android system functions that are accessible by applications, providing a “navigation map” for different versions of Android systems for programmers to understand what functionalities in different versions of Android systems can be invoked by which APIs Technically, we construct Java class hierarchies, call graphs and control-flow graphs for different versions of Android systems using the Soot analysis framework [17], and then identify public functions in Android that can be invoked by applications with suitable parameters that can be obtained by the applications too Such curated functions can reveal to programmers how system APIs, documented or undocumented, can be invoked in applications, helping them to understand the capabilities of the APIs We have analyzed six versions of Android: 4.1.1, 4.2.2, 4.3, 4.4.4, 5.1.0, 6.0.1, and curated publicly accessible functions from them The numbers of publicly accessible functions generally increase with increasing version numbers and Android code sizes, from about 53K to 74K Together with more analyses (e.g., checking whether permissions are added for publicly accessible functions to prevent unauthorized accesses), we aim to show that curated information about such functions can be useful in helping programmers understand system functions and revealing unprotected system APIs that may lead to security and privacy violations in Android The rest of the paper is organized as follows: Section briefly introduces related work; Section describes our approach; Section presents our actual setups and evaluations, and discusses our limitations and possible future work; Section concludes RELATED WORK The work in this paper is closely related to much work in static analysis of Android systems and applications Much work that focuses on analyzing Android applications require expert knowledge and models of the Android systems FlowDroid [4], was introduced in 2014, focuses on the private data leaks It performs static analysis on Android app based on inter-procedural control-flow and data-flow As a part of this work, they modeled the effects of callbacks by generating a dummy main method As shown by Li et al [12], IccTA performs intercomponent communication based taint analysis (ICC) They used a highly precise control-flow graph through instrumentation of the code of applications to detect ICC based privacy leaks CHEX [13] detects possible hijack-enabling flows through conducting low-overhead reachability tests on customized system dependence graphs They model the vulnerabilities from a data-flow analysis perspective The 11th SEATUC Symposium Fig The whole-system callgraph of Android version 4.4.4 In the study by Yang et al [19], they presented a control-flow representation or user-driven callback behavior based on context-sensitive analysis of event handlers They traverse context-compatible interprocedural control-flow paths and identify trigger callbacks of the statements to perform graph reachability In 2015, Rasthofer et al [16] described in detail the components of current state-of-the-art static and dynamic code analysis techniques of Android malware development They emphasize the challenges for automatic malware analysis frameworks These problems hinder the fully automatic detection of Android malicious components significantly Generally, the effectiveness of such analysis is prone to the inaccuracies of the manually constructed models of the systems This paper tries to work towards automated modeling of Android systems Thus, a major objective of the work is performed whole-program analysis of any version of Android system, so as to reduce the need for manually produced behavior models before analyzing an application, and to make the analysis of the application more accurate This objective on whole-program analysis has been considered in the literature For example, Yan et al [18] propose to extend Soot with summary-based analysis so as to scale up to whole-program analysis StubDroid [3] generates summaries for system/library APIs before performing data-flow analysis for applications Those studies focus on building summaries and models for automated application analyses, not application development; their outputs are not intended for programmers to read, and may not be useful for programmers who are developing applications and want to understand system APIs and behavior models better The work on this paper focuses more on the understandability of the whole systems, although techniques used in other work can be adapted for our purposes, and the outputs from our work may be used for both application analysis and system analysis, e.g., checking proper permission controls in Android systems and applications [5,11] APPROACH 3.1 Overview At a high level, our technical idea is straightforward as illustrated in Figure mainly consisting steps (1) For a version of Android, we collect all of its code, identify all Java classes involved, construct call graphs for the whole Android system from the system's main entry point (com.android.server.SystemServer) (2) Then, we identify potentially publicly accessible functions, and use data-flow and control-flow analysis based on the call graphs to identify objects and other functions that are needed to invoke each of the public functions Such analysis will produce information on the dependencies among objects and functions and indicate possible paths in the code that link the dependent elements together (3) To illustrate the usefulness of such information, we follow the dependencies and paths to check whether publicly accessible functions are protected with certain permissions in the Android system (e.g., the sample code fragment in Figure shows that getDeviceId is protected by the READ_PHONE_STATE permission), and detect possible unprotected system APIs that access system or private resources without proper permission checking Such unprotected system APIs could be potentially invoked by applications without permissions, causing security and privacy issues The 11th SEATUC Symposium 3.2 Call Graph Construction Statically constructing call graphs of the Android system faces many technical challenges, some of which are common for all Java programs, other are unique to Android For example, Java reflection is often used to invoke dynamically loaded classes and methods whose signatures may be difficult to determine without accurate string analysis of possible method names This is a common problem handled by the Soot static analysis framework [17] to some extends Android also extensively uses event-driven programming and registered listeners to invoke various kinds of call backs to process messages And, broadcasts (or, intents) can be sent by both the system and applications to each other to invoke different functionalities based on intent matching Android also supports defining call backs and intents via XML configuration files, which incurs additional challenges for accurate static call graph construction We not address these challenges; instead, we reply on the capabilities of Soot to construct the call graphs starting from SystemServer.main() Android is a large system was built in many years, there is other challenge as the callgraph is a huge graph (about one million edges and fifty thousand vertices with Android version 4.4.4) Figure describes the complexity of whole-system callgraph Android It is difficult to load the data from callgraph to memory and apply the pathfinding algorithms We resolve this problem via NetworkX [14] as an intermediate library It dumps the call graph memory to the special format is called Pickle to improve the access performance 3.3 Publicly Accessible Android Functions A basic condition for a function in the Android system to be publicly accessible is that the function should be a public method in Java Also, the second more complex condition is that the objects needed for invoking the function should be either publicly accessible too or could be constructed easily To check whether a function satisfies the two conditions, we need to recursively check whether all involved objects and functions are publicly accessible, which is essentially a backward data-flow analysis with heuristic filters based on coding and naming conventions The following is essentially a backward data-flow analysis: (1) For objects of primary types, they can be easily constructed with random values, and we consider them publicly accessible (2) For an object that is a public field in a class, it is considered publicly accessible if one of the class's constructor and the parameters for the constructor are publicly accessible If the object is a private or protected field, it can still be publicly accessible when the class has a getter function whose name is the same as the field name (3) For a public static method that takes in primary types as parameters, the method can be easily invoked from outside of the Android system with randomly generated parameter values (4) Otherwise, we need to check whether it is easy to obtain all the objects needed for invoking the public method For example, if an object of type T is needed to invoke a public function f, then we need to check whether one of T's constructor is publicly accessible, or whether an instance of T can be returned via some getter functions.1 If either the constructor and the getter function requires additional parameters to be invoked, recursive checks are performed To simplify the analysis and get preliminary results, this paper considers a function to be publicly accessible as long as it is public In addition, there are also many functions in the Android system (about 38-43%) that are not reachable from the SystemServer.main entry We consider such functions are not intended to be invoked by the system itself, and are more likely designed for applications to use So, we consider such functions publicly accessible as long as they are public 3.4 Understanding of Android System Functions and Checking Permissions We consider three kinds of information that may be useful in understanding a publicly accessible function if a programmer wants to invoke it properly: (1) the information about all the dependencies, including objects and other functions needed, before invoking the function (2) the information about what happens, including objects affected and functions invoked, after the function is called (3) the information about what happens, including objects affected and functions invoked, within the function Item (1) can be collected using a backward flow analysis that identifies objects and functions that programmers need to construct or invoke before invoking the function Item (2) can be collected by an impact analysis that traverses control and data flows in a forward mode, together with an escape analysis and heuristics based on Item (3) can be collected by an impact analysis too, but focuses on inner workings of a function and may only E.g., a function named getSomething returns type T These heuristics are neither sound nor complete; they are to simplify the analysis The 11th SEATUC Symposium be needed if programmers want to understand the function's internals Section presents some summarized statistics about the collected information As a particular application of such information, we can apply it to address a security and privacy question: are all the publicly accessible functions that access system and/or private resources protected by proper permissions? Given a publicly accessible function f: (1) if the objects and functions needed before invoking f not have any permission protection (2) if the objects and functions within the invocation of f not have any permission protection (3) if the invocation of f can change some external objects, then it is very likely f is not properly protected by a permission Based on the question mentioned above, we propose Algorithm to detect the permission checking issues This algorithm is a backward-flow analysis through the callgraph paths to get all methods that have permission checking Section 4.2.3 illustrates how such permission checking can be done with an example Result: Set methods has permission checking Set setMethods = null; Stack stackPaths = getCallGraphPaths(); while stackPaths NOT empty Path currentPath = stackPaths.pop(); while currentPath NOT empty Method startingMethod = currentPath.pop(); if startingMethod HAS permission checking and NOT in setMethods then setMethods.add(startingMethod); end StackStmt stackCallerStmts = locateCallerStatements(startingMethod); while stackCallerStmts NOT empty Stmt callerStmt = stackCallerStmts.pop(); if callerStmt HAS permission checking then Method callerMethod = callerStmt.getMethod(); setMethods.add(callerMethod); else Stack stackRelatedVars = locateRelatedVars(callerStmt); Stack stackRelatedStmts = locateStatementsOfRelatedVars(stackRelatedVars); while stackRelatedStmts NOT empty Stmt currentStmt = stackRelatedStmts.pop(); if currentStmt HAS permission checking then Method currentMethod = currentStmt.getMethod(); setMethods.add(currentMethod); end end end end end end Algorithm Detect permission checking EVALUATION 4.1 Setups Our approach uses Soot to generate callgraphs of Android systems and output them in the Dot file format Then we use NetworkX library [14] to analyze the graphs, to traverse callgraphs to find paths, analyze in-degrees, out-degrees and output graphs into Pickle file For Soot to construct callgraphs for a version of Android, we feed it with all system jar files (including android.jar) in the Android SDK as distributed by Google To analyze the Android system from version 4.1 to 4.4.4, we used all of jar files in /system/framework that extracted from Google Nexus emulator of Genymotion tool [9]; these file included Dex file of Dalvik Virtual Machine From version 5.0.0 and later, Android changed its architecture, replacing Dalvik Virtual Machine (VM) with Android Runtime (ART) and the Dex files were combined to Linux binary files (ELF file) Since Soot framework did not support Linux binary files, we used the Java bytecode of Android from Grepcode [10] for Android version 5.1.0 and 6.0.1 Table The generation time for each version Version 4.1.1 4.2.2 4.3 4.4.4 5.1.0 6.0.1 Generated Duration (seconds) 31988 35790 41288 43133 80463 86521 The duration to generate and read the callgraph files is a challenge issue We generated the callgraphs on our server with the specifications as Windows Server 2008 R2 64-bit, Intel(R) Xeon(R) E5540 2.53Ghz, RAM 64 GB Table presents the generated duration for each Android version The generation time in the Dot format is approximate hours for version 4.1.1 and up to 24 hours for version 6.0.1 Then, it takes about 10 minutes to read and convert the Dot file to Pickle via NetworkX, and the following graph traversals based on the Pickle files can be performed quickly 4.2 Result Summary Our evaluation addresses the following research questions: (1) How the numbers of total and public methods changes for each Android version? (2) How are the degree distributions of the methods? (3) Could we find publicly accessible functions that are not properly protected by permission checks? The next sections address each research question in detail 4.2.1 Methods in Each Android Version Comparing Android 4.4.4 with 5.1.0 (the gray line in Figure 3), the numbers of callgraph methods increase 14.7% The change rate is comparable between Android 4.1.1 and 4.4.4 The large change rates indicate the needs of tools to help programmers to understand the Android The 11th SEATUC Symposium 100000 Log(Number of nodes) system functions The numbers of edges also change significantly (e.g., Android 4.2.2 increased 10.8% and 4.4.4 increased 11.2%) These changes also contribute to the complexity of the Android system after each new version The orange line in Figure presents the number of public methods for each Android version The public methods occupy about 51% of all system methods from Android 4.1.1 to 4.4.4 After Dalvik VM was replaced by ART from Android version 5.0, this ratio changed to 54% as our results on Android 5.1.0 and 6.0.1 These ratios demonstrate the difference between Dalvik VM architecture and ART architecture 10000 1000 100 10 1 10 100 Log(In-degree) 1000 10000 1000 10000 1000 10000 (a) Android version 4.1.1 Number of public methods in callgraph Number of methods in callgraph Number of public methods Number of methods 180000 160000 140000 120000 100000 80000 60000 40000 20000 1200000 1000000 800000 600000 400000 200000 Number of edges Number of methods Number of edges (right y-axis) Log(Number of nodes) 100000 10000 1000 100 10 1 4.1.1 4.2.2 4.3.0 4.4.4 5.1.0 6.0.1 Android version 100 Log(In-degree) (b) Android version 5.1.0 Fig Numbers of Methods and Edges 100000 Log(Number of nodes) 4.2.2 Degrees of Methods We use the interaction degrees among methods in callgraphs to illustrate the complexity of Android functions Figures and show the in-degree and outdegree distributions, respectively, for Android The distributions exhibit power-law like relations, especially for degrees in the range of [1, 100] The degrees in the range of [100, 10000] are distributed in a more arbitrary fashion Samples of nodes of high in-degrees are toString, append methods in the general purpose Java StringBuilder, Object classes More interestingly, nodes of high out-degree may not indicate high complexities of the involved methods E.g., equals, toString methods in the Android core.KeyValueMap, text.SpannableStringBuilder classes have almost the highest out-degree, reflecting the fact that it deals with generic object types, but the code of these functions are often short and easy to understand More complex methods are in fact those having tens of out-degrees and dealing with specific object types with rich contents, e.g., parseIntent, getLastLocation in the Android Intent, LocationManagerService classes 10 10000 1000 100 10 1 10 100 Log(In-degree) (c) Android version 6.0.1 Fig In-degree distributions of Android 4.2.3 Accessing system resources without permissions Information curated by our analysis could be applied to find potential security and privacy violations For example, consider the public method setStreamVolume() of system class com.android.server.audio.AudioService Based on the callgraph of Android version 4.3, we realize this public method invokes many other methods in the system class AudioService in a certain order, such as ensureValidStreamType(), getDeviceForStream(), rescaleIndex() and finally sendVolumeUpdate() The method sendVolumeUpdate() could update the device volume without permission So, it means the applications could access its device volume without any permission This bug was fixed from Android 4.4, Google used method The 11th SEATUC Symposium AppOpsManager.noteOp()!=AppOpsManager.MODE_ALLOW ED to check permission before calling rescaleIndex() Log(Number of nodes) 100000 10000 1000 100 10 1 10 100 1000 Log(Out-degree) 10000 (a) Android version 4.1.1 Log(Number of nodes) 100000 10000 1000 100 10 1 10 100 1000 Log(Out-degree) 10000 (b) Android version 5.1.0 Log(Number of nodes) 100000 publicly accessible functions in this paper and are left for future work CONCLUSION This paper takes a first step to analyze the whole Android system across various versions, with the intention to automate the modeling of system behaviors and facilitate more accurate and scalable whole-program analysis of Android applications The work so far focuses on providing better understandability of system functions that are publicly accessible Based on limited studies of six versions of the Android system from 4.1.1 to 6.0.1, we show that system functions change a lot across different versions; the numbers of publicly accessible APIs change from about 53K to about 74K Also, the complexity involved in many APIs can be high based on their indegrees and out-degrees We also illustrate the potential usefulness of the studies by showing missed permission checks for a publicly accessible API that may violate security and privacy In the near future, we will integrate the API dependencies and control/data-flow information into modern IDEs (e.g., Android Studio, Eclipse, IntelliJ IDEA) in a visual way to help programmers navigate through and understand the complex system APIs, and will automate the permission checks for discovering unprotected APIs that may lead to security and privacy violations REFERENCES [1] 10000 Android Open Source Project Android API guides: Activities 1000 https://developer.android.com/guide/components/activities.h tml 100 [2] Android Open Source Project Android API guides: Tasks and back stack 10 https://developer.android.com/guide/components/tasks-andback-stack.html 1 10 100 1000 Log(Out-degree) 10000 [3] precise data-flow summaries for the android framework In (c) Android version 6.0.1 Proceedings of the 38th International Conference on Fig Out-degree distributions of Android 4.3 Discussion As the example in Section 4.2.3, our technique could be used to detect the vulnerabilities of the operating system Android It's also more potential for detecting data leaks or support the developer understands Android system better Note that directly invoking publicly accessible functions in the system is not the only way for Android applications to invoke functionalities of the system There are other ways, such as broadcasting an intent that will be matched and processed by systems, or using Java reflection to invoke functions dynamically, etc These ways of invoking system functions are not yet detected as S Arzt and E Bodden StubDroid: automatic inference of Software Engineering, ICSE, pages 725–735, Austin, TX, USA, May 14–22 2016 [4] S Arzt, S Rasthofer, C Fritz, E Bodden, A Bartel, J Klein, Y L Traon, D Octeau, and P McDaniel FlowDroid: precise context, flow, field, object-sensitive and lifecycle-aware taint analysis for android apps In ACM SIGPLAN Conference on Programming Language Design and Implementation, PLDI, page 29, Edinburgh, United Kingdom, June 9–11 2014 [5] A Bartel, J Klein, M Monperrus, and Y L Traon Static analysis for extracting permission checks of a large scale framework: The challenges and solutions for analyzing android IEEE Trans Software Eng., 40(6):617–632, 2014 [6] R Chiossi Android x ref http://androidxref.com/, 2016 The 11th SEATUC Symposium [7] Evans Data Corporation Mobile developers now number 8.7 million worldwide http://www.fiercewireless.com/developer/ evans-datamobile-developers-now-number-8-7-million-worldwide, June 2014 [8] Gartner Worldwide smartphone sales grew 9.7 percent in fourth quarter of 2015 http://www.gartner.com/newsroom/id/3215217, February 2016 [9] Genymotion Fast and easy android emulator https://www.genymotion.com/ [10] Grepcode Java source code search 2.0 http://repository.grepcode.com/java/ext/com/google/ android/android/ [11] S M Kywe, Y Li, K Petal, and M Grace Attacking android smartphone systems without permissions In 14th PHOTOS AND INFORMATION Nguyen Huu Hoang received his Bachelor's degree in Electronics and Telecommunications, Ho Chi Minh city University of Science (HCMUS), Vietnam in 2013 He became Master student in Computer Science, Ho Chi Minh City University of Technology (HCMUT), Vietnam in 2014 He had one year in School of Information Systems, Singapore Management University as a visiting student His current research interests include programming languages, program analysis and mobile security He also has experience in mobile application Annual Conference on Privacy, Security and Trust, 2016 development To appear Jiang Lingxiao received his Bachelor's [12] L Li, A Bartel, T F Bissyandé, J Klein, Y L Traon, S degree in Information Science and Master's Arzt, S Rasthofer, E Bodden, D Octeau, and P McDaniel degree in Applied Mathematics from the IccTA: Detecting inter-component privacy leaks in android School of Mathematical Sciences at Peking apps In 37th IEEE/ACM International Conference on University (1996-2003) He completed his Software Engineering, ICSE, volume 1, pages 280–291, Ph.D with Prof Zhendong Su in the Florence, Italy, May 16–24 2015 Department of Computer Science at [13] L Lu, Z Li, Z Wu, W Lee, and G Jiang Chex: statically University of California, Davis (2003- vetting android apps for component hijacking 2009) He joined the faculty of School of vulnerabilities In Proceedings of the 2012 ACM conference Information on Computer and communications security, pages 229–240 Management University in November 2009 ACM, 2012 as [14] NetworkX High-productivity software for complex a Systems Professor He at Singapore interested in programming languages and data mining, networks http://networkx.github.io/, 2016 looking for research ideas and techniques [15] OpenSignal Android fragmentation visualized that can help solve software engineering http://opensignal.com/reports/2015/08/android- and security problems fragmentation/, August 2015 Quan Thanh Tho is an Associate [16] S Rasthofer, I Asrar, S Huber, and E Bodden How Professor in the Faculty of Computer current android malware seeks to evade automated code Science and Engineering, Ho Chi Minh analysis In Information Security Theory and Practice - 9th City University of Technology (HCMUT), IFIP WG 11.2 International Conference, WISTP, pages Vietnam He received his B.Eng degree in 187–202, 2015 Information Technology from HCMUT in [17] Sable Research Group Soot: A framework for analyzing 1998 and received Ph.D degree in 2006 and transforming java and android applications from Nanyang Technological University, https://sable.github.io/soot/, 2016 Singapore His current research interests [18] D Yan, G Xu, and A Rountev Rethinking Soot for include formal methods, program summary-based whole-program analysis In ACM analysis/verification, the Semantic Web, SIGPLAN International Workshop on the State Of the Art machine in Java Program Analysis @ PLDI, pages 9–13, 2012 intelligent systems Currently, he heads the [19] S Yang, D Yan, H Wu, Y Wang, and A Rountev Static Department of Software Engineering of the learning/data mining and control-flow analysis of user-driven callbacks in Android Faculty He is also serving as the Chair of applications In International Conference on Software Computer Science Program (undergraduate Engineering, pages 89–99, 2015 level) 8.2 PHỤ LỤC Lý lịch trích ngang Thông tin cá nhân Họ tên: Ngày, tháng, năm sinh: Địa chỉ: Nguyễn Hữu Hoàng 21-01-1990 Nơi sinh: Đồng Tháp 64/4 Lê Liễu, phường Tân Quý, quận Tân Phú, Tp HCM Quá trình đào tạo Năm: Bằng cấp: Chuyên ngành: Trường: 2008 - 2013 Cử nhân Điện tử Viễn thơng Máy tính - Hệ thống nhúng Đại học Khoa học Tự nhiên Tp HCM Q trình cơng tác Tháng 9, 2011 - Tháng 2, 2012 Cơng ty: Vị trí: Công việc: Tháng 7, 2012 - Tháng 10, 2012 Công ty: Vị trí: Cơng việc: Tháng 1, 2013 - Tháng 5, 2014 Cơng ty: Vị trí: Cơng việc: Tháng 7, 2014 - Tháng 12, 2015 Cơng ty: Vị trí: Cơng việc: Tháng 3, 2016 - Công ty: Vị trí: Cơng việc: FPT Mobile Applications Lập trình viên Phát triển ứng dụng Android Molisys Solutions Co., Ltd Lập trình viên Phát triển ứng dụng Android EFSE Co., Ltd Trưởng nhóm di động Phát triển ứng dụng Android IOS Fabrica Vietnam Lập trình viên Phát triển ứng dụng Android SMU - Singapore Management University Trợ lý nghiên cứu Phân tích hệ điều hành Android 51 ... nghiên cứu việc xây dựng đồ thị luồng điều khiển từ mã nhị phân Android Luận văn đề xuất hướng tiếp cận tập trung xây dựng đồ thị luồng điều khiển cho hệ thống ứng dụng Android, từ khai thác để... năm sinh: 21-01-1990 Nơi sinh: Đồng Tháp Chuyên ngành: Mã ngành: 60.48.01 Khoa học Máy tính I TÊN ĐỀ TÀI: Xây dựng đồ thị luồng điều khiển từ mã nhị phân ứng dụng Android II NHIỆM VỤ VÀ NỘI DUNG:... ứng dụng Android từ Dalvik bytecode đưa luồng thực thi ứng dụng, nhiên hạn chế công cụ vấn đề chi phí quyền lớn, khơng hỗ trợ việc xây dựng phân tích đồ thị luồng điều khiển (CFG) cho nhiều ứng