Anti-hijacking method and device for dynamic link library of application program and electronic equipment

Abstract

The invention provides an anti-hijacking method and device for a dynamic link library of an application program and electronic equipment, and the method comprises the following steps: when a source code of a target application program of a specified application program framework is packaged, storing an intermediate file of the target application program generated in a packaging process into a self-defined output directory in a packaging configuration file of a packer; acquiring a hook file address from a packing configuration file of a packer; calling a corresponding hook program according to the hook file address to call a patch program to obtain a patch file; calling a list file tool in the software development kit according to the patch file so as to change a list file in the intermediate file according to the list file tool; the patch file comprises a dynamic link library identifier of a dynamic link library for preventing hijacking; packaging the changed intermediate file into a target application program; the target application program loads the dynamic link library based on the dynamic link library identifier. According to the invention, the security of user data and an operating system is ensured.

Description

Technical Field

[0001] The present invention relates to the field of software development and application security technology, and in particular to a method, device, electronic device and storage medium for preventing a dynamic link library of an application from being hijacked. Background Art

[0002] With the continuous development of computer technology, the demand for applications is increasing. In order to improve the performance and functionality of applications, developers usually use DLL (Dynamic Link Library) to achieve code reuse and modularization. However, applications designed based on dynamic link libraries also bring potential security risks, such as DLL hijacking (dynamic link library hijacking).

[0003] Specifically, DLL hijacking refers to malware placing a malicious dynamic link library with the same name in the search path of an application, so that the malicious dynamic link library is replaced when the application loads the dynamic link library, causing security threats to user data and the operating system. Summary of the invention

[0004] In view of this, the present invention aims to propose a method, device, electronic device and storage medium for preventing the hijacking of dynamic link libraries of applications, so as to solve the problem that when dynamic link libraries are loaded by applications, they are replaced by malicious dynamic link libraries, causing security threats to user data and operating systems. The specific technical solutions are as follows:

[0005] According to a first aspect of the present invention, a method for preventing a dynamic link library of an application from being hijacked is provided, wherein the application is an application built on a specified application framework, and the specified application framework has a packager for packaging the application; the method comprises:

[0006] When packaging the source code of the target application of the specified application framework, saving the intermediate files of the target application generated in the packaging process to the custom output directory in the packaging configuration file of the packager;

[0007] Obtaining the hook file address from the packaging configuration file of the packager;

[0008] According to the hook file address, the corresponding hook program is called to call the patch program to obtain the patch file;

[0009] Calling a manifest file tool in a software development kit to modify the manifest file in the intermediate file according to the patch file; wherein the patch file includes a dynamic link library identifier for preventing the dynamic link library from being hijacked;

[0010] The modified intermediate file is packaged into a target application; wherein the target application loads the dynamic link library based on the dynamic link library identifier.

[0011] Optionally, the software development kit is a software development kit of any version of an operating system having a manifest file tool, and the directory where the manifest file tool is located is set in a list containing directory paths in the system environment variables of the operating system; the designated application framework includes the Electron framework.

[0012] Optionally, when packaging the source code of the target application of the specified application framework, before saving the intermediate files of the target application generated in the packaging process to the custom output directory in the packaging configuration file of the packager, the method further includes:

[0013] The output directory item in the packaging configuration file of the packager is modified to be a custom output directory, so that the intermediate file is saved in the custom output directory in the packaging configuration file of the packager.

[0014] Optionally, when packaging the source code of the target application of the specified application framework, before saving the intermediate files of the target application generated in the packaging process to the custom output directory in the packaging configuration file of the packager, the method further includes:

[0015] The post-packaging item in the packaging configuration file of the packager is modified to be the hook file address, so as to call the corresponding hook program according to the hook file address.

[0016] Optionally, calling a manifest file tool in a software development kit to change the manifest file in the intermediate file according to the patch file; wherein the patch file includes a dynamic link library identifier for preventing the dynamic link library from being hijacked, and changing the manifest file in the intermediate file according to the manifest file tool includes:

[0017] Calling a manifest file tool in a software development kit to modify the manifest file in the intermediate file according to the patch file; wherein the patch file includes a dynamic link library identifier for preventing the dynamic link library from being hijacked, and extracting the manifest file in the intermediate file as an independent file;

[0018] Read all the contents of the independent file into a string;

[0019] Check the current line of the patch file line by line to see whether the current line of the patch file exists in the string;

[0020] If the current line of file content exists in the string, then obtaining a specified tag in the string, and inserting the current line of file content into the position of the specified tag in the string;

[0021] After reading all the contents of the patch file, save the character string into a temporary file;

[0022] The manifest file tool is called to embed the temporary file into the intermediate file.

[0023] Optionally, the method further comprises:

[0024] A patch file is created; the file format of the patch file complies with the requirements of the manifest file of the application program of the operating system for tags.

[0025] Optionally, the dynamic link library identifier in the patch file includes the name and location of the dynamic link library.

[0026] According to a second aspect of the present invention, a dynamic link library anti-hijacking device for an application is also provided, the application is an application built based on a designated application framework, the designated application framework having a packager for packaging the application; the device includes:

[0027] The intermediate file saving module is used to save the intermediate file of the target application generated during the packaging process to a custom output directory in the packaging configuration file of the packager when packaging the source code of the target application of the specified application framework;

[0028] A hook file address acquisition module, used to obtain the hook file address from the packaging configuration file of the packager;

[0029] A patch file acquisition module, used to call the corresponding hook program to call the patch program to acquire the patch file according to the hook file address;

[0030] The manifest file change module is used to call the manifest file tool in the software development toolkit to change the manifest file in the intermediate file according to the patch file; wherein the patch file includes a dynamic link library identifier for preventing hijacked dynamic link library;

[0031] The target application packaging module is used to package the changed intermediate file into a target application; wherein the target application loads the dynamic link library based on the dynamic link library identity.

[0032] According to another aspect of the present invention, there is also provided an electronic device, comprising:

[0033] processor;

[0034] a memory for storing instructions executable by the processor;

[0035] Wherein, the processor is configured to execute the instructions to implement the dynamic link library anti-hijacking method of the application as described above.

[0036] According to another aspect of the present invention, there is also provided a readable storage medium on which a computer program is stored, and the steps of implementing the dynamic link library anti-hijacking method of the application as described above when executed by a processor are provided.

[0037] The embodiment of the present invention provides a method for preventing the dynamic link library of an application from being hijacked. The application is an application built based on a specified application framework. The specified application framework has a packager for packaging the application. When packaging the source code of the target application of the specified application framework, the intermediate file of the target application generated during the packaging process is saved in a custom output directory in the packaging configuration file of the packager. The hook file address is obtained from the packaging configuration file of the packager to call the corresponding hook program to call the patch program to obtain the patch file. Then, the manifest file tool in the software development kit can be called to change the manifest file in the intermediate file according to the dynamic link library identifier of the dynamic link library that is prevented from being hijacked in the patch file. Finally, the changed intermediate file can be packaged as a target application. The target application loads the dynamic link library based on the dynamic link library identifier. That is, when the target application loads the dynamic link library, it will only load the dynamic link library based on the dynamic link library identifier, so that malicious dynamic link libraries will not be loaded, thereby ensuring the security of user data and the operating system.

[0038] The above description is only an overview of the technical solution of the present invention. In order to more clearly understand the technical means of the present invention, it can be implemented in accordance with the contents of the specification. In order to make the above and other purposes, features and advantages of the present invention more obvious and easy to understand, the specific implementation methods of the present invention are listed below. BRIEF DESCRIPTION OF THE DRAWINGS

[0039] Various other advantages and benefits will become apparent to those of ordinary skill in the art by reading the detailed description of the preferred embodiments below. The accompanying drawings are only for the purpose of illustrating the preferred embodiments and are not to be considered as limiting the present invention. Moreover, the same reference symbols are used throughout the accompanying drawings to represent the same components. In the accompanying drawings:

[0040] Figure 1 It is a flowchart of the steps of a method for preventing a dynamic link library of an application from being hijacked provided by an embodiment of the present invention;

[0041] Figure 2This is an overall flow chart of anti-hijacking of a dynamic link library of an application provided by an embodiment of the present invention;

[0042] Figure 3 It is a structural schematic diagram of a dynamic link library anti-hijacking device for an application program provided by an embodiment of the present invention;

[0043] Figure 4 It is a structural schematic diagram of an electronic device provided by an embodiment of the present invention. DETAILED DESCRIPTION

[0044] To make the purpose, technical scheme and advantages of the embodiments of the present invention clearer, the embodiments of the present invention will be described in detail below in conjunction with the accompanying drawings. However, it will be appreciated by those skilled in the art that in the embodiments of the present invention, many technical details are proposed in order to enable the reader to better understand the present application. However, even without these technical details and various changes and modifications based on the following embodiments, the technical scheme claimed in the present application can be implemented. The division of the following embodiments is for the convenience of description, and should not constitute any limitation on the specific implementation of the present invention. The various embodiments can be combined and referenced with each other without contradiction.

[0045] In order to facilitate understanding by those skilled in the art, some terms and nouns involved in the embodiments of the present invention are explained.

[0046] Electron framework: Use JavaScript (Scripting Language, scripting language), HTML (HyperText Markup Language), and CSS (Cascading Style Sheets), etc. to build a cross-platform desktop application framework.

[0047] electron-builder (packager): A packager for applications based on the Electron framework, used to build applications and their installation packages.

[0048] DLL (Dynamic Link Library): A way to implement the concept of a shared function library in the Windows operating system, providing a method for a process to call functions that do not belong to its executable code.

[0049] DLL hijacking: hijack or replace normal DLLs through some means, tricking normal applications into loading pre-prepared malicious DLLs.

[0050] SDK (Software Development Kit): A set of tools, libraries, documentation, and sample code that helps developers create, debug, and deploy applications that run on the Windows operating system. The Windows operating system SDK contains various resources required to develop applications for the Windows operating system, including the Windows operating system API (Application Programming Interface), graphics, and other resources.

[0051] Manifests file (manifest file): A configuration file in XML (extensible markup language, Extensible MarkupLanguage) format used to describe the metadata and dependencies of an application or component. In applications in Windows operating systems, the Manifests file can specify the DL file that the application depends on and its loading location, thereby preventing DLL hijacking attacks.

[0052] In the specific implementation, the application based on the Electron framework embeds the Chromium kernel (an open source browser engine), which will be started when the application starts. The startup of the Chromium kernel will automatically load the dynamic link library (DLL) of the Windows operating system, such as powrprof.dll, wtsapi32.dll, dwmapi.dll, etc. If a malicious DLL with the same name is placed in the same directory as the application, DLL hijacking will occur, and the malicious DLL will obtain system permissions, and then the malicious DLL will access and steal sensitive data in the operating system, such as user passwords, credit card information, personal files, etc., causing security threats to user data and the operating system.

[0053] The currently known methods to prevent DLL hijacking can include: 1. When calling functions involving module loading such as LoadLibrary, LoadLibraryEx, CreateProcess, ShellExecute, etc., specify the complete path of the DLL loading; 2. Cancel the current directory from the DLL's search list; 3. Sign and verify the known DLL; 4. When compiling and building, use the method of manually changing the Manifests file for DLL redirection.

[0054] The above methods 1, 2, and 3 to prevent DLL hijacking involve rewriting the source code before or during DLL loading. For applications based on the Electron framework, DLL loading is completed by the Electron framework when the application starts, and the application developer cannot change it. Method 4 is for ordinary applications developed in Visual Studio (an integrated development environment for Windows). Applications based on the Electron framework build embedded manifests, not independent files, and the compiler builder does not provide a direct way to change them.

[0055] In view of the above problems, the embodiment of the present invention proposes a method for preventing an application based on the Electron framework from being hijacked by DLL. Specifically, the embodiment of the present invention uses the SDK tool mt.exe (manifest file tool) and the hook mechanism of electron-builder (packager) to process the intermediate file [application name].exe of the electron-builder packaged application, and finally generates an application and its installation package that can prevent being hijacked by DLL, thereby ensuring the security of user data and operating system.

[0056] Reference Figure 1 , shows a step flowchart of a dynamic link library anti-hijacking method for an application provided by an embodiment of the present invention. The application is an application built based on a designated application framework, the designated application framework having a packager for packaging the application; the method may include:

[0057] Step 101: When packaging the source code of the target application of the specified application framework, the intermediate file of the target application generated during the packaging process is saved to a custom output directory in the packaging configuration file of the packager.

[0058] Among them, the specified application framework includes the Electron framework, the packager is the electron-builder of the Electron framework, and the packaging configuration file of electron-builder is a configuration file used to define the packaging process and generate the target application and its installation package. The packaging configuration file contains various configuration options required in the packaging process, such as afterPack items (post-packaging items) and directories / output items (output directory items) and other configuration options.

[0059] In a specific example, when packaging the source code of a Windows application (target application) based on the Electron framework on a computer with a Windows operating system, the electron-builder packaging command is executed. Based on the electron-builder packaging command, the source code of the target application will be packaged, and then the target application and its installation package will be packaged. During the packaging process of the target application, an intermediate file will be generated: [application name].exe, wherein the intermediate file is used to generate the final target application and its installation package. In an embodiment of the present invention, the intermediate file of the target application generated during the packaging process can be saved in a custom output directory in the packaging configuration file of the packager.

[0060] Step 102: Obtain the hook file address from the packaging configuration file of the packager.

[0061] Step 103: Call the corresponding hook program to call the patch program to obtain the patch file according to the hook file address.

[0062] Step 104: Call the manifest file tool in the software development toolkit to change the manifest file in the intermediate file according to the patch file; wherein the patch file includes a dynamic link library identifier for preventing hijacked dynamic link library.

[0063] Among them, the manifest file tool can be mt.exe. Specifically, mt.exe is the Manifests processing tool included in the Windows SDK. It is a command line tool used to process and embed the Manifests file (manifest file) of an application, which can be used to describe the metadata and dependencies of an application or component. mt.exe can help developers embed Manifests files into executable files (such as .exe or .dll) or extract Manifests files from executable files.

[0064] In an embodiment of the present invention, patch files, patch programs and hook programs are pre-made. Specifically, the dynamic link library identifier that may include a dynamic link library (DLL) in the patch file may include information such as the name and location of the dynamic link library (loading path).

[0065] The patch program can be written in any language that can be used to write Windows programs. The patch program can use mt.exe, and then based on mt.exe, change the content of the Manifests embedded in the target application according to the content of the specified patch file (the name and location of the dynamic link library), so that the target application can load the corresponding dynamic link library based on the dynamic link library identifier, that is, the target application will not load other dynamic link libraries except the dynamic link library corresponding to the dynamic link library identifier, thereby preventing dynamic link library hijacking. The patch program can execute different or the same patches on the same target program multiple times without generating duplicate entries to cause program execution exceptions. In addition, the patch program can also update the target application in situ and can be called by hook programs or other arbitrary programs without affecting the host program flow.

[0066] The hook program is a program that can be called by electron-builder. Specifically, the function of the hook program is to call the patch program according to the patch file address to call mt.exe based on the patch program, thereby updating the intermediate file of the target application in the custom output directory of electron-builder, so that the intermediate file contains the dynamic link library identifier in the patch file. Preferably, the hook program is a js file (a text file containing JavaScript code) that can complete the aforementioned functions, and the js file will be automatically called by the packaging process of the target application. The hook program can be executed after electron-builder generates an unsigned application, without destroying the original signature process, and the final packaged application contains a normal owner signature.

[0067] In one embodiment of the present invention, a software development kit (SDK) can be a software development kit of any version of a Windows operating system having a manifest file tool (mt.ex). The directory where mt.ex is located can be set in a list (PATH) of directory paths in the system environment variables of the Windows operating system. When the Windows operating system executes a command, it searches for executable files in the order of the paths in the PATH. When a user enters a command in the command line, the Windows operating system searches for executable files corresponding to the command in the directories listed in the PATH in sequence. After the directory where mt.ex is located can be set in the PATH, the Windows operating system can be restarted to facilitate subsequent execution of related steps that require the use of mt.ex.

[0068] Step 105: Pack the modified intermediate file into a target application; wherein the target application loads the dynamic link library based on the dynamic link library identifier.

[0069] In the embodiment of the present invention, after the intermediate file of the target application is changed based on the patch file, the intermediate file may continue to be packaged to generate the target application and its installation package.

[0070] When the target application needs to use certain functions or modules provided by the dynamic link library, the corresponding dynamic link library can be loaded based on the dynamic link library identifier. Since the target application will not load dynamic link libraries other than the dynamic link library corresponding to the dynamic link library identifier, the dynamic link library corresponding to the dynamic link library identifier is a trusted dynamic link library known to the developer, and therefore can effectively prevent the dynamic link library from being replaced by a malicious dynamic link library.

[0071] In the above-mentioned method for preventing the dynamic link library of an application from being hijacked, the application is an application built based on a specified application framework, and the specified application framework has a packager for packaging the application. When packaging the source code of the target application of the specified application framework, the intermediate file of the target application generated during the packaging process is saved in a custom output directory in the packaging configuration file of the packager, and the hook file address is obtained from the packaging configuration file of the packager to call the corresponding hook program to call the patch program to obtain the patch file. Then, the manifest file tool in the software development kit can be called to change the manifest file in the intermediate file according to the dynamic link library identifier of the dynamic link library that is prevented from being hijacked in the patch file. Finally, the changed intermediate file can be packaged as a target application, and the target application loads the dynamic link library based on the dynamic link library identifier, that is, when the target application loads the dynamic link library, it will only load the dynamic link library based on the dynamic link library identifier, so that malicious dynamic link libraries will not be loaded, thereby ensuring the security of user data and the operating system.

[0072] In one embodiment of the present invention, the method may further include before saving the intermediate file of the target application generated during the packaging process into a custom output directory in the packaging configuration file of the packager when packaging the source code of the target application of the specified application framework:

[0073] The output directory item in the packaging configuration file of the packager is modified to be a custom output directory, so that the intermediate file is saved in the custom output directory in the packaging configuration file of the packager.

[0074] Among them, the directories / output item (output directory item) in the packaging configuration file of electron-builder (packager) is used to specify the output directory after the files of the packaged target application are packaged. Specifically, electron-builder generates intermediate files ([application name].exe) and the final installation package in the specified output directory. In the embodiment of the present invention, by modifying the directories / output item, electron-builder can be specified to output the packaged files (intermediate files) to the custom output directory.

[0075] In one embodiment of the present invention, when packaging the source code of the target application of the specified application framework, before saving the intermediate files of the target application generated in the packaging process to the custom output directory in the packaging configuration file of the packager, the method further includes:

[0076] The post-packaging item in the packaging configuration file of the packager is modified to be the hook file address, so as to call the corresponding hook program according to the hook file address.

[0077] Among them, the afterPack item in the packaging configuration file of electron-builder (packager) is used to execute custom scripts or operations after the electron-builder packaging process is completed. For example, the hook program pre-made by the present invention, based on the hook program, developers can perform some additional processing after the packaging is completed, such as updating the Manifests file, signing the application, compressing the file, etc.

[0078] In an embodiment of the present invention, by modifying the afterPack item in the electron-builder packaging configuration file, modifying the afterPack item in the electron-builder packaging configuration file refers to modifying the value of the afterPack item to the hook file address of the hook program, so that electron-builder can call the hook file based on the hook file address.

[0079] In the above embodiment, the afterPack item in the electron-builder packaging configuration file is modified. Modifying the afterPack item in the electron-builder packaging configuration file is to modify the configuration file that can be packaged and specified, so that afterPack points to the hook program, and then the hook program can be executed at the right time.

[0080] In one embodiment of the invention, the manifest file tool in the software development tool kit is called to change the manifest file in the intermediate file according to the patch file; wherein the patch file includes a dynamic link library identifier for preventing hijacked dynamic link library to change the manifest file in the intermediate file according to the manifest file tool, including:

[0081] Calling a manifest file tool in a software development kit to modify the manifest file in the intermediate file according to the patch file; wherein the patch file includes a dynamic link library identifier for preventing the dynamic link library from being hijacked, and extracting the manifest file in the intermediate file as an independent file;

[0082] Read all the contents of the independent file into a string;

[0083] Check the current line of the patch file line by line to see whether the current line of the patch file exists in the string;

[0084] If the current line of file content exists in the string, then obtaining a specified tag in the string, and inserting the current line of file content into the position of the specified tag in the string;

[0085] After reading all the contents of the patch file, save the character string into a temporary file;

[0086] The manifest file tool is called to embed the temporary file into the intermediate file.

[0087] In an embodiment of the present invention, the patch program execution steps are: calling mt.exe (manifest file tool) to extract the Manifests file in the specified application as an independent file; reading all the contents of the independent file into a string; reading the patch file content line by line to obtain the current line file content, and for each line of the current line file content, finding whether it exists in the string, if it exists in the string, continue to process the next line, if it does not exist in the string, find the position in the string, insert the current line file content into the specified tag (position) of the string, and continue to process the next line until all lines in the patch file are processed; 3 The processed string is stored in a temporary file. Finally, mt.exe can be called to embed the temporary file into the intermediate file of the target application. In this way, the intermediate file will include the content in the patch file, that is, the dynamic link library identifier of the dynamic link library that is prevented from being hijacked.

[0088] In one embodiment of the present invention, the method may further include:

[0089] A patch file is created; the file format of the patch file complies with the requirements of the manifest file of the application program of the operating system for tags.

[0090] In the embodiment of the present invention, making a patch file, making a patch file refers to manually creating a patch file. The contents in the patch file list the names and locations of the dynamic link library that need to be prevented from being hijacked. At the same time, it is also necessary to ensure that the file format of the patch file complies with the Windows program Manifests format. <file>The requirements of the tag. Therefore, the relevant information of the dynamic link library of the intermediate file of the target application can be changed based on the patch file, so that after the changed intermediate file is packaged as the target application, when the subsequent target application loads the dynamic link library, it will only load the dynamic link library based on the dynamic link library identifier, so that malicious dynamic link libraries will not be loaded, thereby ensuring the security of user data and operating system. It should be noted that the content of the patch file can be flexibly expanded and can be easily written into the embedded Manifests file in the Exe file (executable file) to prevent any known system dynamic link library from being hijacked.

[0091] In a specific example, the patch file content may include:

[0092] <filename=

[0093] "powrprof.dll" loadFrom="%SystemRoot%\system32\powrprof.dll">< / file>

[0094] <filename=

[0095] "wtsapi32.dll" loadFrom="%SystemRoot%\system32\wtsapi32.dll">

[0096] <filename=

[0097] "dwmapi.dll" loadFrom="%SystemRoot%\system32\dwmapi.dll">

[0098] In the above example, the patch file content may include but is not limited to <file>Tags, by using <file>The tag can specify the name and location of the DLL.

[0099] In order to enable those skilled in the art to better understand the embodiments of the present invention, a complete process is used below to illustrate the specific process of dynamic link library anti-hijacking in the embodiments of the present invention.

[0100] The embodiment of the present invention proposes a method for preventing a program based on the Electron framework from being hijacked by DLL. The embodiment of the present invention uses the tool mt.exe and the hook mechanism of electron-builder to process the intermediate file [application name].exe packaged by electron-builder, and finally generates an application and its installation package that can prevent the application from being hijacked by DLL. Figure 2 , is an overall flow chart of anti-hijacking of a dynamic link library (DLL) of an application provided by an embodiment of the present invention, and the main process steps may include:

[0101] Step 201, creating a patch file, wherein the content in the patch file specifies the name and location (system directory) of a specific system DLL that can be hijacked;

[0102] Step 202: prepare the tool mt.exe, where mt.exe refers to a tool for processing Manifests files in Windows SDK;

[0103] Step 203, write a patch program that can use the mt.exe in step 202 to replace the Manifests content embedded in the target exe file (intermediate file);

[0104] Step 204, modify the directories / output item in the electron-builder packaging configuration file to a custom output directory;

[0105] Step 205, write a hook program that can be called by electron-builder, the hook program brings the patch file address in step 201 to call the patch program in step 203, and updates the intermediate file in the custom output directory in step 204: [application name].exe;

[0106] Step 206, modify the afterPack item in the packaging configuration file of electron-builder to point to the hook program in step 205;

[0107] Step 207, executing the electron-builder packaging command, and obtaining the installation package of the target application after success can prevent the DLL listed in the patch file from being hijacked.

[0108] The embodiments of the present invention can solve the technical problem that conventional anti-DLL hijacking methods are not applicable to applications based on the Electron framework, thereby preventing applications based on the Electron framework from being hijacked by DLL, so that malicious dynamic link libraries will not be loaded, thereby ensuring the security of user data and the operating system.

[0109] Reference Figure 3 , shows a schematic diagram of the structure of a dynamic link library anti-hijacking device for an application provided by an embodiment of the present invention, wherein the application is an application built on a specified application framework, and the specified application framework has a packager for packaging the application; the device comprises:

[0110] The intermediate file saving module 301 is used to save the intermediate files of the target application generated in the packaging process to the custom output directory in the packaging configuration file of the packager when packaging the source code of the target application of the specified application framework;

[0111] A hook file address acquisition module 302, used to acquire the hook file address from the packaging configuration file of the packager;

[0112] The patch file acquisition module 303 is used to call the corresponding hook program to call the patch program to obtain the patch file according to the hook file address;

[0113] A manifest file changing module 304 is used to call a manifest file tool in a software development kit to change the manifest file in the intermediate file according to the patch file; wherein the patch file includes a dynamic link library identifier for preventing the dynamic link library from being hijacked;

[0114] The target application packaging module 305 is used to package the modified intermediate file into a target application; wherein the target application loads the dynamic link library based on the dynamic link library identifier.

[0115] In one embodiment of the present invention, the software development kit is a software development kit of any version of an operating system having a manifest file tool, and the directory where the manifest file tool is located is set in a list containing directory paths in the system environment variables of the operating system; the designated application framework includes the Electron framework.

[0116] In one embodiment of the present invention, the device further includes: a modification module, configured to:

[0117] The output directory item in the packaging configuration file of the packager is modified to be a custom output directory, so that the intermediate file is saved in the custom output directory in the packaging configuration file of the packager.

[0118] In one embodiment of the present invention, the device further includes: a modification module, configured to:

[0119] The post-packaging item in the packaging configuration file of the packager is modified to be the hook file address, so as to call the corresponding hook program according to the hook file address.

[0120] In one embodiment of the present invention, the manifest file modification module 304 is used to:

[0121] Calling a manifest file tool in a software development kit to modify the manifest file in the intermediate file according to the patch file; wherein the patch file includes a dynamic link library identifier for preventing the dynamic link library from being hijacked, and extracting the manifest file in the intermediate file as an independent file;

[0122] Read all the contents of the independent file into a string;

[0123] Check the current line of the patch file line by line to see whether the current line of the patch file exists in the string;

[0124] If the current line of file content exists in the string, then obtaining a specified tag in the string, and inserting the current line of file content into the position of the specified tag in the string;

[0125] After reading all the contents of the patch file, save the character string into a temporary file;

[0126] The manifest file tool is called to embed the temporary file into the intermediate file.

[0127] In an embodiment of the present invention, the device further comprises: a patch file making module, which is used to:

[0128] A patch file is created; the file format of the patch file complies with the requirements of the manifest file of the application program of the operating system for tags.

[0129] In an embodiment of the present invention, the dynamic link library identifier in the patch file includes the name and location of the dynamic link library.

[0130] The embodiment of the present invention provides a method for preventing the dynamic link library of an application from being hijacked. The application is an application built based on a specified application framework. The specified application framework has a packager for packaging the application. When packaging the source code of the target application of the specified application framework, the intermediate file of the target application generated during the packaging process is saved in a custom output directory in the packaging configuration file of the packager. The hook file address is obtained from the packaging configuration file of the packager to call the corresponding hook program to call the patch program to obtain the patch file. Then, the manifest file tool in the software development kit can be called to change the manifest file in the intermediate file according to the dynamic link library identifier of the dynamic link library that is prevented from being hijacked in the patch file. Finally, the changed intermediate file can be packaged as a target application. The target application loads the dynamic link library based on the dynamic link library identifier. That is, when the target application loads the dynamic link library, it will only load the dynamic link library based on the dynamic link library identifier, so that malicious dynamic link libraries will not be loaded, thereby ensuring the security of user data and the operating system.

[0131] As for the device embodiment, since it is basically similar to the method embodiment, the description is relatively simple, and the relevant parts can be referred to the partial description of the method embodiment.

[0132] Reference Figure 4 , shows an electronic device provided by an embodiment of the present invention, comprising: a processor; a memory for storing instructions executable by the processor; wherein the processor is configured to execute the instructions to implement a method for preventing the dynamic link library from hijacking any application.

[0133] Figure 4 4 is a block diagram of an electronic device 400 according to an exemplary embodiment. For example, the electronic device 400 may be a mobile phone, a computer, a digital broadcast terminal, a messaging device, a game console, a tablet device, a medical device, a fitness device, a personal digital assistant, etc.

[0134] Reference Figure 4 , the electronic device 400 may include one or more of the following components: a processing component 402 , a memory 404 , a power component 406 , a multimedia component 408 , an audio component 410 , an input / output interface 412 , a sensor component 414 , and a communication component 416 .

[0135] The processing component 402 generally controls the overall operation of the device 400, such as operations associated with display, phone calls, data communications, camera operations, and recording operations. The processing component 402 may include one or more processors 420 to execute instructions to complete all or part of the steps of the above-mentioned method. In addition, the processing component 402 may include one or more modules to facilitate the interaction between the processing component 402 and other components. For example, the processing component 402 may include a multimedia module to facilitate the interaction between the multimedia component 408 and the processing component 402.

[0136] The memory 404 is configured to store various types of data to support operations on the device 400. Examples of such data include instructions for any application or method operating on the device 400, contact data, phone book data, messages, pictures, videos, etc. The memory 404 can be implemented by any type of volatile or non-volatile storage device or a combination thereof, such as static random access memory (SRAM), electrically erasable programmable read-only memory (EEPROM), erasable programmable read-only memory (EPROM), programmable read-only memory (PROM), read-only memory (ROM), magnetic memory, flash memory, magnetic disk or optical disk.

[0137] The power supply component 406 provides power to the various components of the electronic device 400. The power supply component 406 may include a power management system, one or more power supplies, and other components associated with generating, managing, and distributing power to the electronic device 400.

[0138] The multimedia component 408 includes a screen that provides an output interface between the electronic device 400 and the user. In some embodiments, the screen may include a liquid crystal display (LCD) and a touch panel (TP). If the screen includes a touch panel, the screen may be implemented as a touch screen to receive input signals from the user. The touch panel includes one or more touch sensors to sense touch, slide, and gestures on the touch panel. The touch sensor may not only sense the boundaries of the touch or slide action, but also detect the duration and pressure associated with the touch or slide operation. In some embodiments, the multimedia component 408 includes a front camera and / or a rear camera. When the electronic device 400 is in an operating mode, such as a shooting mode or a video mode, the front camera and / or the rear camera may receive external multimedia data. Each front camera and the rear camera may be a fixed optical lens system or have a focal length and optical zoom capability.

[0139] The audio component 410 is configured to output and / or input audio signals. For example, the audio component 410 includes a microphone (MIC), and when the electronic device 400 is in an operating mode, such as a call mode, a recording mode, and a voice recognition mode, the microphone is configured to receive an external audio signal. The received audio signal can be further stored in the memory 404 or sent via the communication component 416. In some embodiments, the audio component 410 also includes a speaker for outputting audio signals.

[0140] The input / output interface 412 provides an interface between the processing component 402 and the peripheral interface modules, which may be keyboards, click wheels, buttons, etc. These buttons may include but are not limited to: a home button, a volume button, a start button, and a lock button.

[0141] The sensor assembly 414 includes one or more sensors for providing various aspects of status assessment for the electronic device 400. For example, the sensor assembly 414 can detect the open / closed state of the electronic device 400, the relative positioning of the components, such as the display and keypad of the electronic device 400, and the sensor assembly 414 can also detect the position change of the electronic device 400 or a component of the electronic device 400, the presence or absence of contact between the user and the electronic device 400, the orientation or acceleration / deceleration of the electronic device 400, and the temperature change of the electronic device 400. The sensor assembly 414 may include a proximity sensor configured to detect the presence of nearby objects without any physical contact. The sensor assembly 414 may also include an optical sensor, such as a CMOS or CCD image sensor, for use in imaging applications. In some embodiments, the sensor assembly 414 may also include an acceleration sensor, a gyroscope sensor, a magnetic sensor, a pressure sensor, or a temperature sensor.

[0142] The communication component 416 is configured to facilitate wired or wireless communication between the electronic device 400 and other devices. The electronic device 400 can access a wireless network based on a communication standard, such as WiFi, a carrier network (such as 2G, 4G, 4G or 5G), or a combination thereof. In an exemplary embodiment, the communication component 416 receives a broadcast signal or broadcast-related information from an external broadcast management system via a broadcast channel. In an exemplary embodiment, the communication component 416 also includes a near field communication (NFC) module to facilitate short-range communication. For example, the NFC module can be implemented based on radio frequency identification (RFID) technology, infrared data association (IrDA) technology, ultra-wideband (UWB) technology, Bluetooth (BT) technology and other technologies.

[0143] In an exemplary embodiment, the electronic device 400 may be implemented by one or more application-specific integrated circuits (ASICs), digital signal processors (DSPs), digital signal processing devices (DSPDs), programmable logic devices (PLDs), field programmable gate arrays (FPGAs), controllers, microcontrollers, microprocessors, or other electronic components to perform the above methods.

[0144] In an exemplary embodiment, a non-transitory computer-readable storage medium including instructions is also provided, such as a memory 404 including instructions, and the instructions can be executed by a processor 420 of an electronic device 400 to perform the above method. For example, the non-transitory computer-readable storage medium can be a ROM, a random access memory (RAM), a CD-ROM, a magnetic tape, a floppy disk, an optical data storage device, etc.

[0145] In the above embodiments, it can be implemented in whole or in part by software, hardware, firmware or any combination thereof. When implemented by software, it can be implemented in whole or in part in the form of a computer program product. The computer program product includes one or more computer instructions. When the computer program instructions are loaded and executed on a computer, the process or function described in the embodiment of the present invention is generated in whole or in part. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions can be stored in a computer-readable storage medium, or transmitted from one computer-readable storage medium to another computer-readable storage medium. For example, the computer instructions can be transmitted from a website site, computer, server or data center to another website site, computer, server or data center by wired (e.g., coaxial cable, optical fiber, digital subscriber line (DSL)) or wireless (e.g., infrared, wireless, microwave, etc.). The computer-readable storage medium can be any available medium that a computer can access or a data storage device such as a server or data center that includes one or more available media integrated. The available medium can be a magnetic medium (e.g., a floppy disk, a hard disk, a tape), an optical medium (e.g., a DVD), or a semiconductor medium (e.g., a solid-state hard disk Solid State Disk (SSD)), etc.

[0146] It should be noted that, in this article, relational terms such as first and second, etc. are only used to distinguish one entity or operation from another entity or operation, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Moreover, the terms "comprise", "include" or any other variants thereof are intended to cover non-exclusive inclusion, so that a process, method, article or device including a series of elements includes not only those elements, but also other elements not explicitly listed, or also includes elements inherent to such process, method, article or device. In the absence of further restrictions, an element defined by the sentence "comprises a ..." does not exclude the presence of other identical elements in the process, method, article or device including the element.

[0147] Each embodiment in this specification is described in a related manner, and the same or similar parts between the embodiments can be referred to each other, and each embodiment focuses on the differences from other embodiments. In particular, for the system embodiment, since it is basically similar to the method embodiment, the description is relatively simple, and the relevant parts can be referred to the partial description of the method embodiment.

[0148] The above description is only a preferred embodiment of the present invention and is not intended to limit the protection scope of the present invention. Any modification, equivalent replacement, improvement, etc. made within the spirit and principle of the present invention are included in the protection scope of the present invention.< / file> < / file>

Claims

1. A method for preventing a dynamic link library of an application from being hijacked, characterized in that: The application is an application built on a specified application framework, and the specified application framework has a packager for packaging the application; the method comprises: When packaging the source code of the target application of the specified application framework, saving the intermediate files of the target application generated in the packaging process to the custom output directory in the packaging configuration file of the packager; Obtaining the hook file address from the packaging configuration file of the packager; According to the hook file address, the corresponding hook program is called to call the patch program to obtain the patch file; Calling a manifest file tool in a software development kit to modify the manifest file in the intermediate file according to the patch file; wherein the patch file includes a dynamic link library identifier for preventing the dynamic link library from being hijacked; The modified intermediate file is packaged into a target application; wherein the target application loads the dynamic link library based on the dynamic link library identifier.

2. The method according to claim 1, characterized in that The software development kit is a software development kit of any version of an operating system with a manifest file tool, and the directory where the manifest file tool is located is set in a list containing directory paths in the system environment variables of the operating system; the designated application framework includes the Electron framework.

3. The method according to claim 1, characterized in that When packaging the source code of the target application of the specified application framework, before saving the intermediate files of the target application generated in the packaging process to the custom output directory in the packaging configuration file of the packager, the method further includes: The output directory item in the packaging configuration file of the packager is modified to be a custom output directory, so that the intermediate file is saved in the custom output directory in the packaging configuration file of the packager.

4. The method according to claim 1, characterized in that: When packaging the source code of the target application of the specified application framework, before saving the intermediate files of the target application generated in the packaging process to the custom output directory in the packaging configuration file of the packager, the method further includes: The post-packaging item in the packaging configuration file of the packager is modified to be the hook file address, so as to call the corresponding hook program according to the hook file address.

5. The method according to claim 1, characterized in that: Calling a manifest file tool in a software development kit to change the manifest file in the intermediate file according to the patch file; wherein the patch file includes a dynamic link library identifier for preventing the dynamic link library from being hijacked, and changing the manifest file in the intermediate file according to the manifest file tool, including: Calling a manifest file tool in a software development kit to modify the manifest file in the intermediate file according to the patch file; wherein the patch file includes a dynamic link library identifier for preventing the dynamic link library from being hijacked, and extracting the manifest file in the intermediate file as an independent file; Read all the contents of the independent file into a string; Check the current line of the patch file line by line to see whether the current line of the patch file exists in the string; If the current line of file content exists in the string, then obtaining a specified tag in the string, and inserting the current line of file content into the position of the specified tag in the string; After reading all the contents of the patch file, save the character string into a temporary file; The manifest file tool is called to embed the temporary file into the intermediate file.

6. The method according to claim 5, characterized in that The method further comprises: A patch file is created; the file format of the patch file complies with the requirements of the manifest file of the application program of the operating system for tags.

7. The method according to claim 6, characterized in that The dynamic link library identifier in the patch file includes the name and location of the dynamic link library.

8. A device for preventing hijacking of a dynamic link library of an application, characterized in that: The application is an application built on a specified application framework, and the specified application framework has a packager for packaging the application; the device comprises: An intermediate file saving module, used to save the intermediate files of the target application generated during the packaging process to a custom output directory in the packaging configuration file of the packager when packaging the source code of the target application of the specified application framework; A hook file address acquisition module, used to obtain the hook file address from the packaging configuration file of the packager; A patch file acquisition module, used to call the corresponding hook program to call the patch program to acquire the patch file according to the hook file address; A manifest file changing module, used for calling a manifest file tool in a software development kit to change the manifest file in the intermediate file according to the patch file; wherein the patch file includes a dynamic link library identifier for preventing the dynamic link library from being hijacked; The target application packaging module is used to package the modified intermediate file into a target application; wherein the target application loads the dynamic link library based on the dynamic link library identifier.

9. An electronic device, characterized in that: include: processor; a memory for storing processor-executable instructions; The processor is configured to execute the instructions to implement the method for preventing the dynamic link library of an application program from being hijacked as described in any one of claims 1 to 7.

10. A readable storage medium, characterized in that: The readable storage medium stores a computer program, and when the computer program is executed by a processor, the method for preventing the dynamic link library of an application program from being hijacked as claimed in any one of claims 1 to 7 is implemented.

Images