Testing methods, devices and electronic equipment for information hijacking

Abstract

This invention discloses a method, apparatus, and electronic device for testing information hijacking. The method includes: receiving a test request from a target program, wherein the test request requests testing whether the program under test has an information hijacking risk; responding to the test request and identifying the target program on the target device; using the target program to perform an information hijacking risk test on the program under test through the semi-transparent attribute window of the target device, and obtaining the test results. This invention solves the technical problem of the limited applicability of related technologies that use Hook frameworks or listener window activities to detect information hijacking risks on Android devices.

Description

TECHNICAL FIELD

[0001] The present application relates to the field of information security, and in particular, to a method and device for testing information hijacking and an electronic device. BACKGROUND

[0002] With the development of the Android system application, it is used by more and more people. Information theft, information collection and other events are not only used in PC (personal computer) end devices and network devices, but also occur in mobile end devices. Network security incidents caused by Android system vulnerabilities occur frequently, new security vulnerabilities are continuously exploited, and the amount of loss increases year by year.

[0003] At the same time, the fingerprint recognition technology of the Android phone is applied in various fields of mobile devices, such as enabling account login, payment authorization and other operations, and the like. Therefore, using the authorization credentials stored by the fingerprint recognition of the Android phone to perform an Android interface hijacking attack can perform sensitive operations in various APPs (mobile software).

[0004] In the related art, there are generally two hijacking attack test methods for Android interface hijacking attacks:

[0005] Method one: using a Hook framework (an API (application programming interface) call interception technology) such as Xposed (a set of open source framework services running in the high permission mode of Android) to perform interface hijacking testing. After Android 9.0, the system has increased detection of program Activity (window). This method of interface hijacking first needs to obtain the root (the highest management permission of Android) permission of the system. However, this interface hijacking attack method has a high requirement for mobile devices, needs to use the root permission, and install related Android Hook frameworks such as Xposed. Physical contact with the device is required, and the Xposed framework and other hook programs need to be pre-installed on the device. The requirement for testing is high, and there are many conditions for successfully completing interface hijacking.

[0006] Method two, targeting devices below Android 5.0, involves enumerating the top-of-stack Activity and monitoring its appearance to initiate a hijacking attack. The test program calls the fingerprint monitoring Activity within the target application. After a period of time, the malicious background application launches an Activity that overwrites the fingerprint application. However, this method is an older attack technique and is unusable on Android 5.0 and above because the Android framework in versions 5.0 and above has implemented restrictions on apps, preventing application-level apps from accessing the top-of-stack Activity.

[0007] Testing the application using Method Two requires the following condition: the application must have a persistent defect—it never cancels the input listener. Android allows background applications to continue listening for physical input. However, the fingerprint manager API in Android 9 and later fixed this limitation, as well as the camera functionality. Therefore, this attack testing method is only applicable to a small subset of defective applications and is disabled in the latest versions of the fingerprint API.

[0008] There is currently no effective solution to the above problems. Summary of the Invention

[0009] This invention provides a method, apparatus, and electronic device for testing information hijacking, which at least solves the technical problem that the methods for detecting information hijacking risks on Android devices through Hook frameworks or listening to window activities have limited applicability in related technologies.

[0010] According to one aspect of the present invention, a method for testing information hijacking is provided, comprising: receiving a test request from a target program, wherein the test request is used to request testing whether the program under test has an information hijacking risk; responding to the test request and determining a target program on a target device; and performing an information hijacking risk test on the program under test through the target program using a semi-transparent attribute window of the target device, thereby obtaining a test result.

[0011] Furthermore, by utilizing the semi-transparent attribute window of the target device, the target program performs an information hijacking risk test on the program under test and obtains the test results. This includes: when the program under test has an automatic recovery function and a non-pause function, during the hibernation / wake-up process of the target device, the program under test is subjected to an information hijacking risk test using a first test method in the target program, and a first test result is obtained. The automatic recovery function indicates that after the target device executes the hibernation / wake-up process, the program under test's running state automatically returns to its state before the hibernation / wake-up process. The non-pause function indicates that after the target device executes the hibernation / wake-up process, the program under test's running state automatically returns to its state before the hibernation / wake-up process. During the process, the program under test does not stop running; when the target device is in multi-window mode, based on the semi-transparent attribute window of the target device, the program under test is subjected to information hijacking risk testing through the second test method in the target program to obtain a second test result; when the target device is in a conditional race condition, the program under test is subjected to information hijacking risk testing through the third test method in the target program to obtain a third test result, wherein the conditional race condition is that multiple windows of the target device are in a restored state at the same time; the test result is obtained based on the first test result, the second test result, and the third test result.

[0012] Furthermore, when the program under test has an automatic recovery function and a non-pause function, during the sleep-wake process of the target device, the program under test is subjected to an information hijacking risk test through a first test method in the target program to obtain a first test result, including: initiating a listening event in the target device through the target program, and listening to the sleep-wake process of the target device through the listening event; when the listening event detects that the target device is in a sleep-wake process, the program under test is subjected to an information hijacking risk test through the target program to obtain the first test result.

[0013] Furthermore, when the monitoring event detects that the target device is in a sleep-wake process, the target program is used to perform an information hijacking risk test on the program under test to obtain the first test result. This includes: before the target device goes into sleep mode, establishing a first semi-transparent attribute window through the program under test; after the target device wakes up, performing an information hijacking risk test on the program under test through the first semi-transparent attribute window to test whether relevant information is hijacked through the first semi-transparent attribute window, thereby obtaining the first test result. The relevant information includes at least the information input by the user when operating in the program under test.

[0014] Furthermore, when the target device is in multi-window mode, based on the semi-transparent attribute window of the target device, the program under test is subjected to information hijacking risk testing through the second testing method in the target program to obtain a second test result. This includes: when the target device is in multi-window mode, the target program establishes a second semi-transparent attribute window in the target device; acquiring user operation events on the second semi-transparent attribute window, and based on the operation events, performing information hijacking risk testing on the program under test to test whether the relevant information in the operation events is hijacked through the second semi-transparent attribute window, thereby obtaining a second test result.

[0015] Furthermore, before obtaining the third test result by conducting information hijacking risk testing on the program under test through the third test method in the target program, the process includes: within a preset time interval after the program under test initiates an input window, the program under test initiates a third semi-transparent attribute window on the target device, causing the target device to enter a conditional race state.

[0016] Further, based on the first test result, the second test result, and the third test result, the test result is obtained, including: counting the number of test results in which the information hijacking was successful in the first test result, the second test result, and the third test result to obtain a target number; determining whether the target number is greater than a preset threshold, and if the target number is greater than the preset threshold, determining that the test result indicates that the program under test has an information hijacking risk.

[0017] Furthermore, the information hijacking risk test is a fingerprint information hijacking test.

[0018] According to another aspect of the present invention, an information hijacking testing apparatus is also provided, comprising: a receiving module for receiving a test request from a target program, wherein the test request is for requesting to test whether the program under test has an information hijacking risk; a determining module for responding to the test request and determining a target program on a target device; and a testing module for performing an information hijacking risk test on the program under test through the target program using a semi-transparent attribute window of the target device, and obtaining test results.

[0019] Further, the testing module includes: a first testing unit, configured to perform an information hijacking risk test on the program under test during the sleep-wake process of the target device, using a first testing method in the target program, when the program under test has an automatic recovery function and a non-pause function, and obtain a first test result, wherein the automatic recovery function indicates that after the target device performs the sleep-wake process, the program running state of the program under test automatically recovers to the state before the sleep-wake process, and the non-pause function indicates that the program under test does not stop running during the sleep-wake process of the target device; a second testing unit, configured to perform an information hijacking risk test on the program under test based on the semi-transparent attribute window of the target device, using a second testing method in the target program, when the target device is in a multi-window mode, and obtain a second test result; a third testing unit, configured to perform an information hijacking risk test on the program under test using a third testing method in the target program, when the target device is in a conditional race condition, and obtain a third test result, wherein the conditional race condition is that multiple windows of the target device are simultaneously in a recovery state; and a processing unit, configured to obtain the test result based on the first test result, the second test result, and the third test result.

[0020] Furthermore, the first testing unit includes: a listening submodule, used to initiate a listening event in the target device through the target program, and to listen to the sleep-wake process of the target device through the listening event; and a testing submodule, used to perform information hijacking risk testing on the program under test through the target program when the listening event detects that the target device is in a sleep-wake process, and to obtain the first test result.

[0021] Furthermore, the testing submodule includes: a window creation subunit, used to create a first semi-transparent attribute window through the program under test before the target device goes into sleep mode; and a first testing subunit, used to perform an information hijacking risk test on the program under test through the first semi-transparent attribute window after the target device wakes up, test whether relevant information is hijacked through the first semi-transparent attribute window, and obtain the first test result, wherein the relevant information includes at least the information input by the user when operating the program under test.

[0022] Furthermore, the second testing unit includes: a window creation submodule, used to create a second semi-transparent attribute window in the target device through the target program when the target device is in multi-window mode; and a first processing submodule, used to acquire user operation events on the second semi-transparent attribute window, and based on the operation events, perform information hijacking risk testing on the program under test, and test whether the second semi-transparent attribute window hijacks the relevant information in the operation events to obtain a second test result.

[0023] Furthermore, the third testing unit includes: a second processing submodule, used to perform information hijacking risk testing on the program under test through the third testing method in the target program, and before obtaining the third test result, within a preset time interval after the program under test initiates the input window, to initiate a third semi-transparent attribute window on the target device through the program under test, so that the target device enters a conditional race state.

[0024] Furthermore, the processing unit includes: a statistics submodule, used to count the number of successful information hijacking results among the first test result, the second test result, and the third test result, to obtain a target number; and a determination submodule, used to determine whether the target number is greater than a preset threshold, and if the target number is greater than the preset threshold, to determine that the test result indicates that the program under test has an information hijacking risk.

[0025] Furthermore, the information hijacking risk test is a fingerprint information hijacking test.

[0026] According to another aspect of the present invention, an electronic device is also provided, including: a processor; and a memory for storing executable instructions of the processor; wherein the processor is configured to perform a test method for information hijacking of any of the above-mentioned methods by executing the executable instructions.

[0027] In this invention, a test request is received from a target program, wherein the test request is used to request testing whether the program under test has the risk of information hijacking; in response to the test request, the target program on the target device is identified; the target program utilizes the semi-transparent attribute window of the target device to perform information hijacking risk testing on the program under test, and the test results are obtained. This solves the technical problem of limited applicability of methods for detecting information hijacking risks on Android devices using hook frameworks or listening to window activities in related technologies. In this invention, by utilizing a semi-transparent attribute window to perform information hijacking risk testing on the program under test, the limited applicability of methods for detecting information hijacking risks on Android devices using hook frameworks or listening to window activities is avoided, thereby achieving the technical effect of improving the accuracy and versatility of the test results for information hijacking risk testing on the program under test. Attached Figure Description

[0028] The accompanying drawings, which are included to provide a further understanding of the invention and form part of this application, illustrate exemplary embodiments of the invention and, together with their description, serve to explain the invention and do not constitute an undue limitation thereof. In the drawings:

[0029] Figure 1 This is a flowchart of an optional information hijacking test according to an embodiment of the present invention;

[0030] Figure 2 This is a flowchart of another optional information hijacking test method according to an embodiment of the present invention;

[0031] Figure 3 This is a test flowchart of a first test method for an optional information hijacking test according to an embodiment of the present invention;

[0032] Figure 4 This is a schematic diagram of an optional information hijacking test device according to an embodiment of the present invention. Detailed Implementation

[0033] To enable those skilled in the art to better understand the present invention, the technical solutions of the present invention will be clearly and completely described below with reference to the accompanying drawings of the embodiments. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort should fall within the scope of protection of the present invention.

[0034] It should be noted that the terms "first," "second," etc., in the specification, claims, and accompanying drawings of this invention are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments of the invention described herein can be implemented in orders other than those illustrated or described herein. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover a non-exclusive inclusion; for example, a process, method, system, product, or apparatus that comprises a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to such processes, methods, products, or apparatus.

[0035] For ease of description, some terms or nouns involved in the embodiments of the present invention are explained below.

[0036] Android interface hijacking attack: This refers to an attack method in which the attacker pops up an interface similar to the original Android program, inducing the user to enter sensitive information in the similar interface.

[0037] Acticity: An application component in the Android system that provides a screen or window for interacting with the user to complete a task;

[0038] OnStop: Stops the Activity. Used for invisible Activities (when a dialog box pops up, the Activity below is still visible, and onStop will not be called in this case).

[0039] OnPause: Pauses the activity, used to switch from one activity to another, when the device enters sleep mode (screen locked), or when a dialog pops up;

[0040] OnResume: Resumes the Activity. It is executed when the Activity can interact with the user, allowing the user to gain focus on the Activity and interact with it.

[0041] Example 1

[0042] According to an embodiment of the present invention, an optional information hijacking test method embodiment is provided. It should be noted that the steps shown in the flowchart in the accompanying drawings can be executed in a computer system such as a set of computer-executable instructions. Furthermore, although a logical order is shown in the flowchart, in some cases, the steps shown or described may be executed in a different order than that shown here.

[0043] Figure 1 This is a flowchart of an optional information hijacking test method according to an embodiment of the present invention, such as... Figure 1 As shown, the method includes the following steps:

[0044] Step S101: Receive a test request from the target program, wherein the test request is used to request testing whether the program under test has the risk of information hijacking.

[0045] The aforementioned target program can be a hijacking detection tool used to perform information hijacking risk testing on the program under test. It is used to detect whether the program under test has corresponding security protection functions when or after being hijacked.

[0046] The aforementioned test request can be used to test whether the program under test has the risk of information hijacking. The risk of information hijacking can be the risk of hijacking the biometric information of Android devices. Biometric information can include, but is not limited to, fingerprints.

[0047] In this embodiment, the objects involved in testing whether the program under test has the risk of information hijacking may include, but are not limited to: Android users, Android phones (target devices), pre-hijacking applications (hereinafter referred to as TargetAPP, corresponding to the program under test mentioned above), and hijacking detection frameworks (Malicious hijacking framework, hereinafter referred to as MHF, used for information hijacking risk testing, which can deploy the aforementioned target program). In the case where the aforementioned information hijacking risk is an Android biometric information hijacking attack risk, the purpose of the Android biometric information hijacking attack test is to test whether the Android user can overwrite the currently invoked application and obtain authorization from the Target App by inputting some of their biometric information into the Android phone with the lowest possible permissions, thereby testing whether the program under test has the risk of information hijacking through the target program test.

[0048] Step S102: Respond to the test request and determine the target program on the target device.

[0049] The target device mentioned above can be an Android phone or other testing devices used to test the information hijacking risk of the program under test. In this embodiment, the information hijacking risk test of the program under test can be divided into two testing methods. One testing method is a pure silent test, which involves installing the test APP (the program under test) on the corresponding test device. Assuming that it is a malicious program, the Android user downloads the test framework disguised as a normal application from the app store or from some other unofficial application stores, and simulates the user to install it. After that, the phone is operated at will to see if it can obtain fingerprint information normally. The other method is to enable debug mode and directly debug the APP under test on the target device to see if there is an alarm function after the relevant APP is overwritten.

[0050] Step S103: The target program uses the semi-transparent attribute window of the target device to perform information hijacking risk testing on the program to be tested and obtain the test results.

[0051] In this embodiment, due to the characteristics of Android 9.0, many apps cancel the fingerprint authentication API call during the OnStop call, but do not cancel the fingerprint authentication API call in the OnPause event. Additionally, when a semi-transparent Activity overwrites the original Activity, only the underlying OnPause event is triggered. This embodiment primarily utilizes these two frameworks to implement a method for hijacking device fingerprints.

[0052] Based on the aforementioned Android features, a method for testing information hijacking attacks is proposed. A semi-transparent Activity (or window) can be used to cover the Activity calling the fingerprint authentication API. By leveraging this feature, fingerprint authentication can be avoided, allowing testing to determine whether user-related information in the tested application can be successfully hijacked—this is the semi-transparent attack test. The attacking app (corresponding to the target application) declares its semi-transparent Activity attribute as true. This method requires no additional Android permissions to test whether the tested application carries the risk of information hijacking.

[0053] Since Android 9.0, a patch has been added to the fingerprint manager API to mitigate the risk of fingerprint hijacking caused by operating system-level pause failures. The patch's logic is to perform a consistency check between the foreground Activity and the fingerprint Activity whenever the Activity stack changes (e.g., when "Activity" is placed on top of another Activity). The API patch works by ensuring that if the Activity stack change never occurred, the Activity not on top can continue listening to the fingerprint scanner. This integrity check tests the app under test for potential information hijacking risks.

[0054] In this embodiment, considering the integrity check of the Activity Stack for mitigation measures, it is sufficient to cover a semi-transparent Activity without changing the Activity Stack. This embodiment, taking into account the mitigation measures of Android 9.0, proposes a testing method for covering an Activity without changing the Activity Stack, which can be performed using the design principles of the Android system.

[0055] Through the above steps, this invention utilizes a semi-transparent attribute window to perform information hijacking risk testing on the program under test. This avoids the limited applicability of methods for detecting information hijacking risks on Android devices that rely on hook frameworks or listening to window activities, thereby improving the accuracy and versatility of the test results. Furthermore, it solves the technical problem of limited applicability of related technologies that use hook frameworks or listening to window activities to detect information hijacking risks on Android devices.

[0056] Figure 2 This is a flowchart of another optional information hijacking test method according to an embodiment of the present invention, such as... Figure 2As shown, the target program utilizes the semi-transparent property window of the target device to perform information hijacking risk testing on the program under test, and obtains the test results, including the following steps:

[0057] Step S201: When the program under test has an automatic recovery function and a non-pause function, during the sleep-wake process of the target device, the program under test is subjected to an information hijacking risk test through the first test method in the target program to obtain the first test result. The automatic recovery function is used to indicate that after the target device performs the sleep-wake process, the program running state of the program under test is automatically restored to the state before the sleep-wake process. The non-pause function is used to indicate that the program under test does not stop running during the sleep-wake process of the target device.

[0058] Step S202: When the target device is in multi-window mode, based on the semi-transparent attribute window of the target device, the information hijacking risk test is performed on the program to be tested through the second test method in the target program to obtain the second test result.

[0059] Step S203: When the target device is in a conditional race condition, the information hijacking risk test is performed on the program to be tested through the third test method in the target program to obtain the third test result. The conditional race condition is when multiple windows of the target device are in the recovery state at the same time. The test result is obtained based on the first test result, the second test result and the third test result.

[0060] The first testing method described above can be a security test that bypasses stack integrity checks by performing a silent bypass when the device system starts up and the screen is off, i.e., hijacking the API calls. This can be achieved by utilizing the automatic resume and non-pause functions of the app under test (corresponding to the program under test mentioned above); upon detecting the ON_SCREEN_OFF event (listening for screen lock / screen unlock events), the security testing framework immediately switches the semi-transparent framework to the bottom layer of the stack.

[0061] The second testing method mentioned above can be achieved using a floating window, which means conducting information hijacking risk testing in the multi-window mode of the application under test installed on the target device. A new Activity can be placed on the floating window of the application under test and disguised as a legitimate service function, such as a small-window video call, to attract the victim user to click.

[0062] The third testing method mentioned above can utilize the Android system's Activity lifecycle to enter an unstable edge state, i.e. a competition state, during repeated restarts, to conduct information hijacking risk testing.

[0063] By using the three testing methods described above to conduct information hijacking risk testing on the program under test, the technical effects of improving the accuracy of information hijacking risk testing results and the versatility of the testing methods have been achieved.

[0064] Figure 3 This is a test flowchart of a first test method for an optional information hijacking test according to an embodiment of the present invention, as shown below. Figure 3 As shown, when the program under test has automatic recovery and non-pause functions, during the sleep-wake process of the target device, the program under test is subjected to information hijacking risk testing through the first test method in the target program to obtain the first test result, including the following steps:

[0065] Step S301: The target program initiates a listening event in the target device and listens to the sleep-wake process of the target device through the listening event;

[0066] Step S302: When the target device is detected to be in a sleep-wake process by listening to the event, the target program performs an information hijacking risk test on the program to be tested and obtains the first test result.

[0067] In this embodiment, a service that listens for the ON_SCREEN_OFF event can be started on the device, and the attack can be initiated before the device goes to sleep (i.e., before hibernation). When the Android device goes to sleep (i.e., after waking up), the target program in the MHF framework can start a new Activity. After the Activity on the target device ends, both Activities call the resume method (an event used to restore the original thread running state), with the Activity of the lower program in the OnPause state. At this time, the fingerprint hijacking program (corresponding to the target program) can work in the background, avoiding any changes to the Activity stack. In this way, it is possible to bypass the Activity stack integrity detection in various Android system frameworks. When the victim user subsequently unlocks the target device with their fingerprint or enters their biometric information, the hijacking test framework can run in the background to hijack the corresponding user's biometric information (such as fingerprint information). If the corresponding biometric information is hijacked, the first test result can be determined as the information hijacking of the program under test being successful, achieving the technical effect of testing the accuracy of the test for whether there is a risk of information hijacking during the device's sleep-wake process.

[0068] Optionally, if the target device is detected to be in a sleep / wake-up process during the monitoring event, the program under test is subjected to an information hijacking risk test through the target program to obtain a first test result. This includes: establishing a first semi-transparent attribute window through the program under test before the target device goes into sleep mode; and performing an information hijacking risk test through the first semi-transparent attribute window after the target device wakes up, testing whether relevant information is hijacked through the first semi-transparent attribute window to obtain a first test result. The relevant information includes at least the information entered by the user when operating in the program under test.

[0069] In this embodiment, when the Android device goes to sleep (i.e., wakes up), the target program in the MHF framework can launch a new Activity (corresponding to the first semi-transparent attribute window mentioned above). After the Activity lit up on the target device ends, both Activities call the resume method, with the Activity of the lower program now in the OnPause state. At this time, the fingerprint hijacking program (corresponding to the target program mentioned above) can work in the background, avoiding any changes to the Activity stack. It should be noted that the information entered by the user when operating in the program under test can be the user's biometric information, such as fingerprint information, achieving the technical effect of testing the accuracy of the test for whether there is a risk of information hijacking during the device's sleep-wake process.

[0070] Optionally, when the target device is in multi-window mode, based on the semi-transparent attribute window of the target device, the program under test is subjected to information hijacking risk testing through the second testing method in the target program to obtain the second test result. This includes: when the target device is in multi-window mode, the target program creates a second semi-transparent attribute window in the target device; obtains user operation events on the second semi-transparent attribute window, and based on the operation events, performs information hijacking risk testing on the program under test to test whether the relevant information in the operation events is hijacked through the second semi-transparent attribute window, and obtains the second test result.

[0071] In this embodiment, considering the feature of Android 9 that allows applications to run on floating windows in multi-window mode, information hijacking risk testing is conducted using a second testing method. Because multiple Activities are visible to the user in the floating window scenario, only one window will be on top at a time; that is, only the top Activity within that window will be in the OnResume state, and Activity windows will switch from one to another.

[0072] In the second test method using the floating window approach, this method bypasses the issue by using two features of Android: First, when a user clicks on a non-Activity window, it becomes an Activity window, where the top-level Activity will revert to its Activity state; Second, when a user resizes a window, regardless of which window the user previously interacted with, any window larger than half its size will become an Activity window.

[0073] When these two situations occur—that is, when the user clicks on an inactive window and when the user resizes the window—the "Activity" stack will not change, but it will change the "Activity" state and trigger an event. Therefore, in this embodiment, a wake-up bypass attack test can be performed by creating a scenario similar to a double-split window. One is the Activity window (test frame window) where the malicious application (corresponding to the target program mentioned above) is running, and the other is an adjacent window (i.e., the window that is running normally in the program under test), in which the victim's fingerprint target program will be placed (TargetAPP window). This second testing method can be applied to floating window programs in both Android 7.0 and Android 9.0.

[0074] The following describes the workflow of the attack test for the second testing method: information hijacking risk testing.

[0075] (1) A semi-transparent attribute window (corresponding to the second semi-transparent attribute window mentioned above) will be launched in the MHF frame window to set the required Activity stack for the victim window. This is achieved by launching the Activity using the FLAG_ACTIVITY_LAUNCH_ADJACENT flag (a flag used in split-screen multi-window mode).

[0076] (2) Wait for the user to interact with or expand the second semi-transparent attribute window of the target program, i.e., the victim window. When this event occurs, the overlay and the target Activity below are restored, and fingerprint hijacking is invoked to avoid triggering the stack integrity check.

[0077] In this embodiment, a new Activity (or semi-transparent attribute window) can be placed on a floating window or multi-window mode and disguised as a legitimate service function, such as a small window video, to attract the victim to click. This allows for testing whether the program under test can be successfully hijacked by the second testing method, thus obtaining the second test result and achieving the technical effect of improving the applicability of information hijacking testing.

[0078] Optionally, before obtaining the third test result, the test program may be subjected to information hijacking risk testing through the third test method in the target program. This includes: within a preset time interval after the input window is initiated by the test program, the test program initiates a third semi-transparent attribute window on the target device, causing the target device to enter a conditional race state.

[0079] In this embodiment, the Android system's Activity lifecycle can be utilized to enter an unstable edge state during repeated restarts. When the race condition fails to trigger, the underlying test app Activity will receive the OnPause event as expected. If the race condition triggers successfully, the victim Activity remains in the resumed state. According to the original system design, under the global design of the Android system, only one Activity can be in the resumed state at a time, but when a race condition occurs, two Activities appear in the resumed state.

[0080] In this embodiment, information hijacking risk testing of the program under test can be performed by reproducing this race condition state. The race condition vulnerability bypasses the Android framework's detection of sensitive fingerprint APIs. First, an input Activity of the target program is launched. Then, with a very short delay (e.g., within 100ms), the transparent Activity covering MHF is launched again, triggering the race condition vulnerability in the Android system. When the race condition occurs, both the target program's and MHF's Activities are in a restored state. Since Android's Activity design stipulates that only one Activity can be in a restored state globally, this embodiment can utilize this race condition vulnerability to bypass system-level and application-level protection mechanisms for information hijacking risk testing, testing whether the program under test has an information hijacking risk under the race condition state.

[0081] In the third test method, MHF can use the StartActivities(Intent[]) API (a program method for starting an Activity) to start two Activities at the same time. Meanwhile, the second (upper) Activity that is started instantly is a semi-transparent property window.

[0082] The specific ways to initiate a race condition can include, but are not limited to, the following two: The first is to install an app on the target Android system (the target device's operating system) for testing, start a service to listen for related program calls, and simultaneously launch the MHF transparent Activity when the service detects an Intent (activating the application component) in the OnPause event called by the target program. In this case, the race condition is acceptable. If the API is used at this time, a third testing method can be used to test whether user information, such as fingerprint information, can be obtained. The second method utilizes a framework that loads the hook API into the target device's Android system, hooking key system APIs and directly calling the fingerprint hook interface of the relevant program. This testing method is applicable to any application on any Android version, achieving the technical effect of improving the applicability of information hijacking testing.

[0083] Optionally, based on the first test result, the second test result, and the third test result, a test result is obtained, including: counting the number of test results in which the information hijacking was successful in the first test result, the second test result, and the third test result to obtain the target number; determining whether the target number is greater than a preset threshold, and if the target number is greater than the preset threshold, determining that the test result indicates that the program under test has an information hijacking risk.

[0084] In this embodiment, the number of successful information hijacking results among the first, second, and third test results can be counted. By judging the number of successful information hijacking results of the first, second, and third test methods, it can be determined whether the data exceeds a preset threshold. If the target number exceeds the preset threshold, it is determined that the test result indicates that the program under test has an information hijacking risk. By conducting information hijacking risk testing on the program under test through three test methods, and judging whether the program under test has an information hijacking risk based on the test results of the three test methods, the technical effect of improving the test accuracy of information hijacking risk testing is achieved.

[0085] Optionally, the information hijacking risk test is a fingerprint information hijacking test.

[0086] In this embodiment, the information hijacking risk test can be a fingerprint information hijacking test, which is used to determine whether there is a risk of fingerprint information hijacking when the program under test is running on an Android device. If there is a risk of fingerprint information hijacking, the defense capabilities of the program under test will be strengthened in a timely manner, thereby achieving the technical effect of strengthening the security of the program under test.

[0087] Example 2

[0088] This application provides an optional information hijacking test device, wherein each implementation module in the test device corresponds to the steps of each embodiment in embodiment one.

[0089] Figure 4 This is a schematic diagram of an optional information hijacking test apparatus according to an embodiment of the present invention, such as... Figure 4 As shown, the testing device includes: a receiving module 41, a determining module 42, and a testing module 43.

[0090] Specifically, the receiving module 41 is used to receive a test request from the target program, wherein the test request is used to request testing whether the program under test has the risk of information hijacking;

[0091] Module 42 is used to respond to the test request and determine the target program on the target device;

[0092] The test module 43 is used to perform information hijacking risk testing on the program under test through the semi-transparent attribute window of the target device by the target program, and obtain the test results.

[0093] In the information hijacking testing apparatus provided in Embodiment 2 of this application, a receiving module 41 can receive a test request from a target program. The test request requests testing whether the program under test has an information hijacking risk. A determining module 42 responds to the test request, determines the target program on the target device, and a testing module 43 uses the target program and the target device's semi-transparent attribute window to perform an information hijacking risk test on the program under test, obtaining the test results. This solves the technical problem of limited applicability of related technologies that use Hook frameworks or listening window activities to detect information hijacking risks on Android devices. In this embodiment, by using a semi-transparent attribute window to perform information hijacking risk testing on the program under test, the limited applicability of methods that use Hook frameworks or listening window activities to detect information hijacking risks on Android devices is avoided, thereby improving the accuracy and versatility of the test results for information hijacking risk testing on the program under test.

[0094] Optionally, in the information hijacking testing device provided in Embodiment 2 of this application, the testing module 43 includes: a first testing unit, used to perform an information hijacking risk test on the program under test through a first testing method in the target program during the hibernation-wake process of the target device when the program under test has an automatic recovery function and a non-pause function, and obtain a first test result, wherein the automatic recovery function is used to indicate that after the target device executes the hibernation-wake process, the program running state of the program under test automatically recovers to the state before the hibernation-wake process, and the non-pause function is used to indicate that the program under test does not stop running during the hibernation-wake process of the target device; a second testing unit, used to perform an information hijacking risk test on the program under test based on the semi-transparent attribute window of the target device when the target device is in multi-window mode, and obtain a second test result through a second testing method in the target program; a third testing unit, used to perform an information hijacking risk test on the program under test through a third testing method in the target program when the target device is in a conditional race state, and obtain a third test result, wherein the conditional race state is that multiple windows of the target device are in the recovery state at the same time; and a processing unit, used to obtain a test result based on the first test result, the second test result, and the third test result.

[0095] The first testing method described above can be a security test that bypasses stack integrity checks by performing a silent bypass when the device system starts up and the screen is off, i.e., hijacking the API calls. This can be achieved by utilizing the automatic resume and non-pause functions of the app under test (corresponding to the program under test mentioned above); upon detecting the ON_SCREEN_OFF event (listening for screen lock / screen unlock events), the security testing framework immediately switches the semi-transparent framework to the bottom layer of the stack.

[0096] The second testing method mentioned above can be achieved using a floating window, which means conducting information hijacking risk testing in the multi-window mode of the application under test installed on the target device. A new Activity can be placed on the floating window of the application under test and disguised as a legitimate service function, such as a small-window video call, to attract the victim user to click.

[0097] The third testing method mentioned above can utilize the Android system's Activity lifecycle to enter an unstable edge state, i.e. a competition state, during repeated restarts, to conduct information hijacking risk testing.

[0098] By using the three testing methods described above to conduct information hijacking risk testing on the program under test, the technical effects of improving the accuracy of information hijacking risk testing results and the versatility of the testing methods have been achieved.

[0099] Optionally, in the information hijacking testing device provided in Embodiment 2 of this application, the first testing unit includes: a listening submodule, used to initiate a listening event in the target device through the target program, and to listen to the sleep-wake process of the target device through the listening event; and a testing submodule, used to perform information hijacking risk testing on the program to be tested through the target program when the listening event detects that the target device is in the sleep-wake process, and to obtain a first test result.

[0100] In this embodiment, a service that listens for the ON_SCREEN_OFF event can be started on the device, and the attack can be initiated before the device goes to sleep (i.e., before hibernation). When the Android device goes to sleep (i.e., after waking up), the target program in the MHF framework can start a new Activity. After the Activity on the target device ends, both Activities call the resume method (an event used to restore the original thread running state), with the Activity of the lower program in the OnPause state. At this time, the fingerprint hijacking program (corresponding to the target program) can work in the background, avoiding any changes to the Activity stack. In this way, it is possible to bypass the Activity stack integrity detection in various Android system frameworks. When the victim user subsequently unlocks the target device with their fingerprint or enters their biometric information, the hijacking test framework can run in the background to hijack the corresponding user's biometric information (such as fingerprint information). If the corresponding biometric information is hijacked, the first test result can be determined as the information hijacking of the program under test being successful, achieving the technical effect of testing the accuracy of the test for whether there is a risk of information hijacking during the device's sleep-wake process.

[0101] Optionally, in the information hijacking testing device provided in Embodiment 2 of this application, the testing submodule includes: a window creation subunit, used to create a first semi-transparent attribute window through the program under test before the target device goes into sleep mode; and a first testing subunit, used to perform information hijacking risk testing on the program under test through the first semi-transparent attribute window after the target device wakes up, test whether relevant information is hijacked through the first semi-transparent attribute window, and obtain a first test result, wherein the relevant information includes at least the information entered by the user when operating in the program under test.

[0102] In this embodiment, when the Android device goes to sleep (i.e., wakes up), the target program in the MHF framework can launch a new Activity (corresponding to the first semi-transparent attribute window mentioned above). After the Activity lit up on the target device ends, both Activities call the resume method, with the Activity of the lower program now in the OnPause state. At this time, the fingerprint hijacking program (corresponding to the target program mentioned above) can work in the background, avoiding any changes to the Activity stack. It should be noted that the information entered by the user when operating in the program under test can be the user's biometric information, such as fingerprint information, achieving the technical effect of testing the accuracy of the test for whether there is a risk of information hijacking during the device's sleep-wake process.

[0103] Optionally, in the information hijacking testing device provided in Embodiment 2 of this application, the second testing unit includes: a window creation submodule, used to create a second semi-transparent attribute window in the target device through the target program when the target device is in multi-window mode; and a first processing submodule, used to obtain user operation events on the second semi-transparent attribute window, and based on the operation events, perform information hijacking risk testing on the program to be tested, test whether the second semi-transparent attribute window hijacks the relevant information in the operation events, and obtain a second test result.

[0104] In this embodiment, considering the feature of Android 9 that allows applications to run on floating windows in multi-window mode, information hijacking risk testing is conducted using a second testing method. Because multiple Activities are visible to the user in the floating window scenario, only one window will be on top at a time; that is, only the top Activity within that window will be in the OnResume state, and Activity windows will switch from one to another.

[0105] In the second test method using the floating window approach, this method bypasses the issue by using two features of Android: First, when a user clicks on a non-Activity window, it becomes an Activity window, where the top-level Activity will revert to its Activity state; Second, when a user resizes a window, regardless of which window the user previously interacted with, any window larger than half its size will become an Activity window.

[0106] When these two situations occur—that is, when the user clicks on an inactive window and when the user resizes the window—the "Activity" stack will not change, but it will change the "Activity" state and trigger an event. Therefore, in this embodiment, a wake-up bypass attack test can be performed by creating a scenario similar to a double-split window. One is the Activity window (test frame window) where the malicious application (corresponding to the target program mentioned above) is running, and the other is an adjacent window (i.e., the window that is running normally in the program under test), in which the victim's fingerprint target program will be placed (TargetAPP window). This second testing method can be applied to floating window programs in both Android 7.0 and Android 9.0.

[0107] The following describes the workflow of the attack test for the second testing method: information hijacking risk testing.

[0108] (1) A semi-transparent attribute window (corresponding to the second semi-transparent attribute window mentioned above) will be launched in the MHF frame window to set the required Activity stack for the victim window. This is achieved by launching the Activity using the FLAG_ACTIVITY_LAUNCH_ADJACENT flag (a flag used in split-screen multi-window mode).

[0109] (2) Wait for the user to interact with or expand the second semi-transparent attribute window of the target program, i.e., the victim window. When this event occurs, the overlay and the target Activity below are restored, and fingerprint hijacking is invoked to avoid triggering the stack integrity check.

[0110] In this embodiment, a new Activity (or semi-transparent attribute window) can be placed on a floating window or multi-window mode and disguised as a legitimate service function, such as a small window video, to attract the victim to click. This allows for testing whether the program under test can be successfully hijacked by the second testing method, thus obtaining the second test result and achieving the technical effect of improving the applicability of information hijacking testing.

[0111] Optionally, in the information hijacking testing device provided in Embodiment 2 of this application, the third testing unit includes: a second processing submodule, used to perform information hijacking risk testing on the program under test through the third testing method in the target program, and before obtaining the third test result, within a preset time interval after the program under test initiates the input window, to initiate a third semi-transparent attribute window on the target device through the program under test, so that the target device enters a conditional race state.

[0112] In this embodiment, the Android system's Activity lifecycle can be utilized to enter an unstable edge state during repeated restarts. When the race condition fails to trigger, the underlying test app Activity will receive the OnPause event as expected. If the race condition triggers successfully, the victim Activity remains in the resumed state. According to the original system design, under the global design of the Android system, only one Activity can be in the resumed state at a time, but when a race condition occurs, two Activities appear in the resumed state.

[0113] In this embodiment, information hijacking risk testing of the program under test can be performed by reproducing this race condition state. The race condition vulnerability bypasses the Android framework's detection of sensitive fingerprint APIs. First, an input Activity of the target program is launched. Then, with a very short delay (e.g., within 100ms), the transparent Activity covering MHF is launched again, triggering the race condition vulnerability in the Android system. When the race condition occurs, both the target program's and MHF's Activities are in a restored state. Since Android's Activity design stipulates that only one Activity can be in a restored state globally, this embodiment can utilize this race condition vulnerability to bypass system-level and application-level protection mechanisms for information hijacking risk testing, testing whether the program under test has an information hijacking risk under the race condition state.

[0114] In the third test method, MHF can use the StartActivities(Intent[]) API (a program method for starting an Activity) to start two Activities at the same time. Meanwhile, the second (upper) Activity that is started instantly is a semi-transparent property window.

[0115] The specific ways to initiate a race condition can include, but are not limited to, the following two: The first is to install an app on the target Android system (the target device's operating system) for testing, start a service to listen for related program calls, and simultaneously launch the MHF transparent Activity when the service detects an Intent (activating the application component) in the OnPause event called by the target program. In this case, the race condition is acceptable. If the API is used at this time, a third testing method can be used to test whether user information, such as fingerprint information, can be obtained. The second method utilizes a framework that loads the hook API into the target device's Android system, hooking key system APIs and directly calling the fingerprint hook interface of the relevant program. This testing method is applicable to any application on any Android version, achieving the technical effect of improving the applicability of information hijacking testing.

[0116] Optionally, in the information hijacking testing device provided in Embodiment 2 of this application, the processing unit includes: a statistics submodule, used to count the number of successful information hijacking results among the first test result, the second test result, and the third test result, to obtain a target number; and a determination submodule, used to determine whether the target number is greater than a preset threshold, and if the target number is greater than the preset threshold, to determine that the test result indicates that the program under test has an information hijacking risk.

[0117] In this embodiment, the number of successful information hijacking results among the first, second, and third test results can be counted. By judging the number of successful information hijacking results of the first, second, and third test methods, it can be determined whether the data exceeds a preset threshold. If the target number exceeds the preset threshold, it is determined that the test result indicates that the program under test has an information hijacking risk. By conducting information hijacking risk testing on the program under test through three test methods, and judging whether the program under test has an information hijacking risk based on the test results of the three test methods, the technical effect of improving the test accuracy of information hijacking risk testing is achieved.

[0118] Optionally, in the information hijacking test apparatus provided in Embodiment 2 of this application, the information hijacking risk test is a fingerprint information hijacking test.

[0119] In this embodiment, the information hijacking risk test can be a fingerprint information hijacking test, which is used to determine whether there is a risk of fingerprint information hijacking when the program under test is running on an Android device. If there is a risk of fingerprint information hijacking, the defense capabilities of the program under test will be strengthened in a timely manner, thereby achieving the technical effect of strengthening the security of the program under test.

[0120] The aforementioned information hijacking test device may also include a processor and a memory. The aforementioned receiving module 41, determining module 42, testing module 43, etc., are all stored in the memory as program units, and the processor executes the aforementioned program units stored in the memory to realize the corresponding functions.

[0121] The aforementioned processor contains a kernel, which retrieves the corresponding program units from memory. One or more kernels can be configured. By adjusting kernel parameters, information hijacking risk testing of the program under test can be performed using a semi-transparent attribute window. This avoids the limited applicability of methods that rely on hooking frameworks or listening to window activity for information hijacking risk detection on Android devices, thereby improving the accuracy and versatility of the test results.

[0122] The aforementioned memory may include non-permanent memory in computer-readable media, such as random access memory (RAM) and / or non-volatile memory, such as read-only memory (ROM) or flash RAM, and the memory includes at least one memory chip.

[0123] According to another aspect of the present invention, an electronic device is also provided, including: a processor; and a memory for storing executable instructions of the processor; wherein the processor is configured to perform a test method for information hijacking of any of the above-mentioned methods by executing the executable instructions.

[0124] According to another aspect of the present invention, a computer-readable storage medium is also provided, which stores a computer program, wherein a test method for information hijacking that controls the device where the computer-readable storage medium is located to perform any of the above-mentioned methods when the computer program is running is provided.

[0125] The sequence numbers of the above embodiments of the present invention are for descriptive purposes only and do not represent the superiority or inferiority of the embodiments.

[0126] In the above embodiments of the present invention, the descriptions of each embodiment have different focuses. For parts not described in detail in a certain embodiment, please refer to the relevant descriptions of other embodiments.

[0127] In the several embodiments provided in this application, it should be understood that the disclosed technical content can be implemented in other ways. The device embodiments described above are merely illustrative; for example, the division of units can be a logical functional division, and in actual implementation, there may be other division methods. For instance, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the displayed or discussed mutual coupling, direct coupling, or communication connection may be through some interfaces; the indirect coupling or communication connection between units or modules may be electrical or other forms.

[0128] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0129] Furthermore, the functional units in the various embodiments of the present invention can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit.

[0130] If the integrated unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of the present invention, in essence, or the part that contributes to the prior art, or all or part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of the present invention. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, read-only memory (ROM), random access memory (RAM), portable hard drives, magnetic disks, or optical disks.

[0131] The above description is only a preferred embodiment of the present invention. It should be noted that for those skilled in the art, several improvements and modifications can be made without departing from the principle of the present invention, and these improvements and modifications should also be considered within the scope of protection of the present invention.

Claims

1. A method of testing for information hijacking, the method comprising: The method comprises the following steps: receiving a test request of a target program, wherein the test request is used to request testing whether the target program has information hijacking risk; determining the target program on a target device in response to the test request; testing the target program for information hijacking risk by using a semi-transparent attribute window of the target device through the target program, and obtaining a test result; wherein testing the target program for information hijacking risk by using a semi-transparent attribute window of the target device through the target program, and obtaining a test result, comprises: in the case that the target program has an automatic recovery function and a non-suspension function, testing the target program for information hijacking risk by using a first test mode in the target program during a sleep wake-up process of the target device, and obtaining a first test result, wherein the automatic recovery function is used to indicate that the program running state of the target program is automatically restored to the state before the sleep wake-up process after the target device executes the sleep wake-up process, and the non-suspension function is used to indicate that the target program does not stop running during the sleep wake-up process of the target device; in the case that the target device is in a multi-window mode, testing the target program for information hijacking risk by using a second test mode in the target program based on the semi-transparent attribute window of the target device, and obtaining a second test result; in the case that the target device is in a condition competition state, testing the target program for information hijacking risk by using a third test mode in the target program, and obtaining a third test result, wherein the condition competition state is that multiple windows of the target device exist in a recovery state at the same time; obtaining the test result based on the first test result, the second test result and the third test result; wherein testing the target program for information hijacking risk by using a first test mode in the target program during a sleep wake-up process of the target device in the case that the target program has an automatic recovery function and a non-suspension function, and obtaining a first test result, comprises: initiating a listening event in the target device through the target program, and listening to the sleep wake-up process of the target device through the listening event; in the case that the listening event listens to the sleep wake-up process of the target device, testing the target program for information hijacking risk through the target program, and obtaining the first test result.

2. The test method of claim 1, wherein, in the case that the listening event listens to the sleep wake-up process of the target device, testing the target program for information hijacking risk through the target program, and obtaining the first test result, comprises: establishing a first semi-transparent attribute window through the target program before the target device sleeps; After the target device is woken up, the information hijacking risk test is performed on the to-be-tested program through the first semi-transparent attribute window, whether relevant information is hijacked through the first semi-transparent attribute window is tested, and the first test result is obtained, wherein the relevant information at least includes information input by a user when operating in the to-be-tested program.

3. The test method of claim 1, wherein, In a case where the target device is in a multi-window mode, based on the semi-transparent attribute window of the target device, the information hijacking risk test is performed on the to-be-tested program through a second test manner in the target program, and a second test result is obtained, including: In a case where the target device is in a multi-window mode, a second semi-transparent attribute window is established in the target device through the target program; An operation event of a user on the second semi-transparent attribute window is obtained, and based on the operation event, the information hijacking risk test is performed on the to-be-tested program, whether relevant information in the operation event is hijacked through the second semi-transparent attribute window is tested, and a second test result is obtained.

4. The test method of claim 1, wherein, Before the information hijacking risk test is performed on the to-be-tested program through a third test manner in the target program, and a third test result is obtained, including: Within a preset time interval after the to-be-tested program initiates an input window, a third semi-transparent attribute window is initiated on the target device through the to-be-tested program, so that the target device enters a conditional competition state.

5. The test method of claim 1, wherein, Based on the first test result, the second test result, and the third test result, the test result is obtained, including: A target number is obtained by counting a number of test results that are information hijacking successes in the first test result, the second test result, and the third test result; It is determined whether the target number is greater than a preset threshold, and in a case where the target number is greater than the preset threshold, it is determined that the test result is that the to-be-tested program has information hijacking risk.

6. The test method of claim 1, wherein, The information hijacking risk test is a fingerprint information hijacking test.

7. A test device for information hijacking, characterized in that Including: A receiving module is configured to receive a test request of a target program, wherein the test request is used to request whether a to-be-tested program has information hijacking risk; A determining module is configured to determine a target program on a target device in response to the test request; A test module is configured to perform information hijacking risk test on the to-be-tested program through the target program using a semi-transparent attribute window of the target device, and obtain a test result. The test module comprises: a first test unit, configured to perform information hijacking risk test on the to-be-tested program by a first test mode in the target program in a sleep wake-up process of the target device under the condition that the to-be-tested program is provided with an automatic recovery function and a non-suspension function, and obtain a first test result, wherein the automatic recovery function is used to indicate that a program running state of the to-be-tested program is automatically restored to a state before the sleep wake-up process after the target device performs the sleep wake-up process, and the non-suspension function is used to indicate that the to-be-tested program does not stop running in the sleep wake-up process; a second test unit, configured to perform information hijacking risk test on the to-be-tested program by a second test mode in the target program based on a semi-transparent attribute window of the target device under the condition that the target device is in a multi-window mode, and obtain a second test result; a third test unit, configured to perform information hijacking risk test on the to-be-tested program by a third test mode in the target program under the condition that the target device is in a condition competition state, and obtain a third test result, wherein the condition competition state is that multiple windows of the target device exist simultaneously in a recovery state; and a processing unit, configured to obtain the test result based on the first test result, the second test result and the third test result. The first test unit comprises: a listening sub-module, configured to initiate a listening event in the target device by the target program, and listen to a sleep wake-up process of the target device by the listening event; and a test sub-module, configured to perform information hijacking risk test on the to-be-tested program by the target program under the condition that the listening event listens to that the target device is in the sleep wake-up process, and obtain the first test result.

8. An electronic device, comprising: The apparatus comprises one or more processors and a memory storing one or more programs, wherein the one or more programs, when executed by the one or more processors, cause the one or more processors to implement the information hijacking test method according to any one of claims 1 to 6.

Images