CN114580016B - Potential competition state detection method and system in Android shared storage - Google Patents

Potential competition state detection method and system in Android shared storage Download PDF

Info

Publication number
CN114580016B
CN114580016B CN202210163542.5A CN202210163542A CN114580016B CN 114580016 B CN114580016 B CN 114580016B CN 202210163542 A CN202210163542 A CN 202210163542A CN 114580016 B CN114580016 B CN 114580016B
Authority
CN
China
Prior art keywords
file
shared storage
event
name
file operation
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Active
Application number
CN202210163542.5A
Other languages
Chinese (zh)
Other versions
CN114580016A (en
Inventor
杜少勇
罗向阳
杨海峰
李震宇
杨春芳
刘粉林
谭磊
巩道福
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Information Engineering University of PLA Strategic Support Force
Original Assignee
Information Engineering University of PLA Strategic Support Force
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Information Engineering University of PLA Strategic Support Force filed Critical Information Engineering University of PLA Strategic Support Force
Priority to CN202210163542.5A priority Critical patent/CN114580016B/en
Publication of CN114580016A publication Critical patent/CN114580016A/en
Application granted granted Critical
Publication of CN114580016B publication Critical patent/CN114580016B/en
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/60—Protecting data
    • G06F21/62—Protecting access to data via a platform, e.g. using keys or access control rules
    • G06F21/6218—Protecting access to data via a platform, e.g. using keys or access control rules to a system of files or objects, e.g. local or distributed file system or database
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/10—File systems; File servers
    • G06F16/16—File or folder operations, e.g. details of user interfaces specifically adapted to file systems
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/10—File systems; File servers
    • G06F16/17—Details of further file system functions
    • G06F16/176—Support for shared access to files; File sharing support
    • Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
    • Y02—TECHNOLOGIES OR APPLICATIONS FOR MITIGATION OR ADAPTATION AGAINST CLIMATE CHANGE
    • Y02D—CLIMATE CHANGE MITIGATION TECHNOLOGIES IN INFORMATION AND COMMUNICATION TECHNOLOGIES [ICT], I.E. INFORMATION AND COMMUNICATION TECHNOLOGIES AIMING AT THE REDUCTION OF THEIR OWN ENERGY USE
    • Y02D10/00—Energy efficient computing, e.g. low power processors, power management or thermal management

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • Databases & Information Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Data Mining & Analysis (AREA)
  • Health & Medical Sciences (AREA)
  • Bioethics (AREA)
  • General Health & Medical Sciences (AREA)
  • Computer Hardware Design (AREA)
  • Computer Security & Cryptography (AREA)
  • Software Systems (AREA)
  • Human Computer Interaction (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)

Abstract

The invention provides a method and a system for detecting potential competition states when Android shared storage is used. The method comprises the following steps: step 1: monitoring and recording file operation on shared storage of the Android terminal by using an Android. Os. FileObserver; wherein the recording information of each file operation includes: target file path, operation event type and occurrence time; step 2: sequencing and clustering all file operations according to the target file path and the occurrence time to obtain a plurality of file organization modes and a plurality of file operation modes; step 3: constructing a competition state verification model; step 4: and (3) selecting a file organization mode and a file operation mode from the clustering result obtained in the step (2), and verifying whether the files on the shared storage have safety problems of potential competition states by using the constructed competition state verification model under the given file organization mode and the given file operation mode.

Description

Potential competition state detection method and system in Android shared storage
Technical Field
The invention relates to the technical field of shared storage safety, in particular to a method and a system for detecting potential competition states when Android shared storage is used.
Background
Today, the storage capacity of smartphones is rapidly increasing in order to meet the storage requirements of different applications. In Android, storage is logically divided into two parts: internal storage and external storage (i.e., shared storage). Shared storage has become an important medium for application storage and sharing data, but the protection of shared storage is limited, which faces a series of security issues for shared storage. Much work has been done to date to indicate that stored files can leak sensitive information from users and expose victim users to attackers, indicating that the security problem of shared storage is very serious.
Unfortunately, application developers are more concerned with novel functions of applications in development to attract more users than with the security issues of shared storage. Thus, even though application developers have proposed some methods to deal with the security issues of shared storage, solutions may not be as effective as they expect. Since file manipulation may not be carefully organized, this may introduce some potential race conditions, resulting in file content being manipulated by malicious applications before the actual application uses it. Thus, real applications can be induced to perform some unexpected actions, revealing user privacy, causing property damage and even putting the user at risk.
Disclosure of Invention
In order to be able to learn the security problem existing in the Android shared storage at present so as to develop safer application programs, the invention provides a method and a system for detecting potential competition states when the Android shared storage is used.
On the one hand, the invention provides a potential competition state detection method when Android shared storage is used, which comprises the following steps:
Step 1: monitoring and recording file operation on shared storage of the Android terminal by using an Android. Os. FileObserver; wherein the recording information of each file operation includes: target file path, operation event type and occurrence time;
Step 2: sequencing and clustering all file operations according to the target file path and the occurrence time to obtain a plurality of file organization modes and a plurality of file operation modes;
step 3: constructing a competition state verification model;
Step 4: and (3) selecting a file organization mode and a file operation mode from the clustering result obtained in the step (2), and verifying whether the files on the shared storage have safety problems of potential competition states by using the constructed competition state verification model under the given file organization mode and the given file operation mode.
Further, step 2 specifically includes:
step 2.1: sequencing and clustering all file operations according to the target file path and the occurrence time to obtain an operation event sequence of each file, and filtering out files with only one operation event;
step 2.2: preprocessing the operation event sequence of each file to process the operation event sequence of each file into a short sequence list S= { S i|i∈{1,m}};si representing the ith operation sequence in the short sequence list S;
Step 2.3: for a short sequence list S of each file, detecting a time interval between any two adjacent operation sequences in the short sequence list S, and obtaining a file operation mode of the file according to the time interval;
step 2.4: and judging whether the file name of each file is a randomized file name or not, if so, renaming the file by adopting a given file naming mode, and obtaining a file organization mode of the file according to the new file name of the file.
Further, step 2.2 specifically includes:
Step A1: initializing list S filtered, list S temp, list S, and stack open; wherein S filtered is used for saving the filtered file sequence, S temp is used for saving the current file operation sequence, S is used for saving the short file operation sequence, and stack open is used for associating OPEN and CLOSE events;
Step A2: cycling through the original file operation sequence s raw; deduplication is performed on all non-OPEN, non-CLOSE events; saving the de-duplicated result and all OPEN and CLOSE events together in a list s filtered;
Step A3: cycling through s filtered, taking the step A4 to the step A7 as a cycle;
step A4: judging whether the time interval t j-1,j between the current file operation event e j and the adjacent event e j-1 is greater than a preset duration: if t j-1,j is not greater than the first preset duration, adding e j to s temp; otherwise, S temp is added to S, and S temp and stack open are reset, and e j is added to S temp;
Step A5: judging whether the file operation event e j is an OPEN event or a CLOSE event: if the event is OPEN, jumping to the step A6; if the event is a CLOSE event, jumping to the step A7;
step A6: e j is pushed to stack open;
Step A7: judging whether stack open is empty: if stack open is not empty, then popping an element, if stack open is empty after popping, then adding S temp to S and resetting S temp; if stack open is empty, then proceed to determine if the previously obtained sequence S last e S can add more events: if so, the remaining events are all added to s last and s temp is repeated; otherwise, the remaining sequence S temp is added to S and S temp is repeated;
step A8: after traversing all events in S filtered, a list s= { S i |i e {1, m } }, containing several short sequences of operations, is obtained.
Further, step 2.3 specifically includes:
Step B1: initializing a file operation mode set P and a current file operation mode sequence P current;
Step B2: cycling through each file operation sequence S i in the list S with steps B3 to B6 as a cycle;
Step B3: judging whether P is empty: if P is empty, then s i is added to P current and P current is added to P; if P is not null, executing the step B4;
step B4: acquiring a file operation mode P last added last time in P, and judging whether the current time interval between s i and P last is smaller than a second preset duration: if the number is smaller than the preset number, executing the step B5; otherwise, executing the step B6;
Step B5: judging whether p last can append more file operation events or not: if so, adding s i to p last; otherwise, assign s i to P current and add P current to P;
Step B6: setting P last to no longer add any file operation event, assigning s i to P current and adding P current to P;
step B7: after traversing all sequences in the list S, traversing each file operation mode in the P obtained at the moment again, comparing whether the number of OPEN and CLOSE events in the current file operation mode is equal or not, and if not, deleting the file operation mode;
step B8: and B8, traversing all file operation modes in the P, and obtaining a final file operation mode set P.
Further, step 2.4 specifically includes:
step C1: if the length of the file name is smaller than a given length threshold value or the file name does not contain letters, the file name of the file is a randomized file name; otherwise, continuing to execute the step C2;
step C2: dividing the file name into a plurality of substrings according to the Landmark Point; wherein the Landmark Point represents a position where other special characters other than letters and numbers are located;
Step C3: for each substring, counting the number of Switch points contained therein, count switch, and the number of Sharp points, count sharp, if Not smaller than a first given threshold or count sharp not smaller than a second given threshold, the substring name is a randomized substring name; wherein, switch Point represents the position where the current character is when changing from a letter to a number, or the position where the current character is when changing from a number to a letter; sharp Point represents the position where the current character belongs to a letter and its adjacent character belongs to a number, or where the current character belongs to a letter and its adjacent character belongs to a number;
Step C4: renaming the randomized substring names by adopting a given file naming mode; aiming at the non-randomized sub-string name, continuing to adopt an atomic string name;
Step C5: for each file, the names of all its substrings are recombined to get the new file name of the file.
Further, the verification process of the competition state verification model in step3 specifically includes:
Step 3.1: searching files belonging to the file organization mode on shared storage of the Android terminal, and generating fake files for launching attack based on competition states according to the searched files;
step 3.2: monitoring file operation on shared storage of the Android terminal, and replacing an original file by adopting a fake file according to the acquired file operation event and the selected file operation mode;
step 3.3: and after the original file is replaced, detecting whether the function of an application program related to the original file is normal, and if the detection results of all time windows in the selected file operation mode are normal, considering that a competition state does not exist.
On the other hand, the invention provides a potential competition state detection system when Android shared storage is used, which comprises a client and a server;
The client is operated on the Android terminal and used for monitoring and recording file operation on the shared storage of the Android terminal by utilizing an Android. Os. FileObserver and uploading recording information to the server; wherein the recording information of each file operation includes: target file path, operation event type and occurrence time;
The server receives and stores record information from all the clients; sequencing and clustering all file operations according to the target file path and the occurrence time to obtain a plurality of file organization modes and a plurality of file operation modes; and constructing a competition state verification model, and verifying whether the files on the shared storage have potential competition state safety problems by using the constructed competition state verification model under a given file organization mode and a given file operation mode.
The invention has the beneficial effects that:
The method and the system for detecting the potential competition state can effectively detect the potential competition state on the Android terminal shared storage, so that references are provided for safety problems to be considered when application program developers use the Android shared storage, and the safety of the Android terminal shared storage file is improved.
Drawings
Fig. 1 is a schematic flow chart of a method for detecting a potential competition state when Android shared storage is used in the embodiment of the invention;
FIG. 2 is a schematic diagram illustrating a relationship between file operation events and time on a shared storage according to an embodiment of the present invention;
FIG. 3 is a schematic diagram of log records of file operation events according to an embodiment of the present invention;
FIG. 4 is a schematic diagram of a randomized file name and renaming thereof according to an embodiment of the invention;
fig. 5 is a schematic structural diagram of a potential competition state detection system when Android shared storage is used according to an embodiment of the present invention;
FIG. 6 is a schematic diagram illustrating the duty cycle of various file operation events in the collected data according to an embodiment of the present invention;
FIG. 7 is a diagram illustrating the number of files for different numbers of "close_ NOWRITE" events provided by an embodiment of the present invention;
FIG. 8 is a statistical chart of the first 200 file organization patterns provided by an embodiment of the present invention;
FIG. 9 is a schematic diagram of a file containing different number of file operation modes as a percentage of the total file according to an embodiment of the present invention;
FIG. 10 is a statistical diagram of time window sizes in different file modes of operation according to an embodiment of the present invention;
FIG. 11 is a schematic diagram of a file operation performed by only one thread according to an embodiment of the present invention.
Detailed Description
For the purpose of making the objects, technical solutions and advantages of the present invention more apparent, the technical solutions in the embodiments of the present invention will be clearly described below with reference to the accompanying drawings in the embodiments of the present invention, and it is apparent that the described embodiments are some embodiments of the present invention, but not all embodiments. All other embodiments, which can be made by those skilled in the art based on the embodiments of the invention without making any inventive effort, are intended to be within the scope of the invention.
As shown in fig. 1, an embodiment of the present invention provides a method for detecting a potential competition state when Android shared storage is used, including the following steps:
S101: monitoring and recording file operation on shared storage of the Android terminal by using an Android. Os. FileObserver; the record information of each file operation, as shown in table 1, includes: target file path, operation event type and occurrence time;
Table 1 gathers data items for file manipulation events
In particular, the code analysis method is a conventional analysis method commonly used for understanding the working mechanism of an application program, but for some reasons, the method is not suitable for obtaining detailed information of file operations on a shared storage, such as: 1) The file processing code may come from an external or third party library and cannot be obtained in advance; 2) Codes in the issued apk file may be confused or unsharpened, and code analysis is difficult to perform; 3) The target file path information can come from the Internet or be encrypted, so that the real target file is difficult to accurately identify; 4) The code analysis method cannot provide any time information on file operations, etc. Therefore, in the embodiment of the invention, the Android. Os. FileObserver is adopted to monitor and record the file operation on the shared storage of the Android terminal. As shown in fig. 4, the android. Os. Fileoffserver can directly obtain information about where, when, and how the file operates.
S102: sequencing and clustering all file operations according to the target file path and the occurrence time to obtain a plurality of file organization modes and a plurality of file operation modes;
specifically, the method specifically comprises the following substeps:
s1021: sequencing and clustering all file operations according to the target file path and the occurrence time to obtain an operation event sequence of each file, and filtering out files with only one operation event;
In particular, a single file operation event e may not have sufficient information to analyze the potential race condition. Notably, when an application reads or writes a file, it triggers a series of operational events s raw＝{ei |i ε {1, n }, as shown in FIG. 2 and Table 2. Thus, once the sequence of file manipulation events s raw is established, it can be inferred how the application wants to process the file. As shown in fig. 3, the sequence of file operation events can be reconstructed by sorting and clustering all file operations according to the occurrence time and the absolute path of the file.
TABLE 2 behavior and related File manipulation events
In table 2, 1 these file operation events are derived from Android 9, and the different Android versions have only small differences in the file operation events; 2 The file operation event ATTRIB may not occur in certain Android versions; 3 The label 'x' indicates that the relevant event may occur more than once.
S1022: preprocessing the operation event sequence of each file to process the operation event sequence of each file into a short sequence list S= { S i|i∈{1,m}};si representing the ith operation sequence in the short sequence list S;
In particular, it is common for an application to operate a file multiple times (e.g., each time the application is activated), which results in a long sequence of file operation events. To better understand each operation on this file, the retrieved long file operation event sequence s raw needs to be preprocessed.
S1023: for a short sequence list S of each file, detecting a time interval between any two adjacent operation sequences in the short sequence list S, and obtaining a file operation mode of the file according to the time interval;
Specifically, in conjunction with the relationship of file operation events, step S1022 has split the long file operation sequence S raw into a short sequence s= { S i |i e {1, m }. However, these short sequences still cannot support further analysis due to little consideration of time information. When a function is activated, the relevant files are operated continuously for a short time, as shown in fig. 2, the time interval between these events is not too long. The time information plays an important role in the extraction file operation mode. Therefore, this step makes full use of the time information when extracting the file operation mode.
S1024: and judging whether the file name of each file is a randomized file name or not, if so, renaming the file by adopting a given file naming mode, and obtaining a file organization mode of the file according to the new file name of the file.
S103: constructing a competition state verification model;
S104: and selecting a file organization mode and a file operation mode from the clustering result obtained in the step S102, and verifying whether the files on the shared storage have safety problems of potential competition states by using the constructed competition state verification model under the given file organization mode and the given file operation mode.
On the basis of the above embodiment, in the embodiment of the present invention, as a possible implementation manner, step S1022 in the above embodiment specifically includes the following substeps:
Step A1: initializing list S filtered, list S temp, list S, and stack open; wherein S filtered is used for saving the filtered file sequence, S temp is used for saving the current file operation sequence, S is used for saving the short file operation sequence, and stack open is used for associating OPEN and CLOSE events;
Step A2: cycling through the original file operation sequence s raw; deduplication is performed on all non-OPEN, non-CLOSE events; saving the de-duplicated result and all OPEN and CLOSE events together in a list s filtered;
Step A3: cycling through s filtered, taking the step A4 to the step A7 as a cycle;
step A4: judging whether the time interval t j-1,j between the current file operation event e j and the adjacent event e j-1 is greater than a preset duration: if t j-1,j is not greater than the first preset duration, adding e j to s temp; otherwise, S temp is added to S, and S temp and stack open are reset, and e j is added to S temp;
Step A5: judging whether the file operation event e j is an OPEN event or a CLOSE event: if the event is OPEN, jumping to the step A6; if the event is a CLOSE event, jumping to the step A7;
step A6: e j is pushed to stack open;
Step A7: judging whether stack open is empty: if stack open is not empty, then popping an element, if stack open is empty after popping, then adding S temp to S and resetting S temp; if stack open is empty, then proceed to determine if the previously obtained sequence S last e S can add more events: if so, the remaining events are all added to s last and s temp is repeated; otherwise, the remaining sequence S temp is added to S and S temp is repeated;
step A8: after traversing all events in S filtered, a list s= { S i |i e {1, m } }, containing several short sequences of operations, is obtained.
Specifically, the pretreatment process mainly comprises two steps: 1) Merging the continuously repeated file operation events; 2) Splitting the file operation sequence.
1) The continuously repeated file operation events are merged. In the acquired file operation events, it can be seen that when an application program reads and writes a file, some ACCESS or MODIFY operation events occur. While these operational events may reflect the intent of the application, many constantly repeating ACCESS or modification operational events will result in different file operational modes, complicating further analysis.
It is noted that in most cases, the number of ACCESS or MODIFY events is determined by the operating system. Taking the MODIFY operation event as an example, no matter how the application writes to the file, the MODIFY event will only occur when the data is actually written to the physical storage medium.
Since OPEN, CLOSE (including close_ NOWRITE and close_write) events may provide some clues about potential race conditions, as shown in step A2. In addition to OPEN, close_ NOWRITE, and close_write operation events, this step reduces the number of consecutively repeated operation events of the same type to one.
2) Splitting the file operation sequence. Splitting the file operation sequence. As shown in FIG. 2, OPEN and CLOSE events occur sequentially as the application manipulates files. In this section, this relationship between OPEN and CLOSE events is leveraged to split the file operation sequence (as shown in steps A4 and A5).
But there is also a case to be considered, namely: the client may occasionally stop working, which may miss some file manipulation events. When OPEN and CLOSE operation events are missed, it is difficult to couple all acquired OPEN and CLOSE operation events, which can result in incomplete sequences, which is addressed by step A7.
If the previously obtained sequence s last can append more file manipulation events, the incomplete sequence is appended to the previous s last. Otherwise, it is only needed to put it into S. If the client or file owner application stops for a period of time (e.g., 10 minutes), the time interval t j-1,j between the two operational events e j-1 and e j will be longer than 10 minutes. In this case, e j-1 and e j do not belong to the same file operation sequence. This case is handled in advance as shown in step A4.
On the basis of the above embodiments, in the embodiment of the present invention, as an implementation manner, the step S1023 specifically includes the following substeps:
Step B1: initializing a file operation mode set P and a current file operation mode sequence P current;
Step B2: cycling through each file operation sequence S i in the list S with steps B3 to B6 as a cycle;
Step B3: judging whether P is empty: if P is empty, then s i is added to P current and P current is added to P; if P is not null, executing the step B4;
step B4: acquiring a file operation mode P last added last time in P, and judging whether the current time interval between s i and P last is smaller than a second preset duration: if the number is smaller than the preset number, executing the step B5; otherwise, executing the step B6;
Step B5: judging whether p last can append more file operation events or not: if so, adding s i to p last; otherwise, assign s i to P current and add P current to P;
Step B6: setting P last to no longer add any file operation event, assigning s i to P current and adding P current to P;
step B7: after traversing all sequences in the list S, traversing each file operation mode in the P obtained at the moment again, comparing whether the number of OPEN and CLOSE events in the current file operation mode is equal or not, and if not, deleting the file operation mode;
step B8: and B8, traversing all file operation modes in the P, and obtaining a final file operation mode set P.
Specifically, once the time interval t i,i+1 between the two file operation sequences s i and s i+1 is less than the second preset duration (for example, the second preset duration=5 seconds), it is necessary to add s i and s i+1 to the same file operation mode (see step B5). Otherwise, s i and s i+1 belong to different modes of operation (see step B6). In addition, considering the missing file operation event referred to above, the incomplete file operation mode is filtered out in this embodiment (see step B7).
On the basis of the above embodiments, in the embodiment of the present invention, as an implementation manner, the step S1024 specifically includes the following sub-steps:
step C1: if the length of the file name is smaller than a given length threshold value or the file name does not contain letters, the file name of the file is a randomized file name; otherwise, continuing to execute the step C2;
Step C2: dividing the file name into a plurality of substrings according to the Landmark Point; wherein the Landmark Point represents a position where other special characters other than letters and numbers are located; points of this type of Landmark Point may indicate the structure of the file name, since in most cases they are used to link different strings.
Step C3: for each substring, counting the number of Switch points contained therein, count switch, and the number of Sharp points, count sharp, ifNot smaller than a first given threshold or count sharp not smaller than a second given threshold, the substring name is a randomized substring name; where Switch Point represents the position where the current character is when changing from letter to number, or where the current character is when changing from number to letter, such as "a0", "9C", this will result in a series of Switch points due to the random occurrence of letters and numbers. Sharp Point represents the position where the current character belongs to a letter and its neighbor belongs to a number, or where the current character belongs to a letter and its neighbor belongs to a number, such as "A7D", "8c4".
Specifically, for a long string, there may be multiple Switch Points even without randomization. Thus, in this step, use is made ofAs an index, instead of directly using count switc h.
Step C4: renaming the randomized substring names by adopting a given file naming mode; aiming at the non-randomized sub-string name, continuing to adopt an atomic string name;
For example, if a substring is randomly generated, we shorten it with an "[ n ]" sign, where n represents the number of characters. Otherwise, we preserve the original content. LandmarkPoints still exists during this process. As shown in fig. 4, we have established a file naming scheme. Notably, the file path contains directory names and file names, and we can obtain an organization pattern of files by constructing a naming pattern for each portion of the file path. So far we can understand how application developers organize files on shared storage and can further organize the data obtained.
Step C5: for each file, the names of all its substrings are recombined to get the new file name of the file.
In particular, file manipulation events occur on various files. Analyzing all files is a tedious task. To address this challenge, these files have been classified in step S1021. From the classification result, it is found that files having similar naming patterns share similar file processes in one directory. Meanwhile, for some catalogues, the application program can give different file names according to different Android terminal devices and different users. Considering that the operation event comes from different Android terminal devices, the naming mode of each file needs to be known so as to be capable of carrying out further classification tasks on the basis.
By investigation of the collected file names, it was found that the file names can be divided into two categories: (1) Naming by meaningful words, such as "logic", "wall", "purchase", etc.; (2) The dynamically generated string is named using some algorithm (e.g., MD5 algorithm) based on some clue (e.g., user ID or device ID). Analyzing the first case is relatively easy, as it can make full use of the characteristics of the same string and the same location in the file system; however, the analysis process of the second case has a great difficulty, and the step mainly solves the difficulty.
The file name of the second case is composed of a random number C number, a random letter C letter, and some special marks C mark (e.g., "_", "-", etc.). Since it is difficult to predict where letters appear or where numbers appear, the present embodiment attempts to use some statistical index to determine whether the file name is random.
In fig. 4, switch Point, sharp Point, and Landmark Point are illustrated.
On the basis of the above embodiments, in the embodiment of the present invention, as an implementation manner, the step S103 specifically includes the following substeps:
s1031: searching files belonging to the file organization mode on shared storage of the Android terminal, and generating fake files for launching attack based on competition states according to the searched files;
s1032: monitoring file operation on shared storage of the Android terminal, and replacing an original file by adopting a fake file according to the acquired file operation event and the selected file operation mode;
s1033: and after the original file is replaced, detecting whether the function of an application program related to the original file is normal, and if the detection results of all time windows in the selected file operation mode are normal, considering that a competition state does not exist.
Example 2
Corresponding to the method for detecting the potential competition state when using Android shared storage, the embodiment of the invention also provides a system for detecting the potential competition state when using Android shared storage, as shown in fig. 5, which comprises the following steps: a client and a server;
The client is operated on the Android terminal and used for monitoring and recording file operation on the shared storage of the Android terminal by utilizing an Android. Os. FileObserver and uploading recording information to the server; wherein the recording information of each file operation includes: target file path, operation event type and occurrence time;
The server receives and stores record information from all the clients; sequencing and clustering all file operations according to the target file path and the occurrence time to obtain a plurality of file organization modes and a plurality of file operation modes; and constructing a competition state verification model, and verifying whether the files on the shared storage have potential competition state safety problems by using the constructed competition state verification model under a given file organization mode and a given file operation mode.
Specifically, the server comprises a data collection module, a data filtering module, a data linking module, a data sorting and clustering module and a data analysis module; the data collection module receives and stores record information from all the clients; the data filtering module filters noise data in the recorded information; the data link module links the filtered operation event according to the target file path; the data sequencing and clustering module sequences and clusters all file operations according to the target file path and the occurrence time; the data analysis module analyzes according to the sequencing and clustering result to obtain a plurality of file organization modes and a plurality of file operation modes; and constructing a competition state verification model, and verifying whether the files on the shared storage have safety problems of potential competition states by using the constructed competition state verification model under a given file organization mode and a given file operation mode.
It should be noted that, the system for detecting a potential competition state provided by the embodiment of the present invention is for implementing the above method embodiment, and the function thereof may specifically refer to the above method embodiment and is not described herein again.
In order to verify the effectiveness of the method of the invention, the invention is also provided with the following experimental data.
(1) Collecting data: file operations on the 10 volunteer smartphones were tracked continuously over 10 days. The client is installed and activated on the volunteer's smartphone, and will run in the background to monitor the entire Android shared storage, and not affect the normal use of the volunteer smartphone. A total of 5359339 file operation events, exceeding 105963 files, were collected. The detailed information of the obtained dataset is shown in table 3.
Table 3 data set details
In Table 3, both private and public directories are on shared storage; an "OPEN" event indicates that a file is to be read or written. The "close_ NOWRITE" event indicates that only the file is read.
In the experiment, no Personal Identification Information (PII) was collected, and only the relevant information was collected as shown in table 1. Devices are distinguished using a random ID that is generated when the client first runs on the volunteer's smartphone and does not need to obtain any hardware information on the handset. When classifying related file manipulation events with file names, we do not attempt to collect and use any file content on the volunteer smart phone. In this experiment we provided only some statistical information about the shared storage race status problem, and not any further information about victim applications and files. All experiments were performed on our test smartphones while we attempted to verify and exploit the potential competition status.
(2) Type of file operation event: as shown in FIG. 6, when the application uses shared storage, various types of file manipulation events are introduced, and the collected data set is composed of various different types of file manipulation events. By statistics, among these file manipulation events, the first 5 file manipulation events are MODIFY (40%), ACCESS (28%), OPEN (11%), close_ NOWRITE (10%), and close_write (7%). These several file operation events are 97% of all operation events. It can be seen that the number of modification and ACCESS operation events is much higher than the other events because the limited user space cache allows the application to continually repeat the same operations (e.g., modification or ACCESS) to process the entire file content. At the same time, the application program selection of whether to write data to the hard disk immediately also affects the number of MODIFY events.
Further, intuitively, the number of OPEN events should be equal to the total number of close_ NOWRITE and close_write events. But the number of OPEN events found by analysis of the collected data is much less than the total number of close_ NOWRITE and close_write events. This is because the smartphone may stop the client while it is running in the background to save energy. In this case, the client may miss a portion of the file operation event prior to a manual restart.
(3) The occurrence position of the file operation event: android introduces two categories on shared storage (i.e./storage/emulated/0 /): public directories (e.g.,/Picture /) and private directories (e.g.,/Android/data/app_package_name /). As shown in Table 3, 74.2% (78619) of the file accesses are located in the private directory and 25.8% (27344) of the file accesses are located in the public directory.
Also, when a file is processed, it may introduce some modification or ACCESS events. To understand the frequency of file usage, we performed individual statistics on OPEN events, as shown in table 3. In addition, in order to know the frequency of file reading, we also count the close_ NOWRITE event separately, and according to the statistics result, the minimum number of file reading operations can be obtained. From these two statistics we can see that files in public directories are used as frequently as files in private directories, indicating that public directories are still the most common choice for applications. It should be noted that the applications granted permission may still operate on any file on the shared storage, and in the following sections, public and private directories, both referred to as "shared storage", are not explicitly distinguished unless otherwise specified.
(4) Target file path: although the dataset consists of data from different smartphones, a small portion of the files (8411,7.94%) have the same path on different smartphones and a large portion of the files (97552, 92.06%) use different paths, meaning that the developer follows his own standard in naming and organizing the files.
By analyzing the close_ NOWRITE event for different files, it can be known that most of the file content is accessed only without any modification. As shown in fig. 7, the number of operations per file in a large number of files is very limited, which is detrimental to further analysis, and in order to solve this problem, it is necessary to fully understand each complete path we have obtained.
(5) Naming mode of filename: the application program runs too many files, and it is impossible for an application program developer to manually name each file, and considering that the application program developer names files and directories according to its own naming mode, this section analyzes file names and directory names. The results are shown in Table 4.
As can be seen from Table 3, the file names consist mostly (96.28%) of letters (i.e., a-Z and A-Z), numbers (i.e., 0-9), and other specific symbols, with only small portions consisting of only a single character, e.g., case 1 (0.89%), case 2 (2.81%), and case 4 (0.02%). In these cases, the name in case 4 is actually composed of non-english characters, such as chinese, according to the survey. Obviously, it is difficult to obtain detailed information of each application naming mode.
TABLE 4 different organization of filenames
(6) File organization mode: the mention of dynamic random naming rules in section (5) presents a great challenge for understanding the relationships of the obtained files. Thus, to understand how these files are organized, dynamic random naming rules must first be processed. Considering that the absolute path of a file contains a directory name and a file name, an associated organizational schema is constructed by reconstructing a naming schema for each portion of the file path.
An application has a unified standard to organize files on different smartphones so that when different files share the same organization pattern, they mainly belong to a category. Of 97552 files, each file has a unique file path, we get 10395 organization patterns. As can be seen in FIG. 8, each of the first 200 organizational patterns covers at least 64 files, and the first 200 organizational patterns cover 72200 (74.01%) files in total, fully illustrating the effectiveness of these obtained organizational patterns. According to these organization patterns, we categorize these files.
However, due to some special naming patterns, there are still 7974 (8.17%) organizational patterns, each of which can only cover one file. The file in this case requires more effort to analyze the related operations. To solve this problem, we can learn some information through separate file manipulation events. In this section, we construct a sequence of file operations based on the time the event occurred to further understand the potential race condition.
(7) File operation mode: an application operates a file only when a particular function is activated, and the function is typically activated periodically. Thus, we split the file operation sequence into short pieces to extract the relevant operation modes. Notably, the running client may miss some operational events. However, considering that OPEN and CLOSE events occur in pairs, operating a file does not take too much time, we can further filter out incomplete file modes of operation.
As can be seen from fig. 9, in most cases a file is only processed by one mode of operation, which indicates that the file is used by only a single function. In fact, sometimes different functions (or applications) may operate on the same file, so there are also many files with multiple (from 2 to 103) modes of operation. Moreover, when one file is simultaneously operated by different functions, the number of file operation modes may be significantly increased.
In the obtained file operation mode, as shown in table 5, it is most common to open the file and then read it directly, i.e. case 1.
TABLE 5 first 30 File modes of operation
/>
It was mentioned above that in extracting the file operation mode, the operation event is split according to the size of the interval time, so that the possibility that the race condition exists is high even for case 1. This is also the case for other events with only one OPEN. As shown in fig. 10, in these cases we have studied the time windows in the rest of the cases in addition to the single OPEN event case, we have found that a significant number of time windows are sufficient for the third party application to do some of the operations on the file. The 21.41% time window is greater than 500ms and the average value of the entire time window is 1593ms. We will manually verify the potential race condition in a subsequent step.
Meanwhile, in cases 2,3,4, it can be seen that some files are read more than twice when reading their contents. In these cases, the time interval between OPEN events marked in table 5 also indicates the existence of a potential race condition.
(8) Effect of multithreading: in most cases, when an application program operates a file, in order to maintain the integrity of the content of the file, the current action needs to be completed before the subsequent action can be performed, as in the case when only one thread operates the file, as shown in fig. 11. But this still does not avoid simultaneous access of file content by multiple threads, such as case 22,24,26,27 in table 5. When multiple threads operate on a file at the same time, this will result in a series of file modes of operation, lacking an orderly, stable mode of operation, due to the lack of synchronous processing. Checking for potential race conditions is very challenging because it is difficult to determine the owner of each operational event. From the resulting mode of operation, it can be seen that a time window is common before the OPEN event. Since little is known about the specifics of application processing files, the manner in which each time window is checked to determine if the time window would have a potential race condition is employed and thereby to avoid the impact of multithreading as much as possible.
(9) The competition state verification model is constructed and verified, and the process is as follows:
A dummy file is prepared. Each function has special requirements on the file to be operated, and it is difficult to know the specific requirements in advance. To solve this problem, we make full use of existing files with the same file organization pattern. Once a file organization pattern is selected, files with the same file organization pattern are searched in the whole Android shared storage, and the files are used for generating fake files for attack.
The original file is replaced. Once the dummy file is ready, we begin to monitor files on the Android shared storage that have the same file organization pattern. And according to the acquired file operation event and the selected file operation mode, automatically testing the time windows one by replacing the original file. We use file operations move_to and move_from TO reduce the time cost of replacing files.
The subsequent workflow of the relevant application is checked. When the original file is replaced, we check if the relevant application is affected by tampering with the file. In fact, once the associated application has accepted the tampered file content, its functionality is affected. Therefore, according to the thought, whether the tampered file affects the normal functions of the application program is judged, so that whether the competition state exists is known. If this attempt fails, we will check the next time window in the selected file operation mode. When all time window attempts fail, we consider the race condition not to exist.
(10) And (5) manually verifying the result. Based on the verification model described above, we performed some manual experiments on files on shared storage. We note that different files have different effects on the relevant applications, some of which are observable and others are not. Since the acquisition of all details of the application processing and using each file is a labor intensive task, we randomly selected 33 files to verify the potential race condition. The effects of these documents are observable. Based on the verification result, we found that 31 files (93.94%) had a competitive security problem. An application may OPEN a file multiple times, but each time for a different purpose (e.g., checking file format, file integrity, using file content), thus hiding a certain race condition between OPEN events. In addition, the race condition is also common when files are shared between different applications. But successive OPEN events may make the time window too small to operate on the file content accordingly. It is this reason that results in failure of the verification process on the remaining 2 files.
Therefore, the potential competition state detection method and the potential competition state detection system can detect the potential competition state of the Android terminal shared storage, so that references are provided for safety problems to be considered when application program developers use the Android shared storage, and the safety of the Android terminal shared storage file is improved.
Finally, it should be noted that: the above embodiments are only for illustrating the technical solution of the present invention, and are not limiting; although the invention has been described in detail with reference to the foregoing embodiments, it will be understood by those of ordinary skill in the art that: the technical scheme described in the foregoing embodiments can be modified or some technical features thereof can be replaced by equivalents; such modifications and substitutions do not depart from the spirit and scope of the technical solutions of the embodiments of the present invention.

Claims (5)

1. The potential competition state detection method when Android shared storage is used is characterized by comprising the following steps:
Step 1: monitoring and recording file operation on shared storage of the Android terminal by using an Android. Os. FileObserver; wherein the recording information of each file operation includes: target file path, operation event type and occurrence time;
Step 2: sequencing and clustering all file operations according to the target file path and the occurrence time to obtain a plurality of file organization modes and a plurality of file operation modes; the method specifically comprises the following steps:
step 2.1: sequencing and clustering all file operations according to the target file path and the occurrence time to obtain an operation event sequence of each file, and filtering out files with only one operation event;
Step 2.2: preprocessing the operation event sequence S raw of each file to process the operation event sequence of each file into a short sequence list s= { S i|i∈{1,m}};si representing the ith operation sequence in the short sequence list S;
Step 2.3: for a short sequence list S of each file, detecting a time interval between any two adjacent operation sequences in the short sequence list S, and obtaining a file operation mode of the file according to the time interval;
Step 2.4: judging whether the file name of each file is a randomized file name or not, renaming the file by adopting a given file naming mode if the file name is the randomized file name, and obtaining a file organization mode of the file according to the new file name of the file;
Step 3: constructing a competition state verification model; the verification process of the competition state verification model specifically comprises the following steps:
Step 3.1: searching files belonging to the file organization mode on shared storage of the Android terminal, and generating fake files for launching attack based on competition states according to the searched files;
step 3.2: monitoring file operation on shared storage of the Android terminal, and replacing an original file by adopting a fake file according to the acquired file operation event and the selected file operation mode;
Step 3.3: after the original file is replaced, detecting whether the functions of the application programs related to the original file are normal, and if the detection results of all time windows in the selected file operation mode are normal, considering that a competition state does not exist;
Step 4: and (3) selecting a file organization mode and a file operation mode from the clustering result obtained in the step (2), and verifying whether the files on the shared storage have safety problems of potential competition states by using the constructed competition state verification model under the given file organization mode and the given file operation mode.
2. The method for detecting a potential competition state when Android shared storage is used as claimed in claim 1, wherein step 2.2 specifically includes:
Step A1: initializing list S filtered, list S temp, short sequence list S and stack open; wherein S filtered is used for storing a filtered file sequence, S temp is used for storing a current file operation sequence, a short sequence list S is used for storing a short file operation sequence, and stack open is used for associating OPEN and CLOSE events;
Step A2: cycling through the original file operation sequence s raw; deduplication is performed on all non-OPEN, non-CLOSE events; saving the de-duplicated result and all OPEN and CLOSE events together in a list s filtered;
Step A3: cycling through s filtered, taking the step A4 to the step A7 as a cycle;
Step A4: judging whether the time interval t j-1,j between the current file operation event e j and the adjacent event e j-1 is greater than a preset duration: if t j-1,j is not greater than the first preset duration, adding e j to s temp; otherwise, S temp is added to the short sequence list S, S temp and stack open are reset, and e j is added to S temp;
Step A5: judging whether the file operation event e j is an OPEN event or a CLOSE event: if the event is OPEN, jumping to the step A6; if the event is a CLOSE event, jumping to the step A7;
step A6: e j is pushed to stack open;
step A7: judging whether stack open is empty: if stack open is not empty, then popping an element, if stack open is empty after popping, then adding S temp to the short sequence list S and resetting S temp; if stack open is empty, then proceed to determine if the previously obtained sequence S last e S can add more events: if so, the remaining events are all added to s last and s temp is repeated; otherwise, adding the remaining sequence S temp to the short sequence list S and resetting S temp;
Step A8: after traversing all events in S filtered, a short sequence list s= { S i |i e {1, m } }, which contains several short operation sequences, is obtained.
3. The method for detecting a potential competition state when Android shared storage is used as claimed in claim 1, wherein step 2.3 specifically comprises:
Step B1: initializing a file operation mode set P and a current file operation mode sequence P current;
Step B2: traversing each file operation sequence S i in the short sequence list S in a circulating way, wherein the steps B3 to B6 are taken as a circulating way;
Step B3: judging whether P is empty: if P is empty, then s i is added to P current and P current is added to P; if P is not null, executing the step B4;
step B4: acquiring a file operation mode P last added last time in P, and judging whether the current time interval between s i and P last is smaller than a second preset duration: if the number is smaller than the preset number, executing the step B5; otherwise, executing the step B6;
Step B5: judging whether p last can append more file operation events or not: if so, adding s i to p last; otherwise, assign s i to P current and add P current to P;
Step B6: setting P last to no longer add any file operation event, assigning s i to P current and adding P current to P;
Step B7: after traversing all sequences in the short sequence list S, traversing each file operation mode in the P obtained at the moment again, comparing whether the number of OPEN and CLOSE events in the current file operation mode is equal or not, and deleting the file operation mode if the number of OPEN and CLOSE events in the current file operation mode is not equal;
step B8: and B8, traversing all file operation modes in the P, and obtaining a final file operation mode set P.
4. The method for detecting a potential competition state when Android shared storage is used as claimed in claim 1, wherein step 2.4 specifically comprises:
step C1: if the length of the file name is smaller than a given length threshold value or the file name does not contain letters, the file name of the file is a randomized file name; otherwise, continuing to execute the step C2;
step C2: dividing the file name into a plurality of substrings according to the Landmark Point; wherein the Landmark Point represents a position where other special characters other than letters and numbers are located;
Step C3: for each substring, counting the number of Switch points contained therein, count switch, and the number of Sharp points, count sharp, if Not smaller than a first given threshold or count sharp not smaller than a second given threshold, the substring name is a randomized substring name; wherein, switch Point represents the position where the current character is when changing from a letter to a number, or the position where the current character is when changing from a number to a letter; sharp Point represents the position where the current character belongs to a letter and its adjacent character belongs to a number, or where the current character belongs to a letter and its adjacent character belongs to a number; nameStr denotes a file name, length (nameStr) denotes a length of the file name;
Step C4: renaming the randomized substring names by adopting a given file naming mode; aiming at the non-randomized sub-string name, continuing to adopt an atomic string name;
Step C5: for each file, the names of all its substrings are recombined to get the new file name of the file.
5. The potential competition state detection system when Android shared storage is used is characterized by comprising a client and a server;
The client is operated on the Android terminal and used for monitoring and recording file operation on the shared storage of the Android terminal by utilizing an Android. Os. FileObserver and uploading recording information to the server; wherein the recording information of each file operation includes: target file path, operation event type and occurrence time;
The server receives and stores record information from all the clients; all file operations are sequenced and clustered according to the target file path and the occurrence time to obtain a plurality of file organization modes and a plurality of file operation modes, and the method specifically comprises the following steps: sequencing and clustering all file operations according to the target file path and the occurrence time to obtain an operation event sequence of each file, and filtering out files with only one operation event; preprocessing the operation event sequence S raw of each file to process the operation event sequence of each file into a short sequence list s= { S i|i∈{1,m}};si representing the ith operation sequence in the short sequence list S; for a short sequence list S of each file, detecting a time interval between any two adjacent operation sequences in the short sequence list S, and obtaining a file operation mode of the file according to the time interval; judging whether the file name of each file is a randomized file name or not, renaming the file by adopting a given file naming mode if the file name is the randomized file name, and obtaining a file organization mode of the file according to the new file name of the file; establishing a competition state verification model, and verifying whether the files on the shared storage have safety problems of potential competition states or not by using the established competition state verification model under a given file organization mode and a given file operation mode; the verification process of the competition state verification model specifically comprises the following steps: searching files belonging to the file organization mode on shared storage of the Android terminal, and generating fake files for launching attack based on competition states according to the searched files; monitoring file operation on shared storage of the Android terminal, and replacing an original file by adopting a fake file according to the acquired file operation event and the selected file operation mode; and after the original file is replaced, detecting whether the function of an application program related to the original file is normal, and if the detection results of all time windows in the selected file operation mode are normal, considering that a competition state does not exist.
CN202210163542.5A 2022-02-22 2022-02-22 Potential competition state detection method and system in Android shared storage Active CN114580016B (en)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN202210163542.5A CN114580016B (en) 2022-02-22 2022-02-22 Potential competition state detection method and system in Android shared storage

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN202210163542.5A CN114580016B (en) 2022-02-22 2022-02-22 Potential competition state detection method and system in Android shared storage

Publications (2)

Publication Number Publication Date
CN114580016A CN114580016A (en) 2022-06-03
CN114580016B true CN114580016B (en) 2024-04-26

Family

ID=81773098

Family Applications (1)

Application Number Title Priority Date Filing Date
CN202210163542.5A Active CN114580016B (en) 2022-02-22 2022-02-22 Potential competition state detection method and system in Android shared storage

Country Status (1)

Country Link
CN (1) CN114580016B (en)

Citations (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101482887A (en) * 2009-02-18 2009-07-15 北京数码视讯科技股份有限公司 Anti-tamper verification method for key data in database
KR20110042404A (en) * 2009-10-19 2011-04-27 한국과학기술원 System and method of detecting data races in openmp program, and recording medium storing the method thereon
CN102282542A (en) * 2008-10-14 2011-12-14 奇托尔·V·斯里尼瓦桑 TICC-paradigm to build formally verified parallel software for multi-core chips
CN103365776A (en) * 2013-06-28 2013-10-23 中国科学院计算技术研究所 Parallel system weak consistency verifying method and system based on deterministic replay
CN105607631A (en) * 2016-03-24 2016-05-25 辽宁工业大学 Batch process weak fault model control limit establishment method and weak fault monitoring method
CN109885489A (en) * 2019-01-31 2019-06-14 清华大学 Data contention detection method and device in driver
CN114008685A (en) * 2019-06-25 2022-02-01 辉达公司 Intersection region detection and classification for autonomous machine applications

Family Cites Families (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20130304996A1 (en) * 2012-05-09 2013-11-14 Nvidia Corporation Method and system for run time detection of shared memory data access hazards
US11526808B2 (en) * 2019-05-29 2022-12-13 The Board Of Trustees Of The Leland Stanford Junior University Machine learning based generation of ontology for structural and functional mapping
US11812277B2 (en) * 2020-02-07 2023-11-07 Qualcomm Incorporated Interference mitigation through silencing signals in shared radio frequency spectrum

Patent Citations (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN102282542A (en) * 2008-10-14 2011-12-14 奇托尔·V·斯里尼瓦桑 TICC-paradigm to build formally verified parallel software for multi-core chips
CN101482887A (en) * 2009-02-18 2009-07-15 北京数码视讯科技股份有限公司 Anti-tamper verification method for key data in database
KR20110042404A (en) * 2009-10-19 2011-04-27 한국과학기술원 System and method of detecting data races in openmp program, and recording medium storing the method thereon
CN103365776A (en) * 2013-06-28 2013-10-23 中国科学院计算技术研究所 Parallel system weak consistency verifying method and system based on deterministic replay
CN105607631A (en) * 2016-03-24 2016-05-25 辽宁工业大学 Batch process weak fault model control limit establishment method and weak fault monitoring method
CN109885489A (en) * 2019-01-31 2019-06-14 清华大学 Data contention detection method and device in driver
CN114008685A (en) * 2019-06-25 2022-02-01 辉达公司 Intersection region detection and classification for autonomous machine applications

Non-Patent Citations (3)

* Cited by examiner, † Cited by third party
Title
Shaoyong Du 等.Watch out for race condition attacks when using Android external storage.CCS'22：Proceedings of the 2022 ACM SIGSAC Conference on Computer and Communications Security.2022,891-904. *
Yulai Xie 等.P-Gaussian： Provenance-based Gaussian distribution for detecting instrusion behavior variants using high efficient and real time memory databases.IEEE Transactions on Dependable and Secure Computing.2019,第18卷(第6期),2658-2674. *
近场通信技术的安全研究进展与发展趋势;张玉清;王志强;刘奇旭;娄嘉鹏;姚栋;;计算机学报(第06期);1190-1207 *

Also Published As

Publication number Publication date
CN114580016A (en) 2022-06-03

Similar Documents

Publication Publication Date Title
CN106599686B (en) A kind of Malware clustering method based on TLSH character representation
Canfora et al. Detecting android malware using sequences of system calls
Pagani et al. Beyond precision and recall: understanding uses (and misuses) of similarity hashes in binary analysis
Bhat et al. Can computer forensic tools be trusted in digital investigations?
Walls et al. Forensic Triage for Mobile Phones with {DEC0DE}
EP2975873A1 (en) A computer implemented method for classifying mobile applications and computer programs thereof
Gül et al. A survey on anti-forensics techniques
KR100968126B1 (en) System for Detecting Webshell and Method Thereof
Yoon et al. A method and tool to recover data deleted from a MongoDB
CN112560031B (en) Lesovirus detection method and system
Lee et al. ExtSFR: scalable file recovery framework based on an Ext file system
Gonzalez et al. Authorship attribution of android apps
Alazab et al. Effective digital forensic analysis of the NTFS disk image
Pirch et al. Tagvet: Vetting malware tags using explainable machine learning
Fettaya et al. Detecting malicious PDF using CNN
Tang et al. Android malware detection based on deep learning techniques
CN114580016B (en) Potential competition state detection method and system in Android shared storage
CN108650229B (en) Network application behavior analysis and restoration method and system
Vahedi et al. Cloud based malware detection through behavioral entropy
Soltani et al. Developing software signature search engines using paragraph vector model: a triage approach for digital forensics
Alazab et al. Digital forensic techniques for static analysis of NTFS images
Joo et al. A reference database of Windows artifacts for file‐wiping tool execution analysis
Chang et al. File recovery of high-order clearing first cluster based on FAT32
Kayabaş et al. Cyber wars and cyber threats against mobile devices: Analysis of mobile devices
Goldstein Anomaly detection

Legal Events

Date Code Title Description
PB01 Publication
PB01 Publication
SE01 Entry into force of request for substantive examination
SE01 Entry into force of request for substantive examination
GR01 Patent grant
GR01 Patent grant