UWP application outgoing management and control function compatibility adaptation method, system and device and medium

Abstract

The invention provides a UWP application outgoing management and control function compatibility adaptation method, system and device and a medium, and specifically belongs to the technical field of UWP application processing, and the method specifically comprises the steps that a service module creates a named pipeline instance, and grants access authority to the named pipeline instance to all UWP programs; when monitoring a process main module loading event, the driving module sends a process starting notification to the service module; judging whether the newly started process is a UWP process or not, and if yes, inserting an APC item into a main thread of the UWP process in an asynchronous process calling mode; whether the file content has a leakage risk or not is judged, if the file content has the leakage risk, feedback for refusing outgoing is given, and if the injected DLL module receives the feedback, corresponding API calling fails. According to the method, on the premise that sandbox isolation is not destroyed, unified, real-time and auditing management and control of out-of-service issuance of all UWP application files are achieved; and the influence on the system stability and performance is small.

Description

Technical Field

[0001] The present invention belongs to the field of UWP application processing technology, and specifically relates to a UWP application outbound control function compatibility adaptation method, system, device and medium. Background Art

[0002] With the rapid development of information technology, the information security industry has become a crucial sector. Particularly in the enterprise market and in the area of ​​personal privacy protection, demand for products and services that effectively prevent data leaks continues to grow. We provide comprehensive data protection services for the complex network environments of large enterprises, including but not limited to endpoint protection, network intrusion detection, identity authentication, and access management. With increasing public concern about personal data privacy, more and more consumers are seeking applications and services that can help them protect their personal information from misuse.

[0003] In related technologies, due to the limitations of the UWP process's security mechanisms, it is difficult for external modules to establish effective communication connections with it, resulting in the inability to effectively monitor and manage its internal operations. Process startup monitoring is not timely and accurate enough, and effective intervention in the early stages of the UWP process is often impossible. Furthermore, due to the unique nature of the UWP process, it is difficult to intercept API calls related to outbound file transmission, making it impossible to determine in a timely manner whether outbound file transmission poses a risk of leakage and intervene. Summary of the Invention

[0004] The present invention provides a compatibility adaptation method for the outbound control function of UWP applications. The method achieves unified, real-time, and auditable control of the outbound behavior of all UWP application files without destroying sandbox isolation, and has little impact on system stability and performance.

[0005] Methods include: S101: The service module creates a named pipe instance and grants all UWP programs access to the named pipe instance by modifying the access control list of the security descriptor; S102: When the driver module detects a process main module loading event, it sends a process start notification to the service module; S103: The service module determines whether the newly started process is a UWP process. If not, it waits for the next process start notification. If so, it executes step S104; S104: inserting an APC item containing ShellCode into the main thread of the UWP process through an asynchronous procedure call; the ShellCode includes function instructions for loading a target DLL module and performing initialization; the target DLL module is used to intercept APIs related to file outbound transmission; S105: When the user is ready to send a file, the DLL module injected into the UWP process connects to the named pipe instance created by the service module and informs the service module of the file to be sent. S106: The service module determines whether there is a risk of leakage of the file content. If so, it gives a feedback of refusing to send it out. If the injected DLL module receives the feedback, the corresponding API call fails.

[0006] It should be further explained that step S101 specifically includes: The service module constructs the security identifier SID of the ALLAPPLICATIONPACKAGES group through the system function; Fill the EXPLICIT_ACCESS structure with the security identifier and the preset access mask to generate a valid access control entry; Insert access control items into an empty custom access control list through system functions; Initialize the security descriptor; Set the custom access control list as the DACL of the security descriptor; Create a named pipe instance and bind the security descriptor to the named pipe instance during the creation process; Releases the memory resources used by security identifiers, access control entries, custom access control lists, and security descriptors.

[0007] It should be further explained that step S101 also includes: Use the security identifier generation tool provided by the operating system or predefined system constants to obtain the fixed RID value corresponding to the ALLAPPLICATIONPACKAGES group, and combine it with the domain or local computer identifier to generate a complete SID string; According to the access requirements of the target resource, set the access mask of the ACE and configure the flag of the ACE to ensure that the ACE can explicitly grant the ALLAPPLICATIONPACKAGES group specific access rights to the named pipe instance; After initializing the empty DACL through the security descriptor operation function provided by the operating system, ACEs are added to the specified positions of the DACL in sequence to form a DACL structure that contains the target permission rules; Bind the DACL containing ACE to the security descriptor SD of the named pipe instance; initialize the infrastructure of the security descriptor SD, set the generated DACL as the primary DACL of SD, and verify the validity of the binding between SD and the named pipe instance.

[0008] It should be further explained that step S103 specifically includes: Perform initial status check on the empty custom access control list (DACL) to confirm that the default access control items and structures are not damaged and comply with the system security descriptor specification. If there is any implicit invalid structure, repair it. Determine the position of the ACE to be inserted in the DACL based on the preset security priority rules; After inserting the generated ACE into the specified position of the DACL, check whether there is another ACE in the DACL with the same security identifier SID as the ACE. If so, compare the access mask to determine whether the same SID is granted both allow and deny permissions. Adjust the access mask or position of the ACE based on the conflict type. Verify the integrity of the DACL after inserting the ACE.

[0009] It should be further explained that step S104 specifically includes: The service module constructs ShellCode, which includes function instructions for loading the target DLL module and performing initialization, as well as parameters required by the function instructions; The service module writes the ShellCode into the address space of the UWP process through a memory operation function; The service module inserts an APC item into the main thread of the UWP process through an asynchronous procedure call function, and the callback function pointer of the APC item points to the starting address of the ShellCode; The main thread of the UWP process enters a waiting state, checks its APC queue and executes the callback function in the APC item; The callback function loads the target DLL module through the system loading function, and obtains the initialization function address of the DLL module by obtaining the export function address; The callback function calls the initialization function to initialize the DLL module. The initialization includes intercepting the file's outgoing API function.

[0010] It should be further explained that step S105 specifically includes: When the main thread of the UWP process executes the APC item, the pre-verification function in the ShellCode is used to check the accessibility of the target DLL module path in the UWP process environment, and whether the digital signature of the DLL file meets the trust level of the UWP application. If not, the loading process is terminated and the reason for the verification failure is recorded; ShellCode calls LdrLoadDll to load the target DLL module. During the loading process, it monitors whether the UWP process loader imposes additional sandbox restrictions on the DLL module. If so, it attempts to circumvent the restrictions by adjusting the DLL loading parameters. After loading is complete, it obtains the base address of the DLL module and verifies its validity. After getting the address of the InjectInit function through LdrGetProcedureAddress, first verify whether the address is within the memory address range of the loaded DLL module, and then call the function to perform initialization; After initialization, ShellCode triggers a simulated file outbound API call to verify whether the injected DLL module can successfully intercept the call. If the interception is successful, the memory resources occupied by ShellCode are released. If it fails, the interception failure information is fed back to the service module and waits for further instructions.

[0011] It should be further explained that step S106 specifically includes: After the injected DLL module intercepts the API calls related to file outbound transmission, it collects the context information of the file outbound transmission and verifies the integrity of this information in the UWP sandbox environment; When the DLL module establishes a connection with the named pipe instance of the service module, it encrypts the transmitted file information using a preset lightweight encryption algorithm and verifies the legitimacy of the pipe connection. After receiving the encrypted file information, the service module first decrypts and parses the context information sent out by the file, and then performs hierarchical judgment through the content recognition submodule; If the service module determines that there is a risk of leakage, it will feedback an encrypted outbound rejection instruction to the DLL module; after the DLL module decrypts the instruction and verifies its legitimacy, it records the detailed information of the outbound operation and stores it in the security log area of ​​the UWP process, and at the same time prevents the file from being sent again through other outbound APIs within a preset time.

[0012] This application also provides a UWP application outbound control function compatibility adaptation system, which includes: The service module is used to create a named pipe instance and grant all UWP programs access to the named pipe instance by modifying the access control list of the security descriptor; The driver module is used to send a process start notification to the service module when detecting the loading event of the process main module; The service module is used to determine whether the newly started process is a UWP process. If not, it waits for the next process start notification. If it is, it executes the code injection module; The code injection module is used to insert an APC containing ShellCode into the main thread of the UWP process through an asynchronous procedure call. The ShellCode contains function instructions for loading the target DLL module and performing initialization. The target DLL module is used to intercept APIs related to file outbound transmission. The outgoing notification module is used when the user is ready to send files out. The DLL module injected into the UWP process connects to the named pipe instance created by the service module and informs the service module of the files to be sent out. The service module is used to determine whether there is a risk of leakage in the file content. If so, it will give a feedback of refusing to send it out. If the injected DLL module receives the feedback, the corresponding API call will fail.

[0013] According to another embodiment of the present application, an electronic device is provided, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor implements the steps of the UWP application outbound control function compatibility adaptation method when executing the program.

[0014] According to another embodiment of the present application, a storage medium is also provided, on which a computer program is stored. When the computer program is executed by a processor, the steps of the UWP application outbound control function compatibility adaptation method are implemented.

[0015] It can be seen from the above technical solutions that the present invention has the following advantages: The compatibility adaptation method for the outbound control function of UWP applications provided by the present invention grants all UWP applications the permission to access the named pipe instance by configuring the security descriptor, thereby ensuring that a stable communication connection can be established between the injected DLL module and the service module. The driver module monitors the loading event of the main module of the process and sends a notification, so that the service module can be aware of the process startup status in a timely manner, which buys time for the subsequent processing of the UWP process. The service module judges the process type to avoid unnecessary operations on non-UWP processes, improves processing efficiency, and reduces resource waste. The APC item containing ShellCode is inserted through the asynchronous procedure call mechanism to prepare for the injection of relevant code into the UWP process. The main thread of the UWP process executes the APC item to complete the loading and initialization of the DLL module, and successfully injects the module for intercepting the file outbound API into the UWP process, thereby preparing for monitoring the file outbound operation. The DLL module intercepts the file outbound API call and interacts with the service module. The service module judges the risk and feedbacks instructions, which can effectively prevent the outbound transmission of files with leakage risks and ensure information security. It ensures the smooth running of the entire process from process monitoring, code injection to file outbound interception and risk assessment, which not only ensures that the normal functions of UWP applications are not excessively interfered with, but also prevents leaks in a timely manner. BRIEF DESCRIPTION OF THE DRAWINGS

[0016] In order to more clearly illustrate the technical solution of the present invention, the following is a brief introduction to the drawings required for the description. Obviously, the drawings described below are only some embodiments of the present invention. For ordinary technicians in this field, other drawings can be obtained based on these drawings without paying any creative work.

[0017] Figure 1 Flowchart of the compatibility adaptation method for outbound control functions of UWP applications; Figure 2 A flowchart of an implementation method for adapting the compatibility of outbound control functions for UWP applications; Figure 3 A flowchart of another embodiment of a method for adapting the compatibility of outbound control functions of UWP applications; Figure 4 A flowchart of another embodiment of a method for adapting the compatibility of outbound control functions for UWP applications; Figure 5 Schematic diagram of an electronic device. DETAILED DESCRIPTION

[0018] In this application, UWP applications will be able to load DLL modules containing intercepted API codes, just like traditional Win32 desktop applications, and establish a communication mechanism with the service module from within it. At this time, when the user selects a file to be sent out through the UWP program, the service module will be aware of this action and determine whether to allow the outbound transmission through the content identification sub-module.

[0019] The following describes in detail the compatibility adaptation method for the outbound control function of the UWP application involved in this application. For the purpose of illustration rather than limitation, specific details such as specific system structures and technologies are proposed to facilitate a thorough understanding of the embodiments of this application. However, it should be clear to those skilled in the art that this application can also be implemented in other embodiments without these specific details.

[0020] It should be understood that when used in this specification, the term "include" indicates the presence of the described features, integers, steps, operations, elements and / or components, but does not exclude the presence or addition of one or more other features, integers, steps, operations, elements, components and / or their combinations. The terms "include", "comprises", "has" and their variations are meant to include but not limited to, unless otherwise specifically emphasized.

[0021] The phrase "one embodiment or some embodiments" in this application means that the specific features, structures or characteristics described in the embodiment are included in one or more embodiments of the application. Therefore, the phrases "in one embodiment", "in some embodiments", "in other embodiments", "in other embodiments" and so on in this application do not necessarily refer to the same embodiment, but mean one or more but not all embodiments, unless otherwise specifically emphasized.

[0022] In embodiments of the present invention, computer program code for performing the operations of the present disclosure may be written in one or more programming languages, or a combination thereof, including, but not limited to, object-oriented programming languages ​​such as Java, Smalltalk, C++, and conventional procedural programming languages ​​such as C or similar programming languages. The program code may be executed entirely on the user's computer, partially on the user's computer, as a stand-alone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In cases involving a remote computer, the remote computer may be connected to the user's computer via any type of network, including a local area network (LAN) or a wide area network (WAN), or may be connected to an external computer (exemplarily, via the Internet using an Internet service provider).

[0023] The following will clearly and completely describe the technical solutions in the embodiments of the present invention in conjunction with the accompanying drawings. Obviously, the described embodiments are only part of the embodiments of the present invention, not all of the embodiments. Based on the embodiments of the present invention, all other embodiments obtained by ordinary technicians in this field without making creative efforts are within the scope of protection of the present invention.

[0024] See also Figure 1 and Figure 2 The figure is a flowchart of a method for adapting the compatibility of an outbound control function of a UWP application in a specific embodiment, the method including: Step S101: The service module creates a named pipe instance and grants all UWP programs access to the named pipe instance by modifying the access control list of the security descriptor.

[0025] In some embodiments, as Figure 3 As shown, step S101 specifically includes the following methods: Step S2011: The service module constructs the security identifier SID of the ALLAPPLICATIONPACKAGES group through a system function; Step S2012: the service module fills the EXPLICIT_ACCESS structure with the security identifier and the preset access mask to generate a legal access control entry ACE; Step S2013: the service module inserts the access control item into an empty custom access control list DACL through a system function; Step S2014: the service module initializes the security descriptor SD; Step S2015: The service module sets the custom access control list as the DACL of the security descriptor; Step S2016: the service module creates a named pipe instance and binds the security descriptor to the named pipe instance during the creation process; Step S2017: The service module releases the memory resources occupied by the security identifier, access control item, custom access control list and security descriptor.

[0026] It should be noted that the service module constructs the security identifier SID of the ALLAPPLICATIONPACKAGES group through system functions, and verifies the format and validity of the SID to ensure that it complies with the Windows system's specifications for the UWP application association group SID; uses the security identifier and the preset access mask to fill the EXPLICIT_ACCESS structure to generate a legal access control item ACE; the access mask is set according to the actual communication requirements of the UWP application for the named pipe, and only includes read, write, and connect permissions. The service module inserts the access control item into the empty custom access control list DACL through the system function, and checks whether there are other implicit access control items in the DACL that conflict with the ACE. If so, compatibility adjustments are made; the service module initializes the security descriptor SD and sets the version number of SD to adapt to the current Windows system version to ensure that SD can be correctly identified by the system security subsystem; the service module sets the custom access control list as the DACL of the security descriptor and verifies whether the binding of DACL and SD is successful; the service module creates a named pipe instance and binds the security descriptor to the named pipe instance during the creation process; after the creation is completed, the permission configuration of the named pipe is tested to see if it is effective by simulating the access request of the UWP application; the service module releases the memory resources occupied by the security identifier, access control item, custom access control list and security descriptor, and records the resource release status to ensure there is no memory leak.

[0027] It can be seen that in the Windows system, resource access is controlled by security descriptors, and the UWP process runs in the AppContainer sandbox, and its access token is associated with the ALLAPPLICATIONPACKAGES group SID by default. By default, the externally created named pipe SD does not contain the access rights of the SID, resulting in UWP being unable to access it. This step actively adds the permission item of the group SID to the DACL of SD, so that the Windows security subsystem matches the legal permissions when UWP tries to connect to the pipe, thereby allowing communication. The permission control of this embodiment avoids the security risks caused by excessively open permissions, and is compatible with the Windows security mechanism to ensure that the configuration is recognized by the system and has high stability.

[0028] Step S102: When the driver module detects a process main module loading event, it sends a process start notification to the service module.

[0029] In some embodiments, the driver module registers a kernel callback function to trigger an event when the process's main module loads. Monitoring includes the process ID, parent process ID, main module path, and process creation time. The driver encapsulates this information into a structure using custom IO control codes and sends it to the user-mode service module. This connection is established using CreateFile on the device handle, ensuring that notification latency remains below a threshold.

[0030] As can be seen, the driver runs at the kernel level and can directly monitor low-level events created by processes, regardless of the permissions of user-mode processes. When a UWP process starts, the loading of its main module is a key step. After the driver captures this event, it transmits the information to the service module in real time through the kernel-user-mode communication mechanism, providing raw data for subsequent UWP process identification.

[0031] This embodiment enables real-time monitoring of process startups, ensuring that UWP processes are managed as soon as they start, preventing the omission of processes that are already running but not monitored. Kernel-level monitoring is not affected by the UWP sandbox and can obtain complete process information, resolving the issue of incomplete user-level monitoring information.

[0032] Step S103: The service module determines whether the newly started process is a UWP process. If not, it waits for the next process start notification. If so, it executes step S104.

[0033] After receiving the process information, the service module of this embodiment performs three-level judgment: ① Call the GetPackageFullName function to obtain the application package name of the process. If the return is successful and the package name format is publisher, application name, version, architecture and signature, it is initially determined to be UWP; ② If the package name acquisition fails, check the process access token. If the token contains the APP_CONTAINER_INFORMATION structure and the AppContainerSID in the preset format, it is auxiliary determined to be UWP; ③Finally, check whether the main module path is located in the UWP default installation path and whether the path contains the verified package name folder.

[0034] If all three layers are not met, it is judged as non-UWP.

[0035] It's important to note that UWP processes are subject to the AppContainer sandbox based on the application package model and therefore must possess three core characteristics: a unique application package name, a sandbox identifier containing the AppContainerSID, and a fixed protected installation directory. The service module accurately identifies UWP processes by verifying the existence and compliance of these characteristics.

[0036] Step S104: inserting an APC item containing ShellCode into the main thread of the UWP process through an asynchronous procedure call; the ShellCode includes function instructions for loading a target DLL module and performing initialization, and the target DLL module is used to intercept APIs related to file outbound transmission.

[0037] In some embodiments, the service module first constructs ShellCode, which specifically includes calling LdrLoadDll, obtaining the address of InjectInit through LdrGetProcedureAddress, calling the instructions of InjectInit, and parameters such as the DLL path string and function name.

[0038] Using VirtualAllocEx, the program requests memory with PAGE_EXECUTE_READWRITE permissions in the UWP process. Then, it calls WriteProcessMemory to write the shellcode and verify that the hash of the written data matches the original hash. When constructing the APC item, the callback function pointer points to the shellcode's starting address, and the appended data is the package name hash of the UWP process. After calling QueueUserAPC to insert the APC, it monitors the main thread's status using WaitForSingleObject. If the main thread doesn't enter the waiting state within 5 seconds, a reminder is issued, triggering a custom event to cause the thread to switch state.

[0039] The APC mechanism in this embodiment allows a process to insert a pending function into the target thread. When the target thread calls a reminder-waiting function, the APC function takes precedence. The UWP main thread frequently enters a reminder-waiting state during operation. The service module exploits this feature to inject the DLL load instruction through APC, causing the UWP thread to actively execute Shellcode, thereby completing the DLL loading within the sandbox and overcoming UWP's restrictions on external injection.

[0040] This embodiment uses the UWP thread's own execution mechanism to implement injection, preventing it from being identified as malicious by UWP security protection. The memory allocation and ShellCode writing verification mechanism ensures that the injected content has not been tampered with, providing high security.

[0041] Step S105: When the user is ready to send a file, the DLL module injected into the UWP process connects to the named pipe instance created by the service module and informs the service module of the file to be sent.

[0042] In this embodiment, when the UWP main thread executes the APC, ShellCode first calls LdrLoadDll to load the target DLL. If STATUS_SUCCESS is returned, the address of the InjectInit function is obtained through LdrGetProcedureAddress. When InjectInit is called, the function is executed as follows: ① Parse the import table of the file outbound API in the UWP process; ② Redirect the API call to the interception function in the DLL by modifying the first 5 bytes of the function entry to a jump instruction; ③Generate an API interception mapping table to record the original function address and interception function address.

[0043] After initialization, the shellcode calls VirtualFree to free its own memory, triggering a simulated file outbound operation to verify whether the interception function captures the call. If successful, it returns STATUS_SUCCESS; otherwise, it sends an error code to the service module.

[0044] In this embodiment, after the UWP main thread executes the shellcode in the APC, the DLL is loaded into the process address space, becoming part of the UWP process and inheriting its permissions and memory environment. The InjectInit function modifies the API call path so that file outbound operations pass through the DLL's interception function, enabling real-time monitoring of operations and providing an entry point for subsequent control.

[0045] In this embodiment, the DLL runs within the UWP process and can directly access the API and file information within the process, solving the problem of limited cross-process access. The verification mechanism of API interception ensures that the function is effective and avoids the hidden danger of successful injection but failed interception.

[0046] Step S106: The service module determines whether the file content has a risk of leakage, and if so, gives a feedback of rejecting the outbound transmission. If the injected DLL module receives this feedback, the corresponding API call fails.

[0047] In some embodiments, when the DLL intercepts the API, it extracts the file path, outbound method, file size, and content summary. When sending through a named pipe, it encrypts the digital signature of the attached DLL using AES-128.

[0048] After the service module of this embodiment decrypts, the content identification submodule first compares the sensitive file hash library, then uses regular expressions to match sensitive information, and adjusts the threshold in combination with user permissions.

[0049] Optionally, ordinary users match 1 sensitive word and administrators match 3.

[0050] If a risk is determined, the service module generates an encrypted rejection instruction. After decryption, the DLL calls SetLastError to set the error code, causing the API to return failure. At the same time, the operation record is written to %LocalAppData%\Microsoft\Windows\Security\Logs, and the file is blocked from being sent through other APIs such as WriteFile and SaveToStorage within a preset time period.

[0051] It can be seen that the injected DLL acts as a middleman for file outbound operations. After intercepting the API call, it passes key information to the service module. The service module determines the risk through content identification and then feeds back instructions through the pipeline. The DLL controls the API execution results according to the instructions, forming a closed loop of interception, judgment and execution. It uses the collaboration between UWP and the service module to break through the sandbox restrictions and achieve secure control of file outbound transmission.

[0052] This embodiment combines multi-dimensional content recognition with user permissions to reduce misjudgments and improve control accuracy. Encrypted communication and signature verification prevent information theft or tampering, complying with data security standards. The interception mechanism prevents users from circumventing control through other APIs, ensuring consistent control effectiveness.

[0053] In one embodiment of the present invention, based on step S101, a possible embodiment is given below to illustrate its specific implementation scheme in a non-limiting manner. Step S101 specifically includes: Step S1011: Obtain the fixed RID value corresponding to the ALLAPPLICATIONPACKAGES group through the security identifier generation tool provided by the operating system or the predefined system constants, and generate a complete SID string in combination with the domain or local computer identifier to ensure its uniqueness and system identification validity.

[0054] Step S1012: Set the access mask of the ACE according to the access requirements of the target resource.

[0055] Optionally, allow read, write, and connect permissions; configure the ACE flags to ensure that the ACE explicitly grants the ALLAPPLICATIONPACKAGES group specific access rights to the named pipe instance.

[0056] Step S1013: After initializing the empty DACL through the security descriptor operation function provided by the operating system, ACEs are sequentially added to the specified positions of the DACL to form a DACL structure containing target permission rules, thereby ensuring the validity and integrity of the DACL.

[0057] Step S1014: Bind the DACL containing ACE to the security descriptor SD of the named pipe instance; by initializing the infrastructure of the security descriptor SD, set the DACL generated in step S1013 as the primary DACL of SD, and verify the validity of the binding between SD and the named pipe instance to ensure that the named pipe instance can control the access rights of the UWP application based on the SD after creation.

[0058] It can be seen that due to system security policy restrictions, UWP applications can only access resource objects created by themselves by default. Resources created by other processes or system components are denied access to UWP applications by default.

[0059] This step uses the operating system's predefined ALLAPPLICATIONPACKAGES group SID to generate an access control entry containing that SID, explicitly granting it the target access rights to the named pipe instance. This ACE is then inserted into an empty custom access control list, forming a new security descriptor (SD). Finally, this SD is bound to the named pipe instance.

[0060] When a UWP application tries to access the named pipe, the Windows security subsystem checks whether the SID in its access token matches the permission rule of the DACL in SD. Since the ALLAPPLICATIONPACKAGES group SID is included in the access token of the UWP application and SD explicitly grants access rights to this group, the UWP application can successfully access the named pipe instance, solving the problem in traditional solutions where UWP applications cannot access resources that they did not create themselves.

[0061] In one embodiment of the present invention, based on step S1013, a possible embodiment is given below to illustrate its specific implementation scheme in a non-limiting manner. Step S1013 specifically includes: Step S10131: Perform an initial status check on the empty custom access control list DACL to confirm that it has no hidden default access control items, the structure is not damaged and complies with the system security descriptor specification. If there is an implicit invalid structure, repair it.

[0062] Step S10132: Determine the position of the ACE to be inserted in the DACL according to the preset security priority rule to prevent the permission from being overwritten by subsequent ACEs due to incorrect position.

[0063] Optionally, the security priority rule may be that denying permissions takes precedence over allowing permissions, and specific users / groups take precedence over universal groups.

[0064] Step S10133: After inserting the generated ACE into the specified position of the DACL, check whether there are other ACEs in the DACL with the same security identifier SID as the ACE. If so, compare the access mask to determine whether the same SID is granted both allow and deny permissions, and adjust the access mask or position of the ACE according to the conflict type.

[0065] Step S10134: Perform integrity verification on the DACL after inserting ACEs, including checking whether the number of ACEs is consistent with the DACL header record, whether the structure of each ACE is complete, and whether the matching of the access mask and SID complies with the system security policy, to ensure that the DACL can be correctly parsed by the Windows security subsystem.

[0066] It should be noted that the custom access control list (DACL) is a control structure for resource access permissions. It defines how a SID can access resources through the access control items (ACEs) it contains.

[0067] Step S1013 is to reasonably embed the ACE that grants access rights to the UWP application into the empty DACL, so that the DACL can accurately identify the ALLAPPLICATIONPACKAGES group SID and follow the system security priority rules to avoid permission conflicts or invalid configurations, and ultimately ensure that the access request of the UWP application is correctly allowed by the system security mechanism.

[0068] This embodiment is different from the operation of inserting ACE into an empty DACL in the prior art. This step verifies the empty DACL, eliminates the residual default ACE fragments, and solves the potential problem that the empty DACL may not be truly empty. The ACE insertion position is dynamically located based on security priority. For example, if other deny permission ACEs may be added later, the current allow permission ACE must be placed in a reasonable position to prevent it from being overwritten. Adjustments are made to allow and deny writes for the same SID at the same time to avoid confusion in permission logic and ensure that the DACL can be correctly parsed by the system, granting UWP access rights without destroying the basic security boundary of the resource.

[0069] In one embodiment of the present invention, based on step S103, a possible embodiment is given below to illustrate its specific implementation scheme in a non-limiting manner. Step S103 specifically includes: Step S1031: Obtain the basic information of the target process in the process start notification, obtain the process identifier PID of the target process through the OpenProcess function provided by the operating system, and further obtain its process token handle for subsequent identity feature extraction.

[0070] Step S1032: Call the GetTokenInformation function to extract the security identifier SID in the process token, focus on checking whether there is the ALLAPPLICATIONPACKAGES group SID or AppContainer type SID of the UWP application, and record the integrity level of the token.

[0071] Step S1033: Enumerate the module list loaded by the target process through the EnumProcessModules function to check whether it contains the module features of the UWP application runtime.

[0072] Module features include: Windows.UI.Xaml.dll, CoreCLR.dll, etc., to confirm whether the module features comply with the UWP application sandbox directory specifications.

[0073] Step S1034: Perform a logical AND operation on the SID feature extracted in step S1032 and the module feature verified in step S1033. If both meet the feature requirements of the UWP application, it is determined to be the target UWP process; otherwise, it is determined to be a non-UWP process and returns to step S102 to continue monitoring.

[0074] It should be noted that this step uses multi-dimensional feature cross-verification to identify UWP processes, parses SIDs through process tokens, and filters out processes with UWP-exclusive identifiers. Secondly, module list verification ensures that the process is loaded with UWP to avoid misjudging it as an ordinary process with a malicious forged SID. The combination of the two forms a dual verification mechanism for identity and behavior, which not only utilizes the security design features of the UWP system, but also eliminates potential deception through module loading features, thereby improving the accuracy of process type judgment.

[0075] This embodiment also obtains the process handle through the OpenProcess function, and then calls the OpenProcessToken function to obtain the process access token handle, which stores the process's identity information and permission policy. The SID feature verification method is based on the fact that the process token of the UWP application must contain two types of key SIDs: one is the ALLAPPLICATIONPACKAGES group SID, which is used to grant the UWP application permission to access external resources; the other is the AppContainerSID, which is used to identify that the process is running in a sandbox environment. The TokenGroups structure is obtained through the GetTokenInformation function, and verification can be performed by traversing the SID list therein.

[0076] In one embodiment of the present invention, based on step S104, a possible embodiment will be given below to illustrate its specific implementation scheme in a non-limiting manner. Figure 4 As shown, step S104 specifically includes: Step S1041: The service module constructs ShellCode, which includes function instructions for loading the target DLL module and executing initialization, as well as parameters required by the function instructions; Step S1042: The service module writes the ShellCode into the address space of the UWP process through a memory operation function; Step S1043: The service module inserts an APC item into the main thread of the UWP process through an asynchronous procedure call function, and the callback function pointer of the APC item points to the starting address of the ShellCode; Step S1044: The main thread of the UWP process enters a waiting state, checks its APC queue and executes the callback function in the APC item; Step S1045: the callback function loads the target DLL module through the system loading function, and obtains the initialization function address of the DLL module by obtaining the export function address; Step S1046: the callback function calls the initialization function to initialize the DLL module, and the initialization includes intercepting the file outgoing API function.

[0077] It should be noted that ShellCode refers to a piece of binary code and data, including the complete disassembly code of a special function and all the parameters required by this special function. The working content of the special function is as follows: Load the DLL module that needs to be injected through LdrLoadDll; Get the address of the exported function InjectInit of the injected DLL through LdrGetProcedureAddress; Calling InjectInit to initialize the injected DLL is mainly to intercept the file's outgoing API functions.

[0078] Asynchronous Procedure Calls (APC) is an asynchronous I / O mechanism provided by the operating system. Each thread maintains an APC queue. When a thread enters a wait state where it can be notified, the operating system checks whether there is an APC entry in the APC queue. If so, it removes the entry and executes the bound callback function, which is a special function contained in the shellcode.

[0079] The service module of this embodiment first pre-writes all the instructions and necessary parameters for loading the DLL in a self-contained shellcode.Then the service module uses the cross-process memory write function to directly put the shellcode into the private address space of the target UWP process.

[0080] The service module calls the system's asynchronous procedure call function and inserts an APC entry pointing to this shellcode into the APC queue of the UWP process's main thread. When the UWP process's main thread next enters a wait state where it can be notified, the kernel automatically retrieves the APC entry and transfers execution to the shellcode. The shellcode first calls the system's loader function to load the target DLL into memory. It then uses the mechanism for obtaining the address of the exported function to locate the initialization function within the DLL and immediately call it. The initialization function completes the interception of the API related to file outbound calls. Afterward, the shellcode terminates and returns control to the UWP main thread, allowing the UWP process to continue executing normally.

[0081] Step S104 does not require the creation of remote threads or access to dangerous APIs prohibited by the UWP sandbox. DLL injection is achieved solely through the system's legitimate asynchronous procedure calls and memory write mechanisms, penetrating UWP isolation restrictions. Shellcode is small in size and has a short execution path, minimizing impact on the existing logic of the UWP process. A one-time execution marker and integrity check ensure that the injection behavior is unique and non-repeatable, avoiding the stability risks associated with multiple hooks.

[0082] In one embodiment of the present invention, based on step S105, a possible embodiment is given below to illustrate its specific implementation scheme in a non-limiting manner. Step S105 specifically includes: Step S1051: When the main thread of the UWP process executes the APC item, it first checks the accessibility of the target DLL module path in the UWP process environment through the pre-verification function in the ShellCode, and whether the digital signature of the DLL file meets the trust level of the UWP application. If not, the loading process is terminated and the reason for the verification failure is recorded.

[0083] Step S1052: ShellCode calls LdrLoadDll to load the target DLL module. During the loading process, it monitors whether the loader of the UWP process imposes additional sandbox restrictions on the DLL module. If there are restrictions, it attempts to circumvent them by adjusting the loading parameters of the DLL. After the loading is complete, it obtains the base address of the DLL module and verifies its validity.

[0084] Step S1053: After obtaining the address of the InjectInit function through LdrGetProcedureAddress, first verify whether the address is within the memory address range of the loaded DLL module, and then call the function to perform initialization. During the initialization process, if it is detected that the memory address of the file outbound API does not match the preset characteristics, the interception logic is adaptively adjusted.

[0085] Step S1054: After initialization is completed, ShellCode triggers a simulated file outbound API call to verify whether the injected DLL module can successfully intercept the call. If the interception is successful, the memory resources occupied by ShellCode are released. If it fails, the interception failure information is fed back to the service module and waits for further instructions.

[0086] It can be seen that when the main thread of the UWP process of this embodiment executes the ShellCode in the APC queue, the process's own loader and memory environment are used to complete the loading of the target DLL, so that the DLL module is integrated into the address space of the UWP process. By calling the initialization function of the DLL, the API interception logic is triggered, and the calling path of the file outbound related API is redirected to the interception function in the DLL, thereby realizing real-time monitoring of the file outbound operation. This process relies on the trust mechanism of the UWP process for its own loaded module, so that the DLL can participate in the function call flow of the process with a legal identity. Avoid loading failures due to UWP sandbox restrictions. Add API address dynamic adaptation logic in the initialization phase to solve the compatibility problem of API address offsets under different system versions. After loading is completed, the ShellCode memory is released to reduce the detection risk of the UWP security mechanism, and improve the stability and environmental adaptability of the function after DLL injection.

[0087] In one embodiment of the present invention, based on step S106, a possible embodiment is given below to illustrate its specific implementation scheme in a non-limiting manner. Step S106 specifically includes: Step S1061: After the injected DLL module intercepts the API call related to file outbound transmission, it collects the context information of the file outbound transmission and verifies the integrity of this information in the UWP sandbox environment. If the information is incomplete, it supplements it or marks the missing items.

[0088] Step S1062: When the DLL module establishes a connection with the named pipe instance of the service module, the transmitted file information is encrypted using a preset lightweight encryption algorithm, and at the same time, it is verified whether the other end of the pipe connection is a legitimate service module to prevent a third-party process from impersonating the service module to steal information.

[0089] Step S1063: After receiving the encrypted file information, the service module first decrypts and analyzes the context information sent out by the file, and then performs hierarchical judgment through the content identification submodule.

[0090] Specifically, the file type and size are quickly screened, and then the file content is matched with sensitive keywords and structured data. At the same time, the judgment threshold is adjusted based on the user permission level of the user initiating the outbound operation.

[0091] Step S1064: If the service module determines there is a risk of data leakage, it sends an encrypted outbound rejection instruction to the DLL module. After decrypting the instruction and verifying its legitimacy, the DLL module not only returns a failure for the corresponding API call, but also records the details of the outbound operation and stores them in the security log area of ​​the UWP process. Furthermore, it prevents the file from being re-transmitted through other outbound APIs within a preset time.

[0092] In this embodiment, the DLL module injected into the UWP process intercepts the file outbound API and becomes an intermediate node for file outbound operations. It collects operation details and passes them to the service module via a named pipe, while also receiving the service module's risk assessment results. The service module determines whether to allow outbound transmission based on content recognition, and the DLL module ultimately executes the instructions to allow or deny. By leveraging the collaboration between the UWP process and the service module, the module overcomes the external control restrictions of the UWP sandbox and achieves precise control over file outbound transmission.

[0093] It should be understood that the size of the serial numbers of the steps in the above embodiments does not mean the order of execution. The execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of the present invention.

[0094] The following is an embodiment of the UWP application outbound control function compatibility adaptation system provided by the embodiments of the present disclosure. This system and the UWP application outbound control function compatibility adaptation method of the above-mentioned embodiments belong to the same inventive concept. For details not fully described in the embodiments of the UWP application outbound control function compatibility adaptation system, please refer to the embodiments of the above-mentioned UWP application outbound control function compatibility adaptation method.

[0095] The system includes: The service module is used to create a named pipe instance and grant all UWP programs access to the named pipe instance by modifying the access control list of the security descriptor; The driver module is used to send a process start notification to the service module when detecting the loading event of the process main module; The service module is used to determine whether the newly started process is a UWP process. If not, it waits for the next process start notification. If it is, it executes the code injection module; A code injection module, used to insert an APC item containing ShellCode into the main thread of the UWP process through an asynchronous procedure call; the ShellCode includes function instructions for loading a target DLL module and performing initialization; the target DLL module is used to intercept APIs related to file outbound transmission; The outgoing notification module is used when the user is ready to send files out. The DLL module injected into the UWP process connects to the named pipe instance created by the service module and informs the service module of the files to be sent out. The service module is used to determine whether there is a risk of leakage in the file content. If so, it will give a feedback of refusing to send it out. If the injected DLL module receives this feedback, the corresponding API call will fail.

[0096] like Figure 5 As shown, the present application also provides an electronic device, including a display module 103, a memory 102, a processor 101, and a computer program stored in the memory and executable on the processor 101, wherein the processor 101 implements the steps of the UWP application outbound control function compatibility adaptation method when executing the program.

[0097] In the embodiments of the present invention, electronic devices include, but are not limited to, laptop computers, desktop computers, workstations, personal digital assistants, servers, blade servers, mainframe computers, and other suitable computers. Electronic devices may also represent various forms of mobile devices, such as personal digital assistants, cellular phones, smart phones, wearable devices, and other similar computing devices. The components shown herein, their connections and relationships, and their functions are merely examples and are not intended to limit the implementation of the embodiments of the present application described and / or claimed herein.

[0098] In the embodiment of the present application, the processor 101 can be implemented by using at least one of a special purpose integrated circuit, a programmable logic device, a field programmable gate array, a processor, a controller, a microcontroller, a microprocessor, and an electronic unit designed to perform the functions described herein. In some cases, such an embodiment can be implemented in a controller. For software implementation, an embodiment such as a process or function can be implemented with a separate software module that allows the execution of at least one function or operation. The software code can be implemented by a software application (or program) written in any appropriate programming language, and the software code can be stored in a memory and executed by a controller.

[0099] The display module 103 is used to display information input by the user or information provided to the user. The display module 103 may include a display panel, which may be configured in the form of a liquid crystal display, an organic light emitting diode, etc.

[0100] The memory 102 can be used to store software programs and various data. The memory 102 can include high-speed random access memory and non-volatile memory, such as at least one disk storage device, flash memory device, or other volatile solid-state storage device.

[0101] The present application also provides a storage medium on which a computer program is stored. When the computer program is executed by a processor, the steps of the UWP application outbound control function compatibility adaptation method are implemented.

[0102] The storage medium can be any combination of one or more readable media. The readable medium can be a readable signal medium or a readable storage medium. The readable storage medium can be, for example, but not limited to, an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, device or component, or any combination thereof. More specific examples (non-exhaustive list) of readable storage media include: an electrical connection with one or more wires, a portable disk, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory), an optical fiber, a portable compact disk read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination thereof.

[0103] In the context of storage media, a readable signal medium may include a data signal propagated in baseband or as part of a carrier wave, which carries readable program code. This propagated data signal may take a variety of forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination thereof. A readable signal medium may also be any readable medium other than a readable storage medium that can transmit, propagate, or transfer a program for use by or in conjunction with an instruction execution system, apparatus, or device.

[0104] The above description of the disclosed embodiments is intended to enable one skilled in the art to implement or use the present invention. Various modifications to these embodiments will be readily apparent to one skilled in the art, and the general principles defined herein may be implemented in other embodiments without departing from the spirit or scope of the present invention. Therefore, the present invention is not limited to the embodiments shown herein but is intended to conform to the widest scope consistent with the principles and novel features disclosed herein.

Claims

1. A compatibility adaptation method for outbound control functions of UWP applications, characterized in that: Methods include: S101: The service module creates a named pipe instance and grants all UWP programs access to the named pipe instance by modifying the access control list of the security descriptor; S102: When the driver module detects a process main module loading event, it sends a process start notification to the service module; S103: The service module determines whether the newly started process is a UWP process. If not, it waits for the next process start notification. If so, it executes step S104; S104: inserting an APC item containing ShellCode into the main thread of the UWP process through an asynchronous procedure call; the ShellCode includes function instructions for loading a target DLL module and performing initialization; the target DLL module is used to intercept APIs related to file outbound transmission; S105: When the user is ready to send a file, the DLL module injected into the UWP process connects to the named pipe instance created by the service module and informs the service module of the file to be sent. S106: The service module determines whether there is a risk of leakage of the file content. If so, it gives a feedback of refusing to send it out. If the injected DLL module receives the feedback, the corresponding API call fails.

2. The compatibility adaptation method for outbound control functions of UWP applications according to claim 1 is characterized in that: Step S101 specifically includes: The service module constructs the security identifier SID of the ALLAPPLICATIONPACKAGES group through the system function; Fill the EXPLICIT_ACCESS structure with the security identifier and the preset access mask to generate a valid access control entry; Insert access control items into an empty custom access control list through system functions; Initialize the security descriptor; Set the custom access control list as the DACL of the security descriptor; Create a named pipe instance and bind the security descriptor to the named pipe instance during the creation process; Releases the memory resources used by security identifiers, access control entries, custom access control lists, and security descriptors.

3. The compatibility adaptation method for outbound control functions of UWP applications according to claim 2 is characterized in that: Step S101 also includes: Use the security identifier generation tool provided by the operating system or predefined system constants to obtain the fixed RID value corresponding to the ALLAPPLICATIONPACKAGES group, and combine it with the domain or local computer identifier to generate a complete SID string; According to the access requirements of the target resource, set the access mask of the ACE and configure the flag of the ACE to ensure that the ACE can explicitly grant the ALLAPPLICATIONPACKAGES group specific access rights to the named pipe instance; After initializing the empty DACL through the security descriptor operation function provided by the operating system, ACEs are added to the specified positions of the DACL in sequence to form a DACL structure that contains the target permission rules; Bind the DACL containing ACE to the security descriptor SD of the named pipe instance; initialize the infrastructure of the security descriptor SD, set the generated DACL as the primary DACL of SD, and verify the validity of the binding between SD and the named pipe instance.

4. The compatibility adaptation method for outbound control functions of UWP applications according to claim 1, characterized in that: Step S103 specifically includes: Perform initial status check on the empty custom access control list (DACL) to confirm that the default access control items and structures are not damaged and comply with the system security descriptor specification. If there is any implicit invalid structure, repair it. Determine the position of the ACE to be inserted in the DACL based on the preset security priority rules; After inserting the generated ACE into the specified position of the DACL, check whether there is another ACE in the DACL with the same security identifier SID as the ACE. If so, compare the access mask to determine whether the same SID is granted both allow and deny permissions. Adjust the access mask or position of the ACE based on the conflict type. Verify the integrity of the DACL after inserting the ACE.

5. The compatibility adaptation method for outbound control functions of UWP applications according to claim 1, characterized in that: Step S104 specifically includes: The service module constructs ShellCode, which includes function instructions for loading the target DLL module and performing initialization, as well as parameters required by the function instructions; The service module writes the ShellCode into the address space of the UWP process through a memory operation function; The service module inserts an APC item into the main thread of the UWP process through an asynchronous procedure call function, and the callback function pointer of the APC item points to the starting address of the ShellCode; The main thread of the UWP process enters a waiting state, checks its APC queue and executes the callback function in the APC item; The callback function loads the target DLL module through the system loading function, and obtains the initialization function address of the DLL module by obtaining the export function address; The callback function calls the initialization function to initialize the DLL module. The initialization includes intercepting the file's outgoing API function.

6. The compatibility adaptation method for outbound control functions of UWP applications according to claim 1, characterized in that: Step S105 specifically includes: When the main thread of the UWP process executes the APC item, the pre-verification function in the ShellCode is used to check the accessibility of the target DLL module path in the UWP process environment, and whether the digital signature of the DLL file meets the trust level of the UWP application. If not, the loading process is terminated and the reason for the verification failure is recorded; ShellCode calls LdrLoadDll to load the target DLL module. During the loading process, it monitors whether the UWP process loader imposes additional sandbox restrictions on the DLL module. If so, it attempts to circumvent the restrictions by adjusting the DLL loading parameters. After loading is complete, it obtains the base address of the DLL module and verifies its validity. After getting the address of the InjectInit function through LdrGetProcedureAddress, first verify whether the address is within the memory address range of the loaded DLL module, and then call the function to perform initialization; After initialization, ShellCode triggers a simulated file outbound API call to verify whether the injected DLL module can successfully intercept the call. If the interception is successful, the memory resources occupied by ShellCode are released. If it fails, the interception failure information is fed back to the service module and waits for further instructions.

7. The compatibility adaptation method for outbound control functions of UWP applications according to claim 1, characterized in that: Step S106 specifically includes: After the injected DLL module intercepts the API calls related to file outbound transmission, it collects the context information of the file outbound transmission and verifies the integrity of this information in the UWP sandbox environment; When the DLL module establishes a connection with the named pipe instance of the service module, it encrypts the transmitted file information using a preset lightweight encryption algorithm and verifies the legitimacy of the pipe connection. After receiving the encrypted file information, the service module first decrypts and parses the context information sent out by the file, and then performs hierarchical judgment through the content recognition submodule; If the service module determines that there is a risk of leakage, it will feedback an encrypted outbound rejection instruction to the DLL module; after the DLL module decrypts the instruction and verifies its legitimacy, it records the detailed information of the outbound operation and stores it in the security log area of ​​the UWP process, and at the same time prevents the file from being sent again through other outbound APIs within a preset time.

8. A UWP application outbound management and control function compatibility adaptation system, characterized in that: The system is used to implement the UWP application outbound control function compatibility adaptation method as described in any one of claims 1 to 7; The system includes: The service module is used to create a named pipe instance and grant all UWP programs access to the named pipe instance by modifying the access control list of the security descriptor; The driver module is used to send a process start notification to the service module when detecting the loading event of the process main module; The service module is used to determine whether the newly started process is a UWP process. If not, it waits for the next process start notification. If it is, it executes the code injection module; The code injection module is used to insert an APC containing ShellCode into the main thread of the UWP process through an asynchronous procedure call. The ShellCode contains function instructions for loading the target DLL module and performing initialization. The target DLL module is used to intercept APIs related to file outbound transmission. The outgoing notification module is used when the user is ready to send files out. The DLL module injected into the UWP process connects to the named pipe instance created by the service module and informs the service module of the files to be sent out. The service module is used to determine whether there is a risk of leakage in the file content. If so, it will give a feedback of refusing to send it out. If the injected DLL module receives the feedback, the corresponding API call will fail.

9. An electronic device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein: When the processor executes the program, the steps of the UWP application outbound control function compatibility adaptation method as described in any one of claims 1 to 7 are implemented.

10. A storage medium having a computer program stored thereon, characterized in that: When the computer program is executed by the processor, the steps of the UWP application outbound control function compatibility adaptation method as described in any one of claims 1 to 7 are implemented.

Images