Earlonus

暂时没有特别急需AS插件的情况，属于nice to have吧。

> 您好： > 在ZipFileUtils.java文件中的uozip2Dir()方法是为了将zip包解压到指定文件夹中，但由于解压过程中没有对条目名做校验，导致攻击者可能通过构造带有../的zip文件，解压时会覆盖指定目录之外的敏感文件 >  > > 修复方法： >  和刚刚那个问题的情况是一样的，我们这里解压的是实时下拉的RuntimeView数据包，数据包的MD5是通过业务加密通道下行的，下拉的包会经过MD5校验后保存在私有目录（开源版本为了学习方便配置了SD卡目录，今天内会提交一个patch改成私有目录）。因此解压这个过程是发生在zip包进行了MD5校验之后，因此希望能了解到整个模拟攻击过程详情，以便于加强安全措施，修复漏洞。

在代码中有个demo工程，可以看一下 我这边后续完善一些更复杂有趣的demo

目前的demo中确实主要介绍了语法的用法，后面会补充一些常见的开发套路，比如开发动画、交互、多次网络请求、页面整合这类用法。

我在demo中提交了一个新闻内容类APP的滚动tab+feeds流的示例页面，如果希望获得特定样式的开发示例，可以留言详细说明。

re ls:目前应用宝在使用，我们终归是要在实践中检验过才拿出来，这些请放心。

感谢反馈，本地已经修复，外网验证后再提交上来。 RapidPool的中对文件byte[]流缓存本意是对.lua或.xml等影响加载速度的极小文件进行缓存，提高加载速度而又对内存占用影响微乎其微。 而消耗大量内存资源的图片，建议采用glide等图片缓存库封装成控件展示。 本地修改尝试跳过了对图片的缓存，验证后提交上来。

> 您好： > 我是360代码安全的工作人员，在我们的开源代码检测项目中，发现RapidView中存在xxe漏洞，详细信息如下： > 在RapidXmlLoader.java文件中的bytesToDocument方法进行了解析xml的操作，但是没有禁止解析xml外部实体 >  > 但我对RapidView并不了解，还不确认输入源是否完全可靠。。 你好，感谢您的反馈，希望能了解到构造攻击的全部过程。 我们在使用RapidView时，一般是通过加密通道拉取升级文件信息（MD5+文件地址），数据上下行的加密通道一般是根据项目自身的保密级别，自行建立的后台数据加密逻辑，并不在开源范畴内，因此关于这部分我这里并没有过多介绍。通过CDN拉取到文件后将会进行MD5校验并保存到私有目录。因此在非root手机同时不重新编译apk包的情况下，并不能篡改输入源。  但在开源项目中，并不带有网络下载相关模块，只提供了下载接口，同时为了便于学习，把文件下来路径默认放到了SD卡上，我今天之内会把除调试模式外的路径改回私有目录。 不过似乎这并不是你提到的XXE漏洞，因此还是希望能提供更多详情。

从什么维度来看呢，如果是APK增量维度，200KB左右(150KB luaj + 30~50KB代码)

内存占用主要是XML缓存和预加载比较多，应该还在可接受范围内，近期有计划提交一版更新，解决缓存带来的内存占用问题。