# Will Zero Vulnerability Computing (ZVC) Ever Be Possible? Testing the Hypothesis
## 6 Experiment: Supporting the ZVC Hypotheses
### Experiment Outline  
The selected testbed nodes (Linux computers) were remotely accessed using the JFed tool and XRDP software provided by IMEC's Virtual Wall 2 testbed facilities. The staff of the testbed mounted the experimental devices on the USB ports of the selected node. The JFed tool and XRDP software helped us conduct the experiment remotely by implementing and recording events at both experimental nodes. The mock malware was executed on Node1 or the hacker node and was specially designed to detect, infect, and steal data from any device mounted on any of the USB ports of a victim computer targeted for data breach, which in this case was Node0. A mock malware script was designed to copy the.config folder that contains sensitive user information pertaining to the hardware wallet private key of the target user's ETH wallet application running from the hardware wallet device. The following figure (Figure 12) shows the presence of the.config file inside both the ZVC hardware wallet and the control device. The presence of the.config folder inside the ZVC hardware device is highlighted with yellow, while that of the control device is shown with blue highlight. Access to the hardware ETH wallet is authenticated by the private key saved in the.config folder each time the user accesses the ETH wallet account. Anyone in possession of  
Figure 11: Interconnection between Node0 and Node1. Figure 12: The private key stored in the.config folder in the control (blue) as well as the ZVC (yellow) device. a private key would thus have access to the target user's ETH wallet. Hence, a hacker's obvious goal would be to steal the private key; therefore, the mock malware was designed to identify hardware wallets mounted on the USB port of the target node and run a script on the victim device to copy the.config folder containing the ETH wallet's private key. Such copied data are sent to Node1 (hacker node). Figure 13 shows the command line interface to transfer the malware from Node1 (hacker node) to Node0 (target node) and get the sensitive data out of the USB device connected to Node0. The ZVC-powered hardware wallet with the SOS and ICOS modules (hereinafter referred to as ZVC) was mounted on the first USB port of the target Node0, and another similar hardware wallet without a ZVC program was mounted on Node1, i.e., the target node's second USB port. The former ZVC device served as the test device, and the latter served as a control device. A third USB port on target Node0 had mounted a conventional USB device, which served as a reference device to compare the form factor and operational integrity of the node. The mock malware application was executed on hacker Node1, which identifies target Node0 and infects any hardware device mounted on the USB ports of the target node. The control device (Case1) and ZVC test device (Case2), mounted on the target nodes, were tested for their hardware wallet integrity using a Ropsten network (also known as \"Ethereum Testnet\"). Ropsten is an Ethereum test network that allows blockchain development testing before deployment on Mainnet, the main Ethereum network [44]. It is also an ideal test net for recording ERC20 transactions via the ETH wallet, as illustrated in the following scenarios:  
**Case1:** The permanently mounted control device mounted on the target Node0 has a standard cryptocurrency wallet connected to the Internet 24/7. The wallet application was launched to log in using the private key fetched from the.config folder and perform an ETH transaction on the Ropsten Testnet. Contemporaneously, the malware script ran on the hacker Node1. The activities of both nodes were monitored and recorded to first confirm that the wallet transaction was completed at the target Node0 and, second, the mock malware script at hacker Node1 was running, as well as if the.config folder containing sensitive user information (wallet private keys) was transmitted back to the hacker Node1 from the target Node0.