A hard-coded key leakage detection method and device based on classification detection

Abstract

The application discloses a kind of hard coded key leakage detection method and device based on classification detection, belong to key leakage detection technical field.The low identification rate and high false alarm rate of the prior art traditional hard coded key leakage detection method and device are solved;The code preprocessing module receives source code for pre-processing, and is parsed into abstract syntax tree, to obtain the tree representation of source code syntax structure;Through explicit key detection module, API related key detection module and obfuscated key detection module, the tree representation is classified and detected in parallel;Through result aggregation module, the output candidate key list is aggregated and deduplicated, to obtain the preliminary hard coded key leakage list;Through report generation module, it is formatted to obtain the final hard coded key leakage list and generate detection report.The false alarm rate caused by format similarity is effectively reduced, and the application can be applied to hard coded key leakage detection in complex source code environment.

Description

Technical Field

[0001] This invention relates to the field of key leakage detection technology, specifically to a method and apparatus for detecting hard-coded key leakage based on classification detection. Background Technology

[0002] The leakage of hard-coded keys is a common problem in current applications. Sensitive information such as API keys and database passwords are directly written into code or configuration files, leading to serious security vulnerabilities. This is especially true in the development of mini-programs, which are widely adopted due to their ease of development. However, developers often embed sensitive keys directly into the client-side source code to simplify the development process, exposing the keys in the code. Any attacker who obtains the mini-program installation package can extract this sensitive information through decompilation and static analysis. Existing key detection and evaluation technologies have significant shortcomings and cannot fully solve this security problem. Specifically, traditional detection methods mainly rely on fixed regular expressions or keyword matching, which have low recognition rates for obfuscated keys (such as keys constructed by string splitting and concatenation, array concatenation, or template strings). For example, when the key is split into multiple parts, such as "const a1 = "qv3r9ungafro "; or key: The phrase "qv3r9ungafro" indicates a key claim that is obfuscated and difficult to identify using traditional methods. More critically, existing technologies lack a deep semantic understanding of the key context, making it difficult to distinguish between genuine keys and ordinary strings. For example, a variable name containing "UUID" might be used for general business logic rather than as a key, but existing methods cannot accurately determine its actual purpose, leading to numerous false positives, as detailed below:

[0003] The closest existing technical solutions to this invention mainly rely on fixed rules and pattern matching. The steps of such methods are typically as follows: First, the source code is scanned using a pre-defined library of regular expressions based on keywords (such as "key" or "secret") or fixed formats to match and initially filter out strings suspected to be keys. Next, these filtered candidate strings undergo a second stage of filtering. This stage typically employs an information entropy calculation method, utilizing the characteristic that keys, as highly random strings, have significantly higher information entropy than ordinary text, setting an entropy threshold to exclude some non-key strings, or using a format verification method to compare candidate strings with known API key formats. However, such solutions have significant limitations. Their core flaw lies in a lack of deep understanding of the code context and program semantics. Therefore, when developers use string concatenation, array combination, template strings, or other obfuscation techniques to construct keys, these fixed-pattern-based detection methods struggle to identify the final complete key. Simultaneously, the above methods cannot effectively distinguish between functionally non-key strings that are similar in format (e.g., UUIDs used as unique identifiers), leading to numerous false positives and increasing the burden of manual screening.

[0004] Therefore, the disadvantages of the existing technology are: (1) The existing technology mainly adopts detection methods based on fixed regular expressions or keyword matching, which can only identify keys that appear completely in plain text strings in the code. When developers construct obfuscated keys by splitting and splicing strings, combining arrays or using template strings in order to avoid detection, the detection method based on static pattern matching cannot associate these separated parts, thus failing to identify the final complete key, which directly leads to the low recognition rate of obfuscated keys in the existing technology; (2) The existing technology lacks the ability to perform deep semantic analysis of the code context, and only judges based on the characteristics of the string itself (such as format, information entropy) or simple variable names, so it cannot understand the true intent of the code. This makes it impossible for them to accurately distinguish whether a string is a real sensitive key or an ordinary identifier (such as UUID) used in business logic that just happens to match the key characteristics; the large number of false alarms caused by this greatly increases the cost and workload of subsequent manual verification.

[0005] In summary, a classification-based detection method for detecting the leakage of hard-coded keys is needed. Summary of the Invention

[0006] A brief overview of the invention is given below to provide a basic understanding of certain aspects of the invention. It should be understood that this overview is not an exhaustive summary of the invention. It is not intended to identify key or essential parts of the invention, nor is it intended to limit the scope of the invention. Its purpose is merely to present certain concepts in a simplified form as a prelude to the more detailed description that follows.

[0007] In view of this, in order to solve the problems of low recognition rate and high false alarm rate of traditional hard-coded key leakage detection methods and devices in the prior art, the present invention provides a hard-coded key leakage detection method and device based on classification detection.

[0008] The technical solution is as follows: A hard-coded key leakage detection method based on classification detection, comprising the following steps:

[0009] S1. The source code is received and preprocessed by the code preprocessing module, and parsed into an abstract syntax tree to obtain a tree-like representation of the source code syntax structure.

[0010] S2. Parallel classification and detection of the tree representation are performed by an explicit key detection module based on multi-level rule modeling, an API-related key detection module driven by SDK documentation, and an obfuscated key detection module based on context understanding, and each module outputs a candidate key list.

[0011] S3. The result aggregation module aggregates and removes duplicates from the three candidate key lists to obtain a preliminary list of leaked hard-coded keys;

[0012] S4. The preliminary list of leaked hard-coded keys is formatted using the report generation module to obtain the final list of leaked hard-coded keys and generate a detection report.

[0013] Furthermore, step S2 includes the following steps:

[0014] S21. By matching high-frequency keywords with variable names, the string features are analyzed to complete the high-entropy value detection and the format is verified. The explicit key list is output through the explicit key detection module.

[0015] S22. Perform SDK document parsing and feature extraction using a large language model, dynamically generate detection rules for detection, and output an API-related key list through the API-related key detection module;

[0016] S23. The input of the pre-trained convolutional neural network is obtained through structure vectorization, and the obfuscated pattern recognition is performed. The obfuscated key detection module outputs the obfuscated key list.

[0017] Furthermore, step S21 includes the following steps:

[0018] S211. Using a predefined keyword library, quickly scan the tree-like representation of the source code syntax structure to locate code segments with obvious key characteristics in naming, i.e., those containing content from the predefined keyword library, and treat them as high-priority candidate objects.

[0019] In S211, the predefined keyword library contains variable names, attribute names, or comments that are highly related to the key;

[0020] S212. For the selected high-priority candidate objects and all other string literals in the source code, calculate their information entropy, perform entropy detection according to the set information entropy threshold, filter out ordinary strings, and retain candidate keys with highly complex features.

[0021] S213. Compare the candidate keys with highly complex features with the built-in library of known key formats, and select the candidate keys whose formats match perfectly.

[0022] S214. Mark all candidate strings that pass one or more rule verifications in steps S211-S213 as explicit keys, record their code positions, and form an explicit key list that is output by the explicit key detection module.

[0023] Furthermore, step S22 includes the following steps:

[0024] S221. Take the official documentation of one or more target SDKs as input to the large language model, and extract key information related to the key, i.e. key features, through the large language model;

[0025] In S221, the key characteristics include: 1) the variable name or parameter name used by the API key in the code; 2) the specific format of the key; and 3) the name of the API function or method corresponding to the key.

[0026] S222. Based on key features, dynamically generate a set of highly customized detection rules, which are specifically high-precision regular expressions or logical rules describing the context;

[0027] S223. Apply highly customized detection rules to the tree-like representation of the source code syntax structure, and lock the hard-coded key associated with a specific SDK by matching;

[0028] S224. Mark all hard-coded keys related to a specific SDK as API-related keys, and form and output an API-related key list through the API-related key detection module.

[0029] Furthermore, step S22 includes the following steps:

[0030] S231. Convert the tree-like representation of the source code syntax structure into a numerical representation suitable for input neural networks;

[0031] S232. Input the numerically represented code structure into a pre-trained convolutional neural network model for filtering, and output a list of suspicious code segments, which includes all code segments identified as having obfuscated construction patterns and their locations.

[0032] S233. Extract the context code for each suspicious code segment, extract the surrounding code from the abstract syntax tree to form a complete context environment, which includes the location where the variables involved in the suspicious code segment are defined, and the function or application location where the constructed string is ultimately passed.

[0033] S234. Input the suspicious code fragment and its complete context into the large language model for semantic understanding and judgment, and analyze the actual use of the string in the source code program.

[0034] S235. When the actual use of the obtained key is as a key, mark it as a scrambled key, record its relevant information, and form and output a scrambled key list through the scrambled key detection module.

[0035] Technical Solution 2: A hard-coded key leakage detection device based on classification detection, used to execute the hard-coded key leakage detection method based on classification detection described in Technical Solution 1, including a code preprocessing module, an explicit key detection module, an API-related key detection module, an obfuscated key detection module, a result aggregation module, and a report generation module;

[0036] The code preprocessing module is connected to the explicit key detection module, the code preprocessing module is connected to the API-related key detection module, and the code preprocessing module is connected to the obfuscation key detection module.

[0037] The obfuscation key detection module includes a CNN filtering submodule and an LLM filtering submodule connected in sequence;

[0038] The explicit key detection module is connected to the result aggregation module, the API-related key detection module is connected to the result aggregation module, and the obfuscated key detection module is connected to the result aggregation module.

[0039] The result aggregation module is connected to the report generation module.

[0040] The beneficial effects of this invention are as follows: This invention proposes a hard-coded key identification method based on classification detection. By constructing a multi-dimensional detection system, including multi-level rule modeling for explicit keys, SDK document-driven analysis for API-related keys, and contextual understanding methods for obfuscated keys, it effectively identifies various types of hard-coded keys (including explicit keys, API-related keys, and obfuscated keys), especially obfuscated keys constructed through string concatenation, array combination, etc., and accurately assesses the actual impact of key leakage. This invention divides keys into three categories and designs specialized detection schemes for different types of keys: 1) For explicit keys, a detection method based on multi-level rule modeling is used; 2) For API-related keys, an SDK document-driven detection method is used, utilizing a large language model to summarize key features from documents; 3) For obfuscated keys, a two-stage method based on contextual understanding is used, first using a CNN model for structured filtering, and then using a large language model for filtering based on contextual code. Simultaneously, by introducing contextual semantic understanding based on a large language model, this invention can accurately distinguish between real keys and ordinary strings in business logic, thereby significantly improving the accuracy of hard-coded key identification while greatly reducing the false positive rate.

[0041] This invention classifies keys into three categories: explicit keys, API-related keys, and obfuscated keys, and designs specific detection strategies for each category. This fundamentally overcomes the problem of insufficient detection capability caused by the use of a single rule or uniform pattern matching in existing technologies. Since different types of keys have significant differences in syntax, construction methods, and usage contexts, traditional methods can hardly simultaneously achieve both detection accuracy and coverage. However, the classification detection mechanism of this invention can achieve comprehensive recognition of multiple key forms while maintaining the relevance of the rules, thereby significantly improving the overall recall rate of hard-coded key detection.

[0042] Meanwhile, to address the problem that existing technologies struggle to identify obfuscated key constructions such as string concatenation and array combination, this invention proposes a detection method based on a combination of code structure and contextual semantics. By first filtering the code structure and then combining contextual information to determine the actual purpose of suspicious strings, it can effectively associate scattered key construction fragments and accurately distinguish between real keys and ordinary business strings. Thus, this invention significantly reduces the false alarm rate caused by similar formats while improving the ability to identify obfuscated keys, making the detection results more accurate and reliable. Attached Figure Description

[0043] The accompanying drawings, which are included to provide a further understanding of the invention and form part of this invention, illustrate exemplary embodiments of the invention and are used to explain the invention, but do not constitute an undue limitation of the invention. In the drawings:

[0044] Figure 1This is a flowchart illustrating a classification-based method for detecting the leakage of hard-coded keys.

[0045] Figure 2 This is a schematic diagram illustrating the overall execution sequence of a classification-based hard-coded key leakage detection method;

[0046] Figure 3 This is a flowchart illustrating the explicit key detection process.

[0047] Figure 4 This is a flowchart illustrating the API-related key detection process.

[0048] Figure 5 A schematic diagram illustrating the principle of obfuscation key detection;

[0049] Figure 6 A flowchart illustrating the process of detecting obfuscation keys;

[0050] Figure 7 This is a schematic diagram of a hard-coded key leakage detection device based on classification detection.

[0051] Figure descriptions: 501. Code preprocessing module; 502. Explicit key detection module; 503. API related key detection module; 504. Obfuscation key detection module; 505. Result aggregation module; 506. Report generation module. Detailed Implementation

[0052] To make the technical solutions and advantages of the embodiments of the present invention clearer, the exemplary embodiments of the present invention will be further described in detail below with reference to the accompanying drawings. Obviously, the described embodiments are only a part of the embodiments of the present invention, and not an exhaustive list of all embodiments. It should be noted that, unless otherwise specified, the embodiments and features in the embodiments of the present invention can be combined with each other.

[0053] Example 1: Reference Figures 1-7 This embodiment describes a method for detecting the leakage of hard-coded keys based on classification detection, specifically including the following steps:

[0054] S1. The source code is received and preprocessed by the code preprocessing module, and parsed into an abstract syntax tree to obtain a tree-like representation of the source code syntax structure.

[0055] S2. Parallel classification and detection of the tree representation are performed by an explicit key detection module based on multi-level rule modeling, an API-related key detection module driven by SDK documentation, and an obfuscated key detection module based on context understanding, and each module outputs a candidate key list.

[0056] S3. The result aggregation module aggregates and removes duplicates from the three candidate key lists to obtain a preliminary list of leaked hard-coded keys;

[0057] S4. The preliminary list of leaked hard-coded keys is formatted using the report generation module to obtain the final list of leaked hard-coded keys and generate a detection report.

[0058] Specifically, in step S1, the source code preprocessing involves the device receiving the source code of the application to be tested as input. To facilitate subsequent structured analysis, the device first preprocesses the source code, parsing it into an Abstract Syntax Tree (AST). An AST is a tree-like representation of the syntactic structure of the source code. It ignores the surface details of the code (such as punctuation and spaces) and focuses on its internal logical structure, providing a structured foundation for subsequent context analysis, data flow tracing, and pattern recognition.

[0059] In the parallel classification and detection step S2, after obtaining the abstract syntax tree of the code, the device starts three independent detection modules in parallel, which respectively detect explicit keys, API-related keys and obfuscated keys. This parallel processing design improves detection efficiency.

[0060] The explicit key detection in step S21 enters the explicit key detection process based on multi-level rule modeling, which is specifically used to identify keys that appear directly in the code in plaintext form.

[0061] Step S22, API-related key detection, enters the API-related key detection process driven by SDK (Software Development Kit) documentation, which focuses on identifying keys related to specific third-party service API calls;

[0062] Step S23, the obfuscated key detection, enters a two-stage obfuscated key detection process based on context understanding. This step, as one of the core innovations of this invention, is used to identify keys obfuscated by string concatenation, array combination, and other methods.

[0063] Step S3: After the three parallel detection branches are completed, each outputs a candidate key list. In this step, these three lists are aggregated. Since different detection methods may identify the same key (for example, an explicit key is also an API key), deduplication is required to merge duplicate detection results into one, forming a preliminary, unique hard-coded key leakage list.

[0064] Here's an example of deduplication and aggregation: Assume the string "AKIAIOSFODNN7EXAMPLE" exists on line 15 of the config.js file of the project to be detected. The explicit key detection module marks it as an explicit key based on high entropy and format validation rules. The API-related key detection module simultaneously identifies the same string as an AWS Access Key ID based on the detection rules generated by the AWS SDK documentation. During the aggregation phase, the system compares the three candidate lists one by one using the triplet (file path, line number, string value) as a unique identifier. The two records mentioned above match the same unique identifier, so they are merged into one record, while retaining the type labels of the two detection sources. In the final output, this entry is: line 15 of file config.js, string value "AKIAIOSFODNN7EXAMPLE", detection type "explicit key / API-related key (AWS AccessKey ID)";

[0065] Step S4: Format the aggregated and deduplicated key list to generate the final detection report. The report will list in detail each detected hard-coded key, its specific location in the source code (file, line number), the key type (explicit, API-related, or obfuscated), and related code snippets as evidence for developers or security personnel to review and fix.

[0066] Furthermore, step S2 includes the following steps:

[0067] S21. By matching high-frequency keywords with variable names, the string features are analyzed to complete the high-entropy value detection and the format is verified. The explicit key list is output through the explicit key detection module.

[0068] S22. Perform SDK document parsing and feature extraction using a large language model, dynamically generate detection rules for detection, and output an API-related key list through the API-related key detection module;

[0069] S23. The input of the pre-trained convolutional neural network is obtained through structure vectorization, and the obfuscated pattern recognition is performed. The obfuscated key detection module outputs the obfuscated key list.

[0070] Furthermore, step S21 includes the following steps:

[0071] S211. Using a predefined keyword library, quickly scan the tree-like representation of the source code syntax structure. This step aims to quickly locate code segments with obvious key characteristics in naming, i.e., those containing content in the predefined keyword library, and treat them as high-priority candidates.

[0072] In S211, the predefined keyword library contains a large number of variable names, attribute names or comments that are highly related to the key, such as "key", "secret", "token", "password", "secretKey", etc.

[0073] S212. For the selected high-priority candidate objects and all other string literals in the source code, calculate their information entropy, perform entropy detection according to the set information entropy threshold, filter out ordinary strings, and retain candidate keys with highly complex features.

[0074] In step S212, the information entropy H(S) is calculated using the Shannon entropy formula H(S) = -Σp(c)·log2p(c), with a threshold typically set to 3.5 bits / character. Here, H(S) is the information entropy of the string, and p(c) is the frequency of character c in the string (i.e., the number of times the character appears divided by the total string length). High complexity features refer to relatively garbled strings with a rich variety of characters and a uniform distribution. Strings with consecutive repetitions or fixed word frequencies are filtered out at this stage.

[0075] S213. Compare the candidate keys with highly complex features with the built-in library of known key formats, and select the candidate keys whose formats match perfectly.

[0076] In S213, the known key format library stores a large number of API key formats of common service providers (such as cloud services, social platforms, payment interfaces, etc.), which are usually defined in the form of regular expressions (for example, the AccessKey of a certain cloud service is usually a combination of 20 uppercase letters and numbers). If the format of a candidate key matches a certain format in the library exactly, it is highly likely to be a real key.

[0077] S214. Mark all candidate strings that pass one or more rule verifications in steps S211-S213 as explicit keys, and record their code positions and other information to form an explicit key list that is output by the explicit key detection module for subsequent aggregation.

[0078] Furthermore, step S22 includes the following steps:

[0079] S221. Take the official documentation of one or more target SDKs as input to the large language model, and extract key information related to the key, i.e. key features, through the large language model;

[0080] In S221, the large language model is used to read and understand unstructured document text. Key features include: 1) the variable names or parameter names that API keys typically use in the code; 2) the specific format of the key (length, character set, prefix, etc.); and 3) the name of the API function or method corresponding to the key.

[0081] S222. Based on key features, dynamically generate a set of highly customized detection rules, which are specifically high-precision regular expressions or logical rules describing the context;

[0082] Specifically: The highly customized detection rule established in this embodiment is that "in a function call named 'setApiKey', if the first parameter is a string that conforms to a specific format, then that string is the key."

[0083] S223. Apply highly customized detection rules to the tree-like representation of the source code syntax structure, and lock the hard-coded key associated with a specific SDK by matching;

[0084] S224. Mark all hard-coded keys related to a specific SDK as API-related keys, form an API-related key list and output it through the API-related key detection module for subsequent aggregation.

[0085] Furthermore, step S22 includes the following steps:

[0086] S231. Convert the tree-like representation of the source code syntax structure into a numerical representation (vector or matrix) suitable for input neural networks.

[0087] Specifically, in this embodiment, the AST node type, variable name, operator, etc. are encoded to form a structured data representation, which preserves the syntactic structure information of the code;

[0088] S232. Input the numerically represented code structure into a pre-trained convolutional neural network (CNN) model for filtering, and output a list of suspicious code segments, which includes all code segments identified as having a confusing construction pattern and their locations.

[0089] Specifically, the CNN model is trained to identify common string obfuscation patterns in code, such as continuous string concatenation ("a"+"b"+"c"), constructing strings using the array join method (['a','b','c'].join('')) or inserting variables using template strings. The role of the CNN model at this stage is not to directly find the key, but to act as an efficient filter to quickly locate code snippets containing such "suspicious" construction behaviors.

[0090] S233. Extract the context code for each suspicious code segment, extract the surrounding code from the abstract syntax tree to form a complete context environment, which includes the location where the variables involved in the suspicious code segment are defined, and the function or application location where the constructed string is ultimately passed.

[0091] S234. Input the suspicious code fragment and its complete context into the large language model for semantic understanding and judgment. With its powerful code understanding and logical reasoning capabilities, LLM analyzes the actual use of the string in the source code program.

[0092] Specifically, in this embodiment, the large language model will determine whether the string is used as an authentication header for a network request, a password for a database connection, or simply a regular long string for UI display.

[0093] S235. When the actual use of the obtained key is as a key, it is marked as a scrambled key, and its relevant information is recorded. A scrambled key list is formed and output through the scrambled key detection module for subsequent aggregation.

[0094] Specifically, this invention is based on static code analysis and dynamic runtime analysis. Static analysis typically involves lexical and syntactic parsing of the source code, constructing an abstract syntax tree (AST), and tracking the use of sensitive information through data flow analysis. Dynamic analysis, on the other hand, intercepts and decrypts the network traffic of the application during runtime by setting up a man-in-the-middle network proxy (MITM) to verify the actual use and validity of the key. The above technologies constitute the basis for this invention to detect the leakage of hard-coded keys.

[0095] refer to Figure 1 The diagram illustrates the overall flow of the hard-coded key detection method of this invention. Step S1 involves a code preprocessing module performing lexical and syntactic analysis on the input source code, transforming it into an Abstract Syntax Tree (AST) to obtain a unified tree-like representation of the source code's syntactic structure. Step S2 simultaneously launches three parallel detection modules: an explicit key detection module based on multi-layer rule modeling, an API-related key detection module driven by SDK documentation, and an obfuscated key detection module based on context understanding. Each module runs independently and outputs its own candidate key list. Step S3 merges and deduplicates the three candidate key lists using a result aggregation module to obtain a preliminary hard-coded key leakage list. Step S4 formats the list using a report generation module, outputting the final hard-coded key leakage list and generating a detection report.

[0096] refer to Figure 2The diagram shows the overall architecture of the key extractor, corresponding to the design principle of the three-way detection module in stage S2, covering three complementary extraction methods. Method A is context-aware key extraction, corresponding to the core idea of ​​the explicit key detection module: by summarizing the context distribution patterns of common keys, a context feature library is established to extract target strings in a targeted manner. Method B is SDK document-driven key extraction, corresponding to the explicit key detection module: by combining common SDK samples and LLM's automatic summary of key formats, combined with API request feature filtering, a string feature architecture covering length, prefixes and suffixes, string composition, and context content is constructed to guide subsequent rule matching. Method C is context-understanding LLM two-stage extraction, corresponding to the context-understanding obfuscated key detection module: the first stage performs coarse screening by filtering by string format, and the second stage uses LLM to perform deep semantic understanding and judgment of the candidate's context, outputting the final candidate key;

[0097] refer to Figure 3 This document details the implementation of the explicit key detection module. This module takes JS files, configuration files, and JSON files as input and executes the following sequentially within the rule matching module: field pattern recognition (corresponding to S211, performing high-frequency keyword matching on identifiers such as variable names and attribute names), contextual semantic analysis and multi-dimensional string filtering (corresponding to S212, performing high-complexity filtering based on string features and information entropy), and a whitelist exclusion mechanism (corresponding to S213, validating and excluding based on known legal formats). After layer-by-layer filtering by the above rules, the candidate results are marked with position and type, and the explicit key detection result is output in a structured form of "file path + variable name + key value" (corresponding to S214).

[0098] refer to Figure 2 This is a knowledge-driven implementation scheme for the API-related key detection module. Step S221 generates a structured feature template from diverse knowledge sources such as official SDK documentation, developer communities, open-source project code snippets, and third-party API descriptions through LLM-driven document parsing and key feature extraction. Step S222, based on this, dynamically generates a detection rule set for a specific SDK through static code scanning, URL matching, and semantic co-occurrence analysis. Step S223 applies the above rules to the AST for scanning and matching. Step S224, the API verification module classifies and confirms the results, outputting a list of API-related keys according to categories such as cloud services, map services, and AI services. This solves the problem that traditional rule bases are difficult to adapt to the rapid iteration of massive SDKs.

[0099] refer to Figure 5This describes the dual-model fusion principle of the obfuscated key detection module. The module extracts candidate key content and surrounding context code from the source code file as two independent inputs: the key content is fed into the key model (corresponding to S232, CNN structural feature recognition) for string-based discrimination, and the context code is fed into the context model (corresponding to S234, LLM semantic understanding) for semantic association analysis; the outputs of the two models are merged and combined for a comprehensive decision (corresponding to S235) to finally identify and output the leaked key.

[0100] refer to Figure 7 This document details the processing flow of the obfuscated key detection module. After the source code is input, step S231 uses regular expression scanning combined with frequency filtering to initially extract candidate strings and vectorize the code structure. Step S232 feeds the vectorized result into a CNN model for obfuscation pattern recognition, filtering out suspicious code segments with obfuscated features (S233). Step S234 extracts context code from the suspicious segments and feeds it into an LLM for semantic reasoning and judgment. Step S235 outputs the results determined to be genuine keys, forming the final obfuscated key list. This process embodies a two-stage design: "CNN lightweight structure filtering first, followed by LLM deep semantic precision judgment," balancing detection efficiency and accuracy.

[0101] Example 2: Reference Figure 7 This embodiment describes a hard-coded key leakage detection device based on classification detection, used to execute a hard-coded key leakage detection method based on classification detection as described in Embodiment 1. The device includes a code preprocessing module 501, an explicit key detection module 502, an API-related key detection module 503, an obfuscated key detection module 504, a result aggregation module 505, and a report generation module 506.

[0102] The code preprocessing module 501 is connected to the explicit key detection module 502, the code preprocessing module 501 is connected to the API-related key detection module 503, and the code preprocessing module 501 is connected to the obfuscation key detection module 504.

[0103] The obfuscation key detection module 504 includes a CNN filtering submodule 504a and an LLM filtering submodule 504b connected in sequence.

[0104] The explicit key detection module 502 is connected to the result aggregation module 505, the API related key detection module 503 is connected to the result aggregation module 505, and the obfuscated key detection module 504 is connected to the result aggregation module 505.

[0105] The result aggregation module 505 is connected to the report generation module 506.

[0106] Specifically, the code preprocessing module 501 is used to receive source code and parse it into an abstract syntax tree, providing a unified and structured data input for all subsequent analysis modules;

[0107] The explicit key detection module 502 is used to implement the explicit key detection scheme, and integrates functions such as keyword matching, high entropy value calculation and known format verification.

[0108] The API-related key detection module 503 is used to implement the API-related key detection scheme, which embeds a large language model to parse SDK documents and dynamically generate detection rules.

[0109] The obfuscation key detection module 504 is used to implement the obfuscation key detection scheme, the CNN filtering submodule 504a is used to efficiently identify and filter out code structures with potential obfuscation patterns from the code, and the LLM filtering submodule 504b is used to perform in-depth contextual semantic analysis on the code segments filtered by CNN to make a final judgment.

[0110] The result aggregation module 505 is used to collect the detection results from the above three detection modules, and perform deduplication to form a unified leakage list;

[0111] The report generation module 506 is used to format the final key leakage list and generate a detailed and readable detection report.

[0112] Although the invention has been described with reference to a limited number of embodiments, those skilled in the art will understand from the foregoing description that other embodiments are conceivable within the scope of the invention described herein. Furthermore, it should be noted that the language used in this specification has been chosen primarily for readability and edibility purposes, and not for the purpose of interpreting or limiting the subject matter of the invention. Therefore, many modifications and variations will be apparent to those skilled in the art without departing from the scope and spirit of the appended claims. The disclosure of the invention is illustrative and not restrictive, and the scope of the invention is defined by the appended claims.

Claims

1. A method for detecting the leakage of hard-coded keys based on classification detection, characterized in that, Includes the following steps: S1. The source code is received and preprocessed by the code preprocessing module, and parsed into an abstract syntax tree to obtain a tree-like representation of the source code syntax structure. S2. Parallel classification and detection of the tree representation are performed by an explicit key detection module based on multi-level rule modeling, an API-related key detection module driven by SDK documentation, and an obfuscated key detection module based on context understanding, and each module outputs a candidate key list. S3. The result aggregation module aggregates and removes duplicates from the three candidate key lists to obtain a preliminary list of leaked hard-coded keys; S4. The preliminary list of leaked hard-coded keys is formatted using the report generation module to obtain the final list of leaked hard-coded keys and generate a detection report.

2. The method for detecting hard-coded key leakage based on classification detection according to claim 1, characterized in that, S2 includes the following steps: S21. By matching high-frequency keywords with variable names, the string features are analyzed to complete the high-entropy value detection and the format is verified. The explicit key list is output through the explicit key detection module. S22. Perform SDK document parsing and feature extraction using a large language model, dynamically generate detection rules for detection, and output an API-related key list through the API-related key detection module; S23. The input of the pre-trained convolutional neural network is obtained through structure vectorization, and the obfuscated pattern recognition is performed. The obfuscated key detection module outputs the obfuscated key list.

3. The method for detecting hard-coded key leakage based on classification detection according to claim 2, characterized in that, S21 includes the following steps: S211. Using a predefined keyword library, quickly scan the tree-like representation of the source code syntax structure to locate code segments with obvious key characteristics in naming, i.e., those containing content from the predefined keyword library, and treat them as high-priority candidate objects. In S211, the predefined keyword library contains variable names, attribute names, or comments that are highly related to the key; S212. For the selected high-priority candidate objects and all other string literals in the source code, calculate their information entropy, perform entropy detection according to the set information entropy threshold, filter out ordinary strings, and retain candidate keys with highly complex features. S213. Compare the candidate keys with highly complex features with the built-in library of known key formats, and select the candidate keys whose formats match perfectly. S214. Mark all candidate strings that pass one or more rule verifications in steps S211-S213 as explicit keys, record their code positions, and form an explicit key list that is output by the explicit key detection module.

4. The method for detecting hard-coded key leakage based on classification detection according to claim 3, characterized in that, S22 includes the following steps: S221. Take the official documentation of one or more target SDKs as input to the large language model, and extract key information related to the key, i.e. key features, through the large language model; In S221, the key characteristics include: 1) the variable name or parameter name used by the API key in the code; 2) the specific format of the key; and 3) the name of the API function or method corresponding to the key. S222. Based on key features, dynamically generate a set of highly customized detection rules, which are specifically high-precision regular expressions or logical rules describing the context; S223. Apply highly customized detection rules to the tree-like representation of the source code syntax structure, and lock the hard-coded key associated with a specific SDK by matching; S224. Mark all hard-coded keys related to a specific SDK as API-related keys, and form and output an API-related key list through the API-related key detection module.

5. The method for detecting hard-coded key leakage based on classification detection according to claim 4, characterized in that, S22 includes the following steps: S231. Convert the tree-like representation of the source code syntax structure into a numerical representation suitable for input neural networks; S232. Input the numerically represented code structure into a pre-trained convolutional neural network model for filtering, and output a list of suspicious code segments, which includes all code segments identified as having obfuscated construction patterns and their locations. S233. Extract the context code for each suspicious code segment, extract the surrounding code from the abstract syntax tree to form a complete context environment, which includes the location where the variables involved in the suspicious code segment are defined, and the function or application location where the constructed string is ultimately passed. S234. Input the suspicious code fragment and its complete context into the large language model for semantic understanding and judgment, and analyze the actual use of the string in the source code program. S235. When the actual use of the obtained key is as a key, mark it as a scrambled key, record its relevant information, and form and output a scrambled key list through the scrambled key detection module.

6. A hard-coded key leakage detection device based on classification detection, characterized in that, The method for performing a hard-coded key leakage detection method based on classification detection as described in any one of claims 1-5 includes a code preprocessing module (501), an explicit key detection module (502), an API-related key detection module (503), an obfuscated key detection module (504), a result aggregation module (505), and a report generation module (506). The code preprocessing module (501) is connected to the explicit key detection module (502), the code preprocessing module (501) is connected to the API related key detection module (503), and the code preprocessing module (501) is connected to the obfuscation key detection module (504). The obfuscation key detection module (504) includes a CNN filtering submodule (504a) and an LLM filtering submodule (504b) connected in sequence. The explicit key detection module (502) is connected to the result aggregation module (505), the API related key detection module (503) is connected to the result aggregation module (505), and the obfuscated key detection module (504) is connected to the result aggregation module (505). The result aggregation module (505) is connected to the report generation module (506).

Images