Privacy protection method and system for preventing misbehavior app based on deep learning

Abstract

This invention provides a privacy protection method and system for preventing misbehavior in mini-programs based on deep learning. It utilizes the collaborative efforts of deep learning and program analysis techniques to detect inconsistencies between the expected and actual behavior of mini-programs. This invention provides a novel mini-program analysis technique that associates UI information of widgets with corresponding program behaviors and determines the actual behavior of widgets based on program analysis, thereby enabling the construction of large-scale, high-quality training datasets. Based on the results of program analysis, deep learning techniques are used to learn an icon-behavior model from unstructured datasets to infer the expected behavior of widgets. This invention uses a defined three-layer standard model to detect differences between actual and expected behavior by calculating outlier scores. If any inconsistency is found, it indicates the presence of a misbehaving mini-program. The risk level of the inappropriate behavior can then be estimated, and countermeasures can be proactively implemented.

Description

Technical Field

[0001] This invention belongs to the field of software technology and relates to privacy protection technology, particularly to a privacy protection method and system for preventing misconduct in mini-programs based on deep learning. Background Technology

[0002] The in-app paradigm isn't a new concept, but rather a creative improvement on the WebView interface, overcoming the shortcomings of web applications on mobile operating systems (i.e., Android and iOS). In contrast, mini-programs run within a host application, not in a web browser or mobile operating system. Users can interact with all mini-programs provided by the host application without downloading or installing them. Furthermore, developers can use web development languages ​​to implement mini-programs at a lower cost than traditional mobile applications. According to WeChat statistics, there are currently over 1 million mini-programs covering 200 categories, with over 200 million daily active users. To achieve a better experience than native apps, host applications typically encapsulate the mini-program's API to access resources from the device, system, and host application.

[0003] The architecture of a mini-program typically includes a page layer for UI display and a service layer for interaction. The page layer consists of web views, which utilize WXML and WXSS files (i.e., front-end code files) and the Web View API to render the front-end pages. The service layer uses a JavaScript (JS) engine to provide a runtime environment for JS files (i.e., back-end code files) for the mini-program. The mini-program accesses resources from the host application or system through the JS API.

[0004] Design flaws in the in-app paradigm can lead to two types of erroneous behavior in mini-programs. First, system resource exposure: the host application disables protection for some mini-program APIs that can access sensitive resources. Second, UI deception: the mini-program UI is vulnerable to phishing attacks. These erroneous mini-programs typically target the user and contain almost no malicious code harmful to the system, making them indistinguishable from normal applications and thus bypassing the host application's security checks. Furthermore, mobile operating system security mechanisms do not address these erroneous behaviors because mini-programs are managed by the host application and are transparent to the mobile operating system. Detecting application erroneous behavior has become a prevalent research trend in mobile applications, and while existing user privacy protection schemes have some effectiveness, they cannot be applied to mini-programs due to their different architecture and implementation. Summary of the Invention

[0005] To address the aforementioned issues, this invention proposes a privacy protection method and system for preventing misbehaving mini-programs based on deep learning. It utilizes the collaborative efforts of deep learning (DL) and program analysis techniques to detect inconsistencies between the expected and actual behaviors of mini-programs. Expected behavior is the action a user infers from perceived user interface information (i.e., icons and text descriptions) that the mini-program will perform. Actual behavior is the operation of the mini-program on the underlying mobile device, such as API calls triggered by UI interactions. This invention provides a novel mini-program analysis technique that associates UI information of widgets with corresponding program behaviors and determines the actual behavior of widgets (i.e., actual API calls) based on program analysis, thereby enabling the construction of large-scale, high-quality training datasets. Based on the results of program analysis, deep learning techniques are used to learn an icon-behavior model from unstructured datasets (i.e., icons and text descriptions) to infer the expected behavior of widgets. This invention uses a defined three-layer standard model to detect differences between actual and expected behaviors by calculating outlier scores. If any inconsistency is found, it indicates the presence of a misbehaving mini-program. The risk level of the inappropriate behavior can then be estimated, and countermeasures can be proactively implemented.

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

[0007] A privacy protection method for preventing misconduct in mini-programs based on deep learning includes the following steps:

[0008] First, a WeChat Mini Program dataset was constructed using static and dynamic analysis techniques, and the actual behavior of each UI component was determined, i.e., the actual behavior executed by the program.

[0009] Secondly, deep learning technology is used to infer the expected behavior of UI components from unstructured UI information, that is, the user's expected behavior of the application.

[0010] Finally, by defining a three-layer standard model, the gap between actual behavior and expected behavior is aggregated and calculated; if the calculation result is within an unacceptable range, the mini-program is considered to have engaged in misconduct.

[0011] Furthermore, the specific steps include the following:

[0012] Step 1: Preparation phase. The automatic dataset extraction module is used to automatically extract static and dynamic data and then merge them into a complete dataset, including icons of UI components, corresponding text descriptions, and bound API calls; static analysis is applied to extract a portion of static data from the \verb|WXAPKG| file, and dynamic debugging technology is applied to obtain another portion of dynamic data; then, a matcher is designed to merge the static and dynamic data to generate a complete dataset.

[0013] Step 2: Training phase. Based on the dataset obtained by the automatic dataset extraction module, the expected behavior of UI components from the user's perspective is obtained, i.e., the expected API calls. A multi-label classification task is defined, i.e., taking text and images as input, to derive prediction results for one or more API behavior categories. The classifier is trained by first predefining appropriate API categories and annotating the result labels of the dataset. Then, an icon-behavior model called MiniCheckerBert is built and provided with this new dataset so that it can learn enough features to make predictions.

[0014] Step 3: Detection Phase. Given an unknown mini-application, the static analysis module automatically detects each UI component and generates a result report, which is stored in the signature database, describing the consistency between its expected behavior and actual behavior. Based on the three-layer standard model, the discrepancy between intent and behavior is detected through calculation and summarization.

[0015] Step 4: Protection Phase. During the operation of the user device, the dynamic protection module protects user information based on the results report from the signature database. With the help of the Android Connect Bridge ADB tool, the user's device is first monitored in real time. When the user operates a problematic mini-program component, a strategy module is triggered to execute protection measures. Each layer of the three-layer model corresponds to a protection strategy.

[0016] Furthermore, the specific steps for extracting static data in step one are as follows:

[0017] (1) First, obtain the WXAPKG file of the mini program; when a user enters a mini program for the first time through the user interface, the WXAPKG file will be downloaded from the corresponding server to the local machine. The main package is downloaded first during runtime, and then other sub-packages are downloaded as needed;

[0018] (2) Monitor the storage file / data / data / com.tencent.mm / MicroMsg / {a string of hexadecimal characters} / appbrand / pkg / in Android for WeChat mini programs. This folder contains the basic library of the mini program and all the WXAPKG files used by the mini program. Based on the file generation time, find all the WXAPKG files of a mini program. Reverse engineer the WXAPKG files to obtain the source code: First, decompose the main package of a mini program; then place the sub-packages in the main package folder and decompile the sub-packages one by one.

[0019] (3) After obtaining the source code, construct a program call graph for analyzing and extracting static datasets; in the source code, there are three objects in the internal structure of WeChat Mini Program, namely app, page, and component;

[0020] (4) Start analyzing app.json to obtain the paths of all page objects in the current mini program; process each page object separately; in the WXML file of the page object, there are four types of tags: native tags, custom tags, include tags and import tags; the rest of the JSON and JS files are consistent with traditional static web page analysis; establish a mapping relationship between the widgets in the WXML file and the corresponding API calls in the JS file;

[0021] (5) Parse the WXML file to locate each component, converting virtual tags into local tag representations during the analysis process; first, use Python's Lxml toolkit to parse the WXML file into a hierarchical tree, where each UI component is a node in the tree; then traverse the hierarchical tree to convert virtual tags, as follows:

[0022] • Convert custom tags: Determine if a tag is a custom tag based on whether its name is declared in the corresponding JSON file; the tag's src attribute determines its address. If the tag is custom, recursively process the component object and return the corresponding WXML and JS code.

[0023] • Convert include tags: Locate the corresponding WXML file based on the src attribute in the widget code, and then extract the referenced WXML code;

[0024] • Transform import tags: When traversing the hierarchical tree, if a template tag with the is attribute is encountered, extract the corresponding WXML code; obtain the address from the is attribute value, then process the WXML file to find the import code with the template tag and name attribute; finally, return the imported code.

[0025] (6) Repeat step (5) until all tags are native tags in WXML;

[0026] (7) Associate UI components in a WXML file with their bound events; in the WeChat Mini Program syntax, associate JS functions with UI front-end code through special event attributes; iterate through UI components one by one, and locate bound events by matching the special attributes mentioned above; when traversing a hierarchical tree, consider whether a UI component is implicitly bound to the events of its child nodes; assign events to the largest component in the UI tree; find the binding function in the JS file corresponding to the WXML file and establish the connection between the front-end and back-end code;

[0027] (8) Determine the API call of a function from a JS file; parse a piece of JavaScript code into an abstract syntax tree (AST) using the API provided by the JS interpreter; given a function name, first find it in the AST, then process the function body; when encountering an object name imported from the required identifier, recursively process the JS file;

[0028] (9) After completing the above steps, use the program call graph to extract static data;

[0029] The specific steps for obtaining dynamic data in step one are as follows:

[0030] (1) The front-end page needs to be dynamically debugged to determine the icon and context description of each UI component; use Chrome DevTools to dynamically debug the HTML page of the mini program, and use TBS tools to activate the debugging options of the mini program page;

[0031] (2) Then download the Chrome browser that matches the WeChat version, and view the compiled HTML code and UI information of each webview page in DevTools; dump the dynamic front-end code so that it can be linked with the static source code;

[0032] (3) Use JS automation tools to write scripts to parse the presentation page of the mini program into a hierarchical tree, where each node is a native UI component on Android;

[0033] (4) In the script, first enter the homepage and traverse its hierarchical tree; if a node in the tree is clickable, operate on it and enter the next page; then traverse the hierarchical tree of the next page and repeat the previous click operation;

[0034] (5) Iterate through step (4) on all pages; use the paths of the pages that have been manipulated as markers to avoid infinite iteration;

[0035] (6) Automatically dump screenshots of the user interface and the dynamic front-end code of the currently running mini-program;

[0036] (7) Traverse the DOM tree and intercept the icon at the corresponding position in the user interface screenshot to determine the position of a UI component and its text information;

[0037] The specific steps for merging static and dynamic data in step one are as follows:

[0038] (1) Both static and dynamic data include front-end code. Static front-end code is compiled into dynamic front-end code, and the call graph method is used to process static front-end code.

[0039] (2) Identify common features to associate static and dynamic front-end code; common features include: tag name, tag class attribute or is attribute; tag name and class attribute are consistent with traditional HTML;

[0040] (3) Match tag names in dynamic and static front-end code;

[0041] (4) Further match contextual tags of the same part;

[0042] (5) If step (4) still cannot determine the result, use the class attribute of these tags to match the static and dynamic front-end code; if many tags have the same class attribute value, use the same steps to match their parent or child nodes.

[0043] (6) After steps (3), (4), and (5), the mapping of most static and dynamic front-end code is established; the remaining matching is performed through the following steps:

[0044] (7) The is attribute of a tag is a unique identifier. The is attribute is dynamically generated when a special tag is used. The is attribute is used to uniquely identify a piece of code, including static and dynamic ones.

[0045] (8) The mapping between static and dynamic front-end code is one-to-many. The complete dataset is obtained according to the above steps, including icon images, descriptions and API calls.

[0046] Furthermore, the specific steps for setting the API category in step two are as follows:

[0047] (1) Use the main category from the official website as the category of the model;

[0048] (2) In special circumstances, the main categories are divided; the specific categories include:

[0049] The Basic Category is an API category related to basic functionality, including System, Updates, Mini Programs, and other subcategories;

[0050] ● Network category refers to the API category related to the network, including request, upload, download and other subcategories; the above three subcategories are separated and combined with the remaining APIs to form the server communication category;

[0051] ● The Media category is an API category related to media, including images, videos, audio, and other subcategories;

[0052] • The Open Interface category is the API category used to access the main application's resources, including login, account information, address, and other subcategories;

[0053] • Device category is the API category for accessing mobile device hardware, including Bluetooth, NFC, WIFI, and other subcategories;

[0054] (3) Divide the above 5 major categories and use the rest as predefined tags; finally set several API categories.

[0055] Furthermore, the specific steps for training the model in step two are as follows:

[0056] (1) Based on the automatic dataset extraction module, the datasets of several top-ranked mini-programs on the hot list were extracted, feature vectors were obtained, and the prediction results of various API calls for each feature vector were obtained; two DL models were used to process the unstructured dataset to complete the classification task.

[0057] (2) The first model Labeldroid is used to infer the UI icon intent of the mobile application, and an auxiliary optical character recognition technology is used to process the text icons;

[0058] (3) The second model BER was used to complete the natural language processing task. By combining the semantic description of the first model with the text description of the dataset as input, the BERT model was fine-tuned to infer the expected API behavior of the widget. Finally, the learned model was renamed MiniCheckerBert.

[0059] (4) The result of the MiniCheckerBert model is the probability of the predefined API category, and a threshold of probability greater than 0.5 is set as the expected behavior of the widget.

[0060] (5) Finally, we get a set of expected behaviors for a small component.

[0061] Furthermore, the implementation process of the MiniCheckerBert model is as follows:

[0062] (1) First, the text dataset is input into the embedding layer; the embedding process includes token embedding, paragraph embedding and position embedding; token embedding converts the symbol of each word into a fixed-length vector, paragraph embedding determines whether two sentences are semantically similar in order to handle the classification of sentence pairs, and position embedding allows BERT to compensate for the lack of a converter by learning the order attribute of each word in the sentence.

[0063] (2) Based on the results of the embedding layer, the embedded dataset is fed into several cascaded transformer encoders; through the attention mechanism, the encoder performs a non-linear representation of the hidden state output by the embedding layer and extracts features from it.

[0064] (3) Finally, a linear layer is connected to transform the BERT representation for classification.

[0065] Furthermore, the three-layer standard model in step three is based on several API categories, and according to the degree of obtaining user information, it is arranged from bottom to top as: irrelevant layer, low-risk layer and high-risk layer;

[0066] The unrelated layer covers API categories related to basic functions and does not involve user information; the API categories in this layer are mutually compatible.

[0067] The low-risk layer includes API categories related to system environmental information and functions involving limited user data; strict criteria are set to evaluate the discrepancy between the expected and actual behavior of UI components in this layer;

[0068] The high-risk layer contains API categories that are closely related to user privacy; most API categories in this layer require authorization, and the expected behavior and actual behavior of UI components must match one-to-one.

[0069] In the three-layer standard model, the API categories in the upper layer are compatible with those in the lower layer; the API categories in unrelated layers are mutually compatible, while other API categories need to be matched one by one.

[0070] Furthermore, the calculation steps in step three are as follows:

[0071] (1) Set weights for different layers according to the level of risk: irrelevant layers are 1, low-risk layers are 2, and high-risk layers are 3;

[0072] (2) First, based on the automatic dataset extraction module and the MiniCheckerBert module, two sets of actual behavior and expected behavior are obtained; the elements in these two sets are API categories;

[0073] (3) Perform the following steps to calculate and summarize the difference between the expected and actual sets;

[0074] (4) We map their expected and actual sets to the three-layer standard model, respectively, i.e.

[0075] Y i，j =map(C i )

[0076] Where i is the index of the expected or actual set, j takes the values ​​of the irrelevant layer, low-risk layer, and high-risk layer, and is the index of the set in the three-layer standard model; C is the original feature set, such as the expected set, Y is the reconstructed feature set; map is the mapping function for reconstructing the original feature set;

[0077] (5) Remove elements from the first level of both sets.

[0078] Yi，j =Y i，j -C irrelevant

[0079] (6) Assume that the two sets have the same elements in the low-risk and high-risk layers; in this case, remove both to ensure a strict match between the expected behavior and the actual behavior, i.e.

[0080] Y i，j =Y i，j -C expected ∩C actual

[0081] (7) The remaining elements of these two sets may be assigned to the second or third level; the remaining elements are calculated using predetermined weights.

[0082] score i =∑ i Weight j *Count(Y i，j ),

[0083] Where Weight∈{1,2,3} is the weight of the API behavior in the three-layer standard model, and Count is a function to calculate the number of elements in the set; calculate the expected score and the actual score;

[0084] (8) If the range of the expected set is greater than or equal to the actual set, it is considered feasible; otherwise, the widget has erroneous behavior and the result is stored in the signature database for subsequent protection.

[0085] Furthermore, the protection strategy corresponding to each layer of the three-layer model in step four is as follows:

[0086] Irrelevant layer: This erroneous behavior means that the widget does not involve user privacy information, i.e., it is harmless to the user; this behavior can be ignored.

[0087] Low-risk level: This inappropriate behavior indicates that a small amount of user information, such as device information and system functions, is involved, and a pop-up window is used to warn the user.

[0088] High-risk layer: This improper behavior seriously infringes on user privacy; an interceptor module was designed to hook the communication function and return fake data to the mini program without affecting the user's normal operation.

[0089] This invention also provides a privacy protection system for preventing misconduct in WeChat Mini Programs based on deep learning, including an automatic dataset extraction module, a MiniCheckerBert module, a static analysis module, and a dynamic protection module. The automatic dataset extraction module extracts data from static Mini Program WXAPKG files and dynamic webview debugging UI pages to prepare the required WeChat Mini Program dataset, including features and labels. Features include UI icons and their text descriptions, and labels include the actual behaviors of UI components. The MiniCheckerBert module uses the dataset generated by the automatic dataset extraction module, employing icon images and text descriptions as features and corresponding underlying API calls as labels, to train two deep learning models: the first is an image recognition model for understanding icon semantics, and the second is a self-regulating model for classification. The system employs two language processing models; based on these models, the expected behavior of UI components can be inferred; the static analysis module is used to detect which UI components in an unknown WeChat mini-program exhibit abnormal behavior and generate a report. The results are stored in a signature database. The automatic dataset extraction module is used to obtain the dataset of the mini-program to be detected, further determining the mapping set between UI components and actual behavior. Then, using the pre-trained MiniCheckerBert model, the mapping set between UI components and expected behavior is obtained. Finally, a three-layer standard model is defined to calculate the difference between these two sets and determine whether abnormal behavior exists. The dynamic protection module is used to execute specific protection measures based on the signature database results when the user operates on the mini-program. In the three-layer standard model, abnormal behavior is divided into three categories, which also correspond to three different protection measures.

[0090] The beneficial effects of this invention are as follows:

[0091] 1. This invention proposes a novel privacy protection solution to prevent misbehavior by detecting inconsistencies between the intent displayed in the mini-program's UI and the actual operations on the underlying system. It operates independently without causing any changes to the mini-program or the host application. Furthermore, it does not impose any side effects or acceptable resource overhead on the user's mobile device.

[0092] 2. This invention constructs a large-scale mini-program dataset through static and dynamic analysis and determines the actual behavior of widgets. Furthermore, it utilizes deep learning (DL) technology to infer expected behavior from unstructured UI information. Two DL models were trained based on the dataset: the first is a computer vision (CV) model for understanding icon semantics, and the second is a pre-trained BERT model for handling nonlinear programming tasks.

[0093] 3. The solution proposed in this invention was tested using the WeChat application. Evaluation results show that the method can effectively identify erroneous behaviors of the WeChat application, with an average accuracy rate of 97.49%, and can take corresponding measures to protect user privacy. Attached Figure Description

[0094] Figure 1 This is a diagram of the WeChat Mini Program architecture.

[0095] Figure 2 A flowchart of the privacy scheme.

[0096] Figure 3 This is a structural diagram of MiniCheckerBert. Detailed Implementation

[0097] The technical solutions provided by the present invention will be described in detail below with reference to specific embodiments. It should be understood that the following specific embodiments are only used to illustrate the present invention and are not intended to limit the scope of the present invention.

[0098] Figure 1 The diagram shown is the WeChat Mini Program architecture of this system, including: the UI display page layer and the service layer for interaction, as detailed below:

[0099] First, the page layer: consists of two Web views, using WXML and WXSS files (i.e. front-end code files) and the Web view API to render the front-end page;

[0100] Secondly, the service layer:

[0101] (1) Use the JavaScript (JS) engine to provide a runtime environment for JS files (i.e. backend code files) for the mini program;

[0102] (2) Mini programs access resources from host applications or systems via JSAPI.

[0103] This invention provides a privacy protection system for WeChat mini-programs that uses deep learning to prevent misconduct. It determines whether a mini-program exhibits misconduct by detecting inconsistencies between the user's intent presented in the mini-program's UI and the actual operations of the underlying system. Specifically, this invention first constructs a large-scale WeChat mini-program dataset using static and dynamic analysis techniques and determines the actual behavior of each UI component, i.e., the behavior actually executed by the program. Second, it uses deep learning techniques to infer the expected behavior of UI components from unstructured UI information, i.e., the user's expected behavior towards the application. Finally, it defines a three-layer standard model to aggregate and calculate the gap between the actual behavior and the expected behavior. If the calculation result is within an unacceptable range, the mini-program is considered to have exhibited misconduct.

[0104] Figure 2 The diagram shown illustrates the workflow of this system, which consists of four modules: an automatic dataset extraction module, a MiniCheckerBert module, a static analysis module, and a dynamic protection module. These four modules work together to detect misbehaving mini-programs and take measures to protect user privacy.

[0105] The Automatic Dataset Extraction module extracts data from a given static WeChat Mini Program WXAPKG file and a dynamic webview debug UI page to prepare the required WeChat Mini Program dataset, including features (i.e., UI icons and their text descriptions) and tags (i.e., the actual API behavior of UI components).

[0106] MiniCheckerBert is an icon behavior model learned from a training dataset. Based on a dataset generated by an automatically extracted dataset module, it uses icon images and text descriptions as features, and corresponding underlying API calls as labels. Two deep learning models are trained: the first is an image recognition model for understanding icon semantics, and the second is a natural language processing model for classification. Based on these two models, the expected behavior of UI components can be inferred.

[0107] The static analysis module is used to detect which UI components in an unknown WeChat mini-program exhibit abnormal behavior and generates a report, which is stored in a signature database. Specifically, the static analysis module uses an automatic dataset extraction module to obtain the dataset of the mini-program to be tested, further determining the mapping set between UI components and their actual behaviors. Then, using a pre-trained MiniCheckerBert model, it obtains the mapping set between UI components and their expected behaviors. Finally, a three-layer standard model is defined to calculate the difference between these two sets to determine whether abnormal behavior exists. It can perform the detection on any third-party server without causing any modifications to the mini-program or the host application.

[0108] The dynamic protection module executes specific protection measures based on the signature database results when a user interacts with the mini-program. Based on the signature database, the dynamic protection module first monitors the user's device in real time, and then takes countermeasures against different behaviors when a mini-program exhibits abnormal behavior. In the three-layer standard model, abnormal behaviors are divided into three categories, each corresponding to a different protection measure.

[0109] The privacy protection method for preventing misconduct in mini-programs using deep learning provided by this invention, implemented using the aforementioned system, includes the following steps:

[0110] Step 1: Preparation Phase. The automatic dataset extraction module automatically extracts static and dynamic data and then merges them into a complete dataset, including UI component icons, corresponding text descriptions, and bound API calls (i.e., the actual behavior of the UI components). Furthermore, it plays a crucial role in training our model, as it enables the construction of a large-scale, high-quality dataset. We apply static analysis to extract one portion of the data from the `\verb|WXAPKG|` file and apply dynamic debugging techniques to obtain another portion. Then, we designed a matcher to merge the static and dynamic data, generating a complete dataset.

[0111] The preparation phase of this step includes extracting static data, acquiring dynamic data, and merging static and dynamic data. The specific steps for extracting static data are as follows:

[0112] (1) First, obtain the WXAPKG file of the mini-program. When the source code of a mini-program is larger than 2MB, the developer must configure the subpackages option. Then, after compilation, it will generate multiple WXAPKG files, namely one main package and multiple sub-packages. When a user enters a mini-program for the first time through the user interface, the WXAPKG file will be downloaded from the corresponding server to the local machine. The main package is downloaded first during runtime, and then other sub-packages are downloaded as needed. Therefore, we must operate all pages as much as possible to ensure that the corresponding WXAPKG package of the mini-program is downloaded locally.

[0113] (2) Monitored the storage file / data / data / com.tencent.mm / of WeChat Mini Programs in Android.

[0114] The folder `MicroMsg / {a string of hexadecimal characters} / appbrand / pkg / ` contains the basic libraries of the mini-program and all the WXAPKG files used by the mini-program. We locate all the WXAPKG files for a mini-program based on their creation time. To obtain the source code, we must reverse engineer the WXAPKG files. We then introduce a reverse engineering tool, CrackMiniApp, which is one of the most popular tools on GitHub. Specifically, we first disassemble the main package of a mini-program. Then, we place sub-packages under the main package folder and decompile each sub-package one by one. Since most mini-programs do not have code obfuscation enabled, the resulting source code is readable and analyzable.

[0115] (3) After obtaining the source code, we constructed a program call graph for analyzing and extracting static datasets. In the source code, the internal structure of a WeChat Mini Program contains three objects: app, page, and component. An app object is the entry point for the entire Mini Program, controlling its lifecycle, including page objects. A page object is a runtime instance of a page, managing the page lifecycle and each component in the component tree. A component object is an instance of a node in the component tree, primarily used for customizing nodes, including their rendering, styles, and methods. From a development perspective, a Mini Program has only one app object, consisting of an app.json file and an app.js file. A page object is the user interface presented to the user, including WXML, WXSS, JS, and JSON files. If developers need custom tags, they can define a component object, which includes the same file types as the page object, but the main difference lies in the object types declared in their JS files.

[0116] (4) Next, we start by analyzing app.json to obtain the paths of all page objects in the current mini-program. Then we process each page object separately. The WXML in the page object is the most complex because it includes not only local tags but also tags referenced from other WXML files or custom tags from component objects. Therefore, there are four types of tags in the page object's WXML file: native tags, custom tags, include tags, and import tags. Since the WXSS file is responsible for the page's style, it is usually not considered. The remaining JSON and JS files are consistent with traditional static webpage analysis. Therefore, the following steps will analyze how to establish a mapping relationship between widgets in the WXML file and the corresponding API calls in the JS file.

[0117] (5) We parse the WXML file to locate each component. Since virtual tags (i.e., besides native tags) have no practical meaning, we convert them into representations of native tags during the parsing process. To do this, we first use Python's Lxml toolkit to parse the WXML file into a hierarchical tree, where each UI component is a node in the tree. Then we traverse the hierarchical tree to transform the virtual tags, as follows.

[0118] • Custom Tags. This is the WXML part of the component object in the mini-program. We determine if it's a custom tag based on whether its name is declared in the corresponding JSON file. Additionally, the tag's src attribute determines its address. If the tag is custom, we recursively process the component object and return the corresponding WXML and JS code.

[0119] The `include` tag is simply a reference to a piece of WXML code. Therefore, we locate the corresponding WXML file based on the `src` attribute in the widget code and then extract the referenced WXML code.

[0120] The `import` tag. It's typically used with the `template` tag to make complex references to a piece of WXML code. A `template` tag with a `name` attribute defines a template. When using the `import` tag, templates already defined in another WXML file are imported, and the syntax for using these templates is the `template` tag and the `is` attribute. Therefore, when traversing the hierarchical tree, if we encounter a `template` tag with the `is` attribute, we need to extract the corresponding WXML code. Specifically, we get the address from the `is` attribute value, then process the WXML file to find the imported code with the `template` tag and the `name` attribute. Finally, we return the imported code.

[0121] (6) Step (5) is usually repeated until all tags are native tags in WXML.

[0122] (7) We need to associate UI components in a WXML file with their bound events. In the WeChat Mini Program syntax, JS functions can be associated with the UI front-end code through special event attributes, such as `bind` and `bindtap`. Therefore, we iterate through the UI components one by one, locating the bound events by matching the aforementioned special attributes. Typically, the corresponding bound events of non-root nodes in a hierarchical tree can propagate to their parent nodes. Therefore, when traversing a hierarchical tree, we need to consider whether a UI component is implicitly bound to events of its child nodes. Specifically, if a component has a `capture-catch` or `capture-bind` attribute, then events from its child nodes will not be bound to it; if a component uses the `catch` attribute to bind an event, that event will not propagate to its parent node. Furthermore, there are some events on the page that the user has not triggered; therefore, we attribute these events to the largest component in the UI tree. Next, we must find the binding functions in the corresponding JS file of the WXML file, which establishes the connection between the front-end and back-end code.

[0123] (8) We determine a function's API call from a JS file. Due to JS's modularity and anonymous functions, manually locating a function's API call is difficult. Esprima is a JS interpreter whose API parses JavaScript code into an Abstract Syntax Tree (AST). Given a function name, we first find it in the AST and then process the function body. This can lead to multiple levels of nested calls within JS modules. Therefore, it's necessary to determine if an external module is used within the function body. Specifically, we recursively process the JS file when we encounter an object name imported from a desired identifier. Furthermore, it might encapsulate the API call by assigning it to a variable or adding a property to an object class. Therefore, we must add some specific checks to the program.

[0124] (9) After completing the above steps, we use program call graph to extract static data.

[0125] The specific steps to obtain dynamic data are as follows:

[0126] (1) The front-end page needs to be dynamically debugged to determine the icon and context description of each UI component. WeChat Mini Programs use Chromium as the rendering layer for WebView on Android. Many Mini Program pages (i.e., WXML and WXSS) are compiled into a single rendered page (i.e., an HTML page-frame). Therefore, we use ChromeDevTools to dynamically debug the HTML page, a set of web development tools directly built into the Google Chrome browser. To facilitate debugging Mini Program pages, WeChat provides a plugin called TBS. Using the TBS tool, we activate the debugging options for the Mini Program page.

[0127] (2) Next, we download the Chrome browser that matches our WeChat version. We can then view the compiled HTML code and UI information for each webview page in DevTools. Although we only need the UI information, we still need to dump the dynamic front-end code (i.e., page-frame code) to correlate it with the static source code.

[0128] (3) To automate all page operations, we also use Auto.js, a JS automation tool, to write scripts. This JS tool can parse the mini-program's presentation page into a hierarchical tree, where each node is a native UI component on Android (such as ImageView, TextView).

[0129] (4) In the script, we first enter the homepage and traverse its hierarchical tree. If a node in the tree is clickable, we interact with it and proceed to the next page. Next, we traverse the hierarchical tree on the next page, repeating the previous click operations.

[0130] (5) Step (4) is an iterative process across all pages; therefore, we need to use the paths of the pages that have been manipulated as markers to avoid infinite iteration.

[0131] (6) In addition, we automatically dump user interface screenshots and the dynamic front-end code of the currently running mini-program.

[0132] (7) Since the dynamic front-end code is in HTML format, we can quickly locate the information of UI components by manipulating the DOM tree. Specifically, we determine the location of a UI component and its text information by traversing the DOM tree and intercepting its icon at the corresponding position in the user interface screenshot.

[0133] The specific steps for merging static and dynamic data are as follows:

[0134] (1) Both static and dynamic data include front-end code, so the front-end code acts as a bridge between the two parts of data. Compiling static front-end code into dynamic front-end code is similar to generating a call graph for static code. Therefore, we use a call graph approach to process static front-end code.

[0135] (2) We must identify common characteristics to associate static and dynamic front-end code. The easiest characteristics to identify are the tag names, as well as the tag's class or is attribute. The tag names and class attributes are consistent with traditional HTML.

[0136] (3) First, we match the tag names in the dynamic and static front-end code.

[0137] (4) Because many tag names in dynamic front-end code are often the same, we further match the context tags of the same part.

[0138] (5) If step (4) still cannot determine the result, we use the class attribute of these tags to match the static and dynamic front-end code. If many tags have the same class attribute value, we use the same steps to match their parent or child nodes.

[0139] (6) After steps (3), (4), and (5), we can establish the mapping for most of the static and dynamic front-end code. The remaining matching is done through the following steps.

[0140] (7) The `is` attribute of a tag is a unique identifier that is dynamically generated when a specific tag (i.e., `include`, `import`, or a custom tag) is used. Therefore, we use the `is` attribute to uniquely identify a piece of code, including both static and dynamic code.

[0141] (8) We noticed that the mapping between static and dynamic front-end code is one-to-many, which is as expected. Finally, we obtained the complete dataset, including icon images, descriptions, and API calls, based on the steps described above.

[0142] Step Two: In the training phase, our task is to obtain the expected behavior of UI components from the user's perspective, i.e., the anticipated API calls, based on the dataset acquired by the automatic dataset extraction module. Since a UI component may be associated with multiple API behavior categories, we devised a multi-label classification task: taking text and images as input, we derive predictions for one or more API behavior categories. To train the classifier, we first predefine appropriate API categories and annotate the results labels in the dataset. Then, we build an icon-behavior model called MiniCheckerBert and provide it with this new dataset, enabling it to learn sufficient features for prediction.

[0143] The specific steps for setting the API category are as follows:

[0144] (1) On WeChat's official website, there are 20 major categories based on function; however, these are coarse-grained functional classifications that do not conform to the categories in our model. We combine the Android permission group classification principle with the single responsibility of functional categories to ensure that the granularity of the classification is appropriate.

[0145] (2) We generally use the main category of the official website as the category of our model, such as the UI category, which is the main category that does not involve user privacy.

[0146] (3) In some special cases, we divide the main categories. The specific divisions and reasons are as follows.

[0147] The base category is an API category related to basic functionality, including system, update, mini-program, and other subcategories. The main category has responsibilities for multiple functional categories, and some subcategories involve limited user information but do not require authorization.

[0148] • Network category refers to API categories related to the network, including requests, uploads, downloads, and other subcategories. We separate the above three subcategories and combine them with the remaining APIs (e.g., WebSocket, mDNS, TCP, UDP) as the server communication category because we are not concerned with network traffic.

[0149] The Media category is an API category related to media, including images, videos, audio, and other subcategories. We use its subcategories because they are separate groups in Android, and most require authorization.

[0150] The Open Interface category is the API category used to access resources in the main application, including login, account information, address, and other subcategories. The main category has multiple functional categories, and most subcategories relate to user privacy.

[0151] • Device categories are API categories for accessing mobile device hardware, including Bluetooth, NFC, Wi-Fi, and other subcategories. Their subclasses are separate groups in the Android system; therefore, we must separate the subclasses.

[0152] (4) Therefore, we divided the above 5 major categories and used the remaining 15 as our predefined labels. Finally, we set 78 API categories.

[0153] The specific steps for training the model are as follows:

[0154] (1) Based on the automatic dataset extraction module, we extracted the dataset of the top 100 most popular mini-programs, which contains 28,794 feature vectors. Our task is to obtain the prediction results of 78 API calls for each feature vector. Therefore, we use two deep learning models to process the unstructured dataset to complete the classification task.

[0155] (2) The first model, Labeldroid, is a mature computer vision model used to infer the intent of UI icons in mobile applications. However, Labeldroid can only recognize non-text icons; therefore, auxiliary optical character recognition (OCR) technology is still needed to process text icons.

[0156] (3) For the second model, we employ the state-of-the-art deep learning model, BERT, which consists of several pre-trained models based on a general dataset to perform natural language processing tasks. Specifically, we fine-tune the BERT model by combining the semantic description of the first model with the textual description of the dataset as input to infer the expected API behavior of the widget. Finally, we rename the learned model to MiniCheckerBert.

[0157] (4) The MiniCheckerBert model outputs the probability of a predefined API category. We set a threshold of 0.5 for the expected behavior of the widget.

[0158] (5) Finally, we obtain a set of expected behaviors for a small component.

[0159] The structure of the MiniCheckerBert model is as follows: Figure 3 As shown, its implementation process is as follows:

[0160] (1) First, the text dataset is input into the embedding layer. The embedding process includes token embedding, paragraph embedding, and positional embedding. Token embedding transforms the symbol of each word into a fixed-length vector (768 in MiniCheckerBERT). Paragraph embedding determines whether two sentences are semantically similar to handle sentence pair classification. Positional embedding allows BERT to compensate for the lack of a transformer by learning the order properties of each word in the sentence.

[0161] (2) Based on the results of the embedding layer, we feed the embedded dataset into several cascaded transformer encoders. Through an attention mechanism, the encoder performs a non-linear representation of the hidden state output by the embedding layer and extracts features from it.

[0162] (3) Finally, we connect a linear layer to transform the BERT feature representation used for classification, resulting in a probability of a predefined API category (a threshold of probability greater than 0.5 is set as the expected behavior of the widget).

[0163] (4) Obtain the set of expected behaviors of the widget.

[0164] The training parameters for the MiniCheckerBert model are as follows: the dataset ratio is set to 6:2:2, which is a common practice for text classification tasks, i.e., it is divided into training, validation, and test sets. The training parameters are batchsize set to 16, numworkers set to 8, and the model is trained for 30 epochs.

[0165] Step 3: Detection Phase. Given an unknown mini-application, the static analysis module automatically detects each UI component and generates a results report, stored in the signature database, describing the consistency between its expected and actual behavior. Specifically, based on a three-layer standard model and set evaluation rules, we detect discrepancies between intent and behavior through calculation and aggregation.

[0166] We divided the 78 API categories into a three-tiered standard model, based on the degree of user information obtained, from bottom to top: the irrelevant layer, the low-risk layer, and the high-risk layer. The irrelevant layer contains 32 API categories, the low-risk layer contains 21 API categories, and the high-risk layer contains 25 API categories.

[0167] Unrelated layer: This layer covers API categories related to basic functionality and does not involve user information. Therefore, the API categories in this layer are mutually compatible.

[0168] Low-risk layer: This includes API categories related to system environmental information and functions involving limited user data. Therefore, we need to set strict criteria to evaluate the discrepancy between the expected and actual behavior of UI components at this layer.

[0169] High-risk layer: This layer contains API categories closely related to user privacy (see Android permissions file). Most API categories in this layer require authorization. Therefore, API categories in this layer are high-risk and require stricter standards, meaning that the expected behavior and actual behavior of UI components must match one-to-one.

[0170] The evaluation rules set in this step are as follows:

[0171] (1) The API category of the upper layer can be compatible with that of the lower layer. For example, the predicted behavior is the location category in the high-risk layer, even though the actual behavior is the navigation category in the low-risk layer, this is considered normal behavior.

[0172] (2) API categories in unrelated layers are mutually compatible, while other API categories need to be matched one by one. For example, if the predicted behavior is the recording category in the high-risk layer, even though the actual behavior is the camera category in the same layer, it is a serious erroneous behavior because there is no one-to-one matching.

[0173] The calculation steps for setting the evaluation rules are as follows:

[0174] (1) Set weights for different layers according to the level of risk: irrelevant layers are 1, low-risk layers are 2, and high-risk layers are 3.

[0175] (2) We first obtain two sets of actual behaviors and expected behaviors based on the automatic dataset extraction module and the MiniCheckerBert module. The elements in these two sets are API categories (i.e., representative behaviors).

[0176] (3) Perform the following steps to calculate and summarize the difference between the expected and actual sets.

[0177] (4) We map their expected and actual sets to the three-layer standard model, respectively, i.e.

[0178] Y i，j =map(C i )

[0179] Where i is the index of the expected or actual set, j takes the values ​​of the irrelevant layer, low-risk layer, and high-risk layer, and is the index of the set in the three-layer standard model. C is the original feature set, such as the expected set, and Y is the reconstructed feature set. map is the mapping function for reconstructing the original feature set.

[0180] (5) Remove elements from the first level of both sets because they are irrelevant to the user's information, i.e., they are compatible with each other.

[0181] Y i，j =Y i，j -C irrelevant

[0182] (6) Assume that the two sets have the same elements in both the low-risk and high-risk layers. In this case, we will remove both to ensure a strict match between the expected behavior and the actual behavior, i.e.

[0183] Y i，j =Y i，j -C expected ∩C actual

[0184] (7) The remaining elements of these two sets may be assigned to the second or third level. We use predetermined weights to calculate the remaining elements.

[0185] score i =∑ i Weight j *Count(Y i，j ),

[0186] Where Weight∈{1,2,3} is the weight of the API behavior in the three-layer standard model, and Count is a function to calculate the number of elements in the set. We calculate the expected score and the actual score.

[0187] (8) If the range of the expected set is greater than or equal to the actual set, it is considered feasible. Otherwise, the widget has erroneous behavior, and the result is stored in the signature database for subsequent protection.

[0188] Step Four: Protection Phase. During the operation of the user's device, this module silently protects user information based on the results report from the signature database. With the help of the Android Connect Bridge (ADB) tool, we first monitor the user's device in real time. When the user interacts with a problematic mini-program component, a policy module is triggered to execute protection measures. Specifically, each layer of the three-layer model corresponds to a protection policy.

[0189] The three-layer model protection strategy is as follows:

[0190] (1) Irrelevant layer: This error behavior means that the widget does not involve user privacy information, that is, it is harmless to the user. Therefore, this behavior can be ignored.

[0191] (2) Low-risk layer: The inappropriate behavior indicates that a small amount of user information, such as device information and system functions, is involved. We use a pop-up window to warn the user.

[0192] (3) High-risk layer: This inappropriate behavior seriously infringes on user privacy. Therefore, we designed an interceptor module that hooks the communication function and returns fake data to the mini-program without affecting the user's normal operation. This strategy can be used for most erroneous behaviors in the high-risk layer.

[0193] The specific steps of the high-risk layer interceptor are as follows:

[0194] (1) The execution of the mini-program API calls the operating system layer through the host layer, and then its control flow reaches the system permission API. Therefore, we first need to determine the function triggered by the mini-program API call that reaches the operating system layer. Based on a large amount of WeChat logs, we found the Webview API function named com.tencent.mm.plugin.appbrand.jsapi.l.

[0195] (2) Then, an Xposed module was implemented to hook the function and modify its return value at runtime. Specifically, we set different fake data for each resource data type; therefore, misbehaving mini-programs cannot detect it.

[0196] (3) However, some high-risk behavior categories (e.g., account information, address, coupons, group chats) obtain users' private data from WeChat. Due to WeChat's closed-source nature, we cannot hook into its internal functions. Therefore, we block the host application from running and display a warning, which is an effective method, although it affects the user experience.

[0197] It should be noted that the above content merely illustrates the technical concept of the present invention and should not be construed as limiting the scope of protection of the present invention. For those skilled in the art, various improvements and modifications can be made without departing from the principle of the present invention, and all such improvements and modifications fall within the scope of protection of the claims of the present invention.

Claims

1. A privacy protection method for preventing misconduct in mini-programs based on deep learning, characterized in that, Includes the following steps: First, a WeChat Mini Program dataset was constructed using static and dynamic analysis techniques, and the actual behavior of each UI component was determined, i.e., the actual behavior executed by the program. Secondly, deep learning technology is used to infer the expected behavior of UI components from unstructured UI information, that is, the user's expected behavior of the application. Finally, by defining a three-layer standard model, the gap between actual behavior and expected behavior is aggregated and calculated; If the calculation result is within an unacceptable range, the mini-program is considered to have engaged in misconduct; specifically including: During the detection phase, given an unknown mini-application, the static analysis module automatically detects each UI component and then generates a result report, which is stored in the signature database, describing the consistency between its expected behavior and actual behavior; based on the three-layer standard model, the difference between intent and behavior is detected through calculation and summarization. The three-tier standard model is based on several API categories, and according to the degree of user information obtained, it is arranged from bottom to top as: irrelevant layer, low-risk layer and high-risk layer; The unrelated layer covers API categories related to basic functions and does not involve user information; the API categories in this layer are mutually compatible. The low-risk layer includes API categories related to system environmental information and functions involving limited user data; strict criteria are set to evaluate the discrepancy between the expected and actual behavior of UI components in this layer; The high-risk layer contains API categories that are closely related to user privacy; most API categories in this layer require authorization, and the expected behavior and actual behavior of UI components must match one-to-one. In the three-layer standard model, the API categories in the upper layer are compatible with those in the lower layer; the API categories in unrelated layers are mutually compatible, while other API categories need to be matched one by one. The specific calculation steps are as follows: (1) Set weights for different layers according to the degree of risk: irrelevant layers are 1, low-risk layers are 2, and high-risk layers are 3; (2) First, based on the automatic dataset extraction module and the MiniCheckerBert module, two sets of actual behavior and expected behavior are obtained; the elements in these two sets are API categories; (3) Perform the following steps to calculate and summarize the difference between the expected and actual sets; (4) We map their expected and actual sets to the three-layer standard model, respectively, i.e. Where i is the index of the expected or actual set, j takes the values ​​of the irrelevant layer, low-risk layer, and high-risk layer, and is the index of the set in the three-layer standard model; C is the original feature set, such as the expected set, Y is the reconstructed feature set; map is the mapping function for reconstructing the original feature set; (5) Remove elements from the first level of both sets. (6) Assume that the two sets have the same elements in the low-risk and high-risk layers; in this case, remove both to ensure a strict match between the expected behavior and the actual behavior, i.e. (7) The remaining elements of these two sets may be assigned to the second or third level; the remaining elements are calculated using predetermined weights. , in , is the weight of API behavior in the three-layer standard model. It is a function that calculates the number of elements in a set; it calculates the expected score and the actual score. (8) If the range of the expected set is greater than or equal to the actual set, it is considered feasible; otherwise, the widget has erroneous behavior and the result is stored in the signature database for subsequent protection.

2. The privacy protection method for preventing misconduct in mini-programs based on deep learning according to claim 1, characterized in that, Specifically, the steps include the following: Step 1: Preparation phase. The automatic dataset extraction module is used to automatically extract static and dynamic data, and then merge them into a complete dataset, including icons of UI components, corresponding text descriptions, and bound API calls; static analysis is applied to extract a portion of static data from the \verb|WXAPKG| file, and dynamic debugging technology is applied to obtain another portion of dynamic data; Then, a matcher is designed to merge static and dynamic data to generate a complete dataset; Step 2: Training phase. Based on the dataset obtained by the automatic dataset extraction module, the expected behavior of UI components from the user's perspective, i.e., the expected API calls, is obtained. A multi-label classification task is defined, i.e., taking text and images as input, and deriving the prediction results of one or more API behavior categories. The classifier is trained by first predefining appropriate API categories and annotating the result labels of the dataset. Then, an icon-behavior model called MiniCheckerBert is built and provided with this new dataset so that it can learn enough features to make predictions. Step 3: Detection phase. Given an unknown mini-application, the static analysis module automatically detects each UI component and then generates a result report, which is stored in the signature database, describing the consistency between its expected behavior and actual behavior. Based on the three-layer standard model, the difference between intention and behavior is detected through calculation and summarization. Step 4: Protection Phase. During the operation of the user equipment, the dynamic protection module protects user information based on the results of the signature database report. With the help of the Android Connect Bridge ADB tool, the user's device is first monitored in real time. When the user operates a problematic mini-program component, a strategy module is triggered to execute protection measures. Each layer of the three-layer model corresponds to a protection policy.

3. The privacy protection method for preventing misconduct in mini-programs based on deep learning according to claim 2, characterized in that, The specific steps for extracting static data in step one are as follows: (1) First, obtain the WXAPKG file of the mini program; when a user enters a mini program for the first time through the user interface, the WXAPKG file will be downloaded from the corresponding server to the local machine. The main package is downloaded first during runtime, and then other sub-packages are downloaded as needed; (2) Monitor the storage file / data / data / com.tencent.mm / MicroMsg / {a string of hexadecimal characters} / appbrand / pkg / in Android. This folder contains the basic library of the mini program and all the WXAPKG files of the mini program. According to the file generation time, find all the WXAPKG files of a mini program. Reverse engineer the WXAPKG files to obtain the source code: First, decompose the main package of a mini program; then place the sub-packages in the main package folder and decompile the sub-packages one by one. (3) After obtaining the source code, construct a program call graph for analyzing and extracting static datasets; in the source code, there are three objects in the internal structure of WeChat Mini Program, namely app, page, and component; (4) Start analyzing from app.json to obtain the paths of all page objects in the current mini program; process each page object separately; in the WXML file of the page object, there are four types of tags: native tags, custom tags, include tags and import tags; The remaining JSON and JS files follow the same pattern as traditional static webpage analysis; a mapping relationship is established between widgets in the WXML file and corresponding API calls in the JS file; (5) Parse the WXML file to locate each component, and convert virtual tags into local tag representations during the analysis process; first, use Python's Lxml toolkit to parse the WXML file into a hierarchical tree, where each UI component is a node in the tree; then traverse the hierarchical tree to convert virtual tags, as follows: Convert custom tags: Determine if a tag is a custom tag based on whether its name is declared in the corresponding JSON file; the tag's src attribute determines its address. If the tag is custom, recursively process the component object and return the corresponding WXML and JS code. Convert include tags: Locate the corresponding WXML file based on the src attribute in the widget code, and then extract the referenced WXML code; Transform the import tag: When traversing the hierarchical tree, if a template tag with the is attribute is encountered, extract the corresponding WXML code; obtain the address from the is attribute value, then process the WXML file to find the import code with the template tag and name attribute; finally, return the imported code. (6) Repeat step (5) until all tags are native tags in WXML; (7) Associate UI components in a WXML file with their bound events; in the WeChat Mini Program syntax, associate JS functions with UI front-end code through special event attributes; iterate through the UI components one by one and locate the bound events by matching the special attributes mentioned above; When traversing a hierarchical tree, consider whether a UI component is implicitly bound to events of its child nodes; assign the events to the highest-ranking component in the UI tree; find the binding function in the JS file corresponding to the WXML file, and establish the connection between the front-end and back-end code; (8) Determine the API call of a function from a JS file; parse a piece of JavaScript code into an Abstract Syntax Tree (AST) using the API provided by the JS interpreter; Given a function name, first find it in the AST, then process the function body; when an object name imported from the required identifier is encountered, recursively process the JS file; (9) After completing the above steps, use the program call graph to extract static data; The specific steps for obtaining dynamic data in step one are as follows: (1) The front-end page needs to be dynamically debugged to determine the icon and context description of each UI component; use ChromeDevTools to dynamically debug the HTML page of the mini program, and use TBS tools to activate the debugging options of the mini program page; (2) Then download the Chrome browser that matches the WeChat version, and view the compiled HTML code and UI information of each webview page in DevTools; dump the dynamic front-end code so that it can be linked with the static source code; (3) Use JS automation tools to write scripts to parse the presentation page of the mini program into a hierarchical tree, where each node is a native UI component on Android; (4) In the script, first enter the homepage and traverse its hierarchical tree; if a node in the tree is clickable, operate on it and enter the next page; then traverse the hierarchical tree of the next page and repeat the previous click operation; (5) Iterate through step (4) on all pages; use the paths of the pages that have been manipulated as markers to avoid infinite iteration; (6) Automatically dump screenshots of the user interface and the dynamic front-end code of the currently running mini-program; (7) Traverse the DOM tree and intercept the icon at the corresponding position in the user interface screenshot to determine the position of a UI component and its text information; The specific steps for merging static and dynamic data in step one are as follows: (1) Both static and dynamic data include front-end code. Static front-end code is compiled into dynamic front-end code, and the call graph method is used to process static front-end code. (2) Identify common features to associate static and dynamic front-end code; common features include: tag name, tag class attribute or is attribute; tag name and class attribute are consistent with traditional HTML; (3) Match tag names in dynamic and static front-end code; (4) Further match contextual tags of the same part; (5) If step (4) still cannot determine the result, use the class attribute of these tags to match the static and dynamic front-end code; if many tags have the same class attribute value, use the same steps to match their parent or child nodes. (6) After steps (3), (4), and (5), the mapping of most static and dynamic front-end code is established; the remaining matching is carried out through the following steps: (7) The is attribute of a tag is a unique identifier. When a special tag is used, the is attribute is generated dynamically. The is attribute is used to uniquely identify a piece of code, including static and dynamic ones. (8) The mapping between static and dynamic front-end code is one-to-many. The complete dataset is obtained according to the above steps, including icon images, descriptions and API calls.

4. The privacy protection method for preventing misconduct in mini-programs based on deep learning according to claim 2, characterized in that, The specific steps for setting the API category in step two are as follows: (1) Use the main category from the official website as the model's category; (2) In special circumstances, the main categories are divided; the specific categories include: The basic category is an API category related to basic functions, including system, update, mini-program, and other subcategories; Network categories refer to network-related API categories, including request, upload, download, and other subcategories; these three subcategories are separated and combined with the remaining APIs to form server communication categories; The Media category is an API category related to media, including images, videos, audio, and other subcategories; The Open Interface category is the API category used to access resources of the main application, including login, account information, address, and other subcategories; Device categories are API categories for accessing mobile device hardware, including Bluetooth, NFC, WIFI, and other subcategories; (3) Divide the above 5 major categories and use the rest as predefined tags; finally set several API categories.

5. The privacy protection method for preventing misconduct in mini-programs based on deep learning according to claim 2, characterized in that, The specific steps for training the model in step two are as follows: (1) Based on the automatic dataset extraction module, the datasets of several top-ranked mini-programs on the hot list were extracted, feature vectors were obtained, and the prediction results of various API calls for each feature vector were obtained; two DL models were used to process the unstructured dataset to complete the classification task. (2) The first model Labeldroid is used to infer the UI icon intent of the mobile application, and auxiliary optical character recognition technology is used to process text icons; (3) The second model BER was used to complete the natural language processing task. By combining the semantic description of the first model with the text description of the dataset as input, the BERT model was fine-tuned to infer the expected API behavior of the widget. Finally, the learned model was renamed MiniCheckerBert. (4) The result of the MiniCheckerBert model is the probability of the predefined API category, and a threshold of probability greater than 0.5 is set as the expected behavior of the widget. (5) Finally, we obtain a set of expected behaviors for a small component.

6. The privacy protection method for preventing misconduct in mini-programs based on deep learning according to claim 5, characterized in that, The implementation process of the MiniCheckerBert model is as follows: (1) First, the text dataset is input into the embedding layer; the embedding process includes token embedding, paragraph embedding and position embedding; token embedding converts the symbol of each word into a fixed-length vector, paragraph embedding determines whether two sentences are semantically similar in order to handle the classification of sentence pairs, and position embedding allows BERT to compensate for the lack of a converter by learning the order attribute of each word in the sentence. (2) Based on the results of the embedding layer, the embedded dataset is fed into several cascaded transformer encoders; Through the attention mechanism, the encoder performs a non-linear representation of the hidden state output by the embedding layer and extracts features from it; (3) Finally, a linear layer is connected to transform the BERT representation for classification.

7. The privacy protection method for preventing misconduct in mini-programs based on deep learning according to claim 2, characterized in that, The protection strategies corresponding to each layer of the three-layer model in step four are as follows: Irrelevant layer: This erroneous behavior means that the widget does not involve user privacy information, i.e., it is harmless to the user; this behavior can be ignored. Low-risk level: This inappropriate behavior indicates that a small amount of user information, such as device information and system functions, is involved, and a pop-up window is used to warn the user. High-risk layer: This improper behavior seriously infringes on user privacy; an interceptor module was designed to hook the communication function and return fake data to the mini program without affecting the user's normal operation.

8. A privacy protection system for preventing misconduct in mini-programs based on deep learning, characterized in that: The method for preventing misconduct in WeChat Mini Programs based on deep learning, as described in any one of claims 1-6, comprises: an automatic dataset extraction module, a MiniCheckerBert module, a static analysis module, and a dynamic protection module. The automatic dataset extraction module extracts data from static Mini Program WXAPKG files and dynamic webview debugging UI pages to prepare the required WeChat Mini Program dataset, including features and labels. Features include UI icons and their text descriptions, and labels include the actual behaviors of UI components. The MiniCheckerBert module trains two deep learning models based on the dataset generated by the automatic dataset extraction module, using icon images and text descriptions as features and corresponding underlying API calls as labels: the first is an image recognition model for understanding icon semantics, and the second is... A natural language processing model is used for classification; based on these two models, the expected behavior of UI components can be inferred; the static analysis module is used to detect which UI components in an unknown WeChat mini program have abnormal behavior and generate a report. The results are stored in a signature database. The automatic dataset extraction module is used to obtain the dataset of the mini program to be detected, further determining the mapping set between UI components and actual behavior. Then, using the pre-trained MiniCheckerBert model, the mapping set between UI components and expected behavior is obtained. Finally, a three-layer standard model is defined to calculate the difference between the two sets and determine whether abnormal behavior exists; the dynamic protection module is used to execute specific protection measures based on the signature database results when the user operates on the mini program. In the three-layer standard model, abnormal behavior is divided into three categories, which also correspond to three different protection measures.

Images