# Ransomware-Resilient Self-Healing XML Documents
## 4 Proposed Version-Aware Ransomware Recovery Framework
### Details of the Proposed SH-VARR Framework
#### 4.1.1 Version-Control Module  
The version-control module is designed to maintain a copy of the XML-based file at the time of file closure so that the latest version can be retrieved in case of any corruption or system failure. We use the term _snapshot_ to refer to the resulting file version. This can be achieved by adding a special plugin for Microsoft Word or LibreOffice. As part of this work, we have implemented a custom plugin for Microsoft Word 2013.  
Our framework is specifically designed to recover XML-based documents in a predefined folder/directory in case of a ransomware attack. Microsoft documents and LibreOffice documents are XML-based documents that are originally compressed using the zip compression algorithm. To create a snapshot of a.odt or.docx file, the plugin performs the following steps:  
* Step 1: Changing the.odt/.docx extension of the file to.zip.
* Step 2: Extracting the document archive. By unzipping the resulting.zip file, we obtain the document structure containing XML-based files and directories generated originally by Microsoft Word or LibreOffice. This includes configurations, meta information, content, settings, etc.  
Figure 1: The overall architecture of SH-VARR framework.  
* Step 3: Adding a new XML file (link.XML) to the file archive that contains an absolute URL (i.e., a link) of the file version to be created in step 5.
* Step 4: Compressing the resulting ZIP archive, including the link.XML file.
* Step 5: Copying the resulting.zip file to a predefined directory that stores the protected versions. Access control permissions are added by the access control module as discussed in Section 4.1.2.
* Step 6: Changing the.zip extension of the file to.odt.  
As an illustrative example, consider Figure 2, which shows the main steps performed by our distributed version-control module to obtain a new version for an XML-based file abc.odt. In this example, we assume that the file is in the user directory /home/user/documents. The version (i.e., a file snapshot) is created by renaming the file to abc.zip and then unzipping the resulting file to obtain the XML file archive. The main reason for performing this step is to add an absolute path (i.e., a link) to the location of the newly introduced version. Assuming that the file version will be stored in: /home/user/versions with the nameabc-version1.zip, then the absolute path /home/user/versions/abc-version1.zip will be saved in the link.XML file that is added to the document archive in step 3. In step 4, the XML-based document archive is compressed back to obtain abc.zip. At this point, the file is copied to the predefined protected versions directory /home/user/versions. Finally, the file extension is changed to.odt.  
Here, note that the version-control module is invoked at the time of closing the document. This ensures that a new snapshot of the XML-based document is saved each time the user closes the file. Here, we emphasize that keeping track of document history (i.e., versions) is achieved by following the absolute path stored in the link.XML file stored in each version. Figure 3 shows the approach used to retrieve older versions. Staring with the newest version (\(V_{N}\) ), it is possible to retrieve the preceding version by following the link found in the link.XML file stored in the version itself. Older versions can be retrieved similarly. For recovery from a ransomware attack, it would be sufficient to keep the latest version only. However, suppose the objective was to retrieve older file versions while providing ransomware recovery capability. In that case, the system can be configured to store protected versions in precisely the same way as described in this section.  
Figure 2: An illustrative example of the main steps of the version-control module.