CN111737680A

CN111737680A - Application program authorization method and device and computer equipment

Info

Publication number: CN111737680A
Application number: CN201911139510.6A
Authority: CN
Inventors: 李宗辉; 郝铮
Original assignee: Tencent Technology Shenzhen Co Ltd
Current assignee: Tencent Technology Shenzhen Co Ltd
Priority date: 2019-11-20
Filing date: 2019-11-20
Publication date: 2020-10-02
Anticipated expiration: 2039-11-20
Also published as: CN111737680B

Abstract

The disclosure provides an application program authorization method, an application program authorization device and computer equipment, and relates to the technical field of software development. The method comprises the following steps: acquiring a first execution file and a second execution file corresponding to a task code of an application program; acquiring a first address of the second execution file; modifying the first address entry in the first execution file from the second address to the first address to obtain a third execution file; when at least one second computer device is authorized, the third execution file and the authentication file are sent to the at least one second computer device, and the second execution file is injected into the first execution file, so that the task code and the authority check code of the application program can be independently modified or updated, the influence of the authority check code on the writing of the task code is prevented, and the manpower and material resources for software development are saved.

Description

Application program authorization method and device and computer equipment

Technical Field

The present disclosure relates to the field of software development technologies, and in particular, to an application program authorization method, an application program authorization device, and a computer device.

Background

Applications developed by software developers are generally divided into applications of the toB (to Business) type and applications of the toC (to Customer) type. For the toB type application program, in order to prevent the application program from being used by other users, a software developer transparently encrypts the application program, and after an enterprise acquires the application program, the enterprise needs to apply authorization to the software developer, and can normally use the application program only when receiving the authorization of the software developer.

In the related art, a software developer adds an authority verification code in a task code of an application program, and when an enterprise uses the application program, the task code is operated; and calling the authority verification code by operating the task code, verifying the use authority of the enterprise by executing the authority verification code, authorizing the related enterprise when the verification is passed, and enabling the enterprise to normally use the application program after the authorization is completed.

In the related art, because the permission verification code is bound with the task code, when the permission verification code needs to be updated, the updated permission verification code needs to be bound with the task code again, so that a related developer who writes the task code needs to write the task code again, the version of the application program is updated and released again, the workload of the related developer who writes the task code is increased, and manpower and material resources are wasted.

Disclosure of Invention

The embodiment of the disclosure provides an application program authorization method, an application program authorization device and computer equipment, which are used for solving the problems that when an authority check code needs to be updated, the updated authority check code needs to be bound with a task code again, so that a relevant developer writing the task code needs to write the task code again, an application program version is updated and released again, the workload of the relevant developer writing the task code is increased, and manpower and material resources are wasted. The technical scheme is as follows:

in one aspect, an application program authorization method is provided, and the method is applied to a first computer device, and the method includes:

the method comprises the steps of obtaining a first execution file corresponding to a task code of an application program and obtaining a second execution file corresponding to a permission check code, wherein the permission check code is used for calling an authentication file to carry out permission verification on second computer equipment when the second computer equipment runs the second execution file corresponding to the permission check code;

acquiring a first address of the second execution file;

modifying a first address entry in the first execution file from a second address to the first address to obtain a third execution file;

and when at least one second computer device is authorized, sending the third execution file and the authentication file to the at least one second computer device, wherein the at least one second computer device is used for acquiring the use permission of the application program by executing the third execution file and running the application program.

In a possible implementation manner, before the obtaining the first address of the second execution file, the method further includes:

adding a second address entry to the second execution file, the second address entry pointing to the second address;

adding the second execution file to the first execution file;

the obtaining the first address of the second execution file includes:

and acquiring a second address of the second execution file in the first execution file.

In another possible implementation manner, the method further includes:

when the change operation of changing the authority verification code is detected, a fourth execution file corresponding to the changed authority verification code is obtained;

and replacing the second execution file added in the third execution file with the fourth execution file to obtain an updated third execution file.

In another possible implementation manner, the method further includes:

when the application program operation fault is detected, deleting a second execution file injected in the third execution file;

modifying the first address in the third execution file into the second address to obtain the first execution file;

running the first execution file to determine a program bug;

repairing the program bug to obtain a repaired first execution file;

and re-injecting the second execution file into the repaired first execution file to obtain a repaired third execution file.

In another possible implementation manner, before the sending of the third execution file and the authentication file to the at least one second computer device, the method includes:

obtaining authorization time information and at least one device identifier, wherein the at least one device identifier is the device identifier of at least one computer device having the authority to use the application program;

and encrypting the authorization time information and the at least one equipment identifier according to the authority verification code to generate the authentication file.

In another aspect, an application program authorization method is provided, the method is applied to a second computer device, and the method includes:

receiving a third execution file and an authentication file which are sent by first computer equipment and correspond to an application program, wherein the third execution file is obtained by injecting a second execution file corresponding to a permission verification code into a first execution file corresponding to a task code of the application program;

when the third execution file is executed, calling the authentication file according to a second execution file injected in the third execution file;

and acquiring the use permission of the application program according to the authentication file.

In a possible implementation manner, a first address entry in a header file of the third execution file executes a second address of the second execution file;

when the third execution file is executed, invoking the authentication file according to a second execution file injected in the third execution file, including:

when the third execution file is executed, acquiring the second execution file according to a second address corresponding to a header file in the third execution file;

and executing the second execution file, and calling the authentication file through the second execution file.

In another possible implementation manner, the obtaining the usage right of the application program according to the authentication file includes:

acquiring the equipment identifier of the second computer equipment and acquiring at least one equipment identifier included in the authentication file;

and when the device identification of the second computer device exists in the at least one device identification, acquiring the use permission of the application program.

In another aspect, an apparatus for authorizing an application, the apparatus being applied to a first computer device, the apparatus comprising:

the system comprises a first acquisition module, a second acquisition module and a permission verification module, wherein the first acquisition module is used for acquiring a first execution file corresponding to a task code of an application program and acquiring a second execution file corresponding to a permission verification code, and the permission verification code is used for calling an authentication file to carry out permission verification on second computer equipment when the second computer equipment runs the second execution file corresponding to the permission verification code;

the second acquisition module is used for acquiring a first address of the second execution file;

a first modification module, configured to modify a first address entry in the first execution file from a second address to the first address, so as to obtain a third execution file;

and the sending module is used for sending the third execution file and the authentication file to at least one second computer device when authorization is carried out on the at least one second computer device, and the at least one second computer device is used for acquiring the use authority of the application program by executing the third execution file and running the application program.

In one possible implementation, the apparatus further includes:

a first adding module, configured to add a second address entry to the second execution file, where the second address entry points to the second address;

the second adding module is used for adding the second execution file into the first execution file;

the second obtaining module is further configured to obtain a second address of the second execution file in the first execution file.

In another possible implementation manner, the apparatus further includes:

the third acquisition module is used for acquiring a fourth execution file corresponding to the changed authority check code when the change operation of changing the authority check code is detected;

and the replacing module is used for replacing the second execution file added in the third execution file with the fourth execution file to obtain an updated third execution file.

In another possible implementation manner, the apparatus further includes:

the deleting module is used for deleting the second execution file injected in the third execution file when the application program is detected to have a fault in operation;

a second modification module, configured to modify the first address in the third execution file into the second address, so as to obtain the first execution file;

the determining module is used for operating the first execution file and determining program bugs;

the repairing module is used for repairing the program bug to obtain a repaired first execution file;

and the injection module is used for re-injecting the second execution file into the repaired first execution file to obtain a repaired third execution file.

In another possible implementation, the apparatus includes:

a fourth obtaining module, configured to obtain authorization time information and at least one device identifier, where the at least one device identifier is a device identifier of at least one computer device that has permission to use the application program;

and the encryption module is used for encrypting the authorization time information and the at least one equipment identifier according to the authority verification code to generate the authentication file.

In another aspect, an apparatus for authorizing an application program is provided, the apparatus being applied to a second computer device, the apparatus including:

the receiving module is used for receiving a third execution file and an authentication file which are sent by first computer equipment and correspond to an application program, wherein the third execution file is an execution file obtained by injecting a second execution file corresponding to a permission verification code into a first execution file corresponding to a task code of the application program;

the calling module is used for calling the authentication file according to a second execution file injected in the third execution file when the third execution file is executed;

and the fifth acquisition module is used for acquiring the use permission of the application program according to the authentication file.

In another possible implementation manner, a first address entry in a header file of the third execution file executes a second address of the second execution file;

the calling module is further configured to, when the third execution file is executed, obtain the second execution file according to a second address corresponding to a header file in the third execution file; and executing the second execution file, and calling the authentication file through the second execution file.

In another possible implementation manner, the fifth obtaining module is further configured to obtain a device identifier of the second computer device, and obtain at least one device identifier included in the authentication file; and when the device identification of the second computer device exists in the at least one device identification, acquiring the use permission of the application program.

In another aspect, a first computer device is provided, which includes a processor and a memory, where at least one instruction is stored, and the at least one instruction is loaded and executed by the processor to implement the application program authorization method according to any one of the method embodiments of the present disclosure that is performed by the first computer device.

In another aspect, a second computer device is provided, which includes a processor and a memory, where at least one instruction is stored, and the at least one instruction is loaded and executed by the processor to implement the application program authorization method according to any one of the method embodiments of the present disclosure that is performed by the second computer device.

In another aspect, a computer-readable storage medium is provided, where at least one instruction is stored, and the at least one instruction is loaded and executed by a processor to implement the application program authorization method according to any one of the method embodiments of the present disclosure that is performed by a first computer device.

In another aspect, a computer-readable storage medium is provided, where at least one instruction is stored, and the at least one instruction is loaded and executed by a processor to implement the application program authorization method according to any one of the method embodiments of the present disclosure that is performed by a second computer device.

The technical scheme provided by the embodiment of the disclosure has the following beneficial effects:

in the embodiment of the disclosure, the authority verification code is used for calling the authentication file to perform authority verification on the second computer device when the second computer device runs the second execution file corresponding to the authority verification code by acquiring the first execution file corresponding to the task code of the application program and acquiring the second execution file corresponding to the authority verification code; acquiring a first address of the second execution file; modifying the first address entry in the first execution file from the second address to the first address to obtain a third execution file; when at least one second computer device is authorized, the third execution file and the authentication file are sent to the at least one second computer device, the second execution file corresponding to the permission check code is injected into the first execution file to obtain the third execution file, the task code and the permission check code of the application program can be independently compiled and compiled respectively without mutual influence, so that the task code and the permission check code of the application program can be compiled by different software developers respectively, the task code and the permission check code of the application program can be independently modified or updated and the like, the influence of the permission check code on the compiling of the task code is prevented, and the manpower and material resources for software development are saved.

Drawings

In order to more clearly illustrate the technical solutions in the embodiments of the present disclosure, the drawings needed to be used in the description of the embodiments are briefly introduced below, and it is obvious that the drawings in the following description are only some embodiments of the present disclosure, and it is obvious for those skilled in the art to obtain other drawings based on the drawings without creative efforts.

FIG. 1 is an implementation environment in accordance with an application authorization method provided in accordance with an exemplary embodiment;

FIG. 2 is a schematic diagram of a flow of an application authorization method provided in accordance with an exemplary embodiment;

FIG. 3 is a schematic diagram of an organizational structure of an execution file provided in accordance with an exemplary embodiment;

FIG. 4 is a schematic diagram of an organizational structure of an execution file provided in accordance with an exemplary embodiment;

FIG. 5 is a schematic diagram of a header file of an execution file provided in accordance with an exemplary embodiment;

FIG. 6 is a schematic diagram of a flow of an application authorization method provided in accordance with an exemplary embodiment;

FIG. 7 is a schematic diagram illustrating a comparison between before and after encryption of an authentication file according to an exemplary embodiment;

FIG. 8 is a schematic illustration of a flow of an application authorization method provided in accordance with an exemplary embodiment;

FIG. 9 is a schematic illustration of a flow of an application authorization method provided in accordance with an exemplary embodiment;

FIG. 10 is a block diagram of an application authorization apparatus provided in accordance with an exemplary embodiment;

FIG. 11 is a block diagram of an application authorization apparatus provided in accordance with an exemplary embodiment;

fig. 12 is a schematic structural diagram of a terminal provided in accordance with an exemplary embodiment;

fig. 13 is a schematic diagram of a server according to an exemplary embodiment.

Detailed Description

To make the objects, technical solutions and advantages of the present disclosure more apparent, embodiments of the present disclosure will be described in detail with reference to the accompanying drawings.

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 implementations described in the exemplary embodiments below are not intended to represent all implementations consistent with the present disclosure. Rather, they are merely examples of apparatus and methods consistent with certain aspects of the present disclosure, as detailed in the appended claims.

Fig. 1 is a schematic diagram illustrating an implementation environment involved in an application authorization method according to an exemplary embodiment of the present disclosure. Referring to fig. 1, the implementation environment includes a first computer device 101 and at least one second computer device 102. Wherein, the first computer device 101 and the at least one second computer device 102 realize data interaction through network connection. Both the first computer device and the second computer device may be terminals or servers, which are not particularly limited in the embodiments of the present disclosure.

The at least one second computer device 102 obtains a third execution file corresponding to the application program through the first computer device 101. The application is a toB type application that is only allowed to be used by at least one second computer device 102 of an authorized enterprise. Therefore, when any of the second computer devices 102 is executing the third execution file, it is necessary to obtain the authorization of the application program.

The first address entry of the header file in the third execution file points to the first address where the second execution file is located, so that when any second computer device 102 executes the third execution file, the first address entry jumps to the first address, the second execution file stored at the first address is called, the second execution file is executed, the authentication file generated in advance is called through the second execution file, the use authority of the second computer device 102 is verified, and when the authentication file passes, the second computer device 102 is authorized, so that the rest part in the third execution file is executed, and the task of the application program is realized.

The first computer device 101 is configured to obtain a first execution file and a second execution file, and inject the second execution file into the first execution file to obtain a third execution file. In a possible implementation manner, the first computer device 101 may be a terminal for writing a task code and a permission check code for a software developer, and accordingly, when the task code and the full check code input by the software developer are obtained by the first computer device 101, the task code is compiled to obtain a first execution file, and the permission check code is compiled to obtain a second execution file, and the second execution file is injected into the first execution file to obtain a third execution file. In another possible implementation manner, the first computer device 101 is a server corresponding to the application program, and accordingly, the first computer device 101 may receive the compiled first execution file and the compiled second execution file, and inject the second execution file into the first execution file to obtain a third execution file.

The first computer device 101 is also arranged to generate an authentication file from the rights checking code. Correspondingly, before the first computer device 101 sends the third execution file to the at least one second computer device 102, the first computer device 101 obtains the device identifier of the at least one second computer device 102, and generates the authentication file according to the permission check code and the device identifier of the at least one second computer device 102. When the authentication file is used to perform the authority verification on the second computer device 102, authorization is performed on the second computer device 102 according to the device identifier of the second computer device 102 and at least one device identifier in the authentication file.

In addition, the application mentioned in the embodiment of the present disclosure may be an application applied in an embedded operating system, and may also be an application applied in a non-embedded operating system, which is not specifically limited in the embodiment of the present disclosure. For example, the operating system may be Linux (an Embedded operating system), VxWorks (an Embedded real-time operating system), Windows CE (Windows client Embedded, a modular real-time Embedded operating system), and the like. The open source database used by the embodiments of the present disclosure may be any database, for example, the database may be SQLite (a lightweight database).

In the embodiment of the disclosure, the second execution file corresponding to the permission check code is injected into the first execution file to obtain the third execution file, so that the task code and the permission check code of the application program can be independently compiled, respectively compiled and not influenced mutually, and thus the task code and the permission check code of the application program can be respectively compiled by different software developers, so that the task code and the permission check code of the application program can be independently modified or updated, and the influence of the permission check code on the compiling of the task code is prevented, thereby saving manpower and material resources for software development.

The injection mode for injecting the second execution file into the first execution file may be static injection or dynamic injection. The injecting the first execution file into the second execution file by the dynamic injection means that the first execution file dynamically calls the second execution file when executing, and the second execution file is dynamically injected into the first execution file by adding an API (Application Programming Interface) function to the first execution file and calling the second execution file by the API function, so as to obtain a third execution file. The step of injecting the first execution file into the second execution file in a static injection manner means that before the first execution file is executed, the second execution file is added into the first execution file by the second execution file to obtain a third execution file, and the first execution file and the second execution file are directly executed by executing the third execution file.

Fig. 2 is a flowchart of an application authorization method according to an exemplary embodiment, and in the embodiment of the present disclosure, a third execution file is obtained by statically injecting a second execution file into a first execution file by a first computer device. As shown in fig. 2, the method comprises the steps of:

step 201: the first computer device obtains a first execution file corresponding to the task code of the application program.

The first execution file is an execution file for realizing the task of the application program. The first execution file can be an execution file of task codes input by a user and received by the first computer device, or the first execution file can also be an execution file of task codes sent by a third computer device; the first execution file may also be an execution file obtained by compiling the task code by the first computer device. Wherein the task code may be a task code of an application written by a software developer through the first computer device.

The first execution file may be an Executable file in any Format, for example, the first execution file may be an ELF (Executable and Linkable Format) file or a PE (portable Executable) file. In the embodiment of the present disclosure, an ELF format file is taken as an example for description. The ELF file includes an organizational structure of a link format and an execution format. The execution file in the link format is a data storage format of a first execution file stored in the memory, and the execution file in the execution format is a storage format of data of the first execution file when the first execution file is executed in the computer device. Statically injecting the second execution file into the first execution file means that the second execution file is injected into the first execution file by changing an organization result in the first execution file in a connection format; the dynamic injection of the second execution file into the first execution file means that the second execution file is injected into the first execution file by changing the execution format of the first execution file in the execution process of the first execution file.

The organization structure of the link format of the ELF file is shown in fig. 3, and the link format of the first execution file includes an ELF Header (ELF Header), a Program Header Table (Program Header Table), a plurality of Section areas (Section), and a Section Header Table (Section Header Table).

The organization structure of the execution format of the ELF file is shown in fig. 4, and the execution format of the first execution file includes an ELF Header (ELF Header), a Program Header Table (Program Header Table), a plurality of segments (segment), and a Section Header Table (Section Header Table). A segment may contain at least one nodal region.

In the ELF files in both formats, the ELF header is located at the beginning of the file, and its location may be fixed, the ELF header includes the entry address of the execution file, and the entry address of the ELF header describes the organization of the execution file, so as to determine the execution sequence of the execution file during execution, and the like, and the ELF header may be the header file of the execution file, and in the embodiment of the present disclosure, the format of the header file is as shown in fig. 5. The section area may store information of the execution file, including instructions, data, symbol tables, relocation information, and the like.

Step 202: and the first computer equipment acquires a second execution file corresponding to the authority check code.

The authority check code is used for calling the authentication file to carry out authority verification on the second computer equipment when the second computer equipment runs the second execution file corresponding to the authority check code.

In this step, the process of the first computer device obtaining the first execution file corresponding to the task code of the application program in step 201 is similar, and is not described herein again.

It should be noted that the permission check code and the task code may be codes written by different software developers, and the first execution file and the second execution file may be execution files compiled by different software developers, so that the first computer device may send the permission check code and the task code to the first computer device through different other computer devices, which is not specifically limited in the embodiment of the present disclosure.

In the implementation mode, the task code and the permission check code of the application program can be respectively and independently acquired by respectively acquiring the first execution file corresponding to the task code and the second execution file corresponding to the permission check code, so that software developers writing the task code and the permission check code can work independently of each other, the influence of the permission check code on writing of the task code is prevented, and manpower and material resources for software development are saved.

Another point to be noted is that the first computer device may first obtain the first execution file, and then obtain the second execution file; the first computer device may also acquire the second execution file first and then acquire the first execution file; the first computer device may also obtain the first execution file and the second execution file simultaneously. Accordingly, the first computer device may first execute step 201 and then execute step 202, or may first execute step 202 and then execute step 201, and in the embodiment of the present disclosure, the order in which the first computer device executes step 201 and step 202 is not particularly limited.

When the first computer device receives the first execution file and the second execution file, it may detect whether the generation instruction is triggered, and when it is detected that the generation instruction is triggered, the first computer device executes step 203 to start generating a third execution file. The generation instruction can be a generation instruction directly triggered when the first computer device acquires the first execution file and the second execution file; the generation instruction may also be a generation instruction triggered when the first computer device detects that the user triggers the generation operation, which is not specifically limited in the embodiment of the present disclosure.

Step 203: the first computer device adds a second address entry to the second execution file, the second address entry pointing to a second address.

The second address entry is used for indicating the position of a section or segment where the next executed execution file is located in the execution process of the second execution file. For example, with continued reference to FIG. 3, the second address Entry may be "Entry pointaddress". The second address is an address corresponding to the first address entry in the header file of the first execution file when the first execution file is executed. The address may be an identification of the section or segment in which the execution file is located. For example, with continued reference to FIG. 3, the second address may be "0 × 42ce 00" corresponding to "Entry point address". The second address entry may be added at the end of the second execution file, so that after the second execution file is executed, the second execution file may jump to the first execution file again based on the second address entry to continue execution.

In one possible implementation, the first computer device may add a jump instruction at the end of the permission check code, by which a jump to the second address is implemented. Correspondingly, a second execution file added with a second address entry is directly obtained by compiling the authority check code, wherein the second address entry points to the second address. In the implementation mode, the jump instruction is added in the permission check code, so that the first computer equipment can directly obtain the second execution file added with the second address inlet by operating the permission check instruction, and the code segment corresponding to the second address inlet can be added when the permission check code is compiled, thereby preventing the subsequent modification of the permission check code and saving manpower and material resources for software development.

In another possible implementation manner, the first computer device may directly add a section area to an execution file corresponding to the authority check code, and directly add the second address to the section area to obtain a second execution file to which a second address entry is added. In the implementation mode, the section is added in the execution file corresponding to the authority check code, and the second address is added in the section, so that the subsequent modification of the authority check code is prevented, and the manpower and material resources for software development are saved.

Accordingly, prior to this step, the first computer device may obtain the second address. The second address may be a second address input by a software developer, and the second address may also be a second address determined by the first computer device according to an organization structure of the first execution file in the third execution files. Accordingly, in one possible implementation, the first computer device receives a user-entered second address, adds the second address to the second address entry. In the embodiment of the present disclosure, a manner of acquiring the second address entry by the first computer device is not particularly limited.

Step 204: the first computer device adds the second execution file to the first execution file.

In this step, the first computer device may add the second execution file to the section of the first execution file.

Wherein the first computer device may add a new section to the first execution file and add the second execution file to the new section. The first computer device may also be configured to store the second execution file directly in an existing section of the first execution file; the first computer device may further store the first execution file in another location where it is stored, and add the storage address of the second execution file to a section of the first execution file, where the section may be a new section or an existing section.

It should be noted that the first computer device may add the second address entry to the second execution file, and then add the second execution file to the first execution file; the first computer device may also add the second execution file to the first execution file, and then add the second address entry to the second execution file, and the first computer device may also add the second address entry to the second execution file and add the second execution file to the first execution file at the same time, that is, the first computer device may first perform step 203 and then perform step 204; the first computer device may also perform step 204 first and then step 203, and the first computer device may also perform

steps

203 and 204 simultaneously. In the embodiment of the present disclosure, the execution order of step 203 and step 204 is not particularly limited.

Step 205: the first computer device obtains a second address of the second execution file in the first execution file.

In this step, the first computer device determines the section identifier of the second execution file in the first execution file, and uses the section identifier as the second address of the second execution file in the first execution file.

Step 206: and the first computer equipment modifies the first address entry in the first execution file from the second address to the first address to obtain the third execution file.

In this step, the first computer device modifies the second address pointed by the first address entry in the header file of the first execution file into the first address, so that the header file of the first execution file can directly jump to the first address corresponding to the second execution file through the first address entry in the header file during the execution of the third execution file, and execute the second execution file.

After the first computer device generates the third execution file, the third execution file may be stored locally or in a server, and when an authorization request of the second computer device is received, the third execution file and the authentication file are sent to the second computer device.

In addition, after the third execution file is obtained, the first computer device may further receive a change of the permission check code by a software developer. In a possible implementation manner, the first computer device directly regenerates the third execution file according to step 201 and 206 according to the fourth execution file corresponding to the modified permission check code and the first execution file. In another possible implementation manner, the first computer device may further replace the second execution file in the third execution file with the fourth execution file, and generate a new third execution file. When the first computer device can also replace the second execution file in the third execution file with the fourth execution file to generate a new third execution file, the process can be implemented by the following steps (a1) - (a2), including:

(A1) and when the change operation of changing the authority check code is detected, the first computer equipment acquires a fourth execution file corresponding to the changed authority check code.

The change operation may be a trigger operation of an update button or an operation of uploading a new permission check code. In addition, the process of the first computer device acquiring the fourth execution file corresponding to the modified permission check code is similar to the process of the first computer device acquiring the second execution file, and is not repeated here.

(A2) And replacing the second execution file added in the third execution file by the fourth execution file by the first computer equipment to obtain an updated third execution file.

In this step, the first computer device deletes the second execution file from the third execution files and adds the fourth execution file to the first execution file. The process of adding the fourth execution file to the first execution file by the first computer device is similar to that in

step

203 and 206, and the process of adding the second execution file to the first execution file by the first computer device is similar to that in step 206, and is not described herein again.

In the implementation mode, the second execution file in the third execution file is changed, so that the task code does not need to be rewritten when the permission check code is changed, the generated task code and the permission check code of the application program can be updated respectively, the task code is prevented from being rewritten when the permission check code is updated, and manpower and material resources for software development are saved.

In addition, the first computer device may also only change the task code, and when updating or detecting the failure of the application program, the first computer device may restore the third execution file through a reverse operation to obtain a first execution file, update or take care of the length detection of the first execution file, and add the second execution file to the updated or repaired first execution file again to obtain an updated and repaired third execution file. For example, when the third execution file fails, the repair of the third execution file may be implemented by the following steps (B1) - (B5), including:

(B1) and when detecting that the application program runs in a fault, deleting the second execution file injected in the third execution file by the first computer equipment.

The first computer device may receive an operation failure notification sent by the second computer device, and when the first computer device receives the operation failure notification, it is determined that the application program operation failure is detected, and the first computer device repairs the third execution file.

The first computer device may directly delete the section where the second execution file is located, or the first computer device may only delete the second execution file in the section, which is not specifically limited in the embodiment of the present disclosure.

(B2) And the first computer equipment modifies the first address in the third execution file into the second address to obtain the first execution file.

In this step, the first computer device modifies the first address to the second address, thereby restoring the first execution file.

(B3) The first computer device runs the first execution file and determines the program bug.

The first computer device may execute the first execution file in steps to determine the program vulnerability. In a possible implementation manner, the first computer device displays an execution result of the first execution file, a software developer determines a program bug in the first execution file, inputs the program bug into the first computer device, and correspondingly, the first computer device receives the program bug input by the software developer. In another possible implementation, the first computer device may also train a machine learning model in advance, by which the bug in the first execution file that currently causes the fault is determined.

(B4) And the first computer equipment repairs the program bug to obtain a repaired first execution file.

The first computer device can display the program bug and receive a first execution file obtained by a software developer through the repairing operation of the program bug. The first computer device can also automatically repair the program bug to obtain a repaired first execution file.

(B5) And the first computer equipment reinjects the second execution file into the repaired first execution file to obtain a repaired third execution file.

This step is similar to the process in which the first computer device adds the second execution file to the first execution file in step 203-206 to obtain the third execution file, and is not repeated here.

In the implementation mode, the first execution file is restored, the first execution file in the third execution file is changed, and the permission check code is not rewritten when only the task code is changed, so that the generated task code and the permission check code of the application program can be updated respectively, the permission check code is prevented from being rewritten when the task code is modified or updated, and manpower and material resources for software development are saved.

Fig. 6 is a flowchart of an application authorization method according to an exemplary embodiment, which is described in the embodiment of the present disclosure by taking, as an example, that the second device obtains authorization of the application when using the application. As shown in fig. 6, the method comprises the steps of:

step 601: the first computer device sends the third execution file and the authentication file to the at least one second computer device when authorizing the at least one second computer device.

The authentication file includes at least one device identification, the at least one device identification being a device identification of at least one computer device allowed to use the application program.

Before this step, in a possible implementation manner, the first computer device acquires the at least one device identifier, and generates the authentication file according to the at least one device identifier and the permission check code.

In another possible implementation manner, the authentication file further includes authorization time information corresponding to at least one computer device that allows the application to be used, and accordingly, the process of generating the authentication file may be implemented through the following steps (1) - (2), including:

(1) the first computer device obtains authorization time information and at least one device identification.

In a possible implementation manner, the authorization time information includes at least a first time point and a second time point, where the first time point is a starting time point at which the at least one computer device that is allowed to use the application program is allowed to run the application program, and the second time point is an ending time point at which the at least one computer device that is allowed to use the application program is allowed to run the application program, that is, the at least one computer device that is allowed to use the application program may run the application program in the first time point and the second time point. For example, the first time point is 11/1/2019, and the second time point is 12/1/2019, the application can be used by the at least one computer device allowed to use the application from 11/1/2019 to 12/1/2019.

In another possible implementation manner, the authorization time information further includes a permitted usage time period permitted to use the application program, where the permitted usage time period may be determined according to the first time point and the second time point, and the permitted usage time period may be further input by the user. When the permitted use duration is the permitted use duration input by the user, the authorization time information may not include the first time point and the second time point, and correspondingly, when the authority of the second computer device is verified, the current time is determined as the first time point, and the time points after the permitted use duration are determined to be the second designated time point.

In the implementation manner, the allowable use duration is added in the authorization time information, so that the time information corresponding to the computer equipment is prevented from being adjusted when the computer equipment which allows the application program to be used reaches the second time point, and the authorization verification is more accurate.

In this step, the first computer device may receive device identifications transmitted by at least one computer device permitted to use the application program, respectively; the first computer device may further receive at least one device identifier input by a user, and use the at least one device identifier as a device identifier of at least one computer device that is allowed to use the application program, and the first computer device may further receive at least one device identifier forwarded by another computer device. In addition, the method for the first computer device to obtain the authorization time information is similar to the method for the first computer device to obtain the at least one device identifier, and is not described herein again.

(2) And the first computer equipment encrypts the authorization time information and the at least one equipment identifier according to the authority verification code to generate the authentication file.

The at least one second computer device is used for acquiring the use permission of the application program by executing the third execution file and running the application program. The authentication file may be a license file. In this step, the first computer device generates the authority check code according to the authority check code, and generates an authentication file that can be called by the authority check code.

In this embodiment of the present disclosure, when the SQLite database is used, the authentication file may encrypt data corresponding to the authentication file through a database engine layer of the SQLCipher (a software supporting SQLite). Referring to fig. 7, a comparison of the authentication file before encryption and the encrypted database is shown in fig. 7. Before encryption, a database table corresponding to the authentication file can be designed, see the following design:

where MACs represents the MAC (Media Access Control Address) of the authorized computer device. In addition, in the embodiment of the present disclosure, when the device identifier of the computer device is another identifier, another identifier of the computer device may also be used here, and this is not particularly limited in the embodiment of the present disclosure. The first computer device may authorize at least one computer device, and accordingly, the MAC address may also be at least one MAC address, and each MAC address in the at least one MAC address is directly divided by a semicolon. PRIMARY KEY uniquely identify each record in the database table for a constraint. For example, the first computer device allows 3 computer devices to use the application, the three applications having MAC addresses of 12: 12: 12: 12: 12: 12. 34: 34 and 34: 34: 34: 34, the data corresponding to the macs is 12: 12: 12: 12: 12: 12; 34: 34; 34: 34: 34: 34.

start _ time represents a first time point; the used _ time represents how much time the authentication file has been used, the end _ time represents a second point in time of expiration of the authentication file, the first point in time, the second point in time, and the used time are stored in the form of unix timestamps, and the value corresponding to the point in time is an Integer variable. Additionally, NOTCNULL is used to constrain the mandatory field to always contain a value.

In addition, it should be noted that before the first device generates the authentication file, format verification may be performed on the authorization time information and the at least one device identifier, as shown in fig. 8, when the data formats of the authorization time information and the at least one device identifier are correct, step (2) is performed, and when the data formats of the authorization time information and the at least one device identifier are incorrect, step (1) of receiving the authorization time information and the at least one device identifier is performed again.

In this implementation manner, the first computer device determines that a valid authentication file can be generated according to the authorization time information and the at least one device identifier by detecting the authorization time information and the data format of the at least one device identifier, so as to prevent a problem that the second computer device cannot be authorized correctly due to an invalid authentication file being generated by a data format error.

Step 602: and the second computer equipment receives the third execution file and the authentication file corresponding to the application program sent by the first computer equipment.

In this step, the second computer device may receive the third execution file first, and then receive the authentication file corresponding to the verification code in the third execution file, and the second computer device may also receive the third execution file and the authentication file at the same time, which is not specifically limited in this embodiment of the disclosure.

Step 603: and when the third execution file is executed, the second computer equipment acquires the second execution file according to the second address corresponding to the header file in the third execution file.

In this step, when the second computer device executes the third execution file, jumping to a second address where the second execution file is located through a first address entry in a header file of the third execution file, and obtaining the second execution file in the second address.

Step 604: the second computer device executes the second execution file, and calls the authentication file through the second execution file.

In this step, the second computer device executes the second execution file, generates a verification program for verifying the authority of the second computer device, and calls an authentication file corresponding to the authority check code of the second execution file through the verification program.

Referring to fig. 9, before this step, the second computer device may further detect whether an authentication file exists currently, and when the authentication file exists, execute this step; and when the authentication file does not exist, exiting the application program.

Step 605: the second computer device obtains a device identification of the second computer device.

With continued reference to fig. 9, in this step, the second computer device obtains a device identifier of the second computer device, where the device identifier may be a MAC address of the second computer device.

Step 606: the second computer device obtains at least one device identification included in the authentication file.

With continued reference to fig. 9, in this step, the second computer device decrypts the authentication file and reads at least one device identifier in the authentication file.

It should be noted that the second computer device may first obtain the device identifier of the second computer device, and then obtain at least one device identifier included in the authentication file; the second computer device may further obtain at least one device identifier included in the authentication file, and then obtain the device identifier of the second computer device; the second computer device may also obtain the device identifier of the second computer device and at least one device identifier included in the authentication file at the same time. That is, the second computer device may perform step 605 and then step 606; the second computer device may also perform step 606 first and then perform step 605, and the second computer device may also perform

steps

605 and 606 at the same time, which is not particularly limited in the embodiment of the present disclosure.

Step 607: and when the device identification of the second computer device exists in the at least one device identification, the second computer device acquires the use authority of the application program.

In this step, the second computer device detects whether the device identifier of the second computer device is in the at least one device identifier, and when the device identifier of the second computer device is in the at least one device identifier, the second computer device may continue to execute the third execution file and normally run the application program; and when the device identification of the second computer device is not in the at least one device identification, the second terminal does not execute other execution files in the third execution file and exits the application program.

It should be noted that, the authentication file may further include a first time point and a second time point, and correspondingly, with reference to fig. 9, when the second computer device executes the third execution file, it may further detect a current time point, detect whether the current time point is within the first time point and the second time point, and when the current time point is between the first time point and the second time point, determine that the second computer device is within a time range in which the application program is allowed to be used, and the second computer device may continue to execute the third execution file, and normally run the application program; and when the current time point is not between the first time point and the second time point, determining that the second computer equipment is not in the time range allowing the application program to be used, and the second terminal does not execute other execution files in the third execution files and exits the application program.

In this implementation manner, by adding the first time point and the second time point to the authorization time information, the second computer device is prevented from using the application program when the second computer device uses the application program to reach the second time point or the first time point is not reached yet, so that the authorization verification is more accurate.

It should be noted that, the authentication file may further include a permitted use duration, and accordingly, with reference to fig. 9, when the second computer device executes the third execution file, it may further detect a duration that the application program has been run in the second computer device, and when the duration that the application program has been run is not greater than the used duration, it is determined that the second computer device is within the time range that the application program is permitted to be used, and the second computer device may continue to execute the third execution file, and run the application program normally; and when the running time is longer than the used time range, determining that the second computer equipment is not in the time range allowing the application program to be used, not executing other execution files in the third execution file by the second terminal, and exiting the application program.

In addition, the authentication file may also include a first time point, a second time point, and a permitted usage duration at the same time, and correspondingly, with reference to fig. 9, when the second computer device executes the third execution file, it may further detect a current time point and a duration that the application program has been run in the second computer device, and when the duration that has been run is not greater than the used duration range and the current time point is within the first time point and the second time point, it is determined that the second computer device is within the time range that the application program is permitted to be used, and the second computer device may continue to execute the third execution file, and normally run the application program; and when the running time length is greater than the used time length range or the current time point is not in the first time point and the second time point, determining that the second computer equipment is not in the time range allowing the application program to be used, not executing other execution files in the third execution file by the second terminal, and exiting the application program.

In the implementation manner, the first time point, the second time point and the allowed use duration are added in the authorization time information, so that the time information corresponding to the computer equipment is prevented from being adjusted when the computer equipment allowed to use the application program reaches the second time point when the application program is used, and the authorization verification is more accurate.

Another point to be described is that, in the process of executing the third execution file, the second execution file may be called only once to authorize the second computer device once; the third execution file may also call the second execution file periodically, and perform periodic authorization on the second execution file, where the authorization period may be set and changed as needed, and in the embodiment of the present disclosure, the authorization period is not specifically limited. For example, the authorization period may be 60s, 120s, etc.

In this implementation, by periodically authorizing the second computer device, the usage duration of the second computer device is prevented from exceeding the usage duration allowed to use the computer device, so that the authorization verification is more accurate.

Fig. 10 is a block diagram of an application authorization apparatus provided in accordance with an example embodiment. Referring to fig. 10, the apparatus includes:

a first obtaining module 1001, configured to obtain a first execution file corresponding to a task code of an application program, and obtain a second execution file corresponding to a permission check code, where the permission check code is used to call an authentication file to perform permission verification on a second computer device when the second computer device runs the second execution file corresponding to the permission check code;

a second obtaining module 1002, configured to obtain a first address of the second execution file;

a first modification module 1003, configured to modify a first address entry in the first execution file from a second address to the first address, to obtain the third execution file;

a sending module 1004, configured to send the third execution file and the authentication file to at least one second computer device when authorization is performed on the at least one second computer device, where the at least one second computer device is configured to obtain a usage right of the application program by executing the third execution file, and run the application program.

In one possible implementation, the apparatus further includes:

the second obtaining module 1002 is further configured to obtain a second address of the second execution file in the first execution file.

In another possible implementation manner, the apparatus further includes:

the determining module is used for operating the first execution file and determining the program bug;

In another possible implementation, the apparatus includes:

Fig. 11 is a block diagram of an application authorization apparatus provided in accordance with an example embodiment. Referring to fig. 11, the apparatus includes:

a receiving module 1101, configured to receive a third execution file and an authentication file corresponding to an application program sent by a first computer device, where the third execution file is an execution file obtained by injecting a second execution file corresponding to a permission check code into a first execution file corresponding to a task code of the application program;

a calling module 1102, configured to, when the third execution file is executed, call the authentication file according to a second execution file injected in the third execution file;

a fifth obtaining module 1103, configured to obtain the usage right of the application according to the authentication file.

In another possible implementation manner, the first address entry in the header file of the third execution file executes the second address of the second execution file;

the calling module 1102 is further configured to, when the third execution file is executed, obtain the second execution file according to a second address corresponding to a header file in the third execution file; and executing the second execution file, and calling the authentication file through the second execution file.

In another possible implementation manner, the fifth obtaining module 1103 is further configured to obtain a device identifier of the second computer device, and obtain at least one device identifier included in the authentication file; and when the device identification of the second computer device exists in the at least one device identification, acquiring the use permission of the application program.

It should be noted that: the application authorization apparatus provided in the above embodiment is only illustrated by the division of the above functional modules when authorizing the application, and in practical applications, the above function distribution may be completed by different functional modules according to needs, that is, the internal structure of the apparatus is divided into different functional modules to complete all or part of the above described functions. In addition, the application program authorization apparatus provided in the above embodiments and the application program authorization method embodiments belong to the same concept, and specific implementation processes thereof are described in the method embodiments and are not described herein again.

Fig. 12 shows a block diagram of a terminal 1200 according to an exemplary embodiment of the present disclosure. The terminal 1200 may be: a smart phone, a tablet computer, an MP3 player (Moving Picture Experts Group Audio layer iii, motion video Experts compression standard Audio layer 3), an MP4 player (Moving Picture Experts Group Audio layer IV, motion video Experts compression standard Audio layer 4), a notebook computer, or a desktop computer. Terminal 1200 may also be referred to by other names such as user equipment, portable terminal, laptop terminal, desktop terminal, and so forth.

In general, terminal 1200 includes: a processor 1201 and a memory 1202.

The processor 1201 may include one or more processing cores, such as a 4-core processor, an 8-core processor, or the like. The processor 1201 may be implemented in at least one hardware form of a DSP (Digital Signal Processing), an FPGA (Field-Programmable Gate Array), and a PLA (Programmable Logic Array). The processor 1201 may also include a main processor and a coprocessor, where the main processor is a processor for processing data in an awake state, and is also called a Central Processing Unit (CPU); a coprocessor is a low power processor for processing data in a standby state. In some embodiments, the processor 1201 may be integrated with a GPU (Graphics Processing Unit) that is responsible for rendering and drawing content that the display screen needs to display. In some embodiments, the processor 1201 may further include an AI (Artificial Intelligence) processor for processing a computing operation related to machine learning.

Memory 1202 may include one or more computer-readable storage media, which may be non-transitory. Memory 1202 may also include high-speed random access memory, as well as non-volatile memory, such as one or more magnetic disk storage devices, flash memory storage devices. In some embodiments, a non-transitory computer readable storage medium in memory 1202 is used to store at least one instruction for execution by processor 1201 to implement the application authorization method provided by method embodiments in the present disclosure.

In some embodiments, the terminal 1200 may further optionally include: a peripheral interface 1203 and at least one peripheral. The processor 1201, memory 1202, and peripheral interface 1203 may be connected by a bus or signal line. Various peripheral devices may be connected to peripheral interface 1203 via a bus, signal line, or circuit board. Specifically, the peripheral device includes: at least one of radio frequency circuitry 1204, display 1205, camera assembly 1206, audio circuitry 1207, positioning assembly 1208, and power supply 1209.

The peripheral interface 1203 may be used to connect at least one peripheral associated with I/O (Input/Output) to the processor 1201 and the memory 1202. In some embodiments, the processor 1201, memory 1202, and peripheral interface 1203 are integrated on the same chip or circuit board; in some other embodiments, any one or two of the processor 1201, the memory 1202 and the peripheral device interface 1203 may be implemented on a separate chip or circuit board, which is not limited in this embodiment.

The Radio Frequency circuit 1204 is used for receiving and transmitting RF (Radio Frequency) signals, also called electromagnetic signals. The radio frequency circuit 1204 communicates with a communication network and other communication devices by electromagnetic signals. The radio frequency circuit 1204 converts an electric signal into an electromagnetic signal to transmit, or converts a received electromagnetic signal into an electric signal. Optionally, the radio frequency circuit 1204 comprises: an antenna system, an RF transceiver, one or more amplifiers, a tuner, an oscillator, a digital signal processor, a codec chipset, a subscriber identity module card, and so forth. The radio frequency circuit 1204 may communicate with other terminals through at least one wireless communication protocol. The wireless communication protocols include, but are not limited to: metropolitan area networks, various generation mobile communication networks (2G, 3G, 4G, and 5G), Wireless local area networks, and/or WiFi (Wireless Fidelity) networks. In some embodiments, the radio frequency circuit 1204 may further include NFC (Near Field Communication) related circuits, which are not limited by this disclosure.

The display screen 1205 is used to display a UI (User Interface). The UI may include graphics, text, icons, video, and any combination thereof. When the display screen 1205 is a touch display screen, the display screen 1205 also has the ability to acquire touch signals on or over the surface of the display screen 1205. The touch signal may be input to the processor 1201 as a control signal for processing. At this point, the display 1205 may also be used to provide virtual buttons and/or a virtual keyboard, also referred to as soft buttons and/or a soft keyboard. In some embodiments, the display 1205 may be one, providing the front panel of the terminal 1200; in other embodiments, the display 1205 can be at least two, respectively disposed on different surfaces of the terminal 1200 or in a folded design; in some embodiments, the display 1205 may be a flexible display disposed on a curved surface or on a folded surface of the terminal 1200. Even further, the display screen 1205 may be arranged in a non-rectangular irregular figure, i.e., a shaped screen. The Display panel 1205 can be made of LCD (Liquid Crystal Display), OLED (Organic Light-Emitting Diode), or other materials.

Camera assembly 1206 is used to capture images or video. Optionally, camera assembly 1206 includes a front camera and a rear camera. Generally, a front camera is disposed at a front panel of the terminal, and a rear camera is disposed at a rear surface of the terminal. In some embodiments, the number of the rear cameras is at least two, and each rear camera is any one of a main camera, a depth-of-field camera, a wide-angle camera and a telephoto camera, so that the main camera and the depth-of-field camera are fused to realize a background blurring function, and the main camera and the wide-angle camera are fused to realize panoramic shooting and VR (Virtual Reality) shooting functions or other fusion shooting functions. In some embodiments, camera assembly 1206 may also include a flash. The flash lamp can be a monochrome temperature flash lamp or a bicolor temperature flash lamp. The double-color-temperature flash lamp is a combination of a warm-light flash lamp and a cold-light flash lamp, and can be used for light compensation at different color temperatures.

The audio circuitry 1207 may include a microphone and a speaker. The microphone is used for collecting sound waves of a user and the environment, converting the sound waves into electric signals, and inputting the electric signals into the processor 1201 for processing or inputting the electric signals into the radio frequency circuit 1204 to achieve voice communication. For stereo capture or noise reduction purposes, multiple microphones may be provided at different locations of terminal 1200. The microphone may also be an array microphone or an omni-directional pick-up microphone. The speaker is used to convert electrical signals from the processor 1201 or the radio frequency circuit 1204 into sound waves. The loudspeaker can be a traditional film loudspeaker or a piezoelectric ceramic loudspeaker. When the speaker is a piezoelectric ceramic speaker, the speaker can be used for purposes such as converting an electric signal into a sound wave audible to a human being, or converting an electric signal into a sound wave inaudible to a human being to measure a distance. In some embodiments, the audio circuitry 1207 may also include a headphone jack.

The positioning component 1208 is used to locate a current geographic location of the terminal 1200 to implement navigation or LBS (location based Service). The positioning component 1208 may be a positioning component based on the GPS (global positioning System) in the united states, the beidou System in china, the graves System in russia, or the galileo System in the european union.

The power supply 1209 is used to provide power to various components within the terminal 1200. The power source 1209 may be alternating current, direct current, disposable or rechargeable. When the power source 1209 includes a rechargeable battery, the rechargeable battery may support wired or wireless charging. The rechargeable battery may also be used to support fast charge technology.

In some embodiments, terminal 1200 also includes one or more sensors 1210. The one or more sensors 1210 include, but are not limited to: acceleration sensor 1211, gyro sensor 1212, pressure sensor 1213, fingerprint sensor 1214, optical sensor 1215, and proximity sensor 1216.

The acceleration sensor 1211 can detect magnitudes of accelerations on three coordinate axes of the coordinate system established with the terminal 1200. For example, the acceleration sensor 1211 may be used to detect components of the gravitational acceleration in three coordinate axes. The processor 1201 may control the display screen 1205 to display the user interface in a landscape view or a portrait view according to the gravitational acceleration signal collected by the acceleration sensor 1211. The acceleration sensor 1211 may also be used for acquisition of motion data of a game or a user.

The gyro sensor 1212 may detect a body direction and a rotation angle of the terminal 1200, and the gyro sensor 1212 may collect a 3D motion of the user on the terminal 1200 in cooperation with the acceleration sensor 1211. The processor 1201 can implement the following functions according to the data collected by the gyro sensor 1212: motion sensing (such as changing the UI according to a user's tilting operation), image stabilization at the time of photographing, game control, and inertial navigation.

Pressure sensors 1213 may be disposed on the side frames of terminal 1200 and/or underlying display 1205. When the pressure sensor 1213 is disposed on the side frame of the terminal 1200, the user's holding signal of the terminal 1200 can be detected, and the processor 1201 performs left-right hand recognition or shortcut operation according to the holding signal collected by the pressure sensor 1213. When the pressure sensor 1213 is disposed at a lower layer of the display screen 1205, the processor 1201 controls the operability control on the UI interface according to the pressure operation of the user on the display screen 1205. The operability control comprises at least one of a button control, a scroll bar control, an icon control and a menu control.

The fingerprint sensor 1214 is used for collecting a fingerprint of the user, and the processor 1201 identifies the user according to the fingerprint collected by the fingerprint sensor 1214, or the fingerprint sensor 1214 identifies the user according to the collected fingerprint. When the user identity is identified as a trusted identity, the processor 1201 authorizes the user to perform relevant sensitive operations, including unlocking a screen, viewing encrypted information, downloading software, paying, changing settings, and the like. The fingerprint sensor 1214 may be provided on the front, back, or side of the terminal 1200. When a physical button or vendor Logo is provided on the terminal 1200, the fingerprint sensor 1214 may be integrated with the physical button or vendor Logo.

The optical sensor 1215 is used to collect the ambient light intensity. In one embodiment, the processor 1201 may control the display brightness of the display 1205 according to the ambient light intensity collected by the optical sensor 1215. Specifically, when the ambient light intensity is high, the display luminance of the display panel 1205 is increased; when the ambient light intensity is low, the display brightness of the display panel 1205 is turned down. In another embodiment, processor 1201 may also dynamically adjust the camera head 1206 shooting parameters based on the ambient light intensity collected by optical sensor 1215.

A proximity sensor 1216, also known as a distance sensor, is typically disposed on the front panel of the terminal 1200. The proximity sensor 1216 is used to collect a distance between the user and the front surface of the terminal 1200. In one embodiment, when the proximity sensor 1216 detects that the distance between the user and the front surface of the terminal 1200 gradually decreases, the processor 1201 controls the display 1205 to switch from the bright screen state to the dark screen state; when the proximity sensor 1216 detects that the distance between the user and the front surface of the terminal 1200 gradually becomes larger, the processor 1201 controls the display 1205 to switch from the breath-screen state to the bright-screen state.

Those skilled in the art will appreciate that the configuration shown in fig. 12 is not intended to be limiting of terminal 1200 and may include more or fewer components than those shown, or some components may be combined, or a different arrangement of components may be used. The terminal 1200 may be a first computer device or a second computer device.

Fig. 13 is a schematic structural diagram of a server according to an embodiment of the present disclosure, where the server 1300 may generate a relatively large difference due to different configurations or performances, and may include one or more processors (CPUs) 1301 and one or more memories 1302, where the memory 1302 stores at least one instruction, and the at least one instruction is loaded and executed by the processor 1301 to implement the methods provided by the foregoing method embodiments. Certainly, the computer device may further have components such as a wired or wireless network interface, a keyboard, and an input/output interface, so as to perform input and output, and the computer device may further include other components for implementing the functions of the device, which is not described herein again. The server may be the first computer device or the second computer device.

In an exemplary embodiment, a computer-readable storage medium is further provided, in which at least one instruction is stored, and the at least one instruction is loaded and executed by a server to implement the application program authorization method in the foregoing embodiments. The computer readable storage medium may be a memory. For example, the computer readable storage medium may be a ROM, a Random Access Memory (RAM), a CD-ROM, a magnetic tape, a floppy disk, an optical data storage device, and the like.

It will be understood by those skilled in the art that all or part of the steps for implementing the above embodiments may be implemented by hardware, or may be implemented by a program instructing relevant hardware, and the program may be stored in a computer-readable storage medium, and the above-mentioned storage medium may be a read-only memory, a magnetic disk or an optical disk, etc.

The above description is intended to be exemplary only and not to limit the present disclosure, and any modification, equivalent replacement, or improvement made without departing from the spirit and scope of the present disclosure is to be considered as the same as the present disclosure.

Claims

1. An application program authorization method, the method being applied to a first computer device, the method comprising:

acquiring a first address of the second execution file;

2. The method of claim 1, wherein prior to obtaining the first address of the second execution file, the method further comprises:

adding the second execution file to the first execution file;

the obtaining the first address of the second execution file includes:

3. The method of claim 2, further comprising:

4. The method of claim 2, further comprising:

running the first execution file to determine a program bug;

repairing the program bug to obtain a repaired first execution file;

5. The method of claim 1, wherein prior to said sending said third execution file and said authentication file to said at least one second computer device, said method comprises:

6. An application program authorization method, the method being applied to a second computer device, the method comprising:

7. The method of claim 6, wherein a first address entry in a header file of the third execution file performs the second address of the second execution file;

8. An apparatus for authorizing an application, the apparatus being applied to a first computer device, the apparatus comprising:

9. An apparatus for authorizing an application, the apparatus being applied to a second computer device, the apparatus comprising:

10. A computer device comprising a processor and a memory, the memory having stored therein at least one instruction, the at least one instruction being loaded and executed by the processor to implement the application authorization method of any of claims 1 to 5, or the at least one instruction being loaded and executed by the processor to implement the application authorization method of any of claims 6 to 7.