字节_signature完整算法分析以及实现！（混淆vm版本）

        现在字节系已经不验证这个该签名了，不多可以作为学习方式来研究学习下深入学习研究下jsvmp的原理以及工作流程，为后续打好基础。

一、抓包接口分析

在该接口中携带了_signature加密参数;

第一步，全局搜索_signature:

 结果就两个，而且可以确定的是不是我们要找的地方。 

二、跟值

既然通过全局搜索的方式无法确定该参数生成的地方，那么就只能通过xhr断点或则通过调用栈观察该参数的来源。

         在接口的Initiator功能选项中可以看到该接口请求的调用栈，可以看到第一个“send”为javascript发起网络请求的位置，那么，我们就可以从这个位置开始一步步向上跟踪，直到出现签名位置。但是这个这个方法有个缺陷，在你刷新该页面的时候，它不可能只有这一个网络请求，所以推荐使用xhr断点，可以只对某一条请求进行过滤断点。

        在这里使用了xhr断点后，就可以刷新页面去触发这个断点了。

可以看待，这个时候以及在这条url上断住了，那我们就需要查看下这条网络请求携带的参数中有哪些东西，是否有我们的signature存在，我们可以在控制台(console)中查看。通过观察后会发现参数this中携带了完整的url，其中就包括了_signature，那么我们可以通过google浏览器自带的Call Stack查看堆栈情况了。如图:

 在堆栈中我们可以看到一个XMLHttoRequest.send方法，这里我们可以下一个疑问，为什么在一个网络请求内，会出现两个send呢，带着这个疑问我们来分析下栈前栈后。

 通过分析后，我们会发现经过这个地方后，我们的堆栈中就出现了signature，但这明明是一个XMLHttpRequest，我们也没有发现疑似的网络请求。答案只有一个，该send方法被重构了。通过控制台查看一下这个方法:

 果然，他重构了XMLHttpRequest.send方法，并将他指向了一个混淆过的vm中。

 那么，这里就作为生成signature的"入口"了。

三、Jsvmp分析

        通过特征可以发现，这是一个jsvmp，那么我们可以使用插桩大法来查看加密流的过程，从而更加细致的观察计算过程。

 接下来重新刷新页面查看输入值arguments的变化:

        可以看到，它将logout这个url传入到url中了，那么，可以确定的是，有“人”向调用入口传递了某种信息，所以，我们就需要开始观察它的计算过程了。

1、流程分析

        在分析vmp前，我们需要了解下vmp是什么，以及它的执行流程原理等， 这里就不赘述了，大家有兴趣的可以去详细了解一波。下面是基于了解vmp的基础上对该代码进行分析，想学习的小伙伴们一定要先去了解下，不然听起来就像天书一样（我就是其中一位）;

                通过分析，我们可以得出_0x613229 = []在该代码中作为一个缓冲区的角色，计算的每一个步骤都会寄存在_0x613229中，那么，我们可以先通过插桩的方式来查看该变量中的数值变化:

结果如下:

 在密密麻麻的结果中，我们可以看到_signature和x-bogus出现了，那么我们可以得出以下结论

• x-bogus以及_signature都是通过这个这个方法生成的
• 找到入口十分重要
• 必须通过插桩的方式观察流程计算

2、结果分析

        在vmp中，是存在流程控制的，具体是通过解析字节码得出结果后进行逻辑索引。该代码中计算的位置在：

在这一点的基础上，我们开始观察分析签名的生成过程

 可以看到，_signature是由一段一段拼接起来的，那么，我们该怎么去确定这些字符串的由来？

3、逻辑跟踪

        在第2点中介绍了逻辑索引，我们先将这些逻辑索引打印出来查看他们是什么样的。

 vmp会通过判断这两个逻辑索引来控制不同的逻辑条件分支，我们可以通过这个索引进行条件断点来观察每个字符串的生成。