Impact of File-Open Hook Points on Backup Ratio in ROFBS on XFS

I M P A C T O F F I L E - O P E N H O O K P O I N T S O N B A C K U P R A T I O I N RO F B S O N X F S A P R E P R I N T Kosuk e Higuchi K ogakuin Univ ersity 1-24-2 Nishi-Shinjuku Shinjuku-ku T okyo, Japan ed25001@ns.kogakuin.ac.jp Ryotar o K obayashi K ogakuin Univ ersity 1-24-2 Nishi-Shinjuku Shinjuku-ku T okyo, Japan ryo.kobayashi@cc.kogakuin.ac.jp March 18, 2026 A B S T R AC T Ransomware continues encrypting files during the delay between attack onset and detection. R OFBS mitigates this problem by backing up pre-modification files in real time upon file-open ev ents. Howe ver , because the Linux file-open path trav erses multiple k ernel functions, it remains unclear how the choice of hook point af fects defense ef fectiv eness. In this study , we kept the R OFBS mechanism fix ed and changed only the hook points on the Linux file-open path. W e compared may_open , inode_permission , do_dentry_open , security_file_open , and xfs_file_open on AlmaLinux with XFS using three ransomware families: A v osLocker , Conti, and IceFire. W e used Backup Ratio as the main metric and also compared the number of encrypted files with backups and the total number of encrypted files. The results sho wed that hook-point selection substantially affected both reco verability and damage scale. For A vosLock er , security_file_open achiev ed the highest Backup Ratio (82.5%). For Conti and IceFire, xfs_file_open achiev ed the highest v alues (100.0% and 63.2%, respecti vely). Moreov er , xfs_file_open minimized the total number of encrypted files for all three ransomware families. These results indicate that, in R OFBS, the layer at which file-open events are observ ed is a ke y design factor . In particular, on XFS, hooking the filesystem-specific callback xfs_file_open may be advantageous when the goal is to reduce o verall damage. Keyw ords Ransomware defense, real-time backup, Linux kernel, eBPF , hook-point selection, file-open path, XFS 1 Introduction Ransomware can encrypt or destroy a large number of files within a short period of time, severely affecting users’ business continuity . Accordingly , recent studies hav e emphasized not only accurate attack detection but also the extent to which pre-modification data can be preserved while an attack is in progress. In practical deployments, the ef fectiv eness of a defense mechanism depends not only on whether detection succeeds, but also on how many files ultimately remain recov erable. T o address this challenge, in our pre vious work we proposed ROFBS, a Real-T ime Open-File Backup System that backs up pre-modification data in real time upon file-open ev ents [ 1 ]. R OFBS aims to ensure high recov erability against ransomware-induced encryption by obtaining backups before file contents are modified. Compared with approaches that attempt recov ery only after modification has occurred, this approach is less susceptible to detection delay . Howe ver , file-open processing in the Linux kernel does not complete within a single function; rather , it traverses multiple functions spanning the VFS layer , the LSM layer , and filesystem-specific processing. For example, the open path includes may_open , inode_permission called within it, do_dentry_open , security_file_open , and Impact of File-Open Hook Points on Backup Ratio in R OFBS on XFS A P R E P R I N T filesystem-specific open functions. Although all of these functions are related to file-open processing, they differ in the objects that can be observed, the timing of in vocation, and the information av ailable at each point. Therefore, even without changing the R OFBS mechanism itself, the choice of kernel function used as the hook point may alter the timing at which backup creation becomes possible and the path information that can be obtained, thereby affecting both recov erability and the scale of encryption damage. Existing studies have discussed the overall ROFBS architecture and its integration with detectors, but hav e not sufficiently isolated and e v aluated which file-open-related kernel function should be used as the hook point [ 1 , 2 ]. This motiv ates an experiment in which the backup mechanism is fixed and only the hook point is treated as the independent variable. In this study , we keep the basic R OFBS mechanism unchanged and e valuate how differences in hook point affect defense effecti veness in an XFS en vironment. Specifically , we compare the behavior of may_open , inode_permission , do_dentry_open , security_file_open , and xfs_file_open when they are hooked using extended Berkeley Packet Filter (eBPF). As the main metric, we use Backup Ratio, defined as the proportion of encrypted files for which a backup had been created in advance, and we also compare the number of encrypted files with backups and the total number of encrypted files. The objectiv e of this study is to identify the hook point best suited to R OFBS by ev aluating how dif ferences among file-open-related hook points af fect Backup Ratio, the number of encrypted files with backups, and the total number of encrypted files, while keeping the R OFBS mechanism fixed in an XFS en vironment. This study highlights the importance of hook-point selection in Linux ransomw are defense and provides useful insights for the design of real-time backup mechanisms. 2 Related W ork Existing studies can be broadly categorized into three groups: research aimed at ransomware detection, research that mitigates damage using decoys or hone ypots, and research that reduces damage through backup mechanisms. First, among studies on ransomw are detection, Zhura vchak et al. proposed a real-time ransomware detection system that integrates eBPF , machine learning (ML), and natural language processing (NLP) [ 3 ]. Their system combines efficient data collection with eBPF , anomaly detection with ML, and te xt analysis with NLP , thereby achie ving high detection accuracy . Medhat et al. proposed a hybrid approach for detecting packed ransomware samples by scanning process memory dumps and dropped e xecutables [ 4 ]. By extending the Y ARA rule framework so that common ransomware characteristics can be described, their method achie ved a high detection rate. K ok et al. proposed a machine-learning- based pre-encryption detection algorithm that detects ransomware with high accuracy before encryption begins [ 5 ]. Song et al. proposed an anomaly detection method for Android platforms based on resource-related indicators such as CPU usage, memory consumption, and I/O rate [ 6 ]. In addition, Cusack et al. built a stream processor on a Programmable Forw arding Engine (PFE) and proposed a method for identifying malicious netw ork behavior using a random forest classifier , demonstrating the possibility of pre-encryption detection through flow-based fingerprinting [ 7 ]. From the perspecti ve of monitoring infrastructure itself, Ca viglione et al. proposed a method that le verages eBPF to efficiently trace and monitor software process behavior [ 8 ]. Although this work is not specific to ransomware, it sho wed that filesystem changes and hidden communications can be observed with low o verhead, thereby supporting the effecti veness of using eBPF to capture security-rele v ant ev ents on Linux. As for approaches that aim to stop damage in progress, Gómez-Hernández et al. proposed R-Locker , which defends against ransomware by monitoring accesses to decoy files [ 9 ]. Their method prev ents the progression of encryption by stopping ransomware once access to a decoy file is detected. Similarly , Zhuravchak et al. proposed a method that mitigates filesystem damage using hone ypot techniques and symbolic links [ 10 ]. Lee et al. focused on the f act that ransomware binaries often whitelist specific file extensions, and proposed a defense method that protects important files by randomly changing their extensions [11]. There have also been studies that reduce damage through backup mechanisms. Fujinoki et al. proposed PDPZR, a backup system that creates a backup whenever data are updated and manages redundancy by deleting old versions [ 12 ]. Gujar et al. proposed an automatic backup system that detects newly added files in real time and immediately backs them up to a dedicated folder on an SSD [ 13 ]. Oujezsky et al. proposed the Intelligent Malware Defense System (IMDS), which uses AI and hash functions to v erify file integrity before backup and blocks the backup process when anomalies are detected [14]. In summary , prior work has explored improvements in detection accurac y , damage suppression using decoys and honeypots, and damage mitigation through backup. Howe ver , for a mechanism such as R OFBS, which preserves 2 Impact of File-Open Hook Points on Backup Ratio in R OFBS on XFS A P R E P R I N T pre-modification data upon file-open e vents, there has been insufficient e valuation of which hook point in the Linux file-open path should be selected. Our work dif fers in that it keeps the R OFBS mechanism itself fixed while changing only the hook point, and compares the resulting ef fects on Backup Ratio, the number of encrypted files with backups, and the total number of encrypted files. 3 Background This section introduces R OFBS, which is used in the experiments, the eBPF and BCC technologies used in its implementation, and an ov erview of the open-related kernel functions e v aluated in this study . 3.1 Overview of ROFBS R OFBS is a real-time file backup system proposed by the authors to mitigate ransomware damage [ 1 ]. Pre vious ransomware defense studies based on machine learning ha ve mainly focused on improving detection methods and detection accuracy . In practice, howe ver , file encryption continues even during the period between the start of ransomware e xecution and its detection. Therefore, improving detection performance alone is not sufficient to fully suppress encryption damage itself. K ok et al. pointed out that, although many studies adopt machine learning for ransomware detection, relatively fe w propose models that directly prev ent or mitigate the attack itself [ 15 ]. This suggests that, in order to cope with increasingly sophisticated and div erse ransomware attacks, it is important to design defense models aimed not only at detection but also at damage mitigation. Moreover , despite the increase in ransomware targeting Linux, defense models and countermeasures for Linux are still not sufficiently de veloped [ 16 , 17 ]. Whereas many endpoint security products are a vailable in Windo ws en vironments, the options for Linux remain limited, highlighting the need for stronger defense techniques. Against this background, the authors first proposed a model incorporating a file-protection mechanism to mitigate encryption damage occurring during the detection delay [ 18 ], and then dev eloped R OFBS as its extension [ 1 ]. R OFBS captures file-related e vents using eBPF and creates backups before files are modified, thereby preserving pre-modification data ev en while ransomware is running. In this way , ROFBS aims to mitigate ransomware damage in Linux environments while combining real-time monitoring with immediate response. In the ROFBS implementation, file paths are recei ved incrementally from the kernel in re verse order , and complete paths are reconstructed by combining multiple ev ents. In addition, backup files are assigned the .tmp extension. This is because previous work has sho wn that ransomware tends to exclude files with certain extensions, such as .tmp and .exe , from encryption targets [ 19 ]. After the malicious process has been stopped, the original file can be restored by renaming the backup file back to its original extension when necessary . Algorithm 1 shows the backup procedure used in R OFBS. Algorithm 1 Backup procedure of R OFBS Require: File path ( f ile _ path ) and list of protected directories ( pr otected _ dir ector ies ) 1: function C R E ATE B AC K U P F I L E ( f il e _ path , pr otected _ dir ector ies ) 2: if f il e _ path is under one of pr otected _ dir ectories and has not yet been backed up then 3: Sav e the pre-modification contents of f ile _ path as a backup file with the .tmp extension. 4: Record f il e _ path as already backed up. 5: end if 6: end function 7: function R E S T O R E B AC K U P ( f ile _ path , is _ mal icious ) 8: if is _ malicious is true and a corresponding .tmp backup exists for f il e _ path then 9: Rename the .tmp backup to the original file name and restore f il e _ path . 10: end if 11: end function In the e valuation reported in [ 1 ], a backup ratio of 100% was achiev ed for both Monti and Conti across all machine- learning algorithms evaluated. High backup ratios were also reported for other ransomware families. These results suggest that R OFBS can be effecti ve as a Linux-oriented ransomw are defense mechanism. 3 Impact of File-Open Hook Points on Backup Ratio in R OFBS on XFS A P R E P R I N T 3.2 Extended Berkeley Packet Filter eBPF is a mechanism for safely and efficiently executing sandboxed programs in a pri vileged context of the Linux kernel [ 20 ]. By using eBPF , it is possible to extend k ernel capabilities for tracing, performance analysis, networking, and security monitoring without modifying kernel source code or loading kernel modules. In addition, eBPF programs are checked by the verifier before being loaded into the kernel, and are ex ecuted only after their safety has been confirmed. At runtime, JIT compilation can provide high e xecution ef ficiency . In general, the functions av ailable in eBPF and the hook points to which programs can be attached depend on the kernel version. T o address this issue, recent approaches such as BPF CO-RE, which relies on BTF and libbpf, have been dev eloped to improve portability across dif ferent kernel versions. Ho wev er , the implementation in this study uses BCC, described below . 3.3 BPF Compiler Collection The BPF Compiler Collection (BCC) is a toolkit for dev eloping eBPF programs [ 21 ]. W ith BCC, kernel-side instrumen- tation is typically written in C, while user -space components for loading programs and processing collected data can be written in Python or Lua. This makes it relativ ely easy to implement tracing and monitoring mechanisms based on eBPF . BCC also pro vides a v ariety of sample tools and utilities, enabling de velopers to rapidly build eBPF-based tracing and monitoring tools. In this study , we use probes to hook k ernel functions. T ypical e xamples include kprobes, which fire at function entry , and kretprobes, which fire when a function returns. Because the information av ailable before and after function ex ecution differs, it is important to choose the appropriate probe type depending on the purpose. 3.4 File-Open Path in Linux In this study , multiple kernel functions along the Linux open path are compared as candidates for triggering R OFBS backups. Figure 1 shows an ov erview of the Linux open path rele vant to this study . The figure does not attempt to cover all helper functions or special-case branches in open processing; rather , it simplifies the main path in order to show the relativ e positions of the hook points e valuated in this study . T able 1 summarizes the layer and the main information av ailable at each hook point. T able 1: Layers and main information av ailable at each hook point Hook point Layer Main information av ailable may_open Early decision stage path , dentry , inode , open flag inode_permission Permission-check stage inode , access mask do_dentry_open Common VFS open- ex ecution stage file , f_inode , f_mapping , f_op security_file_open Late common VFS stage file , state at open time xfs_file_open Filesystem-specific stage file , inode Belo w , the role of each hook point is described based on the open path in the target kernel version used in our e valuation. In Linux, an open request issued from user space is processed through pathname lookup and open handling in the VFS. During this process, path resolution, acquisition of dentries and inodes, access checks, and initialization of the file structure are performed in stages. Simplifying the open path considered in this paper , may_open performs permission checking through inode_permission , after which control proceeds via vfs_open to do_dentry_open , where security_file_open is executed before the filesystem-specific open callback. Thus, Linux open processing is not completed within a single function, b ut consists of an early decision stage, a common VFS open-e xecution stage, and a filesystem-specific stage. The first hook point considered in this study , may_open , is a decision function located in a relati vely early part of the open path. In may_open , the type of the target inode and the consistency of the open flag are checked, and access permission is then ev aluated through inode_permission . Therefore, hooking may_open means observing events before the actual open ex ecution and before the filesystem-specific open callback is reached. This position has the advantage of capturing open requests at an early stage, but it may also include ev ents that do not proceed to later stages. 4 Impact of File-Open Hook Points on Backup Ratio in R OFBS on XFS A P R E P R I N T open() / openat() / openat2() do_filp_open() path_openat() do_open() may_open() inode_permission() !(file->f_mode & FMODE_OPENED) vfs_open() do_dentry_open() security_file_open() f_op → open xfs_file_open() userspace kernel normal path security_inode_permission() [LSM hook: inode_permission ] [LSM hook: file_open ] security_file_post_open() (recent mainline) ev aluated hook point Figure 1: Simplified Linux open path relev ant to this study . Gray boxes indicate the hook points ev aluated in the experiments. Helper functions and special-case branches are omitted except for se veral annotated points. The second hook point, inode_permission , is responsible for permission checking on an inode. Although this function is in voked from may_open on the open path, it is not specific to open operations. Accordingly , when inode_permission is used as a hook point, an implementation issue is how to distinguish in vocations caused specifically by open. Moreover , because this function primarily handles an inode and an access mask, and does not directly provide path- or file-based context, the conte xtual information av ailable at this point is more limited than at other hook points. The third hook point, do_dentry_open , is located at the common VFS open-execution stage. At this point, ma- jor fields in the file structure, such as f_inode , f_mapping , and f_op , have already been initialized. Therefore, do_dentry_open reflects a more concrete open state than a simple permission check. For a mechanism such as R OFBS, which performs backups on a per-file basis, this makes it a hook point at which the target file can be identified relativ ely clearly . The fourth hook point, security_file_open , is ex ecuted inside do_dentry_open before the filesystem-specific open callback is in voked. This function serves as the entry point for LSM-based state handling and additional checks at open time. Therefore, using security_file_open allows e vents to be captured at a point close to the actual open operation while still remaining on the filesystem-independent common path. 5 Impact of File-Open Hook Points on Backup Ratio in R OFBS on XFS A P R E P R I N T The fifth hook point is a filesystem-specific open callback. In this study , we ev aluate xfs_file_open . This is the callback for regular files, whereas directories use a separate open callback. As a result, compared with hook points on the common VFS path, a filesystem-specific open callback may observe a more restricted set of e vents. On the other hand, because it is located near the final stage in the filesystem-specific layer, it can observ e open e vents in a manner that more closely reflects the implementation of the underlying filesystem. In summary , although all hook points compared in this study are related to open processing, they are distributed across different layers: an early decision stage, a common VFS execution stage, and a filesystem-specific stage. As a result, the type of information av ailable, the range of open events observ ed, and the timing at which ROFBS starts backup processing may differ across hook points. T o ev aluate how these dif ferences affect the number of encrypted files with backups, the total number of encrypted files, and Backup Ratio, this study compares these fiv e hook points [22 – 24]. 3.5 Experimental Setup The experimental environment w as constructed using V irtualBox. T able 2 summarizes the specifications of the host machine and the virtual machine. Because this study e valuates xfs_file_open , the target directory victim in the virtual machine was placed on an XFS filesystem. T able 2: Experimental en vironment Host Machine V irtual Machine CPU Intel Core i7-12650H 1 vCPU Memory 32 GB (DDR4 2400 MT/s) 8 GB Storage 512 GB (M.2 NVMe SSD) 128 GB (virtual disk) OS W indows 11 AlmaLinux 10.1 The experimental settings follo w the basic polic y of prior work, while being adapted to the environment used in this study [ 1 , 2 ]. Specifically , we created a victim directory containing 4,385 files taken from the tiny folder of the NapierOne dataset [ 25 ]. The virtual en vironment included this victim directory , together with the files and libraries required to run the detection model and R OFBS. Three ransomw are samples were used in this study . These samples were obtained between May and October 2023. Each sample was identified by its SHA256 hash, and its name follows the signature name assigned at the time of acquisition. In principle, each sample was ex ecuted with default settings, and the –path argument was provided only when specifying the target path was necessary . That is, we used only the arguments required for execution or explicitly listed in the help menu, and did not specify additional options such as thread count or background ex ecution. IceFire does not support user-defined encryption tar gets, and therefore this argument w as not applied to IceFire. T able 3: Ransomware samples used in the experiments Ransomware SHA256 IceFire e9cc7fdfa3cf40f f9c3db0248a79f4817b170f2660aa2b2ed6c551eae1c38e0b A vosLocker 0cd7b6ea8857ce827180342a1c955e79c3336a6cf2000244e5cfd4279c5fc1b6 Conti 95776f31cbcac08eb3f3e9235d07513a6d7a6bf9f1b7f3d400b2cf0afdb088a7 T able 4 lists the machine-learning algorithm adopted in this study . Accuracy and FPR were ev aluated using logs collected during the execution of A vosLocker . These logs were unparsed and had the same format as those collected in this study . Each log entry was manually labeled as benign or malicious. Accuracy w as calculated as the agreement rate between the model predictions and the manual labels. FPR was calculated as the proportion of benign logs incorrectly classified as malicious. Based on the Accuracy and FPR results, we adopted Random Forest (RF). T able 4: Machine-learning algorithm adopted in this study Algorithm Accuracy (%) FPR Random Forest (RF) 97.2 0.0068 6 Impact of File-Open Hook Points on Backup Ratio in R OFBS on XFS A P R E P R I N T 3.6 Backup Ratio T o ev aluate the ef fectiv eness of the backup mechanism, this study uses Backup Ratio as an ev aluation metric. Backup Ratio represents the proportion of encrypted files for which backups had been created in advance, and is defined as follows: Bac kup Ratio[%] = N backup N encrypted × 100 (1) Here, N backup denotes the number of encrypted files for which pre-created backups existed, and N encrypted denotes the total number of encrypted files. R OFBS was proposed to mitig ate damage caused during the delay before ransomw are is detected. Accordingly , this study focuses not on the number of files that were not encrypted, but on how man y encrypted files remained reco verable. At the same time, because Backup Ratio depends on the denominator N encrypted , the magnitude of change in the ratio is not uniform when N encrypted differs substantially across hook points, e ven if the absolute difference is the same. Therefore, while Backup Ratio is used as the primary metric in this study , its interpretation is supplemented by the absolute values of the number of encrypted files with backups ( B ) and the total number of encrypted files ( E ). 3.7 Results T able 5 shows, for each hook point, the number of encrypted files with backups ( B ) and the total number of encrypted files ( E ). T able 5: Numbers of encrypted files with backups ( B ) and total encrypted files ( E ) for each hook point A vosLocker Conti IceFire Hook Point B E B E B E may_open 9 32 1 46 2 30 inode_permission 7 15 1 46 9 37 do_dentry_open 21 29 1 46 9 35 security_file_open 33 40 1 46 9 36 xfs_file_open 3 7 18 18 12 19 As shown in T able 5, the choice of hook point affects both B and E . For A vosLock er , security_file_open yielded the largest number of encrypted files with backups, recording B = 33 . In contrast, although xfs_file_open yielded only B = 3 , it minimized the total number of encrypted files to E = 7 , showing a dif ferent trend from the other hook points. For Conti, may_open , inode_permission , do_dentry_open , and security_file_open all produced the same result, namely B = 1 , E = 46 . By contrast, xfs_file_open yielded B = 18 , E = 18 , sho wing a markedly different distribution from the other four hook points. For IceFire as well, xfs_file_open yielded B = 12 , E = 19 , which was the smallest v alue of E among all hook points. T able 6 shows the Backup Ratio v alues calculated according to Eq. (1). T able 6: Backup Ratio (%) for each hook point Hook Point A vosLocker Conti IceFire may_open 28.1 2.2 6.7 inode_permission 46.7 2.2 24.3 do_dentry_open 72.4 2.2 25.7 security_file_open 82.5 2.2 25.0 xfs_file_open 42.9 100.0 63.2 T able 6 sho ws that, for A vosLocker , security_file_open achiev ed the highest Backup Ratio at 82.5%, followed by do_dentry_open at 72.4%. For Conti, xfs_file_open reached 100.0%, substantially outperforming the other hook points. For IceFire, xfs_file_open also achie ved the highest value, at 63.2%. These results indicate that security_file_open yielded the highest Backup Ratio for A v osLocker , whereas xfs_file_open achiev ed the highest Backup Ratio for Conti and IceFire. By contrast, may_open remained relativ ely low for all three ransomw are families. Howe ver , because Backup Ratio uses the total number of encrypted files as its denominator, it should be interpreted together with the absolute values of B and E sho wn in T able 5. 7 Impact of File-Open Hook Points on Backup Ratio in R OFBS on XFS A P R E P R I N T 4 Discussion In this section, let B denote the number of encrypted files with backups and E denote the total number of encrypted files. In this study , the R OFBS mechanism itself was k ept fixed, and only the hook point was changed, yet substantial dif ferences were observed in both B and E . This indicates that changing the hook point is not merely an implementation detail, but rather changes the range and conte xt of the open ev ents observed by R OFBS. Although Backup Ratio is a useful normalized metric, the denominator E varies across hook points, which means that defense ef fectiv eness cannot be determined solely from the ratio itself. In particular , when E is small, e ven small differences in B or E can lead to lar ge changes in Backup Ratio. Accordingly , the follo wing discussion interprets not only Backup Ratio but also the absolute v alues of B and E . 4.1 Effect of Hook Position All hook points compared in this study reside in kernel space, but their relativ e positions differ . may_open and inode_permission are located in the early part of the VFS path and are in vok ed relativ ely close to the open request issued from user space. By contrast, do_dentry_open and security_file_open are located in the later part of the common VFS open-e xecution path. Furthermore, xfs_file_open is a filesystem-specific open callback for regular files in XFS, and among the candidates considered here it is the closest to the filesystem-specific layer [22 – 24]. These differences directly af fect both the information av ailable to R OFBS and the range of events that can be observ ed. Because may_open is an early decision function and performs permission checking through inode_permission , upper-le vel hooks may observe a broader range of e vents rather than only files that actually proceed to the open- ex ecution stage [ 22 ]. In particular , inode_permission mainly handles an inode and an access mask, and therefore provides more limited contextual information for file identification than later hooks that can directly access struct file . This interpretation is consistent with the results for may_open and inode_permission , where B tended to remain small and E was not suf ficiently suppressed. By contrast, do_dentry_open and security_file_open can use struct file at a stage closer to the actual open ex ecution, allo wing R OFBS to identify target files more concretely . Experimentally , these later hooks increased B compared with may_open and inode_permission . In particular , security_file_open recorded a relati vely large number of encrypted files with backups ov erall. Howe ver , this did not translate into suppression of E , suggesting that, at least under the present e xperimental conditions, increasing the number of backups alone is not suf ficient to fully characterize protection effecti veness. 4.2 Why xfs_file_open W as Advantageous in This Setting xfs_file_open is the lo west-lev el hook point ev aluated in this study and is specific to the filesystem layer . In XFS, the open callback for regular files is separated from that for directories, and xfs_file_open is in v oked only for regular files [ 24 ]. As a result, compared with hooks placed on the common VFS path, ROFBS performs backup processing on a more restricted set of targets. In the present results, xfs_file_open did not always maximize B , b ut it minimized E for all three ransomware families. This suggests that what matters for ROFBS is not simply increasing the number of observed e vents, but reacting preferentially to open ev ents that are more likely to lead to actual encryption. Whereas the common VFS path can observe a broad set of open ev ents, some of them may be of relatively lo w priority from the perspectiv e of ROFBS. By contrast, because xfs_file_open restricts observation to regular -file opens, it may hav e enabled backup-processing resources to be used more effecti vely . The fact that security_file_open increased B but did not sufficiently suppress E also suggests that broadly observing open e vents on the common path is not enough. In other w ords, the effecti veness of ROFBS depends not only on ho w deep the observ ation point is, but also on how well that point filters out unnecessary open e vents. Under the present XFS-based setting, the filesystem-specific callback xfs_file_open may therefore hav e been advantageous in this respect. 4.3 Differences Across Ransomware Families Looking at differences across ransomware families, for A vosLocker , security_file_open recorded the largest number of encrypted files with backups and also achie ved the highest Backup Ratio. At the same time, the smallest v alue of E was obtained with xfs_file_open . This indicates that, for A vosLocker , the hook point that is fa vorable for maximizing recov erability does not necessarily coincide with the one that is fav orable for minimizing the overall scale 8 Impact of File-Open Hook Points on Backup Ratio in R OFBS on XFS A P R E P R I N T of encryption damage. Therefore, for A vosLocker , it is not appropriate to conclude that security_file_open is the best choice solely on the basis of Backup Ratio; both B and E must also be considered. For Conti, may_open , inode_permission , do_dentry_open , and security_file_open all produced identical results, whereas only xfs_file_open showed a marked improvement. This suggests that, at least under the present experimental conditions, lower -lev el filesystem-specific hooks may be more effecti ve than upper VFS hooks or common-path hooks for ransomware with beha vior similar to Conti. For IceFire as well, xfs_file_open sho wed fav orable results in terms of both B and E , supporting the same tendency . Thus, although the behavior v aries across ransomware families, the present e xperiments suggest that, on XFS, using a filesystem-specific open callback is advantageous particularly for suppressing E . 4.4 Implications for ROFBS Design Overall, these results indicate that, in R OFBS, hook-point selection af fects not only Backup Ratio but also the o verall scale of encryption damage. Upper-le vel VFS hooks can broadly observe open requests, but were less likely to translate into effecti ve backups for R OFBS. Later hook points on the common VFS path increased the number of encrypted files with backups, b ut had limited ability to suppress the total number of encrypted files. By contrast, the XFS filesystem-specific open callback xfs_file_open consistently yielded smaller v alues of E under the present experimental conditions by concentrating observ ation on regular -file opens. Therefore, at least when ROFBS is deplo yed on XFS, hooking at a point close to the filesystem-specific open path may be more effectiv e than hooking upper VFS or common open-path functions. These results indicate that the layer at which file-open ev ents are observed is a fundamental design factor in real-time backup mechanisms. 4.5 Limitations This study has se veral limitations. First, the filesystem-specific hook e v aluated here is xfs_file_open in XFS, and the findings cannot be directly generalized to other filesystems. For example, ext4 implements ext4_file_open as the regular -file open callback, and its internal processing at open time differs from that of XFS [24, 26]. Second, this study focuses primarily on effecti veness as ev aluated through Backup Ratio and file counts, and does not provide a detailed e v aluation of performance, CPU utilization, e vent v olume, or queue behavior in user space. Accordingly , further in vestigation is needed to clarify how the observed differences relate to backup-processing resource consumption and ev ent concentration. Third, the ev aluation in this study is based on XFS, the three ransomware families examined here, and a single workload. Whether the same tendencies hold for other filesystems, other ransomware f amilies, or different w orkload conditions remains future work. Fourth, for hook points such as inode_permission , where path information and struct file cannot be obtained directly , paths are reconstructed using representati ve dentries. This reconstruction method itself may therefore af fect the results, and should be kept in mind when interpreting comparisons across hook points. 5 Conclusion In this study , we ev aluated how changing only the hook point, while keeping the R OFBS mechanism itself unchanged, affected the number of encrypted files with backups, the total number of encrypted files, and Backup Ratio. As compar- ison targets, we used fiv e hook points: may_open , inode_permission , do_dentry_open , security_file_open , and xfs_file_open , and conducted experiments using A vosLocker , Conti, and IceFire. The experimental results showed that the choice of hook point has a substantial impact on the effecti veness of R OFBS. For A vosLocker , security_file_open achiev ed the highest Backup Ratio, whereas for Conti and IceFire, xfs_file_open achiev ed the highest Backup Ratio. Moreover , xfs_file_open minimized the total number of encrypted files for all three ransomware f amilies, indicating an overall adv antage in suppressing the scale of damage. By contrast, may_open remained relatively lo w in Backup Ratio across all three ransomware families. Howe ver , because Backup Ratio uses the total number of encrypted files as its denominator , defense effecti veness cannot be determined solely from this ratio. In particular , for A vosLocker , security_file_open achiev ed the highest Backup Ratio, while xfs_file_open minimized the total number of encrypted files. This indicates that the hook point fa vorable for maximizing recov erability does not necessarily coincide with the one fa vorable for minimizing the total 9 Impact of File-Open Hook Points on Backup Ratio in R OFBS on XFS A P R E P R I N T number of encrypted files. Therefore, when ev aluating ROFBS, it is important to interpret Backup Ratio together with the absolute values of the number of encrypted files with backups and the total number of encrypted files. These results indicate that what matters in ROFBS is not merely whether file-open ev ents are monitored, but which layer of the open path is observed. Dif ferences among an upper VFS decision stage, a common VFS ex ecution stage, and a filesystem-specific open callback affect the nature of the observed e vents, the information obtainable at the hook point, and the timing at which backup creation begins, and these differences ultimately appear as differences in defense effecti veness. Accordingly , in a real-time backup mechanism such as R OFBS, the choice of hook point is itself a fundamental design factor . The results of this study suggest that, at least when R OFBS is deployed on XFS, hooking near a filesystem-specific open callback such as xfs_file_open can be advantageous from the perspecti ve of suppressing the scale of damage. At the same time, this study focuses on ev aluation on XFS, and the findings cannot be directly generalized to other filesystems. Future work includes e valuation on other filesystems such as ext4, more detailed analyses including performance and ev ent volume, and v alidation of reproducibility across other kernel lines and e xecution en vironments. Overall, this study demonstrates that hook-point selection in ROFBS af fects not only Backup Ratio but also the total number of encrypted files, and pro vides useful insights for the design of Linux-oriented ransomware defense mechanisms. References [1] K osuke Higuchi and Ryotaro Kobayashi. Real-time open-file backup system with machine-learning detection model for ransomware. International Journal of Information Security , 24(1):54, January 2025. [2] K osuke Higuchi and Ryotaro K obayashi. ROFBS α : Real time backup system decoupled from ml based ran- somware detection. , 2025. arXi v:2504.14162. [3] Danyil Zhuravchak and V alerii Dudykevych. Real-time ransomware detection by using ebpf and natural lan- guage processing and machine learning. In IEEE 5th International Conference on Advanced Information and Communication T echnologies , pages 1–4, 2023. [4] S. Mehnaz, A. Mudgerikar, and E. Bertino. Rwguard: A real-time detection system against cryptographic ransomware. In 21st International Symposium on Resear ch in Attacks, Intrusions and Defenses , pages 114–136, 2018. [5] S. H. K ok, Azween Abdullah, NZ Jhanjhi, and Mahadev an Supramaniam. Prevention of crypto-ransomw are using a pre-encryption detection algorithm. Computers , 8(4):79, 2019. [6] S. Song, B. Kim, and S. Lee. The effecti ve ransomware prevention technique using process monitoring on android platform. Mobile Information Systems , 2016(1):2946735, 2016. [7] G. Cusack, O. Michel, and E. Keller . Machine learning-based detection of ransomw are using SDN. In A CM International W orkshop on Security in Software Defined Networks & Network Function V irtualization , pages 1–6, 2018. [8] Luca Caviglione, W ojciech Mazurczyk, Matteo Repetto, Andreas Schaffhauser , and Marco Zuppelli. Kernel-le vel tracing for detecting stegomalw are and covert channels in linux en vironments. Computer Networks , 191:108010, 2021. [9] J. A. Gómez-Hernández, L. Álv arez González, and P . García-T eodoro. R-locker: Thwarting ransomware action through a honeyfile-based approach. Computers & Security , 73:389–398, 2018. [10] D. Zhuravchak, T . Ustyianovych, V . Dudyke vych, B. V enny , and K. Ruda. Ransomware pre vention system design based on file symbolic linking honeypots. In 11th International Confer ence on Intelligent Data Acquisition and Advanced Computing Systems: T echnolo gy and Applications , pages 284–287, 2021. [11] S. Lee, H. K. Kim, and K. Kim. Ransomware protection using the moving target defense perspectiv e. Computers & Electrical Engineering , 78:288–299, 2019. [12] H. Fujinoki and L. Manukonda. Proactiv e damage prev ention from zero-day ransomwares. In 5th International Confer ence on Computer Communication and the Internet , pages 133–141, 2023. [13] Kunal Gujar , Pratik Jagdale, Swapnil Y adav , and Srijita Bhattacharjee. Backup solid state driv e for ransomware protection. Journal of Operating Systems De velopment & T r ends , 10(1):12–18, 2023. [14] V aclav Oujezsk y , Pa vel Nov ak, T omas Horvath, Martin Holik, and Michal Jurcik. Data backup system with integrated acti ve protection ag ainst ransomware. In 46th International Confer ence on T elecommunications and Signal Pr ocessing , pages 65–69, 2023. 10 Impact of File-Open Hook Points on Backup Ratio in R OFBS on XFS A P R E P R I N T [15] S. H. K ok, Azween Bin Abdullah, Noor Zaman Jhanjhi, and Mahadev an Supramaniam. Ransomware , threat and detection techniques : A revie w . In International Journal of Computer Science and Network Security , volume 19, pages 136–146, 2019. [16] T rend Micro. Rethinking tactics: 2022 annual c ybersecurity roundup. https://www.trendmicro.com/vinfo/ us/security/research- and- analysis/threat- reports . Accessed 2024-7-29. [17] S. B. Surati and G. I. Prajapati. A revie w on ransomware detection & prev ention. International Journal of Resear ch and Scientific Innovation (IJRSI) , 4(9):86–91, 2017. [18] K osuke Higuchi and Ryotaro K obayashi. Real-time defense system using ebpf for machine learning-based ransomware detection method. In 11th International Symposium on Computing and Networking W orkshops , pages 213–219, 2023. [19] Saleh Alzahrani, Y ang Xiao, and W ei Sun. An analysis of conti ransomware leaked source codes. IEEE Access , PP:1–1, 01 2022. [20] eBPF . What is eBPF? an introduction and deep dive into the eBPF technology . https://ebpf.io/ what- is- ebpf . Accessed 2023-3-25. [21] IO V isor. BCC - tools for BPF-based linux IO analysis, networking, monitoring, and more. https://github. com/iovisor/bcc . Accessed 2023-3-25. [22] Linux K ernel Dev elopers. Linux kernel source: fs/namei.c. https://codebrowser.dev/linux/linux/fs/ namei.c.html , 2026. Accessed 2026-03-11. [23] Linux K ernel De velopers. Linux kernel source: fs/open.c. https://codebrowser.dev/linux/linux/fs/ open.c.html , 2026. Accessed 2026-03-11. [24] Linux Kernel De velopers. Linux kernel source: fs/xfs/xfs_file.c. https://codebrowser.dev/linux/linux/ fs/xfs/xfs_file.c.html , 2026. Accessed 2026-03-11. [25] Simon R. Davies, Richard Macfarlane, and W illiam J. Buchanan. Napierone: A modern mix ed file data set alternativ e to govdocs1. F or ensic Science International: Digital Investigation , 40:301330, 2022. [26] Linux Kernel De velopers. Linux kernel source: fs/e xt4/file.c. https://codebrowser.dev/linux/linux/fs/ ext4/file.c.html , 2026. Accessed 2026-03-11. 11