Lightweight method and device for detecting arithmetic vulnerabilities in an ethereum smart contract
Patent Information
- Application Number
- CN202210771478.9
- Authority / Receiving Office
- CN · China
- Patent Type
- Patents(China)
- Current Assignee / Owner
- Filing Date
- 2022-06-30
- Publication Date
- 2026-08-28
- Estimated Expiration
- 2042-06-30
AI Technical Summary
[0004]本发明提供了一种轻量级以太坊智能合约算术漏洞检测方法及装置,解决相关技术中分析方法复杂繁琐,分析时间较长,硬件资源要求高的问题
Smart Images

Figure CN115344865B_ABST
Abstract
Description
Technical Field
[0001] This invention relates to the fields of deep learning and blockchain technology, and more specifically, to a lightweight method and apparatus for detecting arithmetic vulnerabilities in Ethereum smart contracts. Background Technology
[0002] Smart contracts primarily refer to a set of commitments defined in digital form. Each participant in the contract can execute these commitments according to the predetermined rules in the smart contract protocol. Due to their contractual nature, blockchain-based smart contracts have been applied to an increasing number of industries, such as supply chain, IoT, and finance. Arithmetic vulnerabilities refer to integer overflow problems in smart contracts. Integer calculations in smart contracts are often related to the transfer of digital assets. Attackers frequently exploit this vulnerability to steal assets.
[0003] Smart contract vulnerability detection is mainly divided into manual detection and automated detection. Currently, manual detection methods are gradually being phased out due to their low efficiency and inability to keep pace with the rapid development of smart contracts. Automated detection primarily involves formal analysis and symbolic analysis, but formal verification is inefficient, requiring technical personnel to develop smart contracts and perform formal modeling; some even require secondary verification. Symbolic execution is a popular program analysis technique mainly used to test whether software violates certain properties. Researchers Luu, Nikolic, and Tsankov, among others, have proposed symbolic analysis tools such as OYENTE, MAIAN, and Securify to detect vulnerabilities in smart contracts. Using symbolic analysis tools can effectively reduce the false positive rate and error rate in smart contract vulnerability detection, but the analysis methods are complex and cumbersome, the analysis time is long, and the hardware resource requirements are high. To address these issues, this application proposes a lightweight method and apparatus for detecting arithmetic vulnerabilities in Ethereum smart contracts. Summary of the Invention
[0004] This invention provides a lightweight method and device for detecting arithmetic vulnerabilities in Ethereum smart contracts, solving the problems of complex and cumbersome analysis methods, long analysis time, and high hardware resource requirements in related technologies.
[0005] In a first aspect, this application provides a lightweight Ethereum smart contract arithmetic vulnerability detection method, which uses a lightweight Ethereum smart contract arithmetic vulnerability detection model to detect whether a smart contract has arithmetic vulnerabilities, including: receiving the opcode of the smart contract, generating corresponding arithmetic vulnerability features based on the opcode of the smart contract, and performing vulnerability detection on the smart contract based on the arithmetic vulnerability features.
[0006] Furthermore, the lightweight Ethereum smart contract arithmetic vulnerability detection model includes at least a feature extraction part and a detection part. The feature extraction part includes a feature layer and an embedding layer, and the detection part includes a hidden layer and an attention layer. The feature extraction part is used to generate a corresponding vulnerability feature vector based on the opcode, and the detection part is used to perform vulnerability detection on the smart contract.
[0007] Furthermore, the feature layer is used to obtain the opcode of the smart contract and generate corresponding arithmetic vulnerability features based on the opcode; the embedding layer is used to perform one-hot encoding on the arithmetic vulnerability features and then perform feature vectorization to obtain vectorized arithmetic vulnerability features; the hidden layer is used to train the vectorized arithmetic vulnerability features using a long short-term memory network to obtain the training result; the attention layer is used to train the result of the hidden layer using an attention mechanism to obtain the arithmetic vulnerability detection result.
[0008] Furthermore, generating corresponding vulnerability features based on the opcode includes: processing the opcode differently according to the degree of correlation between the opcode and the arithmetic vulnerability, and generating corresponding vulnerability features.
[0009] Furthermore, the degree of correlation between the opcode and the arithmetic vulnerability includes: the opcode is directly related to the arithmetic vulnerability, the opcode is indirectly related to the arithmetic vulnerability, and the opcode is unrelated to the arithmetic vulnerability.
[0010] Furthermore, the step of processing the opcode differently based on its relevance to the arithmetic vulnerability includes: when the opcode is directly related to the arithmetic vulnerability, classifying the opcode directly as a vulnerability feature; when the opcode is indirectly related to the arithmetic vulnerability, obfuscating the opcode and obtaining the corresponding vulnerability feature; and when the opcode is unrelated to the arithmetic vulnerability, discarding the opcode that is unrelated to the arithmetic vulnerability.
[0011] Furthermore, the types of smart contract opcodes include: 0s, stop and arithmetic operations; 1s, comparison and bitwise logic operations; 20s, SHA3; 30s, context information; 40s, block information; 50s, stack, memory, storage and stream operations; 60s and 70s, push operations; 80s, copy operations; 90s, swap operations; a0s, record operations; f0s, system operations.
[0012] Furthermore, generating corresponding vulnerability features based on the opcodes includes processing 142 types of original smart contract opcodes to generate 28 vulnerability features.
[0013] Furthermore, based on the correspondence between the opcodes and vulnerability features, the opcodes corresponding to addition, multiplication, and subtraction operations are processed first.
[0014] Secondly, this application also provides a lightweight Ethereum smart contract arithmetic vulnerability detection device, characterized in that the device includes a memory and a processor, the memory is used to store a computer program, and when the computer program is executed by the processor, it implements the lightweight Ethereum smart contract arithmetic vulnerability detection method of the first aspect.
[0015] The lightweight Ethereum smart contract arithmetic vulnerability detection method provided in this invention obfuscates 142 original opcodes into a set of 28 vulnerability features. This method is then trained and tested using a Long Short-Term Memory (LSTM) network with an attention mechanism. Experimental results show that these vulnerability features outperform the original opcodes in detecting arithmetic vulnerabilities. Furthermore, the lightweight Ethereum smart contract arithmetic vulnerability model (HuntFlow) significantly reduces the detection time compared to traditional tools, requiring only 0.028 seconds per smart contract. The lightweight Ethereum smart contract arithmetic vulnerability detection method provided in this application can automatically detect arithmetic vulnerabilities in smart contracts on lightweight computers without expert knowledge. It exhibits excellent arithmetic vulnerability detection capabilities, higher accuracy, and, due to the reduction in model parameters, faster detection speed and minimal time consumption. Attached Figure Description
[0016] 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 some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.
[0017] Appendix Figure 1 A model diagram of a lightweight Ethereum smart contract arithmetic vulnerability detection model provided in an embodiment of the present invention; Appendix Figure 2 A schematic diagram of the unit structure of the Long Short-Term Memory network in the hidden layer of the lightweight Ethereum smart contract arithmetic vulnerability detection model provided in this embodiment of the invention; Appendix Figure 3 This is a structural diagram of the attention mechanism in the attention layer of the lightweight Ethereum smart contract arithmetic vulnerability detection model provided in this embodiment of the invention. Appendix Figure 4 This is a schematic diagram illustrating the statistical length of smart contract opcodes provided in an embodiment of the present invention; Appendix Figure 5 This is a schematic diagram illustrating the fuzzy opcode length statistics provided in an embodiment of the present invention; Appendix Figure 6 A schematic diagram of the structure of a lightweight Ethereum smart contract arithmetic vulnerability detection device provided in an embodiment of the present invention. Detailed Implementation
[0018] The technical solutions in 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.
[0019] The inventors' research revealed that current methods of manually detecting smart contract vulnerabilities are inefficient and unable to keep pace with the rapid development of smart contracts, and are gradually being phased out. Automated detection, particularly formal verification, requires technical personnel to develop smart contracts and formal model them; some even require secondary verification, resulting in low efficiency. Using symbolic analysis tools to detect vulnerabilities in smart contracts is complex, time-consuming, and requires significant hardware resources.
[0020] To address the aforementioned issues, this application proposes a lightweight Ethereum smart contract arithmetic vulnerability detection method. This method uses a lightweight Ethereum smart contract arithmetic vulnerability detection model (called HuntFlow) to detect whether a smart contract has arithmetic vulnerabilities. The input to this method is the smart contract's opcode. The method includes: receiving the smart contract's opcode, generating corresponding arithmetic vulnerability features based on the smart contract's opcode, and performing vulnerability detection on the smart contract based on the arithmetic vulnerability features.
[0021] In one implementation, the lightweight Ethereum smart contract arithmetic vulnerability detection model (HuntFlow) is structured as follows: Figure 1As shown, HuntFlow includes at least a feature extraction part and a detection part. The feature extraction part generates corresponding vulnerability features based on the opcode, and the detection part performs vulnerability detection on the vulnerability features. The feature extraction part mainly includes a feature layer and an embedding layer, while the detection part includes a hidden layer and an attention layer. The feature layer receives the input smart contract opcode and extracts arithmetic vulnerability features from it, then inputs these features into the embedding layer. Upon receiving the arithmetic vulnerability features, the embedding layer first performs one-hot encoding, then uses a dense matrix for feature vectorization, and finally inputs the vectorized arithmetic vulnerability features into the hidden layer. The hidden layer uses a Long Short-Term Memory (LSTM) network. After receiving the arithmetic vulnerability feature vector from the embedding layer, it trains and outputs the network, then passes the output to the attention layer. Upon receiving the input from the hidden layer, the attention layer uses an attention mechanism to train the input and finally outputs the vulnerability detection result.
[0022] In smart contracts, an 8-bit representation space is allocated for opcodes, denoted by 0x00 to 0xff. Theoretically, there can be 256 opcodes, but currently only 142 are available. Therefore, this application previously analyzed the relationship between smart contract arithmetic vulnerabilities and opcodes, and implemented a fuzzy representation of smart contract opcodes. The 142 opcodes are obfuscated into 28 vulnerability feature sets, reducing model parameters and resulting in faster detection speed and higher accuracy.
[0023] In one implementation, the feature extraction section is used to obfuscate 142 original opcodes into a set of 28 vulnerability features based on the characteristics of the arithmetic vulnerability.
[0024] In one implementation, the vulnerability detection component consists of a Long Short-Term Memory (LSTM) network with an attention mechanism, which is used for training and vulnerability detection of the vulnerability features.
[0025] In one implementation, the hidden layer of the detection part of the lightweight Ethereum smart contract arithmetic vulnerability detection model is mainly composed of an LSTM network, which is made up of multiple identical cell units connected together. Each LSTM cell unit contains three gates: a forget gate, an input gate, and an output gate, as well as an information transmission band for transmitting the states of each cell. This information transmission band solves the problem of long-term dependencies, ensuring that earlier inputs are not forgotten. The cell structure in LSTM is as follows: Figure 2 As shown, each cell contains a storage unit. Its main purpose is long-term storage and transmission of information. It is the output of the current unit and the input of the next unit. Forget gate. It combines the current input with the previous state of the cell unit. The information has already determined whether the current information should be forgotten or retained. (Input gate) The current input can be updated to the cell state; the output gate... This controls the output of the current state. Each of the three gate functions has its own weight vector and bias vector. The function definitions of the LSTM network are shown in equations (1) to (6).
[0026] (1) (2) (3) (4) (5) (6) In the above formula Indicates the input gate function. Represents the forget gate function. Indicates the output gate function. In cellular state, For cell output, The weight matrix for the initial random test. For bias vectors, It is a hyperbolic function. Element-wise multiplication.
[0027] In one implementation, the attention layer of the detection part of the lightweight Ethereum smart contract arithmetic vulnerability detection model receives input from the hidden layer, trains the input using an attention mechanism, and finally outputs a vulnerability detection result. For example... Figure 3 As shown, the attention mechanism structurally resembles a single-layer perceptron, treating the input data as (K, V) key-value pairs. The ultimate goal is to calculate the weighted sum of V values using the K values. The detailed structure of the attention model is shown in the figure, and the formula for the attention weight coefficient matrix W is shown in (7): (7) The final output can be obtained by performing a dot product (weighted summation) operation between the attention weight coefficient matrix W and the V values, as shown in Equation 1 (8): (8) In one implementation, the types of smart contract opcodes include: 0s, stop and arithmetic operations; 1s, comparison and bitwise logic operations; 20s, SHA3; 30s, context information; 40s, block information; 50s, stack, memory, storage and stream operations; 60s and 70s, push operations; 80s, copy operations; 90s, swap operations; a0s, record operations; and f0s, system operations.
[0028] In the above classification, the 0s and 1s parts represent opcodes for arithmetic calculations. Arithmetic vulnerabilities in Ethereum smart contracts are mainly categorized into integer overflow and integer underflow vulnerabilities. Although Ethereum has a SafeMath library to prevent arithmetic vulnerabilities, in reality, many smart contracts that have passed security audits still contain numerous integer vulnerabilities. Arithmetic vulnerabilities are primarily caused by addition, multiplication, and subtraction operations. The 0x01, 0x02, and 0x03 opcodes in smart contract opcodes correspond to addition, multiplication, and subtraction operations, respectively, and are therefore the parts to focus on.
[0029] In one implementation, based on the correspondence between opcodes and vulnerability features, opcodes corresponding to addition, multiplication, and subtraction operations are processed first. For example, opcodes 0x01, 0x02, and 0x03 in smart contract opcodes correspond to addition, multiplication, and subtraction operations, so they are the parts of focus.
[0030] In one implementation, when generating corresponding vulnerability features based on the opcodes, the opcodes can be first classified, and then the opcodes can be operated on according to their classifications to generate corresponding vulnerability features. For example, the opcodes can be classified according to their correlation with arithmetic vulnerabilities. Specifically, the correlation between the opcodes and arithmetic vulnerabilities can be divided as follows: the opcode is directly related to the arithmetic vulnerability, the opcode is indirectly related to the arithmetic vulnerability, and the opcode is unrelated to the arithmetic vulnerability.
[0031] In one implementation, opcodes can be processed differently based on their classification. Specifically, when an opcode is directly related to the arithmetic vulnerability, it is directly classified as a vulnerability feature; when an opcode is indirectly related to the arithmetic vulnerability, it is obfuscated to obtain the corresponding vulnerability feature; and when an opcode is unrelated to the arithmetic vulnerability, it is discarded.
[0032] For example, firstly, opcodes considered directly related to arithmetic vulnerabilities are directly classified as features. Therefore, opcodes 0x01~0x1d and 0x50 can be directly classified as features without any processing. Then, opcodes considered indirectly related to arithmetic vulnerabilities can be obfuscated to obtain corresponding features. Thus, opcodes 0x60~0x7f, 0x80~0x8f, and 0x90~0x9f can be obfuscated to obtain corresponding features. Finally, opcodes considered unrelated to arithmetic vulnerabilities are discarded. Therefore, opcodes corresponding to 0x00, 0x20~0x4f, 0x51~0x5f, and 0xa0~0xff are discarded. Table 1 shows the correspondence between smart contract opcodes and features.
[0033] Table 1: Correspondence between Smart Contract Opcodes and Features
[0034] Figure 4 and Figure 5 The figures show the statistics for smart contract opcode length and fuzzy opcode length. As can be seen from the figures, the length of smart contract opcodes in the dataset is mainly concentrated around 1200, while the length of fuzzy opcodes is mainly concentrated around 900. LSTM networks can focus their attention mechanism on the entire partial sequence; their cell states contain an information transmission band, thus solving the long-term dependency problem and preventing the forgetting of earlier inputs. The attention mechanism can evaluate the correlation between different elements in the sequence and select information deemed more critical to the target. In the experiments of this application, we aim to use the attention mechanism to make the network pay more attention to opcodes 0x01, 0x02, and 0x03, which are more relevant to arithmetic vulnerabilities.
[0035] The applicant of this invention has further analyzed and verified the present technical solution through experiments. Specifically, as follows: Datasets and experimental environments This application focuses on Ethereum smart contracts written in Solidity. The model in this application was tested on a dataset containing nearly 45,000 smart contracts provided in the paper (Empirical review of automated analysis tools on 47,587 Ethereum smart contracts). In this application, label=0 indicates no vulnerabilities, and label=1 indicates vulnerabilities.
[0036] The paper (Empirical review of automated analysis tools on 47,587 Ethereumsmart contracts) uses tools such as Mythril, Slither, and Smartcheck to verify the dataset and add vulnerability labels. This application randomly selects 80% of the contracts as the training dataset and 20% as the test dataset. The number of arithmetic vulnerabilities in the dataset is shown in Table 2.
[0037] Table 2. Number of vulnerabilities in the dataset
[0038] Evaluation indicators This application uses Accuracy and F1-score metrics to evaluate its detection performance. Accuracy is a metric for classifying models. F1-score is a metric used in statistics to measure the accuracy of binary (or multi-task binary) models, which considers both the accuracy and recall of the classification model. Formulas (9) to (12) are the formulas for calculating Accuracy and F1-score.
[0039] (9) (10) (11) (12) Experimental results This application puts the opcodes into three models for testing: HuntFlow, LSTM with attention mechanism, and classification network built by Transformer.
[0040] Table 3 presents the test results for the three models. As can be seen from Table 3, HuntFlow outperforms LSTM and Transformer, while LSTM outperforms Transformer.
[0041] Table 3 Experimental Results
[0042] In the paper (Empirical review of automated analysis tools on 47,587 Ethereum smart contracts), the authors used three servers with 32 vCPUs and 30GB of RAM to run Mythril, Slither, Smartcheck, and OYENTE on the dataset. The results showed that Slither took an average of 5 seconds to analyze each smart contract, Smartcheck took an average of 10 seconds, OYENTE took an average of 30 seconds, and Mythril took an average of 64 seconds to analyze each smart contract. This application uses a lightweight computer with an i5 processor with 16GB of RAM and a GeForce GTX 1080 Ti with 12GB of RAM to run HuntFlow on the dataset. Experimental results show that HuntFlow requires fewer resources and can significantly reduce detection time. Detecting each smart contract in the dataset takes an average of approximately 0.028 seconds. Table 4 shows the runtime of some tools and HuntFlow.
[0043] Table 4. Running Time
[0044] in conclusion Arithmetic Vulnerability Characteristics By analyzing the characteristics of arithmetic vulnerabilities in smart contracts, this application obfuscates 142 primitive opcodes into a set of 28 vulnerability features. As shown in Table 3, the experimental results demonstrate that HuntFlow's detection accuracy is higher than LSTM and Transformer. Furthermore, the arithmetic vulnerability features accurately describe smart contract arithmetic vulnerabilities while reducing the number of opcode categories, resulting in fewer network parameters and a smaller model.
[0045] As shown in Table 3, HuntFlow outperforms the other two models in detection accuracy and F1-score, while Transformer has the worst accuracy and F1-score. Based on the image classification results of Vision Transformer (An image is worth 16x16 words: Transformers for image recognition at scale), this application speculates that the poor performance of Transformer is due to its requirement for a large dataset, while the dataset in this application is too small.
[0046] As shown in Table 4, HuntFlow significantly reduces vulnerability detection time compared to traditional tools. In experiments, this application ran HuntFlow on a lightweight computer, and detecting each smart contract in the dataset took an average of approximately 0.028 seconds. This application believes the reason is that HuntFlow only detects trained arithmetic vulnerabilities, and cannot detect unknown vulnerabilities that have not been trained.
[0047] This application proposes a lightweight smart contract arithmetic vulnerability detection model, called HuntFlow, which can automatically detect smart contract vulnerabilities on lightweight computers. HuntFlow first obfuscates 142 primitive opcodes into a set of 28 vulnerability features, and then uses an LSTM network with an attention mechanism for detection. Experimental results show that HuntFlow has good arithmetic vulnerability detection capabilities and is extremely time-efficient.
[0048] Figure 6 This is a schematic diagram of the structure of a lightweight Ethereum smart contract arithmetic vulnerability detection device provided in an embodiment of the present invention.
[0049] In this embodiment, the lightweight Ethereum smart contract arithmetic vulnerability detection device includes a memory and a processor. The memory is used to store a computer program, and when the computer program is executed by the processor, it implements the lightweight Ethereum smart contract arithmetic vulnerability detection method described in the first aspect.
[0050] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention, and not to limit them; although the present invention has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features; and these modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of the present invention.
Claims
1. A lightweight method for detecting arithmetic vulnerabilities in Ethereum smart contracts, characterized in that, The method of using a lightweight Ethereum smart contract arithmetic vulnerability detection model to detect whether a smart contract has arithmetic vulnerabilities includes: receiving the opcode of the smart contract, generating corresponding arithmetic vulnerability features based on the opcode of the smart contract, and performing vulnerability detection on the smart contract based on the arithmetic vulnerability features; The lightweight Ethereum smart contract arithmetic vulnerability detection model uses an LSTM network with an attention mechanism for vulnerability detection. The LSTM network focuses on opcodes related to arithmetic vulnerabilities, and prioritizes opcodes corresponding to addition, multiplication and subtraction operations based on the correspondence between the opcodes and vulnerability features. The lightweight Ethereum smart contract arithmetic vulnerability detection model includes at least a feature extraction part and a detection part. The feature extraction part includes a feature layer and an embedding layer, and the detection part includes a hidden layer and an attention layer. The feature layer is used to obtain the opcode of the smart contract and generate corresponding arithmetic vulnerability features based on the opcode. The embedding layer is used to perform one-hot encoding on the arithmetic vulnerability features, and then perform feature vectorization to obtain the vectorized arithmetic vulnerability features. The hidden layer is used to train the vectorized arithmetic vulnerability features using a long short-term memory network to obtain the trained result; The attention layer is used to train the results of the hidden layer using an attention mechanism to obtain arithmetic vulnerability detection results.
2. The lightweight Ethereum smart contract arithmetic vulnerability detection method as described in claim 1, characterized in that, The feature extraction section is used to generate corresponding vulnerability features based on the opcode, and the detection section is used to perform vulnerability detection on the vulnerability features.
3. The lightweight Ethereum smart contract arithmetic vulnerability detection method as described in claim 1, characterized in that, The step of generating corresponding vulnerability features based on the opcode includes: processing the opcode differently according to the degree of correlation between the opcode and the arithmetic vulnerability, and generating corresponding vulnerability features.
4. The lightweight Ethereum smart contract arithmetic vulnerability detection method as described in claim 3, characterized in that, The degree of correlation between the opcode and the arithmetic vulnerability includes: the opcode is directly related to the arithmetic vulnerability, the opcode is indirectly related to the arithmetic vulnerability, and the opcode is unrelated to the arithmetic vulnerability.
5. The lightweight Ethereum smart contract arithmetic vulnerability detection method as described in claim 4, characterized in that, The step of processing the opcode differently based on its correlation with the arithmetic vulnerability includes: When the opcode is directly related to the arithmetic vulnerability, the opcode is directly classified as a vulnerability feature; When the opcode is indirectly related to the arithmetic vulnerability, the opcode is obfuscated to obtain the corresponding vulnerability feature; When the opcode is irrelevant to the arithmetic vulnerability, the opcode that is irrelevant to the arithmetic vulnerability is discarded.
6. The lightweight Ethereum smart contract arithmetic vulnerability detection method as described in claim 1, characterized in that, The types of smart contract opcodes include: 0s, stop and arithmetic operations; 1s, comparison and bitwise logic operations; 20s, SHA3; 30s, context information; 40s, block information; 50s, stack, memory, storage and stream operations; 60s and 70s, push operations; 80s, copy operations; 90s, swap operations; a0s, record operations; f0s, system operations.
7. The lightweight Ethereum smart contract arithmetic vulnerability detection method as described in claim 1, characterized in that, The generation of corresponding vulnerability features based on the opcodes includes: processing 142 types of original smart contract opcodes to generate 28 vulnerability features.
8. A lightweight Ethereum smart contract arithmetic vulnerability detection device, characterized in that, The device includes a memory and a processor, the memory being used to store a computer program, which, when executed by the processor, implements the lightweight Ethereum smart contract arithmetic vulnerability detection method as described in any one of claims 1 to 7.