A source code processing method, device and equipment

Abstract

The application discloses a source code processing method, device and equipment. The method comprises the following steps: performing obfuscation processing on a source code copy to obtain obfuscated code; determining a path where the obfuscated code is located as a target path; determining a target environment variable used for construction in an operating system environment variable set, and setting the target environment variable, so that the target environment variable indicates the target path and does not indicate a path where original source code corresponding to the source code copy is located; and performing construction according to the target environment variable to generate a compiled file or an executable file corresponding to the obfuscated code.

Description

Technical Field

[0001] This specification relates to the field of source code security technology, and in particular to a source code processing method, apparatus, and device. Background Technology

[0002] With the widespread adoption of smart terminal devices, more and more devices need to deploy sensitive business logic such as payment SDKs, identity authentication, and key derivation. Some of these devices, such as wearable devices like smart glasses, operate in open hardware environments, where firmware can be disassembled and read. Attackers can use reverse engineering to extract binary files, reconstruct business logic processes, and then carry out attacks such as device cloning, key theft, or business bypass.

[0003] Traditional white-box encryption schemes can only protect the encryption algorithm itself and cannot hide the state machine and process structure of the upper-layer business logic. Reverse engineers can still quickly locate key business nodes through control flow analysis. Therefore, code obfuscation capabilities need to be introduced into the compilation and build chain to improve the time cost of reverse engineering and reduce the risk of device cloning.

[0004] In the existing technology, there are a variety of code obfuscation processing solutions. However, these solutions are difficult to balance in embedded environments, especially wearable device scenarios, with low invasiveness (no or minimal modification to the existing build system), lightweight (no need for heavy toolchain support), customizability (support for fine-grained strategy configuration) and debuggability (still able to locate problems after obfuscation).

[0005] Therefore, there is a need for source code obfuscation solutions that facilitate seamless or minimal integration with existing build systems. Summary of the Invention

[0006] This specification provides one or more embodiments of a source code processing method, apparatus, or device to solve the following technical problem: the need for a source code obfuscation processing solution that facilitates seamless or low-impact integration with existing build systems to better meet mass production-level commercial needs.

[0007] To solve the above-mentioned technical problems, one or more embodiments of this specification are implemented as follows: This specification provides one or more embodiments of a source code processing method, including: Obfuscate the source code copy to obtain obfuscated code; Determine the path where the obfuscated code is located, and use it as the target path; The target environment variable for construction is determined from the set of operating system environment variables, and the target environment variable is set so that the target environment variable indicates the target path, rather than the path where the original source code corresponding to the source code copy is located; Based on the target environment variables, a compiled file or executable file corresponding to the obfuscated code is generated.

[0008] This specification provides a source code processing apparatus according to one or more embodiments, comprising: The obfuscation module obfuscates the source code copy to obtain obfuscated code. The path determination module determines the path where the obfuscated code is located, and uses it as the target path. The variable setting module determines the target environment variable for construction from the set of operating system environment variables, and sets the target environment variable so that the target environment variable indicates the target path, rather than the path where the original source code corresponding to the source code copy is located; A build module is constructed based on the target environment variables to generate the compiled file or executable file corresponding to the obfuscated code.

[0009] This specification provides one or more embodiments of a source code processing device, comprising: At least one processor; and, A memory communicatively connected to the at least one processor; wherein, The memory stores instructions that can be executed by the at least one processor, and the instructions are executed by the at least one processor to enable the at least one processor to perform: Obfuscate the source code copy to obtain obfuscated code; Determine the path where the obfuscated code is located, and use it as the target path; The target environment variable for construction is determined from the set of operating system environment variables, and the target environment variable is set so that the target environment variable indicates the target path, rather than the path where the original source code corresponding to the source code copy is located; Based on the target environment variables, the system constructs and generates the compiled file or executable file corresponding to the obfuscated code.

[0010] The above-mentioned at least one technical solution adopted in one or more embodiments of this specification can achieve the following beneficial effects: By obfuscating the source code copy and indicating the path of the obfuscated code by the operating system environment variable, the build tool can directly obtain the build input source from the environment variable, and can complete the switch of the build source without affecting or with minimal impact on the build script or build configuration file. This helps to achieve zero-intrusion integration of the obfuscation system into the existing build project, and significantly reduces the engineering adaptation cost introduced by the obfuscation technology; since the obfuscation process acts on the source code copy rather than the original source code, the original source code always remains in its uncontaminated original state, which is convenient for subsequent version iteration, code review and team collaborative development; generated after obfuscation In the compiled or executable files, attackers find it difficult to directly identify key business logic from the decompiled results, thus effectively increasing the time cost of reverse engineering. Since the obfuscated code and the original source code are stored in different paths, only the values ​​of environment variables need to be modified to flexibly switch between the two build sources. When the obfuscated product is abnormal, it can quickly switch back to the original source code for debugging and location, overcoming the shortcomings of traditional obfuscation schemes in debugging. It only relies on the standard passing mechanism of operating system environment variables, avoiding the introduction of additional compiler frameworks or toolchains, making it more friendly to embedded cross-compilation environments and lowering the hardware and environment threshold for solution deployment. For these reasons, it is conducive to seamless or low-impact integration with existing build systems. Attached Figure Description

[0011] To more clearly illustrate the technical solutions in the embodiments or prior art of this specification, the drawings used in the description of the embodiments or prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments recorded in this specification. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0012] Figure 1 A flowchart illustrating a source code processing method provided for one or more embodiments of this specification; Figure 2 Provided for one or more embodiments of this specification Figure 1 A schematic diagram illustrating the principle of a specific implementation scheme of the method; Figure 3 A schematic diagram of a source code processing device provided for one or more embodiments of this specification; Figure 4 This is a schematic diagram of the structure of a source code processing device provided for one or more embodiments of this specification. Detailed Implementation

[0013] This specification provides a source code processing method, apparatus, device, and storage medium through its embodiments.

[0014] To enable those skilled in the art to better understand the technical solutions in this specification, the technical solutions in the embodiments of this specification will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments. Based on the embodiments of this specification, all other embodiments obtained by those skilled in the art without creative effort should fall within the scope of protection of this application.

[0015] To facilitate understanding of the issues mentioned in the background section, examples are provided of some solutions that the applicant has tried, as well as the shortcomings of these solutions that the applicant has observed.

[0016] The first approach is the LLVM-Obfuscator open-source solution. Based on the LLVM framework, this solution achieves control flow flattening and string encryption by inserting an obfuscation pass into an intermediate presentation layer. However, it may have the following drawbacks: it requires a complete LLVM toolchain, resulting in high portability costs in embedded cross-compilation environments, and there are often compatibility issues between LLVM versions and embedded compiler versions; it cannot achieve seamless integration with existing CMake projects, requiring modifications to the build script to introduce additional compilation options; and the obfuscation pass operates on a global compilation unit, affecting all code modules, making debugging difficult and prone to introducing unexpected behavior.

[0017] The second type is commercial obfuscator solutions (such as Virbox, Arxan, etc.). These solutions offer commercial code protection services but may have the following drawbacks: they charge per agent or per call, significantly increasing equipment BOM costs and becoming prohibitively expensive at mass production scales; as black-box tools, users cannot customize obfuscation strategies or adjust the obfuscation granularity for specific functions / modules; and they lack support for static library output in RTOS environments, with some solutions only supporting Windows / Linux applications, making them difficult to adapt to embedded bare-metal or RTOS scenarios.

[0018] The third approach is manual macro obfuscation. This approach involves manually replacing function and variable names with preprocessed macros to obfuscate identifiers. However, it may have the following drawbacks: macro definitions require manual maintenance, which increases dramatically as the codebase grows; macro name conflicts are highly likely to cause compilation errors; it cannot cover deeper protection needs such as string encryption and control flow obfuscation; code readability is significantly reduced, impacting team collaboration and making automated regression testing difficult.

[0019] The fourth approach is the Java / Kotlin ProGuard / R8 solution. This solution is a standard obfuscation tool for the Android platform, but it may have the following drawbacks: it only applies to the DEX bytecode level, cannot address the protection needs of native C / C++ code, and cannot be used in embedded RTOS environments.

[0020] The fifth type is the white-box encryption scheme. This scheme embeds the encryption algorithm's key into the algorithm implementation, so that the key does not appear in plaintext form in memory. It may have the following drawbacks: it only protects the encryption algorithm itself and does not involve obfuscation of business logic; reverse engineers can still identify key business functions such as payment, binding, and key derivation through control flow analysis and locate the attack entry point.

[0021] In summary, the solutions attempted by the applicant are insufficient to simultaneously meet the requirements of low invasiveness, lightweight design, customizability, and debuggability in embedded scenarios. The applicant has also gained a deeper understanding of some preconceived notions surrounding these solutions and existing technologies, including: obfuscation must intrude into the build system; current mainstream obfuscation solutions almost universally assume they are the main component of the build process, requiring the build system to actively cooperate; obfuscation must be tied to the compilation process; the industry generally views obfuscation as an adjunct to compilation, requiring activation through additional parameters in the compilation command or by replacing the compiler, and so on. These preconceived notions make the aforementioned problems difficult to solve and the aforementioned requirements difficult to meet.

[0022] Based on this, the applicant aims to break through these mindsets and propose a low-intrusion or even zero-intrusion embedded source code obfuscation compilation and build solution. The main ideas include: removing the decision-making power of whether to obfuscate from the build script and compiler and entrusting it to an independent environment variable (such as an environment variable provided by the operating system specifically for the build tool). The build script can remain low-aware or even unaware, simply executing mechanically. The build tool does not need to be modified and can control the entire process externally through the operating system mechanism, thereby helping to achieve zero intrusion.

[0023] Based on the above analysis, the solution in this application will be further described in detail.

[0024] Figure 1 This is a flowchart illustrating a source code processing method provided in one or more embodiments of this specification. The method can be executed on devices used to build code and prepare for the build process, typically such as research and development terminal devices or server devices used by researchers.

[0025] Figure 1 The process includes the following steps: S102: Obfuscate the source code copy to obtain obfuscated code.

[0026] By copying the original source code to generate a source code copy, and then obfuscating the source code copy instead of obfuscating the original source code itself, the security and independence of the original source code can be maintained. Of course, if it is certain that the original source code can be reliably restored from the obfuscated code, then it is also possible to directly obfuscate the original source code to obtain obfuscated code. This application does not deny this optional implementation method, but it recommends using a source code copy, as this is more secure.

[0027] Obfuscation disrupts the readability of the original content, making it difficult for attackers to decompile and reconstruct the clear business logic even if they obtain the compiled output. Obfuscation can employ existing techniques or innovative methods; the specific methods are not limited here, as long as the obfuscated code remains functionally equivalent to the original. Examples of obfuscation techniques include changing the control flow structure, renaming, encrypting strings, or adjusting code layout.

[0028] It should be noted that, for ease of description, the original source code, source code copy, and obfuscated code are all described and distinguished as different wholes. For example, the actual content of the original source code and the source code copy may be exactly the same, but they are treated as two different wholes. For obfuscated code, generally speaking, not all of its content is obfuscated; often only a part of the content is obfuscated, while the rest remains in its original form. In this application, these two parts are considered together as a whole, called obfuscated code, and the part that remains in its original form is not considered separately as the original source code.

[0029] In one or more embodiments of this specification, before obfuscating the source code copy to obtain obfuscated code, some preparatory work can be done to improve security. This may include: controlling access permissions or operational logic to ensure the original source code is read-only and not obfuscated; copying the original source code to generate a source code copy for obfuscation to obtain the obfuscated code, wherein the original source code is not in the target path to facilitate isolation and subsequent path switching based on build requirements.

[0030] Access control can utilize file system access permission mechanisms, such as setting the path to the original source code to read-only or restricting write permissions, preventing the functional modules or scripts responsible for obfuscation from writing to the original source code. Operation logic control can involve constraints at the logical level of the obfuscation functional modules or scripts themselves, such as rigidly stipulating that only copies of the source code can be operated on during obfuscation, or using configuration switches to prevent obfuscation tools from accessing the path to the original source code.

[0031] In this way, it is possible to more reliably ensure that the obfuscation process does not directly affect the original source code, thereby ensuring that the original source code remains intact and uncontaminated during the obfuscation process.

[0032] S104: Determine the path where the obfuscated code is located, as the target path.

[0033] After obfuscation, the obfuscated code is written to a specific location in the file system; this location is the target path. The original source code is located at a different path than the target path. Ideally, these two paths should be independent of each other to ensure the security of the original source code and isolate the effects of obfuscation from the original source code.

[0034] S106: Determine the target environment variable for construction from the set of operating system environment variables, and set the target environment variable so that the target environment variable indicates the target path, but does not indicate the path of the original source code corresponding to the source code copy.

[0035] In one or more embodiments of this specification, operating system environment variables are used to decouple the target path information of the obfuscated code from the build tools (such as CMake), thereby reducing or even eliminating intrusion into the subsequent build process. Specifically, a preset environment variable can be selected from the set of operating system environment variables as the target environment variable for subsequent builds. The target environment variable can be a pre-designed environment variable specifically for builds, such as a CMake environment variable.

[0036] Furthermore, the value of the target environment variable is then set to indicate the target path determined in step S104. This path, which could originally indicate the path to the original source code or another copy of the source code, changes after the switch. Thus, efficient path switching is achieved through this setting action. The path switching decision information can be stored independently of the build script and build configuration file. Therefore, the build tool does not need to concern itself with the source of the path or the switching logic; it only needs to read the code path to be used in this build from the target environment variable at runtime.

[0037] Operating system environment variables are key-value pairs used by the operating system to store parameters related to the system's runtime environment. In Unix / Linux systems, environment variables are typically defined in the shell session and made visible to the current shell and all its child processes using the `export` command. In Windows systems, they can be defined using the `set` command or the environment variable settings interface in system properties. Environment variables are passed from the parent process to the child process when the process is created; therefore, build tools started in the shell inherit all environment variables from the current shell.

[0038] In one or more embodiments of this specification, the operating system environment variables mentioned in this application are different from variables defined or cached within the build tool. Variables within the build tool are typically defined in the build configuration file using commands such as `set()`, or passed in via command-line arguments (e.g., the `-D` option). Their scope is limited to the build tool itself and is not passed to other processes. Operating system environment variables, on the other hand, are standard communication mechanisms at the operating system level. The build tool can read them through system-provided APIs and does not rely on any built-in functions of the build tool. A specific environment variable can be pre-specified in the set of operating system environment variables as a target environment variable. This serves as a bridge for the build tool to obtain the target path of the obfuscated code (and can also be used to switch to obtain the path of the original source code as needed). The name of this environment variable can be pre-configured in the build configuration file, and the build tool looks up the corresponding value in the set of environment variables after startup.

[0039] S108: Construct according to the target environment variables to generate the compiled file or executable file corresponding to the obfuscated code.

[0040] In one or more embodiments of this specification, the obfuscated code is built based on the target environment variable. The target path specified by the target environment variable is used as the code path to be built. The obfuscated code in the target path will be built instead of the original source code. Through the execution of the build process, the build artifact corresponding to the obfuscated code is obtained.

[0041] For example, when the build tool is started, it reads the values ​​of the target environment variables from the set of operating system environment variables during execution, obtains the target path where the obfuscated code is located, and uses the code under that path as input for compilation and linking. Since the path points to the obfuscated code obtained by obfuscating the source code copy, the corresponding compiled file or executable file also corresponds to the obfuscated code.

[0042] Compared to the conventional build process, the difference in this application is that the build tool obtains the source code input path not through hard-coded paths in the build script or fixed paths in the build configuration file, but through dynamic acquisition via external environment variables.

[0043] The resulting product can be applied to corresponding smart terminal devices, especially for implementing firmware for wearable devices such as smart glasses, smartwatches, smart bracelets, smart headphones, or AR / VR headsets. Firmware is the underlying software embedded in the corresponding device, responsible for driving hardware peripherals, managing device status, and executing core business logic (such as payment authentication, health monitoring, data transmission, key derivation, etc.). It is the essential foundational software layer for the normal operation of the device.

[0044] The compiled or executable files generated by this application can be burned into the flash memory, ROM, or other non-volatile storage media of a wearable device, becoming part of the device's firmware, thereby enabling the wearable device to execute corresponding business logic. Wearable devices are typically deployed in open physical environments, and their firmware is at risk of being disassembled and read or extracted through debugging interfaces. This application obfuscates the source code during the build process, making it difficult to reconstruct a clear business logic structure from the firmware code ultimately burned into the wearable device after decompilation. This effectively increases the difficulty for attackers to reverse engineer the core business logic, thus contributing to the security of wearable devices.

[0045] pass Figure 1 This method obfuscates a copy of the source code and uses operating system environment variables to indicate the path to the obfuscated code. This allows build tools to directly obtain the build input source from the environment variables, enabling the switching of the build source with minimal or no impact on the build script or build configuration file. This facilitates zero-intrusion integration of the obfuscation system into existing build projects, significantly reducing the engineering adaptation costs associated with introducing obfuscation technology. Because the obfuscation process operates on the source code copy rather than the original source code, the original source code remains in its uncontaminated, original state, facilitating subsequent version iterations, code reviews, and collaborative development within the team. The compiled or executable files generated after obfuscation contain attack vectors. It is difficult for decompilers to directly identify key business logic from the decompiled results, thus effectively increasing the time cost of reverse engineering. Since the obfuscated code and the original source code are stored in different paths, only the values ​​of environment variables need to be modified to flexibly switch between the two build sources. When the obfuscated product is abnormal, it can quickly switch back to the original source code for debugging and location, overcoming the shortcomings of traditional obfuscation schemes in debugging. It only relies on the standard passing mechanism of operating system environment variables, avoiding the introduction of additional compiler frameworks or toolchains, making it more friendly to embedded cross-compilation environments and lowering the hardware and environment threshold for solution deployment. For these reasons, it is conducive to seamless or low-impact integration with existing build systems.

[0046] based on Figure 1 In addition to the method described herein, this specification also provides some specific implementation schemes and extension schemes of this method, which will be further explained below.

[0047] In one or more embodiments of this specification, for ease of implementation, the specific construction process is described exemplarily. The construction process may include: invoking a construction tool by executing a construction script that does not contain the path where the original source code is located and the target path (referring to the specific path address); reading the variable name of the target environment variable from the construction configuration file through the construction tool; obtaining the target environment variable from the operating system environment variable set according to the variable name; determining the target path indicated by the target environment variable; and using the target path as the path of the code to be built to generate the compiled file or executable file corresponding to the obfuscated code.

[0048] Build scripts, such as build.sh, build.bat, or other similar scripts, are used to launch build tools, such as CMake, or similarly, Make or other build tools. The build script should be largely unaware of the paths to the original source code and the target code, thus helping to avoid modifications. The build script can primarily be responsible for calling the build tool and transferring control to it. This way, the build script doesn't need to be modified in different build scenarios (e.g., building for original source code, building for obfuscated code), facilitating zero-intrusion adaptation of the build entry point.

[0049] The build configuration file can be, for example, CMakeLists.txt in the CMake suite or Makefile in the Make suite. The build configuration file pre-defines the variable names of the target environment variables. Assuming the variable name is ENGINE_SDK_DIR, it can be specified using syntax such as "$ENV{ENGINE_SDK_DIR}" or "${ENGINE_SDK_DIR}" so that the build tools can accurately identify and read it.

[0050] For build tools, after reading the name of the target environment variable, they can use standard interfaces provided by the operating system (such as the getenv() function in the C standard library or system calls in other languages) to look up the value corresponding to that variable name from the set of operating system environment variables inherited by the current process. Since the build tool is a child process started by the shell process where the build script resides, it automatically inherits all environment variables from that shell. Therefore, when the target environment variable has already been exported to the runtime environment of the current build process via the export command in the build script, the build tool can successfully read its value. In this case, the build script can include the target environment variable.

[0051] Furthermore, the build script may not even need to include the variable names of the target environment variables. For example, the target environment variables can be pre-set in the operating system by the upstream build scheduling process before the build script is executed. In this case, the build script only performs calls to the build tools, thereby greatly reducing the coupling between the build script and the obfuscation process, and potentially eliminating the need to modify the build script.

[0052] In one or more embodiments of this specification, in practical applications, it may sometimes be necessary to build the original source code (e.g., when developing new features or comparing original logic), and it may even be possible to build the original source code by default. To make the solution more flexible, the direction can be switched based on the target environment variable settings, according to immediate needs. For example, assuming the path of the original source code indicated by the target environment variable is called the original path, after obfuscation processing to obtain obfuscated code, the value of the target environment variable can be modified to switch the original path indicated by the target environment variable to the target path for building the obfuscated code. Afterwards, if it is necessary to build the original source code, the target path indicated by the target environment variable can be switched back to the original path, and the original source code can be built using the target environment variable. The modification of the value of the target environment variable can be done in the build script using the export command, or manually executed in the terminal, or automatically injected by the upstream CI / CD system when the build is triggered, etc.

[0053] In this way, within the same engineering environment, it is possible to switch freely and flexibly between two build code source paths without modifying the build script or build configuration file during the switching process. The path information is carried by the target environment variable, and the switching operation is performed at the environment variable level rather than the code level. This helps to ensure the zero-intrusion characteristic of the obfuscation process on the build system and provides convenience for debugging and other scenarios.

[0054] In one or more embodiments of this specification, the setting of target environment variables can be completed by the build script during execution, rather than necessarily by the developer manually on the command line or by the build tool itself. In this case, the build script serves two purposes: firstly, it calls the build tool to start the build process; secondly, it can perform the export operation of the target environment variables before the build tool starts, so that the variables are added to the operating system environment variable set for subsequent build tool subprocesses to inherit and read.

[0055] Furthermore, the script can perform environment variable setting operations using only the bash and sed commands from the POSIX standard basic command set. The bash command acts as the script interpreter, and the sed command can be used for text processing, such as string transformations of paths or parameters. This low dependency characteristic means that no other additional command-line tools are needed, effectively reducing the requirements for the runtime environment. The script can be executed in any Unix-like environment with a standard POSIX shell (bash) and sed installed, without the need to install additional packages or toolchains.

[0056] The build script, in particular, does not depend on a Python interpreter or the LLVM compiler suite, which can include tools such as clang, clang++, opt, and llc. This allows for a clearer distinction between the build script of this application and other solutions. For example, the LLVM-Obfuscator solution relies on a complete LLVM toolchain, and many automation script solutions depend on a Python environment. In contrast, the build script of this application only relies on the standard bash and sed provided by the operating system when setting environment variables, without requiring the installation of any additional heavyweight toolchains.

[0057] Based on this, the advantages of the proposed solution in engineering deployment can be effectively enhanced. The minimal dependencies of the build script enable it to run in resource-constrained build environments or those without pre-installed heavy toolchains, such as in lightweight Docker images, embedded cross-compilation environments, or on the basic build nodes of CI / CD pipelines. The low dependency requirements of environment variable setting operations, as the link between the obfuscation process and the build process, significantly lower the deployment threshold and enhance adaptability.

[0058] In one or more embodiments of this specification, for obfuscation processing, the source code copy is obfuscated according to the obfuscation strategy corresponding to the following one or more dimensions: function name, string, constant, control flow, wildcard; in order to facilitate flexible execution, obfuscation configuration information can be set to guide how to obfuscate the specific dimensions used.

[0059] Regarding the function name dimension, function identifiers in the original code can be renamed. For example, replacing the original function name, which has clear semantic information, with a meaningless random string makes it difficult for attackers to infer the function's functionality from its name.

[0060] At the string level, plaintext strings in the code can be encrypted or encoded to prevent sensitive strings (such as URLs, key fragments, log tags, etc.) from appearing in plaintext form in the binary file. For example, plaintext strings in a source code copy can be XORed to generate a corresponding static constant array to replace the plaintext strings.

[0061] For the constant dimension, numerical constants or macro definitions in the original code can be transformed or renamed to hide the semantic information of key values ​​(such as key length, buffer size, algorithm parameters, descriptions indicating the purpose of encryption, etc.).

[0062] Regarding the control flow dimension, control structures such as branches and loops in the original code can be transformed (e.g., inserting conditional branches that are always false, flattening the control flow), disrupting the program's control flow graph and increasing the difficulty of reverse engineering.

[0063] Regarding the wildcard dimension, based on wildcard matching rules, symbols or code regions to be obfuscated can be specified in batches, thus serving as a matching rule provider for other dimensions (such as function name and constant dimensions). Wildcard expressions can conveniently specify a batch of symbols conforming to naming patterns as obfuscation targets, enabling flexible and batch definition of the obfuscation scope. For example, based on wildcard matching rules, the original function name to be obfuscated can be determined from a source code copy, and the original function name can be replaced with a randomly generated name. Of course, if wildcards are also used in the original code, obfuscation can also be achieved by replacing and modifying the wildcards.

[0064] In addition to the five dimensions listed above, dimensions can be expanded or reduced as needed. Dimensions can be selected and enabled based on specific security requirements. For example, only function name obfuscation can be enabled during the debugging phase, while full obfuscation can be enabled during production release. The listed dimensions can be further granularized, allowing for flexible selection and division, facilitating the customization of fine-grained obfuscation strategies.

[0065] Furthermore, to facilitate flexible dimension selection, each dimension can have its own independent switch to control whether the obfuscation processing is performed on the dimension corresponding to the switch. For example, the state of each switch can be independently controlled through obfuscation configuration information, thereby making the adjustment of the obfuscation strategy flexible. It does not require modification of the specific code of the obfuscation function, but is based on the obfuscation configuration information for lightweight, efficient, and free control, and is also easy to maintain.

[0066] Additionally, the control flow dimension can have a switch that is off by default, requiring active intervention (e.g., explicit user modification of the switch's state) to enable it. The reasoning here is that while control flow obfuscation effectively increases the difficulty of reverse engineering, its impact on code structure and runtime behavior is greater than other dimensions of obfuscation (e.g., function name renaming). In certain extreme optimization scenarios, it may introduce unexpected execution path changes, leading to abnormal program behavior. Therefore, setting the control flow dimension's switch to off by default ensures a stable and secure obfuscation effect under default configuration. Users requiring stronger protection can explicitly enable the dimension after fully understanding its potential impact. This helps to better balance security and stability.

[0067] Based on the aforementioned multi-dimensional obfuscation approach, this can be achieved through a multi-level obfuscation configuration tree. For example, a multi-level obfuscation configuration tree could be implemented as follows: Level 1, the dimension layer, dividing the obfuscated object into five dimensions: function name, string, constant, control flow, and wildcard; Level 2, the policy layer, with each dimension corresponding to an independent obfuscation policy; Level 3, the switch layer, with each dimension having an independent switch that can be enabled or disabled individually. Alternatively, a multi-level obfuscation configuration tree could be implemented as follows: multiple coarse-grained obfuscation dimensions at the previous level, and multiple further subdivided dimensions at the next level or multiple levels below, and so on.

[0068] Obfuscation strategies such as multi-level obfuscation configuration trees or similar approaches can be pre-defined in the obfuscation configuration information. In actual use, an obfuscation mapping file can be generated for the source code copy based on this configuration, describing the strategies that are actually needed or effective in this instance. Strategies not used in this instance are not included in the obfuscation mapping file. The obfuscation mapping file may indicate at least one of the following obfuscation mapping relationships: a mapping between random names used for obfuscation and specified functions in the source code copy; a mapping between renaming constants used for obfuscation and specified constants in the source code copy; a mapping between XOR keys used for obfuscation and specified strings in the source code copy, etc. Then, based on the obfuscation configuration information, obfuscation is achieved by mapping and replacing the corresponding specified information in the source code copy.

[0069] In one or more embodiments of this specification, the obfuscation mapping file can also be used to restore the original code before obfuscation, thereby enabling debugging and other purposes. More reliably, it can also introduce integrity verification information. Specifically, integrity verification information is generated for the source code copy or the corresponding original source code; the corresponding obfuscation mapping file and integrity verification information are saved for the obfuscated code; when problems occur in the obfuscated code, or its corresponding compiled or executable file, the obfuscated code can be debugged based on the obfuscation mapping file and integrity verification information to locate and resolve the problem.

[0070] Integrity verification information is a checksum obtained by hashing the original code (e.g., SHA256 or MD5), used to uniquely identify the content state of the original code at a specific time. Obfuscation mapping files and integrity verification information can be stored in the same directory or associated with the same version identifier (e.g., build number, Git commit hash). This information is not released to users along with the compiled or executable files to avoid exposing the correspondence between the obfuscated and unobfuscated versions and the obfuscation strategy.

[0071] When obfuscated code or its build artifacts exhibit anomalies (such as crashes, logical errors, or performance issues) during testing or actual operation, developers can verify the code version against integrity check information. If a match is found, the obfuscation mapping file's correctness can be trusted; otherwise, the corresponding version's obfuscation mapping file must be retrieved to prevent the use of incorrect mappings. Upon successful matching, the mapping relationships recorded in the obfuscation mapping file are used to restore the obfuscated content in the corresponding exception information (such as crash stack traces or decompiled results) to its original form, thereby pinpointing the specific location of the problem at the source code level. This helps overcome the difficulty of debugging after obfuscation using traditional methods, enabling a better closed loop of obfuscation and debugging backtracking.

[0072] In one or more embodiments of this specification, an obfuscation scheme targeting the control flow dimension is also provided, including: inserting a conditional branch that is always false into a specified control flow (e.g., at a specified function entry point, inside a loop, after a branch statement, etc.) of the source code copy; wherein the conditional branch that is always false is constructed based on a platform-independent safety expression, the safety expression is logically always false, cannot be eliminated by compilation optimization, and its calculation process only includes behaviors defined by the programming language standard, in order to avoid undefined behaviors and help to balance security and obfuscation effects. In particular, such a pool of conditional branches and / or such a pool of safety expressions can be prepared in advance, so that they can be directly selected from the pool, resulting in better reliability and efficiency.

[0073] The condition in this conditional branch is always false at runtime, so the code within the branch body is never executed. Thus, without changing the original execution path of the program, this increases the complexity of the decompiled control flow graph. When reconstructing the control flow, decompilation tools will include branches that are always false in their analysis, resulting in a reconstructed control flow graph containing many paths that are not actually executed, significantly increasing the time cost of manual analysis.

[0074] The conditional branch's evaluation condition is not a simple constant like `if(0)`, but is constructed based on a platform-independent, safe expression. Platform independence ideally means that the expression's evaluation result remains consistent across all target platforms, unaffected by differences in hardware architecture, operating system, compiler version, or compilation optimization level. A safe expression ideally means that its evaluation process does not involve operations that could cause program crashes or undefined behavior.

[0075] The reason for not using constant false values ​​such as if(0) is that the compiler may identify and eliminate such constant false branches when optimization is enabled, causing insertion failure. if(0) may be deleted during the compilation optimization stage, so the code in the branch body will not appear in the final build artifact, resulting in the loss of obfuscation effect.

[0076] Based on this consideration, safe expressions can be made so that they cannot be optimized away during compilation. The compiler cannot determine the result of the expression during the compilation optimization phase, or although it can determine it, it must retain the calculation process according to the language standard, thus preventing its deletion. This allows the inserted branch to be preserved in the final binary file, increasing the difficulty of reverse engineering.

[0077] For example, one can exploit the fact that the compiler has difficulty statically analyzing the construction method of its values ​​to pre-construct conditional branches or safe expressions for obfuscation. For instance, one can reference volatile variables across compilation units or take advantage of operations whose results the compiler cannot determine at compile time, making it impossible for the compiler to determine the truth value of the expression at compile time, thus preventing the compiler from deleting the branch.

[0078] To be more reliable, the evaluation process of the conditional branch and safety expression should only include behaviors defined by programming language standards (such as ISO / IEC 9899 (C standard) or ISO / IEC 14882 (C++ standard)) to avoid undefined behavior. By using only standard-defined behavior, the same evaluation results can be guaranteed on standard-compliant compilers, thus ensuring consistent behavior of the obfuscated program across different platforms and compiler versions, and avoiding random crashes caused by undefined behavior.

[0079] Based on the foregoing description, and more intuitively, one or more embodiments of this specification provide Figure 1 One specific implementation scheme of the method is shown in [reference]. Figure 2 , Figure 2 This is a schematic diagram illustrating the principle of the scheme.

[0080] This solution typically includes the following steps: The first step is to clear the old build artifacts from the previous build in preparation for the current build.

[0081] The second step is to prepare for obfuscation by copying the original source code to obtain a corresponding source code copy. Incidentally, the integrity verification information of the original source code or the source code copy can also be calculated.

[0082] The original repository "glasses_engine glasses_biz" in the diagram represents the original source code to be used (exemplarily for a smart glasses scenario). Using the `cp -r` command, it is copied to obtain a working copy "output / obfuscated", representing the source code copy. The SHA256 checksum of the source code copy is calculated and saved as integrity verification information in the file "original_checksums.txt".

[0083] The third step is to generate an obfuscation mapping file based on the obfuscation configuration information for this obfuscation process. You can also configure the corresponding obfuscation dimension switch status.

[0084] The "obfuscation.conf" in the diagram represents the obfuscation configuration information. It generates obfuscation mapping files according to the specified generation strategy through the mapping generator "generate_obfuscation_mapping". For example, it at least contains a mapping file between function names and random names, which is represented as "function_mapping.txt" in the diagram. Of course, it can also contain or generate other data to indicate the obfuscation strategy to be used.

[0085] The fourth step involves performing the obfuscation process on the source code copy based on the obfuscation mapping file and other indicated data. The diagram illustrates one of the main methods: batch replacement using the sed command. For example, at the function name level, the command `sed -i "s / original_function / random_name / g"` replaces the original name of a specified function with a generated random name; at the string level, XOR encoding generates `static const uint8_t XOR_ENCODE[]`, which replaces a custom string with the generated array; at the constant level, for example, renaming the encryption-related constant "AES_KEY_SIZE" to `OBF_KEY_SIZE` to hide its true business meaning; at the control flow level, generating constant-false conditional branches based on a pre-built platform-independent constant-false security expression pool and injecting them into the specified control flow; and so on.

[0086] Obfuscation processes generate obfuscated code, which may be in the form of a static library.

[0087] The fifth step is to set the path of the obfuscated code using the operating system environment variables that have been prepared in advance for the build tools, so that a build can be performed against that path.

[0088] Environment variables can be set before the build tool starts, either by the build script or the upstream scheduling process. The build tool itself doesn't care who set the environment variable, when it was set, or whether its value points to the original path or the obfuscated path; it can only retrieve the value from the operating system's environment variable set based on the variable name in the build configuration file. Thus, the decision information for enabling obfuscation is carried within the environment variable, decoupling it from the build script and build configuration file.

[0089] The build tool is, for example, CMake, and the environment variable is, for example, a CMake environment variable called "ENGINE_SDK_DIR". CMake can set the value of this environment variable using the example command "ENGINE_SDK_DIR=${obf_engine}", so that the environment variable is switched to indicate the path where the obfuscated code is located.

[0090] From CMake's perspective, the same variable name (ENGINE_SDK_DIR) is resolved to a path. Regardless of where that path points, CMake handles the subsequent compilation and linking processes in the same way. This makes CMake unaware of the changes, and when it needs to switch back to the original source code for building, it only needs to modify the environment variable to point to the original path; the build script remains unchanged.

[0091] The sixth step involves compiling and other processing steps to output the build artifacts. The corresponding obfuscation mapping files and reports that need to be archived can also be output for auditing and subsequent debugging.

[0092] The figure shows an example output of one of the build artifacts obtained after compilation, "libpay_glasses_sdk.a".

[0093] In one or more embodiments of this specification, a compilation host is used as an exemplary build execution entity. After the R&D personnel or CI system triggers the build process on the compilation host, the obfuscation script or tool is executed to perform obfuscation processing on the source code copy, such as function name replacement and string encryption, and outputs the obfuscated code to an independent target path. Simultaneously, an obfuscation mapping file is generated for subsequent debugging. After obfuscation, before executing build tools such as CMake, the build script can write the target path into the target environment variable using the operating system environment variable export command. The subsequently launched build tool, when parsing the build configuration file, automatically reads the value of the target environment variable from the operating system environment variable set using the pre-specified environment variable name in the build configuration file, and uses it as the code directory for this build. The build tool then calls the underlying compiler to load the obfuscated source code file from this path for compilation and linking, ultimately generating the firmware or executable file required by the target device.

[0094] In the above process, the build script does not need to care whether the source code comes from the original path or the obfuscated path; it is only responsible for calling the build tool. The build tool also only reads the values ​​of environment variables based on the variable names in the configuration file and is unaware of the path switching decision logic. Obfuscation, path switching decision-making, and compilation and building each perform their own functions, achieving low-intrusion or even zero-intrusion integration of the obfuscation system into the existing build process.

[0095] Regarding the problems mentioned in other solutions, the solution in this application helps to resolve them and achieve corresponding positive effects. For example, regarding the issue of LLVM toolchain redundancy, this application can be integrated into existing CMake projects in a very short time based on pure Shell and sed, without additional compilers; regarding the issue of high commercial costs, this application can use self-developed scripts to avoid licensing fees, which helps to reduce BOM costs and may even reduce them to zero; regarding the issue of debugging difficulties, this application can quickly revert to the obfuscated version to locate the problem based on obfuscated mapping files and integrity verification information; and so on.

[0096] Based on the same idea, one or more embodiments of this specification also provide apparatus and devices corresponding to the above methods, such as... Figure 3 , Figure 4 As shown. The apparatus and equipment are capable of performing the above methods and related alternatives accordingly.

[0097] Figure 3 This specification provides a schematic diagram of the structure of a source code processing device according to one or more embodiments, the device comprising: Obfuscation module 302 obfuscates the source code copy to obtain obfuscated code; The path determination module 304 determines the path where the obfuscated code is located as the target path. The variable setting module 306 determines the target environment variable for construction from the set of operating system environment variables, and sets the target environment variable so that the target environment variable indicates the target path, but does not indicate the path where the original source code corresponding to the source code copy is located; The build module 308 builds according to the target environment variables to generate the compiled file or executable file corresponding to the obfuscated code.

[0098] Optionally, the build generation module 308 calls the build tool by executing a build script that does not contain the path where the original source code is located and the target path; The build tool reads the variable names of the target environment variables from the build configuration file. Based on the variable name, the target environment variable is obtained from the set of operating system environment variables; Determine the target path indicated by the target environment variable; The target path is used as the path to the code to be built, and the compiled file or executable file corresponding to the obfuscated code is generated.

[0099] Optionally, the setting of the target environment variable is completed by the build script during execution; the build script is used to call the build tool, and the build script only relies on the bash and sed commands in the POSIX standard basic command set to perform the environment variable setting operation, without relying on the Python interpreter or LLVM compiler suite.

[0100] Optionally, the device further includes: Before obfuscating the source code copy to obtain obfuscated code, the preprocessing module 310, through permission control or operation logic control, allows the original source code to be read-only without undergoing the obfuscation process. The original source code is copied to generate a source code copy, which is used for obfuscation processing to obtain obfuscated code, wherein the original source code is not in the target path.

[0101] Optionally, the variable setting module 306 modifies the value of the target environment variable to switch the original path indicated by the target environment variable to the target path, wherein the original source code is located in the original path; After switching to the target path, if the variable setting module 306 needs to build the original source code, it will switch the target path indicated by the target environment variable back to the original path.

[0102] Optionally, the obfuscation processing module 302, based on the set obfuscation configuration information, performs obfuscation processing on the source code copy according to the obfuscation strategy corresponding to one or more of the following dimensions: Function name, string, constant, control flow, wildcard.

[0103] Optionally, each dimension has an independent switch to control whether the obfuscation process is performed on the dimension corresponding to the switch.

[0104] Optionally, the switch in the dimension of the control flow is in a default off state and needs to be turned on in response to an active operation.

[0105] Optionally, the obfuscation processing module 302 generates an obfuscation mapping file for the source code copy according to the set obfuscation configuration information. The obfuscation mapping file indicates at least one of the following obfuscation mapping relationships: a mapping relationship between a random name used for obfuscation and a specified function in the source code copy; a mapping relationship between a rename constant used for obfuscation and a specified constant in the source code copy; and a mapping relationship between an XOR key used for obfuscation and a specified string in the source code copy. Obfuscation is achieved by mapping and replacing the corresponding specified information in the source code copy according to the obfuscation configuration information.

[0106] Optionally, it also includes: The debugging processing module 312 generates integrity verification information for the source code copy or the corresponding original source code. The obfuscated code is stored in the obfuscated mapping file and the integrity verification information. When problems occur with the obfuscated code, or its corresponding compiled or executable file, the obfuscated code is debugged based on the obfuscation mapping file and the integrity verification information.

[0107] Optionally, the obfuscation processing module 302 inserts a conditional branch that is always false into a specified control flow of the source code copy; The conditional branch that is always false is constructed based on a pre-prepared pool of safe expressions. These safe expressions are platform-independent, logically always false, cannot be eliminated by compile-time optimization, and their calculation process only includes behaviors defined by the programming language standard to avoid undefined behaviors.

[0108] Optionally, the obfuscation processing module 302 determines the original function name to be obfuscated from the source code copy according to wildcard matching rules, and replaces the original function name with a randomly generated name; and / or, The plaintext string in the source code copy is XOR encoded to generate a corresponding static constant array to replace the plaintext string.

[0109] Optionally, the compiled file or executable file corresponding to the generated obfuscated code is used to implement the firmware of the wearable device.

[0110] Figure 4 This specification provides a schematic diagram of the structure of a source code processing device according to one or more embodiments. The source code processing device includes: At least one processor; and, A memory communicatively connected to the at least one processor; wherein, The memory stores instructions that can be executed by the at least one processor, and the instructions are executed by the at least one processor to enable the at least one processor to perform: Obfuscate the source code copy to obtain obfuscated code; Determine the path where the obfuscated code is located, and use it as the target path; The target environment variable for construction is determined from the set of operating system environment variables, and the target environment variable is set so that the target environment variable indicates the target path, rather than the path where the original source code corresponding to the source code copy is located; Based on the target environment variables, the system constructs and generates the compiled file or executable file corresponding to the obfuscated code.

[0111] Based on the same idea, one or more embodiments of this specification also provide a non-volatile computer storage medium storing computer-executable instructions configured as follows: Obfuscate the source code copy to obtain obfuscated code; Determine the path where the obfuscated code is located, and use it as the target path; The target environment variable for construction is determined from the set of operating system environment variables, and the target environment variable is set so that the target environment variable indicates the target path, rather than the path where the original source code corresponding to the source code copy is located; Based on the target environment variables, the system constructs and generates the compiled file or executable file corresponding to the obfuscated code.

[0112] In the 1990s, improvements to a technology could be clearly distinguished as either hardware improvements (e.g., improvements to the circuit structure of diodes, transistors, switches, etc.) or software improvements (improvements to the methodology). However, with technological advancements, many methodological improvements today can be considered direct improvements to the hardware circuit structure. Designers almost always obtain the corresponding hardware circuit structure by programming the improved methodology into the hardware circuit. Therefore, it cannot be said that a methodological improvement cannot be implemented using hardware physical modules. For example, a Programmable Logic Device (PLD) (such as a Field Programmable Gate Array (FPGA)) is such an integrated circuit whose logic function is determined by the user programming the device. Designers can program and "integrate" a digital system onto a PLD themselves, without needing chip manufacturers to design and manufacture dedicated integrated circuit chips. Furthermore, nowadays, instead of manually manufacturing integrated circuit chips, this programming is mostly implemented using "logic compiler" software. Similar to the software compiler used in program development, the original code before compilation must also be written in a specific programming language, called a Hardware Description Language (HDL). There are many HDLs, such as ABEL (Advanced Boolean Expression Language), AHDL (Altera Hardware Description Language), Confluence, CUPL (Cornell University Programming Language), HDCal, JHDL (Java Hardware Description Language), Lava, Lola, MyHDL, PALASM, and RHDL (Ruby Hardware Description Language). Currently, the most commonly used are VHDL (Very-High-Speed ​​Integrated Circuit Hardware Description Language) and Verilog. Those skilled in the art should also understand that by simply performing some logic programming on the method flow using one of these hardware description languages ​​and programming it into an integrated circuit, the hardware circuit implementing the logical method flow can be easily obtained.

[0113] The systems, devices, modules, or units described in the above embodiments can be implemented by computer chips or entities, or by products with certain functions. A typical implementation device is a computer. Specifically, a computer can be, for example, a personal computer, laptop computer, cellular phone, camera phone, smartphone, personal digital assistant, media player, navigation device, email device, game console, tablet computer, wearable device, or any combination of these devices.

[0114] For ease of description, the above devices are described in terms of function, divided into various units. Of course, in implementing this specification, the functions of each unit can be implemented in one or more software and / or hardware components.

[0115] Those skilled in the art will understand that the embodiments of this specification can be provided as methods, systems, or computer program products. Therefore, the embodiments of this specification can take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, the embodiments of this specification can take the form of a computer program product implemented on one or more computer-usable storage media (including, but not limited to, disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0116] This specification is described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of this specification. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, generate instructions for implementing the flowchart illustrations and / or block diagrams. Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.

[0117] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device to function in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in a process Figure 1 One or more processes and / or boxes Figure 1 The function specified in one or more boxes.

[0118] These computer program instructions may also be loaded onto a computer or other programmable data processing equipment to cause a series of operational steps to be performed on the computer or other programmable equipment to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable equipment for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 The steps of the function specified in one or more boxes.

[0119] It should also be noted that 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 limitation, 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.

[0120] This specification can be described in the general context of computer-executable instructions that are executed by a computer, such as program modules. Generally, program modules include routines, programs, objects, components, data structures, etc., that perform a specific task or implement a specific abstract data type. This specification can also be practiced in distributed computing environments, where tasks are performed by remote processing devices connected via a communication network. In distributed computing environments, program modules can reside in local and remote computer storage media, including storage devices.

[0121] The various embodiments in this specification are described in a progressive manner. Similar or identical parts between embodiments can be referred to mutually. Each embodiment focuses on describing the differences from other embodiments. In particular, the embodiments of apparatus, devices, and non-volatile computer storage media are basically similar to the method embodiments, so the descriptions are relatively simple; relevant parts can be referred to the descriptions of the method embodiments.

[0122] The foregoing has described specific embodiments of this specification. Other embodiments are within the scope of the appended claims. In some cases, the actions or steps recited in the claims may be performed in a different order than that shown in the embodiments and may still achieve the desired result. Furthermore, the processes depicted in the drawings do not necessarily require the specific or sequential order shown to achieve the desired result. In some embodiments, multitasking and parallel processing are possible or may be advantageous.

[0123] The above description is merely one or more embodiments of this specification and is not intended to limit this specification. Various modifications and variations can be made to the one or more embodiments of this specification by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principle of one or more embodiments of this specification should be included within the scope of the claims of this specification.

Claims

1. A source code processing method, comprising: Obfuscate the source code copy to obtain obfuscated code; Determine the path where the obfuscated code is located, and use it as the target path; The target environment variable for construction is determined from the set of operating system environment variables, and the target environment variable is set so that the target environment variable indicates the target path, rather than the path where the original source code corresponding to the source code copy is located; Based on the target environment variables, a compiled file or executable file corresponding to the obfuscated code is generated.

2. The method as described in claim 1, wherein the step of constructing based on the target environment variables to generate the compiled file or executable file corresponding to the obfuscated code specifically includes: The build tool is invoked by executing a build script that does not contain the path where the original source code is located or the target path; The build tool reads the variable names of the target environment variables from the build configuration file. Based on the variable name, the target environment variable is obtained from the set of operating system environment variables; Determine the target path indicated by the target environment variable; The target path is used as the path to the code to be built, and the compiled file or executable file corresponding to the obfuscated code is generated.

3. The method as described in claim 1 or 2, wherein the setting of the target environment variable is completed by the build script during execution; the build script is used to call the build tool, and the build script only relies on the bash and sed commands in the POSIX standard basic command set to perform the environment variable setting operation, without relying on the Python interpreter or LLVM compiler suite.

4. The method as described in claim 1, wherein before obfuscating the source code copy to obtain obfuscated code, the method further comprises: Through access control or operation logic control, the original source code is read-only and not obfuscated. The original source code is copied to generate a source code copy, which is used for obfuscation processing to obtain obfuscated code, wherein the original source code is not in the target path.

5. The method as described in claim 1, wherein setting the target environment variable to indicate the target path, rather than the path of the original source code corresponding to the source code copy, specifically includes: By modifying the value of the target environment variable, the original path indicated by the target environment variable is switched to the target path, wherein the original source code is located in the original path; After switching to the target path, the method further includes: If it is necessary to build the original source code, then switch the target path indicated by the target environment variable back to the original path.

6. The method as described in claim 1, wherein obfuscating the source code copy specifically includes: Based on the configured obfuscation information, the source code copy is obfuscated according to the obfuscation strategy corresponding to one or more of the following dimensions: Function name, string, constant, control flow, wildcard.

7. The method of claim 6, wherein each dimension has an independent switch for controlling whether the obfuscation processing is performed on the dimension corresponding to the switch.

8. The method of claim 7, wherein the switch of the control flow dimension is in a default off state and needs to be turned on in response to an active operation.

9. The method as described in claim 1, wherein obfuscating the source code copy specifically includes: Based on the set obfuscation configuration information, an obfuscation mapping file is generated for the source code copy. The obfuscation mapping file indicates at least one of the following obfuscation mapping relationships: the mapping relationship between a random name used for obfuscation and a specified function in the source code copy; the mapping relationship between a rename constant used for obfuscation and a specified constant in the source code copy; and the mapping relationship between an XOR key used for obfuscation and a specified string in the source code copy. Obfuscation is achieved by mapping and replacing the corresponding specified information in the source code copy according to the obfuscation configuration information.

10. The method of claim 9, further comprising: Generate integrity verification information for the source code copy or the corresponding original source code; The obfuscated code is stored in the obfuscated mapping file and the integrity verification information. When problems occur with the obfuscated code, or its corresponding compiled or executable file, the obfuscated code is debugged based on the obfuscation mapping file and the integrity verification information.

11. The method of claim 1, wherein obfuscating the source code copy specifically includes: Insert a conditional branch that is always false into the specified control flow of the source code copy; The conditional branch that is always false is constructed based on a pre-prepared pool of safe expressions. These safe expressions are platform-independent, logically always false, cannot be eliminated by compile-time optimization, and their calculation process only includes behaviors defined by the programming language standard to avoid undefined behaviors.

12. The method of claim 1, wherein obfuscating the source code copy specifically includes: Based on wildcard matching rules, the original function name to be obfuscated is determined from the source code copy, and the original function name is replaced with a randomly generated name; And / or, The plaintext string in the source code copy is XOR encoded to generate a corresponding static constant array to replace the plaintext string.

13. The method as described in claim 1, wherein the compiled file or executable file corresponding to the obfuscated code generated is used to implement the firmware of the wearable device.

14. A source code processing apparatus, comprising: The obfuscation module obfuscates the source code copy to obtain obfuscated code. The path determination module determines the path where the obfuscated code is located, and uses it as the target path. The variable setting module determines the target environment variable for construction from the set of operating system environment variables, and sets the target environment variable so that the target environment variable indicates the target path, rather than the path where the original source code corresponding to the source code copy is located; A build module is constructed based on the target environment variables to generate the compiled file or executable file corresponding to the obfuscated code.

15. The apparatus of claim 14, wherein the build generation module invokes a build tool by executing a build script that does not contain the path where the original source code is located and the target path; The build tool reads the variable names of the target environment variables from the build configuration file. Based on the variable name, the target environment variable is obtained from the set of operating system environment variables; Determine the target path indicated by the target environment variable; The target path is used as the path to the code to be built, and the compiled file or executable file corresponding to the obfuscated code is generated.

16. The apparatus of claim 14 or 15, wherein the setting of the target environment variable is performed by the build script during execution; the build script is used to call the build tool, and the build script relies only on the bash and sed commands in the POSIX standard base command set to perform the environment variable setting operation, without relying on the Python interpreter or LLVM compiler suite.

17. The apparatus of claim 14, further comprising: Before obfuscating the source code copy to obtain obfuscated code, the preprocessing module, through permission control or operation logic control, allows the original source code to be read-only without undergoing the obfuscation process; The original source code is copied to generate a source code copy, which is used for obfuscation processing to obtain obfuscated code, wherein the original source code is not in the target path.

18. The apparatus of claim 14, wherein the variable setting module, by modifying the value of the target environment variable, switches the original path indicated by the target environment variable to the target path, wherein, The original source code is located in the original path; After switching to the target path, if the variable setting module needs to build the original source code, it will switch the target path indicated by the target environment variable back to the original path.

19. The apparatus of claim 14, wherein the obfuscation processing module, based on the set obfuscation configuration information, performs obfuscation processing on the source code copy according to one or more of the following dimensions and the obfuscation strategy corresponding to the dimension: Function name, string, constant, control flow, wildcard.

20. The apparatus of claim 19, wherein each dimension has an independent switch for controlling whether the obfuscation process is performed on the dimension corresponding to the switch.

21. The apparatus of claim 20, wherein the switch in the dimension of the control flow is in a default off state and needs to be turned on in response to an active operation.

22. The apparatus of claim 14, wherein the obfuscation processing module generates an obfuscation mapping file for the source code copy according to the set obfuscation configuration information, the obfuscation mapping file indicating at least one of the following obfuscation mapping relationships: a mapping relationship between a random name used for obfuscation and a specified function in the source code copy, a mapping relationship between a rename constant used for obfuscation and a specified constant in the source code copy, and a mapping relationship between an XOR key used for obfuscation and a specified string in the source code copy; Obfuscation is achieved by mapping and replacing the corresponding specified information in the source code copy according to the obfuscation configuration information.

23. The apparatus of claim 22, further comprising: The debugging processing module generates integrity verification information for the source code copy or the corresponding original source code; The obfuscated code is stored in the obfuscated mapping file and the integrity verification information. When problems occur with the obfuscated code, or its corresponding compiled or executable file, the obfuscated code is debugged based on the obfuscation mapping file and the integrity verification information.

24. The apparatus of claim 14, wherein the obfuscation processing module inserts a conditional branch that is always false into a specified control flow of the source code copy; in, The conditional branch that is always false is constructed based on safe expressions in a pre-prepared pool of safe expressions. These safe expressions are platform-independent, logically always false, cannot be eliminated by compile-time optimization, and their calculation process only includes behaviors defined by the programming language standard to avoid undefined behaviors.

25. A source code processing device, comprising: At least one processor; as well as, A memory communicatively connected to the at least one processor; wherein, The memory stores instructions that can be executed by the at least one processor, and the instructions are executed by the at least one processor to enable the at least one processor to perform: Obfuscate the source code copy to obtain obfuscated code; Determine the path where the obfuscated code is located, and use it as the target path; The target environment variable for construction is determined from the set of operating system environment variables, and the target environment variable is set so that the target environment variable indicates the target path, rather than the path where the original source code corresponding to the source code copy is located; Based on the target environment variables, a compiled file or executable file corresponding to the obfuscated code is generated.

Images