CN120653467A

CN120653467A - UWP application outgoing management and control function compatibility adaptation method, system, equipment and medium

Info

Publication number: CN120653467A
Application number: CN202511127178.7A
Authority: CN
Inventors: 刘洪星; 李兴国; 罗圣美; 刘志远; 李栋; 杨鲁峰
Original assignee: Zhongfu Safety Technology Co Ltd
Current assignee: Zhongfu Safety Technology Co Ltd
Priority date: 2025-08-13
Filing date: 2025-08-13
Publication date: 2025-09-16

Abstract

The present invention provides a method, system, device and medium for adapting the compatibility of the outbound control function of UWP applications, which specifically belongs to the field of UWP application processing technology, and specifically includes: a service module creates a named pipe instance and grants all UWP programs access rights to the named pipe instance; a driver module sends a process start notification to the service module when monitoring a process main module loading event; determines whether the newly started process is a UWP process, and if so, inserts an APC item into the main thread of the UWP process through an asynchronous procedure call; determines whether there is a risk of leakage in the file content, and if so, gives feedback of refusing outbound transmission, and if the injected DLL module receives the feedback, the corresponding API call fails. The method achieves unified, real-time and auditable control of the outbound behavior of all UWP application files without destroying the sandbox isolation, and has little impact on system stability and performance.

Description

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

Technical Field

The invention belongs to the technical field of UWP application processing, and particularly relates to a method, a system, equipment and a medium for adapting compatibility of a UWP application outgoing control function.

Background

Under the rapid development of information technology, the information security industry has become a critical field. Especially in the aspect of enterprise-level market and personal privacy protection, there is a continuous increase in demand for products and services capable of effectively preventing data leakage. For complex network environments of large enterprises, comprehensive data protection services are provided, including but not limited to terminal protection, network intrusion detection, identity authentication, access management and the like. With the increasing public interest in personal data privacy, more and more consumers are beginning to seek applications and services that can help them protect personal information from abuse.

In the related art, due to the limitation of a safety mechanism of the UWP process, an external module is difficult to establish an effective communication connection with the UWP process, so that the internal operation of the UWP process cannot be effectively monitored and managed. The starting monitoring of the process is not timely and accurate enough, and effective intervention cannot be carried out at the initial stage of the UWP process starting. And due to the particularity of the UWP process, the API call related to the file issuing is difficult to intercept, and whether the file issuing has a secret leakage risk or not cannot be judged in time and intervention is performed.

Disclosure of Invention

The invention provides a compatibility adaptation method for UWP application outgoing management and control functions, which realizes unified, real-time and auditable management and control of all UWP application file outgoing behaviors on the premise of not damaging sandbox isolation and has little influence on system stability and performance.

The method comprises the following steps:

S101, a service module creates a named pipeline instance, and grants access rights of all UWP programs to the named pipeline instance by modifying an access control list of a security descriptor;

S102, when the driving module monitors a loading event of the process main module, a process starting notification is sent to the service module;

S103, the service module judges whether the newly started process is a UWP process, if not, the next process is waited for starting notification, if yes, the step S104 is executed;

S104, enabling a main line Cheng Charu of the UWP process to contain an APC item of a Shellcode in an asynchronous procedure call mode, wherein the Shellcode contains a function instruction for loading a target DLL module and executing initialization, and the target DLL module is used for intercepting a file outgoing related API;

S105, when a user prepares an outgoing file, a DLL module injected into the UWP process is connected with a named pipe instance created by the service module, and the service module is informed of the file to be sent out;

And S106, the service module judges whether the file content has a secret leakage risk or not, if so, gives feedback for refusing to be sent out, and if the injected DLL module receives the feedback, the corresponding API call fails.

It should be further noted that step S101 specifically includes:

the service module constructs ALLAPPLICATIONPACKAGES groups of security identifiers SIDs through a system function;

Filling an EXPLICIT_ACCESS structure by using the security identifier and a preset ACCESS mask to generate legal ACCESS control items;

inserting the access control item into an empty custom access control list through a system function;

Initializing a security descriptor;

setting the custom access control list as the DACL of the security descriptor;

creating a named pipe instance, and binding the security descriptor to the named pipe instance in the creation process;

releasing the memory resources occupied by the security identifier, the access control item, the custom access control list and the security descriptor.

It should be further noted that step S101 further includes:

acquiring a fixed RID value corresponding to ALLAPPLICATIONPACKAGES groups through a security identifier generation tool or a predefined system constant provided by an operating system, and generating a complete SID character string by combining an identifier of a domain or a local computer;

According to the access requirement of the target resource, setting an access mask of ACE, configuring a zone bit of ACE, and ensuring that the ACE can definitely grant ALLAPPLICATIONPACKAGES groups of specific access rights to named pipeline examples;

After initializing an empty DACL through a security descriptor operation function provided by an operating system, sequentially adding ACE to a designated position of the DACL to form a DACL structure containing a target authority rule;

And setting the generated DACL as a main DACL of the SD by initializing the infrastructure of the secure descriptor SD, and verifying the binding validity of the SD and the named pipeline instance.

It should be further noted that step S103 specifically includes:

checking the initial state of the empty self-defined access control list DACL, confirming that the default access control item and the structure are not damaged and meet the system security descriptor specification, and repairing if an implicit invalid structure exists;

determining the position of ACE to be inserted in DACL according to a preset safety priority rule;

After inserting the generated ACE into the appointed position of the DACL, detecting whether other ACEs which are the same as the security identifier SID of the ACE exist in the DACL, comparing the access mask if the ACEs exist, judging whether the same SID is granted permission and rejection permission at the same time, and adjusting the access mask or the position of the ACE according to the conflict type;

integrity verification was performed on the DACL after insertion of ACE.

It should be further noted that step S104 specifically includes:

the service module constructs a ShellCode, wherein the ShellCode comprises a function instruction for loading a target DLL module and executing initialization, and parameters required by the function instruction;

The service module writes the ShellCode into an address space of the UWP process through a memory operation function;

The service module inserts an APC item into a main thread of the UWP process through an asynchronous procedure call function, and a callback function pointer of the APC item points to a starting address of the ShellCode;

the main thread of the UWP process enters a waiting state, and an APC queue of the main thread is checked and a callback function in the APC item is executed;

The callback function loads a target DLL module through a system loading function, and acquires an initialization function address of the DLL module in a mode of acquiring an export function address;

The callback function calls an initialization function to initialize the DLL module, and the initialization comprises interception of the file outgoing API function.

It should be further noted that step S105 specifically includes:

When the main thread of the UWP process executes the APC item, checking the accessibility of the path of the target DLL module in the UWP process environment through a pre-checking function in the ShellCode, and if the digital signature of the DLL file accords with the trust level of the UWP application, terminating the loading process and recording the cause of the checking failure;

the ShellCode call LdrLoadDll loads a target DLL module, monitors whether a loader of the UWP process applies additional sandbox restriction to the DLL module in the loading process, tries to avoid by adjusting the loading parameters of the DLL if the additional sandbox restriction exists, acquires the base address of the DLL module after loading is completed and verifies the validity of the base address;

After InjectInit function addresses are obtained through LdrGetProcedureAddress, whether the prior address is located in the memory address range of the loaded DLL module or not is verified, and then function execution initialization is called;

After initialization is completed, the ShellCode triggers a simulated file outgoing API call, whether the injected DLL module can successfully intercept the call is verified, if so, memory resources occupied by the ShellCode are released, and if not, interception failure information is fed back to the service module and further instructions are waited.

It should be further noted that step S106 specifically includes:

After intercepting the file outgoing related API call, the injected DLL module collects the context information of the file outgoing and verifies the integrity of the information in the UWP sandbox environment;

When the DLL module establishes connection with a named pipeline instance of the service module, encrypting the transmitted file information through a preset lightweight encryption algorithm, and simultaneously verifying the legality of the pipeline connection;

after receiving the encrypted file information, the service module firstly decrypts and analyzes the context information sent by the file, and then performs layering judgment through the content identification submodule;

And after decrypting the instruction and verifying the legitimacy, the DLL module records the detailed information of the outgoing operation and stores the detailed information in a safety log area of the UWP process, and simultaneously prevents the file from attempting to be sent again through other outgoing APIs within preset time.

The application also provides a UWP application external management and control function compatibility adaptation system, which comprises:

the service module is used for creating a named pipeline instance and granting access rights of all UWP programs to the named pipeline instance by modifying an access control list of the security descriptor;

The driving module is used for sending a process starting notification to the service module when the process main module loading event is monitored;

The service module is used for judging whether the newly started process is a UWP process, if not, waiting for a next process starting notice, and if so, executing the code injection module;

The code injection module is used for loading the target DLL module and executing initialized function instructions to the APC item of the ShellCode contained in the main line Cheng Charu of the UWP process in an asynchronous procedure calling mode, wherein the target DLL module is used for intercepting file outgoing related APIs;

The outgoing notification module is used for connecting the DLL module injected into the UWP process with the named pipeline instance created by the service module when the user prepares an outgoing file and notifying the service module of the file to be sent out;

and the service module is used for judging whether the file content has a secret leakage risk or not, if so, giving feedback for refusing to be sent out, and if the injected DLL module receives the feedback, making the corresponding API call fail.

According to another embodiment of the present application, there is provided an electronic device including a memory, a processor, and a computer program stored on the memory and executable on the processor, the steps of the UWP application outgoing management function compatibility adaptation method being implemented by the processor when executing the program.

According to yet another embodiment of the present application, there is also provided a storage medium having stored thereon a computer program which, when executed by a processor, implements the steps of the UWP application outgoing management function compatibility adaptation method.

From the above technical scheme, the invention has the following advantages:

The UWP application outbound management and control function compatibility adaptation method provided by the invention grants the authority of all UWP applications to access named pipeline examples through configuring the security descriptor, so that stable communication connection between the injected DLL module and the service module is ensured. The driving module monitors the loading event of the process main module and sends a notification, so that the service module can know the starting condition of the process in time, and the time is strived for the subsequent processing of the UWP process. The service module judges the process type, avoids unnecessary operation on the non-UWP process, improves the processing efficiency and reduces the resource waste. The preparation of injecting relevant code into the UWP process is achieved by inserting APC items containing ShellCode through an asynchronous procedure call mechanism. The UWP process main thread executes the APC item to complete the loading and initialization of the DLL module, and the module for intercepting the file outgoing API is successfully injected into the UWP process, so that the monitoring preparation of the file outgoing operation is realized. The DLL module intercepts the file issuing API call and interacts with the service module, and the service module judges risks and feeds back instructions, so that file issuing with leakage risks can be effectively prevented, and information safety is guaranteed. The whole process from process monitoring, code injection to file outgoing interception and risk judgment is ensured to be smoothly carried out, the normal function of UWP application is ensured not to be excessively interfered, and the leakage behavior can be timely prevented.

Drawings

In order to more clearly illustrate the technical solutions of the present invention, the drawings that are needed in the description will be briefly introduced below, it being obvious that the drawings in the following description are only some embodiments of the present invention, and that other drawings can be obtained according to these drawings without inventive effort for a person skilled in the art.

FIG. 1 is a flow chart of a UWP application outgoing management and control function compatibility adaptation method;

FIG. 2 is a flow chart of an embodiment of a method for adapting compatibility of UWP application outgoing management and control functions;

FIG. 3 is a flowchart of yet another embodiment of a UWP application outgoing management and control function compatibility adaptation method;

FIG. 4 is a flowchart of another embodiment of a UWP application outgoing management and control function compatibility adaptation method;

Fig. 5 is a schematic diagram of an electronic device.

Detailed Description

In the application, the UWP application can load the DLL module containing interception API codes and establish a communication mechanism with the service module from the inside as the traditional Win32 desktop application program, when a user selects a file to be sent out through the UWP program, the service module knows the action and judges whether the sending out is allowed or not through the content identification submodule.

The following detailed description of the application relates to a UWP application outgoing management function compatibility adaptation method, and specific details, such as specific system architecture, techniques, etc., are set forth for purposes of illustration and not limitation, in order to provide a thorough understanding of the embodiments of the application. It will be apparent, however, to one skilled in the art that the present application may be practiced in other embodiments that depart from these specific details.

It will be understood that the terms "comprises" and/or "comprising," when used in this specification, specify the presence of stated features, integers, steps, operations, elements, and/or components, but do not preclude the presence or addition of one or more other features, integers, steps, operations, elements, components, and/or groups thereof. The terms including, comprising, having, and variations thereof are meant to encompass, but not be limited to, unless otherwise specifically emphasized.

The statements of one embodiment or some embodiments described in this disclosure mean that a particular feature, structure, or characteristic described in connection with the embodiment is included in one or more embodiments of the present disclosure. Thus, appearances of the phrases in one embodiment, in some embodiments, in other embodiments, or the like in various places are not necessarily all referring to the same embodiment, but mean one or more, but not all, of the embodiments unless specifically emphasized otherwise.

In embodiments of the present invention, computer program code for carrying out operations of the present disclosure may be written in one or more programming languages, including, but not limited to, an object oriented programming language such as Java, smalltalk, C ++ and conventional procedural programming languages, such as the C programming language or similar programming languages. The program code may execute entirely on the user's computer, partly on the user's computer, as a stand-alone software package, partly on the user's computer and partly on a remote computer or entirely on the remote computer or server. In the case of a remote computer, the remote computer may be connected to the user's computer through any kind of network, including a Local Area Network (LAN) or a Wide Area Network (WAN), or may be connected to an external computer (for example, through the Internet using an Internet service provider).

The following description of the embodiments of the present invention will be made clearly and completely with reference to the accompanying drawings, in which it is apparent that the embodiments described are only some embodiments of the present invention, but not all embodiments. All other embodiments, which can be made by those skilled in the art based on the embodiments of the invention without making any inventive effort, are intended to be within the scope of the invention.

Referring to fig. 1 and 2, a flowchart of a compatibility adaptation method for UWP application outgoing management functions in an embodiment is shown, where the method includes:

step S101, the service module creates a named pipe instance and grants all UWP programs access rights to the named pipe instance by modifying an access control list of the security descriptor.

In some embodiments, as shown in fig. 3, step S101 specifically includes the following ways:

s2011, constructing ALLAPPLICATIONPACKAGES groups of security identifiers SIDs by a service module through a system function;

Step 2012, the service module fills an EXPLICIT_ACCESS structure by using the security identifier and a preset ACCESS mask to generate a legal ACCESS control item ACE;

s2013, the service module inserts the access control item into an empty self-defined 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 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 in the creation process;

And step S2017, the service module releases the memory resources occupied by the security identifier, the access control item, the custom access control list and the security descriptor.

It should be noted that, the service module builds ALLAPPLICATIONPACKAGES groups of security identifiers SIDs through the system function, verifies the format and the validity of the SIDs, ensures that the SIDs conform to the specification of the Windows system to the UWP application association group SIDs, fills the EXPLICIT_ACCESS structure by using the security identifiers and a preset ACCESS mask to generate legal ACCESS control items ACE, wherein the ACCESS mask is set according to the actual communication requirement of the UWP application to the named pipes and only comprises reading, writing and connection rights. The service module inserts the access control item into an empty self-defined access control list DACL through a system function, checks whether other hidden access control items which conflict with the ACE exist in the DACL, and carries out compatibility adjustment if the hidden access control items exist, the service module initializes a security descriptor SD, sets a version number of the SD to adapt to the current Windows system version to ensure that the SD can be correctly identified by a system security subsystem, sets the self-defined access control list as the DACL of the security descriptor, verifies whether the binding between the DACL and the SD is successful, creates a named pipeline instance, binds the security descriptor to the named pipeline instance in the creation process, tests whether the authority configuration of the named pipeline takes effect by simulating an access request of UWP application after the creation is completed, and releases memory resources occupied by the security identifier, the access control item, the self-defined access control list and the security descriptor and records a resource release state to ensure that no memory leakage exists.

It can be seen that in Windows systems, resource access is controlled by a security descriptor, and the UWP process runs in AppContainer sandboxes, which access tokens default to associate ALLAPPLICATIONPACKAGES groups of SIDs. By default, the externally created named pipe SD does not contain the access rights for the SID, resulting in inaccessible UWP. This step allows the Windows security subsystem to match to legal rights when the UWP attempts to connect the pipe by actively adding the set of allowed entries for the SIDs in the DACL of the SD. The permission control of the embodiment avoids security risk caused by excessively opening permission, and the security mechanism compatible with Windows ensures that the configuration is approved by the system to have high stability.

And step S102, the driving module sends a process starting notification to the service module when monitoring the loading event of the process main module.

In some embodiments, the driver module triggers an event when the process master module loads by registering the kernel callback function. The monitor content includes a process ID, a parent process ID, a master module path, and a process creation time. The driver encapsulates the information into a structural body through a custom IO control code, sends the structural body to the user state service module, and ensures that the notification delay is lower than a threshold value through the connection established by the device handle createFile.

It can be seen that the driver runs in the kernel layer of the system, and the bottom event created by the process can be directly monitored without being limited by the authority of the user-mode process. When the UWP process is started, the main module is loaded as a key node, and after the event is captured by the drive, information is transmitted to the service module in real time through a communication mechanism of the kernel and the user mode, so that original data is provided for the follow-up identification of the UWP process.

The method and the device realize real-time monitoring of process starting, ensure that the UWP process is brought into a control range as soon as the process is started, and avoid omission that the process is operated but not monitored. The kernel layer monitoring is not influenced by the UWP sandbox, complete process information can be obtained, and the problem of incomplete user state monitoring information is solved.

Step S103, the service module judges whether the newly started process is a UWP process, if not, the next process is waited for starting notification, and if yes, the step S104 is executed.

After the service module of the embodiment receives the process information, three layers of judgment are executed:

① Calling GetPackageFullName a function to acquire an application package name of the process, and if the return is successful and the package name format is a publisher, an application name, a version, a framework and a signature, primarily judging the package name as UWP;

② If the packet name acquisition failure checking process accesses the token, if the token contains an APP_ CONTAINER _information structure and stores AppContainerSID in a preset format, the auxiliary judgment is UWP;

③ Finally, it is checked whether the primary module path is located in the UWP default installation path and the path contains a verified package name folder.

And if none of the three layers is satisfied, judging that the UWP is not the UWP.

It should be noted that the UWP process is constrained by AppContainer sandboxes based on the application package model, and therefore necessarily has three core features, unique application package name, sandbox identity with AppContainerSID, and fixed protected installation directory. The service module realizes accurate identification of the UWP process by verifying the existence and the compliance of the features.

Step S104, the APC item of the ShellCode is contained in the main line Cheng Charu of the UWP process in an asynchronous procedure call mode, the ShellCode contains a function instruction for loading a target DLL module and executing initialization, and the target DLL module is used for intercepting a file outgoing related API.

In some embodiments, the service module first constructs a ShellCode, specifically including LdrLoadDll calls, ldrGetProcedureAddress gets InjectInit addresses, instructions to call InjectInit, and parameters such as DLL path strings and function names.

And applying for the memory with the authority of PAGE_EXECUTE_ READWRITE in the UWP process through VirtualAllocEx, calling WriteProcessMemory to write in the ShellCode, and checking that the written data hash is consistent with the original hash. When constructing the APC item, the callback function pointer points to a packet name hash of the UWP process with the additional data of the ShellCode start address. After the call QueueUserAPC inserts the APC, the main thread state is monitored through the WaitForSingleObject, and if the remindeable wait is not entered within 5 seconds, a custom event is triggered to prompt the thread state to switch.

The APC mechanism of this embodiment allows a process to insert a function to be executed into a target thread, and when the target thread calls a remindeable wait function, the APC function is preferentially executed. The UWP main thread frequently enters a remindeable waiting state in operation, and the service module utilizes the characteristic to inject an instruction for loading the DLL through the APC, so that the UWP thread actively executes the ShellCode, and the DLL loading is completed in the sandbox, thereby breaking through the limitation of the UWP on external injection.

The embodiment utilizes the execution mechanism of the UWP thread to realize injection, and prevents the UWP thread from being identified as malicious behavior by the UWP security protection. The verification mechanism of memory application and ShellCode writing ensures that the injected content is not tampered, and the security is high.

Step S105, when the user prepares the outgoing file, the DLL module injected into the UWP process is connected with the named pipe instance created by the service module, and informs the service module of the impending outgoing file.

In this embodiment, when the UWP main thread executes APC, the ShellCode calls LdrLoadDll to load the target DLL first, and if status_success is returned, the InjectInit function address is obtained through LdrGetProcedureAddress. When call InjectInit, the function execution operates as follows:

① Analyzing an import table of a file export API in the UWP process;

② Redirecting the API call to the interception function in the DLL by modifying the first 5 bytes of the function entry to a jump instruction;

③ And generating an API interception mapping table, and recording the original function address and the interception function address.

After initialization, the ShellCode calls virtual free to release the internal memory of the ShellCode, triggers the simulation file outgoing operation, and verifies whether the interception function captures the call. And if successful, returning to the STATUS_SUCCESS, otherwise, sending an error code to the service module.

After the UWP main thread of the embodiment executes the ShellCode in APC, the DLL is loaded into the process address space, becomes a part of the UWP process, and inherits its rights and memory environment. The InjectInit function modifies the API call path to enable the file outgoing operation to pass through the interception function of the DLL, thereby realizing the real-time monitoring of the operation and providing an inlet for the subsequent management and control.

The DLL of the embodiment runs in the UWP process, can directly access the API and file information in the process, and solves the problem of limited cross-process access. The verification mechanism of API interception ensures that the function is effective, and avoids the hidden trouble that the injection is successful but the interception is invalid.

Step S106, the service module judges whether the file content has a secret leakage risk or not, and if so, gives feedback of refusing to send out. If the injected DLL module receives the feedback, the corresponding API call fails.

In some embodiments, when the DLL intercepts the API, the file path, the outgoing way, the file size, and the content digest are extracted. The digital signature of the additional DLL is encrypted with AES-128 when sent through the named pipe.

After the service module in this embodiment decrypts, the content recognition sub-module compares the sensitive file Ha Xiku first, matches the sensitive information with the regular expression, and adjusts the threshold in combination with the user authority.

Alternatively, the average user matches 1 sensitive word and the administrator matches 3.

If the risk is judged, the service module generates an encrypted rejection instruction, the DLL decrypts the encrypted rejection instruction, calls SetLastError to set an error code, enables the API to return to failure, writes the operation record into LocalAppData% \Microsoft\Windows\security\ Logs, and intercepts the file from being sent out through other APIs such as WriteFile and SaveToStorage in a preset time period.

It can be seen that the injected DLL is used as a middleman for file outgoing operation, key information is transmitted to the service module after API call interception, the service module judges risk through content identification, then a pipeline feeds back an instruction, the DLL controls an API execution result according to the instruction, a closed loop for interception, judgment and execution is formed, UWP and the service module cooperate to break through sandbox limitation, and file outgoing safety control is achieved.

The mode of the embodiment combines the multidimensional content identification with the user permission to reduce misjudgment and improve the control accuracy. The encryption communication and signature verification prevent information from being stolen or tampered, accords with the data security standard, prevents users from bypassing the management and control through other APIs, and ensures the consistency of the management and control effect.

In one embodiment of the present invention, based on step S101, a possible embodiment thereof will be given below for non-limiting illustration. The step S101 specifically includes:

Step S1011, obtaining the fixed RID value corresponding to ALLAPPLICATIONPACKAGES groups through the security identifier generation tool or the predefined system constant provided by the operating system, and generating a complete SID character string by combining the identifier of the domain or the local computer, thereby ensuring the uniqueness and the system identification validity of the SID character string.

Step S1012, setting an ACE access mask according to the access requirement of the target resource.

Optionally, permission such as reading, writing and connection is allowed, and a flag bit of the ACE is configured to ensure that the ACE can definitely grant ALLAPPLICATIONPACKAGES groups of specific access permissions to named pipeline examples.

Step S1013, after initializing the empty DACL through the security descriptor operation function provided by the operating system, sequentially adding ACE to the designated position of the DACL to form a DACL structure containing the target authority rule, thereby ensuring the validity and the integrity of the DACL.

Step S1014, binding the DACL containing ACE to the security descriptor SD of the named pipe instance, setting the DACL generated in step S1013 as the main DACL of the SD by initializing the infrastructure of the security descriptor SD, and verifying the binding validity of the SD and the named pipe instance to ensure that the named pipe instance can control the access authority of the UWP application according to the SD after being created.

It can be seen that the UWP application, by default, can only access the resource objects created by itself, due to system security policy restrictions, and resources created by other processes or system components by default deny access to the UWP application.

This step utilizes the ALLAPPLICATIONPACKAGES set of SIDs predefined by the operating system to generate access control items containing the SIDs, explicitly granting them target access rights to named pipe instances. The ACE is then inserted into an empty custom access control list to form a new security descriptor SD. Finally, this SD is bound to the named pipe instance.

When the UWP application attempts to access the named pipe, the Windows security subsystem will check if the SID in its access token matches the allowed rules of the DACL in the SD, and since ALLAPPLICATIONPACKAGES sets of SIDs are already contained in the access token of the UWP application and the SD explicitly grants the set of access rights, the UWP application can successfully access the named pipe instance, solving the problem in the conventional scheme that the UWP application cannot access the non-self created resources.

In one embodiment of the present invention, based on step S1013, one possible embodiment of which will be given below as a non-limiting illustration. Step S1013 specifically includes:

Step S10131, checking the initial state of the empty self-defined access control list DACL, confirming that the default access control item without hiding is not damaged and the structure accords with the system security descriptor specification, and repairing if an implicit invalid structure exists.

Step S10132, determining the position of the ACE to be inserted in the DACL according to a preset safety priority rule, and avoiding the permission from being covered by the subsequent ACE due to position errors.

Alternatively, the security priority rule may be to deny permission over allow permission to a specific user/group over a general group.

Step S10133, after inserting the generated ACE into the designated position of the DACL, detecting whether other ACEs with the same security identifier SID as the ACE exist in the DACL, comparing the access mask if the ACEs exist, judging whether the same SID is granted permission and rejection permission at the same time, and adjusting the access mask or the position of the ACE according to the conflict type.

Step S10134, carrying out integrity verification on the DACL after the ACE is inserted, wherein the step comprises the step of checking whether the number of ACEs is consistent with the record of the head of the DACL, whether the structure of each ACE is complete, and whether the matching of an access mask and the SID accords with a system security policy, so as to ensure that the DACL can be correctly analyzed by a Windows security subsystem.

It should be noted that the custom access control list DACL is a control structure of resource access rights, and defines how the SID can access the mask to access the resource by the included access control item ACE.

Step S1013 is to reasonably embed ACE granted to UWP application access right into empty DACL, so that DACL can accurately identify ALLAPPLICATIONPACKAGES groups of SIDs and can also follow the system security priority rule, avoid permission conflict or invalid configuration, and finally ensure that the access request of UWP application is correctly allowed by the system security mechanism.

In this embodiment, unlike the operation of inserting ACE into an empty DACL in the prior art, this step performs verification on the empty DACL, eliminates residual default ACE fragments, and solves the potential problem that the empty DACL does not have to be empty. The ACE insertion location is dynamically located based on security priority, for example if additional denial of authority ACE may be added later, the current permission of authority ACE needs to be placed in a reasonable location to prevent coverage. Write adjustment is allowed and refused at the same time aiming at the same SID, thereby avoiding logic confusion of authorities, ensuring that DACL can be correctly analyzed by a system, not only giving UWP access rights, but also not destroying the basic safety boundary of resources.

In one embodiment of the present invention, based on step S103, a possible embodiment will be given below for non-limiting illustration of its specific implementation. The step S103 specifically includes:

Step S1031, obtaining basic information of a target process in the process starting notification, obtaining a process identifier PID of the target process through an OpenProcess function provided by an operating system, and further obtaining a process token handle of the process identifier PID for subsequent identity feature extraction.

Step S1032, calling GetTokenInformation a function to extract the security identifier SID in the process token, and mainly checking whether ALLAPPLICATIONPACKAGES group SID or AppContainer type SID of the UWP application exists or not and recording the integrity level of the token.

Step S1033, enumerating a module list loaded by the target process through EnumProcessModules functions, and checking whether the module list contains module characteristics of the UWP application in running.

The module features comprise Windows.UI.Xaml.dll, coreCLR.dll and the like, and whether the module features accord with UWP application sandboxed directory specifications is confirmed.

Step S1034, performing logical AND operation on the SID features extracted in the step S1032 and the module features verified in the step S1033, judging that the UWP application meets the feature requirements of the UWP application, if the SID features and the module features meet the feature requirements of the UWP application, judging that the UWP application is a target UWP process, otherwise, judging that the UWP application is a non-UWP process, and returning to the step S102 to continue monitoring.

The step identifies the UWP process through multidimensional feature cross-validation, analyzes SID through the process token, and screens out the process with the unique identifier of the UWP. Secondly, through module list verification, the process is ensured to load the UWP, and the common process misjudged as malicious counterfeit SID is avoided. The identity and behavior dual verification mechanism is formed by combining the two, so that the safety design characteristic of the UWP system is utilized, potential fraud is eliminated through the module loading characteristic, and the accuracy of process type judgment is improved.

In this embodiment, after the process handle is obtained through the OpenProcess function, the access token handle of the process may be obtained by calling OpenProcessToken the function, where the token stores the identity information and the permission policy of the process. The SID feature verification mode is that a process token based on the UWP application necessarily contains two key SIDs, namely ALLAPPLICATIONPACKAGES groups of SIDs in one type and AppContainerSID in the other type, wherein the key SIDs are used for granting the UWP application access to external resources, and the key SIDs are used for identifying that the process runs in a sandboxed environment. And obtaining TokenGroups structure through GetTokenInformation function, and traversing the SID list to verify.

In one embodiment of the present invention, based on step S104, a possible embodiment will be given below for non-limiting illustration of its specific implementation. As shown in fig. 4, step S104 specifically includes:

s1041, constructing a ShellCode by a service module, wherein the ShellCode comprises a function instruction for loading a target DLL module and executing initialization and parameters required by the function instruction;

Step S1042, the service module writes the ShellCode into the address space of the UWP process through the 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 a 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, and checks an APC queue thereof and executes a callback function in the APC item;

Step S1045, loading a target DLL module by the callback function through a system loading function, and acquiring an initialization function address of the DLL module by acquiring an export function address;

Step S1046, the callback function calls the initialization function to initialize the DLL module, wherein the initialization includes interception of the file outgoing API function.

It should be noted that, the ShellCode refers to a piece of binary code and data, which includes the complete disassembly code of a special function, and all the parameters required by the special function, and the working contents of the special function are as follows:

Loading DLL modules to be injected through LdrLoadDll;

Obtaining the address of the derived function InjectInit injected into the DLL through LdrGetProcedureAddress;

Call InjectInit initiates the injected DLL, mainly intercepting the file-outgoing API function.

Asynchronous procedure call (AsynchronousProcedureCalls, APC) is an asynchronous IO mechanism provided by the operating system, each thread maintains an APC queue, and after the thread enters a remindeable waiting state, the operating system checks whether there is an APC item in the APC queue, and if so, fetches it out and executes its bound callback function, i.e., the special function contained in the ShellCode.

The service module of this embodiment first writes all instructions for loading the DLL and necessary parameters in advance based on the self-contained ShellCode. The service module then uses the cross-process memory write function to place the ShellCode directly into the private address space of the target UWP process.

The service module calls a system asynchronous procedure call function and inserts the APC item pointing to the section of ShellCode into the APC queue of the UWP process main thread. When the UWP process main thread enters a remindeable waiting state next time, the system kernel automatically fetches the APC item and gives execution rights to the ShellCode. The ShellCode firstly calls a system loading function to load a target DLL into a memory, and then finds out an initialization function in the DLL through a mechanism for obtaining an export function address and immediately calls the initialization function. The initialization function completes the interception setting of the file outgoing related API, then the ShellCode ends and the control right is returned to the UWP main thread, and the UWP process continues to normally execute.

Step S104 does not need to create a remote thread, does not touch a dangerous API forbidden by the UWP sandbox, and can realize DLL injection by only using a legal asynchronous procedure call and memory writing mechanism of the system, so that UWP isolation limit is penetrated. The ShellCode has small volume and short execution path, and has low influence on the original logic of the UWP process. The one-time execution marking and integrity checking mechanism ensures that the injection behavior is unique and unrepeatable, and avoids the stability risk caused by multiple hooks.

In one embodiment of the present invention, based on step S105, a possible embodiment will be given below for non-limiting illustration of its specific implementation. The step S105 specifically includes:

In step S1051, when the main thread of the UWP process executes the APC item, the accessibility of the path of the target DLL module in the UWP process environment is checked through a pre-check function in the ShellCode, whether the digital signature of the DLL file accords with the trust level of the UWP application or not is checked, and if not, the loading process is terminated and the check failure reason is recorded.

Step S1052, shellCode call LdrLoadDll loads the target DLL module, monitors whether the loader of the UWP process applies additional sandbox restriction to the DLL module in the loading process, tries to avoid by adjusting the loading parameters of the DLL if the restriction exists, acquires the base address of the DLL module after loading is completed and verifies the validity of the base address.

Step S1053, after InjectInit function address is obtained through LdrGetProcedureAddress, whether the address is in the memory address range of the loaded DLL module is verified, the function is called to execute initialization, and if the memory address of the file outgoing API is detected to be not matched with the preset feature in the initialization process, the interception logic is adjusted in a self-adaptive mode.

Step S1054, after initialization is completed, the ShellCode triggers a simulated file outgoing API call, and verifies whether the injected DLL module can successfully intercept the call, if so, the memory resources occupied by the ShellCode are released, and if not, interception failure information is fed back to the service module and further instructions are waited.

It can be seen that when the main thread of the UWP process in this embodiment executes the ShellCode in the APC queue, the loader and the memory environment of the process itself are used to complete the loading of the target DLL, so that the DLL module is fused into the address space of the UWP process, and the API interception logic is triggered by calling the initialization function of the DLL, so that the call path of the file outgoing related API is redirected to the interception function in the DLL, thereby implementing real-time monitoring of the file outgoing operation. The process relies on the trust mechanism of the UWP process on the self-loading module, so that the DLL can participate in the function call flow of the process in legal identity. Loading failure due to UWP sandbox restrictions is avoided. And an API address dynamic adaptation logic is added in an initialization stage, so that the problem of compatibility of API address offset under different system versions is solved. And after loading is finished, releasing the ShellCode memory to reduce the detection risk of the UWP security mechanism, and improving the stability and environmental adaptability of the functions after DLL injection.

In one embodiment of the present invention, based on step S106, a possible embodiment will be given below for non-limiting illustration of a specific implementation thereof. The step S106 specifically includes:

Step S1061, after the injected DLL module intercepts the file outgoing related API call, collecting the context information of the file outgoing, verifying the integrity of the information in the UWP sandbox environment, and supplementing the acquisition or marking the missing item if the information is incomplete.

Step S1062, when the DLL module is connected with the named pipeline instance of the service module, the transmitted file information is encrypted through a preset lightweight encryption algorithm, and meanwhile, whether the other end of the pipeline connection is a legal service module is verified, so that the third party process is prevented from impersonating the service module to steal the information.

Step S1063, after receiving the encrypted file information, the service module decrypts and analyzes the context information sent by the file, and then performs hierarchical judgment through the content recognition sub-module.

Specifically, the type and the size of the file are rapidly screened, sensitive keywords and structured data are matched with the content of the file, and meanwhile, the judgment threshold value is adjusted by combining the user permission level for initiating the outgoing operation.

And step S1064, if the service module judges that the secret leakage risk exists, feeding back an encrypted refused outgoing instruction to the DLL module. After the DLL module decrypts the instruction and verifies the legality, the detailed information of the outgoing operation is recorded and stored in a safety log area of the UWP process besides the failure of returning the corresponding API call, and the file is prevented from being tried to be sent out again through other outgoing APIs within preset time.

The DLL module injected into the UWP process becomes an intermediate node of file issuing operation by intercepting the file issuing API, on one hand, operation details are collected and transmitted to the service module through a naming pipeline, and on the other hand, risk judgment results of the service module are received. The service module decides whether to allow the outgoing based on the content identification, and finally, the DLL module executes the allowed or refused instruction, and the UWP process and the service module cooperate to break through the limitation of the UWP sandbox on the external control, so as to realize the accurate control on the file outgoing.

It should be understood that the sequence number of each step in the foregoing embodiment does not mean that the execution sequence of each process should be determined by the function and the internal logic, and should not limit the implementation process of the embodiment of the present invention.

The following is an embodiment of a UWP application outgoing management function compatibility adapting system provided by an embodiment of the present disclosure, where the system and the UWP application outgoing management function compatibility adapting method of the foregoing embodiments belong to the same inventive concept, and details that are not described in detail in the embodiment of the UWP application outgoing management function compatibility adapting system may refer to the embodiment of the foregoing UWP application outgoing management function compatibility adapting method.

The system comprises:

The service module is used for creating a named pipeline instance and granting all UWP programs access rights to the named pipeline instance by modifying an access control list of the security descriptor;

The code injection module is used for containing an APC item of a Shellcode to a main line Cheng Charu of the UWP process in an asynchronous procedure calling mode, wherein the Shellcode contains a function instruction for loading a target DLL module and executing initialization, and the target DLL module is used for intercepting a file outgoing related API;

And the service module is used for judging whether the file content has a secret leakage risk or not, if so, giving feedback for refusing to be sent out, and if the injected DLL module receives the feedback, failing to call the corresponding API.

As shown in fig. 5, the present application further provides an electronic device, including a display module 103, a memory 102, a processor 101, and a computer program stored in the memory and capable of running on the processor 101, where the steps of the UWP application outgoing management function compatibility adaptation method are implemented by the processor 101 when the program is executed.

In embodiments of the present application, electronic devices include, but are not limited to, laptop computers, desktop computers, workstations, personal digital assistants, servers, blade servers, mainframes, and other suitable computers. The electronic device may also represent various forms of mobile devices, such as personal digital processing, cellular telephones, smartphones, wearable devices, and other similar computing devices. The components shown herein, their connections and relationships, and their functions, are meant to be exemplary only, and are not meant to limit implementations of the embodiments of the application described and/or claimed herein.

In embodiments of the present application, 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, an electronic unit designed to perform the functions described herein, and in some cases such an implementation may be implemented in a controller. For a software implementation, an embodiment such as a process or function may be implemented with a separate software module that allows for performing at least one function or operation. The software codes may be implemented by a software application (or program) written in any suitable programming language, which may be stored in memory and executed by a controller.

The display module 103 is used to display information input by a 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.

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

The present application also provides a storage medium having stored thereon a computer program which when executed by a processor implements the steps of the UWP application outgoing management function compatibility adaptation method.

A storage medium may employ any combination of one or more readable media. The readable medium may be a readable signal medium or a readable storage medium. The readable storage medium can be, for example, but is not limited to, an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or a combination of any of the foregoing. More specific examples (a non-exhaustive list) of a readable storage medium include an electrical connection having 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 disc read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the foregoing.

In a storage medium, a readable signal medium may include a data signal propagated in baseband or as part of a carrier wave, with readable program code embodied therein. Such a propagated data signal may take any of a variety of forms, including, but not limited to, electro-magnetic, optical, or any suitable combination of the foregoing. A readable signal medium may also be any readable medium that is not a readable storage medium and that can communicate, propagate, or transport a program for use by or in connection with an instruction execution system, apparatus, or device.

The previous description of the disclosed embodiments is provided to enable any person skilled in the art to make or use the present invention. Various modifications to these embodiments will be readily apparent to those skilled in the art, and the generic principles defined herein may be applied to other embodiments without departing from the spirit or scope of the invention. Thus, the present invention is not intended 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 UWP application outgoing management and control function compatibility adaptation method, characterized in that the method comprises:

2. The UWP application outgoing management function compatibility adaptation method as claimed in claim 1, characterized in that the step S101 specifically comprises:

Initializing a security descriptor;

setting the custom access control list as the DACL of the security descriptor;

3. The UWP application outgoing management function compatibility adaptation method as claimed in claim 2, characterized in that step S101 further comprises:

4. The UWP application outgoing management function compatibility adaptation method as claimed in claim 1, characterized in that step S103 specifically comprises:

integrity verification was performed on the DACL after insertion of ACE.

5. The UWP application outgoing management function compatibility adaptation method as claimed in claim 1, characterized in that the step S104 specifically comprises:

6. The UWP application outgoing management function compatibility adaptation method as claimed in claim 1, characterized in that step S105 specifically comprises:

7. The UWP application outgoing management function compatibility adaptation method as claimed in claim 1, characterized in that step S106 specifically comprises:

8. A UWP application outgoing management function compatibility adaptation system, characterized in that the system is configured to implement a UWP application outgoing management function compatibility adaptation method according to any one of the claims 1 to 7;

The system comprises:

9. An electronic device comprising a memory, a processor and a computer program stored on the memory and executable on the processor, characterized in that the steps of the UWP application outgoing management function compatibility adaptation method according to any one of the claims 1 to 7 are implemented by the processor when executing the program.

10. A storage medium having stored thereon a computer program which, when executed by a processor, implements the steps of the UWP application outgoing management function compatibility adaptation method as claimed in any one of the claims 1 to 7.