本文转载自微信公众号“卤蛋实验室”，作者：Halocarbon。转载本文请联系卤蛋实验室公众号。前段时间，我们公司的一位老总从一些渠道了解到一些小道消息，一个国民级APP被拒三个月，原因是苹果AppStore审核人员检测到ReactNative热更新的内容。我们的热更新平台类似于意外APP，所以也有被拒的风险。那我们就得想办法把热更新包隐藏起来，不被审稿人发现。事实上，这个问题相当复杂，因为它不仅仅是一个简单的技术问题，还涉及到各种复杂的商业利益。在许多限制条件下，您很难找到最优解。而且，这个问题也比较敏感。只能简单说说我的思路，具体的代码实现本文就不展开了。郑重声明：如有人按照本文思路隐藏热更新数据，导致应用被拒或下架，本人概不负责。参与签名，不能使用具有JIT功能的虚拟机……对于热更新技术，苹果曾在2017年封杀JSPatch[1]热更新框架，导致很多APP被拒。据苹果官方称，主要有以下三个原因：热更新码未加密验证，可能被第三方劫持。JSPatch权限过高，可能调用私有API改变APP原有功能。对于苹果官方来说，JSPatch太自由了，会绕过AppStore这个iOS上唯一的流量分发平台去更新App，这会影响商业利益，我在网上受不了，而且很多App都不是微信。有庞大的用户群可以和苹果官方协商（协商了微信小程序生态，但是小程序支付权限没有协商），所以这个问题还是很复杂的。的。其实对于苹果官方来说，对于动态热更新的态度一直都是不赞成也不反对的。与JSPatch相比，ReactNative和游戏热更新这两个应用场景仍然是允许的，主要体现在三点：网络游戏等运算量大的场景仍然需要热更新来维持活动的热度。每周都有新的活动。用户主动去AppStore下载更新包是不合理的。对于AppActivity的运行，ReactNative/Lua等热更新技术也是如此。它在容器中是动态的，不像JSPatch有这么大的修改权限。苹果正式在商业利益上与游戏厂商/互联网巨头取得了一些微妙的平衡。和太极一样，给出的规范解释各不相同，但为了保险起见，还是需要研究一下相关的平台规范。2.规范解读2015年，Apple发布了一个协议——?[2]，文章3.3.2节有一段关于热更新的内容：Exceptasstatedatnextparagraph,anApplication可能无法下载或安装可执行代码。如果所有脚本、代码和解释器都打包在应用程序中而不是下载，则解释代码只能在应用程序中使用。即将到来的唯一例外是由Apple的内置WebKit框架或JavascriptCore下载和运行的脚本和代码，前提是此类脚本和代码不会通过提供与预期和不一致的特性或功能来改变应用程序的主要目的提交给AppStore的应用程序的广告目的。这段话大概意思是除了Webkit和JavascriptCore可以动态执行下发的脚本和文件，其他所有的脚本/代码/解释器都必须封装在APP内部。这句话其实给ReactNative留了一个坑：ReactNative使用JavascriptCore来执行JS脚本文件，所以动态传递也在情理之中。解释代码可以下载到应用程序，但前提是此类代码：(a)不会通过提供与提交给应用程序的应用程序的预期和宣传目的不一致的特性或功能来改变应用程序的主要目的Store，(b)不会为其他代码或应用程序创建商店或店面，并且(c)不会绕过操作系统的签名、沙盒或其他安全功能。这段话大概是说我允许你更新热点，但是你必须遵守我的三个规则：你不能对APP功能进行重大改动，导致应用实际功能与APPStore的推广不一致（这个地方很太极，评判标准完全看审稿人心情）不能动态创建应用商店（应该不是BypassingIAPpayment的意思，不然怎么收苹果税）不能绕过signature/sandbox/OS的securityfunction（这个可以理解，维护系统和生态安全）这样看来，只要遵守规范，就可以做一个好公民问题就解决了。但说实话，动态规范更多的是君子之约。双方谈武，则大家乐此不疲；如果有人跳出来破坏规则，说实话，每个人都会尴尬。未来，热更新技术肯定会处于一种微妙的平衡之中。3.技术实现每次设计一些工程方案时，我个人的习惯是先从理论上寻找答案。以隐藏热更新包为例。我们主要是想在信息传递上找到突破口。事实上，香农先生在1949年就提出了一个“香农-韦弗通信模型[3]”。在这个模型中，通信分为信息源、发射机、信道、接收机、信息接收者和噪声五个部分。Shannon-Weaver通信模型那么结合这个通信模型，我们的隐藏/加密通信信息的答案就呼之欲出了：收到消息。加密通道：通道中的信息在传输过程中，经过通道时进行加密。那么下面我们就这两个大方向展开讨论。1.加密/混淆消息本身1.1隐写术——当代特洛伊木马隐写术是一项非常非常古老的技术。这项技术的关键是隐藏/伪装你要传输的数据，让任何第三方都看不到你真正要传输的数据。隐写术的例子有很多，比如特洛伊木马。你从外面看它是特洛伊木马，但是当它运到城里时，士兵跑出来了；在我们看的一些影视剧中，也有类似原理的段落：主人公收到一张无字的信纸，放在蜡烛上烤，就会出现字。今天的数字时代，绝对不会用无字信纸来暗中传递信息。我们必须有更多的网络方法，例如图形技术——将消息隐藏到图片文件中。如果你玩过一段时间的贴吧，肯定对图片播种技术不陌生。有的高手会发个帖子，把种子文件藏在图片里，大家下载图片，把.jpg的后缀改成.zip或者.rar，然后解压得到隐藏的种子文件，然后走人贴吧上“好房东”的口碑。那么图像技术的原理是什么？其实很简单。它只是简单地将一个jpg文件和一个rar文件合并在一起，但是图像查看器会忽略额外的rar文件数据，所以它是某种意义上的图片，但是从二进制的角度来看，这个图像文件中隐藏了一些数据。我们先来看看map文件的原理。首先，我使用图像编辑器生成2x24像素图像-RGBY.jpg。我参考谷歌的标志配置了颜色：RGBY-image然后我们用二进制查看工具（我这里用的是HexFiend软件）查看这张图片的编码，因为图片只有4个像素，所以二进制数据会比较小，注意观察这个文件的二进制数据，以FFD8开头，以FFD9结尾。当图片查看器加载图片文件时，它会检测到它。如果以FFD8开头，就会认为是jpg图片，然后进入jpg图片解码的分支。载入二进制数据后，遇到FFD9，会认为这张图片已经载入了，后面的数据就不管了。RGBY-Binary-Code是基于FFD9之后图片预览器不会加载数据的特点，我们可以在jpg文件中追加一些隐藏数据。为了测试方便，我新建一个text.txt文件，内容为helloword，然后使用cat命令合并RGBY.jpg和text.txt，生成RGBY_text.jpg文件：catRGBY.jpgtext.txt>RGBY_text.jpg用图片浏览器查看文件，可以看到文件还是可以正常预览的：RGBY_text-image但是如果用二进制查看工具查看这张图片，会发现它多了11个字节在end，也就是text.txt中的内容-helloword:RGBY_text-Binary-Code这样，我们就达到了隐写的目的。不要认为这个解决方案很低。其实阿里的一些key是通过类似的原理写成一张图片的（当然不像上面的案例那么简单）。我们在传输热更新bundle文件的时候，可以将bundle文件隐写在一张图片中，这样reviewer在做流量监控的时候，看到的就是抓包时的一张图片。如果不检查图片的二进制代码，是找不到里面隐藏的数据的。对于这个方案，服务端和客户端的改动都比较小。服务端只需要在每次发送bundle之前合并一个图片文件，客户端读取隐写图片后就可以去除多余的图片数据。当然，隐写术有很多种。例如，基于LSB的图像隐写技术将数据写入jpg、png、mp4的扩展数据域。因为原理大同小异，这里就不一一介绍了。感兴趣的同学可以自行搜索。学习。1.2对称加密对称加密也是一种历史悠久的加密技术，在信息技术的支持下也得到了迅速的发展。下面给大家介绍一个最简单的对称加密算法——异或算法加密。我想每个程序员都熟悉XOR操作。让我们首先同意0为假，1为真。那么异或运算的真值表如下：ABA⊕B000011101110从真值表可以很容易推导出如下算法：//加密：//原始密钥secret01010111^11110011=10100100//解密：//秘钥原10100100^11110011=01010111众所周知，位运算是非常快的，如果想简单的混淆bundle，直接使用异或加密，基本不会影响性能。虽然异或运算很简单，但密码学有一条第一条规则：永远不要自己实现加密算法。我们可以使用非常成熟的对称加密算法（比如AES和DES）对bundle进行加密：性能高，安全性好，最重要的是开源社区有现成的库，切换包即可直接地。所以如果使用对称加密方案，只要服务端和客户端协商一个密钥，然后服务端用这个密钥加密bundle，客户端用同样的密钥解密，就可以绕过AppStore异常到某个程度。流量检测。1.3非对称加密非对称加密属于现代密码学的内容。它很新，但也很可靠。具体原理太复杂，一两句话说不清楚，就不介绍了。在加密热更新包的场景下，效果和对称加密类似，只是用私钥加密，用公钥解密。1.4总结一般来说，捆绑加密不会简单地使用一种技术。比如我们会使用混合加密对bundle本身进行加密，使用消息认证码（比如HMAC）防止篡改，加上时间戳随机数防止重放，最后对加密后的数据进行隐写加密……太多了组合在这里。个人觉得可以参考一些经典的加密组合进行业务实践。2.通道加密通道加密在本文的场景中也比较直观，即使用HTTPS协议。目的是防止审计人员通过抓包的方式抓到我们的热更新流量。当然HTTPS也有很多有趣的知识点，下面我简单介绍一下。2.1HTTPS已经在2021年开始使用了，我觉得现在互联网上基本没有暴露的HTTP明文流量了。。。几年前，一些公司可能还在考虑HTTPS加密带来的服务器成本，但是在各大平台（iOS/Android/Chrome），除了少数无人维护的网站，基本上所有网站都使用HTTPS。毕竟数据的价值远高于服务器的电费。使用HTTPS后，至少被中间人攻击劫持的概率降低了很多。在HTTPS上能高枕无忧吗？当然不是。去年写了一篇关于Charles抓包的文章，在HTTPS抓包上用了很多篇幅。由于APP开发者可以借助市面上的工具进行抓包，审计人员可以做的更多。在抓包工具下，大部分HTTPS数据都可以被抓取并劫持。下面说说HTTPS协议中的一些比较高级的内容。2.2HTTPS证书锁定HTTPS证书锁定，也称HTTPS证书锁定，英文叫做CertificatePinning，意思是我们只接受APP中指定域名的证书，不接受CA根对应的任何证书操作系统或浏览器中内置的证书。证书。通过这种授权方式，我们可以保证APP与服务端通信的唯一性和安全性。如果开启抓包软件，如果不主动导入固定证书就无法有效抓包（具体原理见我的博文：Charles抓包原理）。我觉得审稿人是没有精力去壳你的APP来拿你的证书的，所以你可以通过这种方式隐藏你的热更新包。当然，证书固定也是有代价的。CA签发的证书有效期有问题，所以缺点是更新证书后需要在APP中重新建证书。2.3HTTPS双向认证我们平时使用HTTPS时，一般只做单向认证，即客户端验证服务器的真实性。事实上，HTTPS支持双向认证，即支持服务端对客户端的真实性进行认证（具体过程见下图中*部分）。TLS1.2握手流程图一般来说，启用HTTPS双向认证的应用都是对安全性要求极高的应用，比如金融类应用、匿名社交类应用。而如果要实现双向认证，就必须在客户端内置公钥证书和私钥，但是APP有砸壳的风险，所以得想办法加密隐写这两个东西（都是俄罗斯宝贝）。整体来说，实现HTTPS双向认证的成本还是很高的，但是一旦实现了，安全系数还是很高的，不仅绕过了审计人员的流量检测，整体整个APP的网络安全有了很大的改善。保护。4.总结关于热更新，根据苹果的应用规范，基于JavaScriptCore的热更新是完全可行的，但前提是你必须遵守规则，不能脱离苹果的控制；但是AppStore的审核规则极其不透明，虽然我们是好公民，但还是需要对热更新包进行一定程度的隐藏，以免造成不必要的麻烦；隐藏热更新包，可以从源头加密和通道加密两个角度来思考。总的来说，是灵活运用密码学习知识，加密网络数据，防止异常流量被检测，隐藏捆绑包，同时也保护用户数据安全，减少被攻击的可能性。5.参考阅读🍶为什么你的Charles抓包失败？
