An intent penetration testing method and an intent penetration testing system

Abstract

The present application relates to a kind of intention penetration test system and its method.The system includes: static analysis module, parses application and extracts application explicit component to obtain static analysis result;Reflection call tracking and confusion restoration module, based on the interception of application runtime reflection call based on the technology of plug-in and parse call stack to locate hidden processor and output reflection call confusion restoration result;Dynamic component full life cycle capture module, intercepts tracking component registration, modification, cancellation in application to obtain dynamic analysis result;Static dynamic two-way fusion engine, static analysis result, dynamic analysis result and reflection call confusion restoration result are fused to generate full test template;Test case generation and adaptation module, based on full test template and reflection call confusion restoration result generates test case;And test execution and result collection module, test case is sent to test target and collects the execution result of test case.

Description

Technical Field

[0001] This invention relates to the field of mobile application security testing technology, and more specifically, to an intent penetration testing method and an intent penetration testing system. Background Technology

[0002] Current industry solutions for Android Intent testing (Intent, in Android development, is a message passing object used for communication between components such as Activity, Service, and BroadcastReceiver, to launch other components, or to pass data) are primarily based on static analysis, supplemented by simple dynamic analysis. However, they have not formed a complete technical loop. The specific implementation methods and architectural features of existing technologies are as follows: The core architecture consists of two main parts: a static analysis module and a basic dynamic instrumentation module. Some tools supplement this with a simple test case generation module, but there is a lack of data interaction mechanisms between modules. The static analysis module is responsible for parsing AndroidManifest.xml and decompiling code, while the dynamic instrumentation module mainly uses Xposed or Frida to intercept basic APIs. The two modules run independently.

[0003] Static analysis implementation method: Relying on APK decompilation tools (such as Apktool, JD-GUI) to extract explicit code structure, and obtaining statically declared components such as Activity, Service, BroadcastReceiver and corresponding IntentFilter rules by parsing the Manifest file; performing syntax analysis on the decompiled code to extract explicit Intent processing logic such as getStringExtra and putExtra, forming a basic test target list.

[0004] Dynamic auxiliary implementation method: Use hook technology to intercept a small number of core Intent APIs (such as startActivity, sendBroadcast) and record the Intent data sent by the application at runtime to supplement explicit communication scenarios not covered by static analysis; some tools attempt to intercept registerReceiver, but can only obtain basic component instances and cannot parse dynamically modified IntentFilter rules.

[0005] Test case generation logic: Based on the component information extracted from static analysis and the IntentFilter rules, test cases with a fixed format are generated, only replacing the numerical content of the extras field, without designing adaptation strategies for obfuscation, reflection and other scenarios.

[0006] The above technical solutions have fundamental flaws when dealing with dynamic and hidden scenarios in Intent testing. The specific problems are as follows: Static analysis has significant limitations: it relies on explicit code structure and Manifest declarations, cannot identify the Intent processing logic of reflection calls (such as the getExtra call triggered by Method.invoke), and cannot restore obfuscated field names and component class names, resulting in a large number of hidden processors not being included in the testing scope.

[0007] Incomplete capture of dynamic components: Only the basic registration API is intercepted, and key methods such as unregisterReceiver and IntentFilter.addAction are not tracked. The component deregistration status and dynamically updated filter rules cannot be obtained. The test only covers statically declared components and some initially registered dynamic components.

[0008] Data fragmentation and lack of integration mechanism: Static analysis results and dynamically captured data are independent of each other. No data integration algorithm is designed, and it is impossible to supplement dynamically acquired reflection parameters, temporary filter rules, etc. into the static test target, resulting in a large number of omissions in test cases.

[0009] Lack of exception handling and scenario adaptation: It does not consider exception scenarios such as InvocationTargetException of reflection call and duplicate registration of dynamic components, which can easily lead to the invalidation or duplication of captured data. Summary of the Invention

[0010] To address the problems in the prior art, the present invention aims to provide an intent penetration testing method and system that can improve the comprehensiveness, accuracy, and robustness of testing.

[0011] The intent penetration testing system of this invention includes: The static analysis module is used to parse the application and extract its explicit components to obtain static analysis results. The reflection call tracing and obfuscation restoration module is used to intercept reflection calls during application runtime based on instrumentation technology, parse the call stack to locate hidden processors, and output the reflection call obfuscation restoration results. The dynamic component lifecycle capture module is used to intercept and track the registration, modification, and deregistration of components in the application, and to capture components temporarily registered at runtime in combination with intent filter rules to obtain dynamic analysis results; A static and dynamic bidirectional fusion engine is used to fuse the static analysis results, the dynamic analysis results, and the reflection call obfuscation and restoration results to generate a full test template. The test case generation and adaptation module is used to generate test cases based on the full test template and the reflection call obfuscation and restoration results; and The test execution and result collection module is used to send the test cases to the test target and collect the execution results of the test targets executing the test cases.

[0012] Optionally, the static analysis results include: the initial logic graph and reflection call obfuscation points. The static analysis module parses the application's Android manifest file to extract statically registered components and intent filter rules, decompiles the application code to construct an initial logic graph, and marks potential reflection call obfuscation points in the code.

[0013] Optionally, the initial logic graph includes one or more of the following: Component class name, intent filter rules, known extras keys, and method call relationships.

[0014] Optionally, the reflection call tracing and obfuscation restoration module intercepts runtime reflection calls based on JVMTI or Frida instrumentation technology, parses the call stack to locate hidden handlers, restores obfuscated fields and hidden handlers, and verifies the accuracy of the restoration.

[0015] Optionally, the reflection call tracing and obfuscation restoration module applies the instrumentation technique only to the reflection call obfuscation points output by the static analysis module.

[0016] Optionally, the dynamic component lifecycle capture module intercepts the registration, deregistration, and intent filter modification of components in the application, records the state changes of dynamically registered components in real time, obtains the latest intent filter rules for each dynamic component, and marks deregistered components.

[0017] Optionally, the static-dynamic bidirectional fusion engine guides the dynamic instrumentation range based on the static analysis results, eliminates irrelevant monitoring overhead, and completes the initial logic graph into the static graph based on the dynamic analysis results.

[0018] Optionally, the static-dynamic bidirectional fusion engine further performs data verification and data deduplication.

[0019] Optionally, the data verification rules include one or more of the following: the component class name exists in the application's class list; the intent filter rules conform to the Android specification; the obfuscation mapping passes closed-loop verification. The data deduplication includes performing deduplication based on the component class name and the signature of the intent filter.

[0020] Optionally, the test case generation and adaptation module generates test cases directly based on intent filter rules for static components, replaces the original fields in the test cases with obfuscation keys for hidden components to ensure matching of hidden processors, and generates test cases based on real-time filter rules for dynamic components.

[0021] The intent penetration testing method of one aspect of the present invention includes the following steps: The static analysis step involves parsing the application and extracting its explicit components to obtain the static analysis results. The reflection call tracing and obfuscation restoration steps are based on instrumentation technology to intercept reflection calls during application runtime, parse the call stack to locate hidden processors, and output the reflection call obfuscation restoration results. The entire lifecycle of dynamic components is captured, intercepting and tracking the registration, modification, and deregistration of components in the application, and combining intent filter rules to capture components temporarily registered at runtime to obtain dynamic analysis results; The static and dynamic bidirectional fusion step integrates the static analysis results, the dynamic analysis results, and the reflection call obfuscation and restoration results to generate a full test template. The test case generation and adaptation steps involve generating test cases based on the full test template and the obfuscation and restoration results of the reflection call; and The test execution and result collection steps involve sending the test cases to the test target and collecting the execution results of the test cases executed by the test target.

[0022] Optionally, the static analysis results include: the initial logic graph and reflection call obfuscation points. In the static analysis step, the Android manifest file of the application is parsed to extract statically registered components and intent filter rules, and the application code is decompiled to build an initial logic graph, and potential reflection call obfuscation points in the code are marked.

[0023] Optionally, the initial logic graph includes one or more of the following: Component class name, intent filter rules, known extras keys, and method call relationships.

[0024] Optionally, in the reflection call tracing and obfuscation restoration step, runtime reflection calls are intercepted based on JVMTI or Frida instrumentation technology, the call stack is parsed to locate hidden handlers, obfuscated fields and hidden handlers are restored, and the accuracy of the restoration is verified.

[0025] Optionally, in the reflection call tracing and obfuscation restoration step, the instrumentation technique is applied only to the reflection call obfuscation points output by the static analysis step.

[0026] Optionally, in the dynamic component lifecycle capture step, the registration, deregistration, and intent filter modification of components in the application are intercepted, the state changes of dynamically registered components are recorded in real time, the latest intent filter rules of each dynamic component are obtained, and deregistered components are marked.

[0027] Optionally, in the static-dynamic bidirectional fusion step, the dynamic instrumentation range is guided based on the static analysis results, irrelevant monitoring overhead is eliminated, and the initial logic graph is completed into the static graph based on the dynamic analysis results.

[0028] Optionally, in the static-dynamic bidirectional fusion step, further data verification and deduplication are performed to ensure that the fused information is authentic, valid, and free of duplication.

[0029] Optionally, the data verification rules include one or more of the following: the component class name exists in the application's class list; the intent filter rules conform to the Android specification; the obfuscation mapping passes closed-loop verification. The data deduplication includes performing deduplication based on the component class name and the signature of the intent filter.

[0030] Optionally, the test case generation and adaptation steps generate test cases directly based on intent filter rules for static components, replace the original fields in the test cases with obfuscation keys for hidden components to ensure matching of hidden processors, and generate test cases based on real-time filter rules for dynamic components.

[0031] The present invention provides a computer-readable medium having a computer program stored thereon, which, when executed by a processor, implements the aforementioned intent penetration testing method.

[0032] A computer device according to one aspect of the present invention includes a storage module, a processor, and a computer program stored on the storage module and executable on the processor, wherein the processor executes the computer program to implement the intent penetration testing method.

[0033] A computer program product according to one aspect of the present invention includes a computer program that, when executed by a processor, implements the aforementioned intent penetration testing method. Attached Figure Description

[0034] The described and other objects and advantages of the invention will become more fully clear from the following detailed description taken in conjunction with the accompanying drawings, wherein like or similar elements are denoted by the same reference numerals.

[0035] Figure 1 This is a structural block diagram illustrating an embodiment of the penetration testing system of the present invention.

[0036] Figure 2This is a schematic flowchart illustrating an embodiment of the penetration testing method of the present invention. Detailed Implementation

[0037] The following are some embodiments of the present invention, intended to provide a basic understanding of the invention. They are not intended to identify key or decisive elements of the invention or to limit the scope of protection sought.

[0038] For purposes of brevity and illustrativeness, the principles of the invention are described herein primarily with reference to exemplary embodiments thereof. However, those skilled in the art will readily recognize that the same principles are equivalently applicable to all types of intent penetration testing methods and systems of the invention, and that these same principles can be implemented therein, and that any such variations do not depart from the true spirit and scope of the invention.

[0039] Furthermore, reference is made in the following description to the accompanying drawings, which illustrate specific exemplary embodiments. Electrical, mechanical, logical, and structural modifications may be made to these embodiments without departing from the spirit and scope of the invention. Moreover, while features of the invention are disclosed in conjunction with only one of several embodiments, this feature may be combined with one or more other features of other embodiments if desired and / or advantageous for any given or identifiable function. Therefore, the following description should not be considered limiting in any sense, and the scope of the invention is defined by the appended claims and their equivalents.

[0040] Terms such as “possessing” and “comprising” indicate that, in addition to having units (modules) and steps that are directly and explicitly stated in the specification and claims, the technical solution of the present invention does not exclude the presence of other units (modules) and steps that are not directly or explicitly stated.

[0041] In the following text, “Filter” refers to a filter, “Intent” refers to an intent, and “IntentFilter” refers to an intent filter.

[0042] Figure 1 This is a structural block diagram illustrating an embodiment of the penetration testing system of the present invention.

[0043] like Figure 1 As shown, an embodiment of the present invention, an intent penetration testing system 100, includes: The static analysis module 110 is used to parse the Manifest to extract static components and to decompile the APK to generate an "explicit Intent processing logic graph" (including, for example, method call relationships and extras key types) and mark potential reflection / obfuscation points; The reflection call tracing and obfuscation restoration module 120 is used to parse the reflection call stack based on JVMTI / Frida instrumentation, restore obfuscated fields and hidden handlers, and verify the accuracy of obfuscation mapping. The dynamic component lifecycle capture module 130 is used to intercept registration / deregistration / Filter modification APIs and record component status and real-time Filter rules. The static and dynamic bidirectional fusion engine 140 is used to statically guide the dynamic tracking range and dynamically complete the static graph to generate a full test template. The test case generation and adaptation module 150 is used to generate test cases adapted to hidden / dynamic components based on full templates and obfuscation mapping, and adjust the test cases through closed-loop verification; and The test execution and result collection module 160 is used to send Intent test cases and collect crash logs, coverage data, and component response results.

[0044] The following is a detailed explanation of these modules.

[0045] First, let's explain the static analysis module 110.

[0046] The static analysis module 110 generates an initial intent communication map through static analysis, which includes component class names, IntentFilter rules, known extras keys, and method call relationships. At the same time, it marks sensitive reflection calls in obfuscated code (such as calling Class.forName but the class name is unknown, or the parameter of getStringExtra is a variable) as fuzzy nodes. Based on the fuzzy nodes, the dynamic tracing scope is narrowed to reduce instrumentation overhead. Reflection calls are captured through JVMTI or Frida instrumentation. In addition to capturing core reflection APIs, reflection calls such as Intent.putExtra and IntentFilter.addAction are also captured to ensure coverage of the entire Intent processing flow.

[0047] Next, the reflection call tracing and obfuscation restoration module 120 will be described.

[0048] The reflection call tracing and obfuscation restoration module 120 is based on instrumentation technology. It achieves obfuscation restoration through four steps: "call stack parsing + parameter association + data flow tracing + closed-loop verification," ensuring accuracy. If the APK is debuggable, JVMTI instrumentation is used first to ensure low overhead; otherwise, Frida is enabled.

[0049] (1) Optimization of stake configuration and tracking range Static-guided dynamic: The static analysis module 110 outputs a "list of potential reflection points" (such as methods that call Class.getDeclaredMethod, Intent-related methods in obfuscated classes), and only methods in this list are instrumented to reduce instrumentation overhead.

[0050] Interception target expansion: In addition to the core reflection API, reflection calls to Intent.putExtra and IntentFilter.addAction have been added to ensure coverage of the entire Intent processing flow.

[0051] (2) Obfuscation and Restoration Process Call stack analysis: When a reflection call is intercepted (such as `Method.invoke` calling `getStringExtra`), the call stack is obtained, and the caller's class name and method name are extracted (even if obfuscated) to determine the component to which the hidden handler belongs. For example, if the call stack is `com.social.app.b.onStartCommand()→java.lang.reflect.Method.invoke()→android.content.Intent.getStringExtra()`, the hidden handler is determined to be `com.social.app.b`.

[0052] 1) Parameter type and context association Extract the parameter (obfuscated key "m") from getStringExtra, combine it with the parameter type (Intent type) of onStartCommand, and mark "m" as the Intent extras key of this component; Trace the reflection calls of putExtra within the same component (e.g., the value corresponding to the parameter "m" is a string type) to determine that the type of "m" is String.

[0053] 2) Cross-method data flow tracing: By intercepting method return values, trace the propagation path of obfuscated keys (such as "m" from com.social.app.b being passed to the process method of com.social.app.util.c), verify the consistency of obfuscated keys, and eliminate interference from temporary variables.

[0054] 3) Closed-loop verification: Generate a test case containing the obfuscation key "m" and send it to com.social.app.b. Monitor whether the expected code path is triggered. If not, adjust the restoration strategy and consider other possible obfuscation keys.

[0055] (3) Examples of semantic roles In the reflection call tracing and obfuscation restoration module 120, the semantic role example is used to guide how to infer the possible semantic roles of different Intent parameter types and contexts, and to design corresponding test strategies.

[0056] The following are specific examples of semantic roles, along with the basis for their inferences, test examples, and test strategies: 1. message_id (message ID) Basis for speculation: The component is a Service (determined by calling onStartCommand); The value of Extras is passed to the function whose method name contains process / handle / dispatch; Verify that the function was executed by checking the coverage.

[0057] Test example: Valid ID format: "msg_12345"; UUID: "550e8400-e29b-41d4-a716-446655440000"; Extremely long string: "m" * 500; Null value: ""; Special characters: "'; DROP TABLE messages--"; Number overflow: "999999999999999999999999999999"

[0058] Testing strategy: Prioritize simulating real message ID injection tests to detect SQL / command injection; Use null and excessively long values ​​to test robustness.

[0059] 2. command Basis for speculation: The component is a Service; The target method name contains execute / run / doAction; Different input values ​​trigger different code branches (verified through multiple sets of coverage).

[0060] Test example: Known commands: "REFRESH", "SYNC", "LOGOUT"; Unknown commands: "DEBUG_MODE", "ENABLE_ROOT", "HIDDEN_ACTION"; Case variants: "refresh", "ReFrEsH"; Empty command: ""; Extremely long command: "A" * 200.

[0061] Testing strategy: Command fields are a high-risk area for hidden functions; try common debugging / backdoor keywords. Test case sensitivity, because it is often overlooked.

[0062] 3. Payload Basis for speculation: The target method name is a generic processing function such as process / parse / load; There are no other semantic features to match; the value is passed in as a whole without further breakdown.

[0063] Test example: No load: ""; JSON payload: '{"id":1,"content":"test"}'; Invalid JSON payload: "{ invalid json}"; Base64 garbled characters: "aGVsbG8gd29ybGQh" (valid) + "!!!invalid!!!" (invalid); XML / HTML injection: <script>alert(1)< / script> ".

[0064] Testing strategy: Even if it is not explicitly JSON, you should try to use structured input; Invalid formats can trigger abnormal paths (crashes / log leaks).

[0065] 4. user_token Basis for speculation: Package names containing bank / pay / auth / social; The target method name contains verify / check / auth / validate; The coverage results show that this method is sensitive to input.

[0066] Test example: Placeholder token: "valid_token_for_testing"; Empty token: ""; Invalid token: "invalid_token_123"; Extra Long Token: "t" * 1000; JWT forged stub: "eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.xx".

[0067] Testing strategy: Empty / invalid tokens often lead to logical branches (such as redirection to login); A JWT stub can trigger parsing logic (even if the signature is not verified).

[0068] 5. event_name (event name) Basis for speculation: The component is BroadcastReceiver (determined by onReceive); The target method name contains track / log / report / event.

[0069] Input values ​​are used for data tracking or statistics.

[0070] Test example: Common events: "app_start", "click_banner", "login_success"; Sensitive events: "payment_complete", "view_private_msg"; Illegal event: "", ".. / .. / .. / .. / etc / passwd"; Extra-long event name: "e" * 300.

[0071] Testing strategy: The event name may affect the content of the data report; Path traversal attempts are used to detect log writing vulnerabilities.

[0072] Next, the dynamic component full lifecycle capture module 130 will be described.

[0073] The dynamic component full lifecycle capture module 130 fully covers the registration, modification, and deregistration process of dynamic components, ensuring that the captured information is effective in real time.

[0074] (1) Target interception throughout the entire lifecycle Intercept the following key functions: Registration: Context.registerReceiver, Context.registerReceiverAsUser; Unregister: Context.unregisterReceiver; Filter modification: IntentFilter.addAction, IntentFilter.addDataScheme, IntentFilter.removeAction; Component status: The activity level of a component is determined by the frequency of calls to the onReceive method of BroadcastReceiver.

[0075] (2) Core Logic 1) Registration interception: Extract the BroadcastReceiver instance and IntentFilter parameters, parse the initial rules, and record the registration time and the context of the component to which it belongs.

[0076] 2) Filter modification interception: Intercept the modification method of IntentFilter and update the corresponding Filter rules of the component in real time (such as adding a new action after addAction).

[0077] 3) Unregister interception: Mark the component as "unregistered" and no longer generate test cases for the component to avoid invalid tests.

[0078] Next, the static and dynamic bidirectional fusion engine 140 will be explained.

[0079] The static-dynamic bidirectional fusion engine 140 achieves bidirectional interaction of "static guiding dynamic and dynamic completing static", generating high-precision full-scale test templates.

[0080] (1) Static guidance for dynamic: Static analysis generates an "explicit Intent processing logic graph", which includes component class names, IntentFilter rules, known extras keys, and method call relationships; Mark "fuzzy nodes" in the graph (such as calling Class.forName but the class name is unknown, or gettingStringExtra with a variable as the parameter), and only perform key instrumentation on these fuzzy nodes to reduce the overhead of irrelevant instrumentation.

[0081] (2) Dynamic completion of static: The dynamically captured reflection call results are used to complete the information of the fuzzy nodes (such as the actual class name of Class.forName and the obfuscation key corresponding to the variable). Dynamically registered components are added to the static component list to improve the Intent processing logic graph; The obfuscation mapping for dynamic verification corrects erroneous assumptions in static analysis (such as misjudged extras key types).

[0082] (3) Data validation and deduplication: Verification rules: The component class name must exist in the class list of the APK, the IntentFilter rules must conform to the Android specification, and the obfuscation mapping must pass closed-loop verification; Deduplication algorithm: Based on "component class name + IntentFilter signature (action + dataScheme hash value)" to avoid duplicate inclusion of different registered instances of the same component.

[0083] (4) Full test template The following is an example of a full test template.

[0084] { "component_list": [ { "type": "HIDDEN_SERVICE", "class_name": "com.social.app.b", "status": "ACTIVE", / / Registration status: ACTIVE / UNREGISTERED "intent_filter": { "actions": ["com.social.app.HIDDEN_ACTION","com.social.app.NEW_ACTION"], / / Includes dynamically added actions "categories": [], "data_schemes": ["content"], "filter_modify_log": [ / / Filter modification log] {"type": "add", "field": "action", "value":"com.social.app.NEW_ACTION", "time": 1690000100} ] }, "extras_info": { "known_keys": {"m": "String", "n": "Int"}, "obfuscation_mapping": { "m": "message_id", "n": "message_type"}, "mapping_verified": true, / / Obfuscation mapping verified "data_flow": { / / Cross-method data flow tracing results "m": ["com.social.app.b.onStartCommand","com.social.app.util.c.process"] } }, "sensitive_api association": ["android.location.Location.getLatitude"] / / Associate sensitive APIs to increase their priority. } ], "static_dynamic_mapping": { / / Static-dynamic association "static_node": "com.social.app.MainActivity.processIntent", "dynamic_captured": "com.social.app.b", "relation": "reflection invocation" } }

[0085] Next, the contents of the full test template for this example will be explained in detail.

[0086] 1. Component List Type: Hidden Service (HIDDEN_SERVICE) Class name: com.social.app.b; Status: ACTIVE (Registered).

[0087] Intent_filter (Intent filter configuration): Actions include: Static declaration: com.social.app.HIDDEN_ACTION Dynamically added: com.social.app.NEW_ACTION (added time: 1690000100) Categories: Empty; Data schemes (data_Schemes): content; Filter modification log: Records operations that dynamically add NEW_ACTION, used to track configuration change history.

[0088] The Extra parameter information includes: Known_keys (known keys and types): m: String type (obfuscation key); n: Int type (obfuscation key); Obfuscated mapping (verified): m: message_id; n: message_type.

[0089] Data stream tracing includes: The path of m: onStartCommand → util.c.process (verify that the parameters are processed correctly).

[0090] Sensitive API associations include: The link to android.location.Location.getLatitude indicates that this component may involve location information processing and should be tested first.

[0091] 2. Static-Dynamic Mapping Static node: com.social.app.MainActivity.processIntent; Dynamically capture target: com.social.app.b; Relationship type: Reflection invocation.

[0092] Therefore, through such a full-scale test template, systematic security testing and verification of hidden service components (HIDDEN_SERVICE) in Android applications can be performed. Its function is to guide testers or automated tools to perform static analysis, dynamic testing, data flow verification and security auditing through structured data description (JSON format) in order to discover potential security vulnerabilities or abnormal behaviors.

[0093] Next, the test case generation and adaptation module 150 will be explained.

[0094] The test case generation and adaptation module 150 generates test cases adapted to hidden / dynamic components based on full templates and obfuscation mapping, and optimizes them through closed-loop verification.

[0095] (1) Use case generation rules 1) For static components: Generate test cases directly based on explicit IntentFilter rules, with the extras key using known fields; 2) For hidden components: Replace the original fields in the test case with obfuscation keys (e.g., “message_id” → “m”) to ensure that the hidden processor is matched; 3) For dynamic components: Generate test cases based on real-time filter rules. If the component is associated with sensitive APIs, add abnormal parameters (such as excessively long strings or boundary values) to test for vulnerabilities.

[0096] (2) Test case adaptation and verification process 1) Generate initial test cases: Generate test cases based on intent_filter and extras_info in the template; 2) Sending test case: Send an Intent via ADB to trigger component processing; 3) Verify the results: Check the coverage data (whether the associated method was triggered) and the application logs (whether there was the expected response); 4) Adjust the test case: If it is not triggered, adjust the obfuscation key (such as trying other possible obfuscation mappings), supplement the missing extras field, and resend the verification.

[0097] Based on the above explanation, the core test points and exception handling mechanisms will be explained next.

[0098] First, core test points include, for example: IntentFilter rules: Are they too lenient? Do they restrict the data scheme and host? Have they added the necessary categories? Intent data validation: Whether the component performs validity checks on extras and data; Component permission configuration: Whether the component receiving the Intent has access permissions set, and whether only trusted applications are allowed to send Intents; Hidden Intent communication: Are there dynamically registered components or hidden actions? Are there any security vulnerabilities in these hidden entry points? Obfuscated component Intent parsing: Does the obfuscated component have vulnerabilities in its Intent data parsing logic (e.g., no validation is performed when calling getStringExtra via reflection)?

[0099] Secondly, exception handling mechanisms include, for example: Reflection call exception: Intercept InvocationTargetException, log the exception information, do not affect the obfuscation restoration process, only mark the reflection call as "invalid"; Dynamic component duplicate registration: Distinguish between registration timestamp and instance hash value to avoid duplicate inclusion in testing; Filter parsing failed: When the IntentFilter parameter is null or has an abnormal format, the registration record is skipped and logged for later analysis.

[0100] Next, let's illustrate this with an example.

[0101] (1) Case details A certain social app (package name com.social.app) employs the following hidden techniques, causing traditional testing tools to miss it: 1) Hide the Intent handler: Target component: Message push processing Service, whose class name is obfuscated by ProGuard as com.social.app.b; Reflection logic: In onStartCommand, intent.getStringExtra("m") is called via reflection, where "m" corresponds to the original key "message_id"; Data flow: The value of "m" is passed to the com.social.app.util.c.process method to retrieve push content.

[0102] 2) Dynamic registration component: After the application starts, it registers a com.social.app.DynamicPushReceiver via registerReceiver to receive com.social.app.PUSH actions; Actions are dynamically added during runtime using intentFilter.addAction("com.social.app.PUSH_V2"); When exiting the application, call unregisterReceiver to unregister the component.

[0103] (2) Execution steps 1) Static analysis stage: Manifest analysis: com.social.app.b and DynamicPushReceiver (dynamic registration) were not found; only static components (such as MainActivity) were retrieved. Decompile the APK: Generate an explicit Intent processing logic graph, mark com.social.app.b's onStartCommand as an "fuzzy node" (calling Method.invoke), and list the parameter of getStringExtra as the variable "key" as a key instrumentation target.

[0104] 2) Dynamic tracking stage: After the application starts, only fuzzy nodes such as com.social.app.b.onStartCommand are instrumented; Intercept the registerReceiver call: extract the DynamicPushReceiver instance and the initial IntentFilter (action: com.social.app.PUSH); Intercepting the IntentFilter.addAction call: capturing the newly added action com.social.app.PUSH_V2 and updating the Filter rules of DynamicPushReceiver in real time; The reflection call in com.social.app.b.onStartCommand was intercepted: Method.invoke calls getStringExtra("m"). Parsing the call stack determined that the component was com.social.app.b. Tracing the data flow revealed that "m" was passed to com.social.app.util.c.process. Generate test cases: action: com.social.app.HIDDEN_ACTION, extras: {"m": "test123"}. After sending, the coverage verification is passed, confirming that the process method is triggered. The obfuscation mapping "m→message_id" is verified to be successful.

[0105] 3) Data fusion stage: Static-Dynamic Two-Way Integration: Add com.social.app.b (hidden Service) and DynamicPushReceiver (dynamic Receiver) to the component list, and complete the extras information of com.social.app.b and the filter rules of DynamicPushReceiver; Generate full template: contains complete information on both types of components.

[0106] 4) Test execution phase: Test DynamicPushReceiver: Generate test case action: com.social.app.PUSH_V2, data: content: / / test / push, extras: {"push_id": "12345"}, trigger the onReceive method after sending; Test com.social.app.b: Use the verified obfuscated key "m" to generate test cases, and successfully trigger message processing logic; When the application exits: intercept unregisterReceiver, mark DynamicPushReceiver as "unregistered", and stop generating use cases for this component.

[0107] The above describes the intent penetration testing system of the present invention, and the intent penetration testing method of the present invention will be described next.

[0108] Figure 2 This is a schematic diagram of an embodiment of the penetration testing method of the present invention.

[0109] like Figure 2 As shown, an embodiment of the present invention provides an intentional penetration testing method comprising: Static analysis step S100: parse the application and extract its explicit components to obtain static analysis results; Reflection call tracing and obfuscation restoration step S200: Based on instrumentation technology, intercept the application's runtime reflection calls and parse the call stack to locate the hidden processor and output the reflection call obfuscation restoration results; Dynamic component full lifecycle capture step S300: Intercept and track the registration, modification, and deregistration of components in the application, and combine intent filter rules to capture components temporarily registered at runtime to obtain dynamic analysis results; Static-dynamic bidirectional fusion step S400: The static analysis results, the dynamic analysis results, and the reflection call obfuscation and restoration results are fused to generate a full test template; Test case generation and adaptation step S500: Generate test cases based on the full test template and the reflection call obfuscation and restoration results; and Test execution and result collection step S600: Send the test case to the test target and collect the execution results of the test case.

[0110] In the static analysis step S100, the Android manifest file of the application is parsed to extract the statically registered components and intent filter rules, and the application code is decompiled to build an initial logic graph, and potential reflection call obfuscation points in the code are marked.

[0111] The initial logic graph includes one or more of the following: Component class name, intent filter rules, known extras keys, and method call relationships.

[0112] In the reflection call tracing and obfuscation restoration step S200, runtime reflection calls are intercepted based on JVMTI or Frida instrumentation technology, the call stack is parsed to locate the hidden processor, the obfuscated fields and the hidden processor are restored, and the accuracy of the restoration is verified.

[0113] Specifically, in the reflection call tracing and obfuscation restoration step S200, the instrumentation technique is applied only to the reflection call obfuscation points output by the static analysis step.

[0114] In the dynamic component lifecycle capture step S300, the registration, deregistration, and intent filter modification of components in the application are intercepted, the state changes of dynamically registered components are recorded in real time, the latest intent filter rules of each dynamic component are obtained, and deregistered components are marked.

[0115] In the static-dynamic bidirectional fusion step S400, the dynamic instrumentation range is guided based on the static analysis results, irrelevant monitoring overhead is eliminated, and the initial logic graph is completed into the static graph based on the dynamic analysis results.

[0116] In the static-dynamic bidirectional fusion step S400, data verification and deduplication are further performed to ensure that the fused information is authentic, valid, and free of duplication.

[0117] The data verification rules include one or more of the following: The component class name exists in the application's class list; Intent filter rules conform to Android specifications; and The obfuscated mapping is verified through a closed loop.

[0118] The data deduplication includes performing deduplication based on the component class name and the signature of the intent filter.

[0119] Specifically, the test case generation and adaptation steps generate test cases directly based on intent filter rules for static components, replace the original fields in the test cases with obfuscation keys for hidden components to ensure matching of hidden processors, and generate test cases based on real-time filter rules for dynamic components.

[0120] As described above, the intent penetration testing system and method of the present invention generate an initial intent communication map through static analysis, which includes component class names, IntentFilter rules, known extras keys, and method call relationships. At the same time, sensitive reflection calls in obfuscated code are marked (such as calling Class.forName but the class name is unknown, or the parameter of getStringExtra is a variable) as fuzzy nodes. Based on the fuzzy nodes, the dynamic tracing scope is narrowed to reduce instrumentation overhead. Reflection calls are captured through JVMTI or Frida instrumentation. In addition to capturing the core reflection API, reflection calls of Intent.putExtra, IntentFilter.addAction, and other intent-related reflection calls are also captured to ensure coverage of the entire Intent processing flow.

[0121] Furthermore, by tracing back the call stack of the reflection call to the real source component, it can be determined whether it belongs to Intent communication. Then, by tracing the cross-method data flow of the parameter flow, the type of the obfuscated parameter can be restored based on the parameter information associated with the context, thus realizing the dynamic restoration of the reflection and obfuscated code.

[0122] Furthermore, in the intent penetration testing system and method of the present invention, the restored obfuscation logic is not readily trusted. The accuracy of the restored obfuscated field mapping is further verified through "send-feedback". Based on the restored obfuscation logic rules, corresponding legitimate request test cases are generated to monitor whether the expected code path is triggered, thereby verifying the accuracy of the obfuscation restoration and ensuring that the test cases can trigger the hidden processor logic.

[0123] Monitor the entire lifecycle of dynamically registered components to ensure the timeliness of filter rules. By intercepting and tracking relevant APIs throughout the dynamic component lifecycle, such as `registerReceiver` and `unregisterReceiver`, record the component's registration and deregistration status. Simultaneously, parse dynamic modifications to `IntentFilter`s (such as `addAction`) to dynamically update intent rules in real time, ensuring the real-time effectiveness of captured filter rules for constructing more accurate test cases. Dynamically registered components are added to the static component list to complete the Intent processing logic graph. For deregistered components, no further test cases are generated for them to avoid invalid testing.

[0124] By dynamically capturing real reflection parameters (such as the actual class name of `Class.forName` and the obfuscation key corresponding to the variable), dynamic components, and inferred obfuscation maps, the missing information in the static analysis's intent communication map is completed. Simultaneously, misjudged fields in the static analysis are dynamically corrected (such as misjudged `extras` key types), ultimately generating a high-precision full-scale test template. The template, completed through dynamic and static methods, will contain all explicit, implicit, and dynamic component information, as well as each component's IntentFilter rules, `extras` field types, obfuscation maps, and data flow paths.

[0125] The intentional penetration testing system and method according to the present invention can achieve the following technical effects: Achieve identification of hidden Intent handlers: Through a multi-dimensional combination of techniques including call stack parsing, parameter association, data flow tracing, and closed-loop verification, the obfuscated fields and hidden handlers are restored, breaking through the technical bottleneck of static analysis parsing reflection and obfuscation. Achieve full lifecycle coverage of dynamic components: By intercepting and tracking the entire process of registration, modification, and deregistration APIs, and combining real-time parsing of IntentFilter dynamic rules, capture components temporarily registered at runtime and valid communication rules, and avoid ignoring temporary communication entry points; Enhance the robustness of the solution in complex scenarios: Design adaptation logic for complex scenarios such as dynamically modifying IntentFilter and abnormal branches of reflection calls, and with a sound exception handling mechanism, ensure that the test process runs stably under various extreme conditions and avoid data failure or process interruption. Expanding the technical compatibility of the solution: Through dynamic instrumentation and static parsing mechanisms without source code dependencies, it adapts to the application of various hidden technologies such as obfuscation, reflection calls, and dynamic registration, and is as compatible as possible with all versions of the Android system.

[0126] The above are merely specific embodiments of the present invention, but the scope of protection of the present invention is not limited thereto. Those skilled in the art can conceive of other feasible variations or substitutions based on the technical scope disclosed in the present invention, and such variations or substitutions are all covered within the scope of protection of the present invention. In the absence of conflict, the embodiments of the present invention and the features thereof can also be combined with each other. The scope of protection of the present invention is determined by the claims.

Claims

1. An intent penetration testing system, characterized in that, include: The static analysis module is used to parse the application and extract its explicit components to obtain static analysis results. The reflection call tracing and obfuscation restoration module is used to intercept reflection calls during application runtime based on instrumentation technology, parse the call stack to locate hidden processors, and output the reflection call obfuscation restoration results. The dynamic component lifecycle capture module is used to intercept and track the registration, modification, and deregistration of components in the application, and to capture components temporarily registered at runtime in combination with intent filter rules to obtain dynamic analysis results; A static and dynamic bidirectional fusion engine is used to fuse the static analysis results, the dynamic analysis results, and the reflection call obfuscation and restoration results to generate a full test template. The test case generation and adaptation module is used to generate test cases based on the full test template and the reflection call obfuscation and restoration results. as well as The test execution and result collection module is used to send the test cases to the test target and collect the execution results of the test targets executing the test cases.

2. The intent penetration testing system as described in claim 1, characterized in that, The static analysis results include: the initial logic graph and reflection call obfuscation points. The static analysis module parses the application's Android manifest file to extract statically registered components and intent filter rules, decompiles the application code to construct an initial logic graph, and marks potential reflection call obfuscation points in the code.

3. The intent penetration testing system as described in claim 2, characterized in that, The initial logic diagram includes one or more of the following: Component class name, intent filter rules, known extras keys, and method call relationships.

4. The intent penetration testing system as described in claim 2, characterized in that, The reflection call tracing and obfuscation restoration module intercepts runtime reflection calls based on JVMTI or Frida instrumentation technology, parses the call stack to locate hidden handlers, restores obfuscated fields and hidden handlers, and verifies the accuracy of the restoration.

5. The intent penetration testing system as described in claim 4, characterized in that, The reflection call tracing and obfuscation restoration module only applies the instrumentation technique to the reflection call obfuscation points output by the static analysis module.

6. The intent penetration testing system as described in claim 2, characterized in that, The dynamic component lifecycle capture module intercepts the registration, deregistration, and intent filter modification of components in the application, records the state changes of dynamically registered components in real time, obtains the latest intent filter rules for each dynamic component, and marks deregistered components.

7. The intent penetration testing system as described in claim 2, characterized in that, The static-dynamic bidirectional fusion engine guides the dynamic instrumentation range based on the static analysis results, eliminates irrelevant monitoring overhead, and completes the initial logic graph into the static graph based on the dynamic analysis results.

8. The intent penetration testing system as described in claim 7, characterized in that, The static-dynamic bidirectional fusion engine further performs data verification and data deduplication.

9. The intent penetration testing system as described in claim 8, characterized in that, The data verification rules include one or more of the following: the component class name exists in the application's class list; Intent filter rules conform to Android specifications; Obfuscation mapping is verified through closed-loop processing. The data deduplication includes performing deduplication based on the component class name and the signature of the intent filter.

10. The intent penetration testing system as described in claim 2, characterized in that, The test case generation and adaptation module generates test cases directly based on intent filter rules for static components, replaces the original fields in the test cases with obfuscation keys for hidden components to ensure matching of hidden processors, and generates test cases based on real-time filter rules for dynamic components.

11. An intent-based penetration testing method, characterized in that, Includes the following steps: The static analysis step involves parsing the application and extracting its explicit components to obtain the static analysis results. The reflection call tracing and obfuscation restoration steps are based on instrumentation technology to intercept reflection calls during application runtime, parse the call stack to locate hidden processors, and output the reflection call obfuscation restoration results. The entire lifecycle of dynamic components is captured, intercepting and tracking the registration, modification, and deregistration of components in the application, and combining intent filter rules to capture components temporarily registered at runtime to obtain dynamic analysis results; The static and dynamic bidirectional fusion step integrates the static analysis results, the dynamic analysis results, and the reflection call obfuscation and restoration results to generate a full test template. The test case generation and adaptation steps involve generating test cases based on the full test template and the obfuscation and restoration results of the reflection call. as well as The test execution and result collection steps involve sending the test cases to the test target and collecting the execution results of the test cases executed by the test target.

12. The intent penetration testing method as described in claim 11, characterized in that, The static analysis results include: the initial logic graph and reflection call obfuscation points. In the static analysis step, the Android manifest file of the application is parsed to extract statically registered components and intent filter rules, and the application code is decompiled to build an initial logic graph, and potential reflection call obfuscation points in the code are marked.

13. The intent penetration testing method as described in claim 12, characterized in that, The initial logic diagram includes one or more of the following: Component class name, intent filter rules, known extras keys, and method call relationships.

14. The intent penetration testing method as described in claim 12, characterized in that, In the reflection call tracing and obfuscation restoration step, runtime reflection calls are intercepted based on JVMTI or Frida instrumentation technology, the call stack is parsed to locate hidden handlers, obfuscated fields and hidden handlers are restored, and the accuracy of the restoration is verified.

15. The intent penetration testing method as described in claim 14, characterized in that, In the reflection call tracing and obfuscation restoration step, the instrumentation technique is applied only to the reflection call obfuscation points output by the static analysis step.

16. The intent penetration testing method as described in claim 12, characterized in that, In the dynamic component lifecycle capture step, the registration, deregistration, and intent filter modification of components in the application are intercepted, the state changes of dynamically registered components are recorded in real time, the latest intent filter rules of each dynamic component are obtained, and deregistered components are marked.

17. The intent penetration testing method as described in claim 12, characterized in that, In the static-dynamic bidirectional fusion step, the dynamic instrumentation range is guided based on the static analysis results, irrelevant monitoring overhead is eliminated, and the initial logic graph is completed into the static graph based on the dynamic analysis results.

18. The intent penetration testing method as described in claim 17, characterized in that, In the static-dynamic bidirectional fusion step, data verification and deduplication are further performed to ensure that the fused information is authentic, valid, and free of duplication.

19. The intent penetration testing method as described in claim 18, characterized in that, The data verification rules include one or more of the following: the component class name exists in the application's class list; Intent filter rules conform to Android specifications; Obfuscation mapping is verified through closed-loop processing. The data deduplication includes performing deduplication based on the component class name and the signature of the intent filter.

20. The intent penetration testing method as described in claim 12, characterized in that, The test case generation and adaptation steps generate test cases directly based on intent filter rules for static components, replace the original fields in the test cases with obfuscation keys for hidden components to ensure matching of hidden processors, and generate test cases based on real-time filter rules for dynamic components.

21. A computer-readable medium having a computer program stored thereon, characterized in that, When executed by a processor, the computer program implements the intent penetration testing method as described in any one of claims 1 to 10.

22. A computer device, comprising a storage module, a processor, and a computer program stored on the storage module and executable on the processor, characterized in that, When the processor executes the computer program, it implements the intent penetration testing method according to any one of claims 1 to 10.

23. A computer program product, comprising a computer program, characterized in that, When executed by a processor, the computer program implements the intent penetration testing method as described in any one of claims 1 to 10.

Images