Android逆向攻防-某redbook shield值破解

作者：yueji0j1anke

首发于公号：剑客古月的安全屋

字数：1449

阅读时间:    15min

声明：请勿利用文章内的相关技术从事非法测试，由于传播、利用此文所提供的信息而造成的任何直接或者间接的后果及损失，均由使用者本人负责，文章作者不为此承担任何责任。合法渗透，本文章内容纯属虚构，如遇巧合，纯属意外

目录

• 前言

• 初步分析

• unidbg补环境

• 总结

0x00 前言

本期用unidbg补算法，着重讲补环境过程

受害者是 red shield值

版本 v6.8.3

相关frida绕过不在这里讲解

0x01 初步分析

可以发现，shield值都带有固定前缀 XYAAAAAQAAAAEAAABTAAAA

这里我用jadx反编译了一下，找不到shield生成关键点。。不出意外，肯定是在so文件中生成的

这里可以用字符串hook法

functionhook_shiled() {varsymbols=Module.enumerateSymbolsSync("libart.so");varaddrNewStringUTF=null;for (vari=0; i<symbols.length; i++) {varsymbol=symbols[i];if (symbol.name.indexOf("NewStringUTF") >=0&&symbol.name.indexOf("CheckJNI") <0) {addrNewStringUTF=symbol.address;console.log("生成 NewStringUTF at ", symbol.address, symbol.name);break        }    }if (addrNewStringUTF!=null) {Interceptor.attach(addrNewStringUTF, {onEnter: function (args) {varc_string=args[1];vardataString=c_string.readCString();if (dataString) {if (dataString.indexOf("XYAAAAA") !==-1) {console.log(dataString);console.log(Thread.backtrace(this.context, Backtracer.ACCURATE).map(DebugSymbol.fromAddress).join('n') +'n');console.log(Java.use("android.util.Log").getStackTraceString(Java.use("java.lang.Throwable").$new()));                    }                }            }        });    }}

最终定位到 

libshield.so文件

对应的堆栈信息

打开jadx，追到这里

native方法，so层逻辑可能就在里面

这里为一个拦截器，使用的是目前主流okhttp框架，其可以在请求发出前或者响应到达后进行处理，比如addheaders()

而Interceptor.Chain，代表的是拦截器链中的当前请求和响应的上下文

这里我们可以hook一下看看这里传入的参数是否带有shield值

 var request = chain.request(); console.log("url-> ", request.url().toString()); console.log("headers-> ", request.headers().toString());

可以看到，没有相关shield值，那shield应该就是在该native方法中内部生成的了

（自信满满）

当然你也可以尝试hook下一个拦截器

var Builder = Java.use('okhttp3.OkHttpClient$Builder');Builder.addInterceptor.implementation = function (inter) {        console.log(JSON.stringify(inter) );        return this.addInterceptor(inter);    };

这里可以尝试去hook所有拦截器，找到下一个拦截器的header里面是否存在shield

0x02 unidbg补环境

三个native方法

肯定会先涉及到初始化等操作，开补

1.initializeNative()

第一次运行我是这样的

顺着这个就开始补环境

下面讲述关键点

sDeviceId

functionhook_sDeviceId(){Java.perform(function() {letContextHolder=Java.use("com.xingin.shield.http.ContextHolder");console.log('sAppId=',ContextHolder.sAppId.value);console.log('sDeviceId=',ContextHolder.sDeviceId.value);console.log('sExperiment=',ContextHolder.sExperiment.value);    })}

hook出来如下

sAppId= -319115519 sDeviceId= d954acxxxxxx Experiment= true

这是补initializeNative()的关键点

2.initialize(String str)

接下来补initialize()

这里需要分析一下对应传入的参数是什么

这里看偏移地址

hook一下native方法，记得延迟hook

发现传入的参数是 main

继续开补

这里存在获取xml文件的上下文相关，先补一个空，看看后续日志

发现需要补getString方法了，读取s.xml文件的值，并获取

日志输出，那我们到对应xml文件中找main键

发现不存在main键，但存在main_hmac键，那就顺带补上

接下来补base64

这里补完 initialize 就告一断落

3.Interceptor

运行

需要补okhttp，倒入依赖即可

<dependency>    <groupId>com.squareup.okhttp3</groupId>    <artifactId>okhttp</artifactId>    <version>3.4.2</version></dependency>

运行

发现需要返回一个Request

那就补充一个全局变量，方便后续补环境

接下来补okhttp的一些基本url属性

随后发现需要引入okio的依赖

 <dependency>      <groupId>com.squareup.okio</groupId>      <artifactId>okio</artifactId>      <version>2.8.0</version> </dependency>

然后常规补即可

这里存在一些空指针错误，建议用try catch逻辑去进行补充

这是我导出shield的逻辑

最后进行校验

一致，补环境验签绕过成功

0x03 总结

本期值得总结的点

1.延迟hook

2.hook 字符串

3.如何补第三方依赖

后期将为大家带来纯算 算法分析

参考文章 https://hyb.life/archives/205

原文始发于微信公众号（剑客古月的安全屋）：Android逆向攻防-某redbook shield值破解