# Reversing File Access Control Using Disk Forensics on Low-Level Flash Memory
## 5 ACRecovery
### Implementing ACRecovery in EXT Filesystems
#### 5.2.4 EXT: Rollback
EXT in particular is susceptible to this, as inodes make up the majority of the filesystem's data. **GPT Partition handling. ** Some modern drive setups will use a system called the GUID partition table (GPT) rather than the MBR for drive partitions. This system has an initial MBR entry whose partition type is 0 xEE, allowing for ACRecovery to adjust accordingly. The GPT system does not have an OS Type header, but does still contain the location of the partition. As such, a GPT-compatible ACRecovery implementation would need to check the partitions for magic numbers to determine OS type rather than using the MBR entries. This is doable, however our test machines did not use GPT and such a system was not implemented. **EXT4. ** EXT4 is the newest version of the EXT filesystem. This added several features, including an extended superblock, dynamic groups, and more. One feature added to EXT4 is metadata checksums for all applicable inodes. This uses a crc32c algorithm to ensure the integrity of metadata across the filesystem. While good for integrity, this makes our system much more difficult to implement, especially when taking write caching (Section 7) into account [11]. Since crc32c is seeded, we are unable to generate new checksums for the system. In the event that a write changes both the permissions of a file and some other piece of its metadata, a system like ours must either undo all of the applicable changes or none of them due to the checksum. As such, any implementation of our system for EXT4 must be limited, though some semblance of the system can still be implemented. During rollback, a page would need to be checked for significant changes outside of permissions (minor changes like the last time modified can be safely reverted without major issue). If no significant changes are detected, the page can then be rolled back. However, if other changes (for instance, the size of the file) are made, the user may need to be informed and perform the changes manually. **Detection in the FTL**. Given that the OS is compromised, it may be impossible for the user to deduce that their system is infected at all. Since we assume that the malware is removed in our system, it is worth acknowledging possible detection methods in the FTL. [PERSON] et al. [31], as well as several other works [24, 25, 28], do this for mobile devices by scanning for noticeable access patterns across the FTL which lead to malware attacks. It is theoretically possible to transfer a system such as this into the FTL from the trusted app layer by downscaling the application to fit the limited processor space available. More work needs to be done in this area, but it should still be well within possibility to perform this detection automatically in the future without trusting the OS at all. This would enable users to be secure without even having to think about it in most scenarios. **Future work**. Several current weaknesses in the system need to be adjusted for future iterations of the work. These include:

1. [leftmargin=*]
2. Boot-proofing. As discussed in the previous section, we must boot proof the system. Once this has been done, several attacks on our work become invalid as we can simply recover the state of the system after a reboot. Until then, a reboot clears the cache, possibly preventing some changes from being rolled back. 3. Byte-specific monitoring. While our current system leaves byte-specific checks for the rollback phase, it is hypothetically possible to do so during monitoring. This would save a large amount of cache space as false positives become impossible. However, a method for doing so efficiently has yet to be found. 4. Automatic Setup. Right now, the setup operation is performed by a command sent from the user. However, it may be possible for the FTL to detect a specific write pattern which corresponds to the completion of a partition on the drive. More work will need to be done in this area to confirm or deny this possibility.