最近测试app时发现某app对数据包做了签名，其直接后果就导致截获的数据包没法修改，因此对该app的数字签名了进行了一次分析。

首先通过class-dump将app的头文件都导出来，通常数字签名都会在数据包发包之前生成，因此我们需要找好http发包有关的类，此处我们搜索httprequest，此处httprequestwithurl引起了我们的兴趣（关键名字实在是太明显了）。

查看ida可以发现该函数中在httprequeast有这样的语句，那此处是不是生成的sign了？

在gdb中在该出下断点，登陆发包断下，该处函数为stringwithFormat。

以此查看r2到r4的参数。发现r4寄存器中保存了该次签名。

向上回溯发现r4来自一个函数的返回值，此处ida没有解析出来。

使用gdb下断点，发现该处的函数调用为URLEnconde，一次实现对数据的编码。

查看寄存器R2，即该函数的第一个参数可以发现此处传入的就是签名（此时是没有经过编码的签名）。通过上图可知，该处传入的第一个参数也来至之前函数（0x00132780）的返回值，因此推断0x00132780的调用很可能生成了函数的签名。

此处对该函数下断点，运行断下之后可以发现该函数为base64StringWithHMACSHA1Digest,而函数的第一个参数即为该次通信的url，由此断定该签名是针对数据包整个包的签名。

函数的第三个参数问签名使用到的密钥，此处硬编码在app中。

进入该函数，可以发现此处CCHmacInit函数使用之前的密钥进行一个sha1处理，让后再做一次base64处理。

参照分析的结果，实现自签名的程序，和发包签名完全一致。