ABSTRACT

In recent years, the security issues of Android third-party libraries have appeared in endlessly. In order to study the potential security threats of third-party game libraries, in this paper, 21 mainstream third-party game SDKs are analyzed in depth and three process models are established to reveal the implementation details of the game SDKs. Then it proposes seven security rules and explains five kinds of attack scenarios which game SDK providers, game developers, and users may encounter after the violation of these security guidelines. Lastly, this paper proposes three methods for detecting violations of security guidelines, and uses these three methods to detect the 21 game SDKs and 2000 game applications in Android application markets. The experimental results show that the 21 game SDKs all violated at least one security rule, resulting in hundreds of gaming applications facing security risks.

Keywords:Third-Party Game Libraries, Security Rules, Process Models, Attack Scenarios

游戏库的安全性分析与验证

李若影，邵帅，崔浩亮，牛少彰

北京邮电大学计算机学院，北京

收稿日期：2018年8月5日；录用日期：2018年8月20日；发布日期：2018年8月28日

摘 要

近年来，Android第三方库的安全问题层出不穷。为了研究第三方游戏库潜在的安全威胁，该文深入分析了21个主流的第三方游戏SDK，并建立了三种过程模型以揭示游戏SDK的实现细节，然后提出了7条安全准则，并说明了违反这些安全准则后游戏SDK提供方、游戏开发方、用户可能遭遇的5种攻击场景。最后，该文提出了检测违反安全准则的三种方法，并利用这三种方法对这21种游戏SDK及Android应用市场中的2000个游戏应用程序进行了检测，实验结果表明，这21个游戏SDK均违反至少一条安全规则，导致上百个游戏应用程序面临安全风险。

关键词 :第三方游戏库，安全准则，过程模型，攻击场景

Copyright © 2018 by authors and Hans Publishers Inc.

This work is licensed under the Creative Commons Attribution International License (CC BY).

http://creativecommons.org/licenses/by/4.0/

1. 引言

近几年，移动应用程序市场迅速发展。大量Android应用程序使用第三方库，第三方库通过提供已经实现的具体功能，使得应用程序的开发更加便利。有研究表明，许多应用程序使用超过20个第三方库 [1] ，在某些极端情况下，一个应用程序可以引入超过30种不同的第三方库 [2] 。在现存的Android第三方SDK中，游戏类SDK尤为突出，被应用程序开发者广泛使用。iiMedia Research显示，2016年中国手游用户规模达5.23亿人，市场规模达783.2亿元 [3] 。据统计，每个Android游戏APP平均使用SDK的数量达17.5个0。由此可见，游戏类SDK的使用数量不断上升，在Android第三方SDK中占据重要地位。

然而，尽管第三方SDK在开发中被普遍使用，它们却往往存在潜在安全问题，例如，它们泄露用户私人信息，利用其宿主应用程序的权限或跟踪用户。文献 [4] 指出中国最大的移动广告提供商Taomike所提供的广告SDK被发现存在秘密监视用户的行为；文献 [5] 指出Google Cloud Messaging提供的推送消息服务SDK允许攻击者劫持用户的注册id并获取用户隐私信息；文献 [6] 指出主流应用程序内支付服务提供商提供的支付SDK规定商家使用URL存储支付命令，这使攻击者很容易获取并篡改支付命令，给用户和商家造成极大经济损失。由此可见，大量第三方SDK存在严重安全问题，亟待研究与解决。

本文旨在回答以下问题：1) 什么原因导致了游戏SDK存在安全漏洞？2) 攻击者可能对游戏SDK执行什么类型的攻击？3) 怎样检测游戏SDK中存在的安全漏洞？为了解决这些问题，本文对游戏SDK进行了深层次分析，包括以下几个方面：1) 通过逆向工程第三方游戏SDK和相关应用程序，分析游戏SDK的主要功能及其实现流程，并建立过程模型。2) 总结出一系列规范游戏SDK的安全规则。3) 举例说明违反这些安全规则后可能遭受的攻击。4) 使用自动化和手动方法结合来检测在游戏SDK，游戏SDK服务器，游戏应用程序及游戏应用程序服务器上违反安全规则的行为。

2. 相关工作

针对Android第三方库的分析研究主要包括同源性分析和漏洞分析。在同源性分析方面，Michael Backes等人 [7] 提出一种可以精确检测Android应用程序中使用的第三库的技术，它利用原始的第三方库生成特征文件，然后对文件进行特征匹配，此方法可以应对代码混淆技术，不仅可以检测应用程序中使用的不同库，还可以检测出所使用的库版本。Charlie Soh等人 [8] 提出一种自动检测第三方库的工具LibSift，这种检测工具基于应用程序的包依赖图，并采用了模块去耦技术提高识别精度。Ziang Ma等人 [1] 首先利用聚类技术收集了大量第三库特征，然后开发了一种叫做LibRadar的工具，结合静态分析和特征匹配技术识别应用程序中的第三方库。

基于大量对第三方库同源分析技术的研究，不少研究者分析了Android应用程序中各类第三方库存在的安全问题，并提出了相应的检测方法。Yangyi Chen等人 [5] 提出了一种工具用于检测推送消息类SDK的漏洞，它旨在从SDK的示例代码及应用程序的Manifest文件中提取指纹，接口等信息，并利用这些信息分析SDK提供的身份认证方式及客户端id的保护方式，它可以检测客户端混淆，服务混淆等漏洞。Wenbo Yang等人 [6] 分析了第三方支付类SDK可能遭受的攻击，例如秘钥泄露，支付命令被替换等，文章针对每种类型的攻击提出了具体的检测方法。Soteris Demetriou等人 [9] 分析了广告库获取用户隐私的四种方式并提出一个移动风险评估框架来检测应用程序是否将个人敏感数据泄漏给广告库。Hui Wang等人 [10] 揭示了由于Android应用程序中利用第三方SDK实现OAuth协议而产生的漏洞，并提出一个漏洞评估框架，此框架可以为Android应用程序中OAuth的实现流程建立五方三阶段模型，从而检测两种类型的漏洞。

上述方法实现了对特定类型的第三方SDK的漏洞检测技术，但都不能针对游戏SDK的特点进行安全检测，目前也没有研究者对游戏SDK进行系统性的安全分析。

3. 过程分析

游戏SDK通常包含两种功能，一是用户体系功能，例如注册、登陆等；二是支付功能，通常提供多种支付渠道以实现游戏APP中充值服务。虽然游戏SDK功能相似，但应用程序如何通过第三方游戏SDK完成服务的过程却不完全一致。第一，游戏SDK没有统一的规范；其次，游戏SDK开发者经常向应用程序开发者提供简单的文档和代码示例，然而这些资料的大部分是模糊的，可能会误导应用程序开发人员。

为了揭示游戏SDK服务过程的细节，本文选择了当下流行的游戏SDK，对它们的示例代码及开发文档进行研究分析，并SDK及相关应用程序的源码进行分析。然后，本文总结了游戏SDK登陆、支付和找回密码流程，包含基本步骤及传递的参数。

3.1. 登录模型

图1所示为一个简单的登陆过程模型，整个过程通常包含以下8步：

1) 游戏客户端初始化第三方游戏SDK，调用SDK登陆接口。

2) SDK客户端向SDK服务器发送登起请求，将用户信息userinfo (例如账号，密码等)及APP信息appinfo (例如客户端唯一标识APPID)加密并传递给SDK服务器。

3) SDK服务器将接收到的userinfo与数据库信息对比，并生成登陆状态码code，登陆令牌token和签名sign，然后响应SDK客户端登陆请求。

4) SDK客户端处理接口的回调结果，将获取的信息传递给APP客户端，token中保存了用户身份信息。

5) APP客户端将获取的token和sign作为用户登陆标识向APP服务器发送登陆请求。

6) APP服务器将登录信息发送到SDK服务器，请求SDK服务器验证此次是否为有效的用户会话。

7) SDK服务器找到对应的会话，验证登陆是否超市，同时校验签名的正确性，然后返回校验结果(包括登陆状态码，信息描述等)。

8) APP服务器接收校验结果后，通知APP客户端登陆结果，APP客户端执行登陆操作并将用户登陆态信息存储到本地数据库中。

3.2. 支付模型

图2所示为一个简单的支付过程模型，整个过程通常包含以下10步：

图1. 登陆过程模型

图2. 支付过程模型

1) APP客户端调用游戏SDK的支付接口，并将商品信息commodityinfo (例如商品数量等)通过接口传递给SDK客户端。

2) SDK客户端向APP服务器发送商品信息和签名以请求充值服务。

3) APP服务器生成加签订单，并将订单信息orderinfo (例如订单ID等)和签名返回给SDK客户端。订单信息和签名将保存在APP服务器的数据库中。

4) SDK客户端根据orderinfo中的支付渠道调用对应的支付SDK，将支付信息发送给SDK服务器，SDK服务器设置订单状态为未完成。

5) 支付SDK客户端根据orderinfo中的信息向支付服务器发送支付请求，支付服务器回调支付SDK方法，弹出支付界面并获取用户输入的支付账户信息userinfo。

6) 支付服务器对订单进行处理，将充值结果信息pay_result (包含订单号支付金额，支付失败原因等)和sign发送给SDK服务器。

7) SDK服务器更新订单状态并存储充值信息，然后通知APP服务器充值结果。

8) SDK服务器使用回调接口通知SDK客户端充值结果，APP客户端提示用户支付结果。但此时，用户购买商品并未同步。

9) APP服务器校验签名和订单信息，将校验结果返回给SDK服务器。

10) 若第9步支付结果校验正确，APP服务器根据订单信息将用户购买的商品发放给APP客户端，并将用户购买商品信息添加到数据库中。

3.3. 找回密码模型

图3所示为一个简单的重置密码过程模型，整个过程通常包含以下9步：

1) APP客户端调用SDK密码重置接口，用户在密码重置界面输入手机号码，并通过接口参数传入SDK客户端进行处理。

2) SDK客户端向SDK服务器发送userid，手机号，令牌token，请求SDK服务器发送验证码。

3) SDK服务器生成验证码，请求短信服务商发送短信。

4) SDK服务器通知APP客户端验证码发送成功。

5) 用户在APP客户端界面输入接收到的验证码，通过对应接口传递给SDK客户端。

6) SDK客户端发送userid，手机号，用户输入的验证码到SDK服务器，请求校验正确性。

7) SDK服务器校验验证码是否正确并检查token是否在有效期，然后返回给SDK客户端校验结果，允许或拒绝用户修改密码。

8) 用户在APP客户端输入新密码，并由SDK客户端发送给SDK服务器，SDK服务器，SDK服务器将新密码存储到数据库中。

9) SDK服务器返回给SDK客户端密码重置结果，SDK客户端通知用户密码重置结果。

4. 安全分析

4.1. 安全准则

大部分游戏SDK在发布之前已经通过审核并且被认为是安全的，但由于整个游戏服务过程涉及多方交互，任何一方在多方模式中犯下的任何错误都可能导致整个过程的脆弱性。因此，有必要制定安全规则，对模型中的各方进行规范。

根据上面三种过程模型，本文总结了以下准则，要求游戏开发方和游戏SDK提供方必须遵守。

1) 永远不要把任何秘密信息存放在客户端APP中，本地重要信息应加密存储。

图3. 找回密码过程模型

2) 校验短信验证码的过程必须在SDK服务器端完成。

3) 客户端和服务器之间必须使用安全的网络通信。

4) userid生成方式应是无规律的。

5) 支付相关的信息必须签名。

6) SDK必须将付款订单的详细信息通知用户。

7) 通信过程中必须验证接收到的信息的签名。

下面本文将详细描述违反安全规则后会遭遇的5种攻击。

4.2. 篡改命令

如果违反了第1条，第5条或第7条中任意一条安全规则，可能会遭受命令被篡改的攻击。在这种情况下，攻击者可以篡改支付订单中的内容，例如篡改支付金额，使得攻击者可以支付较少的费用而获取到商品。

在支付模型中，SDK客户端将用户购买的商品信息发送给APP服务器，APP服务器生成订单号返回给APP。在这个过程中，SDK客户端发送的商品信息和APP服务器返回的订单信息都应加签，并且在传递过程中，任何一方都应该验证接收到的签名。订单信息是由APP服务器生成并签名，攻击者无法篡改获取的信息。但是，如果订单签名的秘钥在APP客户端中，攻击者就可以截获商品或订单信息并篡改，利用获取的秘钥和篡改后的信息生成签名，重新发送给接收端，此时因为签名是合法的，接收端将把篡改后的信息当作正常信息处理。

4.3. 伪造通知

在找回密码过程模型中，SDK服务器负责校验验证码，若校验成功，SDK服务器通知APP客户端允许用户修改密码。但是，如果违反了第2条安全规则，即校验验证码的工作由APP客户端完成，攻击者可以修改本地代码逻辑，无论是否收取到验证码，无论修改密码操作是否由获得允许，攻击者都可以使APP客户端获取校验成功的通知。在这种情况下，攻击者只要任意输入电话号码，便可以在没有验证码的情况下修改此账户的密码，对用户造成危害。

在支付过程模型中，如果同时违反了第1和第7条安全规则，也可能会遭到伪造通知的攻击。在完成支付后，支付SDK服务器会将支付结果通知发送给APP服务器。在这项攻击中，攻击者不会完成支付，而是伪造一个假的支付结果通知发送给APP服务器，使得APP服务器认为订单已经支付成功。若想完成这个攻击过程，攻击者需要知道支付SDK服务器通知APP服务器时的URL。开发人员经常会将此URL随意放入APP的本地信息中，这违背了第1条安全规则。同时，如果APP服务器忽略校验通知的签名，这个通知就会被当作正常信息处理。

4.4. 替换命令

这种攻击是由于违反了第3条或第6条中任意一条安全规则，攻击者通过替换多方之间传输的数据，使用户遭受危害。

当APP服务器和APP客户端之间使用不安全的网络通信时，攻击者可以执行中间人攻击，截取它们之间传递的信息。在支付过程模型中，攻击者可以用一个伪造的合法订单替换APP服务器生成的订单，接下来的过程中，用户将支付攻击者伪造的订单，因为这个订单的格式和信息都是合法的，因此SDK会正常接收并处理这个订单。支付订单被替换还有另一个重要原因，即SDK没有向用户展示支付订单的细节。在这种情况下，用户没有确认生成的订单就进行了支付。例如，SDK只向用户展示用户购买的商品时，攻击者可以伪造与原订单具有相同商品信息，金额却不同的订单，此时用户无法辨别订单的不同，攻击者便可以成功完成攻击。

在找回密码过程模型中，用户重置密码后，SDK客户端将用户名，userid和用户重置的新密码发送给SDK服务器，在这个过程中，攻击者可以监听网络并截取这个过程中的数据包，替换用户重置密码命令，使用户无法成功登陆。这类攻击的根本原因是缺乏安全的通信信道。我们发现多数游戏SDK客户端和服务器之间使用HTTP通信协议和简单的加密算法，很容易通过中间人攻击工具监听到传输内容。

4.5. 伪造客户端

每一个游戏APP用户的账号都有一个userid，它是唯一确定一个用户的标识，userid通常由服务器生成，服务器通过网络请求中的userid来区分来自不同用户的请求。

根据第4条安全规则，userid的生成方式应该是无规律的，否则攻击者很容易推断出被攻击者的userid，并以此作为攻击条件。例如一些游戏APP请求服务器信息时需要使用userid，若攻击者获取被攻击者的userid，就可以伪造用户请求并获取用户信息。

4.6. 非法登录

如果违反了第1条或第3条安全规则中任意一条，攻击者可能获取身份验证信息伪造登录请求。在登录过程模型中，SDK服务器会生成唯一的编码token并将token与用户信息一一对应存入数据库中，之后token会作为安全交互的重要信息，开发者经常会将token存放在本地APP数据库或私有文件中，便于直接读取，甚至有些SDK会将用户名和密码存在私有文件。如果这些信息没有加密存储，攻击者便很容易获取用户的登录信息。另一方面，如果在token和账号信息在传递过程中使用不安全网络通信也同样会造成隐私泄露。

5. 检测

由上述章节可知，违反七项安全规则可能会造成可利用的攻击。在本章中，将详细描述如何检测违反这些安全规则的行为，以便发现真实游戏应用程序中存在的漏洞。本文的检测方法主要分为三类，自动化静态检测、中间人检测和手动检测。自动化检测的主要检测对象是SDK源码和游戏APP源码，中间人检测主要的检测对象是各方之间的网络交互数据，而手动检测主要是检测SDK的显示界面、生成文件等或手动篡改SDK各方之间的网络通信数据。

5.1. 自动化静态检测

对于URL信息，我们在DEX文件和资源文件中搜索URL特征，然后自动化提取SDK中所有的URL，最后判断来确定这之中是否有涉及到服务器之间通信的URL泄露。

对于签名信息，我们可以通过开发文档得知SDK采用的签名方式，然后根据不同的签名方法来搜索关键函数内参数或静态变量是否有涉及秘钥泄露；另外，我们发现一些支付秘钥存在明显的特征，例如支付宝秘钥通常是以‘MI’开头且长度超过300的字符串。

根据安全规则3，如果SDK使用的是HTTPS通信，我们将检查它是否正确验证SSL证书。此漏洞分两种情况，第一，SDK自定义信任所有证书；第二，SDK没有对证书的主机名进行校验。这两种情况有明显的代码特征，可以通过代码特征匹配完成检测。

5.2. 中间人检测

根据安全规则2，校验短信验证码的过程应在服务器端完成。我们在中间人攻击工具Fiddler基础上实现自动获取短信验证码校验过程数据的功能，通过重建短信验证过程来检测此类漏洞。

根据安全规则3，游戏服务器，游戏客户端，SDK服务器之间应该采用安全的通信方式。我们利用MonkeyRunner录制登陆和充值的脚本，在执行脚本的同时利用Fiddler自动获取过程中的全部网络数据。MonkeyRunner是一种Android自动化测试工具，可以通过它提供的API来控制Android设备和模拟器运行，另外，可以运行monkeyrecoder.py脚本录制应用程序测试脚本，并通过monkeyplayback.py脚本来解释执行测试脚本。我们收集了一些网络传输中隐私数据参数常用名称，例如密码参数名常用password，pwd，accessPasswd，passwd等，我们检查在获取的网络数据中是否有这些隐私数据的关键字，如果SDK采用HTTP协议且在网络数据中出现账号、密码、订单号、手机号、邮箱、支付金额等参数名，我们认为它是不安全的。

根据安全规则4，userid应该是无规律的。为了检测这一漏洞，我们利用MonkeyRecorder记录注册框的坐标并随机生成账号和密码，然后利用MonkeyRunner在APP上自动注册大量用户，同时利用Fiddler自动获取注册过程中的userid的值，最后比较userid的信息熵并与随机数的信息熵，并调用Matplotlib工具绘制userid数据的散点图，以检测userid是否有规律。我们用同样的方法检测违反安全规则5的行为，主要检测网络传输数据中是否有例如sign，Signature，mhtSignature，sig，paySig等签名参数常用字段。若没有，则认为是有漏洞的。

5.3. 手动检测

根据安全规则1，一些重要信息应加密存储。一般情况下，开发者会将token存储在数据库或配置文件中，我们在root后的手机上检查APP的数据库和私有文件，查找token信息或用户账号和密码，从而确定这些信息是否加密存储。

为检测违反安全规则6的行为，我们手动检查游戏SDK是否在支付过程中向用户显示了支付订单的详细信息，重点检查以下字段：1) 支付订单ID。2) 用户支付的商品信息。3) 该支付订单所属的用户账号。4) 该支付账单所属的游戏APP信息。5) 用户所选用的支付渠道。6) 支付订单的总额。若游戏SDK的支付界面未向用户提供上述信息，则认为该游戏SDK的支付订单有被篡改的风险。

根据安全规则7，任何一方都应检测接收到的签名。为了检测这个漏洞，我们拦截所有的支付和登陆过程中的数据包，修改签名后再发送出去，如果接收方没有返回签名错误或者参数错误等信息，则证明它没有正确校验签名。

6. 实验评估

我们从Android应用市场中根据下载量从高到低下载了2000个游戏APP，超过50%的APP集成了表1中的游戏SDK，因此我们选取这些游戏SDK进行实验，检测它们是否存在第五章中提到的安全缺陷，研究对象包括这些游戏SDK的官方文档，SDK源码和集成这些游戏SDK的APP，实验结果表明这些游戏SDK都违反了至少一条安全规则。

表1. SDK名称及版本

6.1. 违反安全规则1

我们对500个集成这些SDK的游戏APP进行检测，发现近20%的APP存在秘钥泄露的情况，尤其在搜狗游戏APP和偶玩游戏APP中，我们检测到了支付秘钥泄露。例如，图4是在搜狗游戏龙腾传世APP中检测到的秘钥泄露，该秘钥用于生成游戏APP向APP服务器请求订单号时的签名；我们通过分析APP的源码得出利用此秘钥生成签名的方式，然后利用中间人攻击获取到签名所需的网络数据(表2)

图4. 搜狗游戏APP中泄露的秘钥

表2. 搜狗游戏APP的网络通信数据

并通过反编译APP获取Manifest数据(图5)，最后利用这些信息计算出了正确的签名(图6)。我们尝试用此方式为篡改的订单生成签名并发送给APP服务器，最终APP服务器正常处理并返回订单号。

在支付过程中，SDK客户端负责调起支付，而支付宝要求传入notify_url参数，这个参数为支付宝服务器主动通知游戏服务器支付结果的HTTP/HTTPS路径。因此，若游戏SDK集成了支付宝的支付方式，则这个游戏SDK开发的游戏APP中会包含此URL，从而造成URL泄露。我们检测了一些Android市场中包含支付宝支付方式的游戏APP，结果这些APP均含有URL泄露。图7是在搜狗游戏APP中检测出的URL泄露。

对于token和账号信息的检测，我们分析了这些集成这些游戏SDK的APP，检测沙箱目录和外存中APP生成的文件等，表3为有信息泄露的游戏APP。

6.2. 违反安全规则2

我们获取集成这些SDK的游戏APP的密码找回过程的网络数据。结果发现在当乐游戏APP存在客户端校验短信验证码的情况，当验证码输入正确时，APP会直接进入登录流程，而不会接收到验证码校验成功的通知。因此，我们认为这类游戏APP使用了错误的校验方式。

6.3. 违反安全规则3

我们发现这些游戏SDK均存在网络通信方面的漏洞，而且它们传输信息的主要方式是HTTP。例如，

图5. 搜狗游戏APP的Manifest数据

图6. 生成的签名

图7. APP中泄露的URL

表3. APP中的隐私信息泄露

搜狗游戏SDK利用简单的加密算法甚至是明文传递信息，攻击者可以获取到手机号，账号，密码；蜗牛游戏SDK使用简单的加密方式传递信息，解密后可以获取到账号，密码，而且在支付过程中，可以获取支付账号和支付密码等重要信息；4399游戏SDK在找回密码过程中，用户登录账号和登陆密码为明文传递。另外，这些SDK中均涉及到HTTPS通信，且都存在SSL通信客户端检测信任任意证书的漏洞，攻击者可以使用中间人攻击获取加密内容。图8是4399游戏SDK的网络传输数据，密码采用明文传递。

6.4. 违反安全规则4

我们对游戏SDK检测了userid相关的漏洞，结果发现，搜狗游戏SDK服务器、蜗牛SDK服务器、拇指玩游戏SDK服务器和综合游戏SDK服务器生成的userid是顺序的，攻击者很容易推测连续注册用户的userid。

6.5. 违反安全规则5

我们对这些游戏SDK执行了篡改订单的攻击。结果发现，蜗牛SDK发送给APP服务器商品信息不携带签名字段(表4)，订单信息可随意被篡改，例如我们选择充值100元，然后将订单中的amount字段由100修改为1，最终服务器返回的订单的支付金额为1元(图9)，攻击者可以用较少的金额获取商品；同样，偶玩游戏SDK在支付宝支付过程中没有出现任何签名信息，攻击者可以任意重改用户的订单信息。

6.6. 违反安全规则6

我们手动检查了这些游戏SDK支付Activity，发现大部分SDK没有向用户呈现完整的订单信息，容易发生订单被替换的危险。统计结果如表5所示。

图8. 4399游戏SDK的网络通信数据

6.7. 违反安全规则7

我们主要分析了这些游戏SDK在登陆和支付过程中，服务器是否每次都验证接收到的数据的签名。结果表明，在当乐游戏SDK的支付过程中，点击立即支付之后，我们修改SDK发送给SDK服务器的信

图9. APP向用户展示被篡改的订单

表4. 蜗牛游戏SDK的网络通信数据

表5. SDK的支付Activity信息

息中的签名，服务器收到携待错误签名的信息后没有报错，而是返回订单号；同样，37游戏SDK也存在这种情况。表明这些SDK的服务器并不是每次都正确地验证了签名。

7. 结束语

本文为了展现游戏SDK的实现细节并揭示潜在的安全风险，对Android游戏SDK进行了全面分析，并总结了七条安全规则，然后揭示了违反安全规则后的严重后果并提出了检测方法，最后对21个游戏SDK及上千个Android应用市场中的游戏APP进行了实验。实验结果表明，虽然这些安全规则被开发人员熟知，但多数游戏SDK仍然没有遵守规则，导致上百个游戏应用程序易遭受攻击。我们希望我们的研究能够提醒并指导游戏应用程序开发人员和游戏SDK开发人员开发更安全的游戏APP。

基金项目

国家自然科学基金项目(U1536121, 61370195)。

文章引用

李若影,邵 帅,崔浩亮,牛少彰. 游戏库的安全性分析与验证
Security Analysis and Verification of the Game Library[J]. 计算机科学与应用, 2018, 08(08): 1277-1291. https://doi.org/10.12677/CSA.2018.88138

参考文献