对旅行APP的检测以及参数计算分析【Simplesign篇】

admin 2024年3月3日04:33:18评论14 views字数 10859阅读36分11秒阅读模式
本来想把SimpleSign拆解进行发帖的,但是又觉得是挤牙膏,本贴我可能会持续更新,关于一些细节以及使用的技术手段,将ss函数完全解析出来以学习其实现混淆的方式方法。本篇为前置篇,后续会对此出一个补充的帖子,细数scmain中一些影响计算的点具体的影响因子等因素。

上一篇导航:对某旅行APP的检测以及参数计算分析【新手向-准备篇】(一)
(https://bbs.kanxue.com/thread-278621.htm)

本贴只讨论其实现原理,若有侵权请联系我删除


简要概述:
目标so:scmain.so
讨论的生成过程:SimpleSign
使用工具:IDA pro 7.7、 Binary Ninja、Frida、Frida Stalker
本篇文章实现:SimpleSign的计算过程,包括前、中、后、变换四个主体阶段,文章中会详细介绍。


起手准备
上篇文章中,我们定位到了SimpleSign函数所在的地址偏移,所以我们根据offset去IDA定位其反汇编的代码,先观察其展示出来的东西是否满足我们的推倒过程。

SimpleSign的native函数偏移为0x7D4B4。


对旅行APP的检测以及参数计算分析【Simplesign篇】

结果很明显,代码做了混淆,但是其中我们可以发现一些反射调用的特征,GetByteArrayElements,GetArrayLength,GetStringUTFChars等,因为我们在JNI Native中知道SS函数传入的参数是一个字节数组和一个字符串,所以我们推断出此处跟我们要找的函数入口有关联。我们看一下sub_7d4b4的网状结构。对旅行APP的检测以及参数计算分析【Simplesign篇】

因为本文是新手向,我们就介绍一些简单点、通俗易懂的方法来分析(难的我也不会)。


Trace - Frida Stalker
关于Stalker我在上一篇中已经介绍过了,包括对msaoaidsec.so的anti操作。我们直接跳到使用。


对旅行APP的检测以及参数计算分析【Simplesign篇】

关于Stalker的起始位置,以及长度,这一块需要我们自己去试,调整长度,因为很多时候有一些汇编指令的地址并不在我们trace的范围之内,会造成指令流trace的log记录不到的情况存在。

另外,记得要对Java native函数也hook上,方便我们对传入的参数有更直观的展示以及返回值的分析。

Java.perform(function () { let SecurityUtil = Java.use("ctrip.android.security.SecurityUtil"); SecurityUtil["simpleSign"].implementation = function (bArr, str) { console.log('simpleSign is called' + ', ' + 'bArr: ' + bArr + ', ' + 'str: ' + str); let ret = this.simpleSign(bArr, str); console.log('simpleSign ret value is ' + ret); return ret; }; SecurityUtil["init"].overload('android.content.Context', 'int').implementation = function (context, i2) { console.log(`SecurityUtil.init is called: context=${context}, i2=${i2}`); this["init"](context, i2); }; });

关于trace,有几点要讲:
1.我们对msaoaidsec已经进行了anti操作,但是并不影响其有一些其他的检测手段,会造成进程被kill。
2.我测试了几个版本的frida,貌似16.1.0可以完整trace下来,我有点记不清了。
3.魔改frida,这个是另一个范畴了,暂时不表,后续会对其检测能力做更深的剖析。
Frida Stalker trace 的过程时间其实是比较长的,日志大概是60MB左右,90万行左右,其中有一些在MD5算法的部分漏掉了,我没有重新跑,范围大概锁定在这个区间内,给大家一个参考。

展示下trace的结果。


对旅行APP的检测以及参数计算分析【Simplesign篇】
对旅行APP的检测以及参数计算分析【Simplesign篇】

以上就是一个几乎完整的SimpleSign的计算过程。下面我们开始着手分析。


分析前32位

3.1 设想


起初,我认为结果这75位的字符串应该是MD5 + 某些特征 + MD5组成的,可是通过Frida Hook Native函数发现,前32位几乎是不变的。第41-43位也是几乎不变的。那么我假设,此部分的构成是由一个特征(32位) + 每次都会变化的特征(8位) + 不变的(3位) + 疑似MD5(32位)组成的。对旅行APP的检测以及参数计算分析【Simplesign篇】

我们先对前32位进行分析。取前4位,在trace 日志中进行搜索。


对旅行APP的检测以及参数计算分析【Simplesign篇】

可以看到图中我做了标识,E0AA是由d2538处的汇编代码执行了异或运算,我们试着在IDA中去d2538处观察其计算逻辑。


对旅行APP的检测以及参数计算分析【Simplesign篇】
猜测v17的值应该就是我们的0x45304141了,推测sub_D1DB4的参数a2是用来存放前32位的地址,我们验证一下v5的记过是否是5-8位,鼠标放在v5处,Tab切换到汇编代码,根据其地址在trace日志中搜索。

libscmain.so d23dc ldr x16, [sp, #0x50] ; x16 = 0x7190e94e3d --> 0x7189db0948 (1e0f3c2d5a4b7869) libscmain.so d23e0 ldr w18, [x16, #4] ; x18 = 0x7 --> 0x64326333 libscmain.so d23e4 eor w15, w15, w18 ; x15 = 0x57765407 --> 0x33443734

0x33443734恰恰就是第5-8位,那么我们几乎就确定了这个函数就是我们要找的前32位生成的位置,但是此方法中只有4个变量来存放结果,但是我们在trace日志中所搜该地址发现结果是2个,那么我们可以假设此方法执行了两次,两次的执行结果相加正好是32位。


对旅行APP的检测以及参数计算分析【Simplesign篇】
至此,我们确定了此函数的作用,以及参数a2的功能,那么下一步我们要确认如下几点:
1.a1、a3参数。
2.此函数的调用过程是怎样的。
对于调用过程,可以参考IDA 的X键,查看交叉引用,但是如果存在过多的调用情况排查起来其实略麻烦,配合trace日志能更方便的节省一点时间,但是也有可能存在跳转指令是处在花指令的范围内,如果这样的话那根据日志排查起来就略微有一点点麻烦。还有就是可以用frida打印调用栈,这个方法略微有一些看脸。

碰碰运气

libscmain.so d5f2c ldp x0, x30, [sp], #0x10 ; x0 = 0xc4 --> 0x71edd1f2f0 (���*�g�Iԥxt.��) sp = 0x7189db0860 --> 0x7189db0870 libscmain.so d5f30 ldur x0, [x29, #-8] ; libscmain.so d5f34 ldr x1, [sp, #0x10] ; libscmain.so d5f38 ldr x2, [sp, #8] ; libscmain.so d5f3c bl #0x7190d1adb4 ; libscmain.so d1db4 stp x0, x30, [sp, #-0x10]! ; sp = 0x7189db0870 --> 0x7189db0860 (����q) libscmain.so d1db8 ldr w0, #0x7190d1adc0 ; x0 = 0x71edd1f2f0 --> 0xd1 libscmain.so d1dbc bl #0x7190d1ae60 ; libscmain.so d1e60 sub x0, x0, #0x11 ; x0 = 0xd1 --> 0xc0 libscmain.so d1e64 eor x0, x0, #0xc0 ; x0 = 0xc0 --> 0x0 (null) libscmain.so d1e68 add x0, x0, #1 ; x0 = 0x0 --> 0x1 libscmain.so d1e6c ldr w0, [x30, x0, sxtx #2] ; x0 = 0x1 --> 0xb8

查看trace日志发现,D1DB4方法调用的上方代码块有可能是正常的代码,根据地址d5f38去IDA中查看。


对旅行APP的检测以及参数计算分析【Simplesign篇】

继续向上找

libscmain.so ed09c ldr w0, #0x7190d360a4 ; x0 = 0x71edd1f2f0 --> 0xec libscmain.so ed0a0 bl #0x7190d35dec ; libscmain.so ecdec bl #0x7190d35ecc ; libscmain.so ececc eor x0, x0, #0xc0 ; x0 = 0xec --> 0x2c libscmain.so eced0 lsr x0, x0, #0 ; libscmain.so eced4 add x0, x0, #1 ; x0 = 0x2c --> 0x2d libscmain.so eced8 ldr w0, [x30, x0, sxtx #2] ; x0 = 0x2d --> 0x748 libscmain.so ecedc add x30, x30, x0 ; libscmain.so ecee0 ret ; libscmain.so ed538 ldp x0, x30, [sp], #0x10 ; x0 = 0x748 --> 0x71edd1f2f0 (���*�g�Iԥxt.��) sp = 0x7189db0890 --> 0x7189db08a0 libscmain.so ed53c mov w3, wzr ; x3 = 0x7190e94d78 --> 0x0 (null) libscmain.so ed540 bl #0x7190d1ee5c ; libscmain.so d5e5c stp x0, x30, [sp, #-0x10]! ; sp = 0x7189db08a0 --> 0x7189db0890 (����q) libscmain.so d5e60 ldr w0, #0x7190d1ee68 ; x0 = 0x71edd1f2f0 --> 0x536 libscmain.so d5e64 bl #0x7190d1ee80 ; libscmain.so d5e80 sub x0, x0, #0x3a ; x0 = 0x536 --> 0x4fc libscmain.so d5e84 eor x0, x0, #0xfc ; x0 = 0x4fc --> 0x400 libscmain.so d5e88 lsr x0, x0, #0xa ; x0 = 0x400 --> 0x1

试试ecedc


对旅行APP的检测以及参数计算分析【Simplesign篇】

定位到了sub_ECDE4,我们继续向上走,根据ecde4在日志中查找上层。

libscmain.so efcf8 eor x0, x0, #0xe0 ; x0 = 0xf6 --> 0x16 libscmain.so efcfc sub x0, x0, #0x10 ; x0 = 0x16 --> 0x6 libscmain.so efd00 add x0, x0, #1 ; x0 = 0x6 --> 0x7 libscmain.so efd04 ldr w0, [x30, x0, sxtx #2] ; x0 = 0x7 --> 0x1e0 libscmain.so efd08 add x30, x30, x0 ; libscmain.so efd0c ret ; libscmain.so efe78 ldp x0, x30, [sp], #0x10 ; x0 = 0x1e0 --> 0x71edc30020 (TracerPid) sp = 0x7189db0a00 --> 0x7189db0a10 libscmain.so efe7c adrp x0, #0x7190eb7000 ; x0 = 0x71edc30020 --> 0x7190eb7000 libscmain.so efe80 add x0, x0, #0x1bc ; x0 = 0x7190eb7000 --> 0x7190eb71bc (ed756e23400710596bbd71988670248va4c8db2ae867a149d4a578742e90ec) libscmain.so efe84 sub x1, x29, #0x10 ; x1 = 0x20 --> 0x7189db0a80 ( ) libscmain.so efe88 bl #0x7190d35de4 ; libscmain.so ecde4 stp x0, x30, [sp, #-0x10]! ; sp = 0x7189db0a10 --> 0x7189db0a00 (�q��q) libscmain.so ecde8 ldr w0, #0x7190d35df0 ; x0 = 0x7190eb71bc --> 0xd4 libscmain.so ecdec bl #0x7190d35ecc ; libscmain.so ececc eor x0, x0, #0xc0 ; x0 = 0xd4 --> 0x14 libscmain.so eced0 lsr x0, x0, #0 ;

此处我们注意到一个字符串,add x0, x0, #0x1bc此处需要注意的一点是,他的汇编代码与IDA的反汇编并不一致,道理是相同的,粗俗一点理解其实就是根据某个偏移取到了内存空间中的某个值,这个值从哪里来其实我们目前暂时没办法确定,在ida的反汇编中,他的呈现是这样的ADRL X0, unk_26E1BC,在一个未处理字,暂时推测是某个代码块中应该向其赋了值。

IDA根据此地址跳转,发现找到了上一层调用。


对旅行APP的检测以及参数计算分析【Simplesign篇】

sub_EFC8C函数我们查找交叉引用,发现只有一个函数调用了它 -> sub_F10C0, 0xF10C0的交叉引用我们发现他的上一层其实就是我们的sub_7D4B4。至此,整条simplesign的大体执行流程我们已经基本了解了,现在开始详细的解析simplesign是如何生成的。

3.2 详细解剖前32位是如何组成的


上面的快速预览中,我们知道了前32位的前置在sub_EFC8C中调用了sub_ECDE4函数,其中有两个参数,第一个就是我们trace中那一个64位的字符串,第二个呢?


v7 = qword_270030(10L)如果我们点击进去发现并没有什么,因为他是一个数据段,我们点击qword_270030再点击X会发现他其实是指向的是某个函数,这里我们发现他是在so init时候进行了定义。

qword_270030 = (__int64 (__fastcall *)(_QWORD))dlsym(handle, "malloc"); qword_270038 = (__int64)dlsym(handle, "calloc"); qword_270028 = (__int64 (__fastcall *)(_QWORD))dlsym(handle, "free"); qword_270040 = (__int64 (__fastcall *)(_QWORD, _QWORD))dlsym(handle, "realloc");

那么这里的270030就代表了malloc,申请了一块长度为10的内存空间。

3.2.1 分析sub_ECDE4

大致整理了一下,我们看图说。
对旅行APP的检测以及参数计算分析【Simplesign篇】
大致如图所示,需要关注的是v17 = sub_D0404("f0e1d2c3b4a59687", 128LL, v22)。

这里不详细分析,因为我们看到传入了3个参数,第一个是f0e1d2c3b4a59687,第二个是128,第三个是v22。

第一个参数其实就是个固定值,推测跟版本有关,第二个长度,第三个传入的v22,是决定前32位计算的重要参数,但是我们可以偷个懒,发现前两个参数是固定的,v22用作存储计算后的一个地址指针。所以他的值是固定的,他的计算是通过第一个参数来变换的。这一块还原计算流程也不难,就不占用篇幅了。

3.2.2 sub_D1DB4


直接看图


对旅行APP的检测以及参数计算分析【Simplesign篇】
试试用python还原一下。


对旅行APP的检测以及参数计算分析【Simplesign篇】

与trace的结果一致。


分析第33-40位
老样子,根据我们得到的simplesign的第33-40位去trace日志中搜索,得到了ldr x0, [sp, #0xf8] ; x0 = 0x34 --> 0x7189db0d6c (3469dc64E0AA3D74F268AE*****************),但是我们无法找到计算或者生成的地方,但是我们之前说过有怀疑这里是时间戳,那么我们对其进行转换,转换成10进制然后再时间戳转换试试,具体过程不细说了,直接说结果,转换的10进制并不符合时间戳,因为在这里要处理端续,转换成0x64dc6934再去匹配发现转换成时间戳就对得上我们trace的时间了。

这块其实是syscall了gettimeofday出来的,可以自行看一下,不多赘述。

4.1 41-43位

至于12C的生成,后续会详细说明。


后32位的逻辑
我们继续假设后32位跟前32位一样的逻辑,进行拆分查找,日志搜索前8位,0x825B340C。

搜索到日志的第一条 libscmain.so eef28 ldur x11, [x29, #-0x10] ; x11 = 0x7189db0d40 --> 0x716d81ec00 (825b340c)

汇编指令ldur,证明是从内存中读取出来了,那么说明我们这个思路可能不正确,可以试试搜索825b发现也是一样,都是出现在了0xeef28位置上,那么我们就需要去分析一下,此位置是一个什么样的结构或者功能。


对旅行APP的检测以及参数计算分析【Simplesign篇】

很清晰明了,我们去逆推v3 -> v4 -> v8 -> result = param1(第一个参数)。


X键查看sub_EEE38的交叉引用,发现其恰好都在我们上一级sub_F10C0中,花一分钟去trace日志,我们基本可以定位到具体哪里调用了eee38。


对旅行APP的检测以及参数计算分析【Simplesign篇】

定位最后一个sub_EEE38的param1 ->v32,观察其规律,发现sub_F0E04中有关联,我们试着用frida看一下v32的变化。


对旅行APP的检测以及参数计算分析【Simplesign篇】

因为我这图是后补的,所以后32位生成的值与上面不一样,我们只需要看不同的地方,由图可知,sub_F0E04在调用的时候,a1的值应该就是后32位的值了,但是函数执行结束时,a1的值是有变化的,而变化后的值恰恰就是最终生成的simplesign的后32位。那么我们假设,后32位计算后,会经过f0e04这个函数对后10位进行了某些变化。

我们先去分析后32位是怎么生成的再去研究这后10位的变化逻辑。

5.1 后32位的生成过程

我们接着看sub_F10C0,观察v32的轨迹,在IDA中我们观察v32并没有操作什么,那么问题很有可能出在了上一篇中,scmain存在的花指令混淆的原因,试着去修复会很费时间,有没有其他方式能展现出各函数的执行流程呢?我们试一下Binary Ninja去反汇编,看看能不能比IDA展示的更好。

Binary Ninja打开scmain会消耗一段时间,这期间不要管。我们看下结果。


对旅行APP的检测以及参数计算分析【Simplesign篇】

Binary Ninja 的sub_f0f0c-> IDA的sub_F0E04
Binary Ninja 的sub_F77A4-> IDA的sub_F2794(Binary Ninja识别出了跳转)
为了防止阅读出现混乱,我依旧以IDA的反汇编来分析流程。

5.2 sub_F77A4 (Binary Ninja)


IDA无法对sub_F2794进行有效的反编译,所以我们使用Binary Ninja来分析。

通过Binary Ninja (后续简称BN)分析,sub_F0E04的参数来自sub_F77A4的第三个参数(param3),而且param3在BN中也没有发现有其他函数参与修改、计算,那么我们推测,F77A4是计算后32位的函数,点击进入。


对旅行APP的检测以及参数计算分析【Simplesign篇】

是不是有眼前一亮的感脚,明文的16进制是不是很像MD5中的K表,还有位移数数量也不多不少,正好64个。

看一眼Graph。


对旅行APP的检测以及参数计算分析【Simplesign篇】

硬肝控制流对于我们来说没有任何好处与意义。因为我们是新手教程,所以就使用最简单有效的方式。

前8位,
825B340C因为我们知道了后面是由MD5生成的,所以端续我们可以确定,去trace日志搜索0xC345B82,第一条结果。


对旅行APP的检测以及参数计算分析【Simplesign篇】

定位汇编指令位置0x1041b4,在BNG输入跳转,发现会跳转到函数头部,因为BN的逻辑跟IDA不太一样,定位不到具体变量或者参数的位置,以结果所在的寄存器为地址,那么我们试试将我们的指令地址+4或者-4。

001041b0 int32_t x18_75 = ror.d(x8_1091 + 0x70363da3 + x13_196 + ((x13_367 | not.d(x9_673)) ^ x8_1070), 0x1a) + x13_367

至此,我们定位到了MD5结果的A所在的位置。

我们知道算法的代码了,SV也知道了,但是我们还没有得到
入参以及初始化ABCD(魔数),试着在MD5第一行计算中找规律,因为A、B、C、D一定会参与到前4行的运算中。

int32_t x8_1104 = ror.d(x19_10 + 0x500fe759 + (((var_158.d ^ var_168.d) & var_170.d) ^ var_268.d) + var_178.d, 0x19) + var_270.d int32_t x9_810 = ror.d(x8_330 + 0x6fa2f477 + var_158.d + (((var_168.d ^ var_170.d) & x8_1104) ^ var_168.d), 0x14) + x8_1104 int32_t x0_127 = ror.d(x0_34 - 0x5cbacc06 + var_168.d + (((var_170.d ^ x8_1104) & x9_810) ^ var_170.d), 0xf) + x9_810 int32_t x8_1220 = ror.d(x18_156 + 0x46d88dcf + var_170.d + ((x9_810 & x0_127) | (x8_1104 & not.d(x0_127))), 0xa) + x0_127

我们可以看到,每一行的结果都会放到下一条计算逻辑的最后去相加。

我们梳理一下前两行相加计算的逻辑。

line1 = ror( x_19 + 0x500fe759 + var_178 + ((var_158 ^ var_168) & var_170) ^ var_268 , 0x19) + var_170(var_270=var_170)
通过trace日志,或者直接看反汇编,我们知道x_19就是传入的参数M[0],继续简化公式。

line1=ror(M[0]+k[0]+A+(异或与运算),移位数)+魔数之一
后面的第二行——第四行,我们就可以知道四个魔数对应的变量,通过trace日志可知道其值。四个魔数变量分别是var_178,var_268 = var_158,var270 = var_170,var_168。

可是我们在当前的if分支中,并没有找到var_178var_168。
根据汇编指令流,分析当前if分支的第一行运行结果的计算过程,可以得到var_178的值,在trace日志中搜索得到如下内容,我们跳转到了另一个分支中。


对旅行APP的检测以及参数计算分析【Simplesign篇】
(请无视我的备注,那是还原算法时,做对比用的)
我们发现刚才的MD5的魔数是另一个MD5(我们简称MD5_A)的倒数第4行的计算结果。

那我们是否可以假设,MD5_A的最后四行的结果就是我们之前MD5(简称MD5_B)的魔数呢?

用trace日志做一下验证。

我们发现,MD5_B的魔数是由MD5_A的结果与MD5_A的初始魔数相加而成得,而且MD5_A的计算逻辑与K表以及移位数都是一样的,推断两个MD5的算法是相同的。那么我们先去找MD5_A的魔数来源,根据MD5_A分支,我们推倒出A、B、C、D四个魔数对应的变量值,再去找赋值的来源,发现了一个变量
var_e0,继续逆推。


对旅行APP的检测以及参数计算分析【Simplesign篇】

data_24c0c0值得我们关注。


对旅行APP的检测以及参数计算分析【Simplesign篇】

恰好与我们MD5_A的魔数一模一样。

完事具备,就差还原了。具体细节闲下来我会在文章内补充,直接看结果。


对旅行APP的检测以及参数计算分析【Simplesign篇】

第一行为MD5_A的结果,也就是MD5_B的四个魔数。

第二行为MD5_B的结果,与trace的后32位的前22位完全匹配。

注意!这里有一个问题,最后的结果不一定是后面多少位会变化,这个具体原因后面会详细讲。


对旅行APP的检测以及参数计算分析【Simplesign篇】

至于推导的过程,我建议新手朋友自己动手,能再最大程度上加深印象。

下一步我们要继续向上推,因为我们目前还不知道参数是什么。

通过使用BN与IDA的观察,F77A4的上一个函数
sub_F01AC的param2 对应sub_F77A4的param1, F01AC的param3对应F77A4的param2。

通过frida hook,我们可以大概得了解到这几个函数参数的对应关系。


对旅行APP的检测以及参数计算分析【Simplesign篇】


5.3 sub_F10AC


此函数的参数param1+76处,作为一个计算控制器,给参与计算的v6赋值,0xAB或者0xCD。还原起来没有什么难度。直接上结果。


对旅行APP的检测以及参数计算分析【Simplesign篇】


5.4 sub_167424

此函数是一个非常关键的函数,个人觉得花费的时间比MD5要长,如图:对旅行APP的检测以及参数计算分析【Simplesign篇】

小白方法,就是按照顺序与trace日志做辅助分析,并且根据trace的顺序行数在ida对应的指令上做记录。
对旅行APP的检测以及参数计算分析【Simplesign篇】

跟着流程做对应的还原。


对旅行APP的检测以及参数计算分析【Simplesign篇】
对旅行APP的检测以及参数计算分析【Simplesign篇】

8个变量对应了sub_167424函数结束时的param3对应地址的内容。


对旅行APP的检测以及参数计算分析【Simplesign篇】

param1与param2不变,param3在函数结束时内容被填充,然后在后续的指令中,param3经过了序列化后将地址指针赋给了v21,v21作为刚才讲的sub_F01AC的入参param1进行了运算。

167424前面得F01AC函数就比较简单了,其实就是F10C0传入的参数,也就是SimpleSign的那一串字节数组。

总结一下流程就是

SimpleSign入参 -> F01AC(SimpleSign字节数组作为参数) -> 167424 -> F01AC 再计算一次 -> F77A4 MD5计算生成后32位

5.5 sub_F0E04 及其重要的一个校验点

首先,这个函数中有几个内存段需要先行知晓,例如qword_26FD40qword_26FE38byte_26E010等,因为这些地址的内容中有一些是在so init时赋值,有一些是其他环境影响内容变换,所以,要搞清楚这些是做什么的,怎么做的,才能决定最后16位的内容是怎样的。

先给出我的so的备注大概了解一下。


对旅行APP的检测以及参数计算分析【Simplesign篇】
simplesign最后这16位的组成其实是前8位是当前时间与JNI_OnLoad的时间差的十六进制,高位为0则为0,与原simplesign计算的后16位的前8为逐个异或。

第9-10、11-12则为一个固定数(目前看来)是与0x00和0xff的异或
13-14是取决于
byte_26E010是否有改动。

15-16则是一个计算公式
v18[7] = (v9 << 7) + 8 * v10 + 4 * v11 + 2 * v12 + v13;

5.5.1 时间差

根据分析sub_ED574我们得知,此函数的结果是由获取当前time再减去qword_26FD40得到的。

我们使用IDA的查找交叉引用功能,发现其是在
JNI_OnLoad时被写入了内容。

5.5.2 qword_26FE38


依旧使用上面的方式查看交叉引用,发现STR操作也在JNI_OnLoad中,赋值了255L,那么其内容为0xff。

5.5.3 byte_26E010

默认值是0x2C,但是有几处涉及到更改,后续我们再说。
可能下一篇帖子是补充说明,也可能是bncode。

对旅行APP的检测以及参数计算分析【Simplesign篇】

看雪ID:我是红领巾

https://bbs.kanxue.com/user-home-839701.htm

原文始发于微信公众号(看雪学苑):对旅行APP的检测以及参数计算分析【Simplesign篇】

  • 左青龙
  • 微信扫一扫
  • weinxin
  • 右白虎
  • 微信扫一扫
  • weinxin
admin
  • 本文由 发表于 2024年3月3日04:33:18
  • 转载请保留本文链接(CN-SEC中文网:感谢原作者辛苦付出):
                   对旅行APP的检测以及参数计算分析【Simplesign篇】https://cn-sec.com/archives/2541743.html

发表评论

匿名网友 填写信息