wemobiledev / article

articles by WeChat Mobile Development Team

WeMobileDev Articles

Articles in mp.weixin.qq.com, you can scan the following qrcode to follow us!

article's Issues

repo介绍的时候有typo

articles bt WeChat Mobile Development Team

bt ...

tcp mss问题请教

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

《基于TLS1.3的微信安全通信协议mmtls介绍》文末链接404

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

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

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

请教《ART下的方法内联策略及其对Android热修复方案的影响分析》中的关于判断新旧DexCache的问题

最近我的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也应该初始化了才对，非常的不理解这点，盼望解答一下。

请教：针对闹钟对齐使用了什么策略？

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

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

smart_heartbeat.cc

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

自定义tls协议后，请问贵司团队如何抓加密之后数据包进行测试呢？

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

关于热修复art插桩会导致寻址错误

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

请教下Android N混合编译生成的base.art中的类在运行时最终添加到哪个classloader的问题

您在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_;
  }

不知道我们哪里出错了？

请教下mmtls中关于公钥交换方式的问题

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

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

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

请教下getdefaultgateway6()函数是如何实现

基于TLS1.3的微信安全通信协议mmtls

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

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

Tinker如何兼容Multidex

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

QQ浏览器在某些Android 7.0机型上爆出Tinker异常

行为：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

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

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

如何处理Wi-Fi情况下IPv6和IPv4的切换

如题

getdefaultgateway6 和 getdefaultgateway方法

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

数据库修复后如何重新替换数据库？

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

最新的Mac10.12系统的NAT64热点问题

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

关于Android MediaCodec硬编码16位对齐的问题

前段时间我也遇到这个问题了，参考：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;
}

有遇到相同的情况吗？

Dex 寄存器是否也会影响内联？

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

【疑问】微信iOS SQLite源码优化实践

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

关于ECDSA防止中间人的问题

注意到，由于签名算法中的公钥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无法通过微信后端校验？