A method and device for securely transmitting whitelist information of an application

Abstract

The present invention discloses a method and device for securely transmitting whitelist information of an application, wherein the method comprises: loading a startup module of the application according to a startup part of the application; loading a non-startup module of the application according to a preset loading order in the startup module to obtain whitelist information; synchronizing and encrypting the module name and data information to a preset first memory interval and a preset second memory interval in a clipboard to obtain a first cache data block and a second cache data block; wherein the first memory interval is smaller than the data volume of the module name, and the second memory interval is smaller than the data volume of the data information; when the first memory interval reaches the cache upper limit, the first cache data block is sent to a server and / or saved to a disk; when the second memory interval reaches the cache upper limit, the second cache data block is sent to a server and / or saved to a disk. The present invention improves the security of whitelist information transmission.

Description

Technical Field

[0001] The present invention relates to the field of computer technology, and in particular to a method and device for securely transmitting whitelist information of an application program. Background Art

[0002] In existing client programs, such as applications, game programs, or security software, there are some security mechanisms to protect the security of their own programs and prevent damage from virus programs or "plug-in" programs. Virus programs or "plug-in" programs will have a memory space in the program to store the code or data they execute. The existing client program itself will also do some detection, so whether it is detecting data, detecting code, or reporting results, it is necessary to exclude normal memory addresses to reduce the amount of data detected and improve efficiency. Then usually the client will design a whitelist to exclude the targets on the whitelist and detect the targets that are not on the whitelist.

[0003] However, the current whitelist data transmission design is too simple, so that some "plug-in" programs or virus programs can easily put themselves into the whitelist to bypass detection, and the detection security is low. Summary of the invention

[0004] In view of the above problems, the present invention proposes a method and device for securely transmitting whitelist information of an application, which solves the problem that the existing data transmission design of new whitelist information is too simple, and that "plug-in" programs or virus programs can easily put themselves into the whitelist information to bypass detection, thereby improving the security of transmission detection.

[0005] In the first aspect, the present application provides the following technical solutions through an embodiment of the present application:

[0006] A method for securely transmitting whitelist information of an application, comprising:

[0007] Obtaining a preset loading order between non-startup modules of an application, and loading the startup module of the application according to the startup part of the application; wherein the loading order is saved in a loading order table, the loading order table is stored in the startup module, and the loading order table is constructed based on the dependency order between the non-startup modules;

[0008] According to the loading order in the startup module, the non-startup module is loaded to obtain whitelist information; wherein the whitelist information includes module name and data information;

[0009] The module name and the data information are synchronously encrypted and cached to a preset first memory interval and a preset second memory interval in the clipboard, respectively, to obtain a first cache data block and a second cache data block; wherein the first memory interval is smaller than the data size of the module name, and the second memory interval is smaller than the data size of the data information;

[0010] When the first memory interval reaches the cache upper limit, the first cache data block is sent to the server and / or saved to the disk;

[0011] When the second memory interval reaches the cache upper limit, the second cache data block is sent to the server and / or saved to a disk.

[0012] Optionally, the data information includes a memory address and version information; and the loading of the non-startup module according to a loading order preset in the startup module to obtain the whitelist information includes:

[0013] According to the loading order, the non-startup modules are loaded one by one;

[0014] Each time a non-startup module is loaded, the startup module records the memory address corresponding to the preset whitelist mark in the non-startup module;

[0015] The module name, memory address and version information corresponding to the non-startup module are exported through the export interface to obtain whitelist data; until the whitelist data corresponding to all non-startup modules are obtained;

[0016] The whitelist information is obtained according to the whitelist data corresponding to all the non-startup modules.

[0017] Optionally, after exporting the module name, memory address and version information corresponding to the non-startup module through the export interface, the method further includes:

[0018] Determine whether the non-startup module generates a signal of a global semaphore; wherein the signal of the global semaphore is used to determine whether the memory address of the non-startup module is exported;

[0019] If a semaphore signal is generated, the program function of the non-startup module is executed.

[0020] Optionally, the step of synchronously encrypting and caching the module name and the data information to a preset first memory interval and a preset second memory interval in a clipboard to obtain a first cache data block and a second cache data block includes:

[0021] Allocate the first memory interval and the second memory interval on the clipboard according to the GlobalAlloc() function;

[0022] According to the GlobalLock() function, determine a first address for writing data in the first memory interval and a second address for writing data in the second memory interval;

[0023] According to the first address, the second address and the preset encryption function EncryptBuff(size_tsize, EncryptBuff*otherbuff), the module name and the data are encrypted and written to the clipboard respectively to obtain the first cache data block and the second cache data block; wherein size_t represents the size of the first memory interval, size represents the size of the second memory interval, EncryptBuff* represents the first memory interval, and otherbuff represents the second memory interval.

[0024] Optionally, the step of encrypting and writing the module name and the data into the clipboard to obtain the first cache data block and the second cache data block comprises:

[0025] When the module name is cached in the first memory interval, the variable value of the current static variable is added to the cached module name to obtain the first cache data;

[0026] When the data information is cached in the second memory interval, the variable value of the current static variable is added to the cached data information to obtain the second cache data; wherein the static variable is used to uniquely identify the first cache data and the second cache data.

[0027] Optionally, when the module name is cached in the first memory interval, adding the variable value of the current static variable to the cached module name includes:

[0028] According to Static atomic <uint32>id, construct a static variable; where id is a static variable;

[0029] According to atomic <uint32>currid, build member variables; where currid is a member variable used to record the variable value of the current static variable;

[0030] When the module name is cached in the first memory interval, the member variable is used to record the variable value of the current static variable;

[0031] The variable value of the current static variable of the member variable record is added to the cached module name.

[0032] Optionally, when the first memory interval reaches a cache upper limit, sending the first cache data block to a server and / or saving it to a disk includes:

[0033] Determine whether the first memory interval reaches the cache upper limit through the Bool overflow() interface;

[0034] If the first memory interval reaches the cache upper limit, the IO layer is notified to send the first cache data block to the server and / or save it to the disk.

[0035] Optionally, after sending the first cache data block and the second cache data block to the server, a whitelist information detection step is further included; the server stores historical list information, and the whitelist information detection step includes:

[0036] Obtaining the module name, memory address and version information in the whitelist information according to the first cache data block and the second cache data block;

[0037] According to the module name and the version information, comparing whether the number of memory addresses corresponding to the module name in the whitelist information and the historical list information is the same;

[0038] If they are the same, comparing the memory address corresponding to the module name in the whitelist information with that in the historical list information based on the starting address and relative offset corresponding to the module name to see if they match;

[0039] If they match, it is determined that the whitelist information is legal.

[0040] In the second aspect, based on the same inventive concept, the present application provides the following technical solution through an embodiment of the present application:

[0041] A device for securely transmitting whitelist information of an application program, comprising:

[0042] A loading module, used to obtain a preset loading order between non-startup modules of an application, and load the startup module of the application according to the startup part of the application; wherein the loading order is saved in a loading order table, the loading order table is stored in the startup module, and the loading order table is constructed based on the dependency order between the non-startup modules;

[0043] A whitelist information acquisition module, used to load the non-startup module according to the loading order in the startup module to obtain whitelist information; wherein the whitelist information includes module name and data information;

[0044] A clipboard cache module, used to synchronously encrypt and cache the module name and the data information to a preset first memory interval and a preset second memory interval in the clipboard, respectively, to obtain a first cache data block and a second cache data block; wherein the first memory interval is smaller than the data size of the module name, and the second memory interval is smaller than the data size of the data information;

[0045] A first cache processing module, configured to send the first cache data block to a server and / or save it to a disk when the first memory interval reaches a cache upper limit;

[0046] The second cache processing module sends the second cache data block to the server and / or saves it to a disk when the second memory interval reaches the cache upper limit.

[0047] In the third aspect, based on the same inventive concept, the present application provides the following technical solution through an embodiment of the present application:

[0048] A computer-readable storage medium stores a computer program, which, when executed by a processor, implements the steps of any one of the methods described in the first aspect above.

[0049] The present embodiment provides a method and device for secure transmission of whitelist information of an application. The method first obtains the preset loading order between the non-startup modules of the application, and loads the startup module of the application according to the startup part of the application; wherein the loading order is stored in a loading order table, the loading order table is stored in the startup module, and the loading order table is constructed based on the dependency order between the non-startup modules; then, according to the preset loading order in the startup module, the non-startup modules of the application are loaded to obtain whitelist information; wherein the whitelist information includes module names and data information; loading according to the preset loading order can ensure that the whitelist information has higher efficiency in the transmission cache process. Then, during the cache process, the module name and data information are synchronized and encrypted and cached to the preset first memory interval and the preset second memory interval in the clipboard, respectively, to obtain the first cache data block and the second cache data block; wherein the first memory interval is smaller than the data volume of the module name, and the second memory interval is smaller than the data volume of the data information. Since the clipboard is used for inter-process communication, the present embodiment cleverly uses it as a memory buffer, which can play the role of concealing the whitelist; further, since the module name and data information of the whitelist information are cached in two memory intervals respectively during the clipboard caching process, it can be avoided that the attacker cannot obtain the two parts of the content at the same time, and the whitelist information cannot be completely stored in the first memory interval and the second memory interval. Each time the memory area is cached, only part of the data is stored, so each encrypted cache data block is not a complete information. Thus, the security of the whitelist information is guaranteed. Finally, when the first memory interval reaches the cache upper limit, the first cache data block is sent to the server and / or saved to the disk; when the second memory interval reaches the cache upper limit, the second cache data block is sent to the server and / or saved to the disk. The present invention solves the problem that the existing data transmission design of the new whitelist information is too simple, and the "plug-in" program or virus program can easily put itself into the whitelist information to bypass detection, thereby improving the security of transmission and detection.

[0050] 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 according to 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

[0051] 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:

[0052] Figure 1 A flowchart of a method for securely transmitting whitelist information of an application program provided by a first embodiment of the present invention is shown;

[0053] Figure 2 A schematic diagram of the functional module structure of a device for securely transmitting whitelist information of an application provided in a second embodiment of the present invention is shown. DETAILED DESCRIPTION

[0054] The exemplary embodiments of the present disclosure will be described in more detail below with reference to the accompanying drawings. Although the exemplary embodiments of the present disclosure are shown in the accompanying drawings, it should be understood that the present disclosure can be implemented in various forms and should not be limited by the embodiments set forth herein. On the contrary, these embodiments are provided to enable a more thorough understanding of the present disclosure and to fully convey the scope of the present disclosure to those skilled in the art.

[0055] First embodiment

[0056] See also Figure 1 , shows a flow chart of a method for securely transmitting whitelist information of an application provided by a first embodiment of the present invention. The method comprises:

[0057] Step S10: obtaining a preset loading order between non-startup modules of the application, and loading the startup module of the application according to the startup part of the application; wherein the loading order is saved in a loading order table, the loading order table is stored in the startup module, and the loading order table is constructed based on the dependency order between the non-startup modules;

[0058] Step S20: loading the non-startup module according to the loading order in the startup module to obtain whitelist information; wherein the whitelist information includes module name and data information;

[0059] Step S30: The module name and the data information are synchronously encrypted and cached to a preset first memory interval and a preset second memory interval in the clipboard, respectively, to obtain a first cache data block and a second cache data block; wherein the first memory interval is smaller than the data size of the module name, and the second memory interval is smaller than the data size of the data information;

[0060] Step S40: When the first memory interval reaches the cache upper limit, the first cache data block is sent to the server and / or saved to the disk;

[0061] Step S50: When the second memory interval reaches the cache upper limit, the second cache data block is sent to the server and / or saved to the disk.

[0062] In this embodiment, steps S10-S50 can realize more secure transmission of whitelist information, thereby preventing malicious programs or "plug-in" programs from adding themselves to the whitelist information.

[0063] Step S10: loading the startup module of the application according to the startup part of the application.

[0064] In step S10, the application is divided into a startup part and other components loaded except itself. Specifically, the startup part can be set to load the startup module with a random base address each time, so as to ensure that the program is started at a random memory address each time. The non-startup module is loaded by the startup module. The startup module records the memory address loaded by each module one by one, and also needs to obtain the whitelist memory address that each module needs to register, and record it. There may be some risky operations in the startup module or the non-startup module, and these risky operations are what the application itself needs to perform, so these risky operations need to be added to the whitelist to avoid being detected. These risky operations can be pre-marked by whitelist markings during program design.

[0065] In this embodiment, risky operations may include the following types: the module may allocate an executable memory address for executing shellcode (code that can complete some basic and important work in a very small space), or the module may hook the code of other programs, or the module may modify the code of other modules, or the module may hot-fix and modify the code of its own module, etc.

[0066] In step S10, the preset loading order can be determined based on the startup order between modules. Specifically, it can include: obtaining the dependency order between non-startup modules; constructing a loading order table between non-startup modules according to the dependency order; saving the loading order table to the startup module; wherein the loading order between non-startup modules is stored in the loading order table.

[0067] Design the loading order of non-startup modules in the startup module. First, design the dependent modules. Application dependent modules must be loaded in the dependency order, while non-dependent modules have their loading order fixed according to a certain algorithm, which can speed up the comparison of whitelist information of subsequent modules. Furthermore, dependent modules can be packaged together and loaded in the order of the queue. When implementing the code, you can use the sequence list <string>To design a module group, a group can be multiple modules or one module. In each module group, the modules in the front of the sequence list are loaded first, and the modules in the back are loaded later. For example:

[0068] Create a module group listM1, List <string>listM1. For example, we have a module named network module, which does not need to depend on other modules. Therefore, the module group only has one module listM1.push_back("network"). For other module groups, such as the user module, which must depend on the base module, its implementation is to define a module group listM2, List <string>listM2. Then, listM2.push_back("base") is assigned, and further, listM2.push_back("user"). Since the user module depends on the base module to be loaded first, the base module is queued first and loaded first. At the same time, a total module loading list is designed for non-startup modules. List <list <string>>listall; then non-startup modules will be loaded in a fixed order. Sorting can be done based on the name combination of each module group to ensure that the order of each module group is consistent each time. The name combination of all modules in the module group must be used because some modules may appear in multiple module groups, so the names of the entire module group need to be concatenated and combined for sorting; for example, the first module group is: module1, module2, module3, then the name combination corresponding to this module group is: module1 module2module3. The second module group is: xx, module2, zz, then the name combination corresponding to this module group is: xxmodule2 zz; then the order of the two module groups is: moude1 module2 module3 xx zz, that is, this order is used as the fixed order when loading.

[0069] After the modules are listed in order, the modules are loaded and the whitelist information of the modules is obtained, that is, step S20 is executed.

[0070] Step S20: According to the loading order in the startup module, the non-startup modules of the application are loaded to obtain whitelist information; wherein the whitelist information includes module names and data information.

[0071] Specifically, step S20 includes: loading non-startup modules one by one according to the loading order preset in the startup module; each time a non-startup module is loaded, recording the memory address corresponding to the whitelist mark preset in the non-startup module through the startup module; exporting the module name, memory address and version information corresponding to the non-startup module through the export interface to obtain whitelist data; until the whitelist data corresponding to all non-startup modules are obtained; and obtaining whitelist information based on the whitelist data corresponding to all non-startup modules.

[0072] In step S20, the memory address will be registered when the module is loaded, and can be stored in a list. The specific method is:

[0073] class WihteAddressReg{

[0074] Virtaul std::list <pair<addresss,size> >getInitialWhiteAddress()=0;Among them, this application only writes a memory address list for obtaining the whitelist of each module, because there may be many memory addresses corresponding to whitelist tags in a module. Therefore, a list is needed to store multiple memory addresses. The memory address is an interval, so this application uses<addresss,size> To store, the first address represents the memory address, and size is the size of the interval of this memory address.

[0075] Furthermore, the memory address needs to be exported after it is obtained. Therefore, in this application, each module will write an export interface for external access to whitelist data. Specifically: extern "C" __declspec (dllexport) WihteAddressReg*getReg(); This interface mainly returns the object pointer that the module inherits from WihteAddressReg and instantiates.

[0076] Furthermore, the version information of the module is recorded using: Version getversion(); each module that needs to register the memory address of the whitelist information will inherit the above-mentioned WihteAddressReg and implement its interface getInitialWhiteAddress.

[0077] Furthermore, since each module must provide whitelist data as soon as possible, some special functions of the module itself can only be executed after the whitelist data is provided. In order to ensure the correctness of the module functions and consider the multi-threaded situation, a global semaphore is designed in each module in this embodiment. The signal of the global semaphore can be used to determine whether the memory address corresponding to the whitelist tag of the module is exported. And where the memory address of the above whitelist information is needed, it is determined whether the semaphore has a signal. If there is no signal, it cannot be executed. Here, the use of a global semaphore can ensure that it is correct in the case of multi-threading. If a general variable is used, it may cause a misjudgment due to multi-threaded operations on the variable. Specifically, a global semaphore can be written through Semaphore*getSem().

[0078] For example, after the module name, memory address and version information corresponding to the non-startup module are exported through the export interface, it can be determined whether the non-startup module generates a global semaphore signal; if a semaphore signal is generated, the program function of the non-startup module is executed to ensure the correctness of the function.

[0079] For example, the implementation process of the module loading process and the memory address export in the whitelist data in step S20 can be as follows:

[0080] For example, the specific module loading process can be performed by traversing the listall list as follows:

[0081] For(List <list <string>>::iterator itr=listall.begin();itr!=listall.end();++itr){;Specifically, we traverse listall to load.

[0082] For(list <string>::iterator itr1 = itr.begin(); itr1! = itr.end(); ++itr2) {; Then iterate over the modules of each module group.

[0083] If (GetModuleHandle (*itr1)! = NULL) {; If the module is not loaded, we will load it.

[0084] HMODULE h=Loadlibrary(*itr1); Load the module through the system function.

[0085] Then, the system function GetProcAddress(h,"getReg") is used to obtain the interface to obtain the memory address corresponding to the hundred-list tag that needs to be registered. Specifically: WihteAddressReg*reg=GetProcAddress(h,"getReg").

[0086] Finally, a whitelist statistics collection module can be set up to call and collect the memory address listaddress information of the whitelist data of each module, specifically: std::list <pair<addresss,size> >listaddress=reg->getInitialWhiteAddress().

[0087] Step S30: Synchronously encrypt and cache the module name and the data information to a preset first memory interval and a preset second memory interval in the clipboard respectively to obtain a first cache data block and a second cache data block; wherein the first memory interval is smaller than the data size of the module name, and the second memory interval is smaller than the data size of the data information.

[0088] In step S30, the read and write performance of the network or local disk device is relatively poor. Therefore, this embodiment designs a clipboard memory buffer layer, and adds an IO (Input Output) write data layer to complete the network transmission and disk writing functions of the whitelist data. Usually the clipboard is used for inter-process communication, and in this embodiment, the clipboard is cleverly used as a specific cache space of the memory, so as to achieve the effect of concealing the whitelist.

[0089] Furthermore, since the module name and data information in the whitelist information are stored separately, even if a malicious program captures the packet during the transmission of the whitelist information, the complete whitelist information cannot be obtained, and the whitelist information cannot be tampered with. At the same time, this embodiment is different from the traditional data transmission method. The whitelist data obtained in this embodiment has been transmitted in ciphertext form since it was obtained, and it also exists in ciphertext form in the clipboard memory, which improves security and prevents it from being cracked.

[0090] Since the module name and data information in the whitelist information are stored separately, in order to ensure the relevance between the two, step S30 in this embodiment includes:

[0091] When the module name is cached in the first memory interval, the variable value of the current static variable is added to the cached module name to obtain the first cache data; when the data information is cached in the second memory interval, the variable value of the current static variable is added to the cached data information to obtain the second cache data; wherein, the static variable is used to uniquely identify the first cache data and the second cache data. The static variable is updated once each time the cache is synchronized to ensure that a unique match can be performed each time the cache is synchronized.

[0092] Step S40: When the first memory interval reaches the cache upper limit, the first cache data block is sent to the server and / or saved to the disk;

[0093] Step S50: When the second memory interval reaches the cache upper limit, the second cache data block is sent to the server and / or saved to the disk.

[0094] There is no restriction on the execution order of steps S40 - S50 , and step S40 may be executed first, or step S50 may be executed first, or step S40 and step S50 may be executed simultaneously.

[0095] In step S40 or step S50, the overflow() interface can be used to determine whether the first / second memory interval has reached the cache upper limit; if the first / second memory interval has reached the cache upper limit, the IO layer is notified to send the first / second cache data block to the server and / or save it to the disk.

[0096] For understanding of steps S30-S50 of this embodiment, please refer to the following example:

[0097] The shear plate is designed as a buffer layer function.

[0098] The encryption layer of data can be designed through Class EncryptBuff. Then, we design our cache in combination with the memory address and address length information of our whitelist. The first is the constructor EncryptBuff(size_t size, EncryptBuff*otherbuff); where the parameter size is the size of the memory interval (buff) of the buffer. We must not design this size to be too large. If it is too large, it may contain the entire whitelist information. In this embodiment, it is hoped that the whitelist information in the buffer each time is only partial information, so that each encrypted data block is not a complete information. At the same time, integer multiples such as 1024 cannot be used, but 1022, 1023, 1025, etc. can be used, because the memory is an aligned block size of 1024. Although the aligned block size will be more efficient in reading and writing, it also brings security issues; if non-aligned storage is used, the data is distributed in multiple blocks, which improves the security of the data.

[0099] When storing whitelist information, the module name and data information need to be stored separately. The data information includes memory address and version information. Our interface needs to pass in another memory interval (otherbuff) to coordinate the storage of data in two different memory intervals, so that the data in the two memory intervals are encrypted separately. The two memory intervals correspond to the first memory interval and the second memory interval mentioned above. At the same time, the data in the two memory intervals also need to have a certain connection. The constructor can design a static atomic variable, as follows:

[0100] Static atomic <uint32>id; id will increase every time data is written. This id is a static variable. It is identified by the variable value of the static variable, so it can be used for unique identification. At the same time, a member variable is designed to record the latest id data of the current memory interval, which is used for the subsequent data synchronization function between the two memory intervals. Specifically, atomic <uint32>currid, currid is a member variable.

[0101] Further, when using the clipboard for caching, refer to the following:

[0102] UINT clip = RegisterClipboardFormat ("white"); Register a clipboard handle.

[0103] HGLOBAL h = GlobalAlloc (GMEM_MOVEABLE, size); Clipboard space.

[0104] LPVOID p=GlobalLock(h); Get the memory address where the data is written to the clipboard.

[0105] To write data, you can write it into the memory space corresponding to the p pointer; after writing the data, close the clipboard.

[0106] GlobalUnlock(p);

[0107] SetClipboardData(CF_TEXT,p);

[0108] CloseClipboard();

[0109] Void write(void*addressbuff,size_t size,string modulenmae,versionver,sigslot*sig); Among them, an interface is provided for external data writing, addressbuff is the memory address, modulenmae is the module name, ver is the version information, and the member variable sigslot*sig is used to communicate with the bottom layer. When this interface writes whitelist data externally, it will first encrypt the data information in the memory interval and then store it together with the id information in the memory interval of its own EncryptBuff. At the same time, we will encrypt the module name and concatenate it with the id and store it in another memory interval. The sig is used as a signal slot to notify the IO layer that the buff data is full and needs to be written to the network or disk.

[0110] Furthermore, before writing data to the network or disk, we will determine whether the currid in the two memory sections are consistent. Only when they are consistent can we start writing, otherwise we cannot write. After writing the data, we will again determine whether the two currids are equal to identify whether the two parts of the whitelist information have been modified during the writing process. After writing the data, the currid values ​​corresponding to the two memory sections are updated to the id value, and the id value will be updated after each write.

[0111] Since the addressbuff information and modulenmae are of different sizes, it is possible that one of the memory intervals is full while the other is not. Therefore, in this embodiment, an interface needs to be designed to handle the full situation. Each time a write is made and after a write, overflow() is called to notify the IO layer.

[0112] In this embodiment, Bool overflow() can be used to determine the remaining size of the memory interval. Bool overflow(); This interface is used to determine when the written data is full or the data to be written is larger than the size of the remaining space in the memory interval. Among them, when true is returned, it is full, or the memory interval is not enough to write the whitelist information. Then, at this time, the IO layer will be notified to send the cached data block in the memory address of the clipboard's memory interval to the network or write it to the disk. Sending data means reading the cached data block in the clipboard and sending it, and clearing the data in the clipboard.

[0113] In this embodiment, the IO layer logic design is as follows:

[0114] The IO layer includes writing to the network or writing to a disk file. In this embodiment, an abstract layer is designed to implement whether the cached data block is sent to the network or written to the disk according to whether the file handle or the network handle is passed in. Specifically, the final IO layer can be abstracted first; then, an interface class IO is designed to abstract the abstract interface of writing to a file or a network.

[0115] IO(string name); this constructor takes the file name for a file and the server IP for a network.

[0116] Virtual size write(void*buff,size_t size)=0; this interface can be used to finally write the data in the memory range into the corresponding handle.

[0117] Furthermore, we design a class IOTrans{;

[0118] First, the constructor IOTrans(IO*io,EncryptBuff*buff); the constructor requires two parameters, one is the IO abstraction layer interface, and the other is the buffer buff. Among them, there will be a member variable sigslot*sig, which is used to communicate with the underlying memory space. When the data is full, the data is written to the network layer or written to a file. That is, when sig has a signal, the io->write function will be called to write the data in EncryptBuff to the disk or send it over the network.

[0119] In this embodiment, after the first cache data block and the second cache data block are sent to the server, a whitelist information detection step is also included. The server stores historical list information, which is whitelist related data recorded before this time. Specifically, the whitelist information detection step includes:

[0120] First, the module name, memory address and version information in the whitelist information are obtained based on the first cache data block and the second cache data block; then, based on the module name and version information, the number of memory addresses corresponding to the module name in the whitelist information and the historical list information is compared to see if they are the same; if they are the same, based on the starting address and relative offset corresponding to the module name, the memory address corresponding to the module name in the whitelist information and the historical list information is compared to see if they match; if they match, the whitelist information is determined to be legal. In this way, it can be finally determined whether the transmission process of the whitelist information is safe.

[0121] In this embodiment, the whitelist information is encrypted and written to the disk. When the program is started next time, the whitelist information of the disk, i.e., the historical list information, can be read. To compare whether there are inconsistencies between the whitelist information generated this time and the last time, the whitelist data of the specific module to be compared can be determined by the module name and the version information of the module. When comparing, the legality of the current whitelist information is determined by comparing whether the historical list information of the same module in the last time and the whitelist information this time are consistent. In this way, when a malicious program or a plug-in program writes itself into the whitelist information, it is necessary to modify the data in the historical list information and the whitelist information at the same time to avoid being discovered, so that higher security can be achieved. Specifically, the number of memory addresses in the whitelist information can be compared first, and then the memory addresses in the whitelist information can be compared. The memory address comparison must be based on the module start address and the relative offset, because the memory address of each module loaded each time is different. Since the loading order of each non-startup module is fixed in the previous design in this embodiment, each loading will be loaded according to the preset loading order and compared in sequence, and the speed will be very fast when comparing.

[0122] A method for securely transmitting whitelist information of an application provided in this embodiment first obtains the preset loading order between the non-startup modules of the application, and loads the startup module of the application according to the startup part of the application; wherein the loading order is saved in a loading order table, the loading order table is stored in the startup module, and the loading order table is constructed based on the dependency order between the non-startup modules. Then, according to the preset loading order in the startup module, the non-startup modules of the application are loaded to obtain whitelist information; wherein the whitelist information includes module name and data information; loading according to the preset loading order can ensure that the whitelist information has higher efficiency in the transmission cache process. Then, during the cache process, the module name and data information are synchronized and encrypted and cached to the preset first memory interval and the preset second memory interval in the clipboard, respectively, to obtain the first cache data block and the second cache data block; wherein the first memory interval is smaller than the data volume of the module name, and the second memory interval is smaller than the data volume of the data information. Since the clipboard is used for inter-process communication, the present embodiment cleverly uses it as a memory buffer, which can play the role of concealing the whitelist; further, since the module name and data information of the whitelist information are cached in two memory intervals respectively during the clipboard caching process, it can be avoided that the attacker cannot obtain the two parts of the content at the same time, and the whitelist information cannot be completely stored in the first memory interval and the second memory interval. Each time the memory area is cached, only part of the data is stored, so each encrypted cache data block is not a complete information. Thus, the security of the whitelist information is guaranteed. Finally, when the first memory interval reaches the cache upper limit, the first cache data block is sent to the server and / or saved to the disk; when the second memory interval reaches the cache upper limit, the second cache data block is sent to the server and / or saved to the disk. The present invention solves the problem that the existing data transmission design of the new whitelist information is too simple, and the "plug-in" program or virus program can easily put itself into the whitelist information to bypass detection, thereby improving the security of transmission and detection.

[0123] Second embodiment

[0124] Based on the same inventive concept, a second embodiment of the present invention provides a device 300 for securely transmitting whitelist information of an application. Figure 2 A schematic diagram of the functional module structure of a device 300 for securely transmitting whitelist information of an application program provided in a second embodiment of the present invention is shown.

[0125] The device 300 for securely transmitting whitelist information of an application program includes:

[0126] A loading module 301, used to obtain a preset loading order between non-startup modules of an application, and load the startup module of the application according to the startup part of the application; wherein the loading order is saved in a loading order table, the loading order table is stored in the startup module, and the loading order table is constructed based on the dependency order between the non-startup modules;

[0127] A whitelist information acquisition module 302 is used to load the non-startup modules of the application according to the loading order in the startup module to obtain whitelist information; wherein the whitelist information includes module name and data information;

[0128] The clipboard cache module 303 is used to synchronize and encrypt the module name and the data information and cache them in a preset first memory interval and a preset second memory interval in the clipboard, respectively, to obtain a first cache data block and a second cache data block; wherein the first memory interval is smaller than the data size of the module name, and the second memory interval is smaller than the data size of the data information;

[0129] A first cache processing module 304, configured to send the first cache data block to a server and / or save it to a disk when the first memory interval reaches a cache upper limit;

[0130] The second cache processing module 305 sends the second cache data block to the server and / or saves it to a disk when the second memory interval reaches the cache upper limit.

[0131] It should be noted that the specific implementation and technical effects of the device 300 for securely transmitting whitelist information of an application provided in the embodiment of the present invention are the same as those of the aforementioned method embodiment. For the sake of brief description, for matters not mentioned in the device embodiment, reference may be made to the corresponding contents in the aforementioned method embodiment.

[0132] If the functional module integrated in the device provided by the present invention is implemented in the form of a software functional module and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the present invention implements all or part of the processes in the method of the above embodiment, and can also be completed by instructing the relevant hardware through a computer program. The computer program can be stored in a computer-readable storage medium, and the computer program can implement the steps of the above-mentioned various method embodiments when executed by the processor. Among them, the computer program includes computer program code, and the computer program code can be in source code form, object code form, executable file or some intermediate form. The computer-readable medium may include: any entity or device capable of carrying the computer program code, recording medium, U disk, mobile hard disk, disk, optical disk, computer memory, read-only memory (ROM, Read-Only Memory), random access memory (RAM, Random Access Memory), electric carrier signal, telecommunication signal and software distribution medium. It should be noted that the content contained in the computer-readable medium can be appropriately increased or decreased according to the requirements of legislation and patent practice in the jurisdiction. For example, in some jurisdictions, according to legislation and patent practice, computer-readable media do not include electric carrier signals and telecommunication signals.

[0133] The algorithm and display provided herein are not inherently related to any particular computer, virtual system or other device. Various general purpose systems can also be used together with the teachings based on this. According to the above description, it is obvious that the structure required for constructing such systems. In addition, the present invention is not directed to any specific programming language either. It should be understood that various programming languages ​​can be utilized to realize the content of the present invention described herein, and the description of the above specific languages ​​is for disclosing the best mode of the present invention.

[0134] In the description provided herein, a large number of specific details are described. However, it is understood that embodiments of the present invention can be practiced without these specific details. In some instances, well-known methods, structures and techniques are not shown in detail so as not to obscure the understanding of this description.

[0135] Similarly, it should be understood that in order to streamline the present disclosure and aid in understanding one or more of the various inventive aspects, in the above description of exemplary embodiments of the present invention, various features of the present invention are sometimes grouped together into a single embodiment, figure, or description thereof. However, this disclosed method should not be interpreted as reflecting the intention that the claimed invention requires more features than those explicitly recited in each claim. More specifically, as reflected in the claims below, inventive aspects lie in less than all the features of the individual embodiments disclosed above. Therefore, the claims that follow the specific embodiment are hereby expressly incorporated into the specific embodiment, with each claim itself serving as a separate embodiment of the present invention.

[0136] Those skilled in the art will appreciate that the modules in the devices in the embodiments may be adaptively changed and arranged in one or more devices different from the embodiments. The modules or units or components in the embodiments may be combined into one module or unit or component, and in addition they may be divided into a plurality of submodules or subunits or subcomponents. Except that at least some of such features and / or processes or units are mutually exclusive, all features disclosed in this specification (including the accompanying claims, abstracts and drawings) and all processes or units of any method or device disclosed in this manner may be combined in any combination. Unless otherwise expressly stated, each feature disclosed in this specification (including the accompanying claims, abstracts and drawings) may be replaced by an alternative feature providing the same, equivalent or similar purpose.

[0137] In addition, those skilled in the art will appreciate that, although some embodiments herein include certain features included in other embodiments but not other features, the combination of features of different embodiments is meant to be within the scope of the present invention and form different embodiments. For example, in the claims below, any one of the claimed embodiments may be used in any combination.

[0138] The various component embodiments of the present invention may be implemented in hardware, or in software modules running on one or more processors, or in a combination thereof. It should be understood by those skilled in the art that a microprocessor or digital signal processor (DSP) may be used in practice to implement some or all of the functions of some or all of the components in the apparatus according to an embodiment of the present invention. The present invention may also be implemented as a device or device program (e.g., a computer program and a computer program product) for executing part or all of the methods described herein. Such a program implementing the present invention may be stored on a computer-readable medium, or may have the form of one or more signals. Such a signal may be downloaded from an Internet website, or provided on a carrier signal, or provided in any other form.

[0139] It should be noted that the above embodiments illustrate the present invention rather than limit it, and that those skilled in the art may devise alternative embodiments without departing from the scope of the appended claims. In the claims, any reference symbol between brackets shall not be construed as a limitation on the claims. The word "comprising" does not exclude the presence of elements or steps not listed in the claims. The word "one" or "an" preceding an element does not exclude the presence of a plurality of such elements. The present invention may be implemented by means of hardware comprising a number of different elements and by means of a suitably programmed computer. In a unit claim enumerating a number of devices, several of these devices may be embodied by the same hardware item. The use of the words first, second, and third, etc., does not indicate any order. These words may be interpreted as names. < / string> < / string> < / string> < / string> < / string> < / string>

Claims

1. A method for securely transmitting whitelist information of an application, characterized in that: include: Obtaining a preset loading order between non-startup modules of an application, and loading the startup module of the application according to the startup part of the application; wherein the loading order is saved in a loading order table, the loading order table is stored in the startup module, and the loading order table is constructed based on the dependency order between the non-startup modules; According to the loading order in the startup module, the non-startup module is loaded to obtain whitelist information, including: according to the loading order, the non-startup modules are loaded one by one; each time a non-startup module is loaded, the memory address corresponding to the whitelist mark preset in the non-startup module is recorded by the startup module; the module name, memory address and version information corresponding to the non-startup module are exported through the export interface to obtain whitelist data; until the whitelist data corresponding to all non-startup modules are obtained; the whitelist information is obtained according to the whitelist data corresponding to all non-startup modules; wherein the whitelist information includes the module name and data information; the data information includes the memory address and version information; The module name and the data information are synchronously encrypted and cached to a preset first memory interval and a preset second memory interval in the clipboard, respectively, to obtain a first cache data block and a second cache data block; wherein the first memory interval is smaller than the data size of the module name, and the second memory interval is smaller than the data size of the data information; When the first memory interval reaches the cache upper limit, the first cache data block is sent to the server and / or saved to the disk; When the second memory interval reaches the cache upper limit, the second cache data block is sent to the server and / or saved to a disk.

2. The method according to claim 1, characterized in that After exporting the module name, memory address and version information corresponding to the non-startup module through the export interface, the method further includes: Determine whether the non-startup module generates a signal of a global semaphore; wherein the signal of the global semaphore is used to determine whether the memory address of the non-startup module is exported; If a semaphore signal is generated, the program function of the non-startup module is executed.

3. The method according to claim 1, characterized in that: The step of synchronizing and encrypting the module name and the data information and caching them in a first memory interval and a second memory interval preset in the clipboard to obtain a first cache data block and a second cache data block includes: Allocate the first memory interval and the second memory interval on the clipboard according to the GlobalAlloc() function; According to the GlobalLock() function, determine a first address for writing data in the first memory interval and a second address for writing data in the second memory interval; According to the first address, the second address and the preset encryption function EncryptBuff(size_tsize, EncryptBuff*otherbuff), the module name and the data are encrypted and written to the clipboard respectively to obtain the first cache data block and the second cache data block; wherein size_t represents the size of the first memory interval, size represents the size of the second memory interval, EncryptBuff* represents the first memory interval, and otherbuff represents the second memory interval.

4. The method according to claim 3, characterized in that The step of encrypting and writing the module name and the data into the clipboard to obtain the first cache data block and the second cache data block comprises: When the module name is cached in the first memory interval, the variable value of the current static variable is added to the cached module name to obtain the first cache data; When the data information is cached in the second memory interval, the variable value of the current static variable is added to the cached data information to obtain the second cache data; wherein the static variable is used to uniquely identify the first cache data and the second cache data.

5. The method according to claim 4, characterized in that When the module name is cached in the first memory interval, adding the variable value of the current static variable to the cached module name includes: According to Static atomic <uint32> id, construct a static variable; where id is a static variable; According to atomic <uint32> currid, build member variables; where currid is a member variable used to record the variable value of the current static variable; When the module name is cached in the first memory interval, the member variable is used to record the variable value of the current static variable; The variable value of the current static variable of the member variable record is added to the cached module name.

6. The method according to claim 1, characterized in that When the first memory interval reaches the cache upper limit, sending the first cache data block to the server and / or saving it to a disk includes: Determine whether the first memory interval reaches the cache upper limit through the Bool overflow() interface; If the first memory interval reaches the cache upper limit, the IO layer is notified to send the first cache data block to the server and / or save it to the disk.

7. The method according to claim 1, characterized in that After sending the first cache data block and the second cache data block to the server, a whitelist information detection step is also included; the server stores historical list information, and the whitelist information detection step includes: Obtaining the module name, memory address and version information in the whitelist information according to the first cache data block and the second cache data block; According to the module name and the version information, comparing whether the number of memory addresses corresponding to the module name in the whitelist information and the historical list information is the same; If they are the same, comparing the memory address corresponding to the module name in the whitelist information with that in the historical list information based on the starting address and relative offset corresponding to the module name to see if they match; If they match, it is determined that the whitelist information is legal.

8. A device for securely transmitting whitelist information of an application, characterized in that: include: A loading module, used to obtain a preset loading order between non-startup modules of an application, and load the startup module of the application according to the startup part of the application; wherein the loading order is saved in a loading order table, the loading order table is stored in the startup module, and the loading order table is constructed based on the dependency order between the non-startup modules; A whitelist information acquisition module is used to load the non-startup module according to the loading order in the startup module to obtain whitelist information, including: loading the non-startup modules one by one according to the loading order; recording the memory address corresponding to the whitelist mark preset in the non-startup module through the startup module each time a non-startup module is loaded; exporting the module name, memory address and version information corresponding to the non-startup module through the export interface to obtain whitelist data; until the whitelist data corresponding to all non-startup modules are obtained; obtaining the whitelist information according to the whitelist data corresponding to all non-startup modules; wherein the whitelist information includes the module name and data information; the data information includes the memory address and version information; A clipboard cache module, used to synchronously encrypt and cache the module name and the data information to a preset first memory interval and a preset second memory interval in the clipboard, respectively, to obtain a first cache data block and a second cache data block; wherein the first memory interval is smaller than the data size of the module name, and the second memory interval is smaller than the data size of the data information; A first cache processing module, configured to send the first cache data block to a server and / or save it to a disk when the first memory interval reaches a cache upper limit; The second cache processing module sends the second cache data block to the server and / or saves it to a disk when the second memory interval reaches the cache upper limit.

9. A computer-readable storage medium having a computer program stored thereon, characterized in that: When the program is executed by a processor, the steps of the method described in any one of claims 1 to 7 are implemented.

Images