Attack detection method and apparatus

Abstract

Embodiments of the present specification provide an attack detection method and device. The method comprises: before software is released, simulating loading software code of the software into a first memory; performing normalization processing on the software code in the first memory, and calculating a first feature value of the software code after the normalization processing; after the software is released, after detecting that the software code of the software is read from a disk of an electronic device into a second memory of the electronic device, performing normalization processing on the software code in the second memory, and calculating a second feature value of the software code after the normalization processing; and determining whether the first feature value and the second feature value are the same, and if not, determining that an attack behavior occurs currently to the software in the electronic device. Embodiments of the present specification can detect whether an attack behavior occurs to software code in a memory after the software code is read into the memory.

Description

Technical Field

[0001] This specification relates to computer technology in one or more embodiments, and more particularly to attack detection methods and apparatus. Background Technology

[0002] Electronic devices are loaded with various software programs to perform various functions. In the current network environment, malicious samples frequently attack the software loaded on electronic devices to modify its normal operating logic, such as bypassing permission checks, intercepting passwords, and so on, thereby achieving various purposes. Therefore, it is necessary to detect the attack behavior of malicious samples in order to take timely and appropriate measures to prevent attacks.

[0003] Currently, it's possible to verify the signatures of software code stored on the hard drive of electronic devices, thus detecting whether the software has been attacked. However, many attacks don't target the software code on the hard drive, but rather attack the code in memory after it's been read from the hard drive. Currently, there are no effective methods to detect this type of attack on in-memory software code, making it impossible to prevent such attacks. Summary of the Invention

[0004] This specification describes an attack detection method and apparatus through one or more embodiments, which can detect whether an attack has occurred against the software code in memory after the software code has been read into memory.

[0005] According to the first aspect, an attack detection method is provided, wherein the method includes:

[0006] Before the software is released, the software code is simulated and loaded into the first memory.

[0007] The software code in the first memory is normalized, and the first feature value of the normalized software code is calculated.

[0008] After the software is released, when it is detected that the software code of the software is read from the disk of the electronic device into the second memory of the electronic device, the software code in the second memory is normalized, and the second feature value of the normalized software code is calculated.

[0009] Determine whether the first feature value and the second feature value are the same. If they are not the same, it is determined that an attack has occurred against the software in the electronic device.

[0010] The normalization process for the software code in the first memory includes: assuming the base address of the first memory as a preset base address; correcting the import table used during simulated loading according to the preset base address; and correcting the software code in the first memory according to the preset base address based on the relocation table used during simulated loading.

[0011] The normalization process for the software code in the second memory includes: assuming the base address of the second memory as a preset base address; correcting the import table of the electronic device according to the preset base address; and correcting the software code in the second memory according to the preset base address based on the relocation table used by the electronic device.

[0012] Specifically, before the software is released, after calculating the first feature value, the process further involves: signing the first feature value using the private key in a pre-set public-private key pair; carrying the signature data at a designated location in the software code of the software; and then releasing the software code carrying the signature data to the electronic device.

[0013] After the software is released, before determining whether the first feature value and the second feature value are the same, the method further includes: obtaining signature data from the specified location of the software code of the released software, verifying the signature data using the public key in the pre-set public-private key pair, thereby obtaining the first feature value.

[0014] The software is in the PE file format of the Windows system.

[0015] The specified location includes: the data gaps in the software code defined by the Windows PE structure.

[0016] Specifically, after the software code of the software is read into the second memory of the electronic device, whenever a trigger event is detected, the steps of "normalizing the software code in the second memory, calculating the second feature value of the normalized software code, and determining whether the first feature value and the second feature value are the same" are executed.

[0017] The triggering event includes at least one of the following:

[0018] The reading operation of the software code being read into the second memory of the electronic device has ended;

[0019] The timer reaches the preset time period length;

[0020] The software triggers predetermined key operations while running on the electronic device.

[0021] The key operations include at least one of the following: entering a password, entering the payment page, and transferring funds.

[0022] According to the second aspect, an attack detection device is provided, wherein the device includes:

[0023] Before the software is released, the software code is simulated and loaded into the first memory.

[0024] The software code in the first memory is normalized, and the first feature value of the normalized software code is calculated.

[0025] The detection module is configured to detect whether the software code of the software has been read from the disk of the electronic device into the second memory of the electronic device after the software is published to the electronic device;

[0026] The normalization processing module is configured to normalize the software code in the second memory;

[0027] The calculation module is configured to calculate the second feature value of the normalized software code;

[0028] The judgment module is configured to determine whether a first feature value and a second feature value are the same. If they are not the same, it is determined that an attack has occurred against the software in the electronic device. The method for obtaining the first feature value is as follows: before the software is released, the software code of the software is simulated and loaded into the first memory; the software code in the first memory is normalized, and the first feature value of the normalized software code is calculated.

[0029] According to a third aspect, a computer-readable storage medium is provided having a computer program stored thereon that, when executed in a computer, causes the computer to implement the methods described in any embodiment of this specification.

[0030] According to a fourth aspect, a computing device is provided, including a memory and a processor, wherein the memory stores executable code, and the processor, when executing the executable code, implements the method described in any embodiment of this specification.

[0031] The attack detection methods and apparatuses provided in the embodiments of this specification have at least the following beneficial effects:

[0032] 1. Before software release, the process of loading the software into memory is simulated, and the simulated software code is normalized to prevent changes in the memory storage structure caused by runtime. After release, when the software is run and its code is read into the electronic device's memory, normalization is performed again to prevent changes in the memory storage structure caused by runtime. In other words, because of the normalization, the address at which the software was loaded into memory before release is the same as the address at which it is loaded into memory after release. Since the memory address is the same, the characteristic value of the software code in memory before release should be the same as the characteristic value of the unattacked software code in memory after release. The method in this specification utilizes the above principles and processing methods to ensure effective detection of attacks on software code in memory.

[0033] 2. In the embodiments of this specification, the signature data can be directly stored in the section data of the software code, that is, in the data gaps of the software code defined by the Windows PE structure. In other words, the signature data and the software code as a PE file are integrated, which not only improves the concealment of the signature information, but also enables one-time reading and verification during the loading into memory, which is both efficient and secure. Attached Figure Description

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

[0035] Figure 1 This is a schematic diagram of the system architecture used in one embodiment of this specification.

[0036] Figure 2 This is a flowchart of an attack detection method in one embodiment of this specification.

[0037] Figure 3 This is a flowchart of an attack detection method in another embodiment of this specification.

[0038] Figure 4 This is a schematic diagram of the attack detection device in one embodiment of this specification. Detailed Implementation

[0039] The solution provided in this specification will now be described with reference to the accompanying drawings.

[0040] First, it should be noted that the terminology used in the embodiments of this invention is for the purpose of describing specific embodiments only and is not intended to limit the invention. The singular forms “a,” “the,” and “the” used in the embodiments of this invention and the appended claims are also intended to include the plural forms, unless the context clearly indicates otherwise.

[0041] It should be understood that the term "and / or" used in this article is merely a description of the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A existing alone, A and B existing simultaneously, and B existing alone. Additionally, the character " / " in this article generally indicates that the preceding and following related objects have an "or" relationship.

[0042] To facilitate understanding of the methods provided in this manual, the system architecture involved and applicable to this manual is first described. For example... Figure 1 As shown, the system architecture mainly includes two types of network nodes: publishers and electronic devices. Publishers are the parties that distribute the software for users to download and use. Electronic devices can download the software from the publishers and thus use the functions provided by the software.

[0043] Electronic devices can be any device with memory and processing capabilities, including but not limited to: smart mobile terminals, smart home devices, network devices, wearable devices, smart medical devices, and PCs (personal computers). Smart mobile devices can include mobile phones, tablets, laptops, PDAs (personal digital assistants), and connected cars. Smart home devices can include smart appliances such as smart TVs, smart air conditioners, smart water heaters, smart refrigerators, and smart air purifiers. Smart home devices can also include smart door locks, smart sockets, smart lights, and smart cameras. Network devices can include switches, wireless access points (APs), and servers. Wearable devices can include smartwatches, smart glasses, smart bracelets, virtual reality devices, augmented reality devices, and mixed reality devices (devices that support both virtual and augmented reality). Smart medical devices can include smart thermometers, smart blood pressure monitors, and smart blood glucose meters.

[0044] It should be understood that Figure 1 The number of publishers and electronic devices shown is merely illustrative. Any number can be selected and deployed as needed.

[0045] Figure 2 This is a flowchart of an attack detection method in one embodiment of this specification. It is understood that this method can also be executed by any device, equipment, platform, or cluster of devices with computing and processing capabilities. See also... Figure 2The method includes:

[0046] Step 201: Before the software is released, the software code is simulated and loaded into the first memory.

[0047] Step 203: Normalize the software code in the first memory and calculate the first feature value of the normalized software code.

[0048] Step 205: After the software is released, it is detected that the software code of the software is read from the disk of the electronic device into the second memory of the electronic device.

[0049] Step 207: Normalize the software code in the second memory and calculate the second feature value of the normalized software code.

[0050] Step 209: Determine whether the first feature value and the second feature value are the same. If they are not the same, proceed to step 211. If they are the same, proceed to step 213.

[0051] Step 211: Determine that an attack has occurred against the software in the electronic device.

[0052] Step 213: Determine that no attack has occurred against the software in the electronic device.

[0053] In electronic devices, the storage structure of software code files differs between disk and memory. When software code files are stored on disk, their storage structure remains static, allowing for verification simply by reading the code byte-by-byte from the disk. However, in the memory of an electronic device, the storage structure of data changes every time the device runs, and the dynamic changes after software code is loaded into memory cannot be predicted in advance. This makes it impossible to perform security verification on software code in memory using existing technologies. (See the above...) Figure 2The process described in this embodiment involves simulating the loading of the software into memory before software release, and then normalizing the simulated software code to prevent changes in the memory storage structure caused by runtime. Similarly, after software release, when the software is loaded into the electronic device's memory, a similar normalization process is performed to prevent changes in the memory storage structure caused by runtime. In other words, because of the normalization process, the address at which the software is loaded into memory before release is the same as the address at which it is loaded into memory after release. Since these memory addresses are the same, the characteristic values ​​of the software code in memory before release should be the same as the characteristic values ​​of the un-attacked software code in memory after release. Figure 2 The method described in the embodiments of this specification utilizes the above-mentioned principles and processing methods to ensure that attack behaviors of software code in memory can be detected, and then corresponding attack prevention processing can be carried out, such as terminating the operation of the software or repairing the software.

[0054] The above will be explained below with reference to the accompanying drawings. Figure 2 Each step shown is performed separately.

[0055] First, regarding step 201: Before the software is released, the software code is simulated and loaded into memory, which may be referred to as the first memory.

[0056] As mentioned earlier, the data in memory changes every time the memory is used. Therefore, in order to perform security verification on the software code loaded into the memory of the electronic device after subsequent software releases, this step 201 can be performed.

[0057] Next, for step 203: normalize the software code in the first memory and calculate the first feature value of the normalized software code.

[0058] In the embodiments of this specification, the normalization process serves to shield against changes in the storage structure of data in memory during runtime, ensuring that each memory location used is corrected based on the same base address. Subsequently, comparing the software code in each memory location, such as through signing and verification, allows for the verification of whether the software code has been modified.

[0059] In one embodiment of this specification, the specific implementation process of step 203 may include: assuming the base address of the first memory to be a preset base address, such as 0x1000; correcting the import table used during simulated loading according to the preset base address, such as 0x1000; and correcting the software code in the first memory according to the preset base address, such as 0x1000, based on the relocation table used during simulated loading.

[0060] The import table is used to import / reference functions from other functional modules; it can be understood as multiple lists. The relocation table is used to correct memory addresses when the program is loaded into memory.

[0061] In step 203, after normalization, the address of the software code in the first memory is essentially corrected based on a preset base address. A characteristic value, such as the first characteristic value, is then calculated for the normalized and corrected software code. Here, the characteristic value can be the hash value of the software code.

[0062] To further enhance security, in one embodiment of this specification, signature processing can be performed after step 203, such as the processing described in step 204 below:

[0063] Step 204: Sign the first feature value using the private key in the pre-set public-private key pair; then carry the signature data to a specified location in the software code of the software, and then release the software code carrying the signature data to the electronic device.

[0064] Next, for step 205: After the software is published to the electronic device, it is detected that the software code of the software is read from the disk of the electronic device into the memory of the electronic device (referred to as the second memory).

[0065] Next, for step 207: normalize the software code in the second memory and calculate the second feature value of the normalized software code.

[0066] In step 207, the process of normalizing the software code in the second memory includes: assuming the base address of the second memory to be a preset base address, such as 0x1000; correcting the import table of the electronic device according to the preset base address, such as 0x1000; and correcting the software code in the second memory according to the preset base address, such as 0x1000, based on the relocation table used by the electronic device.

[0067] In step 207, after normalization, the address of the software code in the second memory is essentially corrected based on a preset base address. A feature value, such as a second feature value, is then calculated for the normalized and corrected software code. Here, the feature value can be the hash value of the software code.

[0068] In existing technologies, when carrying signature data within software code, it is typically placed at the end of the software code file. For Windows software (including macOS), the entire file has a unified structure called the PE (Preinstallation Environment) structure. The data contained in this structure is loaded into memory all at once, but the signature data is not in this PE structure and therefore needs to be loaded twice. Thus, when subsequent signature verification is required, the software code itself is first loaded into memory, and then the signature data at the end of the software code file is loaded into memory—meaning it needs to be loaded twice. This is both performance-intensive and insecure (it cannot guarantee the atomicity of verification and loading, giving attackers more opportunities to attack). To avoid this problem, for Windows operating system PE files, step 204 above specifies the location as the data gap in the software code defined by the Windows PE structure. In other words, in this embodiment, the signature data can be directly stored in the section data of the software code and integrated with the software code as a PE file. This improves the concealment of the signature information and enables one-time reading and verification during the loading process into memory, making it both efficient and secure.

[0069] Accordingly, steps 205 and 207 may further include: obtaining signature data from the specified location in the software code of the published software, such as a data gap in the software code, verifying the signature data using the public key in the pre-set public-private key pair, thereby obtaining a first feature value.

[0070] Next, for step 209: determine whether the first feature value and the second feature value are the same. If they are not the same, proceed to step 211; if they are the same, proceed to step 213.

[0071] Here, if the first feature value is different from the second feature value, it means that the software code in the memory of the electronic device is different from the software code before it was released. In other words, it is very likely that the attacker has modified the software code in the memory of the electronic device, that is, an attack has occurred targeting the software code in memory.

[0072] Step 211: Determine that an attack has occurred against the software in the electronic device.

[0073] Step 213: Determine that no attack has occurred against the software in the electronic device.

[0074] In one embodiment of this specification, after the software code of the software is read into the second memory of the electronic device, the above-described steps 207 to 211 or 213 may be executed whenever a triggering event is detected.

[0075] In the embodiments described in this specification, the triggering event may include at least one of the following:

[0076] Event 1: The read operation of the software code being read into the electronic device's secondary memory has ended.

[0077] For event 1, it is possible to detect whether an attack has occurred against the software code during the process of the software code being read into the second memory.

[0078] Event 2: The timer reaches the preset time period length.

[0079] For event 1, it is possible to periodically detect whether the software code in memory has been attacked.

[0080] Event 3: A predetermined critical operation triggered during the software's operation on the electronic device.

[0081] For event 3, key operations may include at least one of the following: entering a password, accessing the payment page, or transferring funds.

[0082] Figure 3 This is a flowchart of an attack detection method in another embodiment of this specification. It is understood that this method can also be executed by any device, equipment, platform, or cluster of devices with computing and processing capabilities. See also... Figure 3 The method includes:

[0083] Step 301: Before a software is released, the publisher loads the software code into memory in a simulated manner, which is called the first memory.

[0084] Step 303: The publisher normalizes the software code in the first memory and calculates the feature value of the normalized software code, which is called the first feature value.

[0085] Step 305: The publisher uses the private key from the pre-set public-private key pair to sign the first feature value, thus obtaining the signature data.

[0086] Step 307: The publisher carries the signature data in the data gaps of the software code and then distributes the software to electronic devices.

[0087] Step 309: After the software is published to an electronic device, the electronic device detects that the software code of the software has been read from the disk into memory, which is called the second memory.

[0088] Step 311: The electronic device obtains the signature data from the data gaps in the software code, verifies the signature data using the public key in the pre-set public-private key pair, and obtains the first feature value.

[0089] Step 313: After the electronic device detects the trigger event, it normalizes the software code in the current second memory and calculates the feature value of the normalized software code, which is called the second feature value.

[0090] Step 315: Determine whether the first feature value and the second feature value are the same. If they are not the same, proceed to step 317. If they are the same, proceed to step 319.

[0091] Step 317: Determine that an attack has occurred against the software in the electronic device.

[0092] Step 319: Determine that no attack has occurred against the software in the electronic device.

[0093] In one embodiment of this specification, an attack detection device is provided, see [link to relevant documentation]. Figure 4 The device includes:

[0094] The detection module 401 is configured to detect whether the software code of the software has been read from the disk of the electronic device into the second memory of the electronic device after the software is published to the electronic device;

[0095] The normalization processing module 402 is configured to perform normalization processing on the software code in the second memory;

[0096] Calculation module 403 is configured to calculate the second feature value of the normalized software code;

[0097] The judgment module 404 is configured to determine whether the first feature value and the second feature value are the same. If they are not the same, it is determined that an attack has occurred against the software in the electronic device. The method for obtaining the first feature value is as follows: before the software is released, the software code of the software is simulated and loaded into the first memory; the software code in the first memory is normalized, and the first feature value of the normalized software code is calculated.

[0098] In one embodiment of the device described in this specification, normalization processing of the software code in the first memory includes: assuming the base address of the first memory as a preset base address; correcting the import table used during simulated loading according to the preset base address; and correcting the software code in the first memory according to the preset base address based on the relocation table used during simulated loading.

[0099] The normalization processing module 402 is configured to perform the following: assume the base address of the second memory as a preset base address; correct the import table of the electronic device according to the preset base address; and correct the software code in the second memory according to the preset base address based on the relocation table used by the electronic device.

[0100] In one embodiment of the device described in this specification, before the software is released, after calculating the first feature value, the method further includes: signing the first feature value using the private key in a pre-set public-private key pair; carrying the signature data at a designated location in the software code of the software; and then releasing the software code carrying the signature data to the electronic device.

[0101] The aforementioned attack detection device further includes: a pre-release signature acquisition module (not shown in the figure), configured to perform: acquiring signature data from a specified location in the software code of the released software, verifying the signature data using the public key in the pre-set public-private key pair, thereby obtaining the first signature value. The software is in the format of a Windows PE file; the specified location includes the data gaps in the software code defined by the Windows PE structure.

[0102] The aforementioned attack detection device further includes: a trigger event detection module (not shown in the figure), configured to: detect trigger events after the software code of the software is read into the second memory of the electronic device, and trigger the normalization processing module 402, the calculation module 403 and the judgment module 404 to perform the above-mentioned processing whenever a trigger event is detected.

[0103] In one embodiment of the device described in this specification, the triggering event includes at least one of the following:

[0104] The reading operation of the software code being read into the second memory of the electronic device has ended;

[0105] The timer reaches the preset time period length;

[0106] The software triggers predetermined key operations while running on the electronic device.

[0107] In one embodiment of the device described in this specification, key operations include at least one of the following: entering a password, accessing a payment page, and transferring funds.

[0108] It should be noted that the above-mentioned devices are typically implemented on the server side. They can be set up on independent servers, or some or all of the devices can be combined and installed on the same server. This server can be a single server or a server cluster consisting of multiple servers. The server can be a cloud server, also known as a cloud computing server or cloud host, which is a host product in the cloud computing service system. The above-mentioned devices can also be implemented on computer terminals with strong computing capabilities.

[0109] This specification provides, in one embodiment, a computer-readable storage medium having a computer program stored thereon, which, when executed in a computer, causes the computer to perform the methods of any embodiment in the specification.

[0110] This specification provides a computing device according to one embodiment, including a memory and a processor, wherein the memory stores executable code, and the processor executes the executable code to perform the method of any embodiment of the specification.

[0111] It is understood that the structures illustrated in the embodiments of this specification do not constitute a specific limitation on the apparatus of the embodiments of this specification. In other embodiments of the specification, the above-described apparatus may include more or fewer components than illustrated, or combine some components, or split some components, or have different component arrangements. The illustrated components may be implemented in hardware, software, or a combination of software and hardware.

[0112] The various embodiments in this specification are described in a progressive manner. Similar or identical parts between embodiments can be referred to mutually. Each embodiment focuses on describing the differences from other embodiments. In particular, the apparatus embodiments are basically similar to the method embodiments, so the description is relatively simple; relevant parts can be referred to the descriptions of the method embodiments.

[0113] Those skilled in the art will recognize that, in one or more of the examples above, the functions described in this invention can be implemented using hardware, software, widgets, or any combination thereof. When implemented in software, these functions can be stored in a computer-readable medium or transmitted as one or more instructions or code on a computer-readable medium.

[0114] The specific embodiments described above further illustrate the purpose, technical solution, and beneficial effects of the present invention. It should be understood that the above description is only a specific embodiment of the present invention and is not intended to limit the scope of protection of the present invention. Any modifications, equivalent substitutions, improvements, etc., made on the basis of the technical solution of the present invention should be included within the scope of protection of the present invention.

Claims

1. Attack detection methods, among which, The method includes: Before the software is released, the software code is simulated and loaded into the first memory. The software code in the first memory is normalized, and the first feature value of the normalized software code is calculated. The signature data is carried at a specified location in the software code of the software, and then the software code carrying the signature data is published to the electronic device. After the software is released, when it is detected that the software code of the software is read from the disk of the electronic device into the second memory of the electronic device, the software code in the second memory is normalized, and the second feature value of the normalized software code is calculated. Determine whether the first feature value and the second feature value are the same. If they are not the same, it is determined that an attack has occurred against the software in the electronic device.

2. The method according to claim 1, wherein, The normalization process for the software code in the first memory includes: assuming the base address of the first memory as a preset base address; correcting the import table used during simulated loading according to the preset base address; and correcting the software code in the first memory according to the preset base address based on the relocation table used during simulated loading. The normalization process for the software code in the second memory includes: assuming the base address of the second memory as a preset base address; correcting the import table of the electronic device according to the preset base address; and correcting the software code in the second memory according to the preset base address based on the relocation table used by the electronic device.

3. The method according to claim 1, wherein, Before the software is released, after calculating the first feature value, the process further involves: signing the first feature value using the private key in a pre-set public-private key pair; carrying the signature data at a designated location in the software code of the software; and then releasing the software code carrying the signature data to the electronic device. After the software is released, before determining whether the first feature value and the second feature value are the same, the method further includes: obtaining signature data from the specified location of the software code of the released software, verifying the signature data using the public key in the pre-set public-private key pair, thereby obtaining the first feature value.

4. The method according to claim 3, wherein, The software is in the PE file format of the Windows system; The specified location includes: the data gaps in the software code defined by the Windows PE structure.

5. The method according to claim 1, wherein, Once the software code is read into the second memory of the electronic device, whenever a trigger event is detected, the following steps are executed: "normalize the software code in the second memory, calculate the second feature value of the normalized software code, and determine whether the first feature value and the second feature value are the same".

6. The method according to claim 5, wherein, The triggering event includes at least one of the following: The reading operation of the software code being read into the second memory of the electronic device has ended; The timer reaches the preset time period length; The software triggers predetermined key operations while running on the electronic device.

7. The method according to claim 6, wherein, The key operations include at least one of the following: entering a password, accessing the payment page, and transferring funds.

8. Attack detection device, wherein, The device includes: The detection module is configured to detect, after the software is published to the electronic device, whether the software code of the software has been read from the disk of the electronic device into the second memory of the electronic device; wherein, the software code of the software published to the electronic device carries signature data at a specified location; The normalization processing module is configured to normalize the software code in the second memory; The calculation module is configured to calculate the second feature value of the normalized software code; The judgment module is configured to determine whether a first feature value and a second feature value are the same. If they are not the same, it is determined that an attack has occurred against the software in the electronic device. The method for obtaining the first feature value is as follows: before the software is released, the software code of the software is simulated and loaded into the first memory; the software code in the first memory is normalized, and the first feature value of the normalized software code is calculated.

9. A computer-readable storage medium having a computer program stored thereon, which, when executed in a computer, causes the computer to perform the method of any one of claims 1-7.

10. A computing device comprising a memory and a processor, wherein the memory stores executable code, and the processor, when executing the executable code, implements the method of any one of claims 1-7.

Images