CN116305011A

CN116305011A - Application program protection method and installation method

Info

Publication number: CN116305011A
Application number: CN202310281381.4A
Authority: CN
Inventors: 沈涛
Original assignee: Shanghai Bilibili Technology Co Ltd
Current assignee: Shanghai Bilibili Technology Co Ltd
Priority date: 2023-03-20
Filing date: 2023-03-20
Publication date: 2023-06-23

Abstract

The application provides a protection method of an application program, which comprises the following steps: obfuscating program code of an application program to obtain a first obfuscated file; encrypting the first confusion file to obtain an encrypted file; acquiring a decryption entry code for the encrypted file; obfuscating the decryption entry code to obtain a second obfuscated file; converting the second obfuscated file into a bytecode entry file; and obtaining an installation package according to the encrypted file and the byte code entry file, wherein the installation package is used for providing the client. The technical scheme provided by the application program protection method and device can avoid the application program from being sleeved, implanted and tampered as much as possible, and realize the protection of the application program.

Description

Application program protection method and installation method

Technical Field

The embodiments of the present application relate to the field of computer technologies, and in particular, to a protection method for an application program, an installation method for an application program, a protection device, an installation device, a computer device, and a computer readable storage medium.

Background

With the development of computer technology, applications based on various operating system environments are produced in large numbers. For example, electronics provide an open source software framework for cross-platform desktop applications. The electronics mainly comprise a main process and a rendering process, and Web technologies such as HTML, CSS, javaScript and the like can be used for constructing the application program, so that development of the cross-platform desktop GUI application program is completed. That is, developers can build cross-platform desktop applications using Web development techniques for use on multiple operating systems, such as Windows, macOS and Linux.

Currently, installation packages such as the above applications are easily sleeved, implanted or tampered with, with certain safety concerns.

It should be noted that the foregoing is not necessarily prior art, and is not intended to limit the scope of the patent protection of the present application.

Disclosure of Invention

An object of an embodiment of the present application is to provide a protection method, an installation method, a protection apparatus, an installation apparatus, a computer device, and a computer-readable storage medium for solving or alleviating the above-described problems.

An aspect of an embodiment of the present application provides a method for protecting an application program, where the method includes:

obfuscating program code of an application program to obtain a first obfuscated file;

encrypting the first confusion file to obtain an encrypted file;

acquiring a decryption entry code for the encrypted file;

obfuscating the decryption entry code to obtain a second obfuscated file;

converting the second obfuscated file into a bytecode entry file; a kind of electronic device with high-pressure air-conditioning system

And obtaining an installation package according to the encrypted file and the byte code entry file, wherein the installation package is used for providing the client.

Optionally, the byte code entry file has a plurality of byte code entry files; the method further comprises the steps of:

Generating an execution entry file according to an operating system and/or a system architecture; wherein:

the execution entry file is used for: and selecting a target byte code entry file from a plurality of byte code entry files according to the system environment of the client.

Optionally, the method further comprises:

after the application program is constructed, generating a hash value of the application program according to the file in the application program.

Optionally, the method further comprises:

generating an application key for the application program; wherein the application key is used to identify and verify the identity of the application.

Another aspect of an embodiment of the present application provides a protection device for an application program, including:

the first confusion module is used for carrying out confusion on the program codes of the application program to obtain a first confusion file;

the encryption module is used for carrying out encryption operation on the first confusion file to obtain an encrypted file;

a first acquisition module that acquires a decryption entry code for the encrypted file;

the second confusion module carries out confusion on the decryption entry codes to obtain a second confusion file;

the conversion module is used for converting the second confusion file into a byte code entry file; a kind of electronic device with high-pressure air-conditioning system

And the second acquisition module is used for obtaining an installation package according to the encrypted file and the byte code entry file, wherein the installation package is used for being provided for the client.

Another aspect of the embodiments of the present application provides an installation method of an application program, including:

under the condition that an installation package of an application program is obtained, acquiring a target byte code entry file in the installation package; a kind of electronic device with high-pressure air-conditioning system

According to the target byte code entry file, decrypting the encrypted file in the installation package to obtain the program code of the application program; wherein the target bytecode entry file is transcoded based on a decryption entry.

Optionally, the decrypting the encrypted file in the installation package according to the target byte code entry file to obtain the program code of the application program includes:

loading the target byte code entry file to obtain a decryption instance;

and decrypting the encrypted file through the decryption example to obtain the program code.

Optionally, the program code includes an application key and/or a hash value of the application program; correspondingly, the method further comprises:

verifying the application program according to the application key and/or the hash value;

If the application program does not pass the verification, the application program is exited; a kind of electronic device with high-pressure air-conditioning system

And starting and running the application program under the condition that the application program passes the verification.

Optionally, the installation package includes an execution entry file and a plurality of bytecode entry files; correspondingly, the obtaining the target byte code entry file in the installation package includes:

executing the execution entry file, and determining an operating system and/or a system frame of the client through the execution entry file; a kind of electronic device with high-pressure air-conditioning system

And selecting the target byte code entry file from the plurality of byte code entry files according to the operating system and/or system framework of the client.

Another aspect of an embodiment of the present application provides an installation apparatus for an application program, including:

the method comprises the steps that an acquisition module acquires a target byte code entry file in an installation package of an application program under the condition that the installation package of the application program is obtained; a kind of electronic device with high-pressure air-conditioning system

The decryption module is used for performing decryption operation on the encrypted file in the installation package according to the target byte code entry file so as to obtain the program code of the application program; wherein the target bytecode entry file is transcoded based on a decryption entry.

Another aspect of an embodiment of the present application provides a computer device, comprising:

at least one processor; a kind of electronic device with high-pressure air-conditioning system

A memory communicatively coupled to the at least one processor;

wherein: the memory stores instructions executable by the at least one processor to enable the at least one processor to perform the method as described above.

Another aspect of the embodiments provides a computer-readable storage medium having stored therein computer instructions which, when executed by a processor, implement a method as described above.

The technical scheme provided by the embodiment of the application is to increase the difficulty of being sleeved, implanted and tampered, and improve the safety of an application program. Program code may be prevented from reverse engineering decryption by confusion and encryption operations. The encrypted file may be decrypted by decrypting the entry code, which in turn increases the difficulty of the attacker to analyze the code by confusion and bytecode conversion. And then, generating an installation package according to the encrypted file and the byte code entry file for the client to use. In the client, the client machine itself may decrypt the encrypted file according to the bytecode entry file, thereby enabling installation and running of the application. However, because the installation package combines the processing modes of code confusion, encryption, byte codes and the like, an attacker is difficult to reversely engineer to obtain the original code, thereby avoiding the application program from being sheathed, implanted and tampered as much as possible and realizing the effective protection of the application program.

Drawings

FIG. 1 (A) schematically illustrates an operating environment diagram of a method of protecting an application program according to a first embodiment of the present application;

FIG. 1 (B) schematically illustrates an overall framework of an application program according to embodiment one of the present application;

FIG. 1 (C) schematically shows a process timing diagram of an optimization flow of an application;

FIG. 1 (D) schematically illustrates interface changes based on an optimization procedure;

fig. 1 (E) schematically shows a schematic diagram in a small window mode;

FIG. 2 schematically illustrates a flow chart of a method of protecting an application according to an embodiment of the present application;

fig. 3 schematically shows a flowchart of an installation method of an application according to a second embodiment of the present application;

FIG. 4 schematically illustrates an installation process;

fig. 5 schematically shows a block diagram of a protection device of an application according to a third embodiment of the present application;

fig. 6 schematically shows a block diagram of an installation apparatus of an application program according to a fourth embodiment of the present application; a kind of electronic device with high-pressure air-conditioning system

Fig. 7 schematically shows a hardware architecture diagram of a computer device according to a fifth embodiment of the present application.

Detailed Description

In order to make the objects, technical solutions and advantages of the present application more apparent, the present application will be further described in detail with reference to the accompanying drawings and examples. It should be understood that the specific embodiments described herein are for purposes of illustration only and are not intended to limit the present application. All other embodiments, which can be made by one of ordinary skill in the art without undue burden from the present disclosure, are within the scope of the present disclosure.

It should be noted that the descriptions of "first," "second," etc. in the embodiments of the present application are for descriptive purposes only and are not to be construed as indicating or implying a relative importance or implicitly indicating the number of technical features indicated. Thus, a feature defining "a first" or "a second" may explicitly or implicitly include at least one such feature. In addition, the technical solutions of the embodiments may be combined with each other, but it is necessary to base that the technical solutions can be realized by those skilled in the art, and when the technical solutions are contradictory or cannot be realized, the combination of the technical solutions should be regarded as not exist and not within the protection scope of the present application.

In the description of the present application, it should be understood that the numerical references before the steps do not identify the order of performing the steps, but are only used for convenience in describing the present application and distinguishing each step, and thus should not be construed as limiting the present application.

First, a term explanation is provided in relation to the present application:

electron: is the open source software framework developed by GitHub for building cross-platform desktop applications. The electronics can construct application programs based on node. Js (corresponding to a main process) and a colorium rendering engine (corresponding to a rendering process) by using Web technologies such as HTML, CSS, javaScript (client script) and the like, and the development of cross-platform desktop GUI application programs is completed. That is, developers can build cross-platform desktop applications using Web development techniques for use on multiple operating systems, such as Windows, macOS and Linux.

Github, an online software source code hosting service platform.

HTML (HyperText Markup Language ) is a markup language used to create Web pages. HTML is used to describe the structure and content of elements in Web pages, such as text, pictures, links, forms, videos, and the like, and to provide tags and attributes for these elements so that the browser can properly display.

CSS (Cascading Style Sheet ), is a style sheet language used to define element styles and layouts in HTML (or XML) documents. By using CSS, web page designers can better control the appearance and layout of documents, thereby realizing richer, more aesthetically pleasing, and easier to manage Web pages.

JavaScript, a scripting language, is used to develop front-end and back-end applications.

The GUI (Graphical User Interface ) is an interface that graphically presents a program or system to a user, allowing the user to interact with the program or system through an intuitive graphical interface. GUIs typically use graphical controls such as windows, menus, buttons, text boxes, etc. to enable interaction between a user and a program.

The electronic-builder is an electronic-based cross-platform software packaging and distribution tool and is used for helping developers to package electronic application programs into executable files, installation packages, compression packages and other various forms, supporting cross-platform packaging and packaging application programs of Windows, mac and Linux platforms. The Electron-builder can automatically process the differences of different platforms, including file systems, operating systems, third party libraries and the like. Electron-builder may also provide a number of configuration options for helping developers customize the packaging process. In the Electron-builder, the package and configuration information for the item are stored in a file named package. The package. Json file is a node. Js project configuration file, and may include various metadata, dependencies, and construction scripts of an application program, which are used to determine how to construct the application program.

NPM (Node Package Manager), tools for managing dependencies, building and packaging applications.

postnstall/postuninstall are NPM script commands.

The afterallArtifactbuilding is a task or script that runs after all the application programs are built.

A hook, referring to a predefined function or method, may be triggered at certain specific points in the life cycle of the program.

Vue, a progressive framework for building user interfaces, focuses on the view layer.

SPA (Single Page Application), which is a Web application development mode, can put all contents in a single HTML page, and dynamically update the contents by using JavaScript and AJAX technologies, so that the problem of refreshing pages multiple times by the conventional Web application can be avoided. SPA is implemented using a front-end framework such as Angular, react, vue, etc., with the back-end providing RESTful API interfaces to provide data services.

An open Page (Splash Page), also known as a start Page, welcome Page, refers to the first Page displayed when the App starts.

Main Page (Main Page), also called Main interface, main interface Page, refers to the initial Page of the function set in the mobile application program, and is usually the Main entry, presentation interface and interaction interface of the App function. The home page is created according to specific needs and designs and typically contains page elements such as various functional menus, buttons, search bars, etc. of the application.

Hierarchical relationships may also exist between different pages, with pages of a higher hierarchy overlaying pages of a lower hierarchy.

A shell refers to a process of embedding an application into another application.

Implantation refers to the process of adding new code, libraries, or components in an application.

Tampering, which refers to the process of modifying an application, may be for illegal purposes, such as the production of malware or pirate software.

v8 bytecode, which is a bytecode used by v8 engines developed by Google, is a low-level, interpreted binary code that can be directly executed in v8 engines. After the JavaScript code is compiled in the v8 engine, v8 bytecode is generated and operation instructions and data of the JavaScript code are included.

Eval, a function in JavaScript language, can execute dynamically generated code strings and execute dynamically generated codes.

WebAsssembly is a low-level bytecode that can run on different types of devices, with security and portability.

Js is a cross-platform running environment capable of writing JavaScript code at the server side.

Nest. Js, a node. Js-based framework that provides a set of tools and modules to help developers build scalable, modular, and easy-to-maintain Web applications and services

Esbuild, is a fast, extensible build tool for building JavaScript and TypeScript applications.

Vue3, a JavaScript framework, is used to create a user interface.

Vite2 is a fast build tool for the development of modern Web applications.

TypeScript, an open source programming language, is a superset of JavaScript.

Next, in order to facilitate a person skilled in the art to understand the technical solutions provided in the embodiments of the present application, the following related art is described:

electron acts as an open source software framework for cross-platform desktop applications, which can be used in a variety of devices. An installation package for an application generally includes: application code files (e.g., JS code, CSS code, etc.), package. Json files, etc. The application code file is easily removed from the case, implanted, or tampered with by a person. Naturally, the package json file contains dependency and script information, and leakage of technical information is also easy to occur.

Therefore, the embodiment of the application provides a new scheme, and the problems that application program codes are easy to be sleeved, implanted or tampered and the like can be solved.

Fig. 1 (a) schematically shows an environmental operation diagram of a protection method of an application program according to an embodiment of the present application. As shown in fig. 1 (a), the environment schematic includes a development platform 2, a server 4, and a client 6, wherein:

The development platform 2 may be a workstation, a personal computer, a virtual instance in a cloud platform, etc., and provides a development environment and a development interface for a user. The development platform 2 may run a Windows system, an IOS system, or a Unix system, etc. After the development platform 2 develops the application (installation package), it can distribute through the server 4.

The server 4, as a storage platform, may be constituted by a plurality of computing devices. The plurality of computing devices may include virtualized computing instances. Virtualized computing instances may include virtual machines such as emulation of computer systems, operating systems, servers, and the like. The computing device may load the virtual machine based on a virtual image and/or other data defining particular software (e.g., operating system, dedicated application, server) for emulation. As the demand for different types of processing services changes, different virtual machines may be loaded and/or terminated on one or more computing devices. A hypervisor may be implemented to manage the use of different virtual machines on the same computing device.

The server 4 may provide services such as storage, distribution of application programs, etc.

The server 4 may be configured to communicate with the development platform 2, clients 6, etc. over a network.

The client 6 may be provided with a user access page, or may automatically download an installation package from the server 4 to perform software update, or the like.

Wherein an optimized application may be provided at the development platform 2 or the client 6, the application processing may be based on an Electron framework.

The application is described below in terms of its overall architecture and construction, playback experience optimization, and code security.

And (one) the whole architecture, construction and upgrading of the application program.

As shown in fig. 1 (B), the overall architecture may include a main service layer 100, a rendering layer 200, and a JSB unified interface 300.

The application program is mainly divided into a Main Process (Main Process) and a rendering Process (Render Process), the Main Process (corresponding to the Main service layer 100) may be node. Js and native API, the rendering Process (Render layer 200) is mainly a front-end technology, and the Main Process and the rendering Process are communicated through the JSB unified interface 300. For the purposes of easy maintenance, good expansion, reusability and the like, a scheme of NodeJs+NestJs+Esbuild can be selected to develop a main process, and Vue3+Vite2+TypeScript is selected to develop a rendering process. Of course, other techniques may be used.

The application program can have the conventional functions of recommendation, live broadcast, popular, OGV (Occupationally Generated Video, professional production content), dynamic, space, search and the like, and needs other capabilities of local software of a computer end, such as installation and upgrading, tray hiding, local storage, proprietary windows, offline cache, custom configuration and call end pull-out.

Specific:

(1) The main service layer 100 is configured to run in a main process and provide an underlying service of an application program.

In an Electron environment, the main process runs in the background of the Electron framework. The main process is responsible for executing the underlying services. As an example, as shown in fig. 1 (B), the underlying service may include: window management service, configuration service, event service, API request service, general public service, account service, reporting service, upgrading and updating service, video downloading service, local storage service, local file service, gray experiment service and other various bottom layer services. The host process may also access underlying resources such as file systems, networks, operating systems, etc. through APIs. In practical application, the adjustment of the service may be performed according to actual needs.

The underlying services may include:

a first class of services, the first class of services being services that introduce dependencies;

and the second class of services are mutually called in an injection mode or a theme subscription mode.

In practical applications, new services may be added as needed, and the services may be classified into different categories.

For example, services such as local logging, local storage, and SDK download may introduce dependencies. By introducing dependencies, various external libraries and SDKs can be used to accomplish specified functions, thereby achieving more functionality and better performance.

For another example, various services such as the window management service and the configuration service can be mutually invoked in a manner of injection or RxJS topic subscription. Where injection refers to injecting an instance of one service into another service in order to invoke the former in the latter. The RxJS topic subscription refers to the use of subjects or Observable objects provided in the RxJS library to enable messaging and subscription between individual services. A Subject or an Observable object may be subscribed to by multiple services. If a Subject or an Observable object changes, all services subscribed to it are notified. This approach is typically used to achieve loose coupling between multiple services.

As above, by introducing dependency, injection, topic subscription and the like, different services can be realized, and the service efficiency and flexibility are improved.

(2) And the rendering layer 200 is used for running in a rendering process and providing display and interaction of pages in the application program.

In an Electron environment, the rendering process corresponds to a window page, responsible for rendering and presenting user interfaces, such as windows, menus, dialog boxes, and the like. The rendering process uses the browser kernel to interpret and execute HTML, CSS, javaScript, etc.

The window page is a main window in the Electron application for displaying a user interface of the application. The window page may call a native API provided by the Electron, such as creating a new window, displaying a system notification, controlling a menu bar, and so forth.

It should be noted that, the application program is developed based on Electron and WEB technologies, and the window page and the HTML page are essentially realized by WEB technologies such as HTML, CSS and JavaScript, and one window page is essentially an HTML page. In addition, the HTML page can be a local page pulled from a local server, and even if the network is disconnected, the application program can respond and display corresponding prompt information. The page (home page) with strong correlation to the network can display failure prompt when the network is disconnected, but the functions of offline caching, setting and the like can be used.

In an optional embodiment, the rendering layer includes various pages such as a local page and an embedded page, so as to promote the richness of the page.

As shown in fig. 1 (B), the rendering layer may include: local pages such as recommendation, live broadcast, popular sitcoms, movies, dynamic, my, spatial messages, settings, search, play list, player, etc. The method can also comprise account login, recharging, live details, and embedded pages such as open broadcasting. The embedded page may be implemented by < iframe >, < webview >, etc. In practical application, the page may be adjusted according to actual needs.

(3) A JSB unified interface 300 for providing communication between the host process and the rendering process.

The JSB unified interface is as follows: injecting JSB objects into window objects of pages of the rendering process by the main process in a preloading (preloading) mode so that the plurality of pages can access the JSB objects.

In an Electron environment, a main process and a rendering process realize data transmission and function call through IPC communication. It is currently known that the current IPC interaction layer is very difficult to maintain, especially in large programs. In this embodiment, IPC is replaced by a JSB unified interface, and communication between the two is performed through the JSB unified interface.

Based on the above architecture, in order to enable pages in the rendering process to directly access the API of the main process, a JSB object is created in the main process, and then the JSB object of the main process is injected into each page in the rendering process through a preload mechanism. Thus, the page can realize communication between the main process and the rendering process through the JSB object, so that the complexity of communication between the main process and the rendering process is simplified, and further, the development and maintenance cost is reduced.

In an alternative embodiment, the rendering layer includes a local page and an embedded page. Correspondingly, the JSB unified interface is further configured to: injecting the JSB object into the local page and the embedded page. In this alternative embodiment, direct communication of various parent, child pages and host processes, including embedded pages, may be implemented.

Based on the functional partitioning above, the main service layer 100 (corresponding to the main process), the rendering layer 200 (corresponding to the rendering process), and the JSB unified interface 300 are introduced. UI and interaction are realized by a rendering process, functions of local log, storage, downloading, reporting and the like are realized by a main process, the rendering process and the main process communicate through a packed JSB unified interface, the problem of complex communication between the main process and the rendering process of a large-scale Electron program is solved, and development and maintenance cost is reduced.

In the development platform 2 or the client 6, the implementation system of the development application thereof may include the following from the viewpoint of file division:

list one

As shown in Table one, from the perspective of file partitioning, the implementation system may include:

(1) Root directory (Electron/, as in table one);

(2) An APP catalog located under the root catalog (Electron /);

(3) A first package. Json file located under the root directory (Electron /);

(4) An installation package packaging configuration file (Electron-builder. Config. Js) located under the root directory (Electron /); and

build resource directory (build /), install package generation directory (dist /), render process build configuration file (vite. Config. Ts), etc.

The APP catalog is configured under the root catalog, and the second package. Json file is configured under the APP catalog; the partial information in the first package json file is synchronized into the second package json file; the partial information includes dependency information required for the production phase, the dependency information including dependency declarations. The APP directory may also include other files such as: encrypted files (encrypted program code), bytecode entry files, execution entry files, application keys, program profiles (readem. Md), etc.

The installation package packaging configuration file is used for designating to place a generated code under the APP catalog and designating to package the generated code and a second package. The installation package configuration file is also configured with a dependency deletion hook for deleting the dependency declaration from the construction package to obtain an installation package.

The reason for setting the file structure is as follows:

the first package json file is a package json in a development environment, which contains a large amount of configuration information, for example: name (name of application), version (description of application), author (author information), license (open source license type), dependencies (including Electron and other npm packages), devDependencies (developing dependencies including build tools and test frameworks, etc.), build (build configuration information including package format, target platform, application icons, etc.).

If the first package is driven into a package when the package is constructed, the package is issued to a user to cause leakage of technical information. For example, dependencies, devDependencies and other information-dependent leaks may result.

For this purpose, the scheme creates the APP catalog under the root catalog by the Electron-loader. The addition of a second package. Json file under the APP directory may of course also add other files like program profiles (e.g. read em. Next, when the package is built, the required files under the APP directory can be designated to be driven in to get the build package. Wherein, the build package may refer to the code built, the compatible package without installation, or the final installation package. Specifically:

first: the dependency information in the first package json file is partially synchronized into the second package json file so that the program can reference the required dependencies. It should be noted that, not all the dependency information in the first package json file is synchronized into the second package json file, but essential dependency information required by the synchronization application in the production environment (not the development environment). Therefore, even if the second package. Json file is packaged into the construction package, information-dependent leakage is reduced, and potential safety hazards are reduced to a certain extent.

In the specific engineering implementation, a synchronization script under the execution/script may be triggered by the NPM executing predefined hooks (such as a postall hook and a postuninstallation hook), so that the necessary dependency information in the first package json file may be synchronized into the second package json file by the synchronization script.

Second,: the generated code is also placed under the./app directory. The generated code is the code compiled at program construction. In a specific engineering implementation, the generated code may be placed under the "/app directory by an electron-builder.config.js designation.

Thus, both the generated code and the second package. Json file in the production environment are under the./app directory. At the time of packaging, it is possible to specify which files under the app directory need to be driven into the package by the electronics-builder.

After packaging is completed and a "build package" is obtained, dependency information in the production environment still exists in the build package. If the build package is provided directly to the user, this part of the dependency information may be compromised. Therefore, after obtaining the build package, the dependency declaration of the second package json file in the build package also needs to be deleted, so as to obtain the final installation package. The final installation package is provided for the user again, so that the problem of information leakage dependence does not occur. In an exemplary operation, a dependency delete hook may be added to the electron-builder. Config. Js, through which the dependency declaration is deleted, thereby obtaining an installation package that may be provided to the user.

The above describes that the problem of technical information leakage is avoided or alleviated by setting the file structure so as to improve the information security.

After an installation package is obtained, the final objective is to provide the client with installation or update.

In an alternative, the installation packages include a full installation package and a delta installation package.

After the full installation package, the delta installation package is obtained, then a download service may be provided. Specific: uploading the full installation package, the incremental installation package and the incremental update configuration file to a server to provide a download update.

The full install package is a software package that replaces the entire software package with the latest version. The client needs to download the installation package of the whole new version and cover the original software package. The updating mode enables the updated software package to be brand new, and stability and integrity of the software can be guaranteed. But downloading the entire installation package requires a long time and bandwidth resources.

The incremental installation package is to update the code package. The benefit of this update approach is that download time and bandwidth resources can be saved. The incremental installation package is obtained on the basis of the construction package, and the construction package is an installation package compatible with a plurality of hardware platforms and has large volume. When the incremental installation package is constructed, an afterallArtifactbuild hook can be added in the electron-builder.config.js, and the incremental installation package is generated through the afterallArtifactbuild hook based on the construction package. The delta installation package may be provided to the client after compression.

The full mount package corresponds to a full update, and the incremental mount package corresponds to an incremental update. That is, the full-volume update is to download the full-volume installation package to the local at one time for updating. The incremental update is performed by downloading only the change part, so that the size and the downloading time of the update package can be reduced, for example, only the incremental update package (code package) is downloaded.

The download update may be a full version download update or a gray level download update in the test phase.

When the incremental gray level update is started, only the version supporting the increment can be updated in increments, and the version not supporting the increment needs to be updated to the latest version through the whole amount. If the latest version of the delta update configuration file (update. Yml) is issued, even the version supporting the delta will detect an update. Therefore, a new update. Yml needs to be generated according to the version number of the client, the configuration of the configuration center, and the resources uploaded by the server.

In an alternative, in the case of incremental updates, the architecture includes:

the incremental installation package is positioned under the user data directory;

wherein the module path variable of the environment variables is set to: a path of the delta installation package is specified.

In a Windows system, due to UAC limitations, modifying files under an installation package requires requesting user rights, and in a system disk requires requesting administrator rights. The request rights can also affect the upgrade experience if the incremental installation package is downloaded under the installation directory. Therefore, this embodiment bypasses the UAC limitation problem described above and places the incremental installation package under the user data directory. At the same time, the module path variable is set to specify the path of the incremental installation package, ensuring that code running under the user data directory (incremental installation package) can be imported.

And (II) optimizing the playing experience of the application program.

When an application program (such as an Electron application) opens a window, if the window opens a relatively large SPA page, because resource loading is relatively time-consuming, a white screen can be generated if loading optimization is not performed. In addition, the rendering process occupies larger resources, and if the user does not use the rendering process for a long time and does not exit the program, the rendering process can cause the conditions of resource waste, power consumption and the like. Under a Windows system, the inability of a window movable region to affect a mouse event can result in the front end being unable to determine whether the mouse hovers over a window.

Therefore, the problems that an application program such as an Electron is slow to open and a white screen is opened, the resource consumption of the application program is optimized, and the problem that a window movable area of the application program cannot influence a mouse event under a Windows system is solved.

Referring to fig. 1 (C), 1 (D) and 1 (E), the specific optimization operation of the application program is as follows:

first: starting and window optimization, wherein the steps are as follows:

1. at start-up (first opening the main window), a hidden main window is created first, and a relatively simple open page is loaded.

2. And after the rendering of the open screen page is completed, calling the open screen page processing interface of the main process, and controlling and displaying the main window to prevent the open screen page from being white.

3. After the main window and the open page are displayed, the main page is loaded and rendered below the open page of the main window.

4. And when the main page rendering is completed, calling a main process main page processing interface, and closing an open screen page covered on the main page.

5. After receiving the notification of the completion of the main page rendering, the main process creates a hidden playing window.

6. When the user clicks the play video, the rendered play window is displayed, and the video is loaded and played.

7. When the main window and the play window are closed, only the main window and the play window are hidden. The window instance is hidden and not really destroyed, and when the video is opened or played again, the window can be opened quickly, so that the user experience is improved.

In the main window, there may be different levels of pages that are presented on the display. For example, there are page a and page B in the main window, and if the level of page a is greater than that of page B, page a is overlaid on page B when displayed.

In the scheme, the application program is started, and the main page is not loaded, but the open page is loaded and displayed first. And under the condition that the main window and the open page are displayed, loading and rendering of the main page can be carried out, so that the problems of resource occupation and abnormal display caused by loading and rendering of the open page and the main page can be avoided.

And loading and rendering the main page after the main window and the open screen page are displayed. The main page is lower in level than the open page, and therefore, the open page is overlaid thereon when the main page is loaded and rendered. In this way, the main page under loading and rendering corresponds to being in a hidden state and is not seen by the user.

In an exemplary application, a domsetloadevent in JavaScript or $ (document) · ready () method in jQuery, etc. may be used to detect whether the main page has completed rendering. In other embodiments, the home page may also be considered to be rendered when the user implements the main content of the setting to complete the loading and rendering.

And after the main page is rendered, setting the main page as the content of the main window, and closing the open screen page. In an exemplary application, the open page may be hidden by controlling the CSS attribute, or removed directly.

The scheme can improve the user experience, and is specifically as follows:

and responding to the starting of the application program, creating a main window in a hidden state, loading and rendering an open screen page, and loading and rendering the main page below the level of the open screen page under the condition that the main window and the open screen page are both displayed, so that a user can see one open screen page instead of a possible home page white screen in the process of waiting for loading the home page. And displaying the main page on the main window and closing the open page under the condition that the main page is completely rendered, so that a user can normally use an application program.

According to the scheme, the starting process of the application program is optimized, the white screen caused by directly loading the main page is avoided or relieved, and the experience is improved. The optimization is particularly applicable to programs with large main pages, such as Electron applications.

In this scenario, the main page may be various types of pages, such as an HTML web page, a multimedia web page, a dynamic web page, a single page application, and so on. The home page may have various controls, such as a home page for video playback having a play control, etc.

Taking an application program based on Eletron as an example, after the main page is rendered, a main window processing interface in a main process is called, and an open page is closed. And after the main process receives the completion of the main page rendering, creating the playing window.

In an exemplary application, a video element in a main window is acquired, the element binding a click event listener. When the user clicks the element, a play window is displayed, and video is acquired according to a video source specified by the video element and added into the play window.

In an exemplary application, a video file or video playback component is played in a playback window using the video tag of HTML 5; the playing window may have video control components, such as a progress bar, display mode switching, etc., as needed.

In an exemplary application, some video processing functions may be added in the play window, such as video clips, adding special effects, etc.; interactive functions such as comments, praise and the like can be added in the play window; other functions may also be provided.

In an exemplary application, elements of a primary window are acquired and an event listener is added to the primary window. When the main window is closed, the event listener sets the display attribute of the main window to none (attribute value), thereby hiding it. It should be noted that, the hiding operation of the playing window may also refer to the main window.

In the scheme, when the main window and the playing window are closed, only the window is hidden and the window instance is not really destroyed, and when the video is opened or played again, the window can be opened rapidly, so that the user experience is improved.

Second, a power saving mode of the application is provided:

because the rendering process occupies larger resources, if the user does not use for a long time and does not close, the resource waste is caused, so that an energy-saving mode can be set for the application program, the application program can enter the mode after being hidden in the tray for a period of time, and the rendering process corresponding to the main window and the playing window can be destroyed at the moment, so that the resource occupation is released. After entering the energy saving mode, if the user reopens the application program, the screen opening process is entered again.

The application entering a minimized state may refer to the application being hidden to a tray or in the background.

In an exemplary application, in the power saving mode, when the application enters the minimized state, a timer is started, recording the duration of time that the minimized state was entered. And when the duration time of entering the minimized state exceeds a preset threshold value, destroying the rendering processes of the main window and the playing window, thereby releasing the occupation of resources and relieving the waste of resources. The above-described resource release is not performed in the non-power saving mode. The user may autonomously select whether to enter the power saving mode.

In some schemes, different preset thresholds can be set according to different application scenes and user requirements; the minimum state duration time can be dynamically determined according to the current state of the client so as not to influence the normal use of the equipment; the method can also remind the user that the process is to be destroyed when the duration approaches to the preset threshold value, and the user decides whether to destroy or not.

Third, provide for optimization of the application in a compact mode (widget mode):

the widget mode is entered when the widget mode button in the upper right corner of the play window is clicked or when the play window is dragged to change to a small size.

In the small window mode: the window can adapt to the video locking aspect ratio to realize black-edge-free play. The function of the fixed window at the forefront is matched, so that a user can learn a course while actually operating the course. Compared with the picture-in-picture of the webpage, the small window of the computer client can display the barrage, and the limitation of the original picture page is avoided. A small window in essence refers to a succinct pattern because it can also drag edges to resize, becoming larger than a "large window".

In the small window mode, the default window size and scale are not fixed, and the user can drag the window edge to change size to achieve the desired effect (shape, size). The user can click the 'lock aspect ratio' button to realize window proportion adaptation video size to realize black-edge-free play, and the scaling can be maintained when the window size is changed by dragging.

In the small window mode, hovering of the mouse is simulated by taking an intersection according to the positions of the window and the mouse in the physical screen. For example, after the designated target play window is acquired, the mouse event listener is executed by setting a preset time interval. When the target playing window is in a visible state, a target area of the target playing window in the physical screen is acquired, and the position of the mouse in the physical screen is acquired. It is checked whether the mouse position exceeds the target area. And under the condition that the position of the mouse is not in the target area or the target playing window is in an invisible state, automatically removing the mouse event monitor so as to achieve the aim of simulating a mouse event, and further efficiently and accurately determining the display and the hiding of the window title bar. It should be noted that the mouse event may be simulated in other manners.

And (III) code security of the application program.

In particular, it will be described by one or more of the following examples how to minimize the need for the mounting package to be protected from the casing, implantation or tampering, etc.

Example 1

In this embodiment, the development platform 2 may be an execution subject.

Fig. 2 schematically shows a flowchart of a method of protecting an application according to an embodiment of the present application.

As shown in fig. 2, the method for protecting an application may include steps S200 to S210, in which:

in step S200, the program codes of the application program are obfuscated to obtain a first obfuscated file.

The application program may be various programs. Taking an Electron-based application as an example, its main process code includes, for example, javaScript code. The JavaScript language is easy to be sleeved, implanted and tampered with because the environment on which the JavaScript language depends is open, readable and editable. For example, an attacker may tamper with JavaScript code during network transmission.

Therefore, it is necessary to perform a secure process after the program code of the application program is constructed.

In this embodiment, the confusion may be performed by a confusion tool to obtain the first confusion file. The Obfuscator may be used, for example. In particular, the obfuscation tool may obfuscate the code by identifying and renaming variables, methods, classes, and interface names, deleting unused code, optimizing code, and so on. The confusion tool may also employ different confusion parameters, such as renaming style, confusion level, etc., to increase the difficulty of confusion. Meanwhile, a plurality of confusion tools can be adopted to carry out multiple confusion on codes so as to increase the confusion intensity.

In some embodiments, the obfuscated file may be further compressed to obtain the first obfuscated file.

By confusing and compressing the program codes, the code readability can be effectively reduced, and the damage difficulty can be increased.

Step S202, performing encryption operation on the first obfuscated file to obtain an encrypted file.

The first obfuscated file reduces the readability of the program code but is easy to unwrap, tamper-evident and secondary package. For this reason, the present embodiment continues to perform further encryption operations on the basis of the first obfuscated file.

Specific: and taking the first mixed file as a plaintext, and performing encryption operation by using the selected encryption algorithm and the key to generate an encrypted file.

In some embodiments, the encryption operation may select one or more encryption algorithms, such as AES (Advanced Encryption Standard ), or the like. The key length and encryption mode can be set according to the requirements.

Step S204, obtaining a decryption entry code for the encrypted file.

The steps are as described above to prevent the program code from being tampered with, embedded in, or tampered with, and to perform the obfuscation and encryption operations.

However, the client is unable to run the encrypted code, and the client needs to restore the encrypted file (obfuscated and encrypted program code) and then run it. Thus, in the installation package, it is necessary to provide the corresponding decrypted file at the same time as the encrypted file. The decryption entry code is a decryption file for restoring the encryption file.

In step S206, the decryption entry code is obfuscated to obtain a second obfuscated file.

The decryption portal code is also needed to provide a client with the encrypted file (obfuscated and encrypted program code) for decrypting the encrypted file. It will be appreciated that the decryption entry code is also exposed to users and attackers and therefore the decryption entry file also needs to be obfuscated to obtain a second obfuscated file, in particular with reference to the first obfuscated file.

In some embodiments, the obfuscated decryption entry code may be further compressed to obtain the second obfuscated file.

By confusing and compressing the decryption entry code, the code readability can be effectively reduced, and the difficulty of destruction can be increased.

Step S208, converting the second obfuscated file into a byte code entry file.

The second obfuscated file reduces the readability but is still easily restored by an attacker to the original decryption entry code, and the encrypted file (obfuscated and encrypted program code) is decrypted by the original decryption entry code, and then the shell, implantation, attack are performed. Therefore, the embodiment further converts the second obfuscated file into a bytecode entry file.

The cached data can be generated from the Script object through the vm module in the Node standard library, the cached data can be understood as the byte code of v8, and the byte code is stored as the cached data, so that the purpose of protecting the source code is achieved. In some embodiments, the second obfuscated file may be compiled into v8 bytecodes using a vm module in node. Js. Due to the poor readability of the byte code, the security of the second obfuscated file (the obfuscated decryption entry code) may be better protected. It should be noted that the vm module is a built-in module in the node. Js, and is used for providing a mechanism for executing JavaScript code by a sandbox in the node. Js environment. The module provides functions and classes that can compile JavaScript code in the form of a string into bytecodes, such as v8 bytecodes.

And step S210, obtaining an installation package according to the encrypted file and the byte code entry file, wherein the installation package is used for providing the client.

The installation package is for deployment onto a client so that the client can use and run the application.

The installation packages include full installation packages and incremental installation packages.

The full install package is a software package that replaces the entire software package with the latest version.

The incremental installation package is to update the code package. The benefit of this update approach is that download time and bandwidth resources can be saved.

It should be noted that, a necessary script or executable file may be added to the installation package, so that the client can decrypt and run the application program. When the installation package is an incremental installation package, the incremental installation package can be set under a user data directory under the condition that the incremental installation package is obtained; the process.env.NODE_PATH variable in the environment variable is set to change the PATH for importing the incremental installation package, thereby bypassing the Windows UAC authority problem.

The application program protection method provided by the embodiment of the application program protection method is used for increasing the difficulty of being sleeved, implanted and tampered and improving the safety of the application program. Program code may be prevented from reverse engineering decryption by confusion and encryption operations. The encrypted file may be decrypted by decrypting the entry code, which in turn increases the difficulty of the attacker to analyze the code by confusion and bytecode conversion. And then, generating an installation package according to the encrypted file and the byte code entry file for the client to use. In the client, the client machine itself may decrypt the encrypted file according to the bytecode entry file, thereby enabling installation and running of the application. However, because the installation package combines the processing modes of code confusion, encryption, byte codes and the like, an attacker (person) is difficult to reversely engineer to obtain the original code, thereby avoiding the application program from being sheathed, implanted and tampered as much as possible and realizing the effective protection of the application program.

In an alternative embodiment, the byte code entry file has a plurality of byte code entry files; the method further comprises the steps of:

The execution portal file provides an installation portal for the client, which may be in JavaScript or the like.

For example, the steps of the plurality of bytecode entry files and the execution entry file may be as follows:

step one: and acquiring a path of the decryption-entry file, and reading the content in the decryption-entry file.

Step two: confusion is made with respect to the decryption entry file.

Step three: and acquiring the confused codes, and covering the original decryption entry file by the confused codes.

Step four: different bytecode entry files are generated based on the obfuscated code, depending on the operating system and system architecture.

If the system is Windows, the suffix is 'win', otherwise, the suffix is generated according to the system architecture.

The suffix is 'arm' if the system architecture is arm, otherwise it is 'x86'.

Step five: a complete path for each bytecode entry file is generated.

Step six: and constructing an execution entry file according to the complete path of each byte code entry file to provide path guidance.

Taking an Electron application as an example, which has cross-platform capability, the installation package is often adapted to different hardware or software environments to improve compatibility and stability. In this embodiment, an installation entry of the application program is provided for the client by executing the entry file, and an operating system and/or a system architecture of the client are determined, and then the corresponding byte code entry file is effectively determined according to the operating system and/or the system architecture of the client, so as to correctly guide the installation.

In an alternative embodiment, the method further comprises:

The hash value of the application may be used to verify the integrity and security of the application. When the installation package of the application program is installed, whether the installation package passes through the shell, is implanted or tampered can be confirmed by calculating the hash value of the application program and comparing the hash value of the application program with an expected hash value, so that the safety is improved.

In an alternative embodiment, the method further comprises:

The application key (AppKey) of the application may be used to identify and verify the identity of the application. The application key may be an encrypted string that may be used to authenticate the publisher and license of the application. The application key may ensure that the application is only published by authorized publishers and may prevent unauthorized tampering or distribution.

Example two

In the present embodiment, the client 6 may be an execution subject.

Fig. 3 schematically shows a flowchart of an installation method of an application according to a second embodiment of the present application.

As shown in fig. 3, the installation method of the application may include steps S300 to S302, in which:

step S300, obtaining a target byte code entry file in an installation package of an application program under the condition that the installation package of the application program is obtained.

Step S302, according to the target byte code entry file, decrypting the encrypted file in the installation package to obtain the program code of the application program; wherein the target bytecode entry file is transcoded based on a decryption entry.

The description of the installation package may refer to embodiment one. This embodiment is directed to how the installation and execution of an application is accomplished through an installation package.

The encrypted file in the installation package is obfuscated and encrypted program code. In the client, the client machine itself may decrypt the encrypted file according to the bytecode entry file and ultimately enable the installation and running of the application. Because the encrypted file in the installation package combines the processing modes of code confusion, encryption, byte codes and the like, and the byte code entry file combines the confusion and byte code processing, an attacker is difficult to obtain the original code in the encrypted file by reverse engineering, and the application program is prevented from being sheathed, implanted and tampered as much as possible while the client can correctly install the program.

By way of example, the installation procedure may be as follows:

step one: decompiling the target byte code entry file to obtain a second obfuscated file.

Step two: and performing anti-obfuscation operation on the second obfuscated file, and restoring the decryption entry code.

Step three: and carrying out decryption operation on the encrypted file through the decryption entry code to obtain a first confusion file.

Step four: and performing anti-confusion operation on the first confusion file to obtain the program code.

Step five: and running the program code.

In an alternative embodiment, the decrypting the encrypted file in the installation package according to the target byte code entry file to obtain the program code of the application program includes:

loading the target byte code entry file to obtain a decryption instance;

For example: loading the target byte code entry file through WebAsssembly to obtain a WebAsssembly decryption instance; and carrying out decryption operation on the encrypted file through the WebAsssembly decryption instance to obtain the program code.

In the optional embodiment, a combination mode of code confusion, encryption, byte code and WebAssemblem decryption is combined, so that the cracking difficulty of the original program code can be further increased, and the cracking difficulty of the installation package is improved.

In an alternative embodiment, the program code comprises an application key and/or a hash value of the application program. Correspondingly, the method further comprises:

The hash value of the application may be used to verify the integrity and security of the application. When the installation package of the application program is installed, whether the installation package passes through the shell, is implanted or tampered can be confirmed by calculating the hash value of the application program and comparing the hash value of the application program with an expected hash value, so that the safety is improved. The application key of the application may be used to identify and verify the identity of the application. The application key may be an encrypted string that may be used to authenticate the publisher and license of the application. The application key can ensure that the application program is only issued by an authorized issuer, and the installation and operation of unauthorized risk application programs are avoided.

In an alternative embodiment, the installation package includes an execution entry file and a plurality of bytecode entry files; correspondingly, the obtaining the target byte code entry file in the installation package includes:

Taking an Electron application as an example, which has cross-platform capability, the installation package is often adapted to different hardware or software environments to improve compatibility and stability. In this embodiment, the client may obtain the installation portal of the application program by executing the portal file, and determine the corresponding bytecode portal file, so as to install correctly and efficiently.

To make this embodiment easier to understand, an example of an installation flow is provided below in conjunction with fig. 4.

S400, running the execution entry file, judging the system architecture, and finding out the corresponding target byte code file for execution.

S402, decrypting the encrypted file (the program code after confusion and encryption) in the byte code, and executing the encrypted file by Eval.

S404, judging whether the application key and the hash value are correct, if the verification is not passed, throwing out an error, and exiting the program.

S406, checking the safety of the error-free running environment, and normally starting the application program.

Example III

Fig. 5 schematically shows a block diagram of a protection device for an application program according to the third embodiment of the present application, which may be divided into one or more program modules, which are stored in a storage medium and executed by one or more processors to complete the embodiments of the present application. Program modules in the embodiments of the present application refer to a series of computer program instruction segments capable of implementing specific functions, and the following description specifically describes the functions of each program module in the embodiments. As shown in fig. 5, the protection apparatus 500 for an application may include a first confusion module 410, an encryption module 520, a first acquisition module 530, a second confusion module 540, a conversion module 550, and a second acquisition module 560, wherein:

The first obfuscation module 510 obfuscates program codes of the application program to obtain a first obfuscated file;

an encryption module 520, configured to encrypt the first obfuscated file to obtain an encrypted file;

a first acquisition module 530 that acquires a decryption entry code for the encrypted file;

a second obfuscation module 540, configured to obfuscate the decryption entry code to obtain a second obfuscated file;

a conversion module 550, configured to convert the second obfuscated file into a bytecode entry file; a kind of electronic device with high-pressure air-conditioning system

And the second obtaining module 560 obtains an installation package according to the encrypted file and the byte code entry file, wherein the installation package is used for providing the client.

In an alternative embodiment, the byte code entry file has a plurality of byte code entries; the apparatus further comprises a first generation module (not identified) for:

In an alternative embodiment, the apparatus further comprises a second generation module (not identified) for:

In an alternative embodiment, the apparatus further comprises a third generation module (not identified) for:

Example IV

Fig. 6 schematically shows a block diagram of an installation apparatus of an application program according to a fourth embodiment of the present application, and the protection apparatus of the application program may be divided into one or more program modules, and the one or more program modules are stored in a storage medium and executed by one or more processors to complete the embodiments of the present application. Program modules in the embodiments of the present application refer to a series of computer program instruction segments capable of implementing specific functions, and the following description specifically describes the functions of each program module in the embodiments. As shown in fig. 6, the installation apparatus 600 of the application program may include an acquisition module 610, a decryption module 620, wherein:

an obtaining module 610, configured to obtain, when an installation package of an application program is obtained, a target bytecode entry file in the installation package; a kind of electronic device with high-pressure air-conditioning system

A decryption module 620, configured to decrypt the encrypted file in the installation package according to the target bytecode entry file, so as to obtain a program code of the application program; wherein the target bytecode entry file is transcoded based on a decryption entry.

In an alternative embodiment, the decryption module 620 is further configured to:

loading the target byte code entry file to obtain a decryption instance;

A decryption module 620, the program code comprising an application key and/or a hash value of the application program; correspondingly, the method further comprises:

in an alternative embodiment, the program code includes an application key and/or hash value of the application program; the apparatus further comprises a verification module (not identified) for:

In an alternative embodiment, the installation package includes an execution entry file and a plurality of bytecode entry files; correspondingly, the apparatus further comprises an acquisition module (not identified) for:

Example five

Fig. 7 schematically illustrates a hardware architecture diagram of a computer device 10000 suitable for implementing a protection method or an installation method of an application program according to a fifth embodiment of the present application. The computer device 10000 may be a client 4 or be part of a client 4. In this embodiment, the computer device 10000 may be a workstation, a personal computer, a cloud server, or the like. As shown in fig. 7, the computer device 10000 includes at least, but is not limited to: the memory 10010, processor 10020, network interface 10030 may be communicatively linked to each other via a system bus. Wherein:

memory 10010 includes at least one type of computer-readable storage medium including flash memory, hard disk, multimedia card, card memory (e.g., SD or DX memory, etc.), random Access Memory (RAM), static Random Access Memory (SRAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), programmable read-only memory (PROM), magnetic memory, magnetic disk, optical disk, etc. In some embodiments, memory 10010 may be an internal storage module of computer device 10000, such as a hard disk or memory of computer device 10000. In other embodiments, the memory 10010 may also be an external storage device of the computer device 10000, such as a plug-in hard disk, a Smart Media Card (SMC), a Secure Digital (SD) Card, a Flash Card (Flash Card) or the like. Of course, the memory 10010 may also include both an internal memory module of the computer device 10000 and an external memory device thereof. In this embodiment, the memory 10010 is typically used for storing an operating system installed on the computer device 10000 and various types of application software, such as program codes of a protection method of an application program. In addition, the memory 10010 may be used to temporarily store various types of data that have been output or are to be output.

The processor 10020 may be a central processing unit (Central Processing Unit, simply CPU), controller, microcontroller, microprocessor, or other object processing chip in some embodiments. The processor 10020 is typically configured to control overall operation of the computer device 10000, such as performing control and processing related to data interaction or communication with the computer device 10000. In this embodiment, the processor 10020 is configured to execute program codes or process data stored in the memory 10010.

The network interface 10030 may comprise a wireless network interface or a wired network interface, which network interface 10030 is typically used to establish a communication link between the computer device 10000 and other computer devices. For example, the network interface 10030 is used to connect the computer device 10000 to an external terminal through a network, establish a data transmission channel and a communication link between the computer device 10000 and the external terminal, and the like. The network may be a wireless or wired network such as an Intranet (Intranet), the Internet (Internet), a global system for mobile communications (Global System of Mobile communication, abbreviated as GSM), wideband code division multiple access (Wideband Code Division Multiple Access, abbreviated as WCDMA), a 4G network, a 5G network, bluetooth (Bluetooth), wi-Fi, etc.

It should be noted that fig. 7 only shows a computer device having components 10010-10030, but it should be understood that not all of the illustrated components are required to be implemented, and more or fewer components may be implemented instead.

In this embodiment, the protection method of the application program stored in the memory 10010 may be further divided into one or more program modules and executed by one or more processors (the processor 10020 in this embodiment) to complete the embodiments of the present application.

Example five

The present application further provides a computer-readable storage medium having stored thereon a computer program which, when executed by a processor, implements the steps of the protection method for an application in the embodiments.

In this embodiment, the computer-readable storage medium includes a flash memory, a hard disk, a multimedia card, a card memory (e.g., SD or DX memory, etc.), a Random Access Memory (RAM), a Static Random Access Memory (SRAM), a read-only memory (ROM), an electrically erasable programmable read-only memory (EEPROM), a programmable read-only memory (PROM), a magnetic memory, a magnetic disk, an optical disk, and the like. In some embodiments, the computer readable storage medium may be an internal storage unit of a computer device, such as a hard disk or a memory of the computer device. In other embodiments, the computer readable storage medium may also be an external storage device of a computer device, such as a plug-in hard disk, a Smart Media Card (SMC), a Secure Digital (SD) Card, a Flash Card (Flash Card), etc. that are provided on the computer device. Of course, the computer-readable storage medium may also include both internal storage units of a computer device and external storage devices. In this embodiment, the computer readable storage medium is typically used to store an operating system installed on a computer device and various types of application software, such as program codes of the protection method of the application program in the embodiment. Furthermore, the computer-readable storage medium may also be used to temporarily store various types of data that have been output or are to be output.

It will be apparent to those skilled in the art that the modules or steps of the embodiments of the application described above may be implemented in a general purpose computing device, they may be concentrated on a single computing device, or distributed across a network of computing devices, they may alternatively be implemented in program code executable by computing devices, so that they may be stored in a storage device for execution by computing devices, and in some cases, the steps shown or described may be performed in a different order than what is shown or described, or they may be separately fabricated into individual integrated circuit modules, or multiple modules or steps of them may be fabricated into a single integrated circuit module. Thus, embodiments of the present application are not limited to any specific combination of hardware and software.

It should be noted that the foregoing is only a preferred embodiment of the present application, and is not intended to limit the scope of the patent protection of the present application, and all equivalent structures or equivalent processes using the descriptions and the contents of the present application or direct or indirect application to other related technical fields are included in the scope of the patent protection of the present application.

Claims

1. A method for protecting an application, comprising:

encrypting the first confusion file to obtain an encrypted file;

acquiring a decryption entry code for the encrypted file;

obfuscating the decryption entry code to obtain a second obfuscated file;

2. The method of claim 1, wherein the byte code entry file has a plurality of byte code entry files; the method further comprises the steps of:

3. The method according to claim 1 or 2, characterized in that the method further comprises:

4. The method according to claim 1 or 2, characterized in that the method further comprises:

5. An apparatus for protecting an application program, comprising:

6. A method for installing an application program, comprising:

7. The method according to claim 6, wherein decrypting the encrypted file in the installation package according to the target bytecode entry file to obtain the program code of the application program comprises:

loading the target byte code entry file to obtain a decryption instance;

8. The method according to claim 6 or 7, characterized in that the program code comprises an application key and/or a hash value of the application program; correspondingly, the method further comprises:

9. The method of claim 6 or 7, wherein the installation package comprises an execution entry file and a plurality of byte code entry files; correspondingly, the obtaining the target byte code entry file in the installation package includes:

10. An installation apparatus of an application program, comprising:

11. A computer device, comprising:

A memory communicatively coupled to the at least one processor; wherein:

the memory stores instructions executable by the at least one processor to enable the at least one processor to perform the method of any one of claims 1-4 or 6-9.

12. A computer readable storage medium having stored therein computer instructions which, when executed by a processor, implement the method of any of claims 1-4 or 6-9.