SDK (Software Development Kit) privacy calling management and control method and system without symbolic stack traceability during operation

Abstract

The invention discloses an SDK (Software Development Kit) privacy calling management and control method and system without symbolic stack traceability during operation, and the method comprises the steps: in a compiling stage, determining a code segment address interval of each third-party SDK in a final executable file, and generating configuration data after the code segment address interval is associated with a corresponding SDK identifier; in a running stage, in response to a calling event of a preset privacy sensitive API, obtaining a return address in a current calling stack, and calculating to obtain an actual memory address during running in combination with an address space layout randomization offset; matching with each SDK code segment address interval recorded in the configuration data so as to identify the identity of the third-party SDK initiating calling; and executing a management and control operation on calling of the privacy-sensitive API. According to the method, code segment address interval configuration of a third-party SDK (Software Development Kit) is constructed, and a return address in an unsigned stack is restored and matched in combination with an address space layout randomization offset during operation, so that the identity of a privacy-sensitive API calling party is accurately traced in a symbol table stripping environment.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of SDK processing, in particular to an SDK privacy call management method and system for runtime unsigned stack tracing. BACKGROUND

[0002] In the current mobile application ecosystem, third-party software development kits (SDKs) are widely integrated into applications to implement functions such as advertising, statistics, and payment. However, during their execution, they may make unauthorized calls to sensitive privacy interfaces, leading to serious risks of user privacy leakage. Existing runtime monitoring solutions typically rely on the API Hook mechanism provided by the operating system to capture sensitive call events. However, due to the fact that platforms such as iOS generally strip symbol tables in release versions, the call stack obtained at runtime only contains memory addresses that cannot be directly identified, making it impossible to accurately determine the caller's identity - that is, it is impossible to distinguish whether the call is from the application's main program, compliant first-party code, or from a specific third-party SDK. This technical obstacle has made existing solutions adopt a "first-pass, then-report" lag processing mode: when a sensitive API is called, only the unsigned stack is recorded and reported asynchronously to the cloud for offline analysis, and real-time interception cannot be implemented at the critical point of call occurrence. As a result, user privacy data may have been obtained or even transmitted externally by third-party SDKs without authorization, and security protection has become a post-mortem, which cannot achieve real-time runtime protection, and due to the lack of precise identification capabilities, it is difficult to perform effective interception on the client side, and forced interception may harm legitimate businesses, seriously affecting application functionality and user experience. Therefore, there is an urgent need for a technical solution that can accurately trace the caller's identity in an unsigned stack environment and implement millisecond-level management and control accordingly, to break through the passive and lagging bottleneck of existing privacy protection mechanisms. SUMMARY

[0003] In view of the above, the present application provides an SDK privacy call management method and system for runtime unsigned stack tracing, which can accurately trace the caller's identity in an unsigned stack environment. The present application provides the following technical solutions: An SDK privacy call management method for runtime unsigned stack tracing, the method comprising: In the compilation phase of the application program, determine the code segment address interval of each third-party SDK in the final executable file based on the link map file, and associate the address interval with the corresponding SDK identifier to generate configuration data; In the application program running phase, in response to a call event to a preset privacy sensitive API, obtain the return address in the current call stack, and combine the address space layout randomization offset to calculate the actual memory address of the call source at runtime; matching the actual memory address with each SDK code segment address interval recorded in the configuration data to identify the third-party SDK identity initiating the call; performing any one of the control operations of release, interception or simulated response on the call of the privacy-sensitive API according to the identification result and a preset SDK permission policy.

[0004] Optionally, the determining, in the compiling stage of the application program, of the code segment address interval of each third-party SDK in the final executable file based on the link map file comprises: parsing the link map file to obtain the start offset address and size of each function symbol in the target third-party SDK in the executable file; calculating the end offset address of each function symbol according to the start offset address and size, and performing upward alignment on the end offset address according to a preset memory alignment granularity; merging the aligned address intervals of each function symbol according to address continuity to generate a continuous or discontinuous address interval set covering the code segment of the target third-party SDK.

[0005] Optionally, in the running stage of the application program, the calculating of the actual memory address of the call source at runtime comprises: obtaining the function call stack of the current process through a system call, and selecting a target frame after skipping the monitoring layer framework from the call stack as a call source frame; extracting the return address of the call source frame as the static offset of the call in the executable file; obtaining the address space layout randomization offset of the application program main binary image; adding the static offset and the address space layout randomization offset to obtain the actual memory address of the call source at runtime.

[0006] Optionally, the preset SDK permission policy comprises a sensitive API white list configured for each third-party SDK respectively; After identifying the third-party SDK identity initiating the call, if the privacy-sensitive API is not included in the white list corresponding to the SDK, performing an interception operation, the interception operation comprising returning at least one of simulated data, null value or preset default response.

[0007] Optionally, the method further comprises: generating an audit log comprising the following information while performing the control operation: the name of the called privacy-sensitive API, the timestamp of the call, the runtime actual memory address of the call source, the identified third-party SDK identity, the type of the performed control operation and the address sequence of the original call stack; and / or upload the audit log to a remote security analysis platform for behavior trace and compliance verification.

[0008] Optionally, the configuration data is embedded into a final application installation package as a static resource file in an application build, and loaded into memory from a local resource path at application startup.

[0009] The application further discloses an SDK privacy calling management system with runtime unsigned stack trace, which comprises: An address interval calculation module is configured to determine code segment address intervals of each third-party SDK in a final executable file based on a link map file in a compilation stage of an application, and generate configuration data by associating the address intervals with corresponding SDK identifiers; A memory address calculation module is configured to obtain a return address in a current calling stack in response to a calling event of a preset privacy sensitive API in a running stage of the application, and calculate an actual memory address of a calling source at runtime in combination with an address space layout randomization offset; An address interval matching module is configured to match the actual memory address with each SDK code segment address interval recorded in the configuration data, so as to identify an identity of a third-party SDK initiating the calling; A management execution module is configured to perform any one of releasing, intercepting or simulating a response of the calling of the privacy sensitive API according to the identification result and a preset SDK permission policy.

[0010] The application further discloses a computer readable storage medium, wherein the storage medium stores a computer program, and the computer program is executed by a processor to realize the method.

[0011] The application further discloses an electronic device, which comprises a memory, a processor and a computer program stored in the memory and executable on the processor, and the processor realizes the method when executing the program.

[0012] The application further discloses a computer program product, which comprises a computer program, and the computer program realizes the method when being executed by a processor.

[0013] According to the technical scheme of the application, the address interval configuration of the code segment of the third-party SDK is constructed based on the link map file in the compilation phase, and the return address in the unsigned stack is restored and matched in combination with the address space layout randomization offset at runtime, thereby realizing accurate tracing of the identity of the private sensitive API calling party in a symbol table stripping environment; on this basis, the preset SDK permission policy is used to implement real-time control operations such as release, interception or simulated response on the calling behavior, thereby effectively overcoming the lagging defect that the prior art can only'release first and report later' due to the inability to identify the calling source, and converting the privacy protection from passive tracing to millisecond-level active interception, while ensuring the normal operation of compliant business, the real-time defense capability of the iOS application to the private behavior of the third-party SDK and the data compliance level are significantly improved. BRIEF DESCRIPTION OF DRAWINGS

[0014] For the purpose of illustration and not limitation, the present application will now be described in conjunction with embodiments thereof and the accompanying drawings, in which: Figure 1 FIG. 1 is a flow diagram of an SDK private calling control method of runtime unsigned stack tracing in an embodiment of the present application; Figure 2 FIG. 2 is a structural diagram of an SDK private calling control system of runtime unsigned stack tracing in an embodiment of the present application; Figure 3 FIG. 3 is a structural diagram of an electronic device in an embodiment of the present application. DETAILED DESCRIPTION

[0015] In order to enable persons skilled in the art to better understand the present application, the technical solutions in the embodiments of the present application will be described in detail below with reference to the accompanying drawings. Obviously, the described embodiments are only a part of the embodiments of the present application, rather than all the embodiments of the present application. Based on the embodiments in the present application, all other embodiments obtained by persons skilled in the art without creative labor should fall within the scope of protection of the present application.

[0016] It should be noted that the features in the embodiments of the present application and the embodiments can be combined with each other without conflict. The embodiments of the present application will be described in detail below with reference to the accompanying drawings.

[0017] Reference Figure 1 The present embodiment discloses an SDK private calling control method of runtime unsigned stack tracing, which comprises the following steps: S100: In the compilation phase of an application program, the address interval of each third-party SDK in the code segment in the final executable file is determined based on the link map file, and the address interval is associated with the corresponding SDK identifier to generate configuration data.

[0018] Specifically, in the compilation phase of the application, to achieve the precise extraction and configuration generation of the address interval of the third-party SDK code segment, the developer first enables the "Write Link Map File" option in the Xcode build settings, so that the compilation and linking process outputs a complete link map file (LinkMap File). This file records in detail all the object files (Object Files), symbols (Symbols) and their offset addresses and sizes in the file in the final executable binary. Subsequently, through an automated script, such as a Python script, the LinkMap file is parsed, and the object file entries belonging to the target third-party SDK are filtered out. For example, by matching the file path or library name (such as AdSDK.a, AnalyticsSDK.framework, etc.), all Object files associated with a specific SDK are identified. Then, the script further iterates through all function symbols belonging to the __TEXT, __text section (i.e. code segment) in these Object files, extracts the starting offset address StartOffset and its size of each symbol, and calculates the ending offset address EndOffset accordingly. To avoid missing the function tail address due to compiler padding or alignment, the script rounds up the ending address to the nearest integer according to the preset memory alignment granularity (such as 8 bytes or 16 bytes). On this basis, all aligned address intervals under the same SDK are merged according to address continuity to eliminate fragmentation, forming one or more compact, non-overlapping continuous address interval sets, such as [0x00123000, 0x00135000], thereby completely covering the code distribution of the SDK in the final executable file. Finally, the identification of each SDK (such as the SDK name or unique ID) is bound to its corresponding address interval set, written in a structured format (such as plist or JSON) into a configuration file, and embedded as a static resource into the application project, packaged into the final.app installation package along with the build process, providing precise binary basis for the caller identification at runtime.

[0019] S200: In the application running phase, in response to the calling event of the preset privacy-sensitive API, the return address in the current call stack is obtained, and the actual memory address of the calling source at runtime is calculated in combination with the address space layout randomization offset.

[0020] Specifically, in the application running phase, in order to achieve accurate identification of the calling source identity, first, the preset privacy-sensitive API is intercepted by Hook through runtime method replacement or underlying function pointer hijacking, for example, using fishhook or method_setImplementation. When any code path calls these monitored APIs, the execution flow will be redirected to the preset monitoring callback function of the application. In the callback function, the system immediately calls backtrace() or __builtin_return_address() mechanism to obtain the original call stack of the current thread, which is composed of a series of return addresses (i.e. the next instruction address of the calling instruction in memory). Then, the system parses the stack, skips the intermediate frames related to the Hook framework itself and system library, and selects the valid business call frame immediately following it as the target calling source frame. After extracting the return address of the frame, the address is only a static offset relative to the starting position of the application main binary file. To restore its real address in the current process memory space, dyld_get_image_vmaddr_slide(0) is called to obtain the runtime loading offset (slide) generated by the address space layout randomization (ASLR) mechanism, and the offset is added to the aforementioned static offset, thereby calculating the actual memory address of the calling source at runtime. The address is the only basis for subsequent matching with the address interval of the SDK code segment generated at compile time, ensuring that high-precision caller tracing can still be achieved in a non-signature environment.

[0021] S300: Matching the actual memory address with the address interval of each SDK code segment recorded in the configuration data to identify the third-party SDK identity that initiates the call.

[0022] After step S200, in the application running phase, after the actual memory address of the calling source is calculated at runtime, the address is matched with the address interval of each third-party SDK code segment recorded in the configuration data generated at the compilation stage and loaded into the memory to identify the specific SDK identity that initiates the call. Specifically, at the start time, the identification of each third-party SDK stored in the configuration file (such as the plist format) and its corresponding address interval set (for example, [0x10023000, 0x10035000]) are parsed into an efficient memory data structure, such as an interval list or an interval tree sorted by the starting address, to support fast lookup. When the sensitive API is triggered and the runtime address is restored, the management engine traverses the data structure and judges whether the actual memory address meets the condition of "greater than or equal to the starting address of a certain interval and less than or equal to the end address of the interval", that is, whether it falls into the target address interval. Once a match is found, it is determined that the address falls within the code segment range of a certain specific third-party SDK, and the identification of the SDK (such as "AdSDK" or "AnalyticsSDK_v2.1") is identified as the initiator of this call; if none of the intervals are hit after traversing all intervals, it is determined that the call comes from the application main program or other unmonitored legitimate modules. The matching process only involves integer comparison, with extremely low computational overhead, which can be completed within microseconds, ensuring that the application performance is not significantly affected, and providing accurate and reliable identification basis for subsequent permission policy decision based on SDK identity.

[0023] S400: According to the identification result and the preset SDK permission policy, any one of the control operations of releasing, intercepting or simulating the response of the call of the privacy-sensitive API is performed.

[0024] Based on step S300, after the third-party SDK identity that initiates the call is identified, the corresponding control operation is performed on the current privacy-sensitive API call according to the preset SDK permission policy. The permission policy is embedded in the installation package in the form of a structured configuration file (such as plist or JSON) at the application building stage, and is loaded into the memory together with the address interval configuration at runtime. For each known SDK identification (such as "AdSDK" and "AnalyticsSDK"), a white list of allowed sensitive API calls is defined. When the runtime control engine completes the identification of the calling source, it first judges whether the call comes from the main program or other unmonitored modules: If not, the white list corresponding to the SDK is further queried to check whether the currently called API (such as advertisingIdentifier) is included.

[0025] If included, it is considered as a compliant behavior, and the system releases the call, that is, the original API implementation is called and the real result is returned; If not included, it is determined as an unauthorized call, and the interception logic is triggered immediately. The interception operation is not simply blocked, but dynamically selects the response mode according to the strategy configuration. For example, for device identification type API, a NSUUID object with all zeros (such as 00000000-0000-0000-0000-000000000000) is returned as a simulated response; for location or address book type API, an empty array, default coordinates or preset simulation data structure can be returned, thereby effectively preventing real privacy data leakage without interrupting the execution of the application main thread. The entire decision and execution process is completed in the same call stack context as the sensitive API is called, with extremely low delay, ensuring the continuity of the business process and achieving millisecond-level accurate interception of illegal behavior, truly achieving the security goal of "runtime bottom protection".

[0026] S500: While performing the management and control operation, generate an audit log containing the following information: the name of the privacy-sensitive API called, the timestamp of the call, the runtime actual memory address of the call source, the identified third-party SDK identity, the type of management and control operation performed, and the address sequence of the original call stack; and locally store and / or upload the audit log to a remote security analysis platform for behavior tracing and compliance verification.

[0027] Specifically, when the runtime management and control engine completes the call source identity recognition and makes a decision to release, intercept or simulate a response, an audit record is immediately constructed, which contains the following key fields: the complete method signature of the privacy-sensitive API called (such as +[ASIdentifierManager advertisingIdentifier]), the high-precision timestamp when the call occurred (usually represented by Unix millisecond timestamp), the ASLR-recovered runtime actual memory address of the call source, the identified third-party SDK identity, the type of management and control operation performed, and the return address sequence of each frame in the original call stack (for example, [0x10012380, 0x10045670, 0x1a2b3c4d0,...]). After the log entry is serialized in a compact format (such as JSON or Protocol Buffer), it is first written to the local log buffer within the application sandbox, ensuring that it can be persisted even when the network is unavailable; at the same time, the log is encrypted according to the preset strategy and uploaded to the remote security analysis platform through the HTTPS protocol. The platform can perform aggregated analysis, visual display and compliance audit on the log, support developers to trace the complete call chain of any privacy call, verify whether the SDK behavior complies with the privacy policy, and provide verifiable technical evidence to meet the requirements of GDPR, CCPA or the Personal Information Protection Law, thereby achieving the dual goals of security protection and compliance governance.

[0028] In summary, the present embodiment realizes high-precision identification of the identity of the calling party of the privacy-sensitive API in the symbol table-stripped iOS release package by constructing the address interval of the code segment of the third-party SDK based on the LinkMap file at the compilation stage and accurately restoring and matching the return address in the unsigned stack in combination with the ASLR offset at runtime; on this basis, differential control operations such as release, interception or return of simulated data are performed in real time according to the preset SDK permission whitelist, and audit logs containing the API name, calling address, SDK identity, control action and complete stack sequence are generated synchronously, which not only effectively overcomes the lagging defect of the prior art “release first and report later”, realizes millisecond-level active defense to prevent user privacy from being stolen without authentication, but also takes into account business compatibility and compliance traceability capability, while ensuring normal operation of application functions, significantly improves the real-time protection level and data governance capability of the privacy behavior of the third-party SDK.

[0029] Reference Figure 2 The present embodiment further discloses an SDK privacy calling control system for runtime unsigned stack tracing, which comprises an address interval calculation module 21, a memory address calculation module 22, an address interval matching module 23, a control execution module 24 and a log management module 25, which will be described in detail as follows: The address interval calculation module 21 is configured to determine the address interval of the code segment of each third-party SDK in the final executable file based on the link mapping file at the compilation stage of the application program, and generate configuration data after associating the address interval with the corresponding SDK identifier; The memory address calculation module 22 is configured to obtain the return address in the current calling stack in response to the calling event of the preset privacy-sensitive API at the running stage of the application program, and calculate the actual memory address of the calling source at runtime in combination with the address space layout randomization offset; The address interval matching module 23 is configured to match the actual memory address with the address interval of each SDK code segment recorded in the configuration data to identify the identity of the third-party SDK initiating the calling; The control execution module 24 is configured to perform any control operation of release, interception or simulated response on the calling of the privacy-sensitive API according to the identification result and the preset SDK permission policy; The log management module 25 is configured to generate an audit log containing the following information while performing the control operation: the name of the called privacy-sensitive API, the timestamp of the calling, the runtime actual memory address of the calling source, the identified third-party SDK identity, the type of the performed control operation and the address sequence of the original calling stack; and store and / or upload the audit log to a remote security analysis platform locally for behavior tracing and compliance verification.

[0030] Figure 3 A schematic diagram of the physical structure of an electronic device provided in an embodiment of the present invention, such as... Figure 3 As shown, the electronic device 50 includes: a processor 501, a memory 502, and a bus 503; The processor 501 and the memory 502 communicate with each other via the bus 503; the processor 501 is used to call the program instructions in the memory 502 to execute the methods provided in the above-described embodiments.

[0031] This embodiment provides a non-transitory computer-readable storage medium that stores computer instructions that cause a computer to execute the methods provided in the above-described embodiments.

[0032] Those skilled in the art will understand that all or part of the steps of the above-described method implementation can be implemented by hardware related to program instructions. The aforementioned program can be stored in a computer-readable storage medium. When the program is executed, it performs the steps of the above-described method implementation. The aforementioned storage medium includes various storage media capable of storing program code, such as ROM, RAM, magnetic disk, or optical disk.

[0033] The device embodiments described above are merely illustrative. The units described as separate components may or may not be physically separate, and the components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the modules can be selected to achieve the purpose of this embodiment according to actual needs. Those skilled in the art can understand and implement this without any creative effort.

[0034] Through the above description of the embodiments, those skilled in the art can clearly understand that each embodiment can be implemented by means of software plus necessary general-purpose hardware platforms, and of course, it can also be implemented by hardware. Based on this understanding, the above technical solutions, in essence or the part that contributes to the prior art, can be embodied in the form of a software product. This computer software product can be stored in a computer-readable storage medium, such as ROM / RAM, magnetic disk, optical disk, etc., including several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute the methods of each embodiment or some parts of the embodiments.

[0035] The foregoing detailed description has set forth various embodiments of the devices and / or processes via the use of specific terminology. However, embodiments thereof can be practiced with the exact description not being presented in detail. The term "device" should be understood to encompass devices operating in various modes, such as active mode, sleep mode, hibernate mode, and the like. The terms "coupled" and "connected," along with derivatives thereof, can be used. It should be understood that these terms are not intended as synonyms for each other. Rather, particular circuitry that can be said to be coupled to, or connected with, other circuitry can be some of the other circuitry that can communicate in some way, while other circuitry can be some of the other circuitry that can not be in communication with that particular circuitry.

Claims

1. A method for controlling SDK privacy calls through runtime unsigned stack tracing, characterized in that, The method includes: During the application compilation phase, the code segment address range of each third-party SDK in the final executable file is determined based on the linker mapping file, and the address range is associated with the corresponding SDK identifier to generate configuration data; During the application runtime phase, in response to a call event to a preset privacy-sensitive API, the return address in the current call stack is obtained, and combined with the address space layout randomization offset, the actual memory address of the calling source at runtime is calculated. The actual memory address is matched with the address range of each SDK code segment recorded in the configuration data to identify the identity of the third-party SDK that initiated the call; Based on the identified third-party SDK identity and the preset SDK permission policy, control operations are performed on the calls to the privacy-sensitive API.

2. The SDK privacy call control method for runtime unsigned stack tracing according to claim 1, characterized in that, During the application compilation phase, determining the code segment address range of each third-party SDK in the final executable file based on the linker mapping file includes: Parse the linker mapping file to obtain the starting offset address and size of each function symbol in the target third-party SDK within the executable file; The ending offset address of each function symbol is calculated based on the starting offset address and size, and the ending offset address is aligned upwards according to the preset memory alignment granularity. The aligned function symbol address ranges are merged according to address continuity to generate a set of continuous or non-contiguous address ranges that cover the target third-party SDK code segment.

3. The SDK privacy call control method for runtime unsigned stack tracing according to claim 1, characterized in that, During the application runtime phase, the calculation to obtain the actual memory address of the calling source at runtime includes: The function call stack of the current process is obtained through system calls, and the target frame after skipping the monitoring layer frame is selected from the call stack as the call source frame. Extract the return address of the source frame of the call and use it as the static offset of the call in the executable file; Obtain the address space layout randomization offset of the application's main binary image; The static offset is added to the address space layout randomization offset to obtain the actual memory address of the calling source at runtime.

4. The SDK privacy call control method for runtime unsigned stack tracing according to claim 1, characterized in that, The preset SDK permission policy includes a whitelist of sensitive APIs configured separately for each third-party SDK; After identifying the identity of the third-party SDK that initiated the call, if the privacy-sensitive API is not included in the whitelist corresponding to the SDK, an interception operation is performed. The interception operation includes returning at least one of simulated data, null value, or preset default response.

5. The SDK privacy call control method for runtime unsigned stack tracing according to claim 1, characterized in that, The method further includes: While performing the aforementioned control operations, an audit log is generated containing the following information: the name of the privacy-sensitive API that was called, the timestamp of the call, the actual runtime memory address of the call source, the identified third-party SDK identity, the type of control operation performed, and the address sequence of the original call stack. The audit logs will be stored locally and / or uploaded to a remote security analysis platform for behavior tracing and compliance verification.

6. The SDK privacy call control method for runtime unsigned stack tracing according to claim 1, characterized in that, The configuration data is embedded as a static resource file in the final application installation package during application building and loaded into memory from the local resource path when the application starts.

7. A runtime unsigned stack traceability SDK privacy call control system, characterized in that, include: The address range calculation module is used to determine the code segment address range of each third-party SDK in the final executable file based on the link mapping file during the compilation phase of the application, and generate configuration data by associating the address range with the corresponding SDK identifier. The memory address calculation module is used during the application runtime phase to respond to call events of preset privacy-sensitive APIs, obtain the return address in the current call stack, and calculate the actual memory address of the calling source at runtime by combining the address space layout randomization offset. The address range matching module is used to match the actual memory address with the address ranges of each SDK code segment recorded in the configuration data in order to identify the identity of the third-party SDK that initiated the call; The control and execution module is used to perform control and management operations on the calls to the privacy-sensitive APIs based on the identified third-party SDK identity and the preset SDK permission policy.

8. A computer-readable storage medium, characterized in that, The storage medium stores a computer program, which, when executed by a processor, implements the method described in any one of claims 1-6.

9. An electronic device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that, When the processor executes the program, it implements the method of any one of claims 1-6.

10. A computer program product, comprising a computer program, characterized in that, When the computer program is executed by a processor, it implements the method of any one of claims 1-6.

Images