Malicious software detection method based on block chain

Abstract

The invention relates to a malicious software detection method based on a block chain, and belongs to the technical field of malicious software detection.The method comprises the steps that firstly, known malicious software is subjected to static analysis, permission characteristics are obtained, and character strings are obtained; calculating a locality sensitive hash value of the character string; building a block chain environment, deploying each malicious software detection node in the block chain environment, and storing the locality sensitive hash value of each malicious software in the block chain environment by using an intelligent contract; by writing the smart contract, each node calculates the TLSH distance between the locality sensitive hash value of the to-be-detected software and the locality sensitive hash value of malicious software stored on the chain to obtain the final distance between the software, the final distance is compared with a set distance threshold, and if the maliciousness of the to-be-detected software is not detected, the software maliciousness of the to-be-detected software is detected. And if yes, performing secondary detection on the to-be-detected software based on a federated learning technology. According to the method, the blockchain and the locality sensitive hashing technology are combined, so that malicious software information sharing is realized while the malicious software detection timeliness is improved.

Description

Technical Field

[0001] The present invention relates to the technical field of malware detection, and in particular to a malware detection method based on blockchain. Background Art

[0002] In recent years, with the popularity of smartphones and the Internet of Things, mobile devices have become an indispensable part of people's daily lives. The continuous expansion of the Android operating system has led to a corresponding increase in malware targeting it. According to data from the Mobile Internet Application Security Monitoring Platform, a total of 2,146,509 malicious applications were found in 2023, with an overall year-on-year growth trend. The largest number of them were deception and fraud (more than 1 million), followed by rogue behavior, fee consumption, and privacy theft. The concealment and destructiveness of malware are constantly improving, and the impact it causes cannot be underestimated. Affected by factors such as technology and trust, it is difficult for malware detection agencies to widely share malware data in a timely manner, and there is no unified standard, resulting in a lot of waste of resources. Blockchain, as a decentralized distributed ledger technology, was first proposed by Satoshi Nakamoto in 2008. It can establish a trusted identity authentication system for users. By recording user identity and authentication information on the chain, blockchain can ensure the authenticity and credibility of user identity. In addition, blockchain can also be used to ensure the integrity and authenticity of data, and can provide a trusted data sharing method for various institutions. Summary of the invention

[0003] In order to solve the problem that existing malware detection agencies find it difficult to widely share malware data in a timely manner and have not formed a unified standard, resulting in a lot of resource waste, the present invention provides a malware detection method based on blockchain.

[0004] In order to solve the above technical problems, the technical solution adopted by the present invention is as follows:

[0005] A malware detection method based on blockchain, the method comprising the following steps:

[0006] Step 1: Perform static analysis on multiple known malware to obtain permission features, and sort the obtained permission features according to the dictionary to obtain a string corresponding to each malware;

[0007] Step 2: Calculate the local sensitive hash value of each string;

[0008] Step 3: Build a blockchain environment, deploy each malware detection node into the blockchain environment, and use smart contracts to store the local sensitive hash values ​​corresponding to each malware in the blockchain environment;

[0009] Step 4: By writing a smart contract, each malware detection node uses the TLSH distance calculation formula to calculate the TLSH distance between the local sensitive hash value of the software under test and the local sensitive hash value of the malware stored on the chain, and takes the average of the two smallest TLSH distance values ​​as the final distance value between the software under test and the malware, and determines whether the calculated final distance value is less than the set distance threshold. If so, the software under test is determined to be malware, otherwise, execute step 5;

[0010] Step 5: Based on the federated learning technology, each malware detection node jointly trains the malware detection model and performs secondary detection on the software to be tested, which specifically includes the following steps:

[0011] Step 5.1, Initialization: Set up a reliable central server to randomly initialize the malware detection model parameters;

[0012] Step 5.2, federated training: The central server distributes the parameters to each malware detection node. Each malware detection node uses local data for model training. During training, the stochastic gradient descent algorithm is used to minimize the loss function in the local training. After training, a local model is generated.

[0013] Step 5.3, model update: Each malware detection node sends the local model parameters back to the central server. The central server collects the parameters of all local models and aggregates them into the latest model parameters using the FedAvg method.

[0014] Step 5.4: Repeat steps 5.2 and 5.3 until the predetermined training rounds are reached and the optimal local model is obtained. Each malware detection node uses the optimal local model to detect the software to be tested. When the software to be tested is detected as malware, the local sensitive hash value of the software to be tested is stored in the blockchain environment.

[0015] The beneficial effects of the present invention are:

[0016] (1) The features extracted by the present invention are compressed and represented by TLSH, which greatly reduces the data dimension and improves the detection speed without losing the features;

[0017] (2) The present invention adopts blockchain technology to solve the trust problem between detection nodes, uses smart contracts to realize malware information sharing, and realizes rapid matching of malware on the chain;

[0018] (3) The present invention enables each malware detection node on the blockchain to jointly train a detection model using federated learning, and conduct secondary detection on the software on the chain that fails to match maliciousness, thereby improving the detection effect. BRIEF DESCRIPTION OF THE DRAWINGS

[0019] Figure 1 The overall flow chart of the blockchain-based malware detection method of the present invention;

[0020] Figure 2 The test result diagram of the present invention;

[0021] Figure 3 The classification result diagram of the present invention for malware families;

[0022] Figure 4 A diagram showing the effect of the federated learning detection method described in the present invention. DETAILED DESCRIPTION

[0023] The technical solution of the present invention will be described in detail below in conjunction with the accompanying drawings and preferred embodiments.

[0024] In one embodiment, if Figure 1 As shown, this implementation proposes a blockchain-based malware detection method, which mainly includes the following steps one to six.

[0025] Step 1: Use known malware as samples and perform static analysis on multiple known malware. For example, use the get_permissions() method of the open source static analysis tool Androguard to perform static analysis on each known malware, obtain the corresponding permission features, and sort the obtained permission features according to the dictionary. Finally, each known malware gets a corresponding string.

[0026] Step 2: Calculate the locality sensitive hash value of each string obtained in step 1.

[0027] Specifically, taking string S as an example, the calculation process of the local sensitive hash value of string S includes the following steps:

[0028] Step 2.1: First, convert the feature file into a set. Use a sliding window of size 5 bytes to process the string S. The sliding window slides forward one byte each time. Suppose the content of a sliding window is: ABCDE. Use Pearson Hash mapping to count the number of ABC, ABD, ABE, ACD, ACE, and ADE buckets respectively.

[0029] Step 2.2: After counting the number of all buckets in string S, define q1, q2, and q3 as follows: 75% of the buckets have a number >= q1; 50% of the buckets have a number >= q2; 25% of the buckets have a number >= q3;

[0030] Step 2.3: Construct the header of the locality-sensitive hash, which consists of three bytes: the first byte is the checksum of the string; the second byte is the logarithm L of the length of the string S described by formula (1); the third byte consists of two 16-bit numbers q 1_ratio ,q 2_ratio Combination of q 1_ratio ,q 2_ratio The calculation method is shown in formula (2):

[0031]

[0032] Where len is the length of string S;

[0033] Step 2.4: Construct the main part of the local sensitive hash: In the 128 mappings generated by Pearson Hash, each mapping is a key, and its corresponding value is the number of occurrences of the key; traverse each key and generate the corresponding binary bits according to formula (3), and finally obtain the main part hash value of 32 bytes:

[0034]

[0035] Step 2.5: Convert the binary string obtained from the header and body of the local sensitive hash into 70 hexadecimal digits, and finally obtain the local sensitive hash value of the string S.

[0036] Step 3: Build a blockchain environment based on the characteristics of blockchain, deploy each malware detection node into the blockchain environment, and use smart contracts to store the local sensitive hash value corresponding to each malware in the blockchain environment.

[0037] In this step, the Ethereum client Geth is used to build the blockchain environment. The relevant parameter settings of Geth's configuration file are shown in Table 1.

[0038] Table 1 Key parameters of Geth configuration file

[0039] Parameter name Parameter Value Nonce 0x0000000000000042 Difficulty 0x400 Mixhash 0x00000000000000000000000000000000 GasLimit 0xffffffffffffff ChainID 666

[0040] Nonce is a one-time number for transactions, which is recorded in the block header together with other information of the block to ensure the uniqueness of the transaction. Difficulty represents the difficulty setting, which determines the difficulty of proof of work in the network. Mixhash represents a 256-bit hash, which, together with Nonce, proves that sufficient calculations (POW) have been performed on this block. GasLimit represents the gas consumption limit for each block, and the gas consumed by each block cannot exceed this value. ChainID represents the ID of the Ethereum network. Each network has a unique ID to distinguish different networks.

[0041] The purpose of building this blockchain environment is to securely store and access malware signatures in an open, interconnected environment.

[0042] Furthermore, when using smart contracts to store the local sensitive hash values ​​corresponding to each malware in the blockchain environment, the characteristic hash values ​​of the known malware, namely the local sensitive hash values, are uploaded to IPFS using smart contracts. The complete information is saved by the IPFS distributed storage layer, and the generated unique hash value IpfsHash is saved on the blockchain.

[0043] In the blockchain network, each node shares the malware features it has mastered through smart contracts. Since most of the data is sensitive and the data volume is large, putting the data on the blockchain is a resource-intensive and risky task with limited storage space. IPFS is a distributed network transmission protocol that can divide files into many small pieces and put them in different places on the server, and then find and transmit these small pieces to obtain a unique hash value (IpfsHash). Therefore, in this step, the IPFS distributed storage layer is used to save the complete information, and the generated IpfsHash is saved on the blockchain.

[0044] Step 4: Match hash values ​​by writing smart contracts. Each malware detection node matches the local sensitive hash value of the software to be tested with the local sensitive hash value of the malware stored on the chain, and performs detection based on the threshold set for the distance. Specifically, by writing smart contracts, each malware detection node uses the TLSH distance calculation formula to calculate the TLSH distance between the local sensitive hash value of the software to be tested and the local sensitive hash value of the malware stored on the chain, and takes the average of the two smallest TLSH distance values ​​as the final distance value between the software to be tested and the malware, and determines whether the calculated final distance value is less than the set distance threshold. If so, the software to be tested is determined to be malware, otherwise, execute step 5.

[0045] When calculating the TLSH distance between the local sensitive hash value of the software under test and the local sensitive hash value of the malware stored on the chain, the following steps 4.1 to 4.4 are specifically included.

[0046] The distance between two locally sensitive hash summaries is measured. A distance score of 0 indicates that the files are identical (or almost identical), and higher scores should represent more differences between the documents. As shown in formula (4), first define mod_diff(X,Y,R), which is the minimum number of steps between locally sensitive hash values ​​X and Y on a circular queue of size R. (XY)modR represents the difference between locally sensitive hash values ​​X and Y, and formula (4) finally takes the minimum value of the difference between locally sensitive hash values ​​X and Y.

[0047] Step 4.1: Define mod_diff(X,Y,R) as the minimum distance from X to Y in a circular queue of size R, that is:

[0048] mod_diff(X,Y,R)=Min((XY)modR,(YX)modR) (4)

[0049] Among them, X and Y are the local sensitive hash values ​​of the software under test and the malware stored on the chain, respectively.

[0050] Step 4.2: Calculate the distance between the two locality sensitive hash values ​​X and Y headers:

[0051] Step 4.2.1: First, calculate the logarithm L of the length of the string S and the two 16-digit numbers q according to formula (4) 1_ratio and q 2_ratio Corresponding distances: mod_diff(XL,YL,256), mod_diff(Xq 1_ratio ,Yq 1_ratio ,256) and mod_diff(Xq 2_ratio ,Yq 2_ratio ,256), where XL is the logarithm L value of the length of the string of the local sensitive hash value X, YL is the logarithm L value of the length of the string of the local sensitive hash value Y, Xq 1_ratio is the 16-bit number q corresponding to the local sensitive hash value X 1_ratio The value of Yq 1_ratio is the 16-bit number q corresponding to the local sensitive hash value Y 1_ratio The value of Xq 2_ratio is the 16-bit number q corresponding to the local sensitive hash value X 2_ratio The value of Yq 2_ratio is the 16-bit number q corresponding to the local sensitive hash value Y 2_ratio The value of

[0052] Step 4.2.2: Then calculate the checksum distance of the two locality sensitive hash values ​​X and Y: if the checksums of X and Y are equal, the checksum distance is 0, otherwise the checksum distance is 1;

[0053] Step 4.2.3: Further optimize the values ​​of the above four distances respectively. The optimization formula is as follows:

[0054]

[0055] Among them, diff is the original value of each distance, and diff' is the corresponding optimized value;

[0056] Step 4.2.4: Add up the four optimized values ​​obtained after optimization in step 4.2.3 to get the distance between the heads of the local sensitive hash values ​​X and Y;

[0057] Step 4.3: Calculate the distance between two locality sensitive hash values ​​X and Y:

[0058] The 256 binary bits of the two local sensitive hash values ​​X and Y are divided into 128 groups from left to right, and the binary of each group is represented by b0b1; if the b0b1 of X and Y are not equal, the distance calculation is performed according to formula (6), otherwise the distance of the group is 0. Finally, the distance corresponding to each group of X and Y is accumulated to obtain the distance between the subjects;

[0059]

[0060] Step 4.4: The sum of the distance between the heads of the two local sensitive hash values ​​X and Y and the distance between the bodies is the TLSH distance between the two local sensitive hash values ​​X and Y.

[0061] Optionally, this embodiment selects 80% of the malware from the CICMalDorid2020 dataset, extracts the permission feature file and obtains the corresponding string, and then uses the local sensitive hash method to calculate the corresponding local sensitive hash value, removes samples that fail to extract and have too few permissions to generate local sensitive hash values, and collects a total of 10,562 data and stores them on the blockchain. The remaining 20% ​​of malware, 2,512 pieces, and another 3,986 benign software are used as test sets.

[0062] The result of matching the local sensitive hash value of the software under test with the local sensitive hash value of the malware stored on the chain is the distance value between [0, N], where 0 means they are basically identical, and the larger the value of N, the greater the difference between the two. Five experiments were conducted with the distance thresholds set to 0, 50, 100, 150, and 200, respectively, to indicate the similarity between the software under test and the malware in the blockchain environment. If the distance threshold is less than the set distance threshold, the software under test is identified as malware, otherwise, step 6 is executed for secondary detection. Figure 2 It shows that when different distance thresholds are set, the indicators of on-chain matching are quite different. When the distance threshold gradually increases, the overall performance of each indicator gets better and better. Among the four indicators, Precision has the best overall performance, all above 85%. Recall and F1-Score have large changes, between 20% and 90%. Overall, when the distance threshold is set to 150, the effect is the best, with an accuracy of 93.56%.

[0063] Malware family refers to a collection of malware with the same attack behavior. The proposed local sensitive hashing method is used to classify Android malware families. The dataset selects the top six categories with the largest number in Drebin: FakeInstaller, DroidKungFu, Plankton, Opfake, GinMaster, and BaseBridge, and classifies the malware families on the chain. The results are shown in the figure below. Figure 3 As shown, it is demonstrated that the malware detection method based on blockchain and local sensitive hashing of the present invention has better results in malware family classification.

[0064] Step 5: Based on federated learning technology, each malware detection node jointly trains a malware detection model and uses the malware detection model to perform secondary detection on the software to be tested to improve the detection success rate.

[0065] When the local sensitive hashing method fails to quickly identify the maliciousness of unknown software (i.e., the software to be tested), each malware detection node uses federated learning for further detection. When the software to be tested is detected as malware, the local sensitive hash value of the software to be tested is stored in the blockchain environment.

[0066] Step 5.1, Initialization: First, set up a reliable central server to randomly initialize the malware detection model parameters;

[0067] Step 5.2, federated training: The central server distributes the parameters to each malware detection node. Each malware detection node uses local data to train the model on the local device. During training, the stochastic gradient descent algorithm is used to minimize the loss function in the local training. After training, a local model is generated.

[0068] The Stochastic Gradient Descent (SGD) algorithm is used to minimize the loss function in local training, that is, the loss function of the local client model training is multiplied by a fixed learning rate η to calculate the new round of weight updates. Therefore, the model weight update of the local client is as follows:

[0069]

[0070] Among them, w t,k represents the value of the kth weight parameter at the tth iteration; w t-1,k Indicates the value of the kth weight parameter at the t-1th iteration; is the gradient of the kth component F with respect to weight w, indicating the gradient of F with respect to w k The partial derivative of , η represents the learning rate;

[0071] Step 5.3, model update: Each malware detection node sends the local model parameters (weights) on the local device back to the central server. The central server collects the parameters of all local models and aggregates them into the latest model parameters using the FedAvg method.

[0072] The model aggregation update formula of the central server in round t is as follows:

[0073]

[0074] Among them, w t represents the model aggregation parameter of the central server in round t, w t,k Indicates the value of the kth weight parameter at the tth iteration, n k represents the total number of samples of the kth node, and n represents the total number of samples of all nodes;

[0075] Step 5.4: Repeat steps 5.2 and 5.3 until the predetermined number of training rounds is reached. The training goal of this process is to optimize the local model under privacy protection conditions to minimize its loss function. After training, the optimal local model is obtained. Each malware detection node uses the optimal local model to detect the software to be tested.

[0076] When each malware detection node fails to match the maliciousness of unknown software through the local sensitive hashing method, it can be detected through the model trained by federated learning to improve the accuracy of malware detection. At the same time, the detected new malware features are converted into local sensitive hash values ​​and updated to the blockchain environment.

[0077] The present invention can use DNN, XGBoost, SVM or LR algorithm combined with Fedavg algorithm for malware detection, namely FL-DNN, FL-XGBoost, FL-SVM, FL-LR. Specifically, DNN uses the deep learning framework PyTorch to train on each detection node, XGBoost independently trains an XGBoost model on each node, the SVM algorithm uses the scikit-learn library to train the SVM model on each node, and similarly LR also uses the scikit-learn library to train the LR model on each node. After each training round, each node sends its model parameters (or gradients) to the central server. After receiving the model parameters from each node, the central server uses the FedAvg algorithm to aggregate these parameters. The experiment set 5, 10, and 15 malware detection nodes respectively, and the federated learning performed 35 rounds of iterations. With the increase of iteration rounds, the model performance also improves. As Figure 4As shown in the figure, the performance of FL-DNN is always better than other methods, with the highest detection accuracy reaching 97.87%. The detection accuracy of FL-XGBoost can also reach up to 97.18%.

[0078] The present invention implements a solution for securely storing and accessing malware features in an open and interconnected environment. In this solution, malware features can not only be accessed at high speed, but also protected by IPFS and authorization mechanisms. In addition, the unique file hash value corresponding to the malware is encrypted and stored on the blockchain. As shown in Table 2, the functions of uploading, viewing, and downloading feature files on the blockchain, as well as the node access blockchain permissions, were tested respectively.

[0079] Table 2 System test scenarios and reports

[0080]

[0081]

[0082] The blockchain-based malware detection method proposed in the present invention combines blockchain and local sensitive hashing technology, improves the timeliness of malware detection, and promotes malware information sharing. It solves the trust problem between malware detection agencies through blockchain, and uses smart contracts to jointly maintain the malware database to achieve malware information sharing. In terms of detection, firstly, local sensitive hashing technology is used to achieve rapid matching of malware on the chain and timely reduce the impact of malware. Secondly, each node on the blockchain uses federated learning to jointly train the detection model, and conducts secondary detection on the software that fails to match maliciousness on the chain to improve the detection effect.

[0083] The technical features of the above-described embodiments may be arbitrarily combined. To make the description concise, not all possible combinations of the technical features in the above-described embodiments are described. However, as long as there is no contradiction in the combination of these technical features, they should be considered to be within the scope of this specification.

[0084] The above-mentioned embodiments only express several implementation methods of the present invention, and the descriptions thereof are relatively specific and detailed, but they cannot be understood as limiting the scope of the invention patent. It should be pointed out that, for ordinary technicians in this field, several variations and improvements can be made without departing from the concept of the present invention, and these all belong to the protection scope of the present invention. Therefore, the protection scope of the patent of the present invention shall be subject to the attached claims.

Claims

1. A malware detection method based on blockchain, characterized in that: The following steps are involved: Step 1: Perform static analysis on multiple known malware to obtain permission features, and sort the obtained permission features according to the dictionary to obtain a string corresponding to each malware; Step 2: Calculate the local sensitive hash value of each string; Step 3: Build a blockchain environment, deploy each malware detection node into the blockchain environment, and use smart contracts to store the local sensitive hash values ​​corresponding to each malware in the blockchain environment; Step 4: By writing a smart contract, each malware detection node uses the TLSH distance calculation formula to calculate the TLSH distance between the local sensitive hash value of the software under test and the local sensitive hash value of the malware stored on the chain, and takes the average of the two smallest TLSH distance values ​​as the final distance value between the software under test and the malware, and determines whether the calculated final distance value is less than the set distance threshold. If so, the software under test is determined to be malware, otherwise, execute step 5; Step 5: Based on the federated learning technology, each malware detection node jointly trains the malware detection model and performs secondary detection on the software to be tested, which specifically includes the following steps: Step 5.1, Initialization: Set up a reliable central server to randomly initialize the malware detection model parameters; Step 5.2, federated training: The central server distributes the parameters to each malware detection node. Each malware detection node uses local data for model training. During training, the stochastic gradient descent algorithm is used to minimize the loss function in the local training. After training, a local model is generated. Step 5.3, model update: Each malware detection node sends the local model parameters back to the central server. The central server collects the parameters of all local models and aggregates them into the latest model parameters using the FedAvg method. Step 5.4: Repeat steps 5.2 and 5.3 until the predetermined training rounds are reached and the optimal local model is obtained. Each malware detection node uses the optimal local model to detect the software to be tested. When the software to be tested is detected as malware, the local sensitive hash value of the software to be tested is stored in the blockchain environment.

2. The blockchain-based malware detection method according to claim 1, characterized in that: In step 1, each malware is statically analyzed using the get_permissions() method of the open source static analysis tool Androguard.

3. The blockchain-based malware detection method according to claim 1 or 2, characterized in that: Step 2 includes the following steps: Step 2.1: Use a sliding window of 5 bytes to process the string. The sliding window slides forward one byte each time. Suppose the content of the sliding window is ABCDE. Use Pearson Hash mapping to count the number of ABC, ABD, ABE, ACD, ACE, and ADE buckets respectively. Step 2.2: Define q1, q2, and q3 as follows: 75% of the buckets have a number >= q1; 50% of the buckets have a number >= q2; 25% of the buckets have a number >= q3; Step 2.3: Construct the header of the locality-sensitive hash, which consists of three bytes: the first byte is the checksum of the string; the second byte is the logarithm of the length of the string described by formula (1); the third byte consists of two 16-bit numbers q 1_ratio ,q 2_ratio The calculation method is shown in formula (2): Among them, len is the length of the string; Step 2.4: Construct the main part of the local sensitive hash: In the 128 mappings generated by Pearson Hash, each mapping is a key, and its corresponding value is the number of occurrences of the key; traverse each key and generate the corresponding binary bits according to formula (3), and finally obtain the main part hash value of 32 bytes: Among them, Value is the number of occurrences of the key; Step 2.5: Convert the header and body of the local sensitive hash into 70 hexadecimal digits to finally obtain the local sensitive hash value of the string.

4. The blockchain-based malware detection method according to claim 1 or 2, characterized in that: The process of calculating the TLSH distance in step 4 includes the following steps: Step 4.1: Define mod_diff(X,Y,R) as the minimum distance from X to Y in a circular queue of size R, that is: mod_diff(X,Y,R)=Min((XY)modR,(YX)modR) (4) Among them, X and Y are the local sensitive hash values ​​of the software under test and the malware stored on the chain respectively; Step 4.2: Calculate the distance between the heads of two locality sensitive hash values ​​X and Y: Step 4.2.1: Calculate the logarithm of the length of the string L and two 16-digit numbers q according to formula (4) 1_ratio and q 2_ratio Corresponding distances: mod_diff(XL,YL,256), mod_diff(Xq 1_ratio ,Yq 1_ratio ,256) and mod_diff(Xq 2_ratio ,Yq 2_ratio ,256); Step 4.2.2: Calculate the checksum distance of two locality-sensitive hash values ​​X and Y: if the checksums of X and Y are equal, the checksum distance is 0, otherwise the checksum distance is 1; Step 4.2.3: For the above four distances, mod_diff(XL,YL,256), mod_diff(Xq 1_ratio ,Yq 1_ratio ,256), mod_diff(Xq 2_ratio ,Yq 2_ratio ,256) and the distance of the checksum are further optimized, and the optimization formula is as follows: Among them, dif is the original value of each distance, and diff' is the corresponding optimized value; Step 4.2.4: Accumulate the four optimized values ​​obtained after optimization in step 4.2.3 to obtain the distance between the heads of the local sensitive hash values ​​X and Y; Step 4.3: Calculate the distance between the two locality sensitive hash values ​​X and Y: The 256 binary bits of the two local sensitive hash values ​​X and Y are divided equally into 128 groups from left to right. The binary bits of each group are represented by b0b1. If the b0b1 of X and Y are not equal, the distance is calculated according to formula (6). Otherwise, the distance of the group is 0. Finally, the distances corresponding to each group of X and Y are accumulated to obtain the distance between the subjects. Step 4.4: Sum the distance between the heads of the local sensitive hash values ​​X and Y and the distance between the bodies to obtain the TLSH distance between the local sensitive hash values ​​X and Y.

5. The blockchain-based malware detection method according to claim 1 or 2, characterized in that: Use the Ethereum client Geth to build the blockchain environment.

6. The blockchain-based malware detection method according to claim 1 or 2, characterized in that: In step 3, when the local sensitive hash value corresponding to each malware is stored in the blockchain environment using a smart contract, the local sensitive hash value is uploaded to IPFS using a smart contract, and the complete information is saved by the IPFS distributed storage layer, and the generated unique hash value IpfsHash is saved on the blockchain.

7. The blockchain-based malware detection method according to claim 1 or 2, characterized in that: The distance threshold is set to 150.

8. The blockchain-based malware detection method according to claim 1 or 2, characterized in that: The weight update formula of the local model is as follows: Among them, w t,k represents the value of the kth weight parameter at the tth iteration; w t-1,k Indicates the value of the kth weight parameter at the t-1th iteration; is the gradient of the kth component F with respect to weight w, indicating the gradient of F with respect to w k The partial derivative of , η represents the learning rate.

9. The blockchain-based malware detection method according to claim 1 or 2, characterized in that: The model aggregation update formula of the central server in round t is as follows: Among them, w t represents the model aggregation parameter of the central server in round t, w t,k Indicates the value of the kth weight parameter at the tth iteration, n k represents the total number of samples of the kth node, and n represents the total number of samples of all nodes.

10. The blockchain-based malware detection method according to claim 1 or 2, characterized in that: 80% of the malware was selected from the CICMalDorid2020 dataset. After extracting permission features and obtaining corresponding strings, the corresponding locally sensitive hash values ​​were calculated, and samples with failed extractions and too few permissions to generate locally sensitive hash values ​​were removed. A total of 10,562 data were collected and stored on the blockchain.

Images