wemobiledev / article Goto Github PK

最近我的Android N手机上京东App偶现crash，通过log发现京东App使用了tinker热修复方案，这个crash和
ART下的方法内联策略及其对Android热修复方案的影响分析中描述的第二种crash相似：

oldDex里的typeid >= newDex的DexCache的长度 被SIGABORT干掉，Abort Message为数组下标越界

但是我对判断新旧DexCache时存在一些疑惑，已知条件：

f.sC内联了h.getExternalStorageDirectory
(12288+1292)/4 = 3395，对应compatible.util.h的typeid
(12288+1120) / 4 = 3352，对应compatible.d.p的typeid

按照我对文章的理解，因为3395对应的类为null或者没有初始化，然后跳转到0x036e40ea这个地方去执行，按照类的加载流程加载了新的类，并且形成了新的DexCache，继而3352作为索引的DexCache是新的DexCache。但是由于内联的原因，3352这个索引对应的是旧的DexCache，因此会出现问题。

我的疑惑就在于这一系列动作的触发条件，那就是只有3395对应的类为null或者没有初始化才会跳转去执行后面的流程。3395对应的是旧的DexCache，按照我的理解，它应该既不为NULL也应该初始化了才对，非常的不理解这点，盼望解答一下。

按照上文自定义tls加密协议后，请问贵司团队在平日测试中如何使用wireshark/charles等工具抓加密之后数据包进行测试的工作呢，亦或者有其他更好的抓包方法，请贵司解答。Thanks♪(･ω･)ﾉ

Hi， 首先对mars项目致敬，阅读了一部分源码，发现其对移动网络确实做了许多优化。�
这篇文章中提到：印象比较深刻的某地的用户反馈连接 WiFi 时，微信不可用，后来 tcpdump 发现，当包的大小超过一定大小后就发不出去。解决方案：在 WiFi 网络下强制把 MSS 改为1400(代码见 unix_socket.cc)。
我们遇到的问题与你在文章中提到的类似，也是请求长度超过mss后，在用户的wifi环境下出现拆包后，请求失败。据我们分析，不一定是与运营商有关系，而是跟路由器组网方式、路由器MTU设置有一定关系。
另外想问一下，据了解mss是最终由服务端与客户端协商定下的，为什么不通过服务端降低mss，来最终减小mss值，而是直接在客户端设置更小的mss？

参考资料中《TLS协议分析与现代加密通信协议设计》链接应为：

https://blog.helong.info/blog/2015/09/07/tls-protocol-analysis-and-crypto-protocol-design/

原文中引用的链接为···/2015/09/06/···，疑为手误

注意到，由于签名算法中的公钥ECDSA_verify_key是一直公开的，攻击者没有办法阻止别人获取公钥，除非完全掐断发送方的通信。这样一来，中间人攻击就不存在了，因为Eve无法伪造签名。

这里没看懂，既然ECDSA的公钥是公开的，那么理论上中间人也可以拦截ECDSA的签名和公钥内容，然后再伪造

这里没看明白，请教下诸位！

请问如何联系到您，我们公司想在热补丁方面和贵团队展开合作，成为内测用户。

您好, 现在很多app早已超过了65535的方法数限制, 请问微信tinker增量dex的方案如何兼容multidex? 谢谢回答.

你好，我在这边文章微信终端跨平台组件 Mars 系列 - 我们如约而至中有如下叙述：

平台特性优化。虽然 Mars 是跨平台的基础组件，但在很多设计上是需要结合各平台的特性的。例如为了尽量减少频繁的唤醒手机，引入了智能心跳，并且在智能心跳中考虑了 Android 的 alarm 对齐特性(具体实现见smart_heartbeat.cc)。再如在网络切换时，为了平滑切换的过程，使用了 iOS 中网络的特性，在 iOS 中做了延迟处理等。

smart_heartbeat.cc

没能明白其中的玄机，还请赐教指点。

1.请问下mmtls协议中会涉及到一些密码学的运算，比如签名验签算法中的大数运算，我想问下你们用到的密码库是自己实现的还是用的第三方开源的，如OpenSSL？

2.关于mmtls安全通信协议代码实现层面，腾讯有无开源的打算？

行为：QQ浏览器7.3.1.3060版本打开百度首页会百分百出现卡顿。看起来像某些patch通过Tinker更新失败进而导致问题产生的。
Log 日志：
03-21 00:58:29.483 28710 28710 W LoadedApk: mResDir: /data/app/com.tencent.mtt-1/base.apk
03-21 00:58:29.483 28710 28710 W LoadedApk: myResfileName: /data/dalvik-cache/arm/data@[email protected]@[email protected]
03-21 00:58:29.483 28710 28710 W LoadedApk: myResfileName: /data/dalvik-cache/arm/data@[email protected]@[email protected] is not exist
03-21 00:58:29.483 28710 28710 W LoadedApk: mResDir: /data/app/com.tencent.mtt-1/base.apk is bigger than 20M. We will pop the text.
03-21 00:58:29.528 31764 1518 V PackageManager: getPackageInfo com.tencent.mtt: Package{5a97724 com.tencent.mtt}
03-21 00:58:29.546 28710 28710 W Tinker.TinkerLoader: tryLoadPatchFiles:patch dir not exist:/data/user/0/com.tencent.mtt/tinker
03-21 00:58:29.555 31764 1083 V PackageManager: getApplicationInfo com.tencent.mtt: Package{5a97724 com.tencent.mtt}
03-21 00:58:29.618 28710 28710 D QBTinkerManager: processName=com.tencent.mtt
03-21 00:58:29.618 28710 28710 D QBTinkerManager: processName=com.tencent.mtt
03-21 00:58:29.624 31764 1495 V PackageManager: getServiceInfo ComponentInfo{com.tencent.mtt/com.tencent.tinker.lib.service.TinkerPatchService}: Service{488d34b com.tencent.mtt/com.tencent.tinker.lib.service.TinkerPatchService}
03-21 00:58:29.626 28710 28710 W Tinker.Tinker: tinker patch directory: /data/user/0/com.tencent.mtt/tinker
03-21 00:58:29.629 28710 28710 I Tinker.DefaultLoadReporter: patch load result, path:/data/user/0/com.tencent.mtt/tinker, code:-2, cost:8

注意到，由于签名算法中的公钥ECDSA_verify_key是一直公开的，攻击者没有办法阻止别人获取公钥，除非完全掐断发送方的通信。这样一来，中间人攻击就不存在了，因为Eve无法伪造签名。具体过程如图5所示：

关于这一点不是很理解——中间人（Eve)仍然可以:

1. 拦截客户端的请求后，通过自己生成一对sign_key和verify_key
2. 篡改Bob_ECDH_pub_key之后，将中间人自己生成的signature_eve、eve_verify_key 和 eve_ECDH_pub_key，发给服务端
3. 同理对客户端。

不知道我的理解中哪个部分是有问题的部分呢？

还是说，原本微信的sign_key和verify_key其实是根据static_svr_pub_key生成的，所以中间人在不破解客户端代码的情况下，生成的sign_key和verify_key无法通过微信后端校验？

"我们知道，iOS app是单进程的，并没有多进程并发的需求，这和SQLite的设计初衷是不相同的。这就给我们的优化提供了理论上的基础"
对于单个app来说是单进程的， 但是如果有apple watch app作为extension，共享sqlite3 db，理论上来说算是2 process，不知道wechat在watch app是怎么做这块地方的呢

你好，获取默认网关的实现是怎么样的

iphone手机连接Mac系统10.12之前的版本 NAT64热点，用getaddrinfo转换出来的v6 IP 是带了NAT64/DNS64 64:ff9b::/96前缀，但最新的10.12用这个函数转换的ip前缀是2001::的，你不是说这个是隧道通道的么，而且这个前缀好像除了2001固定，后面的都不固定吧，这种情况要如何处理？

articles bt WeChat Mobile Development Team

bt ...

直接文件替换不会立即生效，需要重启才生效。微信修复数据库后需要重启APP吗

前段时间我也遇到这个问题了，参考：https://stackoverflow.com/questions/28291204/something-about-stagefright-codec-input-format-in-android 解决了。

但现在遇到一个新问题：视频能正常编码出来，但是部分手机在视频右侧或底部出现一条绿纹，应该就是对齐增加的几个像素导致，不知道如何解决。

不知道是不是对齐的方式有问题，我的方式：
if (w % 16 > 0) {
w = (w / 16) * 16 + 16;
}
if (h % 16 > 0) {
h = (h / 16) * 16 + 16;
}

有遇到相同的情况吗？

首先感谢微信团队的付出. 关于热修复一文中提到的art插桩会导致寻址错误的问题, 文中解释的不是很清楚, 我用手Q的热修复方法测试了art多个机型, 修改方法名修改变量名都正常修复并且没有引起其它问题.

如题

您在Android N混合编译与对热补丁影响深度解析一文提到，为了规避混合编译带来的影响，采用运行时替换PathClassLoader方案，因为App image中的class是插入到PathClassloader中的ClassTable中。

但是最近我们测试这个方案没有成功(程序刚开始运行正常，等过了两三天生成base.art之后就开始报错)
而且从下列代码上看 这些class好像时直接放到了bootclassloader的table里

class_linker.cc#1048

// Boot class loader, use a null handle.
    std::vector<std::unique_ptr<const DexFile>> dex_files;
    if (!AddImageSpace(image_space,
                       ScopedNullHandle<mirror::ClassLoader>(),
                       /*dex_elements*/nullptr,
                       /*dex_location*/nullptr,
                       /*out*/&dex_files,
                       error_msg)) {
      return false;
    }

class_linker.cc#5069

  if (class_loader == nullptr) {
    return &boot_class_table_;
  }

不知道我们哪里出错了？

源码中显示，小于 64 才能被 inline。