An algorithm protection method and system for a human body composition analyzer

Abstract

The application discloses a kind of algorithm protection method and system for human body component analyzer, the method includes: in response to the starting instruction of application program, respectively, the version consistency of core algorithm SO file and second salt value is checked;And when checking any version is inconsistent, send download request to server side;Wait to receive the latest encrypted SO file data and the latest second salt value that are fed back by server side after verifying client machine code legal;The latest encrypted SO file data is written into local and carries out date check, and when the date of file creation date and request date is consistent, the latest second salt value is written into local;The decryption secret key is constructed by request date and the latest second salt value, and the latest encrypted SO file data is decrypted;The complete data after decryption is directly loaded from memory to process space, and corresponding component analysis business is completed.The technical scheme of the embodiment of the application can reduce the risk of core algorithm being reverse cracked.

Description

Technical Field

[0001] This invention relates to the field of software security and encryption technology, specifically to an algorithm protection method and system for a human composition analyzer. Background Technology

[0002] With the development of mobile internet, more and more body composition analyzers (such as smart body fat scales and smart body composition analyzers) are being implemented using Android-based development boards. However, Android platform applications face a serious threat of reverse engineering.

[0003] Current anti-hacking technologies used on the Android platform include code obfuscation, DEX encryption, SO hardening, environment detection, and anti-tampering. However, these solutions still have significant limitations and cannot fundamentally prevent the extraction of the core body fat percentage measurement algorithm in body composition analyzers.

[0004] Therefore, there is an urgent need to propose a technical solution that can effectively protect the core algorithm, prevent the algorithm from being reverse-engineered, and support flexible updates of the algorithm or key. Summary of the Invention

[0005] The present invention aims to solve at least one of the technical problems existing in the prior art, and proposes an algorithm protection method and system for human body composition analyzers.

[0006] In a first aspect, the present invention provides an algorithm protection method for a human body composition analyzer, comprising:

[0007] In response to the application's startup command, a version consistency check is performed on the core algorithm SO file and the second salt value. If either version is inconsistent, a download request is sent to the server. The download request must include at least the following fields: client machine code, request date string, and target SO version number.

[0008] Waiting to receive the latest encrypted SO file data and the latest second salt value from the server after verifying the validity of the client's machine code;

[0009] Write the latest encrypted SO file data locally and perform date verification. If the file creation date matches the request date, write the latest second salt value locally.

[0010] The decryption key is constructed using the request date and the latest second salt value to decrypt the latest encrypted SO file data; the decrypted complete data is then directly loaded from memory into the process space to complete the corresponding component analysis.

[0011] Secondly, the present invention provides an algorithm protection system for a human body composition analyzer, comprising:

[0012] The version check module is configured to perform version consistency checks on the core algorithm SO file and the second salt value in response to the application's startup command; and to send a download request to the server if either version is inconsistent; the download request must include at least the following fields: client machine code, request date string, and target SO version number;

[0013] The feedback receiving module is configured to wait to receive the latest encrypted SO file data and the latest second salt value from the server after verifying the validity of the client's machine code;

[0014] The date verification module is configured to write the latest encrypted SO file data locally and perform date verification, and write the latest second salt value locally when the file creation date matches the request date;

[0015] The data decryption module is configured to construct a decryption key using the request date and the latest second salt value, decrypt the latest encrypted SO file data, and load the decrypted complete data directly from memory into the process space to complete the corresponding component analysis business.

[0016] Thirdly, embodiments of the present invention provide an electronic device, the electronic device comprising:

[0017] At least one processor; and a memory communicatively connected to the at least one processor;

[0018] The memory stores a computer program that can be executed by at least one processor, such that the at least one processor is able to perform the steps of the method according to any embodiment of the present invention.

[0019] Fourthly, embodiments of the present invention provide a computer-readable storage medium storing computer instructions that, when executed by a processor, implement the steps of a method according to any embodiment of the present invention.

[0020] Compared with the prior art, the present invention has the following advantages:

[0021] The technical solution in this embodiment of the invention firstly involves the client performing version consistency checks on the core algorithm SO file and the second salt value upon application startup. If either version is inconsistent, a download request is sent to the server. The client then waits to receive the latest encrypted SO file data and the latest second salt value from the server after verifying the client's machine code. Next, the client writes the latest encrypted SO file data locally and performs date verification. If the file creation date matches the request date, the latest second salt value is written locally. Finally, the client constructs a decryption key using the request date and the latest second salt value to decrypt the latest encrypted SO file data. The decrypted complete data is then directly loaded from memory into the process space to complete the corresponding component analysis. This technical solution reduces the risk of the core algorithm being reverse-engineered. Attached Figure Description

[0022] To more clearly illustrate the technical solutions in the embodiments of the present invention, the accompanying drawings used in the description of the embodiments will be briefly introduced below. Obviously, the accompanying drawings described below are only preferred embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0023] Figure 1 A flowchart illustrating an algorithm protection method for a human body composition analyzer provided in an embodiment of the present invention;

[0024] Figure 2 This is a schematic diagram illustrating the effect comparison in a real device dynamic debugging scenario provided by an embodiment of the present invention;

[0025] Figure 3 This is a schematic diagram illustrating the effect comparison in a static reverse analysis scenario provided by an embodiment of the present invention;

[0026] Figure 4 A schematic diagram of the structure of an algorithm protection system for a human body composition analyzer provided in an embodiment of the present invention;

[0027] Figure 5 This is a schematic diagram of the structure of an electronic device provided in an embodiment of the present invention. Detailed Implementation

[0028] 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 embodiments of the present invention, and not all embodiments. 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.

[0029] Before introducing the embodiments of the invention, it should be noted that some current anti-cracking methods include: code obfuscation, DEX encryption, SO hardening, environment detection, and anti-tampering. Code obfuscation involves renaming methods / classes / variables and flattening the control flow, but this only increases readability and cannot prevent the core logic from being extracted. DEX encryption involves encrypting DEX files and dynamically decrypting them at runtime, but the decrypted DEX can be dumped in memory. SO hardening involves encrypting SO files or obfuscating native code, but the hardened SO still exists as a file and can be extracted and analyzed. Environment detection checks the security of the runtime environment, but its single detection point is easily bypassed. Anti-tampering verifies whether the APK has been modified, but its verification logic itself can be hooked and bypassed.

[0030] The main problems currently existing in protecting the core algorithm (body fat percentage measurement algorithm) of body composition analyzers include:

[0031] 1) Java layer code is easily decompiled. Android applications are largely developed using the Java language, and Java bytecode can be easily decompiled by decompilation tools (such as jadx, apktool, etc.) into highly readable source code, making core algorithm logic extremely easy to leak.

[0032] 2) Static storage of SO files poses a security risk. While writing the core algorithm in a dynamic link library (.so file) in the Native layer increases the difficulty of reverse engineering, SO files are usually packaged and distributed with the APK, existing statically within the APK package. Attackers can obtain the SO file by unzipping the APK and then use disassemblers such as IDAPro for static analysis.

[0033] 3) Existing SO file hardening solutions still have shortcomings. Current SO file hardening solutions mainly fall into two categories: one is hardening the SO file itself, and the other is obfuscating and encrypting the native code within the SO file. However, most of these solutions still exist locally on the device as files, or perform encryption and decryption in memory, leaving the risk of attackers obtaining the SO file locally. Although some solutions employ dynamic loading technology, the decrypted SO file is often temporarily stored locally on the device, making it easy to copy.

[0034] 4) Inadequate key management. Some solutions hardcode the decryption key in the APK or distribute it with the APK. Attackers can obtain the key through reverse engineering and thus decrypt the core algorithm.

[0035] 5) Inflexible key or algorithm updates. When the body composition analyzer algorithm needs optimization and upgrade (or the decryption key needs to be updated), the traditional approach requires redistributing the entire APK version, which users need to download and install again. This results in a long update cycle and low efficiency. In many cases, various factors (such as personnel changes) may lead to key leakage. Failure to update the key can easily lead to the eventual exposure of the company's core value algorithms or formulas.

[0036] Example 1

[0037] Figure 1 This is a flowchart illustrating an algorithm protection method for a body composition analyzer provided in an embodiment of the present invention. This embodiment is particularly applicable to scenarios where the underlying code of a body composition analyzer is protected from reverse engineering attacks. The method can be executed by an algorithm protection system for a body composition analyzer, which can be implemented in software and / or hardware and can be configured in an electronic device.

[0038] This method is applied to the client side of body composition analyzers, such as... Figure 1 As shown, it specifically includes:

[0039] S1, in response to the application's startup command, performs version consistency checks on the core algorithm SO file and the second salt value; and if either version is inconsistent, it sends a download request to the server.

[0040] The download request must include at least the following fields: client machine code, request date string, and target SO version number.

[0041] The device ID (DeviceID) refers to the unique hardware identifier of the device collected by the client (such as AndroidID, IMEI, or system-generated UUID), which is used by the server to verify the device's legitimacy.

[0042] The request date string (Req_Date) refers to the date obtained by the client from the current system date, formatted as a YYYYMMDD string, and used as the time factor for this download request.

[0043] The target SO version number (Target_Version) refers to the version number Ver_Server of the latest core algorithm SO file on the server side.

[0044] When the client determines that an update is needed, it constructs a download request message, which includes at least the following fields: machine code, request date string, and target SO version number. The client encapsulates these parameters into an HTTP / HTTPS request and sends it to the download interface specified on the server.

[0045] Furthermore, in step S1, if any version is found to be inconsistent, a download request is sent to the server, specifically including:

[0046] S101, obtain the version number of the latest core algorithm SO file and the version number of the second salt value from the server.

[0047] S102, read the version number of the locally stored core algorithm SO file and the version number of the second salt value.

[0048] S103, if the version number of the core algorithm SO file on the server and the local storage are inconsistent, and / or the version number of the second salt value on the server and the local storage are inconsistent, then a download request is sent to the server.

[0049] The client stores the encrypted core algorithm SO file and updates the version number of the core algorithm SO file and the second salt value version number recorded locally.

[0050] The client performs a version consistency check upon startup, and all communication between the client and the server is encrypted using SSL / TLS to prevent data interception during network transmission.

[0051] Specifically, when the client application starts, a version verification process is automatically triggered. The client first sends a version query request to the server to obtain the version number Ver_Server of the latest core algorithm SO file currently released by the server, as well as the version number SaltVer_Server of the corresponding variable salt value salt2. The client then reads the version number Ver_Local of the core algorithm SO file and the version number SaltVer_Local of the variable salt value salt2 that are already stored locally.

[0052] If at least one of the following conditions is met:

[0053] 1) The versions of Ver_Local and Ver_Server are inconsistent;

[0054] 2) SaltVer_Local and SaltVer_Server versions are inconsistent;

[0055] Then, it is determined that a download and update process needs to be executed.

[0056] Furthermore, in step S1, the process of performing version consistency checks on the SO file and the second salt value specifically includes:

[0057] S110: If the versions are all consistent, skip the download process of the latest encrypted SO file data and the latest second salt value, directly decrypt the locally stored encrypted core algorithm SO file, and load it into the process space after decryption.

[0058] The client uses existing encrypted SO file data locally for subsequent business logic.

[0059] That is, if Ver_Local == Ver_Server and SaltVer_Local == SaltVer_Server, the client will directly use the existing encrypted SO file and the second salt value for subsequent operations, and this branch of the process will end.

[0060] S2, waits to receive the latest encrypted SO file data and the latest second salt value from the server after verifying the validity of the client's machine code.

[0061] After successful verification on the server side, an encryption key is dynamically derived and used to encrypt the SO file. Subsequently, the server returns the encrypted SO file data along with a second salt value, Salt2.

[0062] Furthermore, in step S2, the process of the server-side returning the latest encrypted SO file data and the latest second salt value specifically includes:

[0063] S201, in response to the client's download request, verifies whether the client machine code in the download request is valid; if it is valid, it locates the path of the core algorithm SO file based on the target SO version number in the download request.

[0064] After the client sends the download request to the server, the server verifies whether the machine code in the request is in the legitimate device database; if the verification is successful, the server locates the original SO file path from the configuration table based on the target SO version number.

[0065] Furthermore, in step S201, the process of verifying the validity of the client machine code in the download request specifically includes:

[0066] S2011, if client machine code verification fails, wait to receive the error code returned by the server after client machine code verification fails and terminate the subsequent process.

[0067] Specifically, after receiving a download request from a client, the server first extracts the machine code field from the request and compares it with a pre-registered whitelist of legitimate devices in the server's database. If the machine code exists in the database and is valid, the verification passes, and the server continues subsequent processing; if the verification fails, an error code is returned to the client, and the process terminates. This process is used to prevent unauthorized devices from illegally obtaining encrypted SO files.

[0068] S202, based on the request date string in the download request, combines a fixed first salt value and a periodically updated second salt value to generate a symmetric encryption key.

[0069] The server retrieves the request date string `date_str` from the download request sent by the client, and pre-sets a fixed salt value `salt1` (a binary byte sequence, e.g., `b'secret'`), and configures a periodically updated variable salt value `salt2` (a binary byte sequence, e.g., `b'change'`). The first salt value `salt1` is hardcoded in the code, while the second salt value `salt2` is configured in the server's configuration file.

[0070] Furthermore, in step S202, the process of generating the symmetric encryption key specifically includes:

[0071] S2021, concatenate the request date string, the first salt value, and the second salt value into a first combined string;

[0072] S2022, The first combined string is digested using a hash algorithm to obtain the first digest result;

[0073] S2023, use the bytes at a specific position in the first digest result as the original key for symmetric encryption.

[0074] The server concatenates the date string `date_str` with the salt values ​​`salt1` and `salt2` to form a combined string, i.e., `date_str + salt1.decode() + salt2.decode()`. It then uses the SHA-256 hash algorithm to perform a digest operation on this combined string and takes the first 16 bytes of the digest as the original key `key_str` for AES symmetric encryption.

[0075] It should be noted that existing technologies require the entire APK version to be republished for algorithm optimization or key updates, necessitating users to download and install it again, resulting in long update cycles and low efficiency. This embodiment achieves online hot updates of algorithms and keys through an architecture design that decouples SO files from the APK: SO files are published independently of the APK; the algorithm SO file is not packaged in the APK but stored on the server, and the client automatically checks the version upon startup. Version comparison and on-demand download: When the client starts, it compares the local SO version with the latest version on the server; if they are inconsistent, it automatically downloads and updates; Salt2 is distributed independently with each version: Salt2 is updated synchronously when the algorithm is updated, and the old and new versions do not affect each other; rapid replacement after key leakage: When Salt2 is leaked due to personnel changes or other reasons, only the Salt2 needs to be replaced on the server side, and the SO file needs to be re-encrypted and distributed; the client automatically completes the update.

[0076] S203 reads all byte data of the core algorithm SO file and uses all byte data as plaintext data blocks to be encrypted, and fills the length of the plaintext data blocks to be an integer multiple of the standard block length.

[0077] The server reads all bytes of data from the target SO file (dynamic link library file) in binary mode, and uses it as the plaintext data block so_data to be encrypted.

[0078] Subsequently, the server performs PKCS#7 format padding. Based on the AES block cipher block length (16 bytes), the padding length is calculated as pad_len = 16 - (len(so_data)%16). If the remainder is 0, 16 bytes are padded. The value of each padding byte is set to pad_len and appended to the end of so_data, ensuring the padded data length is a multiple of 16.

[0079] Understandably, the client application is mainly based on the Android platform and is mostly Java code. Since Java layer code is easy to decompile, the server-side encryption process implements the core algorithm in the native layer (C / C++) SO file. The Java layer is only responsible for non-sensitive operations such as UI interaction and data collection. The core algorithm logic, key derivation logic, decryption logic and SO loading logic are all completed in the native layer. There is no decompilable code related to the core algorithm in the Java layer.

[0080] S204. Construct a random initialization vector, and encrypt the padded plaintext data block by combining the symmetric encryption key and the random initialization vector to generate ciphertext data.

[0081] The server generates a random initialization vector. For example, a 16-byte random initialization vector iv can be generated using a cryptographically secure random number generator.

[0082] The server performs AES encryption in CBC mode. Specifically, using the derived key_str as the encryption key and the generated iv as the initialization vector, the plaintext data block after padding is encrypted using the CBC (Cipher Block Chaining) mode of the AES algorithm to obtain the ciphertext data encrypted.

[0083] Understandably, the server-side encryption process changes the traditional way SO files are packaged and distributed with the APK and statically exist within the APK package. Specifically: SO files are not distributed as part of the APK; the original SO files are not packaged in the APK's lib / directory, but are stored on the server side and dynamically generated upon receiving a client request (ensuring that the keys for each SO are essentially different to prevent leakage); encrypted SO files are distributed on demand, and clients only request a specific version of the encrypted SO file from the server when needed; only the encrypted form is stored locally, and the client locally stores the AES-CBC encrypted SO file. Even if an attacker obtains the file through decompression or other means, they cannot directly perform static analysis using disassemblers such as IDAPro.

[0084] S205: Combine the ciphertext data and the random initialization vector according to a predetermined format to generate the latest encrypted SO file data; send the latest encrypted SO file data and the latest second salt value to the client.

[0085] The server combines the generated ciphertext data with the initialization vector iv in a predetermined format (e.g., appending iv as a prefix to the ciphertext header) to form the latest encrypted SO file data. The server returns this latest encrypted SO file data packet to the client via HTTPS as the response body. Simultaneously, the server returns the latest second salt value (Salt2) used in this encryption to the client in an additional field of the response or in a separate delivery channel for subsequent storage or transmission.

[0086] It's important to emphasize that the core algorithm (SO) file is hosted on the server; the client never receives any unencrypted algorithm files. Furthermore, the key is constructed by combining (e.g., concatenating) the file creation date (which cannot be manually modified) with two sets of random strings (technically termed "encryption salt"). Both the SO algorithm and the encryption salt are updatable. With the analyzer app unchanged, the client only needs to request the version of the SO algorithm or encryption salt that requires a forced update and compare it with the local version each time it starts. If they don't match, the latest version will be requested. Additionally, if a download fails, a previous version can be used, meaning that even if the device is offline after activation, it will not be affected.

[0087] Furthermore, in step S205, the latest encrypted SO file data and the latest second salt value are sent to the client, specifically including:

[0088] S2051, the latest second salt value is distributed in the form of a separate configuration file or key-value pair, and the latest second salt value and the latest encrypted SO file data are two logically independent delivery units.

[0089] Furthermore, in step S2, the process of waiting to receive feedback from the server also includes:

[0090] S210: If no response is received from the server within the predetermined time, an automatic retry will be performed; and when the preset maximum number of retries is reached, the subsequent process will be terminated.

[0091] To enhance reliability, a timeout retry mechanism can also be included: if the download request does not receive a response from the server within a predetermined time (e.g., 3 seconds), it will automatically retry up to 3 times. During the retry, the main thread UI operation will not be blocked, and it will only be executed asynchronously.

[0092] S3 writes the latest encrypted SO file data to the local machine and performs date verification. If the file creation date matches the request date, the latest second salt value is written to the local machine.

[0093] Furthermore, in step S3, the latest encrypted SO file data is written locally and date verification is performed, specifically including:

[0094] S301: Write the latest encrypted SO file data received from the server to the local storage directory and record the file creation date;

[0095] S302, After writing is complete, compare the file creation date with the date corresponding to the request date when the download request was sent to the server;

[0096] S303: If the file creation date matches the request date, the latest encrypted SO file data written is deemed valid; if the file creation date does not match the request date, the latest encrypted SO file data written is deemed expired, and a new download request is initiated to the server.

[0097] After receiving the encrypted SO file data from the server, the client immediately writes it to its local storage directory (overwriting the previous corresponding file) and saves it as an encrypted SO file (e.g., lib.ta). When performing the file write operation, the client records the current system time as the file's creation date. After writing is complete, the client compares and verifies the request initiation time (i.e., the request date string Req_Date) with the actual date portion of the file being written.

[0098] If the two dates match (i.e., file creation date == Req_Date), then the file is considered valid and the write operation was successful.

[0099] If the dates of the two requests do not match (e.g., the request was initiated at 23:59:59, but the file was written after 00:00:00 the next day), the encrypted file being downloaded is determined to have expired (the key derivation date does not match the file date). The client immediately deletes the written file and initiates a new download request to the server, continuing until the dates match. Alternatively, a maximum number of re-requests can be set, terminating when this maximum is reached. For example, the maximum number of re-requests can be set to two.

[0100] This verification mechanism ensures that the date factor on which the encryption key of the encrypted SO file stored on the client depends remains logically consistent with the file's lifecycle, avoiding decryption failures due to cross-day dates.

[0101] Furthermore, in step S3, after writing the latest encrypted SO file data and the latest second salt value locally, the following steps are also included:

[0102] S310 records the version number of the latest encrypted SO file data and the version number of the latest second salt value locally, respectively, and marks that the latest encrypted SO file data and the latest second salt value are ready.

[0103] After the encrypted SO file is successfully written and the date verification passes, the client immediately processes the second salt value, Salt2, returned by the server. The client securely writes this second salt value to a local cached binary file (overwriting any existing file with the same name, such as salt2.bin), and simultaneously records the version number SaltVer_Server corresponding to this second salt value in local information for use in version comparisons during subsequent startup. The storage of the latest second salt value, Salt2, can be converted into a raw byte stream and written to a binary file with no extension or a custom extension to prevent unauthorized reading of the local file.

[0104] The client updates its local version records to Ver_Server and SaltVer_Server, marking the current encrypted SO file and second salt value as ready. Subsequent business processes can directly use this encrypted SO file, combining it with the first salt value Salt1 in the code, the locally stored Salt2, and the current date to decrypt and load it for execution. This download and update process is now complete.

[0105] S4 constructs a decryption key using the request date and the latest second salt value, decrypts the latest encrypted SO file data, and loads the decrypted complete data directly from memory into the process space to complete the corresponding component analysis.

[0106] Furthermore, in step S4, the process of decrypting the latest encrypted SO file data and completing the corresponding component analysis includes:

[0107] S401: Obtain the file creation date of the latest encrypted SO file data that was written locally, and combine it with the local first salt value and the latest second salt value to generate a symmetric decryption key.

[0108] Furthermore, in step S401, the process of generating the symmetric decryption key specifically includes:

[0109] S4011, concatenate the file creation date, the first salt value, and the latest second salt value into a second combined string;

[0110] S4012, The second combined string is digested using a hash algorithm to obtain the second digest result;

[0111] S4013, use the bytes at a specific position in the second digest result as the decryption key for symmetric encryption.

[0112] When a client needs to decrypt a specified file (such as lib.ta), it obtains the following three key derivation factors:

[0113] File creation date (Date_Current): Gets the creation date of the downloaded encrypted file (such as lib.ta), formatted as a YYYYMMDD string;

[0114] First salt value (Salt1): A fixed constant (hard-coded) pre-set in the client C++ code;

[0115] The second salt value (Salt2): is read from the Salt2 cache file (such as salt2.bin) downloaded from the server and stored locally.

[0116] The client concatenates the three factors in the same predetermined order as when the server encrypted them into a combined string, namely Date_Current+Salt1+Salt2. Then, it uses the SHA-256 hash algorithm to perform a digest operation on the combined string and takes the first 16 bytes of the digest result as the AES-128 symmetric decryption key.

[0117] It should be noted that in existing technologies, keys are either hard-coded into the APK or distributed with the APK in some form, allowing attackers to obtain them through reverse engineering. This embodiment employs a "three-factor dynamic key derivation" mechanism, fundamentally solving the hard-coded key problem: the key is not stored anywhere; the decryption key is not stored but is calculated in real-time from three factors each time it is needed. The three-factor combination is: Key = SHA-256(File Creation Date + Salt1 Fixed Salt Value + Salt2 Variable Salt Value). The first 16 bytes are essential for all three factors. The date factor ensures that the file cannot be cracked if it is copied or moved: the creation date is generated by the system and cannot be changed. Salt1 is hard-coded in the C++ code: increasing the difficulty of extraction through code obfuscation and native layer protection. Salt2 is independently distributed by the server according to version: regularly updated to prevent leakage by others.

[0118] S402 reads the complete ciphertext data from the latest encrypted SO file and performs decryption operations using the symmetric decryption key combined with the random initialization vector used during encryption to obtain the decrypted complete data.

[0119] The client reads the downloaded encrypted SO file (such as lib.ta) from the local storage directory and obtains its complete binary ciphertext data CipherData.

[0120] The client uses the derived decryption key, along with the initialization vector IV (extracted from the encrypted SO file header) used during encryption, to decrypt CipherData in AES-CBC mode, obtaining the decrypted complete ELF format binary data PlainData.

[0121] S403, after obtaining the decrypted complete data, performs one or more environmental security checks; and after the environmental security checks pass, it loads the decrypted complete data directly from memory into the process space and obtains the corresponding handle.

[0122] The environmental security testing methods include: debugger testing, memory monitoring testing, and signature verification.

[0123] Before or during loading after decryption, the client C++ layer performs multiple environment security checks, including but not limited to the following:

[0124] Debugger detection: Detects whether the current process is attached to a debugger (such as IDA, gdb, etc.). It uses TracerPid detection + ptrace self-detection. If detected, the loading process is terminated.

[0125] Memory monitoring and detection: Detects for abnormal memory mappings or Hook frameworks (such as dynamic injection tools like Xposed and Frida). If any are found, the process is terminated.

[0126] Signature verification: Verify whether the package name and signature certificate of the calling application are consistent with expectations. If they are inconsistent, refuse to load.

[0127] The above checks ensure that the decrypted SO file only runs in a trusted environment, preventing attackers from stealing the decrypted code or key through dynamic debugging or memory dumping. A preferred implementation method can be supplemented as follows: Referring to the practices used when exporting high-end equipment from China, a forced destruction mechanism can be triggered once an abnormal environment is detected: immediately delete the downloaded encrypted SO file (such as lib.ta and the variable salt file salt2.bin in step 2), rendering it unusable afterward. This forces users to contact the company directly for resolution.

[0128] After the environmental security test is passed, the client directly loads the decrypted ELF binary data (PlainData) into the process space from memory, avoiding writing it to the local file system.

[0129] The specific method is as follows: The client C++ layer calls the system-provided android_dlopen_ext function, sets the ANDROID_DLEXT_LOAD_FROM_MEMORY flag, and passes the memory address and length of PlainData through the android_dlextinfo structure, thereby loading the decrypted SO file directly from memory into the current process space and obtaining the corresponding handle.

[0130] This loading method ensures that the decrypted plaintext SO data always exists in the process memory in a non-persistent form, while only the encrypted SO file is retained in the local storage medium, effectively preventing the plaintext SO file from being directly extracted or statically analyzed.

[0131] S404 caches the obtained handle in a global variable while retaining a memory cache of the decrypted complete data; and when performing component analysis, it calls the SO internal algorithm function through the obtained handle to complete the corresponding business.

[0132] The client caches the obtained Handle in a C++ global variable, while also retaining the decrypted PlainData in a memory cache. All subsequent business scenarios requiring calls to SO internal algorithm functions will access these functions through this cached Handle, eliminating the need to repeatedly perform decryption and loading operations.

[0133] When the client needs volume composition analysis calculation results from the SO library (i.e., after obtaining the base impedance data), the C++ layer uses the `dlsym` function in conjunction with a cached `Handle` to obtain the function pointer of the target function within the SO library. It then directly calls this function pointer, passing in the original data, and retrieves the return result. This entire process is completed in the Native layer, without involving the Java layer's `System.loadLibrary()` or `System.load()` methods, thus avoiding exposing the SO path to the Java layer and reducing the risk of being hooked and dynamically injected.

[0134] Furthermore, step S4 specifically includes:

[0135] S410: When the business is completed or the application exits, release the acquired handle and clear the cached decrypted complete data.

[0136] When the client's business is completed or the application exits, the C++ layer calls dlclose to release the cached SO handle and clear the decrypted memory cache data to ensure that sensitive data does not remain in memory.

[0137] It should be noted that this embodiment has made targeted improvements in the following aspects:

[0138] 1) Only encrypted SO files are stored locally. Decryption is performed in the C++ layer. The decrypted plaintext ELF data is not written to any local file and exists only in the process memory. 2) By using android_dlopen_ext in conjunction with the ANDROID_DLEXT_LOAD_FROM_MEMORY flag, the decrypted memory data is directly loaded into the process space. No plaintext SO files are written to disk throughout the process. 3) After loading, the SO handle is cached. All subsequent algorithm calls are performed in the Native layer through this handle, without exposing the SO path to the Java layer. 4) The decrypted memory cache can be cleared at an appropriate time to avoid plaintext data remaining in memory for a long time.

[0139] In summary, the core concept of the technical solution in this embodiment is reflected in at least the following aspects:

[0140] 1) Decoupling improvements at the architectural level: The SO file is separated from the APK and changed from being released with the package to being released on demand by the server. This achieves complete decoupling between the core algorithm and the application installation package, so that algorithm updates no longer depend on the APK release process.

[0141] 2) Improved key management mechanism: The traditional key storage approach is abandoned, and a dynamic key mechanism with real-time derivation of three factors, namely "date + fixed salt value + variable salt value", is adopted. The key is not stored, not transmitted, and is version isolated, eliminating the security risk of hard-coded extraction of the key.

[0142] 3) Improved SO loading method: The scheme of "memory decryption + memory loading + non-persistent execution" is adopted. The decrypted plaintext SO file is not written to local storage throughout the process, which completely eliminates the possibility of attackers obtaining plaintext SO from the local file system.

[0143] 4) Improved security detection mechanism: Environmental security detection (anti-debugging, anti-Hook, signature verification, etc.) is integrated into the C++ decryption loading layer to ensure that the decrypted SO only runs in a trusted environment, improving memory-level security protection. A destruction mechanism can be added to destroy files to prevent cracking once an abnormal environment is detected.

[0144] 5) Improved update mechanism: Through version number comparison and Salt2 version binding mechanism, online hot update of algorithm and key is realized, which greatly shortens the update cycle and reduces the risk of core assets being exposed due to key leakage.

[0145] To more clearly illustrate the technical effectiveness of the algorithm protection scheme in this embodiment, the following will provide a detailed explanation of the results of this technical solution and existing solutions in dealing with external attacks under different attack scenarios.

[0146] Figure 2 This is a schematic diagram illustrating the effect comparison in a real device dynamic debugging scenario provided by an embodiment of the present invention, such as... Figure 2 As shown, after connecting to a real device and launching the app, the attacker enters the IDA / Frida attached process. In the existing solution, ptrace is not protected and TracePid can be bypassed. The plaintext SO data in memory can be directly dumped, and the attacker has a high success rate in obtaining the core algorithm. However, in this technical solution, ptrace / TracePid needs to perform multi-layer detection. When an attack is detected, it triggers the destruction of encrypted SO data and clears the memory, ultimately terminating the process. The attacker fails and the sample is destroyed.

[0147] Figure 3 This is a schematic diagram illustrating the effect comparison in a static reverse analysis scenario provided by an embodiment of the present invention, such as... Figure 3 As shown, attackers obtain the core algorithm by decompressing / extracting the APK file, and then choose to locate the SO file and prepare for IDA analysis to carry out the attack. In existing solutions, the SO file is a plaintext ELF file that IDA can directly recognize. Its function names / logic are clear and the disassembly is highly readable, allowing attackers to obtain the core algorithm with a certain amount of time. However, in this technical solution, the SO file is AES-CBC encrypted ciphertext and IDA cannot recognize the ELF file (its header data is randomly distributed), ultimately causing the attacker's static analysis to fail and the code to be unable to be reconstructed.

[0148] To more clearly illustrate the technical effectiveness of the algorithm protection scheme in this embodiment, the following will provide a detailed explanation of the results of this technical solution and existing solutions in dealing with external attacks under different attack paths.

[0149] Attackers can use various attack methods to obtain the core algorithm of SO, such as dynamic debugging on real devices, static analysis of copied SO, and decompiling APK.

[0150] In existing solutions, attackers can use dynamic debugging on a real device to dump plaintext SO data in the client's memory by running the app and attaching a debugger, thereby obtaining the core algorithm. Attackers can also use static analysis of SO files to decompress the APK and extract the SO files, then use IDA Pro to directly decompile them, thereby obtaining the core algorithm. Attackers can also decompile the APK and use jadx to decompile Java, thereby obtaining the core algorithm.

[0151] In this technical solution, if an attacker attempts to launch an attack via dynamic debugging on a real device, running the app and attempting debugging will trigger multiple layers of detection, ultimately destroying the SO file and halting the process, resulting in failure to acquire the core algorithm. If an attacker also attempts to launch an attack via static analysis of the SO file by decompressing the APK, the SO file is AES-CBC encrypted and IDA cannot recognize ELF files, leading to failure to acquire the core algorithm. If an attacker also attempts to launch an attack via decompiling the APK by decompiling Java using jadx, the client only has a UI thread / collection logic and no SO file, resulting in failure to acquire the core algorithm.

[0152] The technical solution in this invention encapsulates the core algorithm for body fat percentage measurement into an SO file and stores it encrypted on the server. The APK does not contain any algorithm code or decryption key. Even if an attacker decompiles the APK, they cannot obtain any information about the core algorithm. The encryption process utilizes the immutability of the system file's creation date as part of the key composition. This ensures that even if the creation date of the encrypted file is changed after it has been moved or copied, decryption will still fail, significantly reducing the risk of the algorithm being reverse-engineered.

[0153] On the other hand, after dynamically downloading the encrypted SO file, it is only decrypted and loaded in the client's memory, and the decrypted SO file data does not generate any local files. Compared to temporarily storing the decrypted file in the device's private directory, this completely eliminates the possibility of attackers obtaining the decrypted SO file from the local file system, effectively preventing static analysis attacks.

[0154] On the other hand, through version management and a flexible remote update mechanism for the algorithm and a portion of the key (Salt2) on the server side, remote hot updates of the body fat percentage measurement algorithm and Salt2 are achieved. When the algorithm is optimized or corrected, developers only need to update the encrypted SO file on the server side, and all clients can automatically obtain the latest algorithm upon the next startup, without needing to re-release and reinstall the APK. This significantly shortens the algorithm iteration cycle and prevents the risk of the algorithm file being cracked due to the possible leakage of old key salts.

[0155] On the other hand, given the unique characteristics of body fat percentage measurement apps (requiring the collection of electrical impedance data, relying on specific conversion models, and having high algorithm value), a full-chain protection solution is provided, covering algorithm code writing (C / C++), compilation (SO), encryption (server storage), transmission (dynamic download), loading (memory decryption) to invocation (measurement calculation). This solution is more targeted and has a more significant protection effect.

[0156] Example 2

[0157] Based on the same inventive concept Figure 4 This is a schematic diagram of the structure of an algorithm protection system for a human body composition analyzer provided in an embodiment of the present invention, as shown below. Figure 4 As shown, the system specifically includes:

[0158] The version checking module 100 is configured to perform version consistency checks on the core algorithm SO file and the second salt value in response to the application's startup command; and to send a download request to the server when either version is inconsistent; wherein the download request includes at least the following fields: client machine code, request date string and target SO version number;

[0159] Feedback receiving module 200 is configured to wait to receive the latest encrypted SO file data and the latest second salt value fed back by the server after verifying the validity of the client machine code;

[0160] The date verification module 300 is configured to write the latest encrypted SO file data locally and perform date verification, and write the latest second salt value locally when the file creation date matches the request date;

[0161] The data decryption module 400 is configured to construct a decryption key using the request date and the latest second salt value, decrypt the latest encrypted SO file data, and load the decrypted complete data directly from memory into the process space to complete the corresponding component analysis business.

[0162] To illustrate the algorithm protection mechanism provided in this embodiment in more detail, and in conjunction with the algorithm protection system for a human body composition analyzer provided in this embodiment, the complete hardware and software working process will be shown below:

[0163] 1. Launch the App.

[0164] 2. The client reads the version number Ver_Local and the variable salt value version number SaltVer_Local from the locally stored encrypted SO file.

[0165] 3. The client requests the latest SO version number Ver_Server and salt version number SaltVer_Server from the server.

[0166] 4. The server returns the latest version information.

[0167] 5. The client checks whether the local version and the server version are consistent: if Ver_Local == Ver_Server and SaltVer_Local == SaltVer_Server, then skip the download and proceed directly to step 13 (main business process); if either is inconsistent, then continue with the download and update process from step 6 to step 12.

[0168] 6. The client constructs a download request, with the following parameters: machine code (unique device identifier); request date string (format YYYYMMDD); target SO version number (i.e., the latest version on the server).

[0169] 7. The client sends the download request to the server.

[0170] 8. Server-side processing: Verify whether the machine code in the request is in the legitimate device database; if the verification is successful, locate the original SO file path from the configuration table based on the target version number; derive the encryption key: concatenate "request date + fixed salt value Salt1 + variable salt value Salt2 bound to this version", and use the first 16 bytes of SHA-256 as the AES key; use this key to encrypt the original SO using AES-CBC (including random IV); return the encrypted SO file and the corresponding Salt2 value to the client.

[0171] 9. The client receives the encrypted SO file and Salt2, writes the encrypted SO file to local storage, and records the system date at the time of writing.

[0172] 10. Client performs date consistency check: Compare the "request initiation date" with the "file creation date"; if they match, the write is successful, and continue to step 11; if they do not match (e.g., clocks have struck, and the request process has spanned a day), delete the written file and return to step 6 to make a new request.

[0173] 11. The client saves the Salt2 returned by the server to a local cache file and records its version number.

[0174] 12. The client updates the local version record (Ver_Local=Ver_Server, SaltVer_Local=SaltVer_Server), the download process ends, and proceeds to step 13.

[0175] 13. UI Interaction Layer: The interface guides users to input basic information (age, gender, etc.).

[0176] 14. UI Interaction Layer: The interface displays operation prompts to inform the user to stand properly and hold the handles.

[0177] 15. Hardware Acquisition Layer: Acquires impedance data from the base hardware in real time.

[0178] 16. Core computing layer preparation: Read the encrypted SO file and Salt2 value stored locally; obtain the creation date of the encrypted SO file (format YYYYMMDD).

[0179] 17. Derivation of decryption key from core computing layer: Concatenate "creation date + Salt1 (hardcoded in code) + Salt2"; use the first 16 bytes of SHA-256 as the AES decryption key.

[0180] 18. Core Computing Layer Decrypts SO: Using the derived key and the IV attached during encryption, the encrypted SO is decrypted using AES-CBC; the complete plaintext ELF binary data is obtained, which exists only in memory and is not written to any local file.

[0181] 19. Core computing layer execution environment security check (in C++ layer): Check if the current process is attached by a debugger (IDA, gdb, etc.); check if a Hook framework (Xposed, Frida, etc.) exists; check if the caller application signature matches; if any check fails, terminate the process and report an error; if all checks pass, continue to step 20.

[0182] 20. The core computing layer loads the SO from memory: calls android_dlopen_ext, sets the ANDROID_DLEXT_LOAD_FROM_MEMORY flag; directly loads the decrypted memory data into the current process space; obtains the SO handle and caches it.

[0183] 21. Core computing layer calls algorithm function: obtains the target algorithm function pointer from the cached handle through dlsym; passes the electrical impedance data (and user basic information) collected in step 15 to the algorithm function; performs calculation to obtain the physical test result; the core computing layer returns the physical test result to the UI layer; UI display layer: displays the physical test result on the interface, and the process ends.

[0184] 24. (Optional) Resource release: When the application exits or at an appropriate time, call dlclose to release the SO handle and clear the decrypted memory cache.

[0185] The technical effects of the solution in this embodiment are similar to those described above, and will not be repeated here.

[0186] Example 3

[0187] Based on the same inventive concept Figure 5 This is a schematic diagram of an electronic device that implements the algorithm protection method for a body composition analyzer according to embodiments of the present invention. The electronic device is intended to represent various forms of digital computers, such as laptop computers, desktop computers, workbenches, personal digital assistants, servers, blade servers, mainframe computers, and other suitable computers. The electronic device can also represent various forms of mobile devices, such as personal digital processors, cellular phones, smartphones, wearable devices (such as helmets, glasses, watches, etc.), and other similar computing devices. The components shown herein, their connections and relationships, and their functions are merely illustrative and are not intended to limit the implementation of the invention described and / or claimed herein.

[0188] like Figure 5 As shown, the electronic device 10 includes at least one processor 11 and a memory, such as a read-only memory (ROM) 12 or a random access memory (RAM) 13, communicatively connected to the at least one processor 11. The memory stores computer programs executable by the at least one processor. The processor 11 can perform various appropriate actions and processes based on the computer program stored in the ROM 12 or loaded into the RAM 13 from storage unit 18. The RAM 13 can also store various programs and data required for the operation of the electronic device 10. The processor 11, ROM 12, and RAM 13 are interconnected via a bus 14. An input / output (I / O) interface 15 is also connected to the bus 14.

[0189] Multiple components in electronic device 10 are connected to I / O interface 15, including: input unit 16, such as keyboard, mouse, etc.; output unit 17, such as various types of displays, speakers, etc.; storage unit 18, such as disk, optical disk, etc.; and communication unit 19, such as network card, modem, wireless transceiver, etc. Communication unit 19 allows electronic device 10 to exchange information / data with other devices through computer networks such as the Internet and / or various telecommunications networks.

[0190] Processor 11 can be a variety of general-purpose and / or special-purpose processing components with processing and computing capabilities. Some examples of processor 11 include, but are not limited to, a central processing unit (CPU), a graphics processing unit (GPU), various special-purpose artificial intelligence (AI) computing chips, various processors running machine learning model algorithms, a digital signal processor (DSP), and any suitable processor, controller, microcontroller, etc. Processor 11 performs the various methods and processes described above, such as algorithm protection methods for a body composition analyzer.

[0191] In some embodiments, the algorithm protection method for a body composition analyzer can be implemented as a computer program tangibly contained in a computer-readable storage medium, such as storage unit 18. In some embodiments, part or all of the computer program can be loaded and / or installed on electronic device 10 via ROM 12 and / or communication unit 19. When the computer program is loaded into RAM 13 and executed by processor 11, one or more steps of the algorithm protection method for a body composition analyzer described above can be performed. Alternatively, in other embodiments, processor 11 can be configured to execute the algorithm protection method for a body composition analyzer by any other suitable means (e.g., by means of firmware).

[0192] Various embodiments of the systems and techniques described above herein can be implemented in digital electronic circuit systems, integrated circuit systems, field-programmable gate arrays (FPGAs), application-specific integrated circuits (ASICs), application-specific standard products (ASSPs), systems-on-a-chip (SoCs), payload-programmable logic devices (CPLDs), computer hardware, firmware, software, and / or combinations thereof. These various embodiments may include implementations in one or more computer programs that can be executed and / or interpreted on a programmable system including at least one programmable processor, which may be a dedicated or general-purpose programmable processor, capable of receiving data and instructions from a storage system, at least one input device, and at least one output device, and transmitting data and instructions to the storage system, the at least one input device, and the at least one output device.

[0193] Computer programs used to implement the methods of the present invention may be written in any combination of one or more programming languages. These computer programs may be provided to a processor of a general-purpose computer, a special-purpose computer, or other programmable data processing device, such that when executed by the processor, the computer programs cause the functions / operations specified in the flowcharts and / or block diagrams to be performed. The computer programs may be executed entirely on a machine, partially on a machine, or as a standalone software package, partially on a machine and partially on a remote machine, or entirely on a remote machine or server.

[0194] In the context of this invention, a computer-readable storage medium can be a tangible medium that may contain or store a computer program for use by or in conjunction with an instruction execution system, apparatus, or device. A computer-readable storage medium may include, but is not limited to, electronic, magnetic, optical, electromagnetic, infrared, or semiconductor systems, apparatus, or devices, or any suitable combination thereof. Alternatively, a computer-readable storage medium may be a machine-readable signal medium. More specific examples of machine-readable storage media include electrical connections based on one or more wires, portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fibers, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination thereof.

[0195] To provide interaction with a user, the systems and techniques described herein can be implemented on an electronic device having: a display device (e.g., a CRT (cathode ray tube) or LCD (liquid crystal display) monitor) for displaying information to the user; and a keyboard and pointing device (e.g., a mouse or trackball) through which the user provides input to the electronic device. Other types of devices can also be used to provide interaction with the user; for example, feedback provided to the user can be any form of sensory feedback (e.g., visual feedback, auditory feedback, or tactile feedback); and input from the user can be received in any form (including sound input, voice input, or tactile input).

[0196] The systems and technologies described herein can be implemented in computing systems that include backend components (e.g., as data servers), or middleware components (e.g., application servers), or frontend components (e.g., user computers with graphical user interfaces or web browsers through which users can interact with implementations of the systems and technologies described herein), or any combination of such backend, middleware, or frontend components. The components of the system can be interconnected via digital data communication of any form or medium (e.g., communication networks). Examples of communication networks include local area networks (LANs), wide area networks (WANs), blockchain networks, and the Internet.

[0197] A computing system can include clients and servers. Clients and servers are generally located far apart and typically interact through communication networks. The client-server relationship is created by computer programs running on the respective computers and having a client-server relationship with each other. The server can be a cloud server, also known as a cloud computing server or cloud host, which is a hosting product within the cloud computing service system to address the shortcomings of traditional physical hosts and VPS services, such as high management difficulty and weak business scalability.

[0198] It should be understood that the various forms of processes shown above can be used, with steps reordered, added, or deleted. For example, the steps described in this invention can be executed in parallel, sequentially, or in different orders, as long as the desired result of the technical solution of this invention can be achieved, and this is not limited herein.

[0199] The above are merely preferred embodiments of the present invention and are not intended to limit the present invention. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of the present invention should be included within the protection scope of the present invention.

Claims

1. An algorithm protection method for a body composition analyzer, applied to the client side of the body composition analyzer, characterized in that, include: In response to the application's startup command, version consistency checks are performed on the core algorithm SO file and the second salt value, respectively. Furthermore, if any version is found to be inconsistent, a download request is sent to the server; the download request must include at least the following fields: client machine code, request date string, and target SO version number; Waiting to receive the latest encrypted SO file data and the latest second salt value from the server after verifying the validity of the client's machine code; Write the latest encrypted SO file data locally and perform date verification. If the file creation date matches the request date, write the latest second salt value locally. The decryption key is constructed using the request date and the latest second salt value to decrypt the latest encrypted SO file data; the decrypted complete data is then directly loaded from memory into the process space to complete the corresponding component analysis.

2. The method according to claim 1, characterized in that, If any version is found to be inconsistent, a download request is sent to the server, specifically including: Obtain the version number of the latest core algorithm SO file and the version number of the second salt value from the server. Read the version number of the core algorithm SO file and the version number of the second salt value that are already stored locally; If the version numbers of the core algorithm SO files on the server and in local storage are inconsistent, and / or the version numbers of the second salt value on the server and in local storage are inconsistent, a download request is sent to the server.

3. The method according to claim 1, characterized in that, The process of the server returning the latest encrypted SO file data and the latest second salt value specifically includes: In response to a client's download request, verify the validity of the client machine code in the download request; if the verification is valid, locate the path of the core algorithm SO file based on the target SO version number in the download request. Based on the request date string in the download request, a symmetric encryption key is generated by combining a fixed first salt value and a periodically updated second salt value. Read all bytes of data from the core algorithm SO file and use all bytes of data as plaintext data blocks to be encrypted, and pad the length of the plaintext data blocks to be an integer multiple of the standard block length; Construct a random initialization vector, and combine the symmetric encryption key and the random initialization vector to encrypt the padded plaintext data block to generate ciphertext data; The encrypted data and random initialization vector are combined according to a predetermined format to generate the latest encrypted SO file data; the latest encrypted SO file data and the latest second salt value are sent to the client.

4. The method according to claim 3, characterized in that, The process of generating a symmetric encryption key specifically includes: Concatenate the request date string, the first salt value, and the second salt value into a first combined string; The first digest result is obtained by performing a hash algorithm on the first combined string; Use bytes at specific positions in the first digest result as the raw key for symmetric encryption.

5. The method according to claim 1, characterized in that, Write the latest encrypted SO file data locally and perform date verification, specifically including: Write the latest encrypted SO file data received from the server to the local storage directory and record the file creation date; After writing is complete, the file creation date is compared with the date of the request sent to the server for download; If the file creation date matches the request date, the latest encrypted SO file data is considered valid; if the file creation date does not match the request date, the latest encrypted SO file data is considered expired, and a new download request is initiated to the server.

6. The method according to claim 1, characterized in that, The process of decrypting the latest encrypted SO file data and completing the corresponding component analysis includes: Obtain the file creation date of the latest encrypted SO file data written locally, and combine it with the local first salt value and the latest second salt value to generate a symmetric decryption key; Read the complete ciphertext data from the latest encrypted SO file, and perform decryption operation using the symmetric decryption key combined with the random initialization vector during encryption to obtain the decrypted complete data. After obtaining the decrypted complete data, perform one or more environmental security checks; and after the environmental security checks pass, load the decrypted complete data directly from memory into the process space and obtain the corresponding handle; The obtained handle is cached in a global variable, while the complete decrypted data is stored in a memory cache; and when performing component analysis, the obtained handle is used to call the SO internal algorithm function to complete the corresponding business.

7. The method according to claim 6, characterized in that, The process of generating a symmetric decryption key specifically includes: Concatenate the file creation date, the first salt value, and the latest second salt value into a second combined string; The second combined string is digested using a hash algorithm to obtain the second digest result; Use bytes at specific positions in the second digest result as the decryption key for symmetric encryption.

8. An algorithm protection system for a body composition analyzer, applied to the client side of the body composition analyzer, characterized in that, The system is configured to implement the method according to any one of claims 1-7, the system comprising: The version check module is configured to perform version consistency checks on the core algorithm SO file and the second salt value in response to the application's startup command; and to send a download request to the server if either version is inconsistent; the download request must include at least the following fields: client machine code, request date string, and target SO version number; The feedback receiving module is configured to wait to receive the latest encrypted SO file data and the latest second salt value from the server after verifying the validity of the client's machine code; The date verification module is configured to write the latest encrypted SO file data locally and perform date verification, and write the latest second salt value locally when the file creation date matches the request date; The data decryption module is configured to construct a decryption key using the request date and the latest second salt value, decrypt the latest encrypted SO file data, and load the decrypted complete data directly from memory into the process space to complete the corresponding component analysis business.

9. An electronic device, characterized in that, The electronic device includes: At least one processor; and a memory communicatively connected to said at least one processor; The memory stores a computer program that can be executed by the at least one processor to enable the at least one processor to perform the steps of the method according to any one of claims 1-7.

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer instructions that cause a processor to perform the steps of the method according to any one of claims 1-7.

Images