A UWP application external sending management and control function compatibility adaptation method, system, device and medium

Abstract

The application provides a UWP application external sending management and control function compatibility adaptation method, system, device and medium, and specifically belongs to the UWP application processing technical field, and specifically comprises the following steps: a service module creates a named pipe instance, and grants all UWP programs access rights to the named pipe instance; when a process main module loading event is monitored, a driving module sends a process startup notification to the service module; it is judged whether the newly started process is a UWP process, if yes, an APC item is inserted into the main thread of the UWP process through an asynchronous process calling mode; it is judged whether there is a leakage risk in the file content, if yes, a feedback of rejection of external sending is given, and if the injected DLL module receives the feedback, the corresponding API calling fails. The method realizes unified, real-time and auditable management and control of the external sending behavior of all UWP application files without destroying the sandbox isolation, and has little influence on the system stability and performance.

Description

Technical Field

[0001] This invention belongs to the field of UWP application processing technology, specifically relating to a method, system, device, and medium for compatibility adaptation of UWP application outbound control functions. Background Technology

[0002] With the rapid development of information technology, the information security industry has become a crucial sector. Especially in the enterprise market and in personal privacy protection, the demand for products and services that effectively prevent data breaches continues to grow. For the complex network environments of large enterprises, comprehensive data protection services are provided, including but not limited to endpoint protection, network intrusion detection, identity authentication, and access management. As public awareness of personal data privacy increases, 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 security mechanisms of the UWP process, external modules find it difficult to establish effective communication connections with it, making it impossible to effectively monitor and manage its internal operations. Startup monitoring of the process is not timely or accurate enough, often failing to provide effective intervention in the early stages of UWP process startup. Furthermore, due to the unique nature of the UWP process, it is difficult to intercept its file sharing API calls, making it impossible to promptly determine and intervene in cases of potential data leakage risks associated with file sharing. Summary of the Invention

[0004] This invention provides a compatibility adaptation method for UWP application outbound control functions. The method achieves unified, real-time, and auditable control over the outbound behavior of all UWP application files without violating sandbox isolation; and has minimal impact on system stability and performance.

[0005] The methods include:

[0006] S101: The service module creates a named pipe instance and grants all UWP applications access to the named pipe instance by modifying the access control list of the security descriptor;

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

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

[0009] S104: Insert an APC item containing ShellCode into the main thread of the UWP process via asynchronous procedure call; the ShellCode contains function instructions to load the target DLL module and execute its initialization, and the target DLL module is used to intercept file outgoing APIs;

[0010] S105: When a user is preparing 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 that is about to be sent.

[0011] S106: The service module determines whether there is a risk of file content leakage. If so, it provides feedback to refuse outgoing data. If the injected DLL module receives the feedback, it causes the corresponding API call to fail.

[0012] It should be further explained that step S101 specifically includes:

[0013] The service module constructs the security identifier (SID) for the ALLAPPLICATIONPACKAGES group using system functions;

[0014] The EXPLICIT_ACCESS structure is populated with security identifiers and preset access masks to generate valid access control entries;

[0015] Insert access control entries into an empty custom access control list using system functions;

[0016] Initialize the security descriptor;

[0017] Set the custom access control list as the DACL of the security descriptor;

[0018] Create a named pipe instance and bind a security descriptor to the named pipe instance during the creation process;

[0019] Release memory resources used by security identifiers, access control entries, custom access control lists, and security descriptors.

[0020] It should be further noted that step S101 also includes:

[0021] Obtain the fixed RID value of the corresponding ALLAPPLICATIONPACKAGES group through the security identifier generation tool provided by the operating system or predefined system constants, and generate a complete SID string by combining it with the identifier of the domain or local computer.

[0022] Based on the access requirements of the target resource, set the access mask of ACE and configure the flags of ACE to ensure that ACE can explicitly grant the ALLAPPLICATIONPACKAGES group specific access permissions to the named pipe instance.

[0023] After initializing an empty DACL using the security descriptor manipulation functions provided by the operating system, ACEs are added to the specified positions of the DACL in sequence to form a DACL structure containing the target permission rules;

[0024] Bind the DACL containing the ACE to the security descriptor SD of the named pipe instance; set the generated DACL as the primary DACL of SD by initializing the infrastructure of the security descriptor SD, and verify the binding validity between SD and the named pipe instance.

[0025] It should be further explained that step S103 specifically includes:

[0026] Perform initial state verification on empty custom access control lists (DACLs) to confirm that the default access control items and structure are not corrupted and conform to the system security descriptor specification. If there are implicit invalid structures, repair them.

[0027] The position of the ACE to be inserted in the DACL is determined according to the preset security priority rules;

[0028] After inserting the generated ACE into the specified position in the DACL, it checks whether there are other ACEs in the DACL with the same security identifier SID as the ACE. If so, it compares the access mask to determine whether the same SID is granted both allow and deny permissions at the same time, and adjusts the access mask or position of the ACE according to the conflict type.

[0029] Perform integrity verification on the DACL after inserting ACE.

[0030] It should be further explained that step S104 specifically includes:

[0031] The service module constructs ShellCode, which contains function instructions for loading the target DLL module and executing its initialization, as well as the parameters required by those function instructions;

[0032] The service module writes the ShellCode into the address space of the UWP process through memory operation functions;

[0033] 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;

[0034] The main thread of the UWP process enters a waiting state, checks its APC queue, and executes the callback function in the APC item.

[0035] The callback function loads the target DLL module through the system loading function and obtains the address of the DLL module's initialization function by obtaining the address of the exported function;

[0036] The callback function calls the initialization function to initialize the DLL module. Initialization includes intercepting external API functions sent from the file.

[0037] It should be further explained that step S105 specifically includes:

[0038] When the main thread of the UWP process executes the APC item, it checks the accessibility of the target DLL module's path in the UWP process environment and whether the digital signature of the DLL file meets the trust level of the UWP application through the pre-verification function in the ShellCode. If it does not meet the trust level, the loading process is terminated and the reason for the verification failure is recorded.

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

[0040] 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;

[0041] 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 reported to the service module and further instructions are awaited.

[0042] It should be further explained that step S106 specifically includes:

[0043] After the injected DLL module intercepts API calls related to file outgoing, it collects the context information of file outgoing and verifies the integrity of this information in the UWP sandbox environment.

[0044] When a DLL module establishes a connection with a named pipe instance of a service module, the transmitted file information is encrypted using a preset lightweight encryption algorithm, and the legitimacy of the pipe connection is verified at the same time.

[0045] After receiving the encrypted file information, the service module first decrypts and parses the context information of the file being sent out, and then performs layered judgment through the content recognition submodule;

[0046] If the service module determines that there is a risk of data leakage, it sends an encrypted rejection command to the DLL module. After the DLL module decrypts the command and verifies its legality, it records the details of the outgoing operation and stores them in the security log area of ​​the UWP process. At the same time, it prevents the file from being sent out again through other outgoing APIs within a preset time.

[0047] This application also provides a compatibility adaptation system for UWP application outbound control functions, the system including:

[0048] The service module is used to create named pipe instances and grant all UWP applications access to the named pipe instances by modifying the access control list of the security descriptor;

[0049] The driver module is used to send a process startup notification to the service module when the main process module is detected to be loading.

[0050] The service module is used to determine whether the newly started process is a UWP process. If not, it waits for the next process to start. If it is, it executes the code injection module.

[0051] The code injection module is used to insert an APC item containing ShellCode into the main thread of the UWP process via asynchronous procedure calls. The ShellCode contains function instructions to load the target DLL module and execute its initialization. The target DLL module is used to intercept file outgoing APIs.

[0052] The external notification module is used to notify the service module of the file to be sent when the user is preparing 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.

[0053] The service module is used to determine whether there is a risk of file content leakage. If so, it will provide feedback to refuse outgoing transmission. If the injected DLL module receives the feedback, it will cause the corresponding API call to fail.

[0054] According to another embodiment of this 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 executes the program to implement the steps of the UWP application outbound control function compatibility adaptation method.

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

[0056] As can be seen from the above technical solutions, the present invention has the following advantages:

[0057] The UWP application outbound control function compatibility adaptation method provided by this invention grants all UWP applications access to named pipe instances by configuring security descriptors, ensuring a stable communication connection between the injected DLL module and the service module. The driver module monitors the main module loading event and sends notifications, enabling the service module to be aware of the process startup status in a timely manner, thus saving time for subsequent processing of the UWP process. The service module determines the process type to avoid unnecessary operations on non-UWP processes, improving processing efficiency and reducing resource waste. An APC item containing ShellCode is inserted through an asynchronous procedure call mechanism, preparing for the injection of relevant code into the UWP process. The UWP process main thread executes the APC item to complete the loading and initialization of the DLL module, successfully injecting the module used to intercept file outbound APIs into the UWP process, realizing the monitoring preparation for file outbound operations. The DLL module intercepts file outbound API calls and interacts with the service module. The service module assesses risks and provides feedback instructions, effectively preventing the outbound transmission of files with potential leakage risks and ensuring information security. This ensures a smooth process from process monitoring and code injection to file outreach interception and risk assessment, guaranteeing that the normal functions of UWP applications are not excessively interfered with, while also preventing leaks in a timely manner. Attached Figure Description

[0058] To more clearly illustrate the technical solution of the present invention, the accompanying drawings used in the description will be briefly introduced below. Obviously, the accompanying drawings described below are only some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0059] Figure 1 Flowchart of compatibility adaptation method for UWP application external distribution control function;

[0060] Figure 2 Flowchart of an embodiment of a method for compatibility adaptation of UWP application outbound control functions;

[0061] Figure 3 Flowchart of another embodiment of the compatibility adaptation method for UWP application outbound control function;

[0062] Figure 4 Flowchart of another embodiment of the compatibility adaptation method for UWP application outbound control function;

[0063] Figure 5 This is a schematic diagram of an electronic device. Detailed Implementation

[0064] In this application, the UWP application will be able to load a DLL module containing API interception code, just like a traditional Win32 desktop application, and establish a communication mechanism with the service module from within it. When a user selects a file to send through the UWP application, the service module will be aware of this action and determine whether to allow sending through the content recognition submodule.

[0065] The following describes in detail the compatibility adaptation method for UWP application outbound control functions involved in this application. Specific details such as particular system structures and technologies are presented for illustrative purposes rather than limiting, in order to provide a thorough understanding of the embodiments of this application. However, those skilled in the art will understand that this application can also be implemented in other embodiments without these specific details.

[0066] It should be understood that, when used in this specification, terms include indicating the presence of a described feature, integral, step, operation, element, and / or component, but do not exclude the presence or addition of one or more other features, integrals, steps, operations, elements, components, and / or collections thereof. The terms include, encompass, have, and variations thereof mean including but not limited to, unless otherwise specifically emphasized.

[0067] The statements such as "one embodiment" or "some embodiments" described in this application mean that one or more embodiments of this application include the specific features, structures, or characteristics described in that embodiment. Therefore, the statements such as "in one embodiment," "in some embodiments," "in other embodiments," and "in still other embodiments" in this application do not necessarily refer to the same embodiment, but rather mean one or more, but not all, embodiments, unless otherwise specifically emphasized.

[0068] In embodiments of the present invention, computer program code for performing the operations of this disclosure can be written in one or more programming languages ​​or a combination thereof. These programming languages ​​include, but are not limited to, object-oriented programming languages ​​such as Java, Smalltalk, and C++, as well as conventional procedural programming languages ​​such as C or similar languages. The program code can be executed entirely on the user's computer, partially on the user's computer, as a standalone 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 remote computers, the remote computer can 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 can be connected to an external computer (exemplarily using an Internet service provider for Internet connection).

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

[0070] Please see Figure 1 and Figure 2 The diagram shows a flowchart of a UWP application outbound control function compatibility adaptation method in a specific embodiment. The method includes:

[0071] Step S101: The service module creates a named pipe instance and grants all UWP applications access to the named pipe instance by modifying the access control list of the security descriptor.

[0072] In some embodiments, such as Figure 3 As shown, step S101 specifically includes the following methods:

[0073] Step S2011: The service module constructs the security identifier SID for the ALLAPPLICATIONPACKAGES group through system functions;

[0074] Step S2012: The service module uses the security identifier and the preset access mask to fill the EXPLICIT_ACCESS structure and generate a valid access control entry ACE.

[0075] Step S2013: The service module inserts the access control item into an empty custom access control list (DACL) using a system function;

[0076] Step S2014: The service module initializes the security descriptor SD;

[0077] Step S2015: The service module sets the custom access control list as the DACL of the security descriptor;

[0078] Step S2016: The service module creates a named pipe instance and binds the security descriptor to the named pipe instance during the creation process;

[0079] Step S2017: The service module releases the memory resources occupied by the security identifier, access control item, custom access control list and security descriptor.

[0080] 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 conforms to the Windows system's specification for UWP application-associated group SIDs. The security identifier and a preset access mask are used to fill the EXPLICIT_ACCESS structure to generate a valid access control entry (ACE). The access mask is set according to the actual communication requirements of the UWP application for named pipes and only includes read, write, and connection permissions. The service module inserts the access control item into an empty custom access control list (DACL) using system functions, and checks if there are other implicit access control items in the DACL that conflict with the ACE. If so, it performs compatibility adjustments. The service module initializes the security descriptor (SD) and sets its version number to adapt to the current Windows system version, ensuring that the SD can be correctly recognized 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 between the DACL and the 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 creation, it tests whether the permission configuration of the named pipe is effective by simulating access requests from a 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 no memory leaks.

[0081] As can be seen, in Windows systems, resource access is controlled by security descriptors. The UWP process runs in an AppContainer sandbox, and its access token is associated by default with the ALLAPPLICATIONPACKAGES group SID. By default, externally created named pipes (SDs) do not contain access permissions for this SID, preventing UWP from accessing them. This step proactively adds an allowed entry for this group of SIDs to the SD's DACL, enabling the Windows security subsystem to match legitimate permissions when the UWP attempts to connect to the pipe, thus allowing communication. This embodiment of permission control avoids security risks caused by excessively open permissions, and its compatibility with Windows security mechanisms ensures high system stability and system acceptance of the configuration.

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

[0083] In some embodiments, the driver module triggers an event when the main process module is loaded by registering a kernel callback function. The monitored information includes the process ID, parent process ID, main module path, and process creation time. The driver encapsulates this information into a structure using custom I / O control codes and sends it to the user-space service module. A connection is established via the device handle `CreateFile` to ensure that the notification latency is below a threshold.

[0084] As can be seen, the driver runs at the system kernel level and can directly monitor the underlying events of process creation without being restricted by user-mode process permissions. When the UWP process starts, the loading of its main module is a critical node. After the driver captures this event, it transmits the information to the service module in real time through the communication mechanism between the kernel and user space, providing raw data for subsequent identification of the UWP process.

[0085] This embodiment enables real-time monitoring of process startup, ensuring that UWP processes are included in the management scope as soon as they start, avoiding the omission of processes that are already running but not being monitored. Kernel-level monitoring is not affected by the UWP sandbox and can obtain complete process information, solving the problem of incomplete user-mode monitoring information.

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

[0087] After receiving the process information, the service module in this embodiment performs three-level judgments:

[0088] ① Call the GetPackageFullName function to obtain the application package name of the process. If it returns successfully and the package name is in the format of publisher, application name, version, architecture and signature, it is initially determined to be UWP.

[0089] ② If package name acquisition fails, check the process access token. If the token contains an APP_CONTAINER_INFORMATION structure and has an AppContainerSID in a preset format, then it is determined to be a UWP.

[0090] ③ Finally, check whether the main module path is located in the UWP default installation path and whether the path contains a verified package name folder.

[0091] If none of the three layers meet the requirements, it is determined to be a non-UWP.

[0092] It's important to note that UWP processes, based on the application package model and constrained by the AppContainer sandbox, 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 verifies the existence and compliance of these characteristics to accurately identify UWP processes.

[0093] Step S104: Insert an APC item containing ShellCode into the main thread of the UWP process via asynchronous procedure call; the ShellCode contains function instructions to load the target DLL module and execute its initialization, and the target DLL module is used to intercept file outgoing APIs.

[0094] In some embodiments, the service module first constructs ShellCode, which specifically includes an LdrLoadDll call, an LdrGetProcedureAddress to obtain the InjectInit address, an instruction to call InjectInit, and parameters such as the DLL path string and function name.

[0095] The VirtualAllocEx allocates memory with PAGE_EXECUTE_READWRITE permission in the UWP process, calls WriteProcessMemory to write the ShellCode, and verifies that the hash of the written data matches the original hash. When constructing the APC item, the callback function pointer points to the starting address of the ShellCode and appends data containing the package name hash of the UWP process. After inserting the APC by calling QueueUserAPC, the WaitForSingleObject monitors the main thread status. If it is not entered within 5 seconds, a reminder to wait is displayed, and a custom event is triggered to cause a thread state switch.

[0096] The APC mechanism in this embodiment allows a process to insert a function to be executed into a target thread. When the target thread calls a waitable function, the APC function is executed first. The UWP main thread frequently enters waitable states during runtime. The service module utilizes this feature to inject the DLL loading instruction via APC, causing the UWP thread to actively execute ShellCode, thereby completing DLL loading within the sandbox and overcoming UWP's restrictions on external injection.

[0097] This embodiment utilizes the UWP thread's own execution mechanism to achieve injection, avoiding detection as malicious behavior by UWP security protection. Verification mechanisms for memory allocation and ShellCode writing ensure that the injected content is not tampered with, resulting in high security.

[0098] 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 that is about to be sent.

[0099] In this embodiment, when the APC is executed in the UWP main thread, the ShellCode first calls LdrLoadDll to load the target DLL. If it returns STATUS_SUCCESS, it obtains the address of the InjectInit function through LdrGetProcedureAddress. When InjectInit is called, the function executes in the following manner:

[0100] ① Parse the import table of the file outgoing API in the UWP process;

[0101] ② By modifying the first 5 bytes of the function entry point to a jump instruction, API calls are redirected to an intercept function within the DLL;

[0102] ③ Generate an API interception mapping table to record the original function address and the intercepted function address.

[0103] After initialization, ShellCode calls VirtualFree to release its own memory, triggers a simulated file outgoing operation, and verifies whether the interception function has captured the call. If successful, it returns STATUS_SUCCESS; otherwise, it sends an error code to the service module.

[0104] 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, causing file outgoing operations to pass through the DLL's interception function, thereby achieving real-time monitoring of the operation and providing an entry point for subsequent management.

[0105] In this embodiment, the DLL runs within the UWP process, allowing direct access to APIs and file information within the process, thus resolving the issue of restricted cross-process access. The API interception verification mechanism ensures functional effectiveness and avoids the potential problem of successful injection but failed interception.

[0106] Step S106: The service module determines whether there is a risk of data leakage in the file content. If so, it issues a rejection message. If the injected DLL module receives this message, it causes the corresponding API call to fail.

[0107] In some embodiments, when the DLL intercepts the API, it extracts the file path, outgoing method, file size, and content digest. When sending via a named pipe, the digital signature of the attached DLL is encrypted using AES-128.

[0108] After the service module in this embodiment is decrypted, the content recognition submodule first compares it with the sensitive file hash library, then uses regular expressions to match sensitive information, and adjusts the threshold based on user permissions.

[0109] Optionally, regular users can match one sensitive word, while administrators can match three.

[0110] If a risk is identified, the service module generates an encrypted rejection instruction. After the DLL decrypts the instruction, it 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 out through other APIs such as WriteFile and SaveToStorage within a preset time period.

[0111] As can be seen, the injected DLL acts as a man-in-the-middle in the file outgoing operation. After intercepting the API call, it passes the key information to the service module. The service module judges the risk through content recognition and then feeds back the instruction through the pipeline. The DLL controls the API execution result according to the instruction, forming a closed loop of interception, judgment and execution. By leveraging the collaboration between UWP and the service module, the sandbox restriction is broken, and the security control of file outgoing is achieved.

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

[0113] In one embodiment of the present invention, based on step S101, the following will provide a possible embodiment and its specific implementation will be described in a non-limiting manner. Step S101 specifically includes:

[0114] Step S1011: Obtain the fixed RID value of the corresponding ALLAPPLICATIONPACKAGES group through the security identifier generation tool provided by the operating system or predefined system constants, and combine it with the identifier of the domain or local computer to generate a complete SID string to ensure its uniqueness and system identification validity.

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

[0116] Optionally, permissions such as read, write, and connect can be allowed; the flags of the ACE can be configured to ensure that the ACE can explicitly grant the ALLAPPLICATIONPACKAGES group specific access permissions to the named pipe instance.

[0117] Step S1013: After initializing the empty DACL using the security descriptor operation functions provided by the operating system, add the ACEs to the specified positions of the DACL in sequence to form a DACL structure containing the target permission rules, ensuring the validity and integrity of the DACL.

[0118] Step S1014: Bind the DACL containing the 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 main DACL of the SD, and verify the binding validity between the SD and the named pipe instance to ensure that the named pipe instance can control the access permissions of the UWP application based on the SD after its creation.

[0119] As can be seen, due to system security policy restrictions, UWP applications can only access resource objects created by themselves by default, and resources created by other processes or system components are denied access to UWP applications by default.

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

[0121] When a UWP application attempts to access the named pipe, the Windows security subsystem checks whether the SID in its access token matches the allow rules in the DACL of the SD. Since the SID of the ALLAPPLICATIONPACKAGES group is included in the UWP application's access token and the SD has explicitly granted access to this group, the UWP application can successfully access the named pipe instance, thus solving the problem in traditional solutions where UWP applications cannot access resources not created by themselves.

[0122] In one embodiment of the present invention, based on step S1013, the following will provide a possible embodiment and its specific implementation will be described in a non-limiting manner. Step S1013 specifically includes:

[0123] Step S10131: Perform an initial state check on the empty custom access control list (DACL) to confirm that it has no hidden default access control entries, its structure is not damaged, and it conforms to the system security descriptor specification. If there are hidden invalid structures, repair them.

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

[0125] Optionally, the security priority rule can be: deny permissions take precedence over allow permissions, and specific users / groups take precedence over general groups.

[0126] 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 at the same time, and adjust the access mask or position of the ACE according to the conflict type.

[0127] 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 conforms to the system security policy, to ensure that the DACL can be correctly parsed by the Windows security subsystem.

[0128] It should be noted that a custom access control list (DACL) is a control structure for resource access permissions. It defines how the SID can access the resource through the access control entry ACE.

[0129] Step S1013 involves embedding the ACE that grants access permissions to the UWP application into an empty DACL. This ensures that the DACL can accurately identify the SID of the ALLAPPLICATIONPACKAGES group and follow the system security priority rules, avoiding permission conflicts or invalid configurations. Ultimately, this ensures that the access requests of the UWP application are correctly allowed by the system security mechanism.

[0130] This embodiment differs from existing techniques that insert ACEs into empty DACLs. This step verifies the empty DACL, eliminating residual default ACE fragments and addressing the potential issue that an empty DACL may not truly be empty. The ACE insertion position is dynamically determined based on security priorities. For example, if other deny-permission ACEs may be added later, the currently allowed-permission ACEs must be placed in appropriate positions to prevent overwriting. Simultaneous allow and deny write operations for the same SID are adjusted to avoid confusion in permission logic, ensuring that the DACL can be correctly parsed by the system, granting UWP access rights without compromising the fundamental security boundaries of resources.

[0131] In one embodiment of the present invention, based on step S103, the following will provide a possible embodiment and its specific implementation will be described in a non-limiting manner. Step S103 specifically includes:

[0132] Step S1031: Obtain the basic information of the target process from the process startup 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.

[0133] Step S1032: Call the GetTokenInformation function to extract the security identifier SID from the process token, focusing on checking whether there is an ALLAPPLICATIONPACKAGES group SID or an AppContainer type SID that the UWP application has, and record the token's integrity level.

[0134] Step S1033: Enumerate the list of modules loaded by the target process using the EnumProcessModules function, and check whether it contains the module characteristics of the UWP application runtime.

[0135] Module characteristics include Windows.UI.Xaml.dll, CoreCLR.dll, etc. Confirm whether the module characteristics conform to the UWP application sandbox directory specifications.

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

[0137] It should be noted that this step identifies UWP processes through multi-dimensional feature cross-validation. It uses process tokens to resolve SIDs and filters out processes with unique UWP identifiers. Secondly, it verifies the module list to ensure the process loads UWP, avoiding misjudgment as a regular process with a maliciously forged SID. The combination of these two methods forms a dual verification mechanism of identity and behavior. This leverages the security design features of the UWP system while eliminating potential deceptive behavior through module loading characteristics, thus improving the accuracy of process type identification.

[0138] This embodiment also obtains the process handle through the `OpenProcess` function, and then calls the `OpenProcessToken` function to obtain the process's access token handle. This token stores the process's identity information and permission policy. The SID feature verification method is based on the fact that the process token of a UWP application necessarily contains two types of key SIDs: one is the `ALLAPPLICATIONPACKAGES` group SID, used to grant the UWP application permission to access external resources; the other is the `AppContainerSID`, used to identify that the process is running in a sandbox environment. Verification can be achieved by obtaining the `TokenGroups` structure through the `GetTokenInformation` function and iterating through the SID list within it.

[0139] In one embodiment of the present invention, based on step S104, the following will provide a possible embodiment and its specific implementation will be described in a non-limiting manner. For example... Figure 4As shown, step S104 specifically includes:

[0140] Step S1041: The service module constructs ShellCode, which contains function instructions for loading the target DLL module and executing initialization, as well as the parameters required by the function instructions;

[0141] Step S1042: The service module writes the ShellCode into the address space of the UWP process through memory operation functions;

[0142] Step S1043: The service module inserts an APC item into the main thread of the UWP process through an asynchronous procedure call function, wherein the callback function pointer of the APC item points to the starting address of the ShellCode;

[0143] 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;

[0144] Step S1045: The callback function loads the target DLL module through the system loading function, and obtains the address of the initialization function of the DLL module by obtaining the address of the exported function;

[0145] Step S1046: The callback function calls the initialization function to initialize the DLL module. The initialization includes intercepting the file-external API functions.

[0146] It should be noted that ShellCode refers to a piece of binary code and data, including the complete disassembled code of a special function, as well as all the parameters required by this special function. The work of this special function is as follows:

[0147] Load the DLL module to be injected using LdrLoadDll;

[0148] Get the address of the exported function InjectInit of the injected DLL using LdrGetProcedureAddress;

[0149] Calling InjectInit initializes the injected DLL, primarily to intercept file-external API functions.

[0150] Asynchronous Procedure Calls (APCs) are an asynchronous I / O mechanism provided by the operating system. Each thread maintains an APC queue. When a thread enters a waitable state, the operating system checks if there is an APC item in the APC queue. If there is, it is retrieved and its bound callback function is executed, which is a special function contained in the shell code.

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

[0152] The service module invokes the system's asynchronous procedure call function, inserting the APC entry pointing to this ShellCode into the APC queue of the UWP process's main thread. When the UWP process's main thread enters a waitable state again, the system kernel automatically retrieves the APC entry and hands over execution control to the ShellCode. The ShellCode first calls the system loading function to load the target DLL into memory, then uses the mechanism of obtaining the addresses of exported functions to find the initialization function inside the DLL and immediately calls it. The initialization function completes the interception settings for file outgoing APIs, and then the ShellCode ends and returns control to the UWP main thread, allowing the UWP process to continue executing normally.

[0153] Step S104 does not require creating a remote thread or touching any dangerous APIs prohibited by the UWP sandbox. It achieves DLL injection by utilizing only the system's legitimate asynchronous procedure calls and memory write mechanisms, thus penetrating UWP isolation restrictions. The shellcode is small in size and has a short execution path, with minimal impact on the original logic of the UWP process. The one-time execution marking and integrity verification mechanism ensure that the injection behavior is unique and cannot be repeated, avoiding the stability risks caused by multiple hookings.

[0154] In one embodiment of the present invention, based on step S105, the following will provide a possible embodiment and its specific implementation will be described in a non-limiting manner. Step S105 specifically includes:

[0155] Step S1051: When the main thread of the UWP process executes the APC item, it first checks the accessibility of the target DLL module's path in the UWP process environment and whether the digital signature of the DLL file meets the trust level of the UWP application through the pre-verification function in the ShellCode. If it does not meet the requirements, the loading process is terminated and the reason for the verification failure is recorded.

[0156] 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 DLL's loading parameters. After loading is complete, it obtains the base address of the DLL module and verifies its validity.

[0157] 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. If the memory address of the file outgoing API is detected to be inconsistent with the preset characteristics during the initialization process, the interception logic is adaptively adjusted.

[0158] Step S1054: 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 reported to the service module and further instructions are awaited.

[0159] As can be seen, when the UWP process's main thread executes the ShellCode in the APC queue in this embodiment, it utilizes the process's own loader and memory environment to load the target DLL, integrating the DLL module into the UWP process's address space. By calling the DLL's initialization function, it triggers API interception logic, redirecting the call paths of file outgoing APIs to the interception functions within the DLL, thereby achieving real-time monitoring of file outgoing operations. This process relies on the UWP process's trust mechanism for its own loaded modules, enabling the DLL to participate in the process's function call flow with a legitimate identity. This avoids loading failures due to UWP sandbox limitations. Dynamic API address adaptation logic is added during the initialization phase to resolve compatibility issues related to API address offsets across different system versions. After loading, the ShellCode memory is released to reduce the detection risk of UWP security mechanisms, improving the stability and environmental adaptability of the injected DLL functionality.

[0160] In one embodiment of the present invention, based on step S106, the following will provide a possible embodiment and its specific implementation will be described in a non-limiting manner. Step S106 specifically includes:

[0161] Step S1061: After the injected DLL module intercepts the API calls related to file outgoing, it collects the context information of file outgoing and verifies the integrity of this information in the UWP sandbox environment. If the information is incomplete, it supplements or marks the missing items.

[0162] 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. At the same time, the other end of the pipe connection is verified to be a legitimate service module to prevent third-party processes from impersonating the service module and stealing information.

[0163] Step S1063: After receiving the encrypted file information, the service module first decrypts and parses the context information of the file being sent out, and then performs layered judgment through the content recognition submodule.

[0164] Specifically, the system quickly screens files by type and size, then matches the file content with sensitive keywords and structured data, and adjusts the judgment threshold based on the user's permission level when initiating the outbound operation.

[0165] Step S1064: If the service module determines that there is a risk of data leakage, it sends an encrypted rejection command to the DLL module. After the DLL module decrypts the command and verifies its legitimacy, in addition to causing the corresponding API call to return failure, it also records the detailed information of this outbound operation and stores it in the security log area of ​​the UWP process, while preventing the file from being sent out again through other outbound APIs within a preset time.

[0166] In this embodiment, the DLL module injected into the UWP process intercepts the file outgoing API, becoming an intermediate node for file outgoing operations. On one hand, it collects operation details and passes them to the service module via named pipes; on the other hand, it receives the risk assessment results from the service module. The service module determines whether to allow outgoing files based on content recognition, and ultimately the DLL module executes the allow or deny instruction. By leveraging the collaboration between the UWP process and the service module, the limitations of the UWP sandbox on external control are overcome, achieving precise control over file outgoing files.

[0167] It should be understood that the sequence number of each step in the above embodiments does not imply 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.

[0168] The following are embodiments of the UWP application external release control function compatibility adaptation system provided in this disclosure. This system and the UWP application external release control function compatibility adaptation method in the above embodiments belong to the same inventive concept. For details not described in detail in the embodiments of the UWP application external release control function compatibility adaptation system, please refer to the embodiments of the above UWP application external release control function compatibility adaptation method.

[0169] The system includes:

[0170] The service module is used to create named pipe instances and grant all UWP applications access to the named pipe instance by modifying the access control list of the security descriptor;

[0171] The driver module is used to send a process startup notification to the service module when the main process module is detected to be loading.

[0172] The service module is used to determine whether the newly started process is a UWP process. If not, it waits for the next process to start. If it is, it executes the code injection module.

[0173] The code injection module is used to insert an APC item containing ShellCode into the main thread of the UWP process via asynchronous procedure call; the ShellCode contains function instructions to load the target DLL module and execute its initialization, and the target DLL module is used to intercept file outgoing APIs;

[0174] The external notification module is used to notify the service module of the file to be sent when the user is preparing 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.

[0175] The service module is used to determine whether there is a risk of file content leakage. If so, it will give feedback to refuse to send it out. If the injected DLL module receives this feedback, it will cause the corresponding API call to fail.

[0176] like Figure 5 As shown, this 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. When the processor 101 executes the program, it implements the steps of the UWP application outbound control function compatibility adaptation method.

[0177] In 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 processors, cellular phones, smartphones, 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 described and / or claimed herein.

[0178] In this embodiment, processor 101 may be implemented using at least one of an application-specific integrated circuit, a programmable logic device, a field-programmable gate array, a processor, a controller, a microcontroller, a microprocessor, or an electronic unit designed to perform the functions described herein. In some cases, such an implementation may be implemented within a controller. For software implementation, implementations such as processes or functions may be implemented with separate software modules that allow the performance of at least one function or operation. Software code may be implemented by a software application (or program) written in any suitable programming language, and the software code may be stored in memory and executed by the controller.

[0179] 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, or the like.

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

[0181] This application also provides a storage medium storing a computer program thereon, wherein when the computer program is executed by a processor, it implements the steps of the UWP application outbound control function compatibility adaptation method.

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

[0183] In a storage medium, a readable signal medium may include a data signal propagated in baseband or as part of a carrier wave, carrying readable program code. This propagated data signal may take various 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, capable of sending, propagating, or transmitting a program for use by or in conjunction with an instruction execution system, apparatus, or device.

[0184] The above description of the disclosed embodiments enables those skilled in the art to make or use the invention. Various modifications to these embodiments will be readily apparent to those 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 invention. Therefore, the invention is not to be limited to the embodiments shown herein, but is to be accorded the widest scope consistent with the principles and novel features disclosed herein.

Claims

1. A method for compatibility adaptation of UWP application outbound control functions, characterized in that, The methods include: S101: The service module creates a named pipe instance and grants all UWP applications access to the named pipe instance by modifying the access control list of the security descriptor; S102: When the driver module detects the 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 to start. If it is, it executes step S104. S104: Insert an APC item containing ShellCode into the main thread of the UWP process via asynchronous procedure call; the ShellCode contains function instructions to load the target DLL module and execute its initialization, and the target DLL module is used to intercept file outgoing APIs; S105: When a user is preparing 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 that is about to be sent. S106: The service module determines whether there is a risk of file content leakage. If so, it provides feedback to refuse outgoing data. If the injected DLL module receives the feedback, it causes the corresponding API call to fail.

2. The UWP application outbound control function compatibility adaptation method according to claim 1, characterized in that, Step S101 specifically includes: The service module constructs the security identifier (SID) for the ALLAPPLICATIONPACKAGES group using system functions; The EXPLICIT_ACCESS structure is populated with security identifiers and preset access masks to generate valid access control entries; Insert access control entries into an empty custom access control list using 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 a security descriptor to the named pipe instance during the creation process; Release memory resources used by security identifiers, access control entries, custom access control lists, and security descriptors.

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

4. The UWP application outbound control function compatibility adaptation method according to claim 1, characterized in that, Step S103 specifically includes: Perform initial state verification on empty custom access control lists (DACLs) to confirm that the default access control items and structure are not corrupted and conform to the system security descriptor specification. If there are implicit invalid structures, repair them. The position of the ACE to be inserted in the DACL is determined according to the preset security priority rules; After inserting the generated ACE into the specified position in the DACL, it checks whether there are other ACEs in the DACL with the same security identifier SID as the ACE. If so, it compares the access mask to determine whether the same SID is granted both allow and deny permissions at the same time, and adjusts the access mask or position of the ACE according to the conflict type. Perform integrity verification on the DACL after inserting ACE.

5. The UWP application outbound control function compatibility adaptation method according to claim 1, characterized in that, Step S104 specifically includes: The service module constructs ShellCode, which contains function instructions for loading the target DLL module and executing its initialization, as well as the parameters required by those function instructions; The service module writes the ShellCode into the address space of the UWP process through memory operation functions; 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 address of the DLL module's initialization function by obtaining the address of the exported function; The callback function calls the initialization function to initialize the DLL module. Initialization includes intercepting external API functions sent from the file.

6. The UWP application outbound control function compatibility adaptation method according to claim 1, characterized in that, Step S105 specifically includes: When the main thread of the UWP process executes the APC item, it checks the accessibility of the target DLL module's path in the UWP process environment and whether the digital signature of the DLL file meets the trust level of the UWP application through the pre-verification function in the ShellCode. If it does not meet the trust level, 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's loader imposes additional sandbox restrictions on the DLL module. If there are restrictions, it attempts to circumvent them by adjusting the DLL's loading parameters. After loading is complete, it obtains the base address of the DLL module and verifies its validity. 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; 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 reported to the service module and further instructions are awaited.

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

8. A UWP application outbound control function compatibility adaptation system, characterized in that, The system is used to implement the compatibility adaptation method for UWP application outbound control function as described in any one of claims 1 to 7; The system includes: The service module is used to create named pipe instances and grant all UWP applications access to the named pipe instances by modifying the access control list of the security descriptor; The driver module is used to send a process startup notification to the service module when the main process module is detected to be loading. The service module is used to determine whether the newly started process is a UWP process. If not, it waits for the next process to start. If it is, it executes the code injection module. The code injection module is used to insert an APC item containing ShellCode into the main thread of the UWP process via asynchronous procedure calls. The ShellCode contains function instructions to load the target DLL module and execute its initialization. The target DLL module is used to intercept file outgoing APIs. The external notification module is used to notify the service module of the file to be sent when the user is preparing 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. The service module is used to determine whether there is a risk of file content leakage. If so, it will provide feedback to refuse outgoing transmission. If the injected DLL module receives the feedback, it will cause the corresponding API call to fail.

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

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

Images