公告
Gentoo交流群:87709706 欢迎您的加入
#1 2022-10-12 12:19:10
linux源码解读（三十三）：android下boringSSL核心源码解析&x音防抓包证书校验原理
1、去年逆向x音15.5.0版本时，可以直接用fiddler抓包。后来貌似升级到17版本时fiddler就抓不到包了，看雪有大佬破解了x音防抓包的功能，原理并不复杂：boringssl源码中有个SSL_CTX_set_custom_verify函数，定义如下：
void SSL_CTX_set_custom_verify(
SSL_CTX *ctx, int mode,
enum ssl_verify_result_t (*callback)(SSL *ssl, uint8_t *out_alert)) {
ctx->verify_mode = mode;
ctx->custom_verify_callback = callback;
}（1）第二个mode参数就是验证client的关键参数了，有以下4种取值：
// SSL_VERIFY_NONE, on a client, verifies the server certificate but does not
// make errors fatal. The result may be checked with |SSL_get_verify_result|. On
// a server it does not request a client certificate. This is the default.
#define SSL_VERIFY_NONE 0x00
// SSL_VERIFY_PEER, on a client, makes server certificate errors fatal. On a
// server it requests a client certificate and makes errors fatal. However,
// anonymous clients are still allowed. See
// |SSL_VERIFY_FAIL_IF_NO_PEER_CERT|.
#define SSL_VERIFY_PEER 0x01
// SSL_VERIFY_FAIL_IF_NO_PEER_CERT configures a server to reject connections if
// the client declines to send a certificate. This flag must be used together
// with |SSL_VERIFY_PEER|, otherwise it won't work.
#define SSL_VERIFY_FAIL_IF_NO_PEER_CERT 0x02
// SSL_VERIFY_PEER_IF_NO_OBC configures a server to request a client certificate
// if and only if Channel ID is not negotiated.
#define SSL_VERIFY_PEER_IF_NO_OBC 0x04从注释就能看出：
0x00：client要验证server的证书，但是不会报错；server不会要求client提供证书，这也是默认的参数
0x01：client和server双方都要验证对方的证书，并且会报错
0x02：如果client不提供证书，server可以拒绝连接；这个取值要和SSL_VERIFY_PEER一起配合使用，否则无效
0x04：server向client索要证书
x音默认情况下不能抓包是因为这个参数取值不是0x00，所以直接用frida hook SSL_CTX_set_custom_verify这个函数，把第二个参数改成0x00即可！也可以直接找到libttboringssl.so的源码把第二个参数写死成0x00；
（2）第三个参数callback从名字看就知道是个回调函数，函数返回值ssl_verify_result_t取值如下：
enum ssl_verify_result_t BORINGSSL_ENUM_INT {
ssl_verify_ok,
ssl_verify_invalid,
ssl_verify_retry,
};从名字也能看出来返回值取第一个表示验证通过！直接通过hook把第三个参数改成0即可！如果觉得用frida hook麻烦，也可以在libsscronet.so偏移0x1CCBBE处，把“movs R0，1”改成“moves R0，0”即可！也就是把返回值从1改成0！
2、为了更好的逆向和ssl相关的功能（抓包、加解密等），有必要了解一些ssl的关键函数！
（1） 站在逆向的角度，我个人觉得最最最重要的就是SSL_write函数了，定义如下：从函数名和参数就能看出是从ssl发送buf的数据，发送长度是num！发送的数据存放在buf的，直接hook这个函数打印buf是不是就能看到网络数据了？
/*num字节从缓冲区buf写入指定的ssl连接*/
int SSL_write(SSL *ssl, const void *buf, int num) {
ssl_reset_error_state(ssl);
if (ssl->quic_method != nullptr) {
OPENSSL_PUT_ERROR(SSL, ERR_R_SHOULD_NOT_HAVE_BEEN_CALLED);
return -1;
}
if (ssl->do_handshake == NULL) {
OPENSSL_PUT_ERROR(SSL, SSL_R_UNINITIALIZED);
return -1;
}
int ret = 0;
bool needs_handshake = false;
do {
// If necessary, complete the handshake implicitly.
if (!ssl_can_write(ssl)) {//如果还不能通过这个ssl写数据
ret = SSL_do_handshake(ssl);//开始握手
if (ret < 0) {
return ret;
}
if (ret == 0) {
OPENSSL_PUT_ERROR(SSL, SSL_R_SSL_HANDSHAKE_FAILURE);
return -1;
}
}
//从这里发数据
ret = ssl->method->write_app_data(ssl, &needs_handshake,
(const uint8_t *)buf, num);
} while (needs_handshake);
return ret;
}（2）既然SSL_write是发数据的，SSL_read岂不就是读数据的？代码如下：
int SSL_read(SSL *ssl, void *buf, int num) {
int ret = SSL_peek(ssl, buf, num);
if (ret <= 0) {
return ret;
}
// TODO(davidben): In DTLS, should the rest of the record be discarded? DTLS
// is not a stream. See https://crbug.com/boringssl/65.
ssl->s3->pending_app_data =
ssl->s3->pending_app_data.subspan(static_cast<size_t>(ret));
if (ssl->s3->pending_app_data.empty()) {
ssl->s3->read_buffer.DiscardConsumed();
}
return ret;
}代码很简单，对于逆向人员来说，hook这两个函数是可以获取发送和接收数据的，也就是绕开了证书校验，对部分app是有用的！详细代码可以参考文章末尾第4个链接！
（3）通信双方最重要的莫过于密钥的协商了，handshake最重要的就是干这个的，整个方法如下；handshake内部最重要的又莫过于change_cipher_spec：为了保证安全，通信双方每隔一段时间就会改变加解密的参数！
int ssl_run_handshake(SSL_HANDSHAKE *hs, bool *out_early_return) {
SSL *const ssl = hs->ssl;
for (;;) {
// Resolve the operation the handshake was waiting on. Each condition may
// halt the handshake by returning, or continue executing if the handshake
// may immediately proceed. Cases which halt the handshake can clear
// |hs->wait| to re-enter the state machine on the next iteration, or leave
// it set to keep the condition sticky.
/*handshake等待时可能有很多种情况：*/
switch (hs->wait) {
case ssl_hs_error://报错提示
ERR_restore_state(hs->error.get());
return -1;
case ssl_hs_flush: {//刷新缓存？
int ret = ssl->method->flush_flight(ssl);
if (ret <= 0) {
return ret;
}
break;
}
case ssl_hs_read_server_hello:
case ssl_hs_read_message:
/*为保证安全，每隔一段时间就需要改变加解密参数*/
case ssl_hs_read_change_cipher_spec: {
if (ssl->quic_method) {//双方用quic协议
// QUIC has no ChangeCipherSpec messages.
//quic本身比较简单，就没有改变加解密参数的说法
assert(hs->wait != ssl_hs_read_change_cipher_spec);
// The caller should call |SSL_provide_quic_data|. Clear |hs->wait| so
// the handshake can check if there is sufficient data next iteration.
ssl->s3->rwstate = SSL_ERROR_WANT_READ;
hs->wait = ssl_hs_ok;
return -1;
}
uint8_t alert = SSL_AD_DECODE_ERROR;
size_t consumed = 0;
ssl_open_record_t ret;
//现在的状态是要改变加解密参数
if (hs->wait == ssl_hs_read_change_cipher_spec) {
//开始和对方协商改变加解密参数
ret = ssl_open_change_cipher_spec(ssl, &consumed, &alert,
ssl->s3->read_buffer.span());
} else {
/*否则重新handshake；其实handshake的本质就是协商加解密协议和参数，
目的和change_cipher_spec没本质区别*/
ret = ssl_open_handshake(ssl, &consumed, &alert,
ssl->s3->read_buffer.span());
}
if (ret == ssl_open_record_error &&
hs->wait == ssl_hs_read_server_hello) {
uint32_t err = ERR_peek_error();
if (ERR_GET_LIB(err) == ERR_LIB_SSL &&
ERR_GET_REASON(err) == SSL_R_SSLV3_ALERT_HANDSHAKE_FAILURE) {
// Add a dedicated error code to the queue for a handshake_failure
// alert in response to ClientHello. This matches NSS's client
// behavior and gives a better error on a (probable) failure to
// negotiate initial parameters. Note: this error code comes after
// the original one.
//
// See https://crbug.com/446505.
OPENSSL_PUT_ERROR(SSL, SSL_R_HANDSHAKE_FAILURE_ON_CLIENT_HELLO);
}
}
bool retry;
int bio_ret = ssl_handle_open_record(ssl, &retry, ret, consumed, alert);
if (bio_ret <= 0) {
return bio_ret;
}
if (retry) {
continue;
}
ssl->s3->read_buffer.DiscardConsumed();
break;
}
case ssl_hs_read_end_of_early_data: {
if (ssl->s3->hs->can_early_read) {
// While we are processing early data, the handshake returns early.
*out_early_return = true;
return 1;
}
hs->wait = ssl_hs_ok;
break;
}
case ssl_hs_certificate_selection_pending:
ssl->s3->rwstate = SSL_ERROR_PENDING_CERTIFICATE;
hs->wait = ssl_hs_ok;
return -1;
case ssl_hs_handoff:
ssl->s3->rwstate = SSL_ERROR_HANDOFF;
hs->wait = ssl_hs_ok;
return -1;
case ssl_hs_handback: {
int ret = ssl->method->flush_flight(ssl);
if (ret <= 0) {
return ret;
}
ssl->s3->rwstate = SSL_ERROR_HANDBACK;
hs->wait = ssl_hs_handback;
return -1;
}
// The following cases are associated with callback APIs which expect to
// be called each time the state machine runs. Thus they set |hs->wait|
// to |ssl_hs_ok| so that, next time, we re-enter the state machine and
// call the callback again.
case ssl_hs_x509_lookup:
ssl->s3->rwstate = SSL_ERROR_WANT_X509_LOOKUP;
hs->wait = ssl_hs_ok;
return -1;
case ssl_hs_private_key_operation:
ssl->s3->rwstate = SSL_ERROR_WANT_PRIVATE_KEY_OPERATION;
hs->wait = ssl_hs_ok;
return -1;
case ssl_hs_pending_session:
ssl->s3->rwstate = SSL_ERROR_PENDING_SESSION;
hs->wait = ssl_hs_ok;
return -1;
case ssl_hs_pending_ticket:
ssl->s3->rwstate = SSL_ERROR_PENDING_TICKET;
hs->wait = ssl_hs_ok;
return -1;
case ssl_hs_certificate_verify:
ssl->s3->rwstate = SSL_ERROR_WANT_CERTIFICATE_VERIFY;
hs->wait = ssl_hs_ok;//握手已成功
return -1;
case ssl_hs_early_data_rejected:
assert(ssl->s3->early_data_reason != ssl_early_data_unknown);
assert(!hs->can_early_write);
ssl->s3->rwstate = SSL_ERROR_EARLY_DATA_REJECTED;
return -1;
case ssl_hs_early_return:
if (!ssl->server) {
// On ECH reject, the handshake should never complete.
assert(ssl->s3->ech_status != ssl_ech_rejected);
}
*out_early_return = true;
hs->wait = ssl_hs_ok;
return 1;
case ssl_hs_hints_ready:
ssl->s3->rwstate = SSL_ERROR_HANDSHAKE_HINTS_READY;
return -1;
case ssl_hs_ok:
break;
}
// Run the state machine again.
hs->wait = ssl->do_handshake(hs);
if (hs->wait == ssl_hs_error) {
hs->error.reset(ERR_save_state());
return -1;
}
if (hs->wait == ssl_hs_ok) {
if (!ssl->server) {
// On ECH reject, the handshake should never complete.
assert(ssl->s3->ech_status != ssl_ech_rejected);
}
// The handshake has completed.
*out_early_return = false;
return 1;
}
// Otherwise, loop to the beginning and resolve what was blocking the
// handshake.
}
}（4）还有个很不起眼、容易被忽视的函数：
void SSL_CTX_set_keylog_callback(SSL_CTX *ctx,
void (*cb)(const SSL *ssl, const char *line)) {
ctx->keylog_callback = cb;
}从名字就能看出来是存放key日志的，里面记录的全是ssl协商的密钥！有了这些密钥，是不是就能解密双方通信的数据了？https://www.cnblogs.com/theseventhson/p/14618157.html 这是我之前在PC上用浏览器打开网页时做的操作，记录了ssl协议双方协商的密钥，然后wireshark就能用这些密钥解密数据了！但在android上默认是不记录这些的，需要手动hook来记录，js脚本代码如下：
function startTLSKeyLogger(SSL_CTX_new, SSL_CTX_set_keylog_callback) {
function keyLogger(ssl, line) {
console.log(new NativePointer(line).readCString());
}
const keyLogCallback = new NativeCallback(keyLogger, 'void', ['pointer', 'pointer']);
Interceptor.attach(SSL_CTX_new, {
onLeave: function(retval) {
const ssl = new NativePointer(retval);
const SSL_CTX_set_keylog_callbackFn = new NativeFunction(SSL_CTX_set_keylog_callback, 'void', ['pointer', 'pointer']);
SSL_CTX_set_keylog_callbackFn(ssl, keyLogCallback);
}
});
}
startTLSKeyLogger(
Module.findExportByName('libssl.so', 'SSL_CTX_new'),
Module.findExportByName('libssl.so', 'SSL_CTX_set_keylog_callback')
) 这是我hook x音的结果：
注意：这里抓的是libssl.so的keylog函数，也可以把libssl.so换成libttboringssl.so去获取x音的sslkey！具体操作方式可以参考文章末尾第6个！
参考：
1、https://bbs.pediy.com/thread-267940.htm android抓包整理归纳
2、https://onejane.github.io/2021/05/06/frida%E6%B2%99%E7%AE%B1%E8%87%AA%E5%90%90%E5%AE%9E%E7%8E%B0/#AOSP%E7%BD%91%E7%BB%9C%E5%BA%93%E8%87%AA%E5%90%90 frida沙箱自吐实现
3、https://bbs.pediy.com/thread-268014.htm 绕过非标准http框架和非系统ssl库app的sslpinning
4、https://blog.csdn.net/tzwsoho/article/details/119346275 [frida]拦截SSL_read/SSL_write函数获得HTTPS请求和响应
5、http://buaq.net/go-29171.html 关于抓包碎碎念
6、http://www.zhuoyue360.com/crack/73.html android硬核抓包
离线