本文详细介绍了微信小程序的核心逻辑，包括包结构、关键类的功能，以及如何通过反编译和抓包获取wxapkg文件。重点讨论了解析wxapkg的过程，展示了使用Python进行解码的示例代码，为深入研究小程序提供了基础。
小程序在代码中被称为appbrand，主要逻辑放在包com.tencent.mm.plugin.appbrand下面(部分抽出的ui控件除外)；另外引用了3个js资源，均在/assets/wxa_library/下。虽然很大部分代码被混淆过的，但是适当的反编译后，我们还是能看出绝大部分东西。
包整理
依次整理com.tencent.mm.plugin.appbrand下的内容，按包区分:
a：似乎是单例和依赖注入的容器
appcache：微信小程序打包为wxapkg文件，这里处理的是下载解包验证和后续处理逻辑
appstorage：在数据库中存取AppBrandKVData的逻辑
b：在数据库中存取AppBrandLauncherLayoutItem的逻辑，是微信小程序列表缓存
c：通过安卓的canvas实现了一套完整的js的canvasapi，提供给小程序中canvas控件使用
config：小程序模块环境变量管理，其中数据可以通过互联网下发更新
contact：把app添加为微信联系人，似乎和聊天置顶有关
d：InputStream相关工具类
e：录音功能相关工具类
f：附近的人的小程序相关工具类
g：应该是AppBrandNetworkUtil，小程序模块用到的网络部分的工具类
h：权限管理工具类，包括小程序权限管理和jsapi权限管理，同时也可以通过网络更新
i：小程序sd卡操作工具类
ipc：ipc即进程间通信。小程序通过新开进程来保障独立运行的，独立进程的启动与微信本体的通信依赖这个包的代码完成。其中AppBrandMainProcessService是最主要运行服务，而AppBrandProcessProxyUI是小程序进程持有性质activity。
j：AppBrandConversionExtension，似乎是多个小程序切换过程中的辅助类
jsapi：微信小程序通过浏览器暴露给js环境的api的入口基本上都在这儿了，包括组件部分和api部分。最后AppBrandJSInterface把这些入口聚合在一起。
k：似乎是一些零散的工具类
l：js中WebSocketapi的native实现
launching：微信小程序加载逻辑的实现。主要是处理了很多加载准备过程中的逻辑和错误监测
m：微信小程序列表搜索功能相关逻辑
netscene：好像是对webview发起的特殊请求的处理和中断
page：页面部分，包括微信小程序列表页等，主要都是各个activity和使用的自定义view。其中l.class值得注意，应该是核心使用的webview了，h.class是这个webview的容器，也做了很多操作。
report：只是数据上报相关的东西
task：一些乱七八糟的异步工作放这儿了
ui：和page差不多，也是各种各样的activity和view。微信小程序实际的容器页面(5个)和各种功能与异常页面
widget：所有暴露给js的native控件都在这儿了。其实并不多
其他文件中值得关注的一些东西：
a.class即AppBrandBridge是小程序主路由控制器，持有着当前所有小程序
f.class看起来是AppBrandService，持有后台运行的jscore
现在可以获得的信息
大概知道每个包都包涵一些什么代码之后，我们就可以对微信小程序进行一些挖掘了。
wxapkg解包
通过抓包我们可以发现，每次进入小程序列表后，就会通过网络抓下来所有小程序的wxapkg包，然后所有需要的东西都在里面了。那这个wxapkg在哪儿解包的呢？经过搜索，我们发现是appcache/f.class即AppBrandWxaPkg完成的这段工作。
由于混淆得一塌糊涂，因此我分析实际wxapkg之后自己实现了一次解码(python)：
文件逆向工程思路小记酷炫狂拽屌炸天的Lottie库初
Jan
11
微信小程序源码阅读笔记1
Lrdcq , 2017/01/11 22:32 , 程序 , 評論(4) , 閱讀(6313) , Via 本站原創
在这里阅读的是，微信安卓653.980版的反编译后的代码。很清晰的可以看到，小程序在代码中被称为appbrand，主要逻辑放在包com.tencent.mm.plugin.appbrand下面(部分抽出的ui控件除外)；另外引用了3个js资源，均在/assets/wxa_library/下。虽然很大部分代码被混淆过的，但是适当的反编译后，我们还是能看出绝大部分东西。
包整理
依次整理com.tencent.mm.plugin.appbrand下的内容，按包区分:
a：似乎是单例和依赖注入的容器
appcache：微信小程序打包为wxapkg文件，这里处理的是下载解包验证和后续处理逻辑
appstorage：在数据库中存取AppBrandKVData的逻辑
b：在数据库中存取AppBrandLauncherLayoutItem的逻辑，是微信小程序列表缓存
c：通过安卓的canvas实现了一套完整的js的canvasapi，提供给小程序中canvas控件使用
config：小程序模块环境变量管理，其中数据可以通过互联网下发更新
contact：把app添加为微信联系人，似乎和聊天置顶有关
d：InputStream相关工具类
e：录音功能相关工具类
f：附近的人的小程序相关工具类
g：应该是AppBrandNetworkUtil，小程序模块用到的网络部分的工具类
h：权限管理工具类，包括小程序权限管理和jsapi权限管理，同时也可以通过网络更新
i：小程序sd卡操作工具类
ipc：ipc即进程间通信。小程序通过新开进程来保障独立运行的，独立进程的启动与微信本体的通信依赖这个包的代码完成。其中AppBrandMainProcessService是最主要运行服务，而AppBrandProcessProxyUI是小程序进程持有性质activity。
j：AppBrandConversionExtension，似乎是多个小程序切换过程中的辅助类
jsapi：微信小程序通过浏览器暴露给js环境的api的入口基本上都在这儿了，包括组件部分和api部分。最后AppBrandJSInterface把这些入口聚合在一起。
k：似乎是一些零散的工具类
l：js中WebSocketapi的native实现
launching：微信小程序加载逻辑的实现。主要是处理了很多加载准备过程中的逻辑和错误监测
m：微信小程序列表搜索功能相关逻辑
netscene：好像是对webview发起的特殊请求的处理和中断
page：页面部分，包括微信小程序列表页等，主要都是各个activity和使用的自定义view。其中l.class值得注意，应该是核心使用的webview了，h.class是这个webview的容器，也做了很多操作。
report：只是数据上报相关的东西
task：一些乱七八糟的异步工作放这儿了
ui：和page差不多，也是各种各样的activity和view。微信小程序实际的容器页面(5个)和各种功能与异常页面
widget：所有暴露给js的native控件都在这儿了。其实并不多
其他文件中值得关注的一些东西：
a.class即AppBrandBridge是小程序主路由控制器，持有着当前所有小程序
f.class看起来是AppBrandService，持有后台运行的jscore
现在可以获得的信息
大概知道每个包都包涵一些什么代码之后，我们就可以对微信小程序进行一些挖掘了。
wxapkg解包
通过抓包我们可以发现，每次进入小程序列表后，就会通过网络抓下来所有小程序的wxapkg包，然后所有需要的东西都在里面了。那这个wxapkg在哪儿解包的呢？经过搜索，我们发现是appcache/f.class即AppBrandWxaPkg完成的这段工作。
由于混淆得一塌糊涂，因此我分析实际wxapkg之后自己实现了一次解码(python)：
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
#!/usr/bin/python
# lrdcq
# usage python wxapkg_unpack.py filename, unpack at filename.unpack
import sys,os
import struct
class WxapkgFile:
nameLen = 0
name = ""
offset = 0
size = 0
with open(sys.argv[1], "rb") as f:
root = os.path.dirname(os.path.realpath(f.name))
name = os.path.basename(f.name)
#read header
firstMark = struct.unpack('B', f.read(1))[0]
print 'first header mark = ' + str(firstMark)
info1 = struct.unpack('>L', f.read(4))[0]
print 'info1 = ' + str(info1)
indexInfoLength = struct.unpack('>L', f.read(4))[0]
print 'indexInfoLength = ' + str(indexInfoLength)
bodyInfoLength = struct.unpack('>L', f.read(4))[0]
print 'bodyInfoLength = ' + str(bodyInfoLength)
lastMark = struct.unpack('B', f.read(1))[0]
print 'last header mark = ' + str(lastMark)
if firstMark != 190 or lastMark != 237:
print 'its not a wxapkg file!!!!!'
exit()
fileCount = struct.unpack('>L', f.read(4))[0]
print 'fileCount = ' + str(fileCount)
#read index
fileList = []
for i in range(fileCount):
data = WxapkgFile()
data.nameLen = struct.unpack('>L', f.read(4))[0]
data.name = f.read(data.nameLen)
data.offset = struct.unpack('>L', f.read(4))[0]
data.size = struct.unpack('>L', f.read(4))[0]
print 'readFile = ' + data.name + ' at Offset = ' + str(data.offset)
fileList.append(data)
#save files
for d in fileList:
d.name = '/' + name + '.unpack' + d.name
path = root + os.path.dirname(d.name)
if not os.path.exists(path):
os.makedirs(path)
w = open(root + d.name, 'w')
f.seek(d.offset)
w.write(f.read(d.size))
w.close()
print 'writeFile = ' + root + d.name
f.close()
扫一扫
7万+
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
