前几天的需求中产品想给相册选择的图片加背景渐变色,目的就是为了对齐ins的实现,比如这样:
产品也提供了算法,但是由于算法只是简单地取区域中的占比最大的颜色,取出的效果不太好。恰好学了点逆向的知识,所以黑进ins看看能不能找到其关键的实现。
砸壳,重签名,class-dump的基本步骤就略过了,首先遇到的第一个问题就是登录的时候会抛异常(貌似是cloudkit相关的),直接hook +[NSException raise:format:]
这个函数防止它崩溃。
另外其实这个应用并没有做什么防护,所以只要有一般的知识迟早都能看到一点半点,用的手段也就那么几个,有时候甚至是在重复使用,所以这里仅总结一下整个过程,方便之后回头复习。
进到这个预览页,点击debug view hierarchy
,
可以看到这其实已经生成了一张图片了。
查看内存布局,查看image的创建时机如图:
看着使用
+[UIImage imageWithCGImage:scale:orientation:]
创建的下这个符号断点,在选择相册页的时候使断点生效,每次进断点打印一下当前堆栈跟这次的堆栈一不一样,过一会就来到了这个创建的图片的断点了:
ins-preview-image-stack.png
3和4都是FBShareFramework里面的,先从第5个地址调查起,手动复原其地址:
发现了红框的地址,非常可疑,所以下断点调查之。
之后几个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的汇编和还原的伪代码即可。这个过程就不贴出来了。
网友评论