CN107577715B - SO file protection method and device - Google Patents
SO file protection method and device Download PDFInfo
- Publication number
- CN107577715B CN107577715B CN201710671782.5A CN201710671782A CN107577715B CN 107577715 B CN107577715 B CN 107577715B CN 201710671782 A CN201710671782 A CN 201710671782A CN 107577715 B CN107577715 B CN 107577715B
- Authority
- CN
- China
- Prior art keywords
- section
- encrypted
- encryption
- file
- area
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Active
Links
Images
Landscapes
- Storage Device Security (AREA)
Abstract
The application provides a method and a device for protecting SO files, wherein the method comprises the following steps: the SO file comprises a user-defined section area in which a core function is stored, wherein the user-defined section area is a section area to be encrypted; the method comprises the following steps: determining whether a next section to be encrypted exists after the section to be encrypted; and if the next section to be encrypted exists behind the section to be encrypted, inserting a first set identifier and address information of the next section to be encrypted at the specified position of the section to be encrypted, and encrypting the section to be encrypted to obtain a first encrypted section. By applying the method, the safety of the SO file can be improved, and unnecessary loss caused by leakage of the core function is avoided.
Description
Technical Field
The present application relates to the field of data security technologies, and in particular, to a method and an apparatus for protecting an SO (shared object) file.
Background
The SO file is a dynamic link library in the Linux system and is compiled by a code program written in C language or C + + language. In the android system, a core function is usually written in a C language or a C + + language, and then is compiled to generate an SO file for a JAVA layer to call, SO that the security of the SO file is important.
However, in the related art, an attacker, for example, a hacker, can easily decompile the SO file by using some common cracking tools, for example, an IDA cracking tool, to obtain an assembly code, SO that the core function in the SO file is clearly exposed, and it is possible for a malicious attacker to implement illegal destruction. Therefore, a protection method for an SO file is needed to improve the security of the SO file and avoid unnecessary loss due to leakage of a kernel function.
Disclosure of Invention
In view of this, the present application provides a method and an apparatus for protecting an SO file, SO as to improve the security of the SO file and avoid unnecessary loss due to leakage of a kernel function.
Specifically, the method is realized through the following technical scheme:
according to a first aspect of the embodiments of the present application, a method for protecting an SO file is provided, where the SO file includes a custom section area in which a core function is stored, and the custom section area is a section area to be encrypted; the method comprises the following steps:
determining whether a next section to be encrypted exists after the section to be encrypted;
and if the next section to be encrypted exists behind the section to be encrypted, inserting a first set identifier and address information of the next section to be encrypted at the specified position of the section to be encrypted, and encrypting the section to be encrypted to obtain a first encrypted section.
According to a second method of an embodiment of the present application, there is provided a method for protecting an SO file, where an encrypted nodal region exists in the SO file, the method including:
decrypting the encrypted section area to obtain first original data of the encrypted section area;
if the designated position of the first original data comprises a first setting identifier, acquiring first address information of a next encryption node area at the designated position of the first original data;
and acquiring the next encryption section area based on the first address information, and decrypting the next encryption section area to obtain second original data of the next encryption section area.
According to a third aspect of the embodiments of the present application, there is provided a device for protecting an SO file, where the SO file includes a custom section area in which a core function is stored, and the custom section area is a section area to be encrypted; the device comprises:
the first determining module is used for determining whether a next section to be encrypted exists after the section to be encrypted;
and the first encryption module is used for inserting a first set identifier and the address information of the next section to be encrypted at the specified position of the section to be encrypted if the next section to be encrypted exists behind the section to be encrypted, and encrypting the section to be encrypted to obtain a first encryption section.
According to a fourth aspect of embodiments of the present application, there is provided an apparatus for protecting an SO file, where an encryption node area exists, the apparatus including:
the first decryption module is used for decrypting the encrypted section area to obtain first original data of the encrypted section area;
a first data obtaining module, configured to obtain first address information of a next encryption node area at a specified position of the first original data if the specified position of the first original data includes a first setting identifier;
and the second decryption module is used for acquiring the next encryption section area based on the first address information and decrypting the next encryption section area to obtain second original data of the next encryption section area.
As can be seen from the foregoing embodiments, in the present application, before encrypting a section to be encrypted, it is first determined whether a next section to be encrypted exists after the section to be encrypted, if so, address information of the next section to be encrypted is added to the section to be encrypted, and then the section to be encrypted is encrypted. By means of the processing, when the SO file is decrypted subsequently, the first encryption node area needs to be obtained at first, the first encryption node area is decrypted, the original data of the first encryption node area is obtained, the address information of other encryption node areas can be obtained based on the original data, and therefore other encryption node areas can be obtained. Therefore, in the subsequent process of decrypting the encrypted SO file, the decryption process of each encryption node area is looped, SO that the decryption difficulty of the SO file is increased, the safety of the SO file is effectively improved, and unnecessary loss caused by leakage of a core function can be effectively avoided.
Drawings
FIG. 1 is a schematic diagram of the ELF format;
FIG. 2A is a flow chart of one embodiment of a method for protecting SO documents of the present application;
FIG. 2B is an example of a format of a custom header;
FIG. 2C is an exemplary block diagram of an encrypted SO file;
FIG. 2D is another exemplary block diagram of an encrypted SO file;
FIG. 3 is a flow chart of another embodiment of a method for protecting SO documents of the present application;
FIG. 4 is a block diagram of one embodiment of a protection device for SO documents of the present application;
fig. 5 is a block diagram of another embodiment of the protection device of the SO document of the present application.
Detailed Description
Reference will now be made in detail to the exemplary embodiments, examples of which are illustrated in the accompanying drawings. When the following description refers to the accompanying drawings, like numbers in different drawings represent the same or similar elements unless otherwise indicated. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with the present application. Rather, they are merely examples of apparatus and methods consistent with certain aspects of the present application, as detailed in the appended claims.
The terminology used herein is for the purpose of describing particular embodiments only and is not intended to be limiting of the application. As used in this application and the appended claims, the singular forms "a", "an", and "the" are intended to include the plural forms as well, unless the context clearly indicates otherwise. It should also be understood that the term "and/or" as used herein refers to and encompasses any and all possible combinations of one or more of the associated listed items.
It is to be understood that although the terms first, second, third, etc. may be used herein to describe various information, such information should not be limited to these terms. These terms are only used to distinguish one type of information from another. For example, first information may also be referred to as second information, and similarly, second information may also be referred to as first information, without departing from the scope of the present application. The word "if" as used herein may be interpreted as "at … …" or "when … …" or "in response to a determination", depending on the context.
The SO file is a file in EIF format, as shown in fig. 1, and is a schematic diagram of ELF format, wherein a route map (road map) is stored in an ELF file header, i.e. an "ELF header", for describing an organization condition of the ELF file; a program header table, namely a "program header table", is used for describing how the system creates the process image, the program header table must be provided in the ELF file for constructing the process image, and the program header table is not required to be provided in the relocatable ELF file; section Sections, i.e., "Sections," are used to hold information of the object file, which may include instructions, data, symbol tables, relocation information, and the like, from a link perspective; the section header table, i.e., "section header table," is used to describe information of the section part, each section in the section part has an entry in the section header table, each entry describes information such as a section name, a section size, and the like, the section header table must be included in the ELF file for linking, and the section header table may or may not be included in the ELF file for other purposes.
In the android system, a core function is usually written in a C language or a C + + language, and then is compiled to generate an SO file for a JAVA layer to call, SO that the security of the SO file is important. However, in the related art, an attacker, for example, a hacker, can easily decompile the SO file by using some common cracking tools, for example, an IDA cracking tool, to obtain an assembly code, SO that the core function in the SO file is clearly exposed, and it is possible for a malicious attacker to implement illegal destruction.
Based on this, the embodiment of the present application provides a protection method for SO files, in which, considering that there is more than one core function to be protected in practical application, thus, after "the core function is placed in the custom section of the SO file, the custom section is found, on the basis of encrypting the custom section, further proposes that before encrypting the custom section, adding the address information of the next self-defined section into the self-defined section, then encrypting the self-defined section, through the processing, when the SO file is decrypted subsequently, the first encryption node area needs to be obtained first, and decrypting the first encryption section to obtain the original data of the first encryption section, and acquiring the address information of the next encryption section based on the original data so as to acquire other encryption sections. Therefore, by executing the protection method of the SO file provided by the application, the decryption process of each encryption node area is looped in the subsequent decryption process of the encrypted SO file, SO that the decryption difficulty of the SO file is increased, the security of the SO file is also effectively improved, and unnecessary loss caused by leakage of a core function can be effectively avoided.
In order to make the protection method of the SO document provided in the present application more clearly apparent to those skilled in the art, the method will be described by referring to the following examples.
First, a method for protecting an SO file provided by the present application is described from an "encryption side", for example, a server side:
referring to fig. 2A, a flowchart of an embodiment of a method for protecting an SO file according to the present application is shown, where the method is used to encrypt the SO file, where the SO file includes a custom section area in which a core function is stored, and the custom section area is a section area to be encrypted, and the method may include the following steps:
step 201: determining whether a next section to be encrypted exists after the section to be encrypted, if so, executing step 202; otherwise, step 203 is executed.
Step 202: and inserting a first set identifier and address information of the next section to be encrypted into the designated position of the section to be encrypted, and encrypting the section to be encrypted to obtain a first encrypted section. And ending the flow.
Step 203: and inserting a second set identifier at the designated position of the section to be encrypted, and encrypting the section to be encrypted to obtain a second encrypted section, wherein the first set identifier is different from the second set identifier.
The above steps 201 to 203 are explained as follows:
in the embodiment of the present application, "_ attribute _" ((section ("name")))); "this attribute, the core function to be protected is placed in the custom section of the SO file, which is the section to be encrypted.
In the process of encrypting the user-defined sections, firstly, the sections to be encrypted are obtained, and the specific obtaining process comprises the following steps: analyzing the SO file, finding a section header table, namely a "section header table", traversing each entry in the section header table according to the name of the user-defined section, namely the "name", as can be seen from the above-mentioned related description of fig. 1, each section in the section part of the SO file has an entry in the section header table, and each entry describes information such as the section name, the section size, and the like, SO that an entry corresponding to the user-defined section "name" can be found in a traversal manner, and further information such as the offset address, the size, and the like of the user-defined section "name" can be obtained in the found entry. And subsequently, the user-defined section 'name' can be acquired in the SO file according to the acquired offset address and the acquired size.
Then, it is determined whether a next section to be encrypted exists after the section to be encrypted, and specifically, it may be determined whether a next section to be encrypted exists according to predefined information of a custom section, as follows, first, a case where a next section to be encrypted exists is explained:
when there is a next section to be encrypted, the offset address and the size of the next section to be encrypted are obtained, and specifically, how to obtain the offset address and the size of the next section to be encrypted can refer to the above-mentioned description of "obtaining information such as the offset address and the size of the" name "of the custom section", and details are not described here. Subsequently, a first setting flag, for example, "1", and address information of the next section to be encrypted are inserted into the designated position of the section to be encrypted, where the address information may include information such as offset address and size.
It can be seen that the first setting flag can be used to indicate the existence of the next encryption node area, and the first setting flag can be used in the subsequent process of decrypting the SO file, and the specific decryption process can be referred to the subsequent description, which will not be described in detail herein.
In an alternative implementation manner, the first setting identifier and the address information may be inserted at a start position of the section to be encrypted, and specifically, a custom data header may be inserted at the start position of the section to be encrypted, as shown in fig. 2B, which is an example of a format of the custom data header.
In the custom header illustrated in fig. 2B, flag is a setting flag, and occupies 4 bytes, and at this time, the value of flag is the first setting flag; the offset represents an offset address, occupying 4 bytes; size indicates size, taking 4 bytes.
It should be noted that the format of the custom header illustrated in fig. 2B is merely an example, and the specific format of the custom header is not limited in this application.
And subsequently, encrypting the section to be encrypted to obtain a first encrypted section. The encryption method may include DES, IDEA, and the like, and the application does not limit the specific encryption method.
Next, a case where there is no next node area to be encrypted is explained:
when the next section to be encrypted does not exist, a second setting identifier, for example "0", may be inserted at the designated position of the section to be encrypted, and subsequently, the section to be encrypted is encrypted to obtain a second encrypted section. The encryption method may include DES, IDEA, and the like, and the application does not limit the specific encryption method.
As can be seen from the above description, the second setting flag is different from the first setting flag, the second setting flag can be used to indicate that there is no next encryption section, and the second setting flag can also be used in the subsequent process of decrypting the SO file, and the specific decryption process can be referred to the subsequent description, which is not described in detail first.
In an alternative implementation manner, the second setting identifier may be inserted at the start position of the section to be encrypted, and specifically, similar to the above description, a custom data header is inserted at the start position of the section to be encrypted, where the custom data header differs from the custom data header illustrated in fig. 2B in that: the custom data header only comprises a flag, namely a setting identifier, and the value of the flag at the moment is a second setting identifier.
The description of step 201 to step 203 is completed.
In addition, it should be further noted that, in this embodiment of the present application, after the section to be encrypted is encrypted to obtain the first encrypted section, the offset address of the first encrypted section may be recorded in the e _ entry field in the header of the SO file, and the size of the first encrypted section is recorded in the e _ shoff field in the header, SO that the SO file may be decrypted subsequently based on the e _ entry field and the e _ shoff field, and a specific decryption process please refer to subsequent description, which is not described in detail herein first.
The e _ entry field is used for representing a virtual address for starting the program, and has no meaning on program operation, so that the e _ entry field can be modified; since the e _ shoff field represents a section header tableoffset, which is only active during program linking, and has no effect during program loading, the e _ shoff field may also be modified.
In addition, it should be further noted that, in this embodiment of the present application, after the section to be encrypted is encrypted to obtain the first encryption section, it is determined whether another encryption section exists after the next section to be encrypted, if so, the first setting identifier and the address information of another section to be encrypted may be inserted into the specified position of the next section to be encrypted, and the next section to be encrypted is encrypted to obtain the third encryption section; if the node to be encrypted does not exist, a second set identifier can be inserted into the specified position of the next node to be encrypted, and the next node to be encrypted is encrypted to obtain a fourth encrypted node.
Specifically, how to insert a first setting mark and address information of other sections to be encrypted at the specified position of the next section to be encrypted; or a second setting identifier may be inserted, and the above-mentioned related description may be referred to, and will not be described in detail again.
In order to make the encryption principle of the SO file protection method provided in the embodiments of the present application more clearly understood by those skilled in the art, the following examples are listed:
the first embodiment is as follows:
taking the example of two kernel functions to be protected, "_ attribute _" ((section (". mytext 1")); "this attribute, one of the kernel functions is placed in the custom section". mytext1", using" _ attribute _ "(". mytext2 ")); "this attribute, put another core function in the custom section". mytext2", the custom section". mytext1 "and". mytext2 "are the section to be encrypted.
Firstly, acquiring a custom region ". mytext1" from an SO file, and because a next region to be encrypted, namely the custom region ". mytext2", exists, inserting a custom data header1 into the custom region ". mytext1", where in the custom data header1, a flag value is a first setting identifier, for example, "1", offset2 represents an offset address of the custom region ". mytext2", and size2 represents the size of the custom region ". mytext2", and encrypting the custom region ". mytext 1". Thereafter, the offset address offset1 of the encrypted custom section ". mytext1" is recorded in the e _ entry field in the header of the SO file, and the size1 of the encrypted custom section ". mytext1" is recorded in the e _ shoff field in the header.
Subsequently, since there is no other section to be encrypted after the custom section ". mytext2", a custom data header2 may be inserted into the custom section ". mytext2", and in this custom data header2, the value of flag is a second setting flag, for example, "0". As shown in fig. 2C, is an exemplary structure diagram of the encrypted SO file.
Thus, the description of example one is completed.
Example two:
taking the example of three kernel functions to be protected, "_ attribute _" ((section (". mytext 1")); "this attribute, one of the kernel functions is placed in the custom section". mytext1", using" _ attribute _ "(". mytext2 ")); "this attribute, put another kernel function in the custom section". mytext2", use" _ attribute _ "((section (". mytext3 ")))); "this attribute, put another kernel function in the custom section". mytext3", the custom section". mytext1",. mytext2", and. mytext3 "are the sections to be encrypted.
Firstly, acquiring a custom region ". mytext1" from an SO file, and because a next region to be encrypted, namely the custom region ". mytext2", exists, inserting a custom data header1 into the custom region ". mytext1", where in the custom data header1, a flag value is a first setting identifier, for example, "1", offset2 represents an offset address of the custom region ". mytext2", size2 represents the size of the custom region ". mytext2", and then encrypting the custom region ". mytext 1". Thereafter, the offset address offset1 of the encrypted custom section ". mytext1" is recorded in the e _ entry field in the header of the SO file, and the size1 of the encrypted custom section ". mytext1" is recorded in the e _ shoff field in the header.
Subsequently, since there are other to-be-encrypted sections after the next to-be-encrypted section, i.e., the custom section ". mytext2", i.e., the custom section ". mytext3", a custom data header2 may be inserted into the custom section ". mytext2", in the custom data header2, the value of flag is a first set identifier, e.g., "1", offset3 represents the offset address of the custom section ". mytext3", size3 represents the size of the custom section ". mytext3", and then the custom section ". mytext2" is encrypted.
Subsequently, since there is no other section to be encrypted after the custom section ". mytext3", a custom data header3 may be inserted into the custom section ". mytext3", and in this custom data header3, the value of flag is a second setting flag, for example, "0". Fig. 2D is a diagram illustrating an exemplary structure of an encrypted SO file.
The description of example two is now complete.
As can be seen from the foregoing embodiments, in the present application, before encrypting a section to be encrypted, it is first determined whether a next section to be encrypted exists after the section to be encrypted, if so, address information of the next section to be encrypted is added to the section to be encrypted, and then the section to be encrypted is encrypted. By means of the processing, when the SO file is decrypted subsequently, the first encryption node area needs to be obtained at first, the first encryption node area is decrypted, the original data of the first encryption node area is obtained, the address information of other encryption node areas can be obtained based on the original data, and therefore other encryption node areas can be obtained. Therefore, in the subsequent process of decrypting the encrypted SO file, the decryption process of each encryption node area is looped, SO that the decryption difficulty of the SO file is increased, the safety of the SO file is effectively improved, and unnecessary loss caused by leakage of a core function can be effectively avoided.
The protection method of the SO file provided by the present application is explained from a "decryption side", e.g., a client side, as follows:
referring to fig. 3, a flowchart of another embodiment of a method for protecting an SO file according to the present application is shown, where the method is used to perform decryption processing on the SO file, where the SO file includes an encrypted node area stored therein, and the method may include the following steps:
step 301: and decrypting the encrypted sections to obtain first original data of the encrypted sections.
Step 302: and if the specified position of the first original data comprises the first setting identification, acquiring first address information of a next encryption node area at the specified position of the first original data.
Step 303: and acquiring the next encryption section area based on the first address information, and decrypting the next encryption section area to obtain second original data of the next encryption section area.
First, in the embodiment of the present application, a decryption program may be declared using an attribute of "_ attribute _.
in the embodiment of the present application, the encrypted SO file illustrated in fig. 2C is decrypted as an example:
when decryption is started, the encrypted section is first obtained, and for convenience of description, the obtained encrypted section is referred to as a first encrypted section, based on the above description in the embodiment shown in fig. 2A, an e _ entry field and an e _ shoff field may be obtained in a header, "ELF header", of the encrypted SO file illustrated in fig. 2C, where a value of the e _ entry field indicates an offset address of the first encrypted section, and a value of the e _ shoff field indicates a size of the first encrypted section, and then, according to the obtained e _ entry field and the obtained e _ shoff field, the first encrypted section may be obtained, for example, obtaining a custom section ". mytext1" section 1.
Subsequently, the customized section ". mytext1" may be decrypted to obtain the first original data of the customized section ". mytext 1". Based on the above description related to the embodiment shown in fig. 2A, the first original data at least includes the first setting identifier or the second setting identifier, then, it may be determined that the first setting identifier or the second setting identifier exists at the specified position of the obtained original data first, for example, in conjunction with the structure diagram of the custom data header illustrated in fig. 2B, 4 bytes of data may be obtained from the starting byte (including the starting byte) of the original data, and it is determined whether the 4 bytes of data are the first setting identifier or the second setting identifier.
If the first setting identifier exists at the specified position of the first original data, it may be determined that a next encrypted section area still exists, and then first address information of the next encrypted section area may be further obtained at the specified position of the first original data, for example, in combination with the structure diagram of the custom data header illustrated in fig. 2B, 4 bytes of data may be obtained from the 5 th byte (including the 5 th byte) of the first original data, where the 4 bytes of data are the offset address of the next encrypted section area; and continuously obtaining 4 bytes of data from the 9 th byte (including the 9 th byte) of the first original data, wherein the 4 bytes of data are the size of the next encryption section area.
Subsequently, based on the first address information of the next encrypted region, for example, mytext2", can be obtained in the SO file, and the customized region mytext2" is decrypted, SO as to obtain the second original data of the customized region mytext2 ".
If the second setting mark exists at the designated position of the first original data, it can be determined that the next encryption section does not exist, that is, the decryption operation of the SO file is completed.
The description of step 301 to step 303 is completed.
In addition, it should be noted that, after the next encryption node area is decrypted to obtain the second original data of the next encryption node area, it may be determined whether the specified position of the second original data includes the first setting identifier or the second setting identifier. If the second set identifier is the first set identifier, second address information of other encryption sections can be obtained at the designated position of the second original data, the other encryption sections are obtained based on the second address information, and the other encryption sections are decrypted to obtain third original data of the other encryption sections.
In addition, in the embodiment of the present application, after the encrypted segment, for example, the customized segment ". mytext1" is decrypted to obtain the first original data, the valid original data in the customized segment ". mytext1" may be obtained in the first original data, and the customized segment ". mytext1" may be covered with the valid original data. Specifically, in conjunction with the structure diagram of the custom data header illustrated in fig. 2B, since the header of the custom byte area ". mytext1" is inserted with the first setting identifier of 4 bytes, and the address information of 8 bytes, then the first original data can be determined as valid original data from the header after the 13 th byte (including the 13 th byte).
Furthermore, as shown in fig. 2C, only the second set flag of 4 bytes is inserted into the header of the custom section ". mytext2", then the second original data of the custom section ". mytext2" can be determined as valid original data from the header after the 5 th byte (including the 5 th byte).
As can be seen from the foregoing embodiments, when decrypting an encrypted SO file, the present application needs to first obtain a first encryption node area, decrypt the first encryption node area to obtain original data of the first encryption node area, and based on the original data, address information of other encryption node areas can be obtained, SO as to obtain other encryption node areas. Therefore, in the process of decrypting the encrypted SO file, the decryption process of each encryption node area is in a loop-by-loop manner, SO that the decryption difficulty of the SO file is increased, the safety of the SO file is effectively improved, and unnecessary loss caused by leakage of a core function can be effectively avoided.
Corresponding to the embodiment of the protection method of the SO file, the application also provides an embodiment of a protection device of the SO file.
First, a protection device of the SO document of the present application will be described from an "encryption side", for example, a server side:
referring to fig. 4, which is a block diagram of an embodiment of the protection apparatus for SO documents of the present application, the apparatus may include a first determining module 41 and a first encrypting module 42.
The first determining module 41 may be configured to determine whether a next section to be encrypted exists after the section to be encrypted;
the first encryption module 42 may be configured to insert a first setting identifier and address information of a next section to be encrypted at a specified position of the section to be encrypted if the next section to be encrypted exists after the section to be encrypted, and encrypt the section to be encrypted to obtain a first encrypted section.
In an embodiment, the apparatus may further comprise (not shown in fig. 4):
and the second encryption module is used for inserting a second set identifier at the designated position of the section to be encrypted and encrypting the section to be encrypted to obtain a second encryption section if the next section to be encrypted does not exist after the section to be encrypted, wherein the first set identifier is different from the second set identifier.
In an embodiment, the apparatus may further comprise (not shown in fig. 4):
and the recording module is used for recording the offset address of the first encryption section area in an e _ entry field in a file header of the SO file, and recording the size of the first encryption section area in an e _ shoff field in the file header.
In an embodiment, the apparatus may further comprise (not shown in fig. 4):
a second determining module, configured to determine whether there are other sections to be encrypted after the next section to be encrypted;
a third encryption module, configured to insert a first setting identifier and address information of the other section to be encrypted at an assigned position of the next section to be encrypted if the other section to be encrypted exists behind the next section to be encrypted, and encrypt the next section to be encrypted to obtain a third encryption section;
and the fourth encryption module is used for inserting a second setting identifier at the specified position of the next section to be encrypted if no other section to be encrypted exists behind the next section to be encrypted, and encrypting the next section to be encrypted to obtain a fourth encryption section.
Next, a protection device of the SO file of the present application will be described from a "decryption side", for example, a client side:
referring to fig. 5, a block diagram of another embodiment of the protection apparatus for SO documents of the present application may include a first decryption module 51, a first data obtaining module 52, and a second decryption module 53.
The first decryption module 51 may be configured to decrypt the encrypted segment area to obtain first original data of the encrypted segment area;
the first data obtaining module 52 may be configured to obtain first address information of a next encryption node area at a specified position of the first original data if the specified position of the first original data includes a first setting identifier;
the second decryption module 53 may be configured to obtain the next encrypted segment area based on the first address information, and decrypt the next encrypted segment area to obtain the second original data of the next encrypted segment area.
In an embodiment, the apparatus may further comprise (not shown in fig. 5):
a second data obtaining module, configured to obtain second address information of another encryption node area at a specified position of the second original data if the specified position of the second original data includes the first setting identifier;
and the third decryption module is used for acquiring the other encryption sections based on the second address information and decrypting the other encryption sections to obtain third original data of the other encryption sections.
The implementation process of the functions and actions of each unit in the above device is specifically described in the implementation process of the corresponding step in the above method, and is not described herein again.
For the device embodiments, since they substantially correspond to the method embodiments, reference may be made to the partial description of the method embodiments for relevant points. The above-described embodiments of the apparatus are merely illustrative, and the units described as separate parts may or may not be physically separate, and parts displayed as units may or may not be physical units, may be located in one place, or may be distributed on a plurality of network units. Some or all of the modules can be selected according to actual needs to achieve the purpose of the scheme of the application. One of ordinary skill in the art can understand and implement it without inventive effort.
The above description is only exemplary of the present application and should not be taken as limiting the present application, as any modification, equivalent replacement, or improvement made within the spirit and principle of the present application should be included in the scope of protection of the present application.
Claims (10)
1. A protection method of an SO file is characterized in that the SO file comprises a user-defined section area stored with a core function, and the user-defined section area is a section area to be encrypted; the method comprises the following steps:
determining whether a next section to be encrypted exists after the section to be encrypted;
and if the next section to be encrypted exists behind the section to be encrypted, inserting a first set identifier and address information of the next section to be encrypted at the specified position of the section to be encrypted, and encrypting the section to be encrypted to obtain a first encrypted section, wherein the first set identifier is used for indicating that the next encrypted section exists.
2. The method according to claim 1, wherein after said determining whether there is a next section to be encrypted after said section to be encrypted, further comprising:
and if the next section to be encrypted does not exist behind the section to be encrypted, inserting a second set identifier at the designated position of the section to be encrypted, and encrypting the section to be encrypted to obtain a second encrypted section, wherein the first set identifier is different from the second set identifier.
3. The method according to claim 1, wherein if the section to be encrypted is a first section to be encrypted, after encrypting the section to be encrypted to obtain a first encrypted section, the method further comprises:
and recording the offset address of the first encryption section area in an e _ entry field in a file header of the SO file, and recording the size of the first encryption section area in an e _ shoff field in the file header.
4. The method according to any one of claims 1 to 3, further comprising, after the encrypting the section to be encrypted to obtain a first encrypted section:
determining whether other sections to be encrypted exist after the next section to be encrypted;
if other sections to be encrypted exist behind the next section to be encrypted, inserting a first set identifier and address information of the other sections to be encrypted at the specified position of the next section to be encrypted, and encrypting the next section to be encrypted to obtain a third section to be encrypted;
and if no other section to be encrypted exists behind the next section to be encrypted, inserting a second set identifier at the specified position of the next section to be encrypted, and encrypting the next section to be encrypted to obtain a fourth section to be encrypted.
5. A method for protecting an SO file, wherein an encryption node area exists in the SO file, the method comprising:
decrypting the encrypted section area to obtain first original data of the encrypted section area;
if the designated position of the first original data comprises a first setting identifier, acquiring first address information of a next encryption section area at the designated position of the first original data, wherein the first setting identifier is used for indicating that the next encryption section area exists;
and acquiring the next encryption section area based on the first address information, and decrypting the next encryption section area to obtain second original data of the next encryption section area.
6. The method of claim 5, further comprising, after decrypting the next encrypted session region to obtain second original data of the next encrypted session region:
if the designated position of the second original data comprises the first setting identification, acquiring second address information of other encryption node areas at the designated position of the second original data;
and acquiring the other encryption sections based on the second address information, and decrypting the other encryption sections to obtain third original data of the other encryption sections.
7. A protection device for an SO file is characterized in that the SO file comprises a user-defined section area in which a core function is stored, wherein the user-defined section area is a section area to be encrypted; the device comprises:
the first determining module is used for determining whether a next section to be encrypted exists after the section to be encrypted;
the first encryption module is used for inserting a first setting identifier and address information of the next section to be encrypted at the designated position of the section to be encrypted if the next section to be encrypted exists behind the section to be encrypted, and encrypting the section to be encrypted to obtain a first encryption section, wherein the first setting identifier is used for indicating that the next encryption section exists.
8. The apparatus of claim 7, further comprising:
and the second encryption module is used for inserting a second set identifier at the designated position of the section to be encrypted and encrypting the section to be encrypted to obtain a second encryption section if the next section to be encrypted does not exist after the section to be encrypted, wherein the first set identifier is different from the second set identifier.
9. An apparatus for protecting an SO file, wherein an encryption section exists in the SO file, the apparatus comprising:
the first decryption module is used for decrypting the encrypted section area to obtain first original data of the encrypted section area;
a first data obtaining module, configured to obtain first address information of a next encryption node area at a specified position of the first original data if the specified position of the first original data includes a first setting identifier;
and the second decryption module is used for acquiring the next encryption section area based on the first address information and decrypting the next encryption section area to obtain second original data of the next encryption section area, and the first setting identifier is used for indicating that the next encryption section area exists.
10. The apparatus of claim 9, further comprising:
a second data obtaining module, configured to obtain second address information of another encryption node area at a specified position of the second original data if the specified position of the second original data includes the first setting identifier;
and the third decryption module is used for acquiring the other encryption sections based on the second address information and decrypting the other encryption sections to obtain third original data of the other encryption sections.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN201710671782.5A CN107577715B (en) | 2017-08-08 | 2017-08-08 | SO file protection method and device |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN201710671782.5A CN107577715B (en) | 2017-08-08 | 2017-08-08 | SO file protection method and device |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CN107577715A CN107577715A (en) | 2018-01-12 |
| CN107577715B true CN107577715B (en) | 2020-06-23 |
Family
ID=61035657
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN201710671782.5A Active CN107577715B (en) | 2017-08-08 | 2017-08-08 | SO file protection method and device |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN107577715B (en) |
Families Citing this family (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN109190336A (en) * | 2018-08-17 | 2019-01-11 | 中金金融认证中心有限公司 | A kind of method and system that the library So in Android application reinforces |
| CN115039096A (en) * | 2020-05-20 | 2022-09-09 | 深圳市欢太科技有限公司 | File processing method, file processing device, storage medium and electronic equipment |
Citations (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN102333236A (en) * | 2011-10-27 | 2012-01-25 | 中国华录集团有限公司 | Video content encryption and decryption system |
| CN106650327A (en) * | 2016-11-24 | 2017-05-10 | 湖南鼎源蓝剑信息科技有限公司 | so file dynamic recovery-based Android application reinforcement method |
Family Cites Families (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| EP2918038B1 (en) * | 2012-11-12 | 2017-10-25 | Secured2 Corporation | Systems and methods of transmitting data |
| US20140143553A1 (en) * | 2012-11-20 | 2014-05-22 | Cloudioh Inc. | Method and Apparatus for Encapsulating and Encrypting Files in Computer Device |
-
2017
- 2017-08-08 CN CN201710671782.5A patent/CN107577715B/en active Active
Patent Citations (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN102333236A (en) * | 2011-10-27 | 2012-01-25 | 中国华录集团有限公司 | Video content encryption and decryption system |
| CN106650327A (en) * | 2016-11-24 | 2017-05-10 | 湖南鼎源蓝剑信息科技有限公司 | so file dynamic recovery-based Android application reinforcement method |
Non-Patent Citations (1)
| Title |
|---|
| "一种文件分段加密方法及其应用";刘靖等;《指挥信息系统与技术》;20100831;第1卷(第4期);64-67 * |
Also Published As
| Publication number | Publication date |
|---|---|
| CN107577715A (en) | 2018-01-12 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN108664773B (en) | Method and device for protecting Java source code | |
| KR101391152B1 (en) | Method and apparatus for protecting digital contents stored in USB Mass Storage device | |
| CN104318135B (en) | A kind of Java code Safety actuality loading method based on credible performing environment | |
| KR102433011B1 (en) | Method of apk file protection, apk file protection system performing the same, and storage medium storing the same | |
| US8336109B2 (en) | Method and apparatus for processing rights object | |
| CN111143869B (en) | Application package processing method and device, electronic equipment and storage medium | |
| CN110147329B (en) | Method, device and terminal for dynamically detecting simulator | |
| CN104298932A (en) | Method and device for calling SO file | |
| CN107103214B (en) | Application program anti-debugging method and device applied to Android system | |
| US20110271350A1 (en) | method for protecting software | |
| CN107040520B (en) | Cloud computing data sharing system and method | |
| CN113010856A (en) | Dynamic asymmetric encryption and decryption JavaScript code obfuscation method and system | |
| CN110221990B (en) | Data storage method and device, storage medium and computer equipment | |
| WO2019062015A1 (en) | Source code protection method, application server, and computer-readable storage medium | |
| CN110334531B (en) | Virtual machine key management method, master node, system, storage medium and device | |
| CN107577715B (en) | SO file protection method and device | |
| CN113542187A (en) | File uploading and downloading method and device, computer device and medium | |
| CN112532379A (en) | File protection method and device | |
| CN111198692A (en) | Installation package generation method and device | |
| US20190199694A1 (en) | Individual encryption of control commands | |
| CN104866740A (en) | Static analysis preventing method and device for files | |
| CN107862210A (en) | Cipher processing method, system and computer equipment | |
| CN107592217A (en) | A kind of user identification method and device | |
| US10628561B2 (en) | Technique for enabling nominal flow of an executable file | |
| JP6215468B2 (en) | Program protector |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PB01 | Publication | ||
| PB01 | Publication | ||
| SE01 | Entry into force of request for substantive examination | ||
| SE01 | Entry into force of request for substantive examination | ||
| GR01 | Patent grant | ||
| GR01 | Patent grant |