CN112286736B - Method for recovering equipment infected by suspicious application and related equipment - Google Patents
Method for recovering equipment infected by suspicious application and related equipment Download PDFInfo
- Publication number
- CN112286736B CN112286736B CN202011556461.9A CN202011556461A CN112286736B CN 112286736 B CN112286736 B CN 112286736B CN 202011556461 A CN202011556461 A CN 202011556461A CN 112286736 B CN112286736 B CN 112286736B
- Authority
- CN
- China
- Prior art keywords
- application
- file
- list
- monitoring
- recovery
- 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
Links
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
- G06F11/14—Error detection or correction of the data by redundancy in operation
- G06F11/1402—Saving, restoring, recovering or retrying
- G06F11/1415—Saving, restoring, recovering or retrying at system level
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
- G06F11/14—Error detection or correction of the data by redundancy in operation
- G06F11/1402—Saving, restoring, recovering or retrying
- G06F11/1446—Point-in-time backing up or restoration of persistent data
- G06F11/1458—Management of the backup or restore process
-
- 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/50—Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems
- G06F21/51—Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems at application loading time, e.g. accepting, rejecting, starting or inhibiting executable software based on integrity or source reliability
Abstract
One or more embodiments of the present specification provide a method of recovering a device infected by a suspicious application and related devices; the method comprises the following steps: firstly, the equipment with the recovery application is subjected to initialization operation of a white list and a monitoring list; then, when the monitoring list is not empty, triggering a recovery program in the recovery application, further, the recovery program queries other applications in the monitoring list in real time through the monitoring Activity and Service component, and further judging whether the device encounters hijacking behaviors of other applications; when the recovery application judges that the equipment encounters hijack behavior, checking whether the equipment is maliciously set with a locking password, and removing the password; and the password of the file encrypted maliciously is released and recovered. The scheme realizes effective hijack application, avoids property loss, and provides a simple and efficient execution scheme when malicious hijack viruses are difficult to be prevented from being infected in the same mode on the system level.
Description
Technical Field
One or more embodiments of the present disclosure relate to the field of computer technologies, and in particular, to a method for recovering a device infected by a suspicious application and a related device.
Background
Because the hijacking application and the virus manufacturing cost are low, the phenomenon that the hijacking equipment is used for hijacking property and carrying out strolling property is more and more, in the aspect of restraining the hijacking strolling application, because the modes for realizing hijacking such as window top-mounting are various, the condition that a user is infected with strolling virus by a system layer is difficult to avoid in the aspect of program development at present, the USB interface of the equipment can be shielded by hijacking software, and the equipment is often debugged by using the USB interface when being recovered after being infected with the hijacking virus, so that the recovery of the equipment and files thereof is difficult.
Based on this, a scheme for recovering the device and the file after the device is hijacked is needed, which can be realized quickly, simply and efficiently.
Disclosure of Invention
In view of this, one or more embodiments of the present disclosure are directed to a method for recovering a device infected by a suspicious application and a related device, so as to solve the problem that the device cannot be recovered or is difficult to recover after being hijacked by malicious hijacking software.
In view of the above, one or more embodiments of the present specification provide a device and file recovery method, including: the recovery application is installed when the android device leaves a factory and is pre-installed, the recovery application is set to have a root authority in an android system in a default mode, the installed recovery application establishes a white list and a monitoring list in the device system, and initialization operation of the white list and the monitoring list is carried out; the monitoring list after the initialization operation is empty, when the monitoring list is not empty, a recovery program in the recovery application is triggered, and the specific triggering operation is realized by monitoring the state change of other application programs; after the recovery program is triggered, whether the equipment is hijacked or not is judged according to the fact that the Activity and Service components in the four android components are inquired in real time; when the recovery program judges that the equipment is hijacked, the operation of the Activity and Service components is immediately terminated, and the maliciously tampered locking machine password is forcibly deleted by utilizing the root authority, so that the automatic recovery of the equipment is realized; and acquiring a key of the encrypted file by calling the log file of the program, and automatically decrypting and recovering the maliciously encrypted file.
Based on the same inventive concept, one or more embodiments of the present specification further provide an apparatus for recovering a device infected by a suspicious application, including:
a listening module configured to: in response to monitoring an event of installing a new application on the equipment, performing static detection on the new application, and adding information of the detected malicious application to a monitoring list;
a trigger module configured to: in response to determining that the monitoring list is not empty, periodically querying a running process on the device; and, in response to determining that the process is relevant to a monitoring application in the monitoring list, checking whether the device is set with a malicious lock password;
a device recovery module configured to: in response to determining that the device is set with a malicious lock password, terminating the running of the process and deleting a lock password file on the device under a first predetermined directory to restore the device;
when the recovery application is run on the device for the first time, the monitoring list is initialized to be empty, and the white list is initialized to contain information of all applications installed on the device.
Based on the same inventive concept, one or more embodiments of the present specification further provide an electronic device, which includes a memory, a processor, and a computer program stored in the memory and executable on the processor, and when the processor executes the program, the method for recovering a device infected by a suspicious application is implemented as described in any one of the above.
Based on the same inventive concept, one or more embodiments of the present specification also provide a non-transitory computer-readable storage medium, wherein the non-transitory computer-readable storage medium stores computer instructions for causing the computer to perform the method of recovering a device infected with a suspicious application as described above.
As can be seen from the above, the method for recovering a device infected by a suspicious application and the related device provided in one or more embodiments of the present specification, based on the components of the android system, the Xposed framework and the autonomously written Sandbox module, comprehensively consider the device permissions, recover the device and the file in a recovery manner, have the characteristics of simple and fast user operation, effectively improve the recovery efficiency of hijacking the device, implement efficient recovery operation of the device in multiple hijacking manners such as USB interfaces, and avoid property loss of the user.
Drawings
In order to more clearly illustrate one or more embodiments or prior art solutions of the present specification, the drawings that are needed in the description of the embodiments or prior art will be briefly described below, and it is obvious that the drawings in the following description are only one or more embodiments of the present specification, and that other drawings may be obtained by those skilled in the art without inventive effort from these drawings.
FIG. 1 is a flow diagram illustrating a method for recovering a device infected with a suspicious application according to one or more embodiments of the present disclosure;
FIG. 2 is a block diagram of an apparatus for recovering a device infected by a suspicious application according to one or more embodiments of the present disclosure;
FIG. 3 is a system framework diagram of a recovery application in accordance with one or more embodiments of the disclosure;
FIG. 4 is a schematic diagram of a device recovery in accordance with one or more embodiments of the present disclosure;
FIG. 5 is a schematic diagram of file restoration in accordance with one or more embodiments of the present description;
fig. 6 is a schematic structural diagram of an electronic device according to one or more embodiments of the present disclosure.
Detailed Description
For the purpose of promoting a better understanding of the objects, aspects and advantages of the present disclosure, reference is made to the following detailed description taken in conjunction with the accompanying drawings.
It is to be noted that unless otherwise defined, technical or scientific terms used in one or more embodiments of the present specification should have the ordinary meaning as understood by those of ordinary skill in the art to which this disclosure belongs. The word "comprising" or "comprises", and the like, means that the element or item listed before the word covers the element or item listed after the word and its equivalents, but does not exclude other elements or items.
As described in the background section, existing methods of recovering from a device infected with a suspicious application also have difficulty meeting the needs of the user of the hijacked device. In carrying out the present disclosure, the applicant has found that the main problems of the existing methods for recovering a device infected by a suspicious application are: in the face of various hijacking applications, the hijacking sections are poor in level, it is difficult to prevent users from infecting the Legionella virus in a unified way on the program development level, and the hijacking software can shield the USB interface of the equipment, and the equipment is often debugged by using the USB interface when being recovered after infecting the Legionella virus, which makes the recovery of the equipment and the files thereof extremely difficult and even impossible. Aiming at complex hijack means, many existing recovery schemes often need professional technical personnel to perform recovery operation, and for common users, great difficulty also exists in technical implementation.
In view of this, one or more embodiments of the present disclosure provide a method for recovering a device infected by a suspicious application, and specifically, when an android device leaves a factory and is pre-installed, a recovery application of the present disclosure is installed, and the recovery application is set as having a root authority in an android system by default, and the installed recovery application establishes a white list and a monitoring list in the device system, and performs an initialization operation of the white list and the monitoring list; the monitoring list after the initialization operation is empty, when the monitoring list is not empty, a recovery program in the recovery application is triggered, and the specific triggering operation is realized by monitoring the state change of other application programs; after the recovery program is triggered, whether the equipment is hijacked or not is judged according to the fact that the Activity and Service components in the four android components are inquired in real time; when the recovery program judges that the equipment is hijacked, the operation of the Activity and Service components is immediately terminated, and the maliciously tampered locking machine password is forcibly deleted by utilizing the root authority, so that the automatic recovery of the equipment is realized; and acquiring a key of the encrypted file by calling the log file of the program, and automatically decrypting and recovering the maliciously encrypted file.
The biometric features related to biometric identification in the embodiments of the present specification may include, for example, eye features, voice prints, fingerprints, palm prints, heart beats, pulse, chromosomes, DNA, human teeth bites, and the like. Wherein the eye pattern may include biological features of the iris, sclera, etc.
The technical method of one or more embodiments of the present specification is described in detail below by specific embodiments, and specifically with reference to the system framework diagram of the recovery application shown in fig. 3.
Referring to fig. 1, a method for recovering a device infected by a suspicious application according to one embodiment of the present specification includes the following steps:
and S101, responding to the monitored event of installing the new application on the equipment, and performing static detection on the new application to obtain a static detection result.
In this embodiment, based on the overall consideration of the security of the user equipment, the recovery application loaded in the android system is firstly defaulted to be a pre-installed application when installed, that is, the recovery application is provided and installed when the device is shipped from a factory, and when installed, the recovery application is default to have the highest authority of the android system and has a permanent term, that is, a permanent root authority.
As shown in fig. 3, the recovery application is installed in the device, and when the device is run for the first time, the initial running will be immediately performed, including: establishing a white list and a monitoring list in the equipment; and initializing a white list and a monitoring list. The initialization operation of the white list is to add all the other installed applications in the device into the white list, and since the recovered application defaults to a pre-installed application when the device leaves a factory in this embodiment, it may be defaulted that all the other installed applications in the device are non-hijacking applications; based on the setting of the installation environment, the initialization operation of the monitoring list is only required to keep the list blank.
In this step, as shown in fig. 3, after the monitoring list is initialized, first, the recovery application will monitor the state changes of all other applications in the device. Specifically, a Java class listener written autonomously and inherited from BroadcastReceiver, one of four android components, is utilized: and an Applesener rewrites the onRecocece () method according to the monitoring requirement to realize the monitoring of the state change. The state change includes: installation and uninstallation of other applications; in the present embodiment, the program appllistener declares that an event to be monitored is registered in an android manifest (android development file) in advance, and the declarations are respectively: the method comprises the steps of representing an installed ADDED and representing an uninstalled REMOVED operation, so that when an application carries out the installation and uninstallation operations, an onReceive () method of a program AppListerner in a recovery application can be triggered, the recovery application is made aware of the onReceive () method, and the purpose of monitoring all other applications is achieved.
Further, when the recovery application monitors that other applications are unloaded by the above method, the white list carries out the de-naming processing on the application;
when the recovery application monitors that other applications are installed in the above manner, an R-PackDroid tool is called to perform static detection on the newly installed application, and whether the newly installed application is malicious kidnapping lasso software or not can be judged according to the obtained detection result in the static detection manner.
Step S102, in response to the fact that the static detection result indicates that the new application is a suspicious application, adding information of the new application to a monitoring list.
In the embodiment of the present disclosure, based on the detection result of the static detection, when it is determined that the newly installed application is malicious kidnapping lasso software, the software information is added to the monitoring list, that is, the initialization state of the monitoring list that is empty is changed.
Step S103, in response to determining that the monitoring list is not empty, acquiring information of the running process on the device through periodic query.
In this disclosure, in combination with the framework flow of fig. 3, when the empty state of the monitoring list is changed, that is, the monitoring list is not empty, the operation of the recovery program in the recovery application is further triggered. And the triggered recovery program monitors all other applications in the monitoring list, and the monitoring operation is realized by regularly inquiring the other applications. Specifically, the recovery should be performed by regularly querying two major components currently running in the android system: whether at least one of Activity and Service is in an active state currently or not, and then judging whether the active states of the two large components are related to other application programs in the monitoring list or not, wherein the method is realized by judging whether the packet names of the applications to which the Activity or Service currently runs are consistent with the packet names of other applications in the monitoring list or not; in the embodiment of the present disclosure, the specific period of the timing query may be set to be 1 minute interval in the background server, or the time interval of the timing query may be changed according to specific needs and situations.
Step S104, responding to the fact that the process is determined to be related to the monitoring application in the monitoring list, and checking whether the equipment is set with a malicious machine locking password.
In the embodiment of the present disclosure, when the Activity or Service active state monitored by the recovery application is not related to other applications in the monitoring list, the monitoring of the state change of the other applications is continued; when the Activity or Service active state monitored by the recovery application is related to other applications in the monitoring list, the device is judged to be subjected to the hijacking behavior of other applications, the related Activity or Service is stopped, and whether the malicious password is set in the device is checked.
Step S105, in response to the fact that the malicious machine locking password is set on the equipment, the running of the process is terminated, and the machine locking password file under the first preset directory on the equipment is deleted, so that the equipment is recovered.
In this disclosure, on the basis that the hijacking judgment is made by the recovery program and a malicious lock password is set in the device after the check, the device is unlocked in combination with the device recovery diagram of fig. 4, specifically, based on the feature that the recovery program has root authority, the operation of deleting a password or a texture key file in a data/system/directory is performed. The data/system/directory is system configuration data, password files contained in the data/system/directory are lock password files, key files are lock graphic gesture files, and the two files in the data/system/directory are lock unlocking related files.
In this embodiment, the locking mode and the unlocking file of the locking machine are not specifically limited, and the locking mode may be the above-mentioned password or graphical gesture mode, or may be, for example: eye prints, fingerprints, facial recognition, biometric recognition and the like; the locking and unlocking file can be the password key file or the capture key file, and can also be other locking and unlocking files corresponding to the locking and unlocking modes.
In an embodiment of the present disclosure, with reference to fig. 3, for the foregoing embodiment, the method may further include: after terminating the running of the process, in response to determining that log files unrelated to all applications in the white list exist on the device in a second predetermined directory, obtaining a key and a list of maliciously encrypted files from one of the log files, and decrypting the maliciously encrypted file using the key.
Specifically, on the basis of hijack judgment made by the recovery program, in combination with the file recovery diagram of fig. 5, in this step, first, traversal/sdcard/directory is required, that is, all files in the device storage directory are acquired, and a log-suffix file, that is, a file representing specific change content of log information is acquired; the log suffix file contains the key for encrypting the file, the path of the encrypted file and other information related to the decryption operation. Log suffix files are formed by calling other applications by related API (application programming interface) in an Xpos framework and represent log information of the corresponding applications; the Sandbox module written by itself based on the Xposed framework can implement the hooking function of the relevant API, that is, the recovery program can hook the corresponding API parameter by the Sandbox. If the log suffix file does not exist under the/sdcard/directory, the file restore operation is ended.
Further, referring to fig. 5, if the obtained application package name corresponding to the log suffix file exists in the white list, the log suffix file is filtered, that is, the log suffix file is not processed; after the filtering operation is performed, if there are still log suffix files, and there are more than one log suffix files, the recovery application prompts the user to select a file to be processed next from the log suffix files until all the log suffix files are subjected to the filtering or selecting operation, where the purpose of selecting the log suffix files by the user is to prevent a benign application program of a non-hijacking behavior from being misoperated, in this embodiment, the selecting operation mode is not specifically limited, and may be selected by the user, or may be, for example: and (4) setting a program, and automatically selecting part or all of the programs. And further, obtaining a key and the encrypted file from all selected log suffix files, and performing decryption operation on each corresponding file by using the key.
In the disclosure, the sequence of the operation of automatically restoring the device and the operation of automatically restoring the file is not specifically limited, and only one of the two operations may be selected to be restored according to specific conditions, or the automatic restoration of the file is first selected and then the automatic restoration of the device is performed.
It can be seen that, in the method and the related device for recovering the device infected by the suspicious application according to one or more embodiments of the present specification, the device and the file are recovered based on the components of the android system, the Xposed frame and the autonomously written Sandbox module, by comprehensively considering the setting of the device authority, the operation of the recovery mode, and the like, and the method and the related device have the characteristics of simple and rapid user operation, effectively improve the recovery efficiency of hijacking devices, realize efficient recovery operation of the device in a plurality of hijacking modes such as USB interfaces, and avoid property loss of users.
It should be noted that the method of one or more embodiments of the present disclosure may be performed by a single device, such as a computer or server. The method of the embodiment can also be applied to a distributed scene and completed by the mutual cooperation of a plurality of devices. In such a distributed scenario, one of the devices may perform only one or more steps of the method of one or more embodiments of the present disclosure, and the devices may interact with each other to complete the method.
The foregoing description has been directed to specific embodiments of this disclosure. Other embodiments are within the scope of the following claims. In some cases, the actions or steps recited in the claims may be performed in a different order than in the embodiments and still achieve desirable results. In addition, the processes depicted in the accompanying figures do not necessarily require the particular order shown, or sequential order, to achieve desirable results. In some embodiments, multitasking and parallel processing may also be possible or may be advantageous.
Based on the same inventive concept, corresponding to any of the above embodiments, one or more embodiments of the present specification further provide a device for recovering a device infected by a suspicious application.
Referring to fig. 2, and in particular to the system framework diagram of the recovery application shown in fig. 3, the apparatus for recovering a device infected by a suspicious application includes:
a detection module S201 configured to: in response to monitoring an event of installing a new application on the equipment, performing static detection on the new application to obtain a static detection result;
a list update module S202 configured to: in response to determining that the static detection result indicates that the new application is a suspicious application, adding information of the new application to a monitoring list;
an acquisition module S203 configured to: in response to determining that the monitoring list is not empty, obtaining information of a process running on the device through periodic querying;
a checking module S204, responsive to determining that the process is related to a monitoring application in the monitoring list, checking whether the device is set with a malicious machine locking password;
a device recovery module S205 configured to: in response to the checking module determining that the device is set with a malicious lock password, terminating the running of the process and deleting a lock password file on the device under a first predetermined directory to recover the device;
when the recovery application is run on the device for the first time, the monitoring list is initialized to be empty, and the white list is initialized to contain information of all applications installed on the device.
The detection module S201 is specifically configured to: in this embodiment, based on the overall consideration of the security of the user equipment, the recovery application loaded in the android system is firstly defaulted to be a pre-installed application when installed, that is, the recovery application is provided and installed when the device is shipped from a factory, and when installed, the recovery application is default to have the highest authority of the android system and has a permanent term, that is, a permanent root authority.
As shown in fig. 3, the recovery application is installed in the device, and when the device is run for the first time, the initial running will be immediately performed, including: establishing a white list and a monitoring list in the equipment; and initializing a white list and a monitoring list. The initialization operation of the white list is to add all the other installed applications in the device into the white list, and since the recovered application defaults to a pre-installed application when the device leaves a factory in this embodiment, it may be defaulted that all the other installed applications in the device are non-hijacking applications; based on the setting of the installation environment, the initialization operation of the monitoring list is only required to keep the list blank.
In this step, as shown in fig. 3, after the monitoring list is initialized, first, the recovery application will monitor the state changes of all other applications in the device. Specifically, a Java class listener written autonomously and inherited from BroadcastReceiver, one of four android components, is utilized: and an Applesener rewrites the onRecocece () method according to the monitoring requirement to realize the monitoring of the state change. The state change includes: installation and uninstallation of other applications; in the present embodiment, the program appllistener declares that an event to be monitored is registered in an android manifest (android development file) in advance, and the declarations are respectively: the method comprises the steps of representing an installed ADDED and representing an uninstalled REMOVED operation, so that when an application carries out the installation and uninstallation operations, an onReceive () method of a program AppListerner in a recovery application can be triggered, the recovery application is made aware of the onReceive () method, and the purpose of monitoring all other applications is achieved.
Further, when the recovery application monitors that other applications are unloaded by the above method, the white list carries out the de-naming processing on the application;
when the recovery application monitors that other applications are installed in the above manner, an R-PackDroid tool is called to perform static detection on the newly installed application, and whether the newly installed application is malicious kidnapping lasso software or not can be judged according to the obtained detection result in the static detection manner.
The list updating module S202 is specifically configured to: and based on the detection result of the static detection, when the newly installed application is determined to be malicious kidnapping lasso software, adding the software information into the monitoring list, namely changing the initialization state of the monitoring list to be empty.
The obtaining module S203 is specifically configured to: in conjunction with the framework flow of fig. 3, when the empty state of the monitoring list is changed, that is, the monitoring list is not empty, the operation of the recovery program in the recovery application is further triggered. And the triggered recovery program monitors all other applications in the monitoring list, and the monitoring operation is realized by regularly inquiring the other applications. Specifically, the recovery should be performed by regularly querying two major components currently running in the android system: whether at least one of Activity and Service is in an active state currently or not, and then judging whether the active states of the two large components are related to other application programs in the monitoring list or not, wherein the method is realized by judging whether the packet names of the applications to which the Activity or Service currently runs are consistent with the packet names of other applications in the monitoring list or not; in the embodiment of the present disclosure, the specific period of the timing query may be set to be 1 minute interval in the background server, or the time interval of the timing query may be changed according to specific needs and situations.
The checking module S204 is specifically configured to: when the Activity or Service active state monitored by the recovery application is irrelevant to other applications in the monitoring list, continuing to monitor the state changes of the other applications; when the Activity or Service active state monitored by the recovery application is related to other applications in the monitoring list, the device is judged to be subjected to the hijacking behavior of other applications, the related Activity or Service is stopped, and whether the malicious password is set in the device is checked.
The device recovery module S205 is specifically configured to: and (3) performing hijacking judgment on the recovery program, and performing unlocking operation on the equipment by combining the equipment recovery schematic diagram of fig. 4 on the basis of finding that the equipment is provided with a malicious lock password after checking, specifically, based on the characteristic that the recovery program has root authority, executing the operation of deleting password. The data/system/directory is system configuration data, password files contained in the data/system/directory are lock password files, key files are lock graphic gesture files, and the two files in the data/system/directory are lock unlocking related files.
In this embodiment, the locking mode and the unlocking file of the locking machine are not specifically limited, and the locking mode may be the above-mentioned password or graphical gesture mode, or may be, for example: eye prints, fingerprints, facial recognition, biometric recognition and the like; the locking and unlocking file can be the password key file or the capture key file, and can also be other locking and unlocking files corresponding to the locking and unlocking modes.
In an embodiment of the present disclosure, with reference to fig. 3, for the foregoing embodiment, the method may further include:
the file decryption module S206 is specifically configured to: after terminating the running of the process, in response to determining that log files unrelated to all applications in the white list exist on the device in a second predetermined directory, obtaining a key and a list of maliciously encrypted files from one of the log files, and decrypting the maliciously encrypted file using the key.
Specifically, on the basis of hijack judgment made by the recovery program, in combination with the file recovery diagram of fig. 5, in this step, first, traversal/sdcard/directory is required, that is, all files in the device storage directory are acquired, and a log-suffix file, that is, a file representing specific change content of log information is acquired; the log suffix file contains the key for encrypting the file, the path of the encrypted file and other information related to the decryption operation. Log suffix files are formed by calling other applications by related API (application programming interface) in an Xpos framework and represent log information of the corresponding applications; the Sandbox module written by itself based on the Xposed framework can implement the hooking function of the relevant API, that is, the recovery program can hook the corresponding API parameter by the Sandbox. If the log suffix file does not exist under the/sdcard/directory, the file restore operation is ended.
Further, referring to fig. 5, if the obtained application package name corresponding to the log suffix file exists in the white list, the log suffix file is filtered, that is, the log suffix file is not processed; after the filtering operation is performed, if there are still log suffix files, and there are more than one log suffix files, the recovery application prompts the user to select a file to be processed next from the log suffix files until all the log suffix files are subjected to the filtering or selecting operation, where the purpose of selecting the log suffix files by the user is to prevent a benign application program of a non-hijacking behavior from being misoperated, in this embodiment, the selecting operation mode is not specifically limited, and may be selected by the user, or may be, for example: and (4) setting a program, and automatically selecting part or all of the programs. And further, obtaining a key and the encrypted file from all selected log suffix files, and performing decryption operation on each corresponding file by using the key.
In the disclosure, the sequence of the operation of automatically restoring the device and the operation of automatically restoring the file is not specifically limited, and only one of the two operations may be selected to be restored according to specific conditions, or the automatic restoration of the file is first selected and then the automatic restoration of the device is performed.
For convenience of description, the above devices are described as being divided into various modules by functions, and are described separately. Of course, the functionality of the modules may be implemented in the same one or more software and/or hardware implementations in implementing one or more embodiments of the present description.
The apparatus in the foregoing embodiment is used to implement the method for recovering the device infected by the suspicious application in any of the foregoing embodiments, and has the beneficial effects of the corresponding method embodiment, which are not described herein again.
Based on the same inventive concept, corresponding to any of the above embodiments, one or more embodiments of the present specification further provide an electronic device, which includes a memory, a processor, and a computer program stored in the memory and executable on the processor, and when the processor executes the program, the method for recovering a device infected by a suspicious application as described in any of the above embodiments is implemented.
Fig. 6 is a schematic diagram illustrating a more specific hardware structure of an electronic device according to this embodiment, where the electronic device may include: a processor 1010, a memory 1020, an input/output interface 1030, a communication interface 1040, and a bus 1050. Wherein the processor 1010, memory 1020, input/output interface 1030, and communication interface 1040 are communicatively coupled to each other within the device via bus 1050.
The processor 1010 may be implemented by a general-purpose CPU (Central Processing Unit), a microprocessor, an Application Specific Integrated Circuit (ASIC), or one or more Integrated circuits, and is configured to execute related programs to implement the technical solutions provided in the embodiments of the present disclosure.
The Memory 1020 may be implemented in the form of a ROM (Read Only Memory), a RAM (Random Access Memory), a static storage device, a dynamic storage device, or the like. The memory 1020 may store an operating system and other application programs, and when the technical solution provided by the embodiments of the present specification is implemented by software or firmware, the relevant program codes are stored in the memory 1020 and called to be executed by the processor 1010.
The input/output interface 1030 is used for connecting an input/output module to input and output information. The i/o module may be configured as a component in a device (not shown) or may be external to the device to provide a corresponding function. The input devices may include a keyboard, a mouse, a touch screen, a microphone, various sensors, etc., and the output devices may include a display, a speaker, a vibrator, an indicator light, etc.
The communication interface 1040 is used for connecting a communication module (not shown in the drawings) to implement communication interaction between the present apparatus and other apparatuses. The communication module can realize communication in a wired mode (such as USB, network cable and the like) and also can realize communication in a wireless mode (such as mobile network, WIFI, Bluetooth and the like).
It should be noted that although the above-mentioned device only shows the processor 1010, the memory 1020, the input/output interface 1030, the communication interface 1040 and the bus 1050, in a specific implementation, the device may also include other components necessary for normal operation. In addition, those skilled in the art will appreciate that the above-described apparatus may also include only those components necessary to implement the embodiments of the present description, and not necessarily all of the components shown in the figures.
The apparatus in the foregoing embodiment is used to implement the method for recovering the device infected by the suspicious application in any of the foregoing embodiments, and has the beneficial effects of the corresponding method embodiment, which are not described herein again.
Based on the same inventive concept, corresponding to any of the above-described embodiment methods, one or more embodiments of the present specification further provide a non-transitory computer-readable storage medium storing computer instructions for causing the computer to perform the method of recovering a device infected with a suspicious application as described in any of the above embodiments.
Computer-readable media of the present embodiments, including both non-transitory and non-transitory, removable and non-removable media, may implement information storage by any method or technology. The information may be computer readable instructions, data structures, modules of a program, or other data. Examples of computer storage media include, but are not limited to, phase change memory (PRAM), Static Random Access Memory (SRAM), Dynamic Random Access Memory (DRAM), other types of Random Access Memory (RAM), Read Only Memory (ROM), Electrically Erasable Programmable Read Only Memory (EEPROM), flash memory or other memory technology, compact disc read only memory (CD-ROM), Digital Versatile Discs (DVD) or other optical storage, magnetic cassettes, magnetic tape magnetic disk storage or other magnetic storage devices, or any other non-transmission medium that can be used to store information that can be accessed by a computing device.
The computer instructions stored in the storage medium of the above embodiment are used to enable the computer to execute the method for recovering the device infected by the suspicious application according to any of the above embodiments, and have the beneficial effects of the corresponding method embodiments, which are not described herein again.
Those of ordinary skill in the art will understand that: the discussion of any embodiment above is meant to be exemplary only, and is not intended to intimate that the scope of the disclosure, including the claims, is limited to these examples; within the spirit of the present disclosure, features from the above embodiments or from different embodiments may also be combined, steps may be implemented in any order, and there are many other variations of different aspects of one or more embodiments of the present description as described above, which are not provided in detail for the sake of brevity.
In addition, well-known power/ground connections to Integrated Circuit (IC) chips and other components may or may not be shown in the provided figures, for simplicity of illustration and discussion, and so as not to obscure one or more embodiments of the disclosure. Furthermore, devices may be shown in block diagram form in order to avoid obscuring the understanding of one or more embodiments of the present description, and this also takes into account the fact that specifics with respect to implementation of such block diagram devices are highly dependent upon the platform within which the one or more embodiments of the present description are to be implemented (i.e., specifics should be well within purview of one skilled in the art). Where specific details (e.g., circuits) are set forth in order to describe example embodiments of the disclosure, it should be apparent to one skilled in the art that one or more embodiments of the disclosure can be practiced without, or with variation of, these specific details. Accordingly, the description is to be regarded as illustrative instead of restrictive.
While the present disclosure has been described in conjunction with specific embodiments thereof, many alternatives, modifications, and variations of these embodiments will be apparent to those of ordinary skill in the art in light of the foregoing description. For example, other memory architectures (e.g., dynamic ram (dram)) may use the discussed embodiments.
It is intended that the one or more embodiments of the present specification embrace all such alternatives, modifications and variations as fall within the broad scope of the appended claims. Therefore, any omissions, modifications, substitutions, improvements, and the like that may be made without departing from the spirit and principles of one or more embodiments of the present disclosure are intended to be included within the scope of the present disclosure.
Claims (8)
1. A method of recovering a device infected with a suspicious application, the method performed by a recovery application on the device, comprising:
in response to monitoring an event of installing a new application on the equipment, performing static detection on the new application to obtain a static detection result;
in response to determining that the static detection result indicates that the new application is a suspicious application, adding information of the new application to a monitoring list;
in response to determining that the monitoring list is not empty, obtaining information of a process running on the device through periodic querying;
in response to determining that the process is associated with a monitoring application in the monitoring list, checking whether the device is set with a malicious lock password;
in response to determining that the device is set with a malicious lock password, terminating the running of the process and deleting a lock password file on the device under a first predetermined directory to restore the device;
after terminating execution of the process, in response to determining that log files exist on the device under a second predetermined directory that are not relevant to all applications in the white list, obtaining a key and a list of maliciously encrypted files from one of the log files and decrypting the maliciously encrypted file using the key,
when the recovery application is run on the device for the first time, the monitoring list is initialized to be empty, and the white list is initialized to contain information of all applications installed on the device.
2. The method according to claim 1, wherein the device runs under an Android operating system, and the process comprises an Activity component and/or a Service component.
3. The method of claim 2, wherein the first predetermined directory is/data/system/, and the lock password file comprises a password key file or a capture key file under the/data/system/directory.
4. The method of claim 2, wherein the second predetermined directory is/sdcard/, and wherein the log file is a file with an extension name log under/sdcard/directory.
5. The method of claim 4, wherein the log file is obtained by an APIHook tool under an Xpos frame.
6. An apparatus for recovering a device infected with a suspected application, the apparatus being installed on the device, comprising:
a detection module configured to: in response to monitoring an event of installing a new application on the equipment, performing static detection on the new application to obtain a static detection result;
a list update module configured to: in response to determining that the static detection result indicates that the new application is a suspicious application, adding information of the new application to a monitoring list;
an acquisition module configured to: in response to determining that the monitoring list is not empty, obtaining information of a process running on the device through periodic querying;
an inspection module configured to: in response to determining that the process is associated with a monitoring application in the monitoring list, checking whether the device is set with a malicious lock password;
a device recovery module configured to: in response to the checking module determining that the device is set with a malicious lock password, terminating the running of the process and deleting a lock password file on the device under a first predetermined directory to recover the device;
a file decryption module configured to: after the device recovery module terminates the running of the process, in response to determining that a log file exists on the device under a second predetermined directory that is unrelated to all applications in the white list, obtaining a key and a list of maliciously encrypted files from one of the log files and decrypting the maliciously encrypted file using the key,
when the device is started on the equipment for the first time, the monitoring list is initialized to be empty, and the white list is initialized to contain information of all applications installed on the equipment.
7. An electronic device comprising a memory, a processor and a computer program stored on the memory and executable by the processor, characterized in that the processor implements the method according to any of claims 1 to 5 when executing the computer program.
8. A non-transitory computer-readable storage medium storing computer instructions which, when executed by a computer, cause the computer to implement the method of any one of claims 1 to 5.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202011556461.9A CN112286736B (en) | 2020-12-25 | 2020-12-25 | Method for recovering equipment infected by suspicious application and related equipment |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202011556461.9A CN112286736B (en) | 2020-12-25 | 2020-12-25 | Method for recovering equipment infected by suspicious application and related equipment |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CN112286736A CN112286736A (en) | 2021-01-29 |
| CN112286736B true CN112286736B (en) | 2021-06-22 |
Family
ID=74426209
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN202011556461.9A Active CN112286736B (en) | 2020-12-25 | 2020-12-25 | Method for recovering equipment infected by suspicious application and related equipment |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN112286736B (en) |
Citations (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN108052415A (en) * | 2017-11-17 | 2018-05-18 | 中国科学院信息工程研究所 | A kind of malware detection platform quick recovery method and system |
| CN109977671A (en) * | 2019-03-14 | 2019-07-05 | 西安电子科技大学 | It is a kind of based on compiler modification Android screen locking type extort software detecting method |
| CN111092993A (en) * | 2020-03-20 | 2020-05-01 | 北京热云科技有限公司 | Method and system for detecting hijacking behavior of apk file |
| CN111125698A (en) * | 2019-11-28 | 2020-05-08 | 中金金融认证中心有限公司 | System and method for preventing interface hijacking in Android application |
Family Cites Families (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US8869274B2 (en) * | 2012-09-28 | 2014-10-21 | International Business Machines Corporation | Identifying whether an application is malicious |
-
2020
- 2020-12-25 CN CN202011556461.9A patent/CN112286736B/en active Active
Patent Citations (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN108052415A (en) * | 2017-11-17 | 2018-05-18 | 中国科学院信息工程研究所 | A kind of malware detection platform quick recovery method and system |
| CN109977671A (en) * | 2019-03-14 | 2019-07-05 | 西安电子科技大学 | It is a kind of based on compiler modification Android screen locking type extort software detecting method |
| CN111125698A (en) * | 2019-11-28 | 2020-05-08 | 中金金融认证中心有限公司 | System and method for preventing interface hijacking in Android application |
| CN111092993A (en) * | 2020-03-20 | 2020-05-01 | 北京热云科技有限公司 | Method and system for detecting hijacking behavior of apk file |
Non-Patent Citations (2)
| Title |
|---|
| Android平台下勒索软件的主动实时检测;陈祥云 等;《武汉大学学报（理学版）》;20171031;第63卷(第5期);第0、1.1、2节 * |
| 手机锁机病毒解锁清除教程;ASlien;《CSDN》;20170605;第1-4页 * |
Also Published As
| Publication number | Publication date |
|---|---|
| CN112286736A (en) | 2021-01-29 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| RU2454705C1 (en) | System and method of protecting computing device from malicious objects using complex infection schemes | |
| JP6317434B2 (en) | System and method for facilitating malware scanning using reputation indicators | |
| US7665139B1 (en) | Method and apparatus to detect and prevent malicious changes to tokens | |
| JP5933797B1 (en) | Log information generating apparatus and program, and log information extracting apparatus and program | |
| US20190147163A1 (en) | Inferential exploit attempt detection | |
| JP2014038596A (en) | Method for identifying malicious executable | |
| EP2937807B1 (en) | Monitoring device and monitoring method | |
| CN111191226B (en) | Method, device, equipment and storage medium for determining program by utilizing right-raising loopholes | |
| EP3270318B1 (en) | Dynamic security module terminal device and method for operating same | |
| CN109815700B (en) | Application program processing method and device, storage medium and computer equipment | |
| CN109800577B (en) | Method and device for identifying escape safety monitoring behavior | |
| Jaiswal et al. | Android gaming malware detection using system call analysis | |
| CN113632432B (en) | Method and device for judging attack behaviors and computer storage medium | |
| CN105426751A (en) | Method and device for preventing system time from being tampered | |
| KR101974989B1 (en) | Method and apparatus for determining behavior information corresponding to a dangerous file | |
| CN114595462A (en) | Data processing method and device | |
| US11314859B1 (en) | Cyber-security system and method for detecting escalation of privileges within an access token | |
| KR101500512B1 (en) | Device and method for securing computer | |
| US11251976B2 (en) | Data security processing method and terminal thereof, and server | |
| CN113472789A (en) | Attack detection method, attack detection system, storage medium and electronic equipment | |
| CN112286736B (en) | Method for recovering equipment infected by suspicious application and related equipment | |
| US10880316B2 (en) | Method and system for determining initial execution of an attack | |
| CN108647516B (en) | Method and device for defending against illegal privilege escalation | |
| CN115758353A (en) | Application program protection method, device, equipment and storage medium | |
| CN106856477B (en) | Threat processing method and device based on local area network |
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 |