A method for capturing Android application interaction behaviors based on sandbox

Abstract

The present invention is a method for capturing the interactive behavior of Android applications based on a sandbox. The method captures the stack information of Android APP applications in the process of behavioral interaction by virtualizing a system_process process and realizing a customized virtual service, and by presetting hook points for usage permissions and http access URLs in the sandbox. The present invention can discover the code layer call and processing logic of the interaction, and can intuitively provide the root cause of the problem in solving the interaction problem.

Description

Technical Field

[0001] The present invention belongs to the technical field of communication, and in particular relates to a method for capturing interactive behaviors of Android applications based on a sandbox. Background Art

[0002] With the rapid development of mobile networks, more and more industries are introducing business systems into mobile Internet terminals. Based on the rapid improvement of memory, CPU and other resources of mobile terminal devices, the increasingly huge business volume enables applications to run on mobile terminals.

[0003] For example, Apple's IOS system and Android system are compatible with many application software. In the applications of these application software, there are many information interaction behaviors, and these interactive behaviors are realized in the form of network exchange of data packets.

[0004] As disclosed in patent application 202011223889.1, a method for realizing fast startup of a smart interactive large screen is disclosed, wherein the smart interactive large screen has an Android operating system and a Windows operating system, and the method includes: after the smart interactive large screen is powered on and the power button is pressed, the boot loader is started; after the boot loader is started, the real-time operating system is started, and after the real-time operating system is started, the system framework startup video and the Windows operating system are started at the same time; the startup of the desktop application is canceled, and after the system framework, the startup video and the Windows operating system are started, the teaching player is started, and after the teaching player is started, the smart interactive large screen completes the startup. The present invention shortens the startup time of the smart interactive large screen.

[0005] For example, patent application 202110611495.1 discloses a multi-Bluetooth interaction method and system for the Android system. An extended Bluetooth service BluetoothExt apk is added on the basis of the Android native Bluetooth apk; on the basis of the Android native FW interface android.bluetooth, an extended interface package bluetoothext is added, and the AIDL service interface of Bluetooth communication is expanded to an Ext type interface file, and the service of the extended Bluetooth process bluetoothext is started through the extended Bluetooth Manager ServiceExt. A new extended Bluetooth module is added on the basis of the native module to meet the needs of simultaneous interaction of multiple Bluetooth modules. Due to the compatible design, the development efficiency is further improved and the development cost is saved.

[0006] However, the current analysis of the interactive behavior of Android APP applications is basically to capture the interactive behavior information through network packet capture. Through packet capture, we can only see the surface content of the Android APP application interaction (for example: URL request link, request parameters, response parameters, and interactive plaintext data), and cannot find the code layer call and processing logic of the interaction at a deeper level. When solving interactive problems, it cannot intuitively provide the root cause of the problem, nor can it indirectly prove the problem. Summary of the invention

[0007] To solve the above problems, the primary purpose of the present invention is to provide a method for capturing the interactive behavior of Android applications based on a sandbox. The method can discover the code layer calls and processing logic of the interaction, and can intuitively provide the root cause of the problem when solving the interaction problem.

[0008] Another object of the present invention is to provide a method for capturing the interactive behavior of Android applications based on a sandbox. The method utilizes sandbox technology and replaces the system service agent with a customized system service agent through hook, reflection, and proxy technology. The target application of the :pn process hooks all system service agents, and the application process communicates with the virtual service of the :x process.

[0009] The applicant found that all Android APP applications run on the Framework layer, which is actually a core process of Android, system server (system_process). Starting the system server will start a series of core services, such as ams, wms, pms, etc.

[0010] By using sandbox technology, we can change the interaction mode between Android APP and Android OS and run Android APP in sandbox, which can realize a virtual system_process and implement a customized virtual service. By presetting the hook points of usage permissions and http access URL in the sandbox, we can capture the stack information of Android APP in the process of behavioral interaction.

[0011] To achieve the above objectives, the technical solution of the present invention is as follows.

[0012] A method for capturing the interactive behavior of Android applications based on a sandbox, which captures the stack information of Android APP applications during the behavioral interaction process by virtualizing a system_process process and implementing a customized virtual service, and then presetting hook points for usage permissions and http access URLs in the sandbox.

[0013] The method first sets VA Main and VA:x, where:

[0014] VA Main: the main program of the virtual APP;

[0015] VA:x:virutal Provider of virtual service objects in the APP system;

[0016] When the Virtual APP starts the plugin, it obtains the virtual service proxy object and communicates with the Android system Service object through the Virtaul:x process.

[0017] Furthermore, in the VA:x process, two functional modules are added to the source code to implement the following functions:

[0018] i. Logs of APP application permission application operations;

[0019] ii. Logs of APP application's http access URL.

[0020] Furthermore, to ensure loose coupling between VA:x core functions and business functions:

[0021] i.VA:x collects permission application and http access URL interaction stack information data through hook points, and interacts with external apps through local formatted files;

[0022] ii. The service priority hooker module and the http hooker module add hooks to the key virtualservice object. When the key function is called, the added hook function is called first, and the call behavior interaction stack information is obtained at this time;

[0023] iii. The formatted message is written into the message queue, and the MSG Writer thread outputs the message to sqlite.

[0024] Further, the specific process is:

[0025] Step 1: VA:Main program starts, and VA:x process is automatically called when it starts. When VA:x process starts, the Android sandbox environment is ready.

[0026] Step 2: Upload the Android APP to capture behavior information. Start the Android APP process through VA:Main and perform various operations on the APP. The permission and url modules in VA:x will output logs.

[0027] Step 3: Start the VA:x process. When it starts, it will read the module configuration files of the permissions and URL detection in the process so that the system functions can run normally.

[0028] Step 4: Create a Virtual Service object, start the plugin, and interact with the Android OS through the Virtual Service object created by VA:x.

[0029] Step 5: Share files. During the running of the Android APP, VA:x will generate a message cache file and use sqlite to share the database between processes.

[0030] The beneficial effects of the present invention are:

[0031] Using sandbox technology, the system service proxy is replaced with a custom system service proxy through hook, reflection, and proxy technology. The target application of the :pn process hooks all system service proxies, and the application process communicates with the virtual service of the :x process. BRIEF DESCRIPTION OF THE DRAWINGS

[0032] Figure 1 It is an overall block diagram implemented by the present invention.

[0033] Figure 2 It is the overall flow chart implemented by the present invention.

[0034] Figure 3 It is a diagram of the overall thread model implemented by the present invention. DETAILED DESCRIPTION

[0035] In order to make the purpose, technical solution and advantages of the present invention more clearly understood, the present invention is further described in detail below in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are only used to explain the present invention and are not intended to limit the present invention.

[0036] Figure 1 As shown, the present invention sets VA:x between the Android APP application and the Android OS, and implements control through VA Main. Specifically:

[0037] VA Main: the main program of the virtual APP;

[0038] VA:x:virutal Provider of virtual service objects in the APP system;

[0039] Normal apps interact directly with the system services provided by Android to obtain support from various operating systems.

[0040] When Virtual APP starts plugin( Figure 1 When using the Android APP in the virtual APP, it does not directly obtain the system service, but obtains the virtual service proxy object implemented by the virtual APP itself.

[0041] The process that communicates with the real Android system Service object is Virtaul:x.

[0042] in:

[0043] 1) In the VA:x process, two functional modules are added to the source code to implement the following functions:

[0044] i. Logs of APP application permission applications.

[0045] ii. Logs of APP application's http access URL.

[0046] 2) To ensure loose coupling between VA:x core functions and business functions:

[0047] i.VA:x collects permission application and http access URL interaction stack information data through hook points, and interacts with external apps through local formatted files.

[0048] ii. The service priority hooker module and the http hooker module add hooks to the key virtualservice objects. When the key function is called, the added hook function is called first, and the call behavior interaction stack information is obtained at this time.

[0049] iii. The formatted message is written into the message queue, and the MSG Writer thread outputs the message to sqlite.

[0050] Combination Figure 2 As shown, the overall data flow is:

[0051] 1) When the VA:Main program is started, the VA:x process will be called up. When the VA:x process is started, the Android sandbox environment is ready. When uploading an Android APP application to capture behavior information, the Android APP application process will be started through VA:Main to perform various APP operations. The permissions and URL modules in VA:x will output logs;

[0052] 2) When the VA:x process is started, the module configuration files for permissions and URL detection in the process will be read so that the system functions can run normally;

[0053] 3) The principle description of Virtual APP mentions that after the plugin is started, it will interact with the Android OS through the VirtualService object created by VA:x.

[0054] 4) During the running of the Android APP application, VA:x will generate a message cache file and use sqlite to share the database between processes.

[0055] Combination Figure 3 As shown, the overall thread model is:

[0056] 1) Adding a service hooker to the VA:x process is equivalent to registering a lot of callback functions. When the key system interface is called, the callback interface will be called. The callback interface will organize the call information into messages and input them into the message queue;

[0057] 2) There is a message output thread in VA:x, which continuously polls the message queue. When there is a message in the message queue, it will format the message and output it to the sqlite database.

[0058] Specifically, the log of APP application permission application operation is as follows:

[0059] 1) Description: Read the phone status and identity

[0060] 2) Permission request: READ_PHONE_STAT

[0061] 3)Hook point: TelephonyManager class getDeviceId method

[0062] 4) Behavior stack information:

[0063] java.lang.Throwable

[0064] at plugin.lab.galaxy.demeHookPlugin.Hook_TelephonyManager_getDeviceId.hook(Ho ok_TelephonyManager_getDeviceId.java:15)

[0065] at com.tencent.smtt.utils.bc(Unknown Source)

[0066] at com.tencent.smtt.sdk.TbsLogReport.a(Unknown Source)

[0067] at com.tencent.smtt.sdk.TbsLogReport.a(Unknown Source)

[0068] at com.tencent.smtt.sdk.aw.handleMessage(Unknown Source)

[0069] at android.os.Handler.dispatchMessage(Handler.java:102)

[0070] at android.os.Looper.loop(Looper.java:154)

[0071] at android.os.HandlerThread.run(HandlerThread.java:61)

[0072] 5) Interaction content (device ID): 640310359556315

[0073] The log of the APP application's http access URL is as follows:

[0074] 1) Description: Get communication behavior

[0075] 2) Request domain name and IP address: alog.umeng.com IP: 8.211.35.113

[0076] 3) Hook point: URLConnection class getOutStream, getInputStream method

[0077] 4) Behavior stack information:

[0078] java.lang.Throwable

[0079] at plugin.lab.galaxy.demeHookPlugin.Hook_URLConnection_http_getOutStream.hook(Hook_URLConnection_http_getOutStream.java:28)

[0080] at com.umeng.analytics.pro.av.a(NetworkHelper.java:210)

[0081] at com.umeng.analytics.pro.av.a(NetworkHelper.java:136)

[0082] at com.umeng.analytics.pro.ba.c(Sender.java:190)

[0083] at com.umeng.analytics.pro.ba.a(Sender.java:95)

[0084] at com.umeng.analytics.pro.ap.d(CacheImpl.java:658)

[0085] at com.umeng.analytics.pro.ap.a(CacheImpl.java:122)

[0086] at com.umeng.analytics.pro.aq$1.a(CacheService.java:44)

[0087] at com.umeng.analytics.pro.bz.run(SafeRunnable.java:8)

[0088] at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:428)

[0089] at java.util.concurrent.FutureTask.run(FutureTask.java:237)

[0090] at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(Sched uledThreadPoolExecutor.java:272)

[0091] at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1133)

[0092] at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:607)

[0093] at java.lang.Thread.run(Thread.java:761)

[0094] 5) Interactive content:

[0095] {"header":"{Content-Type=[envelope / json],Msg-Type=[envelope / json],X-Umeng-Sdk=[Android / 6.1.4%E5%B0%8F%E5%AE%9D%E9 %94%80%E5%94%AE%2F2.2.5+Pixel%2F7.1.2+C6C404DF9EE54775A19B506C25FC6166],X-Umeng-UTC=[1615874381321]}","body":"0x18 0x03 0x31 0x2E 0x300x18……0x38 0x15 0x000x00"}

[0096] In summary, the present invention utilizes sandbox technology to replace the system service agent with a customized system service agent through hook, reflection, and proxy technology. The target application of the :pn process hooks all system service agents, and the application process communicates with the virtual service of the :x process.

[0097] The above are only preferred embodiments of the present invention and are not intended to limit the present invention. Any modifications, equivalent substitutions and improvements made within the spirit and principles of the present invention should be included in the protection scope of the present invention.

Claims

1. A method for capturing Android application interaction behavior based on sandbox, characterized in that This method virtualizes a system_process process and implements a custom virtual service, and then captures the stack information of the Android APP application during the behavior interaction process by presetting the hook points for usage permissions and http access URLs in the sandbox; The method first sets VA Main and VA:x, where: VA Main: the main program of the virtual APP; VA:x:virutal Provider of virtual service objects in the APP system; When the Virtual APP starts the plugin, it obtains the virtual service proxy object and communicates with the Android system Service object through the Virtaul:x process. In the VA:x process, two functional modules are added to the source code to implement the following functions: i. Logs of APP application permission application operations; ii. Logs of APP application's http access URL; To ensure loose coupling between VA:x core functions and business functions: i.VA:x collects permission application and http access URL interaction stack information data through hook points, and interacts with external apps through local formatted files; ii. The service priority hooker module and the http hooker module add hooks to the key virtual service objects. When the key function is called, the added hook function is called first, and the call behavior interaction stack information is obtained at this time; iii. The formatted message is written into the message queue, and the MSG Writer thread outputs the message to sqlite.

2. The method for capturing Android application interaction behavior based on sandbox as claimed in claim 1, characterized in that The specific process is: Step 1: VA:Main program starts, and VA:x process is automatically called when it starts; Step 2: Upload the Android APP to capture behavior information. Start the Android APP process through VA:Main and perform various operations on the APP. The permission and url modules in VA:x will output logs. Step 3: Start the VA:x process. When it starts, it will read the module configuration files of the permissions and URL detection in the process so that the system functions can run normally. Step 4: Create a virtual service object, start the plugin, and interact with the Android OS through the virtual service object created by VA:x; Step 5: Share files. During the running of the Android APP, VA:x will generate a message cache file and use sqlite to share the database between processes.

Images