记一次逆向的过程（ins背景渐变色生成算法调研）

前几天的需求中产品想给相册选择的图片加背景渐变色，目的就是为了对齐ins的实现，比如这样：

产品也提供了算法，但是由于算法只是简单地取区域中的占比最大的颜色，取出的效果不太好。恰好学了点逆向的知识，所以黑进ins看看能不能找到其关键的实现。

砸壳，重签名，class-dump的基本步骤就略过了，首先遇到的第一个问题就是登录的时候会抛异常(貌似是cloudkit相关的)，直接hook +[NSException raise:format:]这个函数防止它崩溃。

另外其实这个应用并没有做什么防护，所以只要有一般的知识迟早都能看到一点半点，用的手段也就那么几个，有时候甚至是在重复使用，所以这里仅总结一下整个过程，方便之后回头复习。

进到这个预览页，点击debug view hierarchy，

ins-preview-debug.png

可以看到这其实已经生成了一张图片了。

查看内存布局，查看image的创建时机如图：

看着使用 +[UIImage imageWithCGImage:scale:orientation:]创建的
下这个符号断点，在选择相册页的时候使断点生效，每次进断点打印一下当前堆栈跟这次的堆栈一不一样，过一会就来到了这个创建的图片的断点了：

ins-preview-image-stack.png

3和4都是FBShareFramework里面的，先从第5个地址调查起，手动复原其地址：

ins-backcolor.png

发现了红框的地址，非常可疑，所以下断点调查之。

之后几个loc函数忘记截图了，主要是将x21放到x0调用msg_send，所以打印x21和x1的值，得知其类型和方法。用kvc查看这个到底是个啥

这是个颜色的数组，查了下色值基本跟上下渐变色的起始位置差不多，基本可以确定是这里来的了，然后查看颜色的创建堆栈看看能否找到线索：

看着是通过initwithred,green,blue创建的，针对这个颜色，下符号的条件断点：

colorstack.png

进入断点后，直接打印d1,d2确定是不是这个颜色

看上去基本核实了，然后上一个栈帧的函数地址看看

发现是一个新类，在fbshareframework里面，class-dump出这个framework，观察下这个类：

，从名字可以确定，这个类基本就是取色的工具类了。

接了下来，hook这个类的所有函数，查看其调用和传参情况。发现这个方法在相册的时候就已经有再调用了，说明取色是在相册进行的，将手机的相册清理得只剩一张，以方便查看。

首先调用的是 initWithImage,从image的高度来看，是被截取过的，而且上下都一样。

PS:给这个方法下断点会发现这个image是截取原图上下5%的部分，宽度不变，这个过程跟上面类似，就不贴出来了。

然后打印 getorcomputecolors的返回，是一个set，在这里又发现一个新类

看着像是使用了某种聚类算法

接下来调用dominantColor这个方法，打印这个返回值，是NSArray类型（里面的类型是color）

接下来调用dominantColor这个方法，打印这个返回值，是color类型的，看着像是上面array的第一个元素(后面面还原成高级代码看的时候发现真的是)

再结合刚才的堆栈信息，可以得出调用关系是dominatecolor -> _dominantcolors -> getorcomputecolors,如果分析取色的聚类算法，分析getorcomputecolors的汇编和还原的伪代码即可。这个过程就不贴出来了。