CN117519813A - 一种文件运行方法及装置 - Google Patents

Abstract

本申请实施例提供了一种文件运行方法及装置，在该方案中，电子设备可以根据可执行文件对待加载的非可执行文件进行完整性校验。由于可执行文件能够实现完整性保护，因此，对可执行文件的完整性保护可以扩展延伸到对非可执行文件的完整性保护，实现对非可执行文件的完整性保护，规避由于非可执行文件被篡改导致的安全风险。

Description

一种文件运行方法及装置

技术领域

本申请涉及网络安全技术领域，尤其涉及一种文件运行方法及装置。

背景技术

电子设备中的软件是通过软件开发商或软件开发者开发的软件安装包实现安装的。软件安装包中一般包含可执行文件和非可执行文件两种。例如，当用户需要在电子设备中安装某个应用时，电子设备获取并安装该应用的应用安装包后，启动其中的可执行文件，在可执行文件的运行过程中，加载并运行非可执行文件。

在网络安全领域，为了防止文件被篡改，在电子设备加载或运行一个文件前需要先对该文件进行完整性校验。目前，业界一般使用数字签名技术实现文件的完整性校验。如果有攻击者对一个被数字签名的文件进行篡改，那么电子设备在使用该文件前，可以通过该文件的数字签名信息进行验证，从而识别出该文件已被篡改，进而可以避免直接运行被篡改的文件导致遭受攻击。

然而，在操作系统里，一般只支持对可执行文件进行数字签名，而无法对非可执行文件进行数字签名，这就导致操作系统无法通过数字签名技术对非可执行文件进行完整性保护，导致非可执行文件在传输过程中可能存在被篡改的风险。

发明内容

本申请提供一种文件运行方法及装置，用于保证非可执行文件的完整性，规避由于非可执行文件被篡改导致的安全风险。

第一方面，本申请实施例提供了一种文件运行方法，该方法可以应用于电子设备中，该方法可以包括以下步骤：

电子设备对可执行文件进行完整性校验；当对所述可执行文件的完整性校验通过后，所述电子设备启动所述可执行文件，并根据所述可执行文件对待加载的非可执行文件进行完整性校验；当对所述非可执行文件的完整性校验通过后，所述电子设备根据所述可执行文件加载并运行所述非可执行文件。

通过该方法，电子设备可以根据可执行文件对待加载的非可执行文件进行完整性校验。由于可执行文件能够实现完整性保护，因此，对可执行文件的完整性保护可以扩展延伸到对非可执行文件的完整性保护，实现对非可执行文件的完整性保护，规避由于非可执行文件被篡改导致的安全风险。该方法可以打破现有的操作系统仅支持使用数字签名对可执行文件进行完整性保护的约束限制，实现通过数字签名技术间接保护非可执行文件的完整性的效果。

在一种可能的设计中，所述电子设备可以通过以下步骤，根据所述可执行文件对待加载的非可执行文件进行完整性校验：

所述电子设备使用所述可执行文件配置的哈希算法计算所述非可执行文件的第一摘要值；然后所述电子设备判断所述第一摘要值与所述可执行文件包含的第二摘要值是否相同；所述第二摘要值为软件发布前使用所述哈希算法对所述非可执行文件进行计算得到并配置到所述可执行文件中的；其中，当所述第一摘要值与所述第二摘要值相同时，表示对所述非可执行文件的完整性校验通过；当所述第一摘要值与所述第二摘要值不同时，表示对所述非可执行文件的完整性校验不通过。

通过该设计，所述电子设备可以完成对非可执行文件的完整性校验。

在一种可能的设计中，当对所述非可执行文件的完整性校验不通过时，所述电子设备可以停止运行所述可执行文件。

在一种可能的设计中，所述可执行文件中包含用于对所述非可执行文件进行完整性校验的程序代码。

在一种可能的设计中，所述可执行文件与所述非可执行文件位于软件安装包中。

在一种可能的设计中，所述软件安装包为通过Electron框架开发的。

在一种可能的设计中，所述可执行文件的文件类型为以下任一项：可执行程序EXE文件、动态链接库DLL文件、磁盘映像DMG文件、对象类别扩充组件OCX文件、系统SYS文件、应用APP文件，或命令COM文件。

第二方面，本申请实施例提供了一种文件运行装置，包括用于执行以上第一方面中各个步骤的单元。

第三方面，本申请实施例提供了一种电子设备，包括至少一个处理元件和至少一个存储元件，其中该至少一个存储元件用于存储程序和数据，该至少一个处理元件用于执行本申请以上第一方面中提供的方法。

第四方面，本申请实施例还提供了一种计算机程序，当计算机程序在计算机上运行时，使得计算机执行上述第一方面提供的方法。

第五方面，本申请实施例还提供了一种计算机可读存储介质，该计算机可读存储介质中存储有计算机程序，当计算机程序被计算机执行时，使得计算机执行上述任一方面提供的方法。

第六方面，本申请实施例还提供了一种芯片，芯片用于读取存储器中存储的计算机程序，执行上述第一方面提供的方法。可选的，所述芯片中可以包含处理器和存储器，所述处理器用于读取存储器中存储的计算机程序，执行上述第一方面提供的方法。

第七方面，本申请实施例还提供了一种芯片系统，该芯片系统包括处理器，用于支持计算机装置实现上述任一方面提供的方法。在一种可能的设计中，芯片系统还包括存储器，存储器用于保存该计算机装置必要的程序和数据。该芯片系统可以由芯片构成，也可以包含芯片和其他分立器件。

附图说明

图1为本申请实施例提供的一种数字签名机制的示意图；

图2为本申请实施例提供的一种软件开发场景示意图；

图3为本申请实施例提供的一种可执行文件和非可执行文件的关系图；

图4为一种传统的软件开发方案示意图；

图5为本申请实施例提供的一种软件开发方案示意图；

图6为本申请实施例提供的一种对非可执行文件进行完整性保护的示意图；

图7为本申请实施例提供的一种对文件运行方法的流程图；

图8为一种基于Electron框架的传统软件开发方案示意图；

图9为本申请实施例提供的一种可执行文件和非可执行文件的关系图；

图10为本申请实施例提供的一种基于Electron框架的软件开发方案示意图；

图11为本申请实施例提供的一种对非可执行文件进行完整性保护的实例示意图；

图12为本申请实施例提供的一种文件运行装置的结构图；

图13为本申请实施例提供的一种电子设备的结构图。

具体实施方式

本申请提供一种文件运行方法及装置，用于保证非可执行文件的完整性，规避由于非可执行文件被篡改导致的安全风险。其中，方法和设备是基于同一技术构思的，由于方法及装置解决问题的原理相似，因此装置与方法的实施可以相互参见，重复之处不再赘述。

以下对本申请中的部分用语进行解释说明，以便于本领域技术人员理解。

1)电子设备，为具有数据连通功能、软件运行、数据计算和处理功能的设备或装置。例如，所述电子设备可以为计算机、手机、平板电脑、笔记本电脑、上网本、车载设备，以及商务智能终端(包括：可视电话、会议桌面智能终端等)、个人数字助理(personaldigital assistant，PDA)、增强现实(augmented reality，AR)\虚拟现实(virtualreality，VR)设备等，本申请对所述电子设备的具体形态不作限定。

2)可执行文件，为电子设备的操作系统能够直接加载执行的文件。示例性的，可执行文件的文件类型可以但不限于为以下任一项：可执行程序(executable program，EXE)文件、动态链接库(dynamic-link library，DLL)文件、磁盘映像(disk image，DMG)文件、对象类别扩充组件(object class extension，OCX)文件、系统(system，SYS)文件、应用(application，APP)文件，或命令(command，COM)文件等。

3)非可执行文件，与可执行文件相对，即除可执行文件以外的文件。非可执行文件不能被操作系统直接加载执行，而是通过可执行文件加载才能运行的文件。因此，相对于可执行文件，非可执行文件又可以称为外部被加载文件或外部文件。

非可执行文件的文件类型为除可执行文件的文件类型以外的类型。示例性的，非可执行文件可以为以下任一项：原子壳归档(atom-shell archive，ASAR)文件、可扩展标记语言(extensible markup language，XML)文件、JavaScript对象表示法(JavaScriptobject notation，JSON)文件、JavaScript(简称为JS)文件、基于JavaScript的强类型编程语言(即JavaScript with syntax for types)(TypeScript，TS)文件。

4)数字签名技术，是一种类似写在纸上的签名，但是使用密钥加密领域的技术实现，用于鉴别数字信息的方法，在网络通信中可以使用数字签名来进行身份验证。

文件的发送端对文件进行数字签名后，该文件的数字签名信息是一个独一无二的数值，发送端可以将该文件以及该文件的数字签名信息一起发送；若文件的接收端使用发送端的公钥对该文件的数字签名验证通过，表示接收端使用的公钥准确，该接收端为该文件的合法接收端，也可以表示该文件的发送端是合法的，且该文件未被篡改。

需要说明的是，在操作系统中，一般只支持对可执行文件进行数据签名，而无法对非可执行文件进行数据签名。

5)哈希(hash)算法，又称为安全散列算法或消息摘要算法，指单向散列函数。通过该算法能够把任意长度的输入消息串映射为固定长度的输出串。目前，常见的哈希算法有MD5、SHA1、SHA256等。

哈希算法满足以下特性：

a、为一个给定的输出串找出能映射到该输出串对应的输入串在计算上是困难的。

b、为一个给定的输出串找出能映射到同一个输出串的另一个输入串在计算上是困难的。

c、要发现不同的输入串映射到同一输出串在计算上是困难的。

6)软件，是一系列按照特定顺序组织的计算机指令和数据的集合，用于实现电子设备的某个业务或功能。软件又称为软件程序，二者之间可以相互替换。示例性的，按照功能划分，软件可以被划分为系统软件、应用软件，以及介于这两者之间的中间件。电子设备中的软件可以是通过软件安装包安装的，软件安装包中可以包含：可执行文件和非可执行文件。

其中，应用软件又可以称为应用(application，APP)、应用软件或应用程序。而应用软件安装包又可以简称为应用安装包。

7)“和/或”，描述关联对象的关联关系，表示可以存在三种关系，例如，A和/或B，可以表示：单独存在A，同时存在A和B，单独存在B这三种情况。字符“/”一般表示前后关联对象是一种“或”的关系。

需要说明的是，本申请中所涉及的多个，是指两个或两个以上。至少一个，是指一个或一个以上。

另外，需要理解的是，在本申请的描述中，“第一”、“第二”等词汇，仅用于区分描述的目的，而不能理解为指示或暗示相对重要性，也不能理解为指示或暗示顺序。

下面先对网络安全领域中的数字签名技术进行说明。

数字签名技术是当前业界防止文件被篡改的有效手段。参阅图1所示，数字签名技术的主要步骤如下：

S101：发送端存在原始文件需要传输的情况下，通过哈希算法对原始文件的内容计算，得到一份原始文件的摘要值。为了便于下文进行区分，本申请将此处通过S101得到的摘要值命名为摘要1。

其中，哈希算法的作用是：不论输入多长的文件内容，只要通过哈希算法计算后，都能得到一个固定长度的输出值。这个输出值，被称为文件的摘要值。由于不同的文件内容生成的摘要值不相同，因此，文件的摘要值也被称为文件的指纹。

在数字签名技术中，通过比对文件的摘要值是否一致，即可识别文件的内容是否完全一样。如果一个文件最新生成的摘要值与之前某个时刻生成的摘要值不同，证明在传输该文件的这个时间段内文件有被篡改过。

S102：发送端使用自己的私钥对S101得到的摘要1进行加密计算，得到原始文件的数字签名信息。

其中，发送端的私钥只有发送端自己知道，其他设备均无法获知该私钥的内容。与发送端的私钥配套的是发送端的公钥，而发送端的公钥是其他设备可以通过合法方式公开获取到的。当发送端使用发送端的私钥对摘要1加密生成的数字签名信息后，文件的接收端可以使用发送端的公钥对数字签名信息进行解密，从而得到摘要1以进行后续的完整性校验。

S103：发送端在S102中生成的数字签名信息会嵌入到原始文件，并且不会追加到该原始文件的内容中，得到已数字签名的文件。示例性的，数字签名信息可以嵌入原始文件的文件属性中，那么电子设备可以通过查看该已数字签名的文件的文件属性，查看到文件的数字签名信息。

S101-S103的过程即发送端对原始文件进行数字签名的过程。

S104：在S103之后，已数字签名的文件可以通过网络或者其他方式传输至接收端。接收者接收到已数字签名的文件。此时，该已数字签名的文件中包含了原始文件和数字签名信息。

S105：接收端使用发送端的公钥对数字签名信息进行解密，得到原始文件的摘要值，即摘要1。应注意，如果接收端解密时使用的公钥不正确，则会报错，无法正常解密。

S106：接收端使用哈希算法对接收的文件的内容计算，得到接收的文件的摘要值。为了区分，本申请将此处通过S106的摘要命名为摘要2。

应注意，接收端在S106中使用的哈希算法与发送端在S101中使用的哈希算法应该相同。该哈希算法可以为二者协商的或预先设定的，本申请对设置二者使用相同哈希算法的方式不作限定。

S107：接收端根据S105得到的摘要1与S106得到的摘要2进行完整性校验。接收端可以对比摘要1和摘要2是否相同；若二者相同则表示接收的文件的完整性校验通过，证明接收的文件为原始文件，原始文件未被篡改；若二者不同则表示该接收的文件的完整性校验不通过，证明该接收的文件不是原始文件，原始文件已被篡改。

上述S105-S107为接收端对已数字签名的文件进行完整性校验的过程。

另外，为了证明数字签名者的身份，文件的发送端可以向证书中心(certificateauthority，CA)申请数字证书。这样，发送端在对文件进行数字签名时，可以在文件中附上数字证书，就可以证明文件的“数字签名者”的确是发送端。接收端接收到已数字签名的文件后，在使用该文件前，可以验证该文件中附的数字证书是否在该接收端的证书信任库中。若文件中的数字证书包含在该证书信任库中，表示该文件的数字签名者是安全可信的；否则表示该文件的数字签名者不可信。

下面结合附图对本申请进行详细说明。

图2示出了本申请提供的文件运行方法适用于的软件开发场景。如图2所示，在该场景中，软件开发者可以针对用户或市场对电子设备的功能、业务需求开发软件代码，然后对该软件代码进行编译打包，得到软件安装包。该软件安装包可以通过网络或其他各种方式，传输至电子设备。最终，电子设备的操作系统可以获取该软件安装包并安装该软件，进而实现该软件对应的业务或功能。

示例性的，软件开发者可以对该软件代码中的一部分业务代码/程序框架源码进行编译打包，生成可执行文件；软件开发者可以对该软件代码中其余业务代码进行编译打包，生成非可执行文件。最终，软件开发者可以基于该可执行文件和非可执行文件，得到最终的软件安装包。应注意，业务代码也可以称为应用源码，在一些情况下，二者可以相互替换。

可选的，在本申请中，电子设备可以通过多种方式获取软件开发者开发的软件安装包。如图2中所示，软件开发者可以将软件安装包上传至服务器，电子设备可以通过网络从服务器下载该软件安装包。示例性的，该网络可以但不限于包括移动通信网络、局域网、广域网、物联网等。

另外，软件安装包还可以为电子设备的生产厂商预置到所述电子设备中的；或者软件安装包可以为电子设备的操作系统开发商预置到操作系统中的。当然，软件安装包还可以通过其他方式传输到电子设备，例如，软件安装包可以保存到计算机可读存储介质中，电子设备安装该计算机可读存储介质后，即可读取该软件安装包。其中，计算机可读存储介质可以但不限于包括：U盘、移动硬盘、只读存储器(read-only memory，ROM)、随机存取存储器(random access memory，RAM)、磁盘或者光盘等各种可以存储程序代码的介质。

电子设备获取并安装软件安装包后，电子设备的操作系统可以启动软件安装包中的可执行文件，并根据该可执行文件加载并运行软件安装包中的非可执行文件，从而可以运行该软件安装包对应的软件。示例性的，当用户在电子设备的用户界面点击软件安装包中的可执行文件的图标时，电子设备的操作系统可以启动该可执行文件。

应注意，本申请不限定软件开发者所使用的软件开发平台。示例性的，软件开发者可以但不限于通过Electron框架开发软件安装包。下面对Electron框架进行简单介绍：

Electron框架是一个使用JavaScript、超文本标记语言(hyper text markuplanguage，HTML)和层叠样式表(cascading style sheets，CSS)等网络(web)技术构建应用程序的开源框架。软件开发者使用Electron框架，可以基于业务代码构建出支持多种操作系统平台的软件。示例性的，上述多种操作系统可以但不限于以下操作系统：Mac、微软视窗(Microsoft Windows)和Linux。

Electron框架具备简单易用、门槛低、跨平台等诸多优点，目前已成为开发跨平台桌面应用程序的主流框架，被广泛使用。市面上很多桌面应用程序都是使用Electron框架开发的，例如，瓦次普(WhatsApp)、Messager、钉钉、Twitch等。

基于Electron开发构建的应用程序(下文简称Electron应用程序)，在安装目录的resources文件夹下会包含一个文件名为app.asar的文件，该文件是对业务代码打包生成的归档压缩文件，还可以包含可执行文件(例如：扩展名为.exe、.dmg、.dll、.app等的文件)。Electron应用程序的可执行文件在启动运行时会加载app.asar文件，执行其中的业务逻辑。

在如图2所示的软件开发场景中，电子设备的操作系统一般只支持对可执行文件进行数据签名，而无法对非可执行文件进行数字签名。如果非可执行文件被人恶意篡改，那么电子设备运行该非可执行文件时，会遭受恶意攻击。

例如，Windows操作系统仅支持对可移植的可执行文件(Portable Executable，PE)(例如：扩展名为.exe、.dll、.dmg、.app等的文件)进行数字签名，对于非可执行文件无法进行数字签名。

由于Electron应用程序的可执行文件中并不包含所有业务代码，因此即使Windows操作系统对Electron应用程序的可执行文件进行数字签名，也无法保护所有业务代码的完整性。而app.asar文件不属于可执行文件，在Windows操作系统下无法对其进行数字签名，Electron框架也未针对该问题采取相关的安全防护措施，因此app.asar存在被篡改注入恶意代码的安全风险。如果app.asar文件被篡改并注入恶意代码，用户在运行该Electron应用程序时，运行的可执行文件会加载运行app.asar中的恶意代码，从而遭受恶意攻击。

进一步的，由于Electron框架已被广泛应用，使用Electron框架构建出的应用程序的用户量已经多达几十亿，而基于Electron框架构建的应用程序的app.asar文件存在被篡改注入恶意代码的安全风险，因此如果能探索研究出一种防止app.asar文件被篡改注入的安全增强方法，将会大幅降低使用Electron应用程序的用户所面临的安全风险，这也是本领域技术人员亟待解决的问题。

为了保证非可执行文件的完整性，规避由于非可执行文件被篡改导致的安全风险，本申请实施例提供了一种文件运行方法。该方法适用于可执行文件加载运行非可执行文件的场景中，如图3所示。图3中的可执行文件和非可执行文件可以包含在同一软件的软件安装包中。

由于被加载运行的非可执行文件未被打包到可执行文件中，因此，操作系统对可执行文件进行数字签名无法保护非可执行文件中的业务代码的完整性。

基于图3所示的可执行文件和非可执行文件的关系图，参阅图4所示，在传统的软件开发方案中，软件开发者在开发软件过程中，会针对业务需求开发软件代码，得到软件的业务代码。

软件开发者可以对一部分业务代码(简称为第一业务代码)进行编译打包后，可以得到非可执行文件。当电子设备对另一部分业务代码(简称为第二业务代码)进行编译打包后，可以得到可执行文件。可选的，当软件开发者依赖现有的应用框架来开发软件时，第一业务代码和/或第二业务代码中可以包含应用框架的源码。其中，该应用框架的源码可以为该应用框架现有的，无需开发。

需要说明的是，以上第一业务代码和第二业务代码的划分仅是在代码编译打包后生成的是可执行文件还是非可执行文件的角度上进行区分的。即编译打包后得到非可执行文件的业务代码统称为第一业务代码，而编译打包后得到可执行功能文件的业务代码统称为第二业务代码。根据软件开发的实际需要，第一业务代码和/或第二业务代码中可以包含或依赖现有的应用框架的源码，也可以不包含或不依赖现有的应用框架的源码，还可以完全就是应用框架源码，本申请对此不作限定。

应注意，在编译打包过程中，还可能会涉及一些相关文件(例如文本文件等)，本申请实施例和附图作为示例性说明，对此不作限定。

电子设备还可以对可执行文件进行数字签名，得到已数字签名的可执行文件。

电子设备可以将非可执行文件和已数字签名的可执行文件进行打包，最终得到软件安装包。

按照可执行文件启动运行的传统通用流程和运行逻辑，目前可以将可执行文件(可执行文件对应的源码)的功能抽象划分为启动模块、加载模块和运行模块，如图4所示。

启动模块，用于启动可执行文件。

加载模块，用于加载各种文件，包括可执行文件、非可执行文件以及其他相关文件等。

运行模块，用于运行各种文件，包括可执行文件、非可执行文件以及其他相关文件等。

图4仅以加载模块和运行模块处理非可执行文件的场景为例进行说明。

通过对可执行文件传统的通用流程和运行逻辑的描述可知，由于操作系统不支持对非可执行文件进行数字签名，因此，图4所示的上述方案无法实现对非可执行文件的完整性保护，即无法实现对业务代码或文件的完整性保护。同时，由于业务代码或文件未编译打包至可执行文件中，因此，即使对可执行文件进行数字签名，也依然无法实现对业务代码或文件的完整性保护。

综上，图4所示的现有软件开发方案无法实现对软件中的业务代码或文件的完整性保护，导致业务代码或文件存在被篡改注入的风险，进而造成网络安全风险。

基于图3所示的可执行文件和非可执行文件的关系图，本申请提供了一种新的软件开发方案，参阅图5所示：

基于图4所示的传统软件开发方案，软件开发者在开发软件过程中，还可以在第二业务代码中增加对非可执行文件的完整性校验的运行逻辑，即在第二业务代码增加用于对非可执行文件进行完整性校验的程序代码。

图5所示的方案通过在生成可执行文件的第二业务代码中添加对非可执行文件的完整性校验的程序代码，再(可选的，使用数字证书)对可执行文件进行数字签名，最终可以实现对非可执行文件的完整性保护。

如图5所示，通过对可执行文件进行数字签名，可以保证可执行文件不被篡改，从而保证可执行文件的完整性；由于对非可执行文件的完整性校验的运行逻辑被打包到可执行文件中，因此，只要可执行文件不被篡改，那么对非可执行文件的完整性校验的运行逻辑就不会被篡改。进一步的，可执行文件被接收端的操作系统启动运行时，操作系统可以执行可执行文件中的对非可执行文件的完整性校验逻辑，实现对非可执行文件的完整性保护，从而保证非可执行文件不被篡改。

基于图5所示的软件开发方案，由于对非可执行文件的完整性校验是在可执行文件启动运行时自动执行的，且对可执行文件进行数字签名的机制为操作系统默认支持的保护机制，因此，本申请提供的方案的实施不需要用户手工操作来验证非可执行文件的完整性，具有便捷、安全、有效的特点。

图5所示的软件开发方案可以实现对非可执行文件进行完整性保护的效果，并且保护强度与对可执行文件进行数字签名进行完整性保护的保护强度相同。另外，由于用户运行该可执行文件过程中不需要任何手工操作，方案实施便捷可靠，用户体验高。该方案可以在图4所示的方案对可执行文件进行安全保护的基础上，实现对非可执行文件的防注入安全增强保护。

基于图5所示的软件开发方案，本申请实施例还提供了一种对非可执行文件进行完整性保护的示意图，参阅图6所示。

按照可执行文件启动运行的通用流程和运行逻辑，与图4提供的方案类似地，本申请实施例可以继续将可执行文件的功能抽象划分为启动模块、加载模块和运行模块。另外，为了实现加载模块在加载非可执行文件前先校验该非可执行文件的完整性，软件开发者可以在生成可执行文件的源码(图6中的应用程序/应用框架的源码，对应如图5中的第二业务代码)中添加一个完整性校验模块。

完整性校验模块，用于对非可执行文件进行完整性校验。

通过对可执行文件进行数字签名，可以实现对可执行文件的完整性保护，保证可执行文件中对非可执行文件的完整性校验模块不被篡改，进而可以实现对非可执行文件的完整性保护。在本申请中，操作系统可以使用数字证书对可执行文件进行数字签名，具体过程可以参考以上对图1的描述，此处不再赘述。

如图6中所示，该完整性校验模块在运行时的具体执行过程至少包括以下步骤：

a1：计算非可执行文件的摘要值。需要说明的是，本步骤中还可以为电子设备计算摘要值设置其使用的哈希算法。

a2：比较计算的摘要值与设定的基准摘要值是否相同。其中，该基准摘要值为软件开发者侧使用a1中约定的哈希算法对非可执行文件进行计算得到，并配置到该完整性校验模块中的。

a3：如果相同，则加载该非可执行文件；否则停止运行可执行文件(即停止运行应用程序或软件)。

需要说明的是，上述步骤为完整性校验模块中的运行逻辑，在应用程序/应用框架的源码中，上述步骤的形式为程序代码，上述步骤为该代码被执行时实现的动作。

该方案的实现原理为：新增的用于对非可执行文件进行完整性校验的完整性校验模块被编译打包到了可执行文件中。当对可执行文件进行数字签名后，可以防止该可执行文件被篡改，也就能防止新添加的完整性校验模块的内容被篡改。基于此，当可执行文件被运行时，可执行文件可以在加载非可执行文件之前，基于该完整性校验模块对非可执行文件进行完整性校验，最终保证了非可执行文件的完整性。显然，新添加的完整性校验模块可以实现对非可执行文件的完整性保护，最终效果等同于使用数据签名技术对可执行文件的完整性保护扩展延伸到了对非可执行文件的完整性保护。在该方案中，非可执行文件对应的完整性保护传递路径如图中的黑色粗线所示。

基于图5或图6所示的方案，本申请实施例提供了一种文件运行方法。该方法适用于运行如图3所示的可执行文件加载运行非可执行文件的场景中。该方法适用于已获取可执行文件和非可执行文件的电子设备。可选的，该方法可以由电子设备的操作系统执行，以下仅以电子设备为执行主体进行示例性的说明。应注意，本申请实施例中涉及的可执行文件可以是通过图5或图6所示的软件开发方案开发的。参阅图7所示，该方法包括以下流程：

S701：电子设备对可执行文件进行完整性校验。

可选的，所述电子设备可以通过多种获取该可执行文件以及会被该可执行文件加载的非可执行文件。以该可执行文件与该非可执行文件位于同一软件安装包中为例进行说明。例如，所述电子设备可以通过网络从服务器下载该软件安装包。又例如，所述电子设备还可以通过安装计算机可读存储介质，获取保存在计算机可读存储介质中的软件安装包。再例如，上述软件安装包为所述电子设备的生产厂商预置到所述电子设备中的。

示例性的，该软件安装包可以为软件开发者通过Electron框架开发的。

需要说明的是，由于目前操作系统支持对可执行文件进行数字签名，因此，为了保证可执行文件的完整性，软件开发者侧可以对该可执行文件进行数字签名。基于此，所述电子设备可以通过数字签名技术对该可执行文件进行完整性校验，具体过程可以参考以上对图1所示的数字签名机制的描述，此处不再赘述。

S702：当对所述可执行文件的完整性校验通过后，所述电子设备启动所述可执行文件，并根据所述可执行文件对待加载的非可执行文件进行完整性校验。

其中，当对所述可执行文件的完整性校验未通过，表示所述可执行文件已被篡改，为了保证所述电子设备的网络安全，所述电子设备不启动所述可执行文件。可选的，所述电子设备还可以删除所述可执行文件，以及所述非可执行文件，以规避安全风险和清理存储空间。另外，所述电子设备可以通过显示屏向用户提醒错误信息，提醒用户所述可执行文件的完整性校验未通过。

可选的，所述电子设备可以通过以下步骤，根据所述可执行文件对待加载的非可执行文件进行完整性校验：

b1：所述电子设备使用所述可执行文件配置的哈希算法计算所述非可执行文件的第一摘要值。

b2：所述电子设备判断所述第一摘要值与所述可执行文件包含的第二摘要值是否相同，其中，所述第二摘要值为软件开发者侧在软件发布前使用b1中使用的所述哈希算法对所述非可执行文件进行计算得到，并配置到所述可执行文件中的。

其中，当所述第一摘要值与所述第二摘要值相同时，表示对所述非可执行文件的完整性校验通过；当所述第一摘要值与所述第二摘要值不同时，表示对所述非可执行文件的完整性校验不通过。

应注意，所述可执行文件中可以包含用于对所述非可执行文件进行完整性校验的程序代码，这样，所述电子设备可以依据该程序代码执行上述步骤，对非可执行文件进行完整性校验。可选的，生成所述可执行文件的源码(例如，应用程序/应用框架的源码)中包含该用于对所述非可执行文件进行完整性校验的程序代码，如图5或图6所示。

S703：当对所述非可执行文件的完整性校验通过后，根据所述可执行文件加载并运行所述非可执行文件。

可选的，当对所述非可执行文件的完整性校验不通过时，所述电子设备停止运行所述可执行文件(即停止运行应用程序或软件)。另外，所述电子设备可以通过显示屏向用户提醒错误信息，提醒用户对所述非可执行文件的完整性校验不通过。

还需要说明的是，在本申请实施例中，所述可执行文件的文件类型可以但不限于为以下任一项：EXE文件、DLL文件、DMG文件、OCX文件、SYS文件、APP文件，或COM文件。所述非可执行文件的文件类型为除上述可执行文件的文件类型以外的类型。

通过本申请实施例提供的文件运行方法，电子设备可以根据可执行文件对待加载的非可执行文件进行完整性校验。由于可执行文件能够实现完整性保护，因此，对可执行文件的完整性保护可以扩展延伸到对非可执行文件的完整性保护，实现对非可执行文件的完整性保护，规避由于非可执行文件被篡改导致的安全风险。该方法可以打破现有的操作系统仅支持使用数字签名对可执行文件进行完整性保护的约束限制，实现通过数字签名技术间接保护非可执行文件的完整性的效果。

另外，该方案仅需要修改生成可执行文件的个别文件的源码，且修改代码的逻辑仅涉及对非可执行文件进行摘要值计算和摘要值比对，对源码无其他嵌入式修改，对软件开发者的操作实施门槛低，便于操作。由于对非可执行文件的完整性校验运行逻辑已固化在可执行文件中，因此用户在运行该可执行文件时无需再额外进行手工操作来完成对非可执行文件的完整性校验，只需要执行启动该可执行文件的操作即可实现对非可执行文件的完整性校验，能够方便、快捷、安全、有效地实现对非可执行文件的完整性保护。

下面以使用Electron框架构建软件为例进行示例性说明。

通过以上对Electron框架的说明，参阅图8对基于Electron框架的软件开发方案进行说明。如图8所示，软件开发者可以基于Electron框架开发软件的业务代码。软件开发者还可以对Electron框架源码进行编译打包，生成Electron框架压缩包(例如扩展名为.zip的文件)。最后，软件开发者可以对软件的业务代码和Electron框架压缩包进行编译打包，生成软件安装包。其中，该软件安装包中有基于该业务代码编译打包得到的非可执行文件(以图中的app.asar文件为例)，以及可执行文件(以图中app.exe文件为例)。在生成软件安装包时，软件开发者还可以对软件安装包中的可执行文件进行数字签名，以对可执行文件进行完整性保护。

当某个电子设备获取该软件安装包并完成安装后，可以启动该app.exe文件，然后根据该app.exe文件加载运行app.asar文件，最终运行该软件，如图9所示。

在图8所示的软件开发方案中，由于Electron框架开发软件过程中，软件的业务代码被编译打包到了app.asar文件，因此对app.exe文件进行完整性保护无法保护app.asar文件的完整性。app.asar文件是非可执行文件，无法对其进行数字签名实现完整性保护，因此，app.asar文件存在被篡改注入的风险。

基于图8所示基于Electron框架的传统软件开发方案，本申请提供了一种新的基于Electron框架的软件开发方案，参阅图10所示：

软件开发者在开发软件过程中，可以修改Electron框架的源码，在源码中增加用于在加载app.asar文件前先校验app.asar的完整性的程序代码。这样，当软件开发者对修改后的Electron框架的源码编译打包生成app.exe文件后，使用数字证书对该app.exe文件进行数字签名，最终可以实现对app.asar文件的完整性保护。

如图10所示，通过对app.exe文件进行数字签名，可以保证app.exe文件不被篡改，保证app.exe文件的完整性；由于对app.asar文件的完整性校验的运行逻辑被打包到app.exe文件中，因此，只要app.exe不被篡改，那么对app.asar文件的完整性校验的运行逻辑就不会被篡改。进一步的，app.exe文件被接收端的操作系统启动运行时，操作系统会执行app.exe文件中的对app.asar文件的完整性校验逻辑，实现对app.asar文件的完整性保护，从而保证app.asar文件不被篡改。

显然，在源码中增加用于在加载app.asar文件前先校验app.asar文件的完整性的程序代码可以实现对加载app.asar文件的完整性保护，最终效果等同于使用数据签名技术对app.exe文件的完整性保护扩展延伸到了对app.asar文件的完整性保护。因此，该方法可以提升基于Electron构建的应用程序的安全性。

根据图10所示的基于Electron框架的软件开发方案，本申请实施例提供了一种对非可执行文件(以app.asar文件为例)的完整性保护方案，参阅图11所示。

按照可执行文件(以app.exe文件为例)启动运行的通用流程和运行逻辑，与图4类似的，本申请实施例可以将Electron框架的源码抽象划分为启动模块、加载模块和运行模块。另外，为了实现加载模块在加载app.asar文件前先校验该app.asar文件的完整性，软件开发者可以在Electron框架的源码中添加一个完整性校验模块。

完整性校验模块，用于对app.asar文件进行完整性校验。

本实施例通过对app.exe文件进行数字签名，可以实现对app.exe文件的完整性保护，保证app.exe文件中对app.asar文件的完整性校验模块不被篡改，进而可以实现对app.asar文件的完整性保护。在本申请中，操作系统可以使用数字证书对app.exe文件进行数字签名，具体过程可以参考以上对图1的描述，此处不再赘述。

如图11中所示，在运行app.exe文件之后，该完整性校验模块在运行时的具体执行过程至少包括以下步骤：

c1：计算app.asar文件的摘要值。需要说明的是，本步骤中还可以设置计算摘要值所使用的哈希算法。

c2：比较计算的摘要值与设定的基准摘要值是否相同。其中，该基准摘要值为软件开发者侧使用c1中约定的哈希算法对app.asar文件进行计算得到，并配置到该完整性校验模块中的。

c3：如果相同，则加载该app.asar文件；否则停止运行应用程序。

下面参阅图11对本方案进行详细说明：

d1：在软件开发过程中，软件开发者修改Electron框架的源码(例如修改lib/browser/init.ts)，在不改动其他代码的基础上，在其中增加完整性校验模块。该模块中代码的运行逻辑内容如下：

I、在app.exe文件启动并加载运行安装目录下的app.asar文件前，先使用哈希算法实时计算app.asar文件的摘要值。可选的，该完整性校验模块中还可以包含对该哈希算法的约定。当然，软件开发者还可以通过其他方式约定计算app.asar文件的摘要值的哈希算法，本申请对此不作限定。

II、针对步骤I中实时计算得到的app.asar文件摘要值，判断其是否与设定的基准摘要值相同。其中，该基准摘要值是指软件开发者侧计算的原始发布的app.asar文件的摘要值，也就是图11中软件开发者对业务代码进行编译打包生成的app.asar文件的摘要值。

需要注意的是，由于在修改Electron框架的源码时，app.asar文件可能还未生成，软件开发者可以先使用“基准摘要值”字符串常量代指实际的摘要值，等到app.asar文件生成后，再将此处的“基准摘要值”字符串常量替换成app.asar文件的实际摘要值。

III、如果步骤II中计算得到的app.asar摘要值与设定的基准摘要值相同，则app.exe文件正常加载app.asar文件；否则停止运行应用程序，并在用户界面上给出app.asar校验失败的错误提示信息。

d2：将修改后的Electron框架的源码编译打包成可直接供应用程序使用的Electron框架压缩包。

d3：基于步骤d2中的Electron框架压缩包，将业务代码编译打包成软件安装包。其中，该软件安装包中包含可执行文件(即app.exe文件)和非可执行文件(即app.asar文件)。

其中，业务代码被编译打包到app.asar文件，Electron框架压缩包被编译打包到app.exe文件中。

应注意，在不同的操作系统下，操作系统生成的可执行文件的文件类型不同。示例性的，在Windows操作系统下编译构建出的是扩展名为.exe的文件，在Mac操作系统下编译构建出的是扩展名为.dmg或.app的文件。本申请统一称之为可执行文件。

在本方案中，app.exe文件在启动时会加载app.asar文件。由于在步骤d1中增加了对app.asar文件的完整性校验模块，app.exe文件在加载app.asar文件前会先校验app.asar文件的完整性，从而防止了由于app.asar文件被篡改注入而导致用户遭受攻击。

d4：软件开发者使用数字证书对app.exe文件进行数字签名，以实现对app.exe文件的完整性保护。由于app.exe文件中包含了的对app.asar的完整性校验机制，因此app.exe文件的数字签名也间接保护了app.asar的完整性。

当该软件安装包被接收者运行时，接收者的操作系统会对app.exe文件进行完整性校验后，运行该app.exe文件；在该app.exe文件加载app.asar文件之前，通过完整性校验模块执行上述I-III的运行逻辑，实现对app.asar文件的完整性校验。

本实施例可以将对可执行文件(例如app.exe文件)的数字签名完整性保护机制，扩展延伸到对非可执行文件(例如app.asar文件)的完整性保护，打破了数字签名仅支持对可执行文件进行完整性保护的约束限制，实现了通过数字签名间接保护非可执行文件的完整性。

由于目前的数字签名技术仅支持对可执行文件(例如，.dll、.exe、.dmg、app等扩展名的文件)进行完整性保护，通过实施本申请提供的方案，可以将数字签名对可执行程序的完整性保护机制，传递到了对非可执行文件进行完整性保护，从而间接实现了对非可执行文件进行完整性保护。

图11所示的方法不需要对Electron框架的C/C++源代码进行补丁(Patch)，仅需修改个别文件(如lib/browser/init.ts)，且修改代码的逻辑仅涉及对app.asar文件计算摘要值并进行摘要值的比较，对Electron框架的源码无其它侵入式修改，操作实施门槛低，方便跟随Electron开源社区版本升级演进。

在该方法中，对非可执行文件(如app.asar)的完整性校验已经固化在了可执行文件(如app.exe文件)中，用户在使用时无需再额外进行手工操作来完成对app.asar的完整性校验，只需要和平时一样正常运行可执行文件，即可实现对非可执行文件的完整性保护，具备方便、快捷、安全有效的特点。

基于相同的技术构思，本申请还提供了一种文件运行装置，该装置可以适用于电子设备，用于实现如图7所示的文件运行方法。参阅图12所示，文件运行装置1200中包括：第一校验模块1201、启动模块1202、第二校验模块1203、加载模块1204、运行模块1205。下面对各个单元的功能进行描述。

第一校验模块1201，用于对可执行文件进行完整性校验；

启动模块1202，用于当对所述可执行文件的完整性校验通过后，启动所述可执行文件；

第二校验模块1203，用于根据所述可执行文件对待加载的非可执行文件进行完整性校验；

加载模块1204，用于当对所述非可执行文件的完整性校验通过后，根据所述可执行文件加载所述非可执行文件；

运行模块1205，用于运行所述非可执行文件。

可选的，所述第二校验模块1203，具体用于：

使用所述可执行文件配置的哈希算法计算所述非可执行文件的第一摘要值；

判断所述第一摘要值与所述可执行文件包含的第二摘要值是否相同；所述第二摘要值为软件发布前使用所述哈希算法对所述非可执行文件进行计算得到并配置到所述可执行文件中的；

其中，当所述第一摘要值与所述第二摘要值相同时，表示对所述非可执行文件的完整性校验通过；当所述第一摘要值与所述第二摘要值不同时，表示对所述非可执行文件的完整性校验不通过。

可选的，所述启动模块1202，还用于：

当对所述非可执行文件的完整性校验不通过时，停止运行所述可执行文件。

可选的，所述可执行文件中包含用于对所述非可执行文件进行完整性校验的程序代码。

可选的，所述可执行文件与所述非可执行文件位于软件安装包中。

可选的，所述软件安装包为通过Electron框架开发的。

可选的，所述可执行文件的文件类型为以下任一项：可执行程序EXE文件、动态链接库DLL文件、磁盘映像DMG文件、对象类别扩充组件OCX文件、系统SYS文件、应用APP文件，或命令COM文件。

需要说明的是，本申请实施例中对模块的划分是示意性的，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，另外，在本申请各个实施例中的各功能单元可以集成在一个处理单元中，也可以是单独物理存在，也可以两个或两个以上单元集成在一个单元中。上述集成的单元既可以采用硬件的形式实现，也可以采用软件功能单元的形式实现。

所述集成的单元如果以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在一个计算机可读取存储介质中。基于这样的理解，本申请的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的全部或部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)或处理器(processor)执行本申请各个实施例所述方法的全部或部分步骤。而前述的存储介质包括：U盘、移动硬盘、只读存储器(read-only memory，ROM)、随机存取存储器(random access memory，RAM)、磁碟或者光盘等各种可以存储程序代码的介质。

基于相同的技术构思，本申请还提供了一种电子设备，所述电子设备适用于运行如图3所示的可执行文件加载运行非可执行文件的场景中，用于实现如图7所示的文件运行方法，具有如图12所示的文件运行装置1200的功能。参阅图13所示，所述电子设备1300包括：处理器1301，存储器1302。可选的，所述电子设备1300还可以包括通信模块1303。

其中，所述处理器1301与其它部件之间相互连接。可选的，所述处理器1301和其他部件可以通过总线相互连接；所述总线可以是外设部件互连标准(peripheral componentinterconnect，PCI)总线或扩展工业标准结构(extended industry standardarchitecture，EISA)总线等。所述总线可以分为地址总线、数据总线、控制总线等。为便于表示，图13中仅用一条粗线表示，但并不表示仅有一根总线或一种类型的总线。

所述通信模块1303，用于接收和发送数据。示例性的，所述通信模块1303可以为通信接口，也可以为收发器，本申请对此不作限定。可选的，所述电子设备1300可以基于所述通信模块1303接收软件安装包。

所述处理器1301，用于实现如图7所示的文件运行方法，具体可以参见上述实施例中的描述，此处不再赘述。

在一些实施方式中，所述电子设备1300还可以包括摄像头、各种传感器、显示屏等部件。

所述存储器1302，用于存放计算机程序和数据等。具体地，计算机程序可以包括程序代码，该程序代码包括计算机操作的指令。存储器1302可能包含随机存取存储器(randomaccess memory，RAM)，也可能还包括非易失性存储器(non-volatile memory)，例如至少一个磁盘存储器。所述处理器1301执行所述存储器1302所存放的程序指令，并通过上述各个部件，实现上述功能，从而最终实现以上实施例提供的文件运行方法。

基于以上实施例，本申请实施例还提供了一种计算机程序，当所述计算机程序在计算机上运行时，使得所述计算机执行以上实施例提供的文件运行方法。

基于以上实施例，本申请实施例还提供了一种计算机存储介质，该计算机存储介质中存储有计算机程序，所述计算机程序被计算机执行时，使得计算机执行以上实施例提供的文件运行方法。

基于以上实施例，本申请实施例还提供了一种芯片，所述芯片用于读取存储器中存储的计算机程序，实现以上实施例提供的文件运行方法。

基于以上实施例，本申请实施例提供了一种芯片系统，该芯片系统包括处理器，用于支持以上实施例中电子设备所涉及的功能。在一种可能的设计中，所述芯片系统还包括存储器，所述存储器用于保存该计算机装置必要的程序和数据。该芯片系统，可以由芯片构成，也可以包含芯片和其他分立器件。

本申请实施例提供了一种文件运行方法及装置，在该方案中，电子设备可以根据可执行文件对待加载的非可执行文件进行完整性校验。由于可执行文件能够实现完整性保护，因此，对可执行文件的完整性保护可以扩展延伸到对非可执行文件的完整性保护，实现对非可执行文件的完整性保护，规避由于非可执行文件被篡改导致的安全风险。该方法可以打破现有的操作系统仅支持使用数字签名对可执行文件进行完整性保护的约束限制，实现通过数字签名技术间接保护非可执行文件的完整性的效果。

本领域内的技术人员应明白，本申请的实施例可提供为方法、系统、或计算机程序产品。因此，本申请可采用完全硬件实施例、完全软件实施例、或结合软件和硬件方面的实施例的形式。而且，本申请可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、CD-ROM、光学存储器等)上实施的计算机程序产品的形式。

本申请是参照根据本申请的方法、设备(系统)、和计算机程序产品的流程图和/或方框图来描述的。应理解可由计算机程序指令实现流程图和/或方框图中的每一流程和/或方框、以及流程图和/或方框图中的流程和/或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其他可编程数据处理设备的处理器以产生一个机器，使得通过计算机或其他可编程数据处理设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的装置。

这些计算机程序指令也可存储在能引导计算机或其他可编程数据处理设备以特定方式工作的计算机可读存储器中，使得存储在该计算机可读存储器中的指令产生包括指令装置的制造品，该指令装置实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能。

这些计算机程序指令也可装载到计算机或其他可编程数据处理设备上，使得在计算机或其他可编程设备上执行一系列操作步骤以产生计算机实现的处理，从而在计算机或其他可编程设备上执行的指令提供用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的步骤。

显然，本领域的技术人员可以对本申请进行各种改动和变型而不脱离本申请的精神和范围。这样，倘若本申请的这些修改和变型属于本申请权利要求及其等同技术的范围之内，则本申请也意图包含这些改动和变型在内。

Claims (17)

1.一种文件运行方法，应用于电子设备，其特征在于，所述方法包括：

对可执行文件进行完整性校验；

当对所述可执行文件的完整性校验通过后，启动所述可执行文件，并根据所述可执行文件对待加载的非可执行文件进行完整性校验；

当对所述非可执行文件的完整性校验通过后，根据所述可执行文件加载并运行所述非可执行文件。

2.如权利要求1所述的方法，其特征在于，根据所述可执行文件对待加载的非可执行文件进行完整性校验，包括：

使用所述可执行文件配置的哈希算法计算所述非可执行文件的第一摘要值；

判断所述第一摘要值与所述可执行文件包含的第二摘要值是否相同；所述第二摘要值为软件发布前使用所述哈希算法对所述非可执行文件进行计算得到并配置到所述可执行文件中的；

其中，当所述第一摘要值与所述第二摘要值相同时，表示对所述非可执行文件的完整性校验通过；当所述第一摘要值与所述第二摘要值不同时，表示对所述非可执行文件的完整性校验不通过。

3.如权利要求1或2所述的方法，其特征在于，所述方法还包括：

当对所述非可执行文件的完整性校验不通过时，停止运行所述可执行文件。

4.如权利要求1-3任一项所述的方法，其特征在于，所述可执行文件中包含用于对所述非可执行文件进行完整性校验的程序代码。

5.如权利要求1-4任一项所述的方法，其特征在于，所述可执行文件与所述非可执行文件位于软件安装包中。

6.如权利要求5所述的方法，其特征在于，所述软件安装包为通过Electron框架开发的。

7.如权利要求1-6任一项所述的方法，其特征在于，所述可执行文件的文件类型为以下任一项：可执行程序EXE文件、动态链接库DLL文件、磁盘映像DMG文件、对象类别扩充组件OCX文件、系统SYS文件、应用APP文件，或命令COM文件。

8.一种文件运行装置，应用于电子设备，其特征在于，所述装置包括：

第一校验模块，用于对可执行文件进行完整性校验；

启动模块，用于当对所述可执行文件的完整性校验通过后，启动所述可执行文件；

第二校验模块，用于根据所述可执行文件对待加载的非可执行文件进行完整性校验；

加载模块，用于当对所述非可执行文件的完整性校验通过后，根据所述可执行文件加载所述非可执行文件；

运行模块，用于运行所述非可执行文件。

9.如权利要求8所述的装置，其特征在于，所述第二校验模块，具体用于：

使用所述可执行文件配置的哈希算法计算所述非可执行文件的第一摘要值；

判断所述第一摘要值与所述可执行文件包含的第二摘要值是否相同；所述第二摘要值为软件发布前使用所述哈希算法对所述非可执行文件进行计算得到并配置到所述可执行文件中的；

其中，当所述第一摘要值与所述第二摘要值相同时，表示对所述非可执行文件的完整性校验通过；当所述第一摘要值与所述第二摘要值不同时，表示对所述非可执行文件的完整性校验不通过。

10.如权利要求8或9所述的装置，其特征在于，所述启动模块，还用于：

当对所述非可执行文件的完整性校验不通过时，停止运行所述可执行文件。

11.如权利要求8-10任一项所述的装置，其特征在于，所述可执行文件中包含用于对所述非可执行文件进行完整性校验的程序代码。

12.如权利要求8-11任一项所述的装置，其特征在于，所述可执行文件与所述非可执行文件位于软件安装包中。

13.如权利要求12所述的装置，其特征在于，所述软件安装包为通过Electron框架开发的。

14.如权利要求8-13任一项所述的装置，其特征在于，所述可执行文件的文件类型为以下任一项：可执行程序EXE文件、动态链接库DLL文件、磁盘映像DMG文件、对象类别扩充组件OCX文件、系统SYS文件、应用APP文件，或命令COM文件。

15.一种电子设备，其特征在于，所述电子设备包括：存储器和处理器；

所述处理器，与所述存储器耦合，用于读取所述存储器中的计算机程序，实现如权利要求1-7任一项所述的方法。

16.一种计算机可读存储介质，其特征在于，所述计算机可读存储介质中存储有计算机程序，当所述计算机程序在计算机上运行时，使得所述计算机执行权利要求1-7任一项所述的方法。

17.一种芯片，其特征在于，所述芯片与存储器耦合，所述芯片读取存储器中存储的计算机程序，执行权利要求1-7任一项所述的方法。