A privacy permission detection method and system in a game distribution access

Abstract

This application provides a method and system for detecting privacy permissions in game publishing access, including: extracting a permission declaration list and decompiled bytecode from the game publishing code product, identifying the degree of code obfuscation and hardening, and obtaining a symbol integrity retention identifier; determining the target tracing mode based on the symbol integrity retention identifier, the target tracing mode including a full-link tracing mode and a shallow tracing mode; using a bytecode tracing unit to traverse the decompiled bytecode according to the target tracing mode, locating the actual call location of each permission item, and obtaining a permission call mapping table; performing a difference operation on the permission declaration list and the permission call mapping table, filtering out permission items that are declared but not called, and obtaining a preliminary set of unused permissions; identifying the target tracing mode of the preliminary set of unused permissions, wherein the full-link tracing mode corresponds to high confidence and the shallow tracing mode corresponds to low confidence, and determining the confidence level of the result.

Description

Technical Field

[0001] This invention relates to the field of information technology, and in particular to a method and system for detecting privacy permissions in game distribution access. Background Technology

[0002] In the cross-platform, cross-engine field of game development and publishing, privacy compliance testing is particularly crucial, directly impacting user data security and ensuring compliance with laws and regulations. With the rapid expansion of the mobile application market, privacy compliance is not only a technical challenge but also a vital guarantee of corporate reputation and market competitiveness. Accurately identifying permission usage in complex development environments has become a key issue urgently needing resolution within the industry. Currently, many detection methods, when facing permission compliance issues, are often limited to checking surface-level files or focusing only on obvious calls within the code. This approach often proves inadequate when dealing with complex code structures, especially after developers employ technical measures to protect their code, significantly reducing detection accuracy.

[0003] The problem is that these methods cannot adapt to changes in the code environment and struggle to delve into permission call behaviors hidden deep within the code, resulting in incomplete compliance detection results. Existing technology discloses a cross-platform mobile SDK integration method (publication number CN104932901A), which automatically obtains the game's raw package resources and integrates a preset SDK to generate different version game packages. However, this method cannot accurately identify the actual usage of permissions when symbol information is incomplete, leading to insufficient detection depth and breadth. A deeper technical challenge lies in the core factor of code symbol integrity. Code symbols are markers used to identify key elements such as functions and variables in the code; they are crucial for tracing permission call paths.

[0004] If these symbols are deliberately removed or obscured during code protection, detection tools will struggle to reconstruct the complete call logic, making it impossible to determine whether a particular permission has actually been used. This situation directly impacts the depth and breadth of detection, creating a dilemma: if the detection scope is too broad, it may lead to numerous false positives; if the scope is too narrow, it will miss many hidden issues. For example, in a cross-platform game, a developer might declare permission to read user location in the file manifest, but the actual code may not call this function. If the code is protected and the symbol information is removed, detection tools cannot accurately track whether the permission has been invoked and can only blindly rely on the manifest declaration, potentially leading to the incorrect conclusion that the permission has been used, thus affecting the accuracy of compliance assessments.

[0005] Therefore, how to reasonably adjust the depth and scope of detection when symbolic information is incomplete in order to accurately identify the actual use of permissions has become a key problem that this research urgently needs to solve. Summary of the Invention

[0006] This invention discloses a method for detecting privacy permissions in game publishing access, including: Extract the permission declaration list and decompiled bytecode from the game's release code artifacts, identify the degree of code obfuscation and hardening, and obtain the symbol preservation integrity indicator; The target tracking mode is determined based on the symbol retention integrity identifier, and the target tracking mode includes a full-link tracking mode and a shallow tracking mode; The bytecode tracing unit traverses the decompiled bytecode according to the target tracing pattern to locate the actual call location of each permission item and obtain the permission call mapping table. Perform a difference operation between the permission declaration list and the permission invocation mapping table to filter out the permission items that are declared but not invoked, and obtain a preliminary set of unused permissions; Identify the target tracking patterns in the unused permission initial screening set, where the full-link tracking pattern corresponds to high confidence and the shallow tracking pattern corresponds to low confidence, and determine the confidence level of the result; Based on the confidence level of the results, the initial set of unused permissions is filtered and validated. For high confidence levels, a strict filtering strategy is adopted and the results are directly output. For low confidence levels, a lenient filtering strategy is adopted to expand the retention range, thus obtaining the final set of unused permissions and a compliance test report.

[0007] Furthermore, the extraction of the permission declaration list and decompiled bytecode from the game release code artifacts, identification of the code obfuscation and hardening level, and obtaining the symbol preservation integrity indicator include: The configuration file and compilation output file are read from the game release code product. The permission declaration node in the configuration file is parsed, the name and declaration position of each permission item are extracted, and the bytecode of the compilation output file is restored using a decompilation tool to obtain the decompiled bytecode and the permission declaration list. Based on the decompiled bytecode scanning of the class definition region and method definition region, the ratio of the number of original semantic identifiers retained in the class name to the total number of class names is used as the class name retention rate. The ratio of the number of identifiable parameter types and return types in the method signature to the total number of method signatures is used as the signature recognition rate. The code obfuscation level is determined based on the class name retention rate and the signature recognition rate. Based on the code obfuscation level marker and the decompiled bytecode, detect whether there are decryption loop instructions and jump shell code features in the bytecode entry area, collect the nesting level and branch density of jump instructions in the control flow, and obtain the symbol retention ratio by weighted summation of the class name retention rate and the signature recognition rate. Combine the code obfuscation level marker to classify the symbol retention ratio into levels to obtain the symbol retention integrity identifier.

[0008] Furthermore, the target tracking mode is determined based on the symbol retention integrity identifier. The target tracking mode includes a full-link tracking mode and a shallow tracking mode, including: Obtain the symbol preservation integrity identifier, compare the symbol preservation integrity identifier with a preset traceable threshold, and determine the symbol support capability of the current code based on the comparison result; The target tracking mode is determined based on the result of the symbol support capability assessment. When the symbol support capability meets the requirements, the target tracking mode is determined to be a full-link tracking mode. When the symbol support capability is limited, the target tracking mode is determined to be a shallow tracking mode.

[0009] Furthermore, determining the target tracking mode based on the result of the symbol support capability determination includes: Extract the class name retention status and method signature recognition degree of the decompiled bytecode from the symbol retention integrity identifier, collect the control flow flattening strength and string encryption coverage corresponding to the code obfuscation and hardening degree, and obtain symbol resolution features and obfuscation features; The cross-class call tracing support capability is determined based on the class name retention status, the reachability of permission call point location is determined based on the method signature recognition level, and a comprehensive tracing capability marker is obtained by combining the obfuscation features. Based on the comprehensive tracing capability marker, it is determined whether the symbol retention integrity identifier reaches the traceable threshold. If both cross-class tracing and call point location are supported in the comprehensive tracing capability marker and the obfuscation feature is lower than the preset obfuscation threshold, then it is determined to enable the full-link tracing mode to perform deep call chain traversal; otherwise, it is determined to enable the shallow tracing mode to only trace the direct call level.

[0010] Furthermore, the bytecode tracing unit traverses the decompiled bytecode according to the target tracing pattern to locate the actual call location of each permission item and obtain a permission call mapping table, including: The target tracing mode is read using the bytecode tracing unit, and the traversal depth is determined according to the target tracing mode. The full-link tracing mode corresponds to multi-level traversal across methods, and the shallow tracing mode corresponds to single-level direct call traversal. The decompiled bytecode is scanned according to the traversal depth. Starting from the beginning of each method definition region, the bytecode instructions are parsed one by one to identify the method call instructions. The target method signature of each method call instruction is extracted to construct a set of call instructions. For each method call instruction in the set of call instructions, the target method signature is matched with a preset list of permission interfaces. If the target method signature exists in the list of permission interfaces, the location information of the method call instruction in the decompiled bytecode and the corresponding permission item name are recorded to obtain a permission call record. All permission call records in the decompiled bytecode are summarized, grouped and categorized by permission item name to form a correspondence between permission items and call locations, thus obtaining the permission call mapping table.

[0011] Furthermore, the step of performing a difference operation between the permission declaration list and the permission invocation mapping table to filter out permission items that are declared but not invoked, thereby obtaining a preliminary set of unused permissions, includes: Obtain all permission item names from the permission declaration list to form a set of declared permission names, and obtain the permission item names with call records in the permission call mapping table to form a set of called permission names; Iterate through each permission item name in the set of declared permission names, and determine whether the permission item name exists in the set of invoked permission names. If it does not exist, mark the permission item as uninvoked. All permission items marked as not invoked are merged into the same set to obtain the initial set of unused permissions.

[0012] Furthermore, the identification of target tracking patterns in the unused permission initial screening set, where the full-link tracking pattern corresponds to high confidence and the shallow tracking pattern corresponds to low confidence, and the determination of the result confidence level includes: Obtain the initial set of unused permissions, read the target tracking mode used when generating the initial set of unused permissions, and obtain the tracking mode identifier; Based on the confidence level of the tracking mode identifier, the full-link tracking mode corresponds to high confidence, and the shallow tracking mode corresponds to low confidence. The confidence level of the result is determined by associating it with the initial screening set of unused permissions.

[0013] Furthermore, the step of determining the confidence level of the result based on the tracking pattern identifier includes: Extract the tracing path depth and call chain integrity flags corresponding to each permission item from the unused permission initial screening set to obtain path tracing features; Based on the path tracing features, the tracing mode type is identified. For the full-link tracing mode, the scope of reflection call identification and dynamic loading code scanning coverage are collected. For the shallow tracing mode, the number of indirect call layers that it failed to penetrate and the missed delayed binding call scenarios are collected to obtain the tracing mode coverage features. The reliability of the detection results is evaluated based on the coverage features of the tracking mode. In the full-link tracking mode, when both the reflection call identification range and the dynamic loading code scanning coverage reach the preset coverage threshold, the possibility of false alarms is determined to be in the low-level range. In the shallow tracking mode, when the number of indirect call layers exceeds the preset number of layers, it is determined that there is a risk of missed detection. Based on the determination results of the false alarm probability and the missed detection risk, the high confidence level corresponding to the full-link tracing mode is identified, and the low confidence level corresponding to the shallow tracing mode is identified.

[0014] Furthermore, the step of performing filtering verification on the unused permission initial screening set based on the result confidence level includes: Obtain the result confidence level and the initial set of unused permissions, and select the corresponding filtering range according to the result confidence level; When the confidence level of the result is high, a strict filtering range is used to retain only the permission items with complete call chains and tracking path depth reaching a preset depth threshold. When the confidence level of the result is low, a loose filtering range is used to retain all permission items in the initial screening set of unused permissions, thus obtaining the filtered permission set. Based on the filtered permission set, the name, declaration location and tracking path depth of each permission item are extracted and summarized to form the final unused permission set, while recording the corresponding result confidence level information; Based on the final set of unused permissions and the result confidence level information, the comparison results of the permission declaration list and the permission call mapping table are integrated to output a compliance detection report containing a list of unused permissions and confidence level labels.

[0015] On the other hand, the present invention also discloses a privacy permission detection system in game publishing access, comprising: The permission extraction and obfuscation identification module is used to extract permission declaration lists and decompiled bytecode from the game release code artifacts, identify the degree of code obfuscation and hardening, and obtain symbol retention integrity indicators. The tracking mode determination module is used to determine the target tracking mode based on the symbol retention integrity identifier, wherein the target tracking mode includes a full-link tracking mode and a shallow tracking mode; The permission call mapping module is used to use the bytecode tracing unit to traverse the decompiled bytecode according to the target tracing pattern, locate the actual call location of each permission item, and obtain the permission call mapping table. The unused permission screening module is used to perform a difference operation between the permission declaration list and the permission call mapping table to filter out the permission items that are declared but not called, and obtain the unused permission screening set. The confidence level determination module is used to identify the target tracking patterns of the unused permission initial screening set, wherein the full-link tracking pattern corresponds to high confidence and the shallow tracking pattern corresponds to low confidence, and to determine the confidence level of the result. The filtering verification and report generation module is used to perform filtering verification on the initial screening set of unused permissions according to the confidence level of the results. For high confidence levels, a strict filtering strategy is used to output directly, while for low confidence levels, a lenient filtering strategy is used to expand the retention range, so as to obtain the final set of unused permissions and a compliance detection report.

[0016] The technical solutions provided by the embodiments of the present invention may include the following beneficial effects: This invention discloses a method and system for privacy permission detection in game publishing and access. By extracting the permission declaration list and decompiled bytecode from the game publishing code, it identifies the degree of code obfuscation and hardening, as well as the integrity of symbol preservation. It innovatively determines two modes: full-link tracing and shallow tracing, to solve the accuracy problems of permission call location and unused permission filtering. This invention designs a tracing mode switching mechanism for symbol preservation integrity, combining class name preservation status and method signature recognition degree to evaluate cross-class call tracing capabilities and permission call point reachability. This ensures deep traversal of the call chain under high integrity and focuses on the direct call level under low integrity, generating a permission call mapping table and filtering the set of unused permissions. Simultaneously, this invention evaluates the confidence level of the tracing mode differences and optimizes the output using strict or lenient filtering strategies, ultimately generating a compliance detection report. This invention significantly improves the accuracy and reliability of permission compliance detection, effectively reduces the risk of false positives and false negatives, and provides technical assurance for code security and compliance. Attached Figure Description

[0017] Figure 1 This is a flowchart of a privacy permission detection method in game distribution access according to the present invention.

[0018] Figure 2 This is a schematic diagram of a privacy permission detection method in game distribution access according to the present invention.

[0019] Figure 3 This is a schematic diagram of the privacy permission detection system in game distribution access according to the present invention. Detailed Implementation

[0020] The technical solution of the present invention will be clearly and completely described below with reference to the embodiments. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0021] like Figures 1-3 This embodiment of a privacy permission detection method and system in game publishing access may specifically include: S101. Extract the permission declaration list and decompiled bytecode from the game release code artifacts, identify the degree of code obfuscation and hardening, and obtain the symbol preservation integrity indicator.

[0022] The configuration files and compiled output files are read from the game's release code artifacts. The permission declaration nodes in the configuration files are parsed, and the names and declaration locations of each permission item are extracted. A decompilation tool is used to restore the bytecode of the compiled output files, obtaining the decompiled bytecode and a permission declaration list. Based on the decompiled bytecode, the class definition and method definition areas are scanned. The ratio of the number of class names retaining their original semantic identifiers to the total number of class names is used as the class name retention rate. The ratio of the number of recognizable parameter types and return types in method signatures to the total number of method signatures is used as the signature recognition rate. If both the class name retention rate and the signature recognition rate are lower than a preset obfuscation threshold, the code obfuscation level is determined to be high-intensity. If either is lower than the preset obfuscation threshold, the code obfuscation level is determined to be medium-intensity. If both are higher than the preset obfuscation threshold, the code obfuscation level is determined to be low-intensity, thus obtaining a code obfuscation level label. Based on the code obfuscation level marker and the decompiled bytecode, detect whether there are decryption loop instructions and jump shell code features in the bytecode entry area, collect the nesting level and branch density of jump instructions in the control flow, and obtain the symbol retention ratio by weighted summation of the class name retention rate and the signature recognition rate. Combine the code obfuscation level marker to classify the symbol retention ratio into levels to obtain the symbol retention integrity identifier.

[0023] In one implementation, when reading the configuration file from the game release code artifact, for the game package on the Android platform, the configuration file is a manifest file, which is stored in a structured markup language format. The permission declaration nodes are located under a fixed tag hierarchy, and each permission item contains a permission name attribute and a declaration type attribute. The name and declaration position of each permission item can be extracted by the parser traversing the tag tree layer by layer to form a permission declaration list.

[0024] Specifically, the process of restoring decompiled bytecode involves using a static decompilation tool to process the compiled output file. On the Android platform, the compiled output file is a bytecode compressed package. After reading the compressed package, the decompilation tool converts the bytecode instruction sequence into an intermediate representation. This intermediate representation retains the class definition structure, method signature information, and instruction opcodes, but some symbol information may be lost due to compilation optimization or obfuscation. The decompiled bytecode output after decompilation is stored in text form and contains the complete structure of the class definition area and method definition area.

[0025] For example, the statistical process for class name retention rate is as follows: scan all class definition areas in the decompiled bytecode, identify whether each class name consists of meaningful words or phrases, and if the class name is presented as a random combination of letters or a single character sequence, it is determined that the class name has been obfuscated. The number of class names that retain the original semantic identifier is divided by the total number of class names to obtain the class name retention rate. The statistical process for signature recognition rate is similar. The parameter types and return types in the method definition area are identified. If the type name can be parsed into a standard data type or a known class reference, it is determined that the signature is recognizable.

[0026] In one embodiment, the preset obfuscation threshold is set to 30%. When the class name retention rate is 15% and the signature recognition rate is 20%, both are below the preset obfuscation threshold, and the code obfuscation level is determined to be high intensity; when the class name retention rate is 60% and the signature recognition rate is 25%, only the signature recognition rate is below the preset obfuscation threshold, and the code obfuscation level is determined to be medium intensity; when both are above the preset obfuscation threshold, the code obfuscation level is determined to be low intensity.

[0027] It should be noted that the detection of decryption loop instructions is achieved by scanning the instruction sequence of the bytecode entry region. If a combination of consecutive XOR operation instructions and loop jump instructions exists, it is determined that decryption loop characteristics exist. The detection of jump shell code characteristics is achieved by identifying whether the entry point points to non-standard code segments. (Symbol retention ratio) The calculation formula is ,in For class name retention rate, For signature recognition rate, and These are the first and second weight values, respectively, and their sum is 1. The symbol retention ratio is then categorized based on the code obfuscation level. A code obfuscation level of high intensity with a symbol retention ratio below the first threshold is classified as low integrity; a code obfuscation level of low intensity with a symbol retention ratio above the second threshold is classified as high integrity; and all other cases are classified as medium integrity, resulting in a symbol retention integrity label.

[0028] S102. Determine the target tracking mode based on the symbol integrity identifier. The target tracking mode includes full-link tracking mode and shallow tracking mode.

[0029] Obtain a symbol integrity indicator and compare it with a preset traceable threshold. If the symbol integrity indicator reaches the traceable threshold, the current code is determined to have complete symbol support capability; if the symbol integrity indicator is lower than the traceable threshold, the current code's symbol support capability is determined to be limited. Based on the determination of symbol support capability, a target tracing mode is determined. If the code has complete symbol support capability, the target tracing mode is determined to be a full-link tracing mode; if the symbol support capability is limited, the target tracing mode is determined to be a shallow tracing mode.

[0030] In one implementation, after obtaining the symbol retention integrity identifier, the identifier value is compared with a preset traceability threshold. The traceability threshold is preset according to the type of game release code. For Android platform game packages, the traceability threshold is set to the lower limit value corresponding to the medium integrity level. When the value of the symbol retention integrity identifier reaches or exceeds the threshold, it is determined that the current code has the ability to support complete symbols.

[0031] Specifically, the full-link tracing mode is suitable for code scenarios where symbol information is fully preserved. In this mode, the bytecode tracing unit performs a deep call chain traversal across classes and methods, covering the complete path from the entry method to the underlying access call. The shallow tracing mode is suitable for code scenarios where symbol information is damaged or obfuscated. In this mode, only the direct call level is traced to avoid path breaks caused by missing symbols.

[0032] It should be noted that the determination of the target tracing mode directly affects the positioning accuracy of subsequent permission call locations. The full-link tracing mode outputs a more complete call path, while the shallow tracing mode maintains the executability of tracing under symbol-restricted conditions.

[0033] Extract class name retention status and method signature recognition level from decompiled bytecode from symbol retention integrity flags. Collect control flow flattening strength and string encryption coverage corresponding to code obfuscation and hardening level. Analyze the support capability of class name retention status for cross-class call tracing. Evaluate the reachability of method signature recognition level for locating permission call points. Determine when to enable full-link tracing mode to perform deep call chain traversal when symbol retention integrity flag reaches tracing threshold. Identify when to enable shallow tracing mode to only trace the direct call level when symbol retention integrity flag is below tracing threshold.

[0034] The symbol preservation integrity identifier is used to extract the class name preservation status and method signature recognition level of the decompiled bytecode. The class name preservation status represents the retention ratio of original semantic identifiers in the class definition area, and the method signature recognition level represents the resolvable ratio of parameter types and return types in the method definition area, thus obtaining symbol resolution features. Based on these symbol resolution features, the control flow flattening strength and string encryption coverage corresponding to the code obfuscation and hardening level are collected. The control flow flattening strength is obtained by statistically analyzing the nesting depth and number of branches of jump instructions in the bytecode, and the string encryption coverage is obtained by identifying the proportion of encrypted string constants to all string constants in the bytecode, thus obtaining obfuscation features. The class name preservation status is used to determine the cross-class call tracing support capability. If the class name preservation status is higher than a preset class name threshold, it is marked as supporting cross-class tracing. The method signature recognition level is used to determine the reachability of permission call point location. If the method signature recognition level is higher than a preset signature threshold, it is marked as supporting call point location. Combining these obfuscation features yields a comprehensive tracing capability label. Based on the comprehensive tracing capability marker, if the integrity of the retained symbol reaches the traceable threshold, and if both cross-class tracing and call point location are supported in the comprehensive tracing capability marker and the obfuscation feature is lower than the preset obfuscation threshold, then it is determined that the full-link tracing mode is enabled to perform deep call chain traversal; otherwise, it is determined that the shallow tracing mode is enabled to only trace the direct call level.

[0035] In one implementation, when extracting symbol resolution features from the symbol retention integrity identifier, the name fields of each class are scanned one by one in the class definition area of ​​the decompiled bytecode to identify whether the class name is composed of words or phrases with semantic meaning. The ratio of the number of class names that retain the original semantic identifier to the total number of class names is counted as a quantitative representation of the class name retention status.

[0036] Specifically, the process for determining the class name retention status includes the following operations: traversing all class definition nodes in the decompiled bytecode, extracting the complete name string of each class, performing lexical analysis on the string to determine if it conforms to conventional naming conventions, and determining that the class name has been obfuscated if it consists of a series of random letters and is shorter than a preset naming length threshold; if the class name contains recognizable business terms or follows camelCase naming rules, it is determined that the class name retains its original semantics. In game distribution code, unobfuscated class names typically contain business-related terms, while obfuscated class names appear as meaningless character sequences.

[0037] It should be noted that the extraction process for method signature recognition is similar to that for class name preservation. The parameter type list and return type in the method definition area are parsed. If both the parameter type and return type can be recognized as standard data types or known class references, then the method signature is marked as recognizable.

[0038] In one possible implementation, the statistical process for determining the control flow flattening strength involves a structured analysis of the bytecode instruction sequence. Control flow flattening is a common code obfuscation technique that transforms the sequential execution flow of a program into a loop-based scheduling structure based on state variables, making previously clear conditional branches and loop structures difficult to trace. When calculating the control flow flattening strength, the jump instruction nodes in the bytecode are first identified, including conditional and unconditional jump instructions. Then, a jump relationship graph between instructions is constructed, and the nesting depth of jump instructions—the maximum number of jump levels from the entry instruction to a given jump instruction—is calculated. Simultaneously, the number of exit branches for each basic code block is counted. The product of the jump instruction nesting depth and the number of branches serves as the quantification value of the control flow flattening strength. A higher value indicates a more complex code structure and greater difficulty in tracing the call path. Control Flow Flattening Strength The calculation formula is ,in The depth of jump instruction nesting. This represents the average number of exit branches for a basic code block. A higher value indicates a more complex code structure and greater difficulty in tracing the call path.

[0039] For example, the identification of string encryption coverage is achieved by scanning string constants in the bytecode constant pool. Encrypted strings are typically presented as unreadable byte sequences or encoded character combinations. During the identification process, the readability of each string constant is checked. If a string contains a large number of non-printable characters or conforms to a specific encryption encoding pattern, it is marked as an encrypted string. Furthermore, the obfuscation feature is jointly constituted by the control flow flattening strength and the string encryption coverage, which respectively reflect the degree of code obfuscation hardening from the code structure dimension and the data dimension.

[0040] Understandably, the ability to support cross-class call tracing is determined based on the class name reservation status. When the class name reservation status is higher than the preset class name threshold, the tracing unit can accurately locate the definition of the target class by class name when traversing the call instructions, thereby supporting call chain tracing across multiple classes. When the class name reservation status is lower than the threshold, the obfuscation of class names causes the call target to be unable to be accurately identified, and the cross-class tracing capability is limited.

[0041] In one embodiment, the process of forming a comprehensive tracking capability marker integrates cross-class tracking support status, call point location support status, and obfuscation features to form a multi-dimensional capability evaluation result, which directly determines the selection of subsequent tracking modes.

[0042] Preferably, the final determination of the tracing mode follows this logic: when the comprehensive tracing capability flag indicates that both cross-class tracing and call point localization are supported, and the obfuscation characteristics are below a preset obfuscation threshold, the full-link tracing mode is enabled to perform deep call chain traversal on the decompiled bytecode; otherwise, the shallow tracing mode is enabled, tracing only the direct call level, thereby maintaining the executability of the tracing process under the condition of limited symbol information. For the full-link tracing mode, its coverage of reflection call identification and dynamic loading code scanning coverage are collected; for the shallow tracing mode, the number of indirect call layers it fails to penetrate and the delayed binding call scenarios that may be missed are identified to obtain the tracing mode coverage characteristics.

[0043] S103. The bytecode tracing unit traverses the decompiled bytecode according to the target tracing mode to locate the actual call location of each permission item and obtain the permission call mapping table.

[0044] The target tracing mode is read using a bytecode tracing unit. The traversal depth is determined based on the target tracing mode, where the full-link tracing mode corresponds to multi-level traversal across methods, and the shallow tracing mode corresponds to single-level direct call traversal, thus obtaining the traversal depth configuration. Instruction scanning is performed on the decompiled bytecode according to the traversal depth configuration. Starting from the beginning of each method definition region, bytecode instructions are parsed line by line to identify method call instructions. The target method signature of each method call instruction is extracted to construct a call instruction set. For each method call instruction in the call instruction set, the target method signature is matched against a preset list of permission interfaces. The permission interface list stores the sensitive interface method signatures corresponding to each permission item. If the target method signature exists in the permission interface list, the position information of the method call instruction in the decompiled bytecode and the corresponding permission item name are recorded to obtain a permission call record. All permission call records in the decompiled bytecode are summarized and grouped by permission item name. Each permission item corresponds to a list of call positions, forming a correspondence between permission items and call positions, thus obtaining a permission call mapping table.

[0045] In one implementation, the bytecode tracing unit, as a functional component that performs bytecode traversal operations, reads the target tracing mode determined in the preceding steps and determines the traversal depth configuration based on the type of the mode. This configuration directly determines the limit on the number of layers the tracing unit can cross during the traversal of method boundaries.

[0046] Specifically, the process for determining the traversal depth configuration is as follows: When the target tracing mode is full-link tracing mode, the bytecode tracing unit is configured for multi-level traversal across methods. That is, after tracing a method call instruction, the tracing unit enters the interior of the called method to continue scanning until the preset maximum tracing depth is reached or all reachable paths are traversed. When the target tracing mode is shallow tracing mode, the bytecode tracing unit is configured for single-level direct call traversal. That is, it only scans the call instructions within the current method body and does not enter the interior of the called method for recursive tracing. This differentiated traversal depth configuration allows the tracing process to adapt to code structures under different symbol integrity conditions.

[0047] It should be noted that the instruction scan starts at the beginning of each method definition region. Each method definition region in the decompiled bytecode contains the instruction sequence of that method, and the tracing unit parses it line by line, starting from the first instruction in the instruction sequence.

[0048] In one possible implementation, the identification process for method call instructions involves determining the opcode of the bytecode instruction. A bytecode instruction consists of an opcode and operands, where the opcode identifies the instruction type, and the operands provide additional information required for instruction execution. Method call instructions have specific opcode identifiers. When parsing instructions one by one, the tracing unit checks whether the opcode of the current instruction belongs to the method call category. If it does, it extracts the target method signature from the operands of that instruction. The target method signature contains the fully qualified name of the target class, the name of the target method, and a list of parameter types. This signature uniquely identifies the method being called.

[0049] For example, the permission interface list is a pre-established data structure that stores the signatures of sensitive interface methods corresponding to each permission item. In the privacy compliance detection scenario of game distribution code, each permission item corresponds to several sensitive interfaces. The permission to read the user's location corresponds to the "get location" method of the location service class, and the permission to read the device identifier corresponds to the "get device number" method of the device information class. Furthermore, the matching process between the target method signature and the permission interface list adopts an exact string matching method. The extracted target method signature is compared with each record in the permission interface list one by one. If there is a completely identical record, it is determined that the method call instruction triggered the call of the corresponding permission item.

[0050] It is understandable that the formation of a permission call record includes two parts of information: first, the location information of the method call instruction in the decompiled bytecode, including the class name, the method name, and the instruction offset; and second, the name of the successfully matched permission item, which identifies the specific permission category involved in the call.

[0051] In one embodiment, the process of summarizing the permission invocation mapping table involves grouping all permission invocation records in the decompiled bytecode by permission item name. All invocation location information under the same permission item name is grouped into the same group, forming a list of invocation locations for that permission item. The final permission invocation mapping table uses the permission item name as the index and the list of invocation locations as the value, completely recording the actual invocation distribution of each permission item in the code.

[0052] Preferably, the structure of the permission call mapping table supports quick querying of whether a certain permission item has a call record, as well as all call locations of that permission item, providing a data foundation for subsequent comparison operations between permission declarations and actual calls.

[0053] S104. Perform a difference operation between the permission declaration list and the permission call mapping table to filter out the permission items that are declared but not called, and obtain the initial set of unused permissions.

[0054] A set of declared permission names is formed by retrieving all permission item names from the permission declaration list. A set of invoked permission names is formed by retrieving permission item names with invocation records from the permission invocation mapping table. Each permission item name in the set of declared permission names is traversed, and it is determined whether the permission item name exists in the set of invoked permission names. If it does not exist, the permission item is marked as uninvoked, resulting in an uninvoked permission item tag. Based on the uninvoked permission item tags, all permission items marked as uninvoked are merged into the same set to obtain the initial set of unused permissions.

[0055] In one implementation, the name fields of all permission items are extracted from the permission declaration list and aggregated to form a declared permission name set; the names of permission items with call location records are extracted from the permission call mapping table and aggregated to form a called permission name set. The declared permission name set reflects the complete permission scope declared in the configuration file in the game's release code artifact, while the called permission name set reflects the permission scope actually triggered by the code.

[0056] Specifically, it iterates through each permission item name in the set of declared permission names, searches for the existence of a record with the same name in the set of called permission names, and if the search result is empty, it indicates that although the permission item is declared, it has not generated actual calling behavior in the code. At this time, the permission item is marked as uncalled. After the traversal is completed, all uncalled permission item marks are obtained.

[0057] It should be noted that by merging all permission items marked as unused into the same set, an initial set of unused permissions is formed. This set contains all declared but unused permission items, providing input data for subsequent confidence determination and filtering verification.

[0058] S105. Identify the target tracking patterns in the unauthorized initial screening set, where the full-link tracking pattern corresponds to high confidence and the shallow tracking pattern corresponds to low confidence, and determine the confidence level of the result.

[0059] Obtain a preliminary set of unused permissions. Read the target tracking mode used when generating the preliminary set of unused permissions, which is either a full-link tracking mode or a shallow tracking mode, and obtain a tracking mode identifier. Determine the confidence level of the result based on the tracking mode identifier. If the tracking mode identifier is a full-link tracking mode, the confidence level of the result is determined to be high; if the tracking mode identifier is a shallow tracking mode, the confidence level of the result is determined to be low. Associate the result confidence level with the preliminary set of unused permissions, record the confidence level information corresponding to the preliminary set of unused permissions, and determine the result confidence level.

[0060] In one implementation, when obtaining the initial set of unused permissions, the target tracing mode used in the process of generating the set is read synchronously. The tracing mode has been determined and recorded in the preceding bytecode traversal stage. After reading, the tracing mode identifier is obtained, and the value of the identifier is either full-link tracing mode or shallow tracing mode.

[0061] Specifically, there is a direct correspondence between tracing modes and result confidence levels. This is because different tracing modes have varying detection coverage and depth. Full-link tracing mode performs a deep call chain traversal with complete symbolic information, covering the entire call chain from the application entry point to the underlying permission interface. If a permission item is not detected by a call record in full-link tracing mode, it indicates that the permission item has no actual call behavior in the entire code execution path, and the detection result has a high degree of reliability. Shallow tracing mode, with limited symbolic information, only traces the direct call level and cannot penetrate multiple levels of method calls and indirect references. If a permission item is not detected by a call record in shallow tracing mode, there is a risk of missing hidden calls due to insufficient tracing depth, and the reliability of the detection result is relatively low.

[0062] It should be noted that when the tracking mode is identified as full-link tracking mode, the confidence level of the judgment result is high; when the tracking mode is identified as shallow tracking mode, the confidence level of the judgment result is low. Furthermore, the determined confidence level of the result is associated with the initial set of unused permissions, and the confidence level information is recorded in the metadata of the set. This ensures that each permission item in the initial set of unused permissions carries a corresponding confidence flag, providing a basis for subsequent filtering and verification.

[0063] Extract the tracing path depth and call chain integrity markers corresponding to each permission item from the initial screening set of unused permissions. Collect the reflection call identification range and dynamic loading code scanning coverage covered by the full-link tracing mode. Analyze the number of indirect call layers that could not be penetrated and the missed delayed binding call scenarios in the shallow tracing mode. Assess that the false alarm probability of the full-link tracing mode output is in the low range. Determine that the shallow tracing mode output has the risk of missed detection due to insufficient tracing depth. Identify that the full-link tracing mode corresponds to a high confidence level while the shallow tracing mode corresponds to a low confidence level.

[0064] The tracing path depth and call chain integrity markers corresponding to each permission item are extracted from the unused permission initial screening set. The tracing path depth represents the number of method call layers crossed during the tracing process, and the call chain integrity marker represents whether there is a break in the call path from the entry method to the permission interface, thus obtaining path tracing features. Based on these path tracing features, the tracing mode type is identified. For the full-link tracing mode, its coverage of reflection call identification and dynamic loading code scanning is collected. For the shallow tracing mode, the number of indirect call layers it failed to penetrate and the missed delayed binding call scenarios are collected, thus obtaining tracing mode coverage features. The reliability of the detection results is evaluated based on these tracing mode coverage features. If the reflection call identification range and dynamic loading code scanning coverage in the full-link tracing mode both reach a preset coverage threshold, the false alarm probability is determined to be in a low-level range. If the number of indirect call layers in the shallow tracing mode exceeds a preset threshold, a risk of missed detection due to insufficient tracing depth is identified. Based on the determination results of the false alarm probability and the missed detection risk, the full-link tracing mode is identified as corresponding to a high confidence level, and the shallow tracing mode is identified as corresponding to a low confidence level.

[0065] In one implementation, when extracting path tracing features from the unused permission initial screening set, for each permission item in the set, the tracing path depth value and call chain integrity flag recorded during the bytecode tracing stage are read. These two features reflect the tracing process's ability to detect the call status of the permission item.

[0066] Specifically, tracing path depth represents the number of method call layers traversed during the tracing process; that is, the number of methods traversed from the application's entry method down the call chain until reaching the permission interface call point. In full-chain tracing mode, the tracing path depth typically covers the entire call chain, resulting in a larger depth value; in shallow tracing mode, the tracing path depth is limited to a single level of direct calls, resulting in a smaller depth value. This depth value directly affects the ability to detect permission calls hidden in multiple levels of method nesting.

[0067] It should be noted that the call chain integrity flag is used to characterize whether there is a break in the call path from the entry method to the permission interface. If a link cannot be traced due to missing or confusing symbol information during the tracing process, it is marked as incomplete.

[0068] In one possible implementation, the coverage metrics for the full-link tracing mode include the scope of reflection call identification and the coverage of dynamically loaded code scanning. The specific identification methods for these two metrics are detailed in step S1021. Limitations of the shallow tracing mode include the number of indirect call layers and the omission of delayed binding call scenarios.

[0069] In one embodiment, the assessment of the probability of false positives and the risk of missed detections is based on the coverage characteristics of the tracing mode. If the scope of reflection call identification and the coverage of dynamic loading code scanning both reach the preset coverage threshold in the full-link tracing mode, it indicates that the tracing process covers various call types sufficiently, and the probability of false positives is in a low range. If the number of indirect call layers exceeds the preset number of layers in the shallow tracing mode, it indicates that there are many call layers that have not been penetrated, and the risk of missed detections is high.

[0070] Preferably, a correspondence between tracking modes and confidence levels is established based on the determination results of the probability of false alarms and the risk of missed detections. The full-link tracking mode corresponds to a high confidence level because of its wide coverage and low probability of false alarms, while the shallow tracking mode corresponds to a low confidence level because of its limited tracking depth and high risk of missed detections.

[0071] S106. Perform filtering and verification on the initial set of unused permissions based on the confidence level of the results. When the confidence level is high, a strict filtering strategy is used to output directly, and when the confidence level is low, a lenient filtering strategy is used to expand the retention range, so as to obtain the final set of unused permissions and the compliance test report.

[0072] Obtain the result confidence level and the initial set of unused permissions. Based on the result confidence level, select the corresponding filtering range. If the result confidence level is high, a strict filtering range is used to retain only permission items with complete call chains and tracing path depths reaching a preset depth threshold. If the result confidence level is low, a loose filtering range is used to retain all permission items in the initial set of unused permissions, resulting in a filtered permission set. Extract the name, declaration location, and tracing path depth of each permission item from the filtered permission set, and summarize them to form the final unused permission set, while recording the result confidence level information. Based on the final unused permission set and the result confidence level information, integrate the comparison results of the permission declaration list and the permission call mapping table, and output a compliance detection report containing the unused permission list and confidence level annotations.

[0073] In one implementation, the filtering verification is performed differentially based on the result confidence level. A high confidence level indicates that the tracking result has a high degree of credibility, while a low confidence level indicates that the tracking result has a certain degree of uncertainty. The two levels correspond to different filtering ranges to balance the accuracy and completeness of the detection results.

[0074] Specifically, strict filtering is suitable for high-confidence scenarios. Its filtering conditions include two metrics: call chain integrity and tracing path depth. Call chain integrity requires that the tracing path corresponding to the permission item has no breaks from the entry method to the detection endpoint. The tracing path depth requires that it reach a preset depth threshold, which is set based on the typical call hierarchy of game code to indicate that the tracing process covers sufficient method call levels. Only when a permission item meets both of these conditions is it retained in the filtered permission set. In privacy compliance detection scenarios for game distribution code, strict filtering can eliminate false positives caused by partial missing symbol information, improving the accuracy of the final detection results.

[0075] It should be noted that the loose filtering range is suitable for low-confidence scenarios. Due to limited tracking depth, some permission calls may not be detected. The loose filtering range retains all permission items in the initial unused permission set to avoid missing truly unused permission items due to insufficient tracking capabilities. Furthermore, the filtered permission set is aggregated to form the final unused permission set. Each permission item includes three pieces of information: name, declaration location, and tracking path depth, while also recording the corresponding result confidence level.

[0076] In one embodiment, the compliance testing report integrates the comparison results of the permission declaration list and the permission call mapping table. The report content includes two parts: an unused permission list and a confidence level label. The unused permission list lists the permission items in the final set of unused permissions and their declaration positions. The confidence level label indicates the credibility of the current testing results for compliance auditors to refer to and judge.

[0077] This invention provides a privacy permission detection system for game publishing access, mainly comprising: The permission extraction and obfuscation identification module is used to extract permission declaration lists and decompiled bytecode from the game release code artifacts, identify the degree of code obfuscation and hardening, and obtain symbol retention integrity indicators. The tracking mode determination module is used to determine the target tracking mode based on the symbol retention integrity identifier. The target tracking mode includes full-link tracking mode and shallow tracking mode. The permission call mapping module is used to traverse the decompiled bytecode according to the target tracing pattern using the bytecode tracing unit, locate the actual call location of each permission item, and obtain the permission call mapping table. The unused permission screening module is used to perform a difference operation between the permission declaration list and the permission call mapping table to filter out the permission items that have been declared but not called, and obtain the unused permission screening set. The confidence level determination module is used to identify the target tracking patterns in the unauthorized initial screening set, where the full-link tracking pattern corresponds to high confidence and the shallow tracking pattern corresponds to low confidence, and to determine the confidence level of the result. The filtering, validation, and report generation module is used to perform filtering and validation on the initial set of unused permissions based on the confidence level of the results. When the confidence level is high, a strict filtering strategy is used to output directly, while when the confidence level is low, a lenient filtering strategy is used to expand the retention range, resulting in the final set of unused permissions and a compliance test report.

[0078] If the technical solution of this application involves the collection, processing, or application of personal information, the relevant products have strictly complied with the requirements of the "Personal Information Protection Law of the People's Republic of China" and other laws and regulations before implementing any personal information processing activities, clearly and explicitly informing individuals of the rules for personal information processing and obtaining their independent and voluntary authorization and consent. Specifically, if the information involved is sensitive personal information, the product has not only obtained the individual's separate consent before processing, but this consent is also an explicit consent made on the basis of full knowledge. For example, in areas where personal information collection devices such as cameras are deployed, prominent and eye-catching signs have been set up to clearly inform users that entering the area is considered as consenting to the collection of their personal information; or, on the personal information processing interface (such as applications, web pages, etc.), through pop-ups, checkboxes, or active uploads, the user is required to actively authorize the process after clearly displaying key rules such as the identity of the personal information processor, the purpose of processing, the processing method, and the types of information involved.

[0079] The preferred embodiments of the present invention disclosed above are merely illustrative of the invention. These preferred embodiments do not exhaustively describe all details, nor do they limit the invention to any specific implementation. Clearly, many modifications and variations can be made based on the content of this specification. This specification selects and specifically describes these embodiments to better explain the principles and practical applications of the invention, thereby enabling those skilled in the art to better understand and utilize the invention. The invention is limited only by the claims and their full scope and equivalents.

Claims

1. A method for detecting privacy permissions in game publishing access, characterized in that, include: Extract the permission declaration list and decompiled bytecode from the game's release code artifacts, identify the degree of code obfuscation and hardening, and obtain the symbol preservation integrity indicator; The target tracking mode is determined based on the symbol retention integrity identifier, and the target tracking mode includes a full-link tracking mode and a shallow tracking mode; The bytecode tracing unit traverses the decompiled bytecode according to the target tracing pattern to locate the actual call location of each permission item and obtain the permission call mapping table. Perform a difference operation between the permission declaration list and the permission invocation mapping table to filter out the permission items that are declared but not invoked, and obtain a preliminary set of unused permissions; Identify the target tracking patterns in the unused permission initial screening set, where the full-link tracking pattern corresponds to high confidence and the shallow tracking pattern corresponds to low confidence, and determine the confidence level of the result; Based on the confidence level of the results, the initial set of unused permissions is filtered and validated. For high confidence levels, a strict filtering strategy is adopted and the results are directly output. For low confidence levels, a lenient filtering strategy is adopted to expand the retention range, thus obtaining the final set of unused permissions and a compliance test report.

2. The privacy permission detection method in game publishing access according to claim 1, characterized in that, The process of extracting the permission declaration list and decompiled bytecode from the game's release code artifacts, identifying the degree of code obfuscation and hardening, and obtaining a symbol preservation integrity indicator includes: The configuration file and compilation output file are read from the game release code product. The permission declaration node in the configuration file is parsed, the name and declaration position of each permission item are extracted, and the bytecode of the compilation output file is restored using a decompilation tool to obtain the decompiled bytecode and the permission declaration list. Based on the decompiled bytecode scanning of the class definition region and method definition region, the ratio of the number of original semantic identifiers retained in the class name to the total number of class names is used as the class name retention rate. The ratio of the number of identifiable parameter types and return types in the method signature to the total number of method signatures is used as the signature recognition rate. The code obfuscation level is determined based on the class name retention rate and the signature recognition rate. Based on the code obfuscation level marker and the decompiled bytecode, detect whether there are decryption loop instructions and jump shell code features in the bytecode entry area, collect the nesting level and branch density of jump instructions in the control flow, and obtain the symbol retention ratio by weighted summation of the class name retention rate and the signature recognition rate. Combine the code obfuscation level marker to classify the symbol retention ratio into levels to obtain the symbol retention integrity identifier.

3. The privacy permission detection method in game publishing access according to claim 1, characterized in that, The target tracking mode is determined based on the symbol integrity identifier. The target tracking mode includes a full-link tracking mode and a shallow tracking mode, including: Obtain the symbol preservation integrity identifier, compare the symbol preservation integrity identifier with a preset traceable threshold, and determine the symbol support capability of the current code based on the comparison result; The target tracking mode is determined based on the result of the symbol support capability assessment. When the symbol support capability meets the requirements, the target tracking mode is determined to be a full-link tracking mode. When the symbol support capability is limited, the target tracking mode is determined to be a shallow tracking mode.

4. The privacy permission detection method in game publishing access according to claim 3, characterized in that, Determining the target tracking mode based on the result of the symbol support capability determination includes: Extract the class name retention status and method signature recognition degree of the decompiled bytecode from the symbol retention integrity identifier, collect the control flow flattening strength and string encryption coverage corresponding to the code obfuscation and hardening degree, and obtain symbol resolution features and obfuscation features; The cross-class call tracing support capability is determined based on the class name retention status, the reachability of permission call point location is determined based on the method signature recognition level, and a comprehensive tracing capability marker is obtained by combining the obfuscation features. Based on the comprehensive tracing capability marker, it is determined whether the symbol retention integrity identifier reaches the traceable threshold. If both cross-class tracing and call point location are supported in the comprehensive tracing capability marker and the obfuscation feature is lower than the preset obfuscation threshold, then it is determined to enable the full-link tracing mode to perform deep call chain traversal; otherwise, it is determined to enable the shallow tracing mode to only trace the direct call level.

5. The privacy permission detection method in game publishing access according to claim 1, characterized in that, The bytecode tracing unit traverses the decompiled bytecode according to the target tracing pattern, locates the actual call location of each permission item, and obtains a permission call mapping table, including: The target tracing mode is read using the bytecode tracing unit, and the traversal depth is determined according to the target tracing mode. The full-link tracing mode corresponds to multi-level traversal across methods, and the shallow tracing mode corresponds to single-level direct call traversal. The decompiled bytecode is scanned according to the traversal depth. Starting from the beginning of each method definition region, the bytecode instructions are parsed one by one to identify the method call instructions. The target method signature of each method call instruction is extracted to construct a set of call instructions. For each method call instruction in the set of call instructions, the target method signature is matched with a preset list of permission interfaces. If the target method signature exists in the list of permission interfaces, the location information of the method call instruction in the decompiled bytecode and the corresponding permission item name are recorded to obtain a permission call record. All permission call records in the decompiled bytecode are summarized, grouped and categorized by permission item name to form a correspondence between permission items and call locations, thus obtaining the permission call mapping table.

6. The privacy permission detection method in game publishing access according to claim 1, characterized in that, The step of performing a difference operation between the permission declaration list and the permission invocation mapping table to filter out declared but uninvoked permission items, resulting in a preliminary set of unused permissions, includes: Obtain all permission item names from the permission declaration list to form a set of declared permission names, and obtain the permission item names with call records in the permission call mapping table to form a set of called permission names; Iterate through each permission item name in the set of declared permission names, and determine whether the permission item name exists in the set of invoked permission names. If it does not exist, mark the permission item as uninvoked. All permission items marked as not invoked are merged into the same set to obtain the initial set of unused permissions.

7. The privacy permission detection method in game publishing access according to claim 1, characterized in that, The process of identifying the target tracking pattern in the unused permission initial screening set, where the full-link tracking pattern corresponds to high confidence and the shallow tracking pattern corresponds to low confidence, and determining the result confidence level includes: Obtain the initial set of unused permissions, read the target tracking mode used when generating the initial set of unused permissions, and obtain the tracking mode identifier; Based on the confidence level of the tracking mode identifier, the full-link tracking mode corresponds to high confidence, and the shallow tracking mode corresponds to low confidence. The confidence level of the result is determined by associating it with the initial screening set of unused permissions.

8. The privacy permission detection method in game publishing access according to claim 7, characterized in that, The step of determining the confidence level of the tracking pattern identifier includes: Extract the tracing path depth and call chain integrity flags corresponding to each permission item from the unused permission initial screening set to obtain path tracing features; Based on the path tracing features, the tracing mode type is identified. For the full-link tracing mode, the scope of reflection call identification and dynamic loading code scanning coverage are collected. For the shallow tracing mode, the number of indirect call layers that it failed to penetrate and the missed delayed binding call scenarios are collected to obtain the tracing mode coverage features. The reliability of the detection results is evaluated based on the coverage features of the tracking mode. In the full-link tracking mode, when both the reflection call identification range and the dynamic loading code scanning coverage reach the preset coverage threshold, the possibility of false alarms is determined to be in the low-level range. In the shallow tracking mode, when the number of indirect call layers exceeds the preset number of layers, it is determined that there is a risk of missed detection. Based on the determination results of the false alarm probability and the missed detection risk, the high confidence level corresponding to the full-link tracing mode is identified, and the low confidence level corresponding to the shallow tracing mode is identified.

9. The privacy permission detection method in game publishing access according to claim 1, characterized in that, The step of performing filtering and verification on the unused permission initial screening set based on the result confidence level includes: Obtain the result confidence level and the initial set of unused permissions, and select the corresponding filtering range according to the result confidence level; When the confidence level of the result is high, a strict filtering range is used to retain only the permission items with complete call chains and tracking path depth reaching a preset depth threshold. When the confidence level of the result is low, a loose filtering range is used to retain all permission items in the initial screening set of unused permissions, thus obtaining the filtered permission set. Based on the filtered permission set, the name, declaration location and tracking path depth of each permission item are extracted and summarized to form the final unused permission set, while recording the corresponding result confidence level information; Based on the final set of unused permissions and the result confidence level information, the comparison results of the permission declaration list and the permission call mapping table are integrated to output a compliance detection report containing a list of unused permissions and confidence level labels.

10. A privacy permission detection system for game publishing access, characterized in that, include: The permission extraction and obfuscation identification module is used to extract permission declaration lists and decompiled bytecode from the game release code artifacts, identify the degree of code obfuscation and hardening, and obtain symbol retention integrity indicators. The tracking mode determination module is used to determine the target tracking mode based on the symbol retention integrity identifier, wherein the target tracking mode includes a full-link tracking mode and a shallow tracking mode; The permission call mapping module is used to use the bytecode tracing unit to traverse the decompiled bytecode according to the target tracing pattern, locate the actual call location of each permission item, and obtain the permission call mapping table. The unused permission screening module is used to perform a difference operation between the permission declaration list and the permission call mapping table to filter out the permission items that are declared but not called, and obtain the unused permission screening set. The confidence level determination module is used to identify the target tracking patterns of the unused permission initial screening set, wherein the full-link tracking pattern corresponds to high confidence and the shallow tracking pattern corresponds to low confidence, and to determine the confidence level of the result. The filtering verification and report generation module is used to perform filtering verification on the initial screening set of unused permissions according to the confidence level of the results. For high confidence levels, a strict filtering strategy is used to output directly, while for low confidence levels, a lenient filtering strategy is used to expand the retention range, so as to obtain the final set of unused permissions and a compliance detection report.

Images