An SDK code construction method and device, computer equipment and storage medium
By dividing SDK data into multiple dependency packages and selecting different strategies based on the build mode, the problem of code leakage and efficiency conflict in multi-team collaborative development is solved, achieving a balance between security and efficiency, and supporting version management and access control.
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- SHENZHEN YANYU TECHNOLOGY CO LTD
- Filing Date
- 2026-03-02
- Publication Date
- 2026-06-09
AI Technical Summary
Existing technologies have problems such as high risk of code leakage, conflict between security and development efficiency, difficulty in version management, and insufficient access control in the process of multi-team collaborative development of large-scale SDKs, making it difficult to balance code security, development efficiency and version management.
By dividing the SDK data into multiple dependency packages, the dependency acquisition strategy and security protection level are dynamically selected according to the build mode. In development mode, the packed dynamic library is acquired, and in release mode, the static library is acquired. The code isolation and protection are achieved through the automated process of the build system.
It effectively reduces the risk of code leakage, improves development efficiency, achieves code isolation between modules, ensures efficient operation of the development environment, supports version traceability and access control, and meets the security needs of different scenarios.
Smart Images
Figure CN122173066A_ABST
Abstract
Description
Technical Field
[0001] This invention relates to the field of computer software technology, and in particular to an SDK code construction method, apparatus, computer device, and storage medium. Background Technology
[0002] In the field of software development, especially in the development of large software development kits (SDKs), modular development is the mainstream approach, while multi-team collaborative development is the core model for ensuring development efficiency and promoting project implementation. Currently, the mainstream solutions for traditional multi-team collaborative development of large SDKs in the industry are mainly divided into four types. Each solution has formed a differentiated implementation path based on different methods of code sharing, library file distribution, and protection. However, all of them have significant technical defects and are difficult to simultaneously address core requirements such as code security, development efficiency, version management, and access control.
[0003] The main traditional models for developing large-scale SDKs through multi-team collaboration are as follows: First, the fully shared source code model: all collaborating teams submit the source code of their respective modules to a unified code repository. Using unified build scripts such as Makefile and CMake, all modules are compiled and linked into the final SDK product. Each team can access the source code of all modules during compilation. Second, the static library distribution model: each team compiles its own modules into static libraries in .lib or .a format and provides header files for other teams to use. The main project ultimately generates a complete SDK by linking all static libraries, but these static libraries are in binary form without any protection measures. Third, the dynamic library distribution model, where each team compiles modules into dynamic libraries in .dll or .so format, and the main project integrates each module through dynamic linking, achieving a certain degree of code isolation. However, this model is usually only used in the final release stage, and the development stage still needs to rely on the source code or unprotected library files. Fourth, the packer protection model, before the final release of the SDK, uses packer tools such as VMProtect and Themida to protect the final product through code virtualization, anti-debugging, integrity verification and other technologies to prevent reverse analysis. However, this type of protection only applies to the final release stage, and intermediate products in the development process still exist in plaintext form.
[0004] The aforementioned existing technical solutions have several prominent shortcomings in scenarios involving multi-team collaborative development of large-scale SDKs, which can be summarized into four main categories: First, the risk of code leakage is extremely high. On the one hand, the code is completely exposed during the development phase. In the case of a completely shared source code model and a static library distribution model, developers need to obtain the source code of other modules or unprotected binary files during the compilation and linking process. This makes it easy for core algorithms to be leaked when collaborating across companies or outsourced teams. Employees leaving the company may take away complete source code of multiple modules, and competitors may also obtain trade secrets by infiltrating the development team. On the other hand, intermediate products lack protection. Even if a packer is used to protect the final product, intermediate products such as unpacked library files and debug versions generated during the development process may still be leaked, and then the core algorithm can be obtained through reverse engineering.
[0005] Secondly, there is a significant conflict between security and development efficiency. If the development environments of each module are completely isolated to protect the code, integration testing will require frequent manual operations, resulting in low efficiency. Interface changes will require complex cross-team coordination, extending the development cycle. Furthermore, dependency version management will be complex and prone to compatibility issues. On the other hand, if dependent modules are protected with a protective shield during the development phase, cross-module debugging and performance analysis will be restricted, leading to slow development environment startup and impacting development efficiency. Additionally, anti-debugging protection will interfere with the use of normal development tools.
[0006] Secondly, version management and traceability are quite difficult. In the process of multi-module collaboration, each module evolves its version independently, which can easily lead to situations such as developers using incompatible combinations of module versions, difficulty in tracing the versions of each module corresponding to the final SDK, and inability to accurately locate the module version that caused the problem when issues occur. In addition, in traditional solutions, operations such as dependency acquisition, version management, and protection with packers often rely on manual execution or complex scripts, which are prone to human error, and the operations of different developers may be inconsistent, lacking a complete automation mechanism.
[0007] Finally, there are significant shortcomings in access control. Existing solutions struggle to achieve fine-grained access control that ensures developers can use the software but cannot access the source code. While static libraries are in binary form, they can be analyzed using reverse engineering tools. Source code repositories typically have all-or-nothing access settings, lacking differentiated access control for different development and release scenarios, and thus failing to accurately match access management needs. Summary of the Invention
[0008] This invention provides an SDK code building method, apparatus, computer device, and storage medium, aiming to improve code development security and efficiency.
[0009] In a first aspect, embodiments of the present invention provide an SDK code construction method, including: Obtain the original SDK data, initialize the original SDK data, and then set access credentials for the initialized original SDK data; wherein, the initialization process includes dividing the original SDK data into multiple dependency packages; The current build mode is detected based on the original SDK data; wherein, the build mode includes development mode and release mode; If the current build mode is development mode, then obtain the corresponding development dependency package based on the access credentials, and set a development link for the development dependency package; If the current build mode is release mode, then obtain the corresponding release dependency package based on the access credentials, and set the release link for the release dependency package; The original SDK data is compiled through the development link or release link to construct the target SDK library file.
[0010] Secondly, embodiments of the present invention provide an SDK code building apparatus, comprising: A data processing unit is used to acquire raw SDK data, initialize the raw SDK data, and then set access credentials for the initialized raw SDK data; wherein, the initialization process includes dividing the raw SDK data into multiple dependency packages; The pattern detection unit is used to detect the current build mode based on the original SDK data; wherein, the build mode includes development mode and release mode; The first acquisition unit is used to acquire the corresponding development dependency package based on the access credentials if the current build mode is development mode, and to set a development link for the development dependency package. The second acquisition unit is used to acquire the corresponding release dependency package based on the access credentials if the current build mode is release mode, and set a release link for the release dependency package. The compilation and build unit is used to compile the original SDK data through the development link or the release link to build the target SDK library file.
[0011] Thirdly, embodiments of the present invention provide a computer device, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the computer program to implement the SDK code construction method as described in the first aspect.
[0012] Fourthly, embodiments of the present invention provide a computer-readable storage medium storing a computer program, which, when executed by a processor, implements the SDK code construction method as described in the first aspect.
[0013] This invention provides an SDK code building method, apparatus, computer device, and storage medium. The method includes: acquiring raw SDK data, initializing the raw SDK data, and then setting access credentials for the initialized raw SDK data; wherein the initialization process includes dividing the raw SDK data into multiple dependency packages; detecting the current build mode based on the raw SDK data; wherein the build mode includes development mode and release mode; if the current build mode is development mode, acquiring the corresponding development dependency package according to the access credentials and setting a development link for the development dependency package; if the current build mode is release mode, acquiring the corresponding release dependency package according to the access credentials and setting a release link for the release dependency package; and compiling the raw SDK data through the development link or release link to build a target SDK library file. This invention significantly reduces the risk of code leakage by treating dependency packages differently under different build modes and by adding protective shells. Furthermore, by differentiating between development and release modes, it avoids the inefficiency caused by excessive isolation of the development environment in pursuit of security. For example, normal cross-module debugging and performance analysis can be performed in development mode, ensuring the efficient operation of the development environment; automated processing in release mode reduces manual operations and improves integration efficiency. Thus, both code development security and development efficiency are improved. Attached Figure Description
[0014] To more clearly illustrate the technical solutions of the embodiments of the present invention, the drawings used in the following description of the embodiments will be briefly introduced. Obviously, the drawings described below are some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.
[0015] Figure 1 A flowchart illustrating an SDK code construction method provided in an embodiment of the present invention; Figure 2 A schematic block diagram of an SDK code building apparatus provided in an embodiment of the present invention; Figure 3 This is an overall architecture diagram of an SDK code construction method provided in an embodiment of the present invention. Detailed Implementation
[0016] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some, not all, of the embodiments of the present invention. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.
[0017] It should be understood that, when used in this specification and the appended claims, the terms "comprising" and "including" indicate the presence of the described features, integrals, steps, operations, elements and / or components, but do not exclude the presence or addition of one or more other features, integrals, steps, operations, elements, components and / or collections thereof.
[0018] It should also be understood that the terminology used in this specification is for the purpose of describing particular embodiments only and is not intended to limit the invention. As used in this specification and the appended claims, the singular forms “a,” “an,” and “the” are intended to include the plural forms unless the context clearly indicates otherwise.
[0019] It should also be further understood that the term "and / or" as used in this specification and the appended claims refers to any combination of one or more of the associated listed items and all possible combinations, and includes such combinations.
[0020] Please see below. Figure 1 The present invention provides an SDK code construction method, which specifically includes steps S101 to S105.
[0021] Step S101: Obtain the original SDK data, initialize the original SDK data, and then set access credentials for the initialized original SDK data; wherein, the initialization process includes dividing the original SDK data into multiple dependency packages; Step S102: Detect the current build mode based on the original SDK data; wherein, the build mode includes development mode and release mode; Step S103: If the current build mode is development mode, obtain the corresponding development dependency package according to the access credential, and set the development link for the development dependency package; Step S104: If the current build mode is release mode, obtain the corresponding release dependency package according to the access credential, and set the release dependency package with a release link. Step S105: Compile the original SDK data through the development link or release link to build the target SDK library file.
[0022] In this embodiment, the original SDK data is first obtained, initialized (divided into multiple dependency packages), and access credentials are set. Then, the current build mode (development mode or release mode) is detected. If it is development mode, the development dependency package is obtained based on the access credentials and the development link is set. If it is release mode, the release dependency package is obtained based on the access credentials and the release link is set. Finally, the original SDK data is compiled through the corresponding link to build the target SDK library file.
[0023] This embodiment significantly reduces the risk of code leakage by handling dependency packages differently under different build modes and using packers for protection. Furthermore, by differentiating between development and release modes, it avoids the inefficiency caused by excessive isolation of the development environment in pursuit of security. For example, normal cross-module debugging and performance analysis can be performed in development mode, ensuring the efficient operation of the development environment; automated processing in release mode reduces manual operations and improves integration efficiency. This achieves the goal of improving both code development security and development efficiency.
[0024] The code security SDK construction method provided in this embodiment is based on the core idea of dynamically selecting different dependency acquisition strategies and security protection levels according to the build mode (development mode / release mode): In development mode, dynamic library dependencies that have been protected by obfuscation and other security measures are obtained from a remote server, ensuring that developers cannot access the source code of other modules; in release mode, unobfuscated static library dependencies are obtained from a controlled local repository, and after unified compilation and linking, high-strength obfuscation protection is applied to the entire SDK. Through this differentiated strategy, code isolation between modules can be achieved during the development phase, and overall security protection can be achieved during the release phase, fundamentally solving the contradiction between security and efficiency in traditional SDK development. Combination Figure 3 In practical applications, the system architecture corresponding to this method can consist of four parts: First, a build script module, which is written based on a cross-platform build system, defines the module composition, dependencies, and compilation options of the SDK, and implements build mode recognition and differentiated configuration logic; Second, a dependency distribution system, which includes a remote dependency server that stores the packed dynamic libraries of each module for developers to access via the network, a local dependency repository deployed on a controlled packaging server that stores the static libraries of each module, and a version management file that records the version number and integrity verification value of each module; Third, an automated build process, which covers three core stages: automatically obtaining dependencies from the corresponding source according to the build mode, calling the compiler to generate SDK library files, and automatically executing code protection for the release version; Fourth, an access control mechanism, which implements differentiated permissions for ordinary developers and the packaging server. Ordinary developers only have remote server access and can only obtain packed dynamic libraries, while the packaging server has local repository access and can obtain static libraries for integration and compilation. In one embodiment, the step of acquiring raw SDK data, initializing the raw SDK data, and then setting access credentials for the initialized raw SDK data includes: The original SDK data is divided into multiple independent sub-modules based on the code's functionality; Each independent submodule is configured with attributes; wherein, the attribute configuration includes declaring the module name, defining the dependencies and linking order between the independent submodules; A version management file should be created for each of the aforementioned independent submodules; A remote dependency server is established based on the version management file, and each independent submodule is stored as a dependency package; Access credentials are set based on the remote dependent server.
[0025] In this embodiment, when initializing the original SDK data, it is first divided into multiple independent sub-modules based on the code functionality. Each sub-module can be developed by a dedicated team to ensure its independence and professional development. Then, attributes are set for each independent sub-module, including explicitly declaring the names of all sub-modules in the main SDK's build script, and defining the dependencies and linking order between them. Next, a version management file (e.g., versions.txt) is created for each independent sub-module, recording its version number and hash checksum in text format. For example, the format could be: Version Number 1 - Hash Value 1, Version Number 2 - Hash Value 2, etc. Finally, a remote dependency server (e.g., an FTP server) is established based on the version management files of each independent sub-module, and each independent sub-module is stored as a dependency package on this server. Access credentials are also assigned to developers based on this remote dependency server, enabling remote management and access control of the independent sub-modules.
[0026] In addition, to further ensure the security of dependency packages, a local dependency repository can be established on the packaging server and file system-level access permissions can be set, allowing only the packaging server to access it. This serves as a supplementary protection for remote dependency servers, ensuring the security of submodule dependency packages during the packaging process and preventing unauthorized access.
[0027] In one embodiment, detecting the current build mode based on the original SDK data includes: Retrieve the hook script from the original SDK data; The hook script is used to perform pattern recognition based on the current pattern parameters to confirm the current build pattern of the original SDK data.
[0028] In this embodiment, the current build mode is detected in the pre-build hook of the build script, and pattern recognition is performed based on the build system's mode parameters (such as Debug / Release flags). This identifies two specific build modes: a development mode for daily development and debugging, and a release mode for building the official release version. Based on these pattern recognition results, the corresponding dependency acquisition strategy can be selected, providing a basis for the smooth progress of the subsequent SDK build.
[0029] In one embodiment, if the current build mode is development mode, then obtaining the corresponding development dependency package based on the access credentials and setting a development link for the development dependency package includes: Read the access credentials of the remote dependent server through the local configuration file; The version information of each independent submodule is obtained based on the access barrier, and the corresponding development dependency package is downloaded based on the version information; The development dependency packages are verified, and the linker is configured after the verification is passed to implement the development linking settings.
[0030] In this embodiment, for the development mode, the access credentials are first read, and the authentication information (such as username and password) of the remote dependency server is read from the local configuration file (such as a hidden file). This configuration file is not included in the version control system. Then, the version information of each independent submodule is obtained. For each submodule dependency, the version management file of that module on the remote server can be accessed via a network request using commands such as curl. The file content is parsed to extract the latest version number, and the existence of a version locking configuration is checked. If it exists, the specified version number is used. Next, the development dependency package is downloaded, and a U-code for the dependency package on the remote server is constructed based on the module name and version number. The RL path (format can be protocol: / / server address / platform type / module name / version number.compressed package) is specified. Before downloading, the local cache directory is checked. If the same version already exists, the download is skipped; otherwise, the download operation is performed. Afterward, the development dependency packages can be verified by calculating the hash value of the downloaded compressed package and comparing it with the hash value in the version management file to ensure that the dependency packages have not been tampered with. After successful verification, the linker is configured, and the path of the downloaded dependency packages (including the packed dynamic library files and header files) is added to the build configuration for use by the compiler and linker. During this stage, the dependency packages are not uncompressed to maintain the integrity of the packed libraries.
[0031] Furthermore, in some embodiments, macros that skip security modules (such as skipping anti-debugging modules) can be defined in the build script for the development mode, debugging symbols can be retained for easy debugging, no optimization or low optimization level can be set, and the target type can be configured as a dynamic library to ensure debugging convenience and development efficiency during the development phase.
[0032] In one embodiment, if the current build mode is a release mode, then obtaining the corresponding release dependency package based on the access credentials and setting a release link for the release dependency package includes: Obtain the target platform corresponding to the release mode, and determine the fixed path of the local dependency repository based on the target platform; The version information of each independent submodule is read according to the fixed path, and the corresponding release dependency package is copied from the local dependency repository according to the version information; The release dependency package is decompressed, and a linker is configured on the decompressed release dependency package to implement the release link settings.
[0033] In this embodiment, for the release mode, the local repository path is first determined. Based on the target platform corresponding to the release mode, the fixed path of the local dependency repository on the packaging server is specified (e.g., C: / pkg / Win / for Windows platform, / Users / publish / pkg / Mac / for macOS platform). Then, the version information of each independent submodule is read. For each submodule dependency, the version management file of that module in the local repository is directly accessed, and the file content is parsed to obtain the latest version number or a specified version number. Next, the release dependency package is copied. From the fixed path of the local repository, the corresponding version of the static library compressed package is copied to the project dependency directory according to the path format "local repository root directory / platform type / module name / version number.compressed package". Then, the release dependency package is decompressed. First, the decompression directory of the old version is cleaned up, and then the compressed package is decompressed to the corresponding module subdirectory under the project dependency directory, and the header files and static library files are extracted. After decompression, the linker is configured. The path of the decompressed dependency library is added to the build configuration, and the static linking options are configured, including static libraries for security protection modules such as anti-debugging modules and all functional modules.
[0034] Furthermore, in some embodiments, macro definitions that skip security modules can be removed from the build script for the release mode, symbol visibility can be hidden, the highest optimization level can be set, symbol stripping can be enabled, and the target type can be configured as an optional dynamic library or static library to ensure the security, stability and lightweight nature of the release version.
[0035] In one embodiment, compiling the original SDK data through the development link or release link to construct the target SDK library file includes: The compiler is invoked to compile the source code of the original SDK data. The development link dynamically links to the shelled dynamic libraries of each independent sub-module; or the release link statically links to the static libraries of each independent sub-module. The target SDK library file is constructed by combining the compiled source code and the linked packed dynamic or static libraries.
[0036] In this embodiment, when building the target SDK library file, the compiler is first invoked to compile the main SDK source code file in the original SDK data. Then, a linking operation is performed according to the previous build configuration. Specifically, in development mode, the packed dynamic libraries of each independent submodule are dynamically linked via the development link; in release mode, the static libraries of each independent submodule are statically linked via the release link. Then, by combining the compiled source code and the successfully linked packed dynamic libraries (development mode) or static libraries (release mode), the target SDK library file is built, ensuring that the target SDK library file meets the usage requirements of the corresponding mode.
[0037] In one embodiment, the SDK code construction method further includes: When the current build mode is release mode, the code virtualization protection tool is invoked to perform packing protection, resulting in protected library files; wherein, the packing protection includes code virtualization, anti-debugging protection, integrity verification, and resource encryption; Replace the original unpacked file with the protected library file, and output it to the distribution directory after the replacement is complete.
[0038] In this embodiment, a security packing process is also applied to the release mode. Specifically, the current build mode is first detected in the post-build hook of the build script. If the current mode is release mode, a code virtualization protection tool (such as VMProtect) is automatically invoked. Then, the packing tool performs a complete packing protection operation according to a preset configuration file. This includes code virtualization (converting the machine code of critical functions into custom virtual machine instructions), anti-debugging protection (inserting anti-debugging detection code to prevent dynamic debugging), integrity verification (adding file integrity verification to prevent modification), and resource encryption (encrypting constant strings and embedded resources). After packing is completed, the generated protected library file replaces the original unpacked file, and the packed SDK library file, header file, resource file, etc., are all output to the release directory. This completes the final processing in the release mode, ensuring that the released SDK library file has sufficient security protection capabilities to prevent the core code from being reverse-engineered and tampered with.
[0039] Furthermore, in some embodiments, the SDK code building method may also include version recording and tracking. Specifically, during the SDK building process, the names of all pulled independent sub-modules and their corresponding version numbers can be recorded synchronously, and an SDK version manifest file can be generated. The format can be JSON or text. The manifest must include the main SDK version number (sdk_version), build timestamp (build_time), current build mode (build_mode), target platform (platform), and the mapping relationship between each sub-module name and its corresponding version number (modules). A specific format example is as follows: { "sdk_version": "major version number", "build_time": "build timestamp", "build_mode": "build mode", "platform": "target platform", "modules": { "Module A": "Version Number", "Module B": "Version Number", ... }} The above version list can be embedded within the SDK or released as a separate file with the SDK to enable traceability of the SDK version and the versions of each submodule, facilitating subsequent problem identification and version management.
[0040] In addition, automatic adaptation is performed for different target platforms such as Windows, macOS, and Linux to ensure compatibility with various platform environments during the build process. Specific differences are addressed in four aspects: First, remote server address differences: Windows platforms access Windows-specific server paths, and macOS platforms access macOS-specific server paths; second, tool selection differences: Windows platforms use PowerShell's Expand-Archive command to unzip dependency packages, while Unix-like platforms (such as macOS and Linux) use the unzip command; third, packer differences: Windows platforms use packers adapted for Windows, such as VMProtect, while macOS platforms use corresponding macOS version protection tools; and fourth, system library and framework differences: linking the corresponding system libraries based on the target platform's characteristics, for example, linking the D3D12 library on Windows platforms and the OpenCL framework on macOS platforms.
[0041] Furthermore, the build script in this embodiment supports version locking configuration, with the configuration rule being "specific module name -> forced version number". When a version locking configuration is detected for a submodule, the locked version number can be used first, rather than the automatically obtained latest version of the module. This mechanism is mainly applied in three scenarios: first, locking a fully tested stable version to ensure the stability of the SDK build; second, in case of version issues, it can quickly revert to a known, working historical version; and third, handling compatibility issues between versions of specific submodules to avoid build failures or functional abnormalities due to version incompatibility.
[0042] A caching optimization mechanism can also be configured to improve SDK build efficiency. This involves reducing repetitive operations and shortening build time through cache reuse. The specific implementation process includes four steps: First, generating a cache key, which generates a unique cache identifier based on the submodule name and version number, such as "module A_1.2.3"; second, cache checking, which checks whether a file with the corresponding cache key exists in the local cache directory before performing dependency package download or copy operations; third, cache reuse, which uses the cache file directly if the cache hits (i.e., the corresponding cache file exists), skipping the network download or local file copy steps; and fourth, cache updating, which automatically invalidates the corresponding cache when the submodule version is upgraded, and the system downloads the new version of the module and updates the local cache to ensure that the cache file is consistent with the latest version.
[0043] In summary, the SDK code construction method provided in this embodiment has several key technical points, and these key points work together to balance security, development efficiency, and operability. Specifically, this embodiment employs a dual-mode differentiated build strategy, selecting different dependency forms and sources based on the different needs of development and release modes. In development mode, it obtains the packed dynamic library from a remote server, while in release mode, it obtains the static library from a local repository. This innovatively separates the security requirements of the development and release phases, achieving a balance between security and development efficiency. Relying on automated dependency management based on the build system, and utilizing the build system's before_build and after_build hook mechanisms, dependencies are automatically obtained before compilation, and packing is automatically completed after compilation. Dependency acquisition, version management, and security packing are integrated into the build process. Developers only need to execute standard build commands, eliminating the need for manual operation and effectively reducing the probability of errors. A dual-channel mechanism of network distribution and local repository is implemented. On one hand, packed dynamic libraries are distributed via remote servers such as FTP, providing services to ordinary developers. On the other hand, static libraries are stored in a local file system repository, accessible only to the packaging server. This combination of physical and network isolation achieves differentiated access control for different roles, preventing ordinary developers from obtaining static libraries. A multi-level packing protection system is established. The first level implements submodule-level packing to ensure that the dependencies obtained by developers have basic protection. The second level... The SDK is completely obfuscated to provide strong protection for released versions, forming a multi-layered code protection from sub-modules to the entire SDK. Even if dependency library leaks occur during development, it can prevent core code from being reverse-engineered, further improving the security of the final product. It employs a version management file and automatic acquisition mechanism, using a text-formatted versions.txt file to automatically obtain the latest version information through network requests or local reading. It also supports version locking configuration, eliminating the need for complex dependency management tools; automated version management can be achieved through simple text files and network requests, making it easy to deploy and maintain. It features a platform adaptive mechanism, automatically matching the corresponding server address, decompression tool, obfuscation tool, and system libraries based on the target platform. A unified build script supports multi-platform development, eliminating the need for developers to worry about platform differences and ensuring consistent security protection levels across all platforms. It enables dynamic switching of security configurations during the build process. Within the same build script, development mode and release mode use different compilation options and macro definitions. Development mode skips anti-debugging and other security modules, retains debugging symbols, and does not perform optimizations, facilitating daily development and debugging. Release mode includes security modules, hides symbols, enables maximum optimization, and strips symbols, ensuring the security and lightweight nature of the released version.
[0044] Furthermore, the SDK code building method provided in this embodiment can achieve significant effects in multiple dimensions, covering six major aspects: security, development efficiency, version management, team collaboration, commercial application, and maintainability. Specifically: In terms of security, firstly, it effectively prevents code leakage during development. Ordinary developers can only obtain other module dynamic libraries that have been protected by the packer. Even with reverse engineering tools, it is difficult to obtain the core algorithm source code. Experiments show that the reverse engineering cost of the packed code increases by more than 80%, effectively protecting trade secrets. Secondly, it constructs a multi-layered security protection system throughout the entire process, from dependency distribution and development integration to final release, forming a complete protection system. Even if a leak occurs at any stage, only the protected intermediate product can be obtained, and the complete source code or unprotected library files cannot be obtained. Thirdly, it ensures high-strength protection for the final product. The released SDK undergoes overall packing and integrates multiple protection technologies such as code virtualization, anti-debugging, and integrity verification, achieving a security level comparable to commercial applications and meeting the high security requirements of scenarios such as finance and government.
[0045] In terms of development efficiency, it can maintain the normal development process for developers without any additional learning costs. Simply execute the standard build command (such as "xmake build" or "make") and the system can automatically complete the dependency acquisition and configuration. The local caching mechanism optimizes the build speed. Test data shows that the build speed is improved by more than 60% for the second and subsequent builds. At the same time, dependency acquisition, version management, packing and other operations are all automated, avoiding version errors, configuration omissions and other problems caused by manual operation, and reducing the build failure rate by about 40%.
[0046] In terms of version management, it has precise version traceability capabilities. Each SDK version has a complete list of module versions, and when a problem occurs, it can accurately locate the specific version of the specific module, which greatly improves the efficiency of problem investigation. It also supports flexible version control. Through the version locking mechanism, it can force the use of a specific version for a specific module, reducing the average time to resolve version compatibility issues by 70%.
[0047] In terms of team collaboration, it achieves true code isolation between different teams, supports outsourced teams and cross-company collaboration scenarios, and reduces collaboration risks. After implementing this solution in a project, it successfully collaborated with three outsourced teams to complete SDK development without any code leakage incidents. At the same time, there is no need to formulate complex code access permission management rules. Access control is automatically implemented through technical means, reducing management costs by more than 50%.
[0048] In commercial applications, it can effectively protect core competitiveness and is suitable for SDK products that require protection of core algorithms, such as multimedia processing, game engines, security encryption, and industrial control, preventing competitors from stealing technological achievements through reverse analysis. It can also meet compliance requirements and comply with the code security requirements of regulations such as HIPAA and PCI DSS in regulated industries such as finance and healthcare, thereby reducing compliance risks.
[0049] In terms of maintainability, it has a unified cross-platform solution, with a single build script supporting multiple platforms such as Windows, macOS, and Linux, reducing maintenance costs and ensuring consistent security across platforms; at the same time, it is easy to extend, and when adding a submodule, you only need to add the module name to the dependency list to automatically include it in the secure build process.
[0050] Figure 2 This is a schematic block diagram of an SDK code building apparatus 200 provided in an embodiment of the present invention. The apparatus 200 includes: The data processing unit 201 is used to acquire raw SDK data, perform initialization processing on the raw SDK data, and then set access credentials for the initialized raw SDK data; wherein, the initialization processing includes dividing the raw SDK data into multiple dependency packages; The pattern detection unit 202 is used to detect the current build mode based on the original SDK data; wherein, the build mode includes development mode and release mode; The first acquisition unit 203 is used to acquire the corresponding development dependency package according to the access credential and set a development link for the development dependency package if the current build mode is development mode. The second acquisition unit 204 is used to acquire the corresponding release dependency package according to the access credential and set a release link for the release dependency package if the current build mode is release mode. The compilation and build unit 205 is used to compile the original SDK data through the development link or the release link to build the target SDK library file.
[0051] In one embodiment, the data processing unit 201 includes: A module partitioning unit is used to divide the original SDK data into multiple independent sub-modules based on code functionality; The attribute setting unit is used to set attributes for each of the independent sub-modules; wherein, the attribute setting includes declaring the module name, defining the dependencies and linking order between the independent sub-modules; The version creation unit is used to create version management files for each of the aforementioned independent sub-modules; The dependency establishment unit is used to establish a remote dependency server based on the version management file and store each independent submodule as a dependency package; The access setting unit is used to set access credentials based on the remote dependent server.
[0052] In one embodiment, the pattern detection unit 202 includes: The script acquisition unit is used to acquire hook scripts from the original SDK data; The pattern recognition unit is used to perform pattern recognition on the hook script based on the current pattern parameters in order to confirm the current build mode of the original SDK data.
[0053] In one embodiment, the first acquisition unit 203 includes: The credential reading unit is used to read the access credentials of the remote dependent server through a local configuration file; The dependency download unit is used to obtain the version information of each independent submodule according to the access barrier, and download the corresponding development dependency package according to the version information; The dependency verification unit is used to verify the development dependency packages and configure the linker after the verification is passed to realize the development linking settings.
[0054] In one embodiment, the second acquisition unit 204 is configured to include: The path determination unit is used to obtain the target platform corresponding to the release mode and determine the fixed path of the local dependency repository based on the target platform. The dependency copying unit is used to read version information for each independent submodule according to the fixed path, and copy the corresponding release dependency package from the local dependency repository according to the version information. The decompression configuration unit is used to decompress the publishing dependency package and configure the linker for the decompressed publishing dependency package to realize the publishing link settings.
[0055] In one embodiment, the compilation and build unit 205 includes: The code compilation unit is used to call the compiler to compile the source code of the original SDK data; The linking unit is used to dynamically link the packed dynamic libraries of each independent sub-module through the development link; or to statically link the static libraries of each independent sub-module through the publishing link. The library file building unit is used to combine the compiled source code and the linked packed dynamic or static library to build the target SDK library file.
[0056] In one embodiment, the SDK code building apparatus further includes: The packing protection unit is used to call the code virtualization protection tool to perform packing protection when the current build mode is release mode, so as to obtain the protected library file; wherein, the packing protection includes code virtualization, anti-debugging protection, integrity verification and resource encryption; The replacement output unit is used to replace the original unpacked file with the protected library file and output it to the release directory after the replacement is completed.
[0057] Since the embodiments of the apparatus and the embodiments of the method correspond to each other, please refer to the description of the embodiments of the method for the embodiments of the apparatus, which will not be repeated here.
[0058] This invention also provides a computer-readable storage medium storing a computer program thereon, which, when executed, can perform the steps provided in the above embodiments. The storage medium may include various media capable of storing program code, such as a USB flash drive, a portable hard drive, a read-only memory (ROM), a random access memory (RAM), a magnetic disk, or an optical disk.
[0059] This invention also provides a computer device, which may include a memory and a processor. The memory stores a computer program, and when the processor calls the computer program in the memory, it can implement the steps provided in the above embodiments. Of course, the computer device may also include various network interfaces, power supplies, and other components.
[0060] The various embodiments in this specification are described in a progressive manner, with each embodiment focusing on its differences from other embodiments. Similar or identical parts between embodiments can be referred to interchangeably. For the systems disclosed in the embodiments, since they correspond to the methods disclosed in the embodiments, the descriptions are relatively simple; relevant parts can be referred to in the method section. It should be noted that those skilled in the art can make various improvements and modifications to this application without departing from the principles of this application, and these improvements and modifications also fall within the protection scope of the claims of this application.
[0061] It should also be noted that, in this specification, relational terms such as "first" and "second" are used only to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitations, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes said element.
Claims
1. An SDK code construction method, characterized in that, include: Obtain the original SDK data, initialize the original SDK data, and then set access credentials for the initialized original SDK data; wherein, the initialization process includes dividing the original SDK data into multiple dependency packages; The current build mode is detected based on the original SDK data; wherein, the build mode includes development mode and release mode; If the current build mode is development mode, then obtain the corresponding development dependency package based on the access credentials, and set a development link for the development dependency package; If the current build mode is release mode, then obtain the corresponding release dependency package based on the access credentials, and set the release link for the release dependency package; The original SDK data is compiled through the development link or release link to construct the target SDK library file.
2. The SDK code construction method according to claim 1, characterized in that, The process of acquiring raw SDK data, initializing the raw SDK data, and then setting access credentials for the initialized raw SDK data includes: The original SDK data is divided into multiple independent sub-modules based on the code's functionality; Each independent submodule is configured with attributes; wherein, the attribute configuration includes declaring the module name, defining the dependencies and linking order between the independent submodules; A version management file should be created for each of the aforementioned independent submodules; A remote dependency server is established based on the version management file, and each independent submodule is stored as a dependency package; Access credentials are set based on the remote dependent server.
3. The SDK code construction method according to claim 1, characterized in that, The detection of the current build mode based on the original SDK data includes: Retrieve the hook script from the original SDK data; The hook script is used to perform pattern recognition based on the current pattern parameters to confirm the current build pattern of the original SDK data.
4. The SDK code construction method according to claim 2, characterized in that, If the current build mode is development mode, then the corresponding development dependency package is obtained based on the access credentials, and a development link is set for the development dependency package, including: Read the access credentials of the remote dependent server through the local configuration file; The version information of each independent submodule is obtained based on the access barrier, and the corresponding development dependency package is downloaded based on the version information; The development dependency packages are verified, and the linker is configured after the verification is passed to implement the development linking settings.
5. The SDK code construction method according to claim 2, characterized in that, If the current build mode is a release mode, then the corresponding release dependency package is obtained based on the access credentials, and a release link is set for the release dependency package, including: Obtain the target platform corresponding to the release mode, and determine the fixed path of the local dependency repository based on the target platform; The version information of each independent submodule is read according to the fixed path, and the corresponding release dependency package is copied from the local dependency repository according to the version information; The release dependency package is decompressed, and a linker is configured on the decompressed release dependency package to implement the release link settings.
6. The SDK code construction method according to claim 1, characterized in that, The process of compiling the original SDK data through the development link or release link to construct the target SDK library file includes: The compiler is invoked to compile the source code of the original SDK data. The development link dynamically links to the shelled dynamic libraries of each independent sub-module; or the release link statically links to the static libraries of each independent sub-module. The target SDK library file is constructed by combining the compiled source code and the linked packed dynamic or static libraries.
7. The SDK code construction method according to claim 1, characterized in that, Also includes: When the current build mode is release mode, the code virtualization protection tool is invoked to perform packing protection, resulting in protected library files; wherein, the packing protection includes code virtualization, anti-debugging protection, integrity verification, and resource encryption; Replace the original unpacked file with the protected library file, and output it to the distribution directory after the replacement is complete.
8. An SDK code building apparatus, characterized in that, include: A data processing unit is used to acquire raw SDK data, initialize the raw SDK data, and then set access credentials for the initialized raw SDK data; wherein, the initialization process includes dividing the raw SDK data into multiple dependency packages; The pattern detection unit is used to detect the current build mode based on the original SDK data; wherein, the build mode includes development mode and release mode; The first acquisition unit is used to acquire the corresponding development dependency package based on the access credentials if the current build mode is development mode, and to set a development link for the development dependency package. The second acquisition unit is used to acquire the corresponding release dependency package based on the access credentials if the current build mode is release mode, and set a release link for the release dependency package. The compilation and build unit is used to compile the original SDK data through the development link or the release link to build the target SDK library file.
9. A computer device, characterized in that, It includes a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the computer program to implement the SDK code construction method as described in any one of claims 1 to 7.
10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program that, when executed by a processor, implements the SDK code construction method as described in any one of claims 1 to 7.