Online examination terminal environment risk detection method and electronic device

Abstract

The application discloses an online examination terminal environment risk detection method and electronic equipment, and the method comprises the following steps: acquiring a process set currently running on a terminal, and classifying remote control related processes into active session layer processes or background support layer processes according to preset process layering rules; detecting a remote control enabling state of a terminal operating system to obtain a system-level remote control state signal; merging the existence state of the active session layer processes and the system-level remote control state signal as default risk judgment basis to determine whether the terminal has an effective remote control risk, wherein the background support layer processes are not included in the default risk judgment basis range. The application can effectively distinguish real remote control risks from background resident services, reduce the false positive rate, and form a standardized access decision basis.

Description

Technical Field

[0001] This application relates to the field of online education proctoring technology, and more specifically, to a method and electronic device for detecting risks in online examination terminal environments. Background Technology

[0002] With the widespread application of online examinations and remote intelligent proctoring technologies, the risk of remote control of the terminal environment has become a core security threat affecting the fairness of examinations. If a candidate's terminal is in a state that can be remotely controlled, it will directly breach the proctoring defenses and lead to serious cheating behaviors such as proxy test-taking and remote assistance in answering questions.

[0003] Currently, the mainstream terminal remote control risk detection solutions mainly adopt a process blacklist matching mechanism: by enumerating the processes currently running in the terminal operating system, the process names are compared with a preset list of third-party remote control software processes, and if a matching process is found, it is determined that there is a remote control risk.

[0004] However, in complex real-world application scenarios, existing terminal environment detection technologies still face long-standing technical bottlenecks. On the one hand, it is difficult to accurately distinguish between active sessions with actual remote control risks and auxiliary processes that only exist as background services. This leads to the possibility of blocking candidates from entering the examination room due to misjudging normal background services while intercepting real cheating behavior. On the other hand, there is a lack of effective means to detect the status of native remote control functions on cross-platform operating systems, resulting in terminals in a controlled state being missed. Summary of the Invention

[0005] In view of the above problems, this application proposes to provide a method and electronic device for detecting risks in online examination terminal environments, in order to solve the problem that existing solutions rely on flat third-party remote control software process blacklists, which cannot perceive the actual operational state of risks, leading to false alarms and missed alarms. The specific solution is as follows:

[0006] Firstly, a method for detecting risks in online examination terminal environments is provided, including:

[0007] Get the set of processes currently running in the terminal;

[0008] According to the preset process layering rules, the remote control-related processes in the process set are classified into active session layer processes or background support layer processes. The active session layer processes are those that can directly establish or carry valid remote control sessions, while the background support layer processes are those that only provide background auxiliary support and do not directly generate valid remote control sessions.

[0009] Detect the native remote control enabled status of the terminal operating system to obtain the system-level remote control status signal;

[0010] The existence status of the active session layer process and the system-level remote control status signal are combined as the default risk judgment basis to determine whether there is a valid remote control risk in the terminal, and the terminal remote control risk detection result is obtained.

[0011] The background support layer process is not included in the default risk assessment criteria.

[0012] In one possible design, in another implementation of the first aspect of the embodiments of this application, the process of classifying the remote control-related processes in the process set into active session layer processes or background support layer processes according to preset process layering rules includes:

[0013] Obtain the runtime context information of each remote control-related process in the process set;

[0014] Based on the runtime context information, the remote control-related processes are classified as active session layer processes or background support layer processes.

[0015] The runtime context information includes at least one or more of the following: whether the process has a visual window interface, whether the process is started as a system service or daemon process, and whether the process is associated with the current user interaction session.

[0016] In one possible design, another implementation of the first aspect of the embodiments of this application further includes:

[0017] Maintain a risk baseline library, which includes a remote control baseline library, a screen recording software baseline library, and a virtual machine software baseline library;

[0018] The processes in the process set are matched with the risk baseline library. Processes that match the remote control baseline library are classified as remote control related processes, processes that match the screen recording software baseline library are classified as screen recording software processes, and processes that match the virtual machine software baseline library are classified as virtual machine software processes.

[0019] Based on the existence status of the screen recording software process, a screen recording risk detection result is generated; based on the existence status of the virtual machine software process, a virtual machine risk detection result is generated.

[0020] In one possible design, in another implementation of the first aspect of this application, the process of merging the existence state of the active session layer process with the system-level remote control status signal as a default risk determination criterion to determine whether the terminal has a valid remote control risk includes:

[0021] If any remote control-related process exists in the active session layer process, or if the system-level remote control status signal indicates that the terminal operating system's native remote control function is enabled, then the terminal is determined to have a valid remote control risk.

[0022] In one possible design, in another implementation of the first aspect of the embodiments of this application, the process of detecting the native remote control enabled state of the terminal operating system includes:

[0023] If the terminal is a Windows system, detect the system's remote desktop session status to obtain the system-level remote control status signal;

[0024] If the terminal is a macOS system, detect one or more of the following: system screen sharing status, remote management status, or virtual network computing port listening status to obtain the system-level remote control status signal.

[0025] In one possible design, in another implementation of the first aspect of the embodiments of this application, the process of detecting the remote desktop session state of the system includes:

[0026] Detect one or more of the following: session environment variables, current session list, system remote session metrics, differences between current process sessions and console sessions.

[0027] In one possible design, another implementation of the first aspect of the embodiments of this application further includes:

[0028] Under the strict testing strategy instructed in this examination, the background support layer processes are included in the risk assessment criteria to determine whether the terminal poses a valid risk of remote control. Specifically, if any remote control-related process exists in the background support layer processes, the terminal is deemed to pose a valid risk of remote control.

[0029] In one possible design, another implementation of the first aspect of the embodiments of this application further includes camera availability detection, the process of which includes:

[0030] Start the camera and capture continuous video frames;

[0031] The determination of whether the camera is effectively outputting images is based on the image features of video frames. The image features include one or more of the following: image brightness, dark pixel ratio, and inter-frame motion variation.

[0032] In one possible design, another implementation of the first aspect of the embodiments of this application further includes microphone availability detection, the process of which includes:

[0033] The microphone is activated and audio signals are acquired. The microphone is then used to determine whether it is in a valid input state based on the audio signal strength.

[0034] In one possible design, another implementation of the first aspect of the embodiments of this application further includes display environment detection, the process of which includes:

[0035] Detect the full-screen state of the current window on the terminal, as well as the number of monitors connected to the system;

[0036] Generate full-screen state detection results and single-monitor detection results.

[0037] In one possible design, another implementation of the first aspect of the embodiments of this application further includes input limit preheating detection, the process of which includes:

[0038] When all mandatory tests pass and the exam strategy indicates that the specified input method is disabled, the availability of the terminal input method control component is pre-detected, and the input restriction capability is warmed up.

[0039] In one possible design, another implementation of the first aspect of the embodiments of this application further includes:

[0040] The results of remote control risk detection are mapped together with the results of other environmental detection items into a standardized inspection item data structure. The standardized inspection item data structure includes: item identifier, readable name, whether it is required, whether it passes, and failure prompt information fields.

[0041] In one possible design, another implementation of the first aspect of the embodiments of this application further includes:

[0042] Perform a logical AND operation on the pass status of all check items marked as mandatory to generate a summary result of terminal environment access control;

[0043] When the exam policy indicates that a mandatory security check policy is enabled and the access summary result is "failed", the terminal will be blocked from entering the exam interface, and only the environment check will be re-executed.

[0044] If the exam policy does not enable the mandatory security check policy and there are failed checks, display the failed checks and allow the terminal to enter the exam interface, while retaining the audit log of the failed checks.

[0045] In one possible design, another implementation of the first aspect of the embodiments of this application further includes:

[0046] After the terminal enters the examination stage, the system-level remote control status signal is detected at a low frequency, lower than the pre-examination detection frequency.

[0047] When the system-level remote control status signal indicates that the remote control function is enabled, a remote control risk alarm is triggered.

[0048] In a second aspect, an electronic device is provided, comprising: a memory and a processor;

[0049] The memory is used to store programs;

[0050] The processor is configured to execute the program to implement the various steps of the online examination terminal environment risk detection method as described in any of the first aspects above.

[0051] By employing the aforementioned technical solution, this application functionally layers remote control-related processes, removing background support processes that do not directly generate valid remote control sessions from the default judgment criteria. This prevents a large number of background service / daemon processes that persist with system startup but do not actually establish remote connections from being directly used as reasons to block exams. This avoids misjudgments in scenarios where "remote control software is installed but remote functions are not actually enabled" from the root of the rules, effectively preventing large-scale misjudgments caused by static residual processes, significantly reducing the false alarm rate, and better adapting to the deployment needs of large-scale online exams.

[0052] In addition, this application supplements the third-party process detection with the operating system's native system-level remote control status detection, breaking through the limitations of detection that relies solely on process name matching. It can cover the system's built-in remote desktop, screen sharing and other native remote control capabilities, achieving a more comprehensive identification of risks to effective remote control of the terminal and reducing the false negative rate.

[0053] Furthermore, this application functionally differentiates the remote control-related processes in the process set into active session layer processes and background support layer processes. Based on this, different detection rules can be flexibly adapted. For example, by default, background support layer processes are not included in the default risk assessment criteria, but they can be enabled as strict detection items as needed. This allows for adaptation to online examination scenarios with different security levels, balancing the strong security requirements of high-level examinations with the practical compatibility of ordinary examinations. Attached Figure Description

[0054] Various other advantages and benefits will become apparent to those skilled in the art upon reading the following detailed description of preferred embodiments. The accompanying drawings are for illustrative purposes only and are not intended to limit the scope of this application. Furthermore, the same reference numerals denote the same parts throughout the drawings. In the drawings:

[0055] Figure 1 This application provides a schematic flowchart of an online examination terminal environment risk detection method.

[0056] Figure 2 This is a schematic diagram of another online examination terminal environment risk detection method provided in an embodiment of this application;

[0057] Figure 3 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. Detailed Implementation

[0058] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0059] It is understood that before using the technical solutions disclosed in the various embodiments of this application, users should be informed of the types, scope of use, and usage scenarios of the personal information involved in this application in an appropriate manner in accordance with relevant laws and regulations, and user authorization should be obtained.

[0060] In online examination scenarios, to prevent candidates from cheating using remote control, screen sharing, or screen recording software, existing examination clients typically employ a terminal environment detection method based on process blacklists. The basic implementation idea is as follows: the client enumerates all running processes in the current operating system, matches the process name or path against a pre-set blacklist database, and if a match is found, it determines that the terminal poses a cheating risk, and accordingly performs blocking or alarm operations.

[0061] However, the aforementioned detection mechanism based on static blacklists has an inherent technical flaw: the mechanism's judgment relies solely on the "static existence" of the software (i.e., whether the software has been installed or whether its process is running in the background), completely ignoring whether the software is in a "truly usable and effective running state" in the current system environment.

[0062] Specifically, on the one hand, many remote control or screen recording software programs, after installation, have their auxiliary processes, daemons, or service processes (such as Helper, Service, Daemon, etc.) resident in the background for extended periods after the operating system starts. Although these processes exist, they do not establish actual remote connections or screen capture sessions, and therefore do not possess the conditions for real-time cheating. However, existing blacklist mechanisms cannot distinguish between processes that are "statically resident in the background" and those that are "actively controllable in the foreground," leading to a large number of terminals that could normally participate in the exam being mistakenly identified as high-risk, resulting in an extremely high false alarm rate.

[0063] On the other hand, operating system-provided remote desktop services (such as Windows Remote Desktop Session and macOS Screen Sharing Service) or remote control services based on standard protocols (such as VNC) typically exist at the system level as services or port listeners, and do not correspond to a specific third-party application process name. Existing blacklist mechanisms can only enumerate regular application processes and cannot detect such system-level, active remote connection states, thus creating a detection blind spot and causing terminals that are truly under control to be missed.

[0064] In summary, the root cause of the shortcomings of existing technical solutions lies in their overly flat detection dimensions, which only focus on "whether the process name exists" and cannot identify the actual remote control process in the terminal environment.

[0065] This application provides an online examination terminal environment risk detection solution, which can be applied to online examination terminals. This solution can detect whether the terminal has a risk of effective remote control. Further optionally, it can also detect other environmental items, including but not limited to: camera checks, microphone checks, full-screen checks, display environment checks, virtual machine checks, and screen recording software checks.

[0066] Next, we will introduce a method for detecting risks in the online examination terminal environment provided in the embodiments of this application, referring to... Figure 1 As shown, the method may include the following steps:

[0067] Step S100: Obtain the set of processes currently running on the terminal.

[0068] With the necessary permissions to run the exam client and access the operating system, the detection system calls the process query interface provided by the operating system to traverse and collect information on all running processes in the current terminal system.

[0069] In some implementations, the process of obtaining the set of processes currently running on the terminal may include:

[0070] Call the process enumeration interface provided by the operating system to obtain the process IDs and process names of all active processes in the current terminal system.

[0071] For example, when the terminal is a Windows operating system, the current process list can be obtained through the process enumeration command. When the terminal is a macOS operating system, the current process list can be obtained through the process command line enumeration.

[0072] It is understood that the above process enumeration method is merely illustrative and not intended to limit this application. In other embodiments, the process set can also be obtained using any one or more combinations of the following methods:

[0073] Processes are traversed using system application programming interfaces provided by the operating system (such as Windows API's EnumProcesses or CreateToolhelp32Snapshot).

[0074] Query process information through the Windows Management Instrumentation (WMI) interface;

[0075] Obtain terminal process information through the Endpoint Security interface or the Mobile Device Management interface (MDM);

[0076] Obtain information about currently running service processes by reading the system service list;

[0077] By obtaining the window title information of all windows in the current system, the foreground process with a visual interface can be determined.

[0078] Active processes exhibiting network communication behavior can be identified by reading driver layer information or network connection tables (such as TCP / UDP connection status).

[0079] The process set obtained through the above method includes the process name, process identifier, startup method, and runtime context information of each process, providing raw input data for subsequent process layering and risk identification.

[0080] Step S110: According to the preset process layering rules, the remote control-related processes in the process set are classified into active session layer processes or background support layer processes.

[0081] In this step, remote control-related processes can be identified from the process set, and then further classified into active session layer processes or background support layer processes.

[0082] Among them, the active session layer process is the process that can directly establish or carry a valid remote control session, while the background support layer process is the process that only provides background auxiliary support and does not directly generate a valid remote control session.

[0083] Active session layer processes refer to processes capable of directly establishing network connections, rendering user interfaces, or carrying real-time session data streams. These processes typically exhibit a visual window interface, are directly associated with the currently logged-in user's interactive session, and run as the initiator or receiver of network connections. Background support layer processes primarily function as system services, daemons, auxiliary tools, or host agents. While they provide necessary underlying support for the normal operation of remote control software (such as keeping services online, handling driver communication, and maintaining privilege escalation), they do not directly generate user-facing remote control session interfaces or data channels. This layered approach effectively separates the active components of remote control-related processes that truly pose a real-time cheating risk from the background components that are merely remnants of software installation.

[0084] Step S120: Detect the native remote control enabled status of the terminal operating system to obtain the system-level remote control status signal.

[0085] This step obtains the native remote control capability activation status from the operating system's underlying layers, serving as an important supplement to process detection. System-level remote control status signals reflect the current operational status of the operating system's integrated remote desktop, screen sharing, or remote management functions, originating from the operating system's core service status or system configuration parameters. The detection system generates this signal by querying the running status of system services, checking the listening status of specific system ports, or reading system remote setting switches. For example, in a Windows system environment, it is determined based on the value of session environment variables (such as SESSIONNAME), the presence of a remote session identifier in the current session list, system remote session metrics (such as the number of session connections), or the difference between the current process session and the console session; in a macOS system environment, it is generated by detecting the activation status of the screen sharing service, the running status of the remote management agent, or the listening status of the default Virtual Network Computing (VNC) port (such as TCP port 5900). This yields a system-level remote control status signal characterizing whether the operating system's native remote control functions are enabled. This signal can independently identify remote control behaviors utilizing native system capabilities, independent of third-party software processes.

[0086] Step S130: Combine the existence status of the active session layer process with the system-level remote control status signal as the default risk judgment basis to determine whether there is a valid remote control risk in the terminal, and obtain the terminal remote control risk detection result.

[0087] Among them, the backend support layer processes are not included in the default risk assessment criteria.

[0088] The existence status of active session layer processes can refer to whether the set of active session layer processes is empty after classification in step S110. The existence status of active session layer processes includes two Boolean states: existence or non-existence.

[0089] The system-level remote control status signal is a binary status generated in step S120, indicating whether it is enabled or disabled.

[0090] In this embodiment, the default risk assessment logic is configured as follows: if any remote control-related process exists in the active session layer process, or if the system-level remote control status signal indicates that the terminal's native remote control function is enabled, the terminal is determined to have a valid remote control risk. The resulting terminal remote control risk detection result accurately reflects whether the current terminal has the capability to perform remote control or is currently engaging in remote control behavior.

[0091] In addition, the default risk assessment criteria exclude background support processes, effectively avoiding false alarms caused by the persistent presence of background services in remote control software.

[0092] In some embodiments of this application, the aforementioned step S110 is described, which involves classifying remote control-related processes in the process set into active session layer processes or background support layer processes according to preset process layering rules.

[0093] In one optional implementation, remote control-related processes in the process set can be categorized into either active session layer processes or background support layer processes based on a pre-configured process classification list. The process classification list contains information on processes belonging to the active session layer and processes belonging to the background support layer. Classification is achieved by matching remote control-related processes in the process set with the process classification list.

[0094] In another optional implementation, processes can be categorized based on their runtime context information. Specifically:

[0095] First, obtain the runtime context information of each remote control-related process in the process set.

[0096] Runtime context information characterizes the dynamic behavior and state attributes of a process within the current operating system environment, distinct from static program file information. For risk detection clients, this information can originate from the terminal operating system's process management interface, window manager interface, and session management service. By calling the operating system's application programming interface to query the process list, and for each process identified as remote control-related, further calls are made to the system's underlying interface to extract real-time state data such as its process identifier, parent process identifier, startup type, window handle ownership, and session number.

[0097] The specific data acquisition methods differ across operating system platforms. On Windows, the detection component can utilize the Windows Management Specification interface or Task Manager command-line tool to obtain the process's command-line parameters, service status, and session ID. On macOS, information such as the process's startup time, the user session it belongs to, and whether it is a background daemon process can be obtained through BSD (Berkeley Software Distribution) system calls or the Activity Monitor interface.

[0098] The above raw data is integrated to form a contextual description of whether the process has a visual interface, whether it is started as a system service or daemon process, and whether it is associated with the current user interaction session.

[0099] Furthermore, based on the runtime context information, remote control-related processes are classified as active session layer processes or background support layer processes.

[0100] Based on the obtained runtime context information, classification logic is executed according to preset hierarchical rules. Here, active session layer processes can refer to processes with a visible window interface and associated with the current user interaction session. Background support layer processes can refer to processes without a visible window interface that are started as system services or daemons.

[0101] In some embodiments of this application, a risk baseline library may be maintained, which includes a remote control baseline library, a screen recording software baseline library, and a virtual machine software baseline library.

[0102] The risk baseline library is built during the system initialization or rule update phase. Internally, it is logically divided into three parallel subsets, each corresponding to a different dimension of cheating risk environment. Specifically, the remote control baseline library stores the characteristic identifiers of various remote desktops, remote assistance, and third-party remote control clients; the screen recording software baseline library stores the characteristics of software capable of recording or live streaming screen content; and the virtual machine software baseline library stores the characteristics of virtualization management programs or clients used to run virtual operating systems on the host operating system.

[0103] In one optional implementation, the construction process of the risk baseline library may include: collecting known cheating software samples from online examination scenarios, official process name lists provided by operating system vendors, and publicly available sources of risk software intelligence; extracting key identifiers such as process names, file path characteristics, and signature information of various software types using natural language processing or regular expression matching; mapping the software to three categories—remote control, screen recording, or virtual machine—based on its functional attributes, forming key-value pairs or hash table-structured data entries; and aggregating all entries to generate the risk baseline library. To address the emergence of new cheating software, this risk baseline library supports dynamic expansion and updates via server-side configuration or a local rule editor, ensuring the timeliness of its risk identification capabilities.

[0104] Based on the maintained risk baseline library, this application can match the processes in the obtained process set with the risk baseline library, classify the processes that match the remote control baseline library as remote control related processes, classify the processes that match the screen recording software baseline library as screen recording software processes, and classify the processes that match the virtual machine software baseline library as virtual machine software processes.

[0105] Specifically, using the aforementioned well-maintained risk baseline library, multi-dimensional feature matching and classification are performed on the acquired set of currently running processes on the terminal to accurately identify process objects with specific risk attributes from the generalized system processes. By traversing each process entity in the process set, its process name or executable path is extracted as a matching key value, and this key value is compared with the feature entries in the remote control baseline library, the screen recording software baseline library, and the virtual machine software baseline library, respectively.

[0106] The matching process can employ methods such as exact string matching, wildcard matching, or regular expression matching. When a process's characteristic key value matches a corresponding entry in the remote control baseline library, the process is marked and categorized as a remote control-related process. Similarly, if it matches in the screen recording software baseline library, it is categorized as a screen recording software process; if it matches in the virtual machine software baseline library, it is categorized as a virtual machine software process. Through this classification operation based on multi-dimensional baselines, the originally chaotic set of processes is mapped into structured data objects with clear risk semantics.

[0107] After completing the matching of the above processes with the risk baseline library, a screen recording risk detection result is generated based on the existence status of the screen recording software process, and a virtual machine risk detection result is generated based on the existence status of the virtual machine software process.

[0108] The screen recording risk detection result is used to characterize whether there is a risk of screen recording behavior currently running on the terminal. Its generation logic is to check whether the set of categorized screen recording software processes is empty. If the set of screen recording software processes contains at least one process, it indicates that screen recording software is running in the current terminal environment. At this time, it is determined that there is a screen recording risk, and the screen recording risk detection result is marked as failing or having a risk. Conversely, if the set of screen recording software processes is empty, it is determined that there is no screen recording risk, and the detection result is marked as passing.

[0109] Similarly, the virtual machine risk detection result is used to characterize whether the terminal is currently in a virtualization environment. Its generation logic is based on the existence status of the categorized virtual machine software processes. If a virtual machine software process is detected running, it means that the candidate may be hiding cheating tools or performing multiple instances of the virtual machine image. In this case, it is determined that there is a virtual machine risk, and the virtual machine risk detection result is marked as failing. If no such process is detected, it is considered passing.

[0110] The generated detection results are encapsulated into a standardized data structure containing information such as risk category, judgment status, and specific process details of the hit. This structure is not only used for local real-time access control (controlling whether the terminal can enter the examination interface), but also provides a structured data foundation for subsequent risk aggregation analysis and server-side review.

[0111] In this embodiment, in addition to identifying remote control risks, it can further detect multi-dimensional environmental risks such as screen recording software and virtual machine software on the terminal, effectively making up for the shortcomings of a single remote control detection method.

[0112] In some embodiments of this application, an optional implementation scheme is described for the aforementioned step S120, which detects the native remote control enabled status of the terminal operating system to obtain a system-level remote control status signal.

[0113] (1) If the terminal is a Windows system, the system remote desktop session status can be detected to obtain the system-level remote control status signal.

[0114] The process of detecting the remote desktop session status of the system may include:

[0115] Detect one or more of the following: session environment variables, current session list, system remote session metrics, differences between current process sessions and console sessions.

[0116] In the Windows operating system environment, the session number of a process is the fundamental identifier that distinguishes between a local console session and a remote desktop session. By reading the session creation parameters recorded in the current process's environment variables or the system registry, the creation source identifier of the currently active session can be extracted. This creation source identifier reflects whether the session was generated by logging into a local physical console or through a network remote connection protocol (such as RDP). When the source identifier of the current session contains a remote desktop protocol characteristic field, it can be determined that remote desktop connection activity exists.

[0117] The system session enumeration interface is invoked to retrieve a snapshot of all sessions maintained within the system, providing a list of all active sessions. This session list includes not only the current user's session but may also include sessions of other logged-in users or system service sessions. When analyzing the current session list, the focus is on checking for session entries with remote attributes. For example, each entry in the session list typically includes a session name, connection status (e.g., Active, Connected), and session type (e.g., Console or RDP). If a session entry with a status of Connected and type RDP exists in the list, it directly indicates that the terminal is accepting a remote desktop connection. Furthermore, this list helps identify any residual remote sessions that have been disconnected but not yet logged out, preventing the use of such sessions for stealthy control.

[0118] Query session-related performance counters in the Windows Management Instrumentation (WMI) class library, or obtain various metrics related to remote sessions through the Terminal Services query interface, to reflect the activity level and resource consumption of remote connections. These system remote session metrics may include, for example, the number of current remote sessions, the cumulative connection duration of remote sessions, I / O traffic statistics, and the frame buffer update frequency. By monitoring these dynamically changing metrics, it is possible to more accurately determine whether there is ongoing data interaction, rather than just the existence of an established connection channel. For example, if the frame buffer update frequency of a remote session is continuously non-zero within a preset time window, it indicates that the remote end is viewing or operating the local desktop in real time, rather than simply being suspended.

[0119] The system retrieves the session ID of the currently detected process and compares it with the physical console session ID recognized by the system to determine whether the current running environment deviates from the physical console. A console session typically refers to a local physical session directly connected to the monitor, keyboard, and mouse. If the two IDs do not match, it means that the current process is not running in a physical console session, but rather in a virtual session created by the remote desktop service.

[0120] By comprehensively detecting one or more of the above indicators, the remote desktop session status of a Windows system can be cross-verified from multiple dimensions, including session origin, list status, activity level, and process affiliation. This multi-dimensional detection mechanism effectively avoids the risk of missed detections caused by the forgery or invalidation of a single feature, ensuring robustness in identifying remote control behavior in complex environments.

[0121] (2) If the terminal is a macOS system, detect one or more of the system screen sharing status, remote management status or virtual network computing port listening status to obtain the system-level remote control status signal.

[0122] Given that the macOS platform offers various remote access mechanisms, including screen sharing, remote management, and third-party services based on the Virtual Network Computing (VNC) protocol, a multi-dimensional coverage strategy is adopted to avoid omissions from single-dimensional detection. For screen sharing, the system's screen recording permissions or core graphics service status are queried to determine if screen content is being broadcast. For remote management, the remote management switch status in System Preferences or the running status of related daemons are checked. For virtual network computing port listening status, the default VNC service port (such as TCP port 5900) is scanned for listening. The detection results of one or more of these dimensions are combined to form a unified system-level remote control status signal. This approach not only covers the system's built-in remote control functions but also is compatible with third-party remote control tools implemented via the standard VNC protocol, achieving comprehensive awareness of the enabled status of system-level remote control on the macOS platform.

[0123] By implementing differentiated detection logic for Windows and macOS systems respectively, the heterogeneous remote control implementations at the underlying levels of different operating systems are abstracted into a unified semantic system-level remote control status signal. This cross-platform abstraction and encapsulation allows upper-layer applications to determine whether there are operating system-level remote control risks on the terminal based solely on the unified signal, without needing to concern themselves with specific operating system versions or underlying interface differences.

[0124] In some embodiments of this application, another optional implementation of the online examination terminal environment risk detection method is provided, specifically:

[0125] This application's embodiments support specifying the examination strategy before the exam. The examination strategy can specify either a strict sampling detection strategy or a default detection strategy.

[0126] Under the strict testing strategy instructed in this examination, the background support layer processes can be included in the risk assessment criteria to determine whether there is a valid remote control risk to the terminal. Specifically, if any remote control-related process exists in the background support layer processes, the terminal is determined to have a valid remote control risk.

[0127] The examination strategy, as a set of core configuration rules used for environmental risk detection, defines the specific detection standards, judgment thresholds, and response actions to be adopted under different security level requirements. The strict detection strategy is a specific working mode within the examination strategy, configured for examination scenarios with extremely high security requirements that must eliminate potential cheating risks to the greatest extent possible, such as national qualification examinations, high-stakes selection examinations, or industry entry certification examinations. In this mode, the detection logic no longer focuses solely on currently active, immediate remote control behavior, but further tightens the risk tolerance, requiring the complete removal of all software traces related to remote control in the terminal environment, including background components that, while not directly establishing a session, provide auxiliary support capabilities.

[0128] Background support layer processes can refer to a set of processes that are identified as providing only background auxiliary support and not directly generating effective remote control sessions under the process layering rules of the above embodiments. These processes usually reside in the operating system for a long time in the form of system services, daemons, or auxiliary tools.

[0129] When the current examination policy contains an identifier or parameter indicating that a strict detection policy is enabled, the risk review logic for the background support layer processes is activated. If any remote control-related process exists among the background support layer processes identified after classifying the process set, the terminal will still be determined to have a valid remote control risk under the strict detection policy, even if these processes have not currently established an active connection session.

[0130] This embodiment realizes the dynamic expansion of the risk assessment criteria, that is, from relying only on active session layer processes and system-level remote control status signals under the default policy, to including background support layer processes under the strict policy, thereby providing flexible and configurable risk control methods for examination scenarios with different security levels.

[0131] The examination strategy acts as a global switch, dynamically controlling the scope of risk assessment criteria. This allows the detection system to ensure device availability and pass rates for test takers by ignoring background support processes under a default strategy, while simultaneously eliminating potential, inactive remote control vulnerabilities by incorporating background support processes under a stricter detection strategy. This mechanism achieves a balance between detection accuracy and user experience, satisfying both the false positive rate control requirements of regular examinations and the zero-tolerance security and compliance needs of high-risk examinations.

[0132] In some embodiments of this application, the examination policy can be read first after the examination entry is triggered. The examination policy may include fields such as whether full-screen mode is required, whether a camera is required, whether a specified input method is disabled, and whether mandatory security checks are enabled.

[0133] Based on this, the online examination terminal environmental risk detection method of this application can further perform detection of one or more of the following environmental detection items:

[0134] Camera availability detection, microphone availability detection, display environment detection, input limitation warm-up detection, etc.

[0135] The above-mentioned environmental detection items are not strictly ordered in relation to the high-risk process detection items introduced earlier (including remote control risk detection, screen recording risk detection, and virtual machine risk detection). This is provided as an example. Figure 2 As shown, this application provides an example of an optional detection order:

[0136] Camera availability test → Microphone availability test → Display environment test → High-risk process test → Input restriction warm-up test.

[0137] It should be noted that, optionally, a media permissions preprocessing process can be included before initiating camera availability detection and microphone availability detection:

[0138] For macOS, system-level permissions for the camera and microphone are requested from the operating system in advance, and the permission status is obtained synchronously. Since the permission request pop-up in macOS is a system-level modal window, if the permission request is triggered in full-screen mode, the pop-up may be obscured or prevent the user from operating normally. Therefore, completing the permission request in advance before performing full-screen operation can ensure that the permission pop-up is displayed normally and the user can complete the authorization operation, thereby avoiding the detection process being blocked or failed due to the permission pop-up being obscured.

[0139] Next, the detection process for the environmental detection items in the above examples will be explained.

[0140] (1) Camera availability test:

[0141] The detection process may include:

[0142] The camera is activated and captures continuous video frames. The effectiveness of the camera's output is determined based on the image characteristics of the video frames, including one or more of the following: image brightness, percentage of dark pixels, and inter-frame motion variation.

[0143] Specifically, the camera hardware is activated by calling the system's underlying media interface or the application programming interface provided by the browser, establishing an actual data transmission channel with the camera device. During startup, a hidden video preview container is configured to avoid exposing the detection interface to the user during the detection phase. A media stream track is created and bound to this container. After the data stream is established, video frame image data is continuously captured from the video track, forming a sampling sequence for subsequent analysis. To ensure the real-time performance and effectiveness of the detection, image data is continuously acquired at a fixed frame rate within a preset time window, ensuring that the samples cover the camera's actual output state under the current lighting conditions. If a data stream is not successfully established or a valid video frame is not acquired within the preset timeout period, the camera startup is considered failed, and the camera is marked as unavailable.

[0144] The system analyzes pixel-level data from video frames to quantify the visual features of the image, thereby determining whether the camera is in a valid working state. The core of this determination lies in distinguishing between an authorized but non-functional signal state and a normal imaging state.

[0145] Based on the brightness characteristics of the image, the video frame image is converted into a grayscale image, and the average grayscale value of the entire image is calculated. If the calculated average brightness is lower than a preset darkness threshold, it is assumed that the camera may be physically obstructed, the lens cap is closed, or the camera is in a dark environment.

[0146] To assess the proportion of dark pixels, the system counts the number of pixels in a video frame whose grayscale value is below a certain lower limit and calculates their proportion of the total number of pixels. If the proportion of dark pixels exceeds a preset threshold, it indicates that the image is almost entirely black, suggesting a risk of camera obstruction or hardware malfunction.

[0147] Based on the characteristics of inter-frame motion variation, the pixel differences or structural similarities between two or more consecutive video frames are calculated. Specifically, the degree of dynamic change in the image is evaluated by performing differential operations on adjacent frames and counting the number of non-zero pixels or the mean square error value in the differential image. If the amount of inter-frame motion variation remains below a preset static threshold throughout a continuous acquisition period, the camera image is considered frozen, which may indicate a drive malfunction or sensor lock-up.

[0148] In practical applications, any of the above features can be used for quick single-dimensional judgment, or multiple features can be combined to form a composite judgment logic. For example, only when the image brightness is normal and there is a certain amount of motion change between frames is the camera's output of an image confirmed as valid. Through this multi-dimensional analysis based on pixel-level features, invalid cameras that have obtained permissions but whose images are abnormal can be effectively filtered out, providing a reliable signal source for subsequent monitoring video streams.

[0149] This method uses screen brightness to identify insufficient lighting or occlusion faults, uses the proportion of dark pixels to quantify full-screen black screen anomalies, and uses inter-frame motion changes to detect screen freezing problems. Thus, it can automatically identify camera failure scenarios caused by physical occlusion, hardware failure, or driver abnormalities without human intervention, ensuring that the proctoring videos captured by the online examination system are authentic and usable.

[0150] (2) Microphone availability detection:

[0151] The detection process may include:

[0152] The microphone is activated and audio signals are acquired. The microphone is then used to determine whether it is in a valid input state based on the audio signal strength.

[0153] Specifically, this application creates a microphone detection instance, starts the microphone through the browser's media interface, attempts to acquire the audio track, and sets a timeout during the startup process. If the audio track is successfully acquired within the timeout period, the microphone device is confirmed to be usable; if the timeout occurs or startup fails, the microphone device is confirmed to be unusable, and the corresponding error type is recorded. This timeout protection mechanism is based on the same principle as the timeout protection mechanism in the aforementioned camera detection, and is used to prevent the detection process from being suspended for a long time due to the microphone device freezing, driver unresponsiveness, or being occupied by other applications.

[0154] During the detection process, the device identifier, group identifier, track label, and error type when the microphone fails to start are recorded. The acquired audio signal is sampled to obtain audio signal strength information, which is used to help determine whether the microphone can collect valid audio input (for example, when the audio signal strength is continuously zero or lower than the preset strength threshold, it can be determined that the microphone has no valid input, which may be due to mute, being occupied, or hardware failure).

[0155] Upon successful detection, the client will save the identifier of the available microphone device as the priority device for audio detection during the exam. This means that in subsequent exams, when audio capture is required (e.g., for audio behavior analysis in AI proctoring), the client will prioritize using this confirmed available microphone device to avoid delays or anomalies caused by device switching or repeated detection.

[0156] Regarding the admission policy for microphone checks: By default, microphone checks are only a non-blocking warning item. That is, if the microphone detection fails, only a prompt message is displayed to the examinee, which does not affect their entry into the exam. However, in exam scenarios that require strict audio proctoring, microphone checks can be adjusted to be a mandatory option according to the exam policy. That is, if the microphone detection fails, it is treated the same as camera checks and used as a basis for blocking access.

[0157] (3) Display environment detection:

[0158] The detection process may include:

[0159] The system detects the full-screen state of the current window on the terminal and the number of monitors connected to the system, generating full-screen state detection results and single-monitor detection results.

[0160] Specifically, by calling the application programming interface provided by the operating system, the current window properties of the examination client are read in real time to determine whether the window covers the entire display area and is in exclusive display mode, thus determining the full-screen state. At the same time, the display subsystem can be queried to enumerate the currently connected and active physical display devices and count the number of monitors to identify whether there are external secondary screens or multi-monitor expansion configurations.

[0161] Based on whether the obtained full-screen state meets the preset exam strategy requirements (e.g., forced full-screen mode), a corresponding full-screen state detection result is generated; based on whether the count of monitors is a single value, a single monitor detection result is generated. These detection results are used to block paths for finding answers via external secondary screens or cheating through split-screen mode.

[0162] (4) Input limit preheating detection:

[0163] The detection process may include:

[0164] When all mandatory tests pass and the exam strategy indicates that the specified input method is disabled, the availability of the terminal input method control component is pre-detected, and the input restriction capability is warmed up.

[0165] Mandatory checks can refer to environmental checks marked as required by the admission strategy for this exam, such as, but not limited to, camera availability, full-screen mode, single-monitor mode, and remote control risk checks. Passing all mandatory checks means that the terminal's current basic environment meets the security admission requirements for the exam. This is a prerequisite for performing input restriction warm-up checks, aiming to ensure that input method capabilities are prepared only for terminals with a legitimate exam environment, avoiding unnecessary consumption of system resources.

[0166] The exam policy instruction to disable a specific input method can refer to a configuration field in the exam configuration issued from the server or a local global policy that explicitly restricts candidates from using a specific input method (such as a Chinese input method). This configuration field reflects the exam's standardized requirements for the input environment, and when it is activated, it means that technical constraints need to be placed on the input method switching behavior of the terminal during the exam.

[0167] Input method control components can refer to program interfaces or driver modules deployed in the terminal operating system for monitoring and managing input method switching states. Their core functions include obtaining the currently active input method identifier, intercepting or disabling specified input method processes, and responding to input method switching requests.

[0168] Pre-detecting the availability of the terminal input method control component can be done by calling the application programming interface (API) provided by the operating system to attempt to establish a communication connection with the input method control component, read the component version number, permission status, or send a test control command. If the component responds normally and its permissions meet the requirements for performing the disabling operation, the pre-detection is considered successful; if the component is not installed, the response times out, or a permission error is returned, the pre-detection is considered a failure. This pre-detection can expose technical vulnerabilities caused by missing components or insufficient permissions before the exam officially begins.

[0169] The ability to pre-initialize input restrictions refers to the process of initializing the relevant states or resources for input restrictions after confirming the availability of the components, so that the system can take effect immediately when the exam officially begins. This process ensures that restrictions on specified input methods are executed smoothly and stably during the exam, avoiding page freezes caused by initialization time or interruptions to the exam process due to permission request pop-ups.

[0170] Input restriction preheating checks are not displayed as page-visible checks, but they can be written to the runtime diagnostic log and processed by the input restriction service during the exam.

[0171] Reference Figure 2 As shown, in some embodiments of this application, the online examination terminal environment risk detection method may further include a step of aggregating the detection results of various environmental detection items, specifically:

[0172] The test results of various types of environmental testing items (such as the remote control risk test results mentioned above and the test results of other environmental testing items) are uniformly mapped into a standardized inspection item data structure.

[0173] The standardized inspection item data structure includes: item identifier, readable name, whether it is required, whether it passes or fails, and failure message fields.

[0174] The project identifier is a key value used to uniquely identify a specific environmental testing category.

[0175] Readable names are natural language description fields displayed to test takers and invigilators, clearly indicating the physical meaning of the current detection item in the user interface and audit report. For example, mapping remoteControl to remote control environment detection ensures that non-technical personnel can intuitively understand the security dimension targeted by the detection result.

[0176] The "Required" field is a Boolean parameter representing the criticality of the current detection item in the current exam access strategy. Its value is determined by the exam strategy and instance configuration. This field is used to distinguish between core blocking items and suggested prompts. Only when this field is marked as true and the detection fails will the forced blocking logic be triggered, thereby achieving tiered access control.

[0177] The pass / fail field is a Boolean status value generated based on the actual execution results of the aforementioned steps. This field transforms the original detection signals (such as process existence status, system API return values, and screen feature analysis results) into unified high and low level logic, serving as the direct basis for subsequent summary judgment and admission decision.

[0178] The failure message field is the text content that is filled in when the test fails. This field contains the specific reason for the failure and repair suggestions, such as "Active remote control session detected, please close the remote desktop software", providing candidates with clear error location and operation guidance.

[0179] By using the standardized inspection item data structure described above, heterogeneous detection results scattered across different detection modules and operating system platforms (such as session lists on Windows, port listening status on macOS, and validity parameters of video streams) are forcibly mapped to a homogeneous data contract. This enables the front-end presentation layer, local access control judgment layer, server-side reporting layer, and log auditing layer to interact based on the same data structure, thereby establishing a closed-loop data chain from terminal detection to cloud-based auditing and effectively reducing the complexity of multi-terminal data integration.

[0180] Reference Figure 2 As shown, in some embodiments of this application, the online examination terminal environment risk detection method may further include access control and result display stages, specifically:

[0181] Perform a logical AND operation on the pass status of all check items marked as mandatory to generate a summary result of terminal environment access control.

[0182] Specifically, based on the standardized check item data structure generated in the preceding steps, a set of check items whose "mandatory" attribute is true is extracted. A logical AND operation is performed on the "pass" field of each check item in this set. If all check items marked as mandatory are in the "pass" state, the result is determined to be true, meaning the terminal environment access summary result is passed; if any mandatory check item is in the "fail" state, the summary result is determined to be failed.

[0183] If the exam policy indicates that a mandatory security check policy is enabled and the access summary result is "failed", the terminal will be blocked from entering the exam interface, and only the environment check will be allowed to be re-executed.

[0184] Specifically, the system reads the exam policy configuration. When it detects that the mandatory security check policy is enabled and the terminal environment access summary result is "failed," a blocking mechanism is triggered. This mechanism locks the entrance to the exam interface, preventing users from switching to the answer page or accessing the exam questions. At this time, the terminal user interface only retains interactive controls related to environment detection, such as a re-detection button or specific error messages, guiding users to rectify the environment according to the prompts for the failed checks (such as asking to close the remote desktop software or connect the camera) and try the detection again. Through this mandatory blocking logic, it ensures that in high-risk, high-compliance exam scenarios, only terminal devices that fully comply with security standards can access the exam system, thereby effectively avoiding the risk of cheating caused by environmental risks.

[0185] If the exam policy does not enable the mandatory security check policy and there are failed checks, display the failed checks and allow the terminal to enter the exam interface, while retaining the audit log of the failed checks.

[0186] Specifically, when the policy instruction does not enable the mandatory security check policy, and the summary results contain failed checks (including failed mandatory items or non-mandatory risk items), flexible access control is implemented. The system generates a list containing details of the failed checks and displays it to the user through pop-ups, sidebars, or status bars, clearly informing them of the current environmental risks, while granting the user access to the exam interface to begin answering questions. To ensure the traceability of risks, the item identifier, failure reason, and timestamp of all failed checks are encapsulated into an audit log. This audit log is not only persistently stored locally but also synchronously uploaded to the server along with the exam log or security report. This allows invigilators or back-end administrators to trace the environmental status of candidates upon entry based on these audit logs during or after the exam, providing objective data support for subsequent violation determinations or score reviews.

[0187] In this embodiment, the mandatory security check strategy acts as a decision switch, driving two different response paths: blocking intervention and allowing auditing. This design allows the same set of environmental monitoring data to adapt to exam management needs of varying rigor, satisfying both the rigid security access requirements of formal exams and the flexible entry requirements of mock exams or low-risk scenarios. Simultaneously, unified audit logs preserve comprehensive evidence of all environmental anomalies, achieving a balance between security compliance and user experience.

[0188] In some embodiments of this application, a system-level remote control risk monitoring mechanism for examinations is further provided. The online examination terminal environment risk detection method of this application may also include the following steps:

[0189] After the terminal enters the examination phase, the system-level remote control status signal is detected at a low frequency, lower than the pre-examination detection frequency. When a system-level remote control status signal indicating that the remote control function is enabled is detected, a remote control risk alarm is triggered.

[0190] Specifically, once the terminal enters the examination phase, the monitoring focus shifts from a comprehensive pre-exam environment scan to continuous tracking of changes in the status of key systems. During this phase, instead of enumerating and analyzing all third-party processes at high frequency, the monitoring is adjusted to a low-frequency approach, periodically polling only system-level remote control status signals. This low-frequency polling cycle can be set, for example, every 30 to 60 seconds, or even longer intervals. The specific frequency can be dynamically adjusted based on the terminal's CPU load, the bandwidth usage of the AI-powered proctoring video stream, and the current examination's security requirements. By significantly reducing the detection frequency and limiting the detection targets, frequent system call process query commands can be avoided from consuming processor resources, preventing exam page lag or unstable frame rates in the AI-powered proctoring video due to resource contention, thereby ensuring a smooth interactive experience for examinees and high-quality video uploads.

[0191] The detection logic for system-level remote control status signals remains consistent with the pre-exam phase, employing different native status detection methods for Windows and macOS systems. Detailed procedures are described earlier and will not be repeated here. The aforementioned detection process is executed silently in a background thread or independent daemon process, without interfering with the foreground rendering of the exam's main interface.

[0192] If a remote control channel at the operating system level is detected as activated during any low-frequency polling during the examination, a high-level takeover risk is immediately identified, and a remote control risk alarm is triggered. This alarm mechanism could include, for example, displaying a prominent warning overlay on the candidate's client interface, indicating the detection of unauthorized remote control activity, and simultaneously uploading this risk event as a critical audit record to the proctoring server for manual review and intervention by the proctor.

[0193] In some embodiments of this application, the method provided in this application may further include: reporting the remote control risk detection results and the detection results of other environmental detection items to the server to generate a security check audit log.

[0194] The remote control risk detection result is generated based on the judgment logic of the terminal's active session layer process and system-level remote control status signals in the aforementioned embodiments, and is used to characterize whether the terminal is currently in a risky state of being remotely controlled. The detection results of other environmental detection items cover the output of other environmental security check items besides remote control risk detection, such as camera real availability detection results, microphone availability detection results, display environment detection results (such as full-screen state and single monitor detection results), and input restriction warm-up detection results, etc.

[0195] The server is deployed on the network side, serving as a server cluster or single server to receive, store, and process data reported by examination clients, undertaking the function of persistent storage and management of security audit data. The reporting process involves calling the server's pre-defined application programming interfaces (APIs) to encapsulate the various test results into network packets according to the agreed data transmission protocol, and sending them to the server via the internet. This aggregates various environmental status information scattered across candidate terminals to a centralized server, providing a data foundation for subsequent security audits, compliance checks, and issue tracing.

[0196] After receiving the remote control risk detection results and other environmental detection results reported by the terminal, the server performs data parsing and log generation operations. The security check audit log transforms the entire process of this environmental detection into a structured, traceable audit record according to time sequence. Specifically, the server receives network packets and parses out the various detection results in the load. These results include at least metadata such as the check item name, the status indicator of pass or fail, the detection timestamp, and the unique identifier of the terminal device. Subsequently, according to a preset log format template, the parsed detection data is filled into the corresponding fields to form a complete audit record. Finally, the audit record is persistently stored in the server's database or log storage system, forming an immutable historical record.

[0197] By reporting multi-dimensional environmental detection results from the terminal side in real time and generating structured security check and audit logs on the server side, a complete technical closed loop of local detection, remote reporting, and cloud auditing is constructed. This mechanism enables invigilators or maintenance personnel to retrospectively analyze the environmental security status of any exam based on historical logs recorded on the server side. This not only solves the risk of data tampering or loss that may exist if relying solely on local detection, but also provides high-quality data support for subsequent optimization of exam security strategies and analysis of cheating methods.

[0198] Next, we will introduce several specific examples of the online examination terminal environment risk detection method proposed in this application:

[0199] Example 1: Mandatory security check upon entry.

[0200] An exam requires a webcam, full-screen mode, single-screen mode, no remote control, no virtual machine, and no screen recording. The client initiates a security check after the user clicks "Security Check." If webcam permissions are allowed but the image remains consistently dark with no frame variation, the camera check fails; if two monitors are detected simultaneously, the single display check fails. Because `force Security CheckEnabled` is true and `passed` is false, the client prevents access to the exam and prompts for a re-check.

[0201] Example 1: Suppression of false alarms in remote control.

[0202] The student's computer has a remote control software installed. Its background service runs continuously after system startup, but the foreground client is not open, and there are no remote desktop sessions, screen sharing, or remote management signals on the system. This application identifies this background service as a candidate option rather than a default hard block, therefore it will not prevent the exam from being blocked solely because of the software installation. If the student actually opens the remote control client or the system is in a remote session, the remote control check will fail.

[0203] Example 3: Discovery via system-level remote assistance during the exam.

[0204] After the exam begins, the client will no longer scan for third-party processes frequently, but will continue to check system-level remote control signals at a low frequency. If the macOS side detects that the screen sharing service is running or that port 5900 is listening, a system remote assistance risk event will occur, and a soft blocking mask can be displayed or the proctor's trajectory can be reported according to the policy.

[0205] This application also provides an electronic device in its embodiments. (See reference...) Figure 3 The diagram illustrates a structural schematic suitable for implementing the electronic device in the embodiments of this application. The electronic device in the embodiments of this application may include, but is not limited to, fixed terminals such as tablet computers, learning machines, examination terminals, desktop computers, etc. Figure 3 The electronic device shown is merely an example and should not impose any limitation on the functionality and scope of use of the embodiments of this application.

[0206] like Figure 3 As shown, the electronic device may include a processing unit (e.g., a central processing unit, a graphics processing unit, etc.) 1, which can perform various appropriate actions and processes according to a program stored in a read-only memory (ROM) 2 or a program loaded from a storage device 8 into a random access memory (RAM) 3, to implement the online examination terminal environment risk detection method of the foregoing embodiments of this application. When the electronic device is powered on, the RAM 3 also stores various programs and data required for the operation of the electronic device. The processing unit 1, ROM 2, and RAM 3 are interconnected via a bus 4. An input / output (I / O) interface 5 is also connected to the bus 4.

[0207] Typically, the following devices can be connected to I / O interface 5: input devices 6 including, for example, touchscreens, touchpads, keyboards, mice, cameras, microphones, accelerometers, gyroscopes, etc.; output devices 7 including, for example, liquid crystal displays (LCDs), speakers, vibrators, etc.; storage devices 8 including, for example, memory cards, hard drives, etc.; and communication devices 9. Communication device 9 allows electronic devices to communicate wirelessly or wiredly with other devices to exchange data. Although Figure 3 Electronic devices with various devices are shown, but it should be understood that it is not required to implement or have all of the devices shown. More or fewer devices may be implemented or have instead.

[0208] This application also provides a computer program product, including computer-readable instructions, which, when executed on an electronic device, cause the electronic device to implement any of the online examination terminal environment risk detection methods provided in this application.

[0209] This application also provides a computer-readable storage medium that carries one or more computer programs. When the one or more computer programs are executed by an electronic device, the electronic device can implement any of the online examination terminal environment risk detection methods provided in this application.

[0210] It should also be noted that the device embodiments described above are merely illustrative. The units described as separate components may or may not be physically separate, and 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 network units. Some or all of the modules can be selected to achieve the purpose of this embodiment according to actual needs. In addition, in the device embodiment drawings provided in this application, the connection relationship between modules indicates that they have a communication connection, which can be implemented as one or more communication buses or signal lines.

[0211] Through the above description of the embodiments, those skilled in the art can clearly understand that this application can be implemented by means of software plus necessary general-purpose hardware, or it can be implemented by special-purpose hardware including application-specific integrated circuits, special-purpose CPUs, special-purpose memory, special-purpose components, etc. Generally, any function performed by a computer program can be easily implemented by corresponding hardware, and the specific hardware structure used to implement the same function can also be diverse, such as analog circuits, digital circuits, or special-purpose circuits. However, for this application, software program implementation is more often the preferred implementation method. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, can be embodied in the form of a software product. This computer software product is stored in a readable storage medium, such as a computer floppy disk, USB flash drive, mobile hard disk, ROM, RAM, magnetic disk, or optical disk, etc., and includes several instructions to cause a computer device (which may be a personal computer, training equipment, or network device, etc.) to execute the methods described in the various embodiments of this application.

[0212] In the above embodiments, implementation can be achieved, in whole or in part, through software, hardware, firmware, or any combination thereof. When implemented in software, it can be implemented, in whole or in part, as a computer program product.

[0213] The computer program product includes one or more computer instructions. When the computer program instructions are loaded and executed on a computer, all or part of the processes or functions described in the embodiments of this application are generated. The computer may be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions may be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another. For example, the computer instructions may be transmitted from one website, computer, training device, or data center to another website, computer, training device, or data center via wired (e.g., coaxial cable, fiber optic, digital subscriber line (DSL)) or wireless (e.g., infrared, wireless, microwave, etc.) means. The computer-readable storage medium may be any available medium that a computer can store or a data storage device such as a training device or data center that integrates one or more available media. The available media may be magnetic media (e.g., floppy disks, hard disks, magnetic tapes), optical media (e.g., DVDs), or semiconductor media (e.g., solid-state drives (SSDs)).

[0214] The various embodiments in this specification are described in a progressive manner. Each embodiment focuses on the differences from other embodiments. The various embodiments can be combined as needed, and the same or similar parts can be referred to each other.

Claims

1. A method for detecting risks in an online examination terminal environment, characterized in that, include: Get the set of processes currently running in the terminal; According to the preset process layering rules, the remote control-related processes in the process set are classified into active session layer processes or background support layer processes. The active session layer processes are those that can directly establish or carry valid remote control sessions, while the background support layer processes are those that only provide background auxiliary support and do not directly generate valid remote control sessions. Detect the native remote control enabled status of the terminal operating system to obtain the system-level remote control status signal; The existence status of the active session layer process and the system-level remote control status signal are combined as the default risk judgment basis to determine whether there is a valid remote control risk in the terminal, and the terminal remote control risk detection result is obtained. The background support layer process is not included in the default risk assessment criteria.

2. The method according to claim 1, characterized in that, According to preset process layering rules, the process of classifying remote control-related processes in the process set into active session layer processes or background support layer processes includes: Obtain the runtime context information of each remote control-related process in the process set; Based on the runtime context information, the remote control-related processes are classified as active session layer processes or background support layer processes. The runtime context information includes at least one or more of the following: whether the process has a visual window interface, whether the process is started as a system service or daemon process, and whether the process is associated with the current user interaction session.

3. The method according to claim 1, characterized in that, Also includes: Maintain a risk baseline library, which includes a remote control baseline library, a screen recording software baseline library, and a virtual machine software baseline library; The processes in the process set are matched with the risk baseline library. Processes that match the remote control baseline library are classified as remote control related processes, processes that match the screen recording software baseline library are classified as screen recording software processes, and processes that match the virtual machine software baseline library are classified as virtual machine software processes. Based on the existence status of the screen recording software process, a screen recording risk detection result is generated; based on the existence status of the virtual machine software process, a virtual machine risk detection result is generated.

4. The method according to claim 1, characterized in that, The process of combining the existence status of the active session layer process with the system-level remote control status signal as the default risk judgment criterion to determine whether the terminal has a valid remote control risk includes: If any remote control-related process exists in the active session layer process, or if the system-level remote control status signal indicates that the terminal operating system's native remote control function is enabled, then the terminal is determined to have a valid remote control risk.

5. The method according to claim 1, characterized in that, The process of detecting the native remote control enabled status of the terminal operating system includes: If the terminal is a Windows system, detect the system's remote desktop session status to obtain the system-level remote control status signal; If the terminal is a macOS system, detect one or more of the following: system screen sharing status, remote management status, or virtual network computing port listening status to obtain the system-level remote control status signal.

6. The method according to claim 5, characterized in that, The process of detecting the remote desktop session status of the system includes: Detect one or more of the following: session environment variables, current session list, system remote session metrics, differences between current process sessions and console sessions.

7. The method according to claim 1, characterized in that, Also includes: Under the strict testing strategy instructed in this examination, the background support layer processes are included in the risk assessment criteria to determine whether the terminal poses a valid risk of remote control. Specifically, if any remote control-related process exists in the background support layer processes, the terminal is deemed to pose a valid risk of remote control.

8. The method according to claim 1, characterized in that, It also includes camera availability testing, a process that includes: Start the camera and capture continuous video frames; The determination of whether the camera is effectively outputting images is based on the image features of video frames. The image features include one or more of the following: image brightness, dark pixel ratio, and inter-frame motion variation.

9. The method according to claim 1, characterized in that, It also includes microphone availability detection, a process that includes: The microphone is activated and audio signals are acquired. The microphone is then used to determine whether it is in a valid input state based on the audio signal strength.

10. The method according to claim 1, characterized in that, It also includes display environment detection, the process of which includes: Detect the full-screen state of the current window on the terminal, as well as the number of monitors connected to the system; Generate full-screen state detection results and single-monitor detection results.

11. The method according to claim 1, characterized in that, It also includes input limitation preheating detection, a process that includes: When all mandatory tests pass and the exam strategy indicates that the specified input method is disabled, the availability of the terminal input method control component is pre-detected, and the input restriction capability is warmed up.

12. The method according to any one of claims 1-11, characterized in that, Also includes: The results of remote control risk detection are mapped together with the results of other environmental detection items into a standardized inspection item data structure. The standardized inspection item data structure includes: item identifier, readable name, whether it is required, whether it passes, and failure message fields.

13. The method according to claim 12, characterized in that, Also includes: Perform a logical AND operation on the pass status of all check items marked as mandatory to generate a summary result of terminal environment access control; When the exam policy indicates that a mandatory security check policy is enabled and the access summary result is "failed", the terminal will be blocked from entering the exam interface, and only the environment check will be re-executed. If the exam policy does not enable the mandatory security check policy and there are failed checks, display the failed checks and allow the terminal to enter the exam interface, while retaining the audit log of the failed checks.

14. The method according to any one of claims 1-11, characterized in that, Also includes: After the terminal enters the examination stage, the system-level remote control status signal is detected at a low frequency, lower than the pre-examination detection frequency. When the system-level remote control status signal indicates that the remote control function is enabled, a remote control risk alarm is triggered.

15. An electronic device, characterized in that, include: Memory and processor; The memory is used to store programs; The processor is used to execute the program to implement each step of the online examination terminal environment risk detection method as described in any one of claims 1 to 14.

Images