# Reversing File Access Control Using Disk Forensics on Low-Level Flash Memory
## 5 ACRecovery
### Implementing ACRecovery in EXT Filesystems
#### 5.2.4 EXT: Rollback  
Rollback follows the pattern shown in Figure 4. Permissions data is the first 3 bytes of an inode. Since we harvested the length of an inode in the setup portion, we are able to ignore bytes which are not in the first three bytes of the inode. However, we must perform one further check: If the type setting of the file (the first 4 bits of the first byte) are out of the range 0x10-0 xCF, then we know that the file was either created or destroyed by the previous operation [9]. This value being invalid indicates that the file was either created (if buf2 is invalid and buf1 is not) or deleted (if buf1 is invalid and buf2 is not) by the write being rolled back. Once a page has been fully vetted, we may write the newly created page to its original location by using the address we cached for writing. This is a simple, yet expensive, operation and as such is left to rollback. In addition, each page must be written, which takes up further resources. This algorithm is presented as an example of why recovery is presented as expensive and why detecting whether a change directly affects permissions data is left up to an expensive function (Algorithm 4). ```
1:PAGE page, page //Used to hold page data
2:OOB spare //Used to hold OOB data
3:for int \(i\gets 0\); \(i<permissionCache.size\); \(i++\)do




```
4:\(data\_buffer,spare\gets FTL\_Read(permissionCache.contents[i])\)
5:\(page2\gets spare[2]\)
6:\(buffer2,spare\gets FTL\_Read(page2)\)
7:forint\(j\gets 0;j<PAGE\_SIZE;j+=INODE\_SIZE\)do
8:if\(data\_buffer[j+1]!=buffer2[j+1]\)then
9:\(data\_buffer[j]\gets buffer2[j]\)
10:\(data\_buffer[j+1]\gets buffer2[j+1]\)
11:endif
12:endfor
13:FTL_Write(permissionCache.contents[i], data_buffer)
14:endfor
15:Return
```

**Algorithm 4**_Cont._

## 6 Experimental Evaluation

### Experimental Setup

We chose to implement our design by modifying an existing open-source FTL software known as OpenNFM [37]. OpenNFM contains full C code for an FTL implementation, allowing for modification to any relevant read/write functions and further additions to the project. Our experiments were performed using an LPC-H3131 board (512 MB storage, 180 MHz controller with 192 kB RAM) [38] on a virtual machine running Kali Linux. The VM was allocated 2 cores of an intel i9-10900 KF (5.0 GHz overclock) [39] and 4 GB of 2.1 GHz RAM. The drive was flashed by using the board's reset button and downloading a compiled binary to it [40]. We could then install the relevant filesystem on top of OpenNFM. We elected to perform two tests:

1. Throughput test, particularly in write speed. Since monitoring directly affects the write functionality of the drive, a test of throughput is needed in order to check whether our system dramatically impacts usability. 2. Time to rollback. With our system, it is good to know how long a queue of a given size takes to revert to its original state. This will give us a sense of how major a change the rollback operation gives. These two tests should be able to give an indication of the usability of the system and its impact on the FTL as a whole. If the results of our experiments are positive, the design can be quickly adapted to a publishing of the system. On the other hand, negative results may indicate that the design needs further adjustment before being given to the general public. ### Experimental Results

**Throughput**. The results of the throughput tests are displayed in Tables 1 and 2. Results show a slight decrease in write speeds (and an extremely slight increase in read speeds in some cases, but this is likely caused by system usage at the time the test was run or any number of other factors). This indicates a small, but not problematic loss of performance compared to an unmodified instance, or it could be an indication that the impact of modifications on the drive is irrelevant compared to other unseen factors like system use. In either case, a system like ours is shown to be fully feasible for current implementation. **Rollback time**. Rollback time results are shown in Figures 5 and 6.