文件规则引擎库的生成、文件信息检测方法、装置及设备与流程

1.本公开涉及人工智能技术领域，具体涉及深度学习、知识图谱技术领域，尤其涉及一种文件规则引擎库的生成、文件信息检测方法、装置及设备。


背景技术：

2.人工智能是研究使计算机来模拟人的某些思维过程和智能行为(如学习、推理、思考、规划等)的学科，既有硬件层面的技术也有软件层面的技术。人工智能硬件技术一般包括如传感器、专用人工智能芯片、云计算、分布式存储、大数据处理等技术；人工智能软件技术主要包括计算机视觉技术、语音识别技术、自然语言处理技术以及机器学习/深度学习、大数据处理技术、知识图谱技术等几大方向。
3.相关技术中，通常依赖于ai模型来检测文件信息。


技术实现要素：

4.本公开提供了一种文件规则引擎库的生成、文件信息检测方法、装置、电子设备、存储介质及计算机程序产品。
5.根据本公开的第一方面，提供了一种文件规则引擎库的生成方法，包括：确定适于应用程序的检测规则的第一数据量；获取第一数据量的候选文件信息，和与每个候选文件信息对应的候选特征；为每个候选特征配置文件检测规则；以及根据第一数据量的候选文件信息、候选特征，以及文件检测规则生成文件规则引擎库。
6.根据本公开的第二方面，提供了一种文件信息检测方法，包括：获取应用程序的应用特征；确定如上述第一方面的文件规则引擎库的生成方法生成的文件规则引擎库中是否存在与应用特征对应的参考特征，得到确定结果；以及根据确定结果检测目标文件信息。
7.根据本公开的第三方面，提供了一种文件规则引擎库的生成装置，包括：第一确定模块，用于确定适于应用程序的检测规则的第一数据量；第一获取模块，用于获取第一数据量的候选文件信息，和与每个候选文件信息对应的候选特征；配置模块，用于为每个候选特征配置文件检测规则；以及第一生成模块，用于根据第一数据量的候选文件信息、候选特征，以及文件检测规则生成文件规则引擎库。
8.根据本公开的第四方面，提供了一种文件信息检测装置，包括：第二获取模块，用于获取应用程序的应用特征；第二确定模块，用于确定如上述第三方面的文件规则引擎库的生成装置生成的文件规则引擎库中是否存在与应用特征对应的参考特征，得到确定结果；以及检测模块，用于根据确定结果检测目标文件信息。
9.根据本公开的第五方面，提供了一种电子设备，包括：至少一个处理器；以及与至少一个处理器通信连接的存储器；其中，存储器存储有可被至少一个处理器执行的指令，指令被至少一个处理器执行，以使至少一个处理器能够执行如本公开第一方面的文件规则引擎库的生成方法，或者执行如本公开第二方面的文件信息检测方法。
10.根据本公开的第六方面，提供了一种存储有计算机指令的非瞬时计算机可读存储
介质，计算机指令用于使计算机执行如本公开第一方面的文件规则引擎库的生成方法，或者执行如本公开第二方面的文件信息检测方法。
11.根据本公开的第七方面，提供了一种计算机程序产品，包括计算机程序，计算机程序在被处理器执行时实现如本公开第一方面的文件规则引擎库的生成方法的步骤，或者实现如本公开第二方面的文件信息检测方法的步骤。
12.应当理解，本部分所描述的内容并非旨在标识本公开的实施例的关键或重要特征，也不用于限制本公开的范围。本公开的其它特征将通过以下的说明书而变得容易理解。
附图说明
13.附图用于更好地理解本方案，不构成对本公开的限定。其中：
14.图1是根据本公开第一实施例的示意图；
15.图2是根据本公开第二实施例的示意图；
16.图3是根据本公开第三实施例的示意图；
17.图4是根据本公开第四实施例的示意图；
18.图5是本公开实施例中的文件信息检测装置的架构示意图；
19.图6是本公开实施例中的文件规则引擎库的线上更新示意图；
20.图7是本公开实施例中的文件检测模型的线上更新示意图；
21.图8是根据本公开第五实施例的示意图；
22.图9是根据本公开第六实施例的示意图；
23.图10是根据本公开第七实施例的示意图；
24.图11是根据本公开第八实施例的示意图；
25.图12示出了可以用来实施本公开的方法的示例电子设备的示意性框图。
具体实施方式
26.以下结合附图对本公开的示范性实施例做出说明，其中包括本公开实施例的各种细节以助于理解，应当将它们认为仅仅是示范性的。因此，本领域普通技术人员应当认识到，可以对这里描述的实施例做出各种改变和修改，而不会背离本公开的范围和精神。同样，为了清楚和简明，以下的描述中省略了对公知功能和结构的描述。
27.图1是根据本公开第一实施例的示意图。
28.其中，需要说明的是，本实施例的文件规则引擎库的生成方法的执行主体为文件规则引擎库的生成装置，该装置可以由软件和/或硬件的方式实现，该装置可以配置在电子设备中，电子设备可以包括但不限于终端、服务器端等。
29.本公开实施例涉及人工智能技术领域，具体涉及深度学习、知识图谱等技术领域。
30.其中，人工智能(artificial intelligence，ai)，它是研究、开发用于模拟、延伸和扩展人的智能的理论、方法、技术及应用系统的一门新的技术科学。
31.深度学习，是学习样本数据的内在规律和表示层次，这些学习过程中获得的信息对诸如文字，图像和声音等数据的解释有很大的帮助。深度学习的最终目标是让机器能够像人一样具有分析学习能力，能够识别文字、图像和声音等数据。
32.知识图谱，是显示知识发展进程与结构关系的一系列各种不同的图形，用可视化
技术描述知识资源及其载体，挖掘、分析、构建、绘制和显示知识及它们之间的相互联系，以及通过将应用数学、图形学、信息可视化技术、信息科学等学科的理论与方法与计量学引文分析、共现分析等方法结合，并利用可视化的图谱形象地展示学科的核心结构、发展历史、前沿领域以及整体知识架构达到多学科融合目的的现代理论。
33.本公开的技术方案中，所涉及的用户个人信息的收集、存储、使用、加工、传输、提供和公开等处理，均符合相关法律法规的规定，且不违背公序良俗。
34.如图1所示，该文件规则引擎库的生成方法，包括：
35.s101：确定适于应用程序的检测规则的第一数据量。
36.其中，应用程序，指为完成某项或多项特定工作的计算机程序，它运行在用户模式，可以和用户进行交互，具有可视的用户界面。
37.本公开实施例中支持对应用程序是否携带文件信息进行有效地检测。
38.举例而言，文件信息可以例如是指计算机病毒的文件信息，计算机病毒，是一种程序文件，它通过不同的途径潜伏或寄生在存储媒体(磁盘、程序)里，当某种条件或时机成熟时，能够自我复制并传播，使计算机资源受到不同程度的破坏。
39.本公开实施例中的文件信息，也可以为计算机系统中其他任意可能形式的文件信息，比如资源文件信息、内存文件信息等等，对此不做限制。
40.其中，检测规则，是指对文件信息进行检测时所配置的检测匹配规则，比如文件信息a的特征和文件信息b的特征的相似度大于百分之七十，则确定文件信息a和文件信息b匹配，或者，也可以是其他任意可能形式的检测规则，比如确定文件信息a和文件信息b之间的置信度，基于置信度进行检测，对此不做限制。
41.其中，检测规则可以基于实际文件信息检测场景的需求自适应配置，对此不做限制。
42.本公开实施例中为了便于文件规则引擎库在电子设备本地的部署和实施，使得所生成文件规则引擎库的规模大小与电子设备中待检测的应用程序的实际情况相适配，可以对电子设备中的一个或者多个应用程序配置适应数据量的检测规则，该数据量可以被称为第一数据量，该第一数据量可以例如为检测规则的条数，对此不做限制。
43.举例而言，在确定适于应用程序的检测规则的第一数据量，可以对应用程序的业务能力、功能，以及所支持业务的类型，该业务类型所需加载的数据量，以及文件检测频率进行分析处理，确定适于该应用程序的检测规则的第一数据量，该第一数据量可以被用于构建合适规模的文件规则引擎库，以便于文件规则引擎库能够更好地在电子设备本地的部署和实施。
44.s102：获取第一数据量的候选文件信息，和与每个候选文件信息对应的候选特征。
45.上述确定适于应用程序的检测规则的第一数据量之后，可以获取确定适于应用程序的检测规则的第一数据量，以及与每个候选文件信息对应的候选特征。
46.也即是说，首先获取适于应用程序的检测规则的第一数据量，以确定适于应用程序的文件规则引擎库的规模大小，而后获取相应第一数据量的候选文件信息，该候选文件信息可以是预先获知计算机病毒的文件信息，分析每个候选文件信息的特征作为候选特征(例如，计算机病毒的文件信息的标识符、文件的解析特征等)，对此不做限制。
47.其中，每个候选文件信息对应的候选特征，还可以例如为android应用程序包
(android application package，apk)的apk包名、apk类型、签名，以及自定义的特征，而后还可以针对每种候选特征配置文件检测规则。
48.s103：为每个候选特征配置文件检测规则。
49.本公开实施例中，在针对每种候选特征配置文件检测规则时，还可以是为每种候选特征配置黑名单和白名单，比如apk包名黑名单、apk包名白名单，apk类型的黑白名单、签名黑白名单，以及自定义的特征的黑白名单，将文件检测规则配置为与相应类型候选特征的黑白名单进行匹配检测，对此不做限制。
50.s104：根据第一数据量的候选文件信息、候选特征，以及文件检测规则生成文件规则引擎库。
51.上述在获得第一数据量的候选文件信息、候选特征，以及文件检测规则之后，可以根据第一数据量的候选文件信息、候选特征，以及文件检测规则生成文件规则引擎库。
52.例如，可以将第一数据量的候选文件信息、候选特征，以及文件检测规则写入数据库中，并将写入内容的数据库作为文件规则引擎库。
53.又例如，也可以执行预先配置的规则引擎生成脚本文件，以处理第一数据量的候选文件信息、候选特征，以及文件检测规则得到文件规则引擎库，对此不做限制。
54.本实施例中，通过确定适于应用程序的检测规则的第一数据量，并获取第一数据量的候选文件信息，和与每个候选文件信息对应的候选特征，为每个候选特征配置文件检测规则，以及根据第一数据量的候选文件信息、候选特征，以及文件检测规则生成文件规则引擎库，所得文件规则引擎库能够支持检测文件信息，由于不依赖于ai模型来检测文件信息，从而能够避免使用ai模型进行文件信息检测的局限性，有效提升文件信息检测成功的概率，提升文件信息检测效果。
55.本公开实施例中还提供了一种文件规则引擎库的生成方法，还可以对文件规则引擎库进行加密处理，得到文件规则引擎库的加密信息，生成与加密信息对应的密钥位置信息，其中，密钥位置信息用于描述密钥信息的存储位置，从而有效避免文件规则引擎库被篡改，提升文件规则引擎库的保密安全性。
56.本公开实施例中还提供了一种文件规则引擎库的生成方法，还可以在本地服务层对文件规则引擎库进行加密处理，能够进一步提升文件规则引擎库的保密安全等级。
57.举例而言，该文件规则引擎库可以被预先加载至扫描应用程序的软件开发工具包(software development kit，sdk)中，该扫描应用程序可以用于对文件信息进行扫描检测，由于预先对文件规则引擎库进行加密，则每次扫描应用程序sdk启动时可以对文件规则引擎库进行解密，并在解密后加载文件规则引擎库中的文件检测规则。
58.举例而言，文件规则引擎库中的数据，可以通过高级加密标准(advanced encryption standard，aes)方式，针对文件规则引擎库中每行数据(例如可以描述文件检测规则)随机生成密钥信息，而后，将密钥信息配置在加密数据中的某个随机位置，并记录该随机位置相关的信息(可以被称为密钥位置信息)，该密钥位置信息可用于描述密钥信息在加密数据中的起止位置，在解密时可以先获取密钥位置信息(该密钥信息的起始、终止位置)，而后再进行解密处理，还可以支持将文件规则引擎库的加密、解密处理均下沉至native层(本地服务层)，使得文件规则引擎库的数据防护能力得以有效保障。
59.本公开实施例中还提供了一种文件规则引擎库的生成方法，在确定适于应用程序
的检测规则的第一数据量时，可以确定应用程序的程序性能信息，并确定对应用程序进行文件信息检测的频率，以及根据程序性能信息和检测的频率，确定第一数据量，使得所构建的文件规则引擎库，能够有效适配于实际文件信息检测的情况，并且便于实现文件规则引擎库的轻量化部署。
60.其中，应用程序的程序性能信息，用于描述应用程序的功能情况，比如应用程序所占内存大小，应用程序包的大小等，应用程序进行文件信息检测的频率，可以例如为一定时间范围内进行文件信息检测的次数、一次文件信息检测所需的检测时间，或者基于检测周期所确定的频率等等，对此不做限制。
61.上述在还可以根据程序性能信息和检测的频率，确定第一数据量，比如可以基于模型的方式确定，对此不做限制。
62.图2是根据本公开第二实施例的示意图。
63.如图2所示，该文件规则引擎库的生成方法，包括：
64.s201：确定适于应用程序的检测规则的第一数据量。
65.s202：获取第一数据量的候选文件信息，和与每个候选文件信息对应的候选特征。
66.s203：为每个候选特征配置文件检测规则。
67.s204：根据第一数据量的候选文件信息、候选特征，以及文件检测规则生成文件规则引擎库。
68.针对s201-s204的描述说明可以具体参见上述实施例，在此不再赘述。
69.s205：根据文件规则引擎库，生成待编译程序代码文件。
70.其中，待编译程序代码文件，可以是指该文件规则引擎库对应的源程序代码文件，待编译程序代码文件可以被编译，在编译并被运行后可支持相应的功能，比如文件信息检测功能，文件信息查询功能等。
71.s206：将待编译程序代码文件添加至初始程序代码文件中，以得到目标程序代码文件，其中，被编译的初始程序代码文件用于基于文件检测模型进行文件信息检测。
72.上述在根据文件规则引擎库，生成待编译程序代码文件之后，可以将待编译程序代码文件添加至初始程序代码文件中，以得到目标程序代码文件，其中，被编译的初始程序代码文件用于基于文件检测模型进行文件信息检测。
73.举例而言，该初始程序代码文件可以例如扫描类应用程序对应的源程序代码文件，扫描类应用程序通常可以基于初次联网时获得的ai检测模型来进行文件信息检测。
74.本公开实施例中，可以支持将待编译程序代码文件与初始程序代码文件进行合成，得到目标程序代码文件，从而使得目标程序代码文件能够支持多样化的文件信息检测功能。
75.s207：对目标程序代码文件进行编译处理，其中，被编译的目标程序代码文件用于基于文件检测模型和/或文件规则引擎库进行文件信息检测。
76.上述在将待编译程序代码文件添加至初始程序代码文件中，以得到目标程序代码文件之后，可以对目标程序代码文件进行编译处理，其中，被编译的目标程序代码文件用于基于文件检测模型和/或文件规则引擎库进行文件信息检测。
77.其中，该文件检测模型，还可以是基于构建文件规则引擎库所参考的候选文件信息、候选特征对基于初次联网时获得的ai检测模型进行迭代训练得到，也即是说，该文件检
测模型相比初次联网时获得的ai检测模型，具有更优的文件信息检测能力。
78.本实施例中，不依赖于ai模型来检测文件信息，从而能够避免使用ai模型进行文件信息检测的局限性，有效提升文件信息检测成功的概率，提升文件信息检测效果。通过根据文件规则引擎库，生成待编译程序代码文件，并将待编译程序代码文件添加至初始程序代码文件中，以得到目标程序代码文件，其中，被编译的初始程序代码文件用于基于文件检测模型进行文件信息检测，以及对目标程序代码文件进行编译处理，其中，被编译的目标程序代码文件用于基于文件检测模型和/或文件规则引擎库进行文件信息检测，从而支持将文件规则引擎库的待编译程序代码文件添加至初始程序代码文件，当该初始程序代码文件是扫描类应用程序的sdk中的源程序代码文件时，还可以实现将文件规则引擎库的待编译程序代码文件随编译自动打包至扫描类应用程序的sdk中，针对离线扫描场景形成有效的文件信息检测与识别能力。
79.本公开实施例中还提供了一种文件规则引擎库的生成方法，还可以获取第二数据量的候选文件信息，第二数据量大于第一数据量；对第二数据量的候选文件信息进行排序处理；从排序处理后第二数据量的候选文件信息中选择排序在前的第一数据量的候选文件信息，能够有效避免所得文件规则引擎库占用过多的运算资源，并且保障文件规则引擎库的文件检测效果。
80.其中，第二数据量的候选文件信息，可以是预先从云端海量病毒库规则引擎中拉取的，具体的获取方式可以是在在线状态下直接从云端海量病毒库规则引擎中获取，或者，还可以是在离线状态下基于自动化脚本实现，对此不做限制。
81.上述对第二数据量的候选文件信息进行排序处理，可以例如基于候选文件信息的重要等级进行排序，或者还可以基于候选文件信息的大小进行排序，对此不做限制。
82.本公开实施例中还提供了一种文件规则引擎库的生成方法，对第二数据量的候选文件信息进行排序处理，还可以是根据每个候选文件信息的活跃程度值，对第二数据量的候选文件信息进行排序处理，其中，活跃程度值用于描述相应候选文件信息被检测出的概率情况，从而使得文件规则引擎库的参考价值，使得基于文件规则引擎库的文件信息检测准确率更优。
83.图3是根据本公开第三实施例的示意图。
84.如图3所示，该文件规则引擎库的生成方法，包括：
85.s301：获取差量文件信息，和与每个差量文件信息对应的差量特征。
86.其中，当检测处于在线状态时，可以从云端获取近期活跃程度较高的文件信息作为差量文件信息，该差量文件信息可以被用于对文件规则引擎库进行规则更新，而对差量文件信息进行特征解析所得文件特征，可以被称为差量特征，对此不做限制。
87.s302：为每个差量特征配置文件检测规则。
88.上述在获取与每个差量文件信息对应的差量特征，还可以为每个差量特征配置文件检测规则。
89.s303：根据差量文件信息、差量特征，以及文件检测规则对文件规则引擎库进行更新。
90.而后可以根据差量文件信息、差量特征，以及文件检测规则对文件规则引擎库进行更新，比如将差量文件信息、差量特征，以及文件检测规则添加至文件规则引擎库的待编
译程序代码文件中，重新将更新所得待编译程序代码文件随编译自动打包至扫描类应用程序的sdk中，以实现差量化更新。
91.举例而言，当处于在线状态(比如电子设备连网)时，可以自动化地对本地的文件规则引擎库中的内容进行自动更新，比如可以由客户端携带本地的文件规则引擎库中的文件信息内容(病毒库大小、时间跨度、上次差量化更新标记)，而后，由云端依照以上参数，按照最近候选文件信息的活跃程度值返回差量的文件信息内容，客户端基于差量的文件信息内容对文件规则引擎库进行更新，使得离线文件信息扫描成功率可维持高可用性和高识别率，从而实现使得本地的文件规则引擎库不断更新，更加有效识别病毒的目的。
92.图4是根据本公开第四实施例的示意图。
93.如图4所示，该文件信息检测方法，包括：
94.s401：获取应用程序的应用特征。
95.s402：确定如上述文件规则引擎库的生成方法生成的文件规则引擎库中是否存在与应用特征对应的参考特征，得到确定结果。
96.s403：根据确定结果检测目标文件信息。
97.如图5所示，图5是本公开实施例中的文件信息检测装置的架构示意图，该文件信息检测装置包括：获取应用特征的部分、本地文件规则引擎库的识别部分、以及本地的离线ai模型的检测识别部分，该本地的离线ai模型可以例如为上述的文件检测模型。
98.其中，应用程序的应用特征，例如为应用程序的签名的散列值、包名、apk包的散列值，该散列值可以基于信息摘要算法(message-digest algorithm，md5)确定，而后将应用特征提供至本地文件规则引擎库的识别部分，以进行文件信息的检测识别，如果确定结果是文件规则引擎库中存在与应用特征对应的参考特征，则基于参考特征检测目标文件信息，如果确定结果是文件规则引擎库中不存在与应用特征对应的参考特征，则将应用特征输入至文件检测模型中，以得到文件检测模型输出的目标文件信息，以提升文件信息检测的成功率。
99.其中，图5中的manifest特征是指androidmanifest.xml文件中所携带的特征，每个安卓应用程序通常会有一个androidmanifest.xml文件，在app/manifests目录中。
100.本公开实施例中还可以支持根据密钥位置信息，获取密钥信息，并根据密钥信息，在本地服务层对文件规则引擎库进行解密处理，从而有效避免文件规则引擎库被篡改，提升文件规则引擎库的保密安全性。
101.如图6所示，图6是本公开实施例中的文件规则引擎库的线上更新示意图，如图7所示，图7是本公开实施例中的文件检测模型的线上更新示意图。
102.本公开实施例提供的文件规则引擎库的生成方法以及文件信息检测方法，可以在离线场景下，有效识别出目标文件信息(当该目标文件信息为计算机病毒的文件信息时，该目标文件信息，可以例如为恶意扣费、远程控制、系统破坏、资费消耗、木马等各类计算机病毒的文件信息)，能够较大程度提升离线扫描文件信息的检出率，并依托插件化技术和插件加固技术提升了安全性和对抗能力，通过按照文件信息的活跃程度差量化地更新本地的文件规则引擎库，使得离线扫描能力可不断更新增强。支持智能设备处于离线状态与在线状态下的闭环的文件信息检测识别能力。
103.图8是根据本公开第五实施例的示意图。
104.如图8所示，该文件规则引擎库的第一生成装置80，包括：
105.第一确定模块801，用于确定适于应用程序的检测规则的第一数据量。
106.第一获取模块802，用于获取第一数据量的候选文件信息，和与每个候选文件信息对应的候选特征。
107.配置模块803，用于为每个候选特征配置文件检测规则。
108.第一生成模块804，用于根据第一数据量的候选文件信息、候选特征，以及文件检测规则生成文件规则引擎库。
109.在本公开的一些实施例中，如图9所示，图9是根据本公开第六实施例的示意图，该文件规则引擎库的第二生成装置90，还包括：第一确定模块901、第一获取模块902、配置模块903、第一生成模块904，该第二生成装置90还包括：
110.第二生成模块905，用于根据文件规则引擎库，生成待编译程序代码文件；
111.第一处理模块906，用于将待编译程序代码文件添加至初始程序代码文件中，以得到目标程序代码文件，其中，被编译的初始程序代码文件用于基于文件检测模型进行文件信息检测；以及
112.第二处理模块907，用于对目标程序代码文件进行编译处理，其中，被编译的目标程序代码文件用于基于文件检测模型和/或文件规则引擎库进行文件信息检测。
113.在本公开的一些实施例中，其中，第一确定模块901，具体用于：
114.确定应用程序的程序性能信息；
115.确定对应用程序进行文件信息检测的频率；
116.根据程序性能信息和检测的频率，确定第一数据量。
117.在本公开的一些实施例中，其中，第一获取模块902，具体用于：
118.获取第二数据量的候选文件信息，其中，第二数据量大于第一数据量；
119.对第二数据量的候选文件信息进行排序处理；
120.从排序处理后第二数据量的候选文件信息中选择排序在前的第一数据量的候选文件信息。
121.在本公开的一些实施例中，其中，第一获取模块902，还用于：
122.根据每个候选文件信息的活跃程度值，对第二数据量的候选文件信息进行排序处理，其中，活跃程度值用于描述相应候选文件信息被检测出的概率情况。
123.在本公开的一些实施例中，其中，第一获取模块902，还用于获取差量文件信息，和与每个差量文件信息对应的差量特征；
124.配置模块903，还用于为每个差量特征配置文件检测规则；
125.第一生成模块904，还用于根据差量文件信息、差量特征，以及文件检测规则对文件规则引擎库进行更新。
126.在本公开的一些实施例中，还包括：
127.第三处理模块908，用于对文件规则引擎库进行加密处理，得到文件规则引擎库的加密信息；
128.第三生成模块909，用于生成与加密信息对应的密钥位置信息，其中，密钥位置信息用于描述密钥信息的存储位置。
129.在本公开的一些实施例中，其中，第三处理模块908，具体用于：
130.在本地服务层对文件规则引擎库进行加密处理。
131.可以理解的是，本实施例附图9中的文件规则引擎库的第二生成装置90与上述实施例中的文件规则引擎库的第一生成装置80，第一确定模块901与上述实施例中的第一确定模块801，第一获取模块902与上述实施例中的第一获取模块802，配置模块903与上述实施例中的配置模块803，第一生成模块904与上述实施例中的第一生成模块804，可以具有相同的功能和结构。
132.需要说明的是，前述对文件规则引擎库的生成方法的解释说明也适用于本实施例文件规则引擎库的生成装置。
133.本实施例中，通过确定适于应用程序的检测规则的第一数据量，并获取第一数据量的候选文件信息，和与每个候选文件信息对应的候选特征，为每个候选特征配置文件检测规则，以及根据第一数据量的候选文件信息、候选特征，以及文件检测规则生成文件规则引擎库，所得文件规则引擎库能够支持检测文件信息，由于不依赖于ai模型来检测文件信息，从而能够避免使用ai模型进行文件信息检测的局限性，有效提升文件信息检测成功的概率，提升文件信息检测效果。
134.图10是根据本公开第七实施例的示意图。
135.如图10所示，该第一文件信息检测装置100，包括：
136.第二获取模块1001，用于获取应用程序的应用特征。
137.第二确定模块1002，用于确定如上述文件规则引擎库的生成装置生成的文件规则引擎库中是否存在与应用特征对应的参考特征，得到确定结果。
138.检测模块1003，用于根据确定结果检测目标文件信息。
139.在本公开的一些实施例中，如图11所示，图11是根据本公开第七实施例的示意图，该第二文件信息检测装置110，还包括：第二获取模块1101、第二确定模块1102，以及检测模块1103，其中，检测模块1103，具体用于：
140.如果确定结果是存在与应用特征对应的参考特征，则基于参考特征检测目标文件信息；
141.如果确定结果是不存在与应用特征对应的参考特征，则将应用特征输入至文件检测模型中，以得到文件检测模型输出的目标文件信息。
142.在本公开的一些实施例中，该第二文件信息检测装置110还包括：
143.第三获取模块1104，用于根据密钥位置信息，获取密钥信息。
144.第四处理模块1105，用于根据密钥信息，在本地服务层对文件规则引擎库进行解密处理。
145.可以理解的是，本实施例附图9中的第二文件信息检测装置110与上述实施例中的第一文件信息检测装置100，第二获取模块1101与上述实施例中的第二获取模块1001，第二确定模块1102与上述实施例中的第二确定模块1002，检测模块1103与上述实施例中的检测模块1003，可以具有相同的功能和结构。
146.需要说明的是，前述对文件信息检测方法的解释说明也适用于本实施例文件信息检测装置。
147.本公开实施例提供的文件规则引擎库的生成装置以及文件信息检测装置，可以在离线场景下，有效识别出目标文件信息(当该目标文件信息为计算机病毒的文件信息时，该
目标文件信息，可以例如为恶意扣费、远程控制、系统破坏、资费消耗、木马等各类计算机病毒的文件信息)，能够较大程度提升离线扫描文件信息的检出率，并依托插件化技术和插件加固技术提升了安全性和对抗能力，通过按照文件信息的活跃程度差量化地更新本地的文件规则引擎库，使得离线扫描能力可不断更新增强。支持智能设备处于离线状态与在线状态下的闭环的文件信息检测识别能力。
148.根据本公开的实施例，本公开还提供了一种电子设备、一种可读存储介质和一种计算机程序产品。
149.图12示出了可以用来实施本公开的方法的示例电子设备的示意性框图。电子设备旨在表示各种形式的数字计算机，诸如，膝上型计算机、台式计算机、工作台、个人数字助理、服务器、刀片式服务器、大型计算机、和其它适合的计算机。电子设备还可以表示各种形式的移动装置，诸如，个人数字处理、蜂窝电话、智能电话、可穿戴设备和其它类似的计算装置。本文所示的部件、它们的连接和关系、以及它们的功能仅仅作为示例，并且不意在限制本文中描述的和/或者要求的本公开的实现。
150.如图12所示，设备1200包括计算单元1201，其可以根据存储在只读存储器(rom)1202中的计算机程序或者从存储单元1208加载到随机访问存储器(ram)1203中的计算机程序，来执行各种适当的动作和处理。在ram 1203中，还可存储设备1200操作所需的各种程序和数据。计算单元1201、rom 1202以及ram 1203通过总线1204彼此相连。输入/输出(i/o)接口1205也连接至总线1204。
151.设备1200中的多个部件连接至i/o接口1205，包括：输入单元1206，例如键盘、鼠标等；输出单元1207，例如各种类型的显示器、扬声器等；存储单元1208，例如磁盘、光盘等；以及通信单元1209，例如网卡、调制解调器、无线通信收发机等。通信单元1209允许设备1200通过诸如因特网的计算机网络和/或各种电信网络与其他设备交换信息/数据。
152.计算单元1201可以是各种具有处理和计算能力的通用和/或专用处理组件。计算单元1201的一些示例包括但不限于中央处理单元(cpu)、图形处理单元(gpu)、各种专用的人工智能(ai)计算芯片、各种运行机器学习模型算法的计算单元、数字信号处理器(dsp)、以及任何适当的处理器、控制器、微控制器等。计算单元1201执行上文所描述的各个方法和处理，例如执行文件规则引擎库的生成和文件信息检测方法。
153.例如，在一些实施例中，执行文件规则引擎库的生成和文件信息检测方法可被实现为计算机软件程序，其被有形地包含于机器可读介质，例如存储单元1208。在一些实施例中，计算机程序的部分或者全部可以经由rom 1202和/或通信单元1209而被载入和/或安装到设备1200上。当计算机程序加载到ram 1203并由计算单元1201执行时，可以执行上文描述的执行文件规则引擎库的生成和文件信息检测方法的一个或多个步骤。备选地，在其他实施例中，计算单元1201可以通过其他任何适当的方式(例如，借助于固件)而被配置为执行文件规则引擎库的生成和文件信息检测方法。
154.本文中以上描述的系统和技术的各种实施方式可以在数字电子电路系统、集成电路系统、场可编程门阵列(fpga)、专用集成电路(asic)、专用标准产品(assp)、芯片上系统的系统(soc)、负载可编程逻辑设备(cpld)、计算机硬件、固件、软件、和/或它们的组合中实现。这些各种实施方式可以包括：实施在一个或者多个计算机程序中，该一个或者多个计算机程序可在包括至少一个可编程处理器的可编程系统上执行和/或解释，该可编程处理器
可以是专用或者通用可编程处理器，可以从存储系统、至少一个输入装置、和至少一个输出装置接收数据和指令，并且将数据和指令传输至该存储系统、该至少一个输入装置、和该至少一个输出装置。
155.用于实施本公开的方法的程序代码可以采用一个或多个编程语言的任何组合来编写。这些程序代码可以提供给通用计算机、专用计算机或其他可编程数据处理装置的处理器或控制器，使得程序代码当由处理器或控制器执行时使流程图和/或框图中所规定的功能/操作被实施。程序代码可以完全在机器上执行、部分地在机器上执行，作为独立软件包部分地在机器上执行且部分地在远程机器上执行或完全在远程机器或服务器上执行。
156.在本公开的上下文中，机器可读介质可以是有形的介质，其可以包含或存储以供指令执行系统、装置或设备使用或与指令执行系统、装置或设备结合地使用的程序。机器可读介质可以是机器可读信号介质或机器可读储存介质。机器可读介质可以包括但不限于电子的、磁性的、光学的、电磁的、红外的、或半导体系统、装置或设备，或者上述内容的任何合适组合。机器可读存储介质的更具体示例会包括基于一个或多个线的电气连接、便携式计算机盘、硬盘、随机存取存储器(ram)、只读存储器(rom)、可擦除可编程只读存储器(eprom或快闪存储器)、光纤、便捷式紧凑盘只读存储器(cd-rom)、光学储存设备、磁储存设备、或上述内容的任何合适组合。
157.为了提供与用户的交互，可以在计算机上实施此处描述的系统和技术，该计算机具有：用于向用户显示信息的显示装置(例如，crt(阴极射线管)或者lcd(液晶显示器)监视器)；以及键盘和指向装置(例如，鼠标或者轨迹球)，用户可以通过该键盘和该指向装置来将输入提供给计算机。其它种类的装置还可以用于提供与用户的交互；例如，提供给用户的反馈可以是任何形式的传感反馈(例如，视觉反馈、听觉反馈、或者触觉反馈)；并且可以用任何形式(包括声输入、语音输入或者、触觉输入)来接收来自用户的输入。
158.可以将此处描述的系统和技术实施在包括后台部件的计算系统(例如，作为数据服务器)、或者包括中间件部件的计算系统(例如，应用服务器)、或者包括前端部件的计算系统(例如，具有图形用户界面或者网络浏览器的用户计算机，用户可以通过该图形用户界面或者该网络浏览器来与此处描述的系统和技术的实施方式交互)、或者包括这种后台部件、中间件部件、或者前端部件的任何组合的计算系统中。可以通过任何形式或者介质的数字数据通信(例如，通信网络)来将系统的部件相互连接。通信网络的示例包括：局域网(lan)、广域网(wan)、互联网及区块链网络。
159.计算机系统可以包括客户端和服务器。客户端和服务器一般远离彼此并且通常通过通信网络进行交互。通过在相应的计算机上运行并且彼此具有客户端-服务器关系的计算机程序来产生客户端和服务器的关系。服务器可以是云服务器，又称为云计算服务器或云主机，是云计算服务体系中的一项主机产品，以解决了传统物理主机与vps服务("virtual private server"，或简称"vps")中，存在的管理难度大，业务扩展性弱的缺陷。服务器也可以为分布式系统的服务器，或者是结合了区块链的服务器。
160.应该理解，可以使用上面所示的各种形式的流程，重新排序、增加或删除步骤。例如，本发公开中记载的各步骤可以并行地执行也可以顺序地执行也可以不同的次序执行，只要能够实现本公开公开的技术方案所期望的结果，本文在此不进行限制。
161.上述具体实施方式，并不构成对本公开保护范围的限制。本领域技术人员应该明
白的是，根据设计要求和其他因素，可以进行各种修改、组合、子组合和替代。任何在本公开的精神和原则之内所作的修改、等同替换和改进等，均应包含在本公开保护范围之内。