小程序在代码中被称为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()