某A系电商App x-sign签名分析

简介: 某A系电商App x-sign签名分析

一、目标


前不久(我去,都大半年了)分析过 某二手电商App x-sign签名分析 类成员变量的分析 我们找到了几个伪装成so的jar包。


虽然rpc调用ok了,但是它的实际运算过程还是在so里面的。


今天我们从它们同族的App来入手,利用Native层字符串定位的方式来定位下在哪个so中去做的运算。


App版本: v4.15.143.png


二、步骤

特征字符串定位


一开始选择的特征字符串是 x- ,后来发现没有 x-sign 好使

Interceptor.attach(addrGetStringUTFChars, {
    onEnter: function (args) {},
    onLeave: function (retval) {
        if (retval != null) {
            var bytes = Memory.readCString(retval);
            if(bytes != null) {
                if(bytes.toString().indexOf("x-sign") >= 0 )
                {
                    console.log("[GetStringUTFChars] result:" + bytes);
                    var threadef = Java.use('java.lang.Thread');
                    var threadinstance = threadef.$new();
                    var stack = threadinstance.currentThread().getStackTrace();
                    console.log("Rc Full call stack:" + Where(stack));
                    // Native 层 堆栈
                    console.log(Thread.backtrace(this.context, Backtracer.FUZZY)
                    .map(DebugSymbol.fromAddress).join("\n"))
                }
            }
        }
    }
});


跑一下

[NewStringUTF] bytes:x-sign
Rc Full call stack:dalvik.system.VMStack.getThreadStackTrace(Native Method)
 tt: java.lang.Thread.getStackTrace(Thread.java:1538)
 tt: com.txxxao.wireless.security.adapter.JNICLibrary.doCommandNative(Native Method)
 tt: com.axxbxxx.wireless.security.mainplugin.а.doCommand(Unknown Source:0)
 tt: com.axxbxxx.wireless.security.middletierplugin.c.d.a.a(Unknown Source:280)
 tt: com.axxbxxx.wireless.security.middletierplugin.c.d.a$a.invoke(Unknown Source:56)
 tt: java.lang.reflect.Proxy.invoke(Proxy.java:913)
 tt: $Proxy12.getSecurityFactors(Unknown Source)
 tt: mtopsdk.security.d.a(lt:620)
 tt: mtopsdk.mtop.a.a.a.a.a(lt:218)
 tt: mtopsdk.framework.a.b.d.b(lt:45)
 tt: mtopsdk.framework.b.a.a.a(lt:60)
0xcb434e10 libsgmiddletierso-6.5.50.so!0x33e10
0xcb404e28 libsgmiddletierso-6.5.50.so!0x3e28
0xc9dd5536 libsgmainso-6.5.49.so!0x10536
0xc9dd71c8 libsgmainso-6.5.49.so!0x121c8
0xf365607a libart.so!art_quick_generic_jni_trampoline+0x29
0xf364068a libart.so!MterpAddHotnessBatch+0x29
0xf3651b76 libart.so!art_quick_invoke_stub_internal+0x45


有之前分析的基础,我们在java层的堆栈,重点关注


com.axxbxxx.wireless.security.middletierplugin.c.d.a.a 这个类,  Native层的堆栈就必须是 libsgmiddletierso-6.5.50.so 和  libsgmainso-6.5.49.so


缩小范围


jadx打开apk,搜索一下 com.axxbxxx.wireless.security.middletierplugin.c.d.a.a, 奇怪,这个类搜不到。


某二手电商App x-sign签名分析 类成员变量的分析 的文章里面,我们是通过 类成员变量的分析来定位的。现在我们知道了 这个类大概率是在那两个假的so里面44.png

是的,他俩是假的so,本质上是 jar包, jadx伺候

45.png


libsgmiddletier.so 这个jar包里面找到了。


上Frida

var signCls = Java.use('com.axxbxxx.wireless.security.middletierplugin.c.d.a');
signCls.a.implementation = function(a){
    console.log(">>> sign = " + a);     
    var retval = this.a(a);
    console.log(">>> sign Rc = " + retval);     
    return retval;      
}


跑一下,提示这个类找不到?


为啥找不到? 因为这个jar包是动态加载的,所以他的Classloader是不同的,不能使用默认的。


Hook 动态加载的类

先要遍历一下所有的ClassLoader

Java.enumerateClassLoaders({
    "onMatch": function(loader) {
        console.log(loader);
    },
    "onComplete": function() {
        console.log("success");
    }
});

47.png


没毛病就是它了。


指定 ClassLoader

Java.enumerateClassLoaders({
    "onMatch": function(loader) {
        if (loader.toString().indexOf("libsgmiddletier.so") > 0 ) {
            Java.classFactory.loader = loader; // 将当前class factory中的loader指定为我们需要的
        }
    },
    "onComplete": function() {
        console.log("success");
    }
});
// 此处需要使用 Java.classFactory.use
var  signCls =  Java.classFactory.use('com.axxbxxx.wireless.security.middletierplugin.c.d.a');
signCls.a.overload('java.util.HashMap').implementation = function(a){
    var retval = this.a(a);
    console.log(" #### >>> a = " + a.entrySet().toArray());
    console.log(" #### >>> rc= " + retval.entrySet().toArray());
    var stack = threadinstance.currentThread().getStackTrace();
    console.log("#### >>> Rc Full call stack:" + Where(stack));
    return retval;
}


再跑一下,这下Ok了

49.png

三、总结

我们找到了最接近的jave层的接口,也找到了so中对应的函数,但是要继续分析这个so还是需要费不少功夫的。


frida提示找不到类的时候不要慌,遍历大法好。49.png


每当年关将至,总会想起刘瑜这段话———— 忙,却似乎也没忙成什么,时间被碾得如此之碎,一阵风吹过,稀里哗啦全都不知去向,以至于我试图回想这一年到底干了些什么,发现自己简直是从一场昏迷中醒来。


TIP: 本文的目的只有一个就是学习更多的逆向技巧和思路,如果有人利用本文技术去进行非法商业获取利益带来的法律责任都是操作者自己承担,和本文以及作者没关系,本文涉及到的代码项目可以去 奋飞的朋友们 知识星球自取,欢迎加入知识星球一起学习探讨技术。有问题可以加我wx: fenfei331 讨论下。


关注微信公众号: 奋飞安全,最新技术干货实时推送


相关文章
|
4月前
|
搜索推荐 开发工具 UED
apptrace 三大策略,助力电商 App 在 618 突围​
随着“618”电商大促预售开启,各大平台投入百亿流量与现金争夺用户。然而,网络购物市场增量空间趋于饱和,电商App亟需突破曝光、拉新与转化瓶颈。apptrace提供三大增长策略:精准曝光通过智能广告监测优化投放;裂变拉新简化流程,助力社交传播;高效转化实现一键直达活动页面,提升用户体验与留存率。这些技术优势助力开发者和运营者在618大战中抢占先机,实现用户增长与商业价值最大化。
|
3月前
|
JavaScript
TypeOrmModule 从 app.module.ts 抽离到 database.module.ts 后出现错误的原因分析
本文分析了TypeORM实体元数据错误的成因,主要涉及实体注册方式、路径解析差异及模块结构变化导致的关系解析问题,并提供了具体解决方案和最佳实践建议。
120 56
|
1月前
|
数据采集 数据可视化 API
驱动业务决策:基于Python的App用户行为分析与可视化方案
驱动业务决策:基于Python的App用户行为分析与可视化方案
|
6月前
|
安全 算法 小程序
【03】微信支付商户申请下户到配置完整流程-微信开放平台创建APP应用-填写上传基础资料-生成安卓证书-获取Apk签名-申请+配置完整流程-优雅草卓伊凡
【03】微信支付商户申请下户到配置完整流程-微信开放平台创建APP应用-填写上传基础资料-生成安卓证书-获取Apk签名-申请+配置完整流程-优雅草卓伊凡
369 28
【03】微信支付商户申请下户到配置完整流程-微信开放平台创建APP应用-填写上传基础资料-生成安卓证书-获取Apk签名-申请+配置完整流程-优雅草卓伊凡
|
5月前
|
数据采集 数据可视化 数据挖掘
基于Python的App流量大数据分析与可视化方案
基于Python的App流量大数据分析与可视化方案
|
6月前
|
监控 数据可视化 数据挖掘
【开发者必看—电商篇】数据赋能电商类App转化率循序增长
通过友盟+ 数据分析工具,团队深入分析了用户行为路径、转化漏斗、停留时间及错误事件等关键数据,定位到用户体验与产品性能的问题。经过精准优化,包括简化购物流程、修复技术故障及提升稳定性,最终显著提高了用户转化率。这一案例展示了数据驱动在产品优化中的重要作用。
【开发者必看—电商篇】数据赋能电商类App转化率循序增长
|
6月前
|
监控 搜索推荐 数据挖掘
【开发者必看—电商篇】数据赋能电商App活跃度重焕新生
通过友盟+数据分析工具的综合数据分析和个性化推送功能,解决APP用户活跃度迅速下降的问题。
|
2月前
|
人工智能 文字识别 小程序
旅游社用什么工具收报名 + 资料?不开发 App 也能自动收集信息
本文探讨了旅游行业中报名信息收集的常见痛点及解决方案,重点介绍了二维码表单工具在提升信息收集效率、简化操作流程方面的优势。通过对比多种工具,分析其适用场景与实际应用逻辑,为一线旅游从业者提供高效、低成本的执行参考。
|
3月前
|
容器
HarmonyOS NEXT仓颉开发语言实战案例:外卖App
仓颉语言实战分享,教你如何用仓颉开发外卖App界面。内容包括页面布局、导航栏自定义、搜索框实现、列表模块构建等,附完整代码示例。轻松掌握Scroll、List等组件使用技巧,提升HarmonyOS应用开发能力。

热门文章

最新文章