点击上方↑↑↑蓝字[协议分析与还原]关注我们
“ 解密uc浏览器的安全代理流量，看看是不是真安全。”
作为一个从上古网络时代过来的人，一定对UC浏览器有深刻印象，它的流量透明代理功能，就是现在的云加速功能，使用UC的服务器作为访问各个页面的代理，并且对流量进行压缩，在早期网络环境下，很大程度地解决了广大人民的省流量、上网快的重要需求，和Opera有得一拼。后来，随着互联网的发展，UC浏览器被收归阿里巴巴旗下，各大小巨头纷纷推出自己的浏览器产品，各家浏览器基本都加入了流量代理功能，虽然4G建设取得了很多成就，网速得到了极大提高，但它们都号称是在进行流量的加速，让你用得更爽，至于流量从它们的服务器过一道到底是为了加速还是减速或者其它的啥，我也不知道啊。再后来，就有些人走路走歪了，号称流量经过他们的服务器的云加密服务，变得更安全了，在访问一些网页的时候，会有类似“已为您开启云加密服务”的提示，让人心里暖暖的，恨不得立马和它分享我心中的一切，没错，我说的是UC浏览器。不知道这个提示现在还有没有。我一直不明白，我和相好的网站进行隐秘互动，第三者在中间横插一杠，从它那这走一趟，就会更安全，这是什么道理？光阴似箭，岁月如梭，不知UC的这个功能还在不在，大概率在，不知道这个提示还在不在，可能不在了，毕竟这个提示一没卖点，二来扰民。在这里，我们从流量的角度来分析这个UC浏览器的号称安全的流量代理功能的加密情况，看看是否能够解密。不过，这是很早之前分析的，可能已经过期了，大家不妨抓个最新版本的流量来比对下。当然，这里首先告诉你，这个UC服务器加密的流量是可以解密的，是不安全的，你相好的网站如果么有加密，那么uc服务器代理过后，你仍然是在裸奔，只是多了个第三方——UC的服务器，来欣赏你裸奔的流量了。01
—流量首先，我们从直观上来看下UC产生的流量，直接过滤HTTP，一眼看去，很多呀，都是和UC的服务器的交互，看样子这个浏览器并不怎么省流量呀，打开一个网页省下的那么一点点流量，都用在浏览器它自己身上了：不要慌，这些uc相关的流量大部分是加密过的HTTP，虽然都是能解的那种。不过，今天我们只关心HTTP流量里面经过代理服务器的流量，也就是我们在使用UC浏览器上网时被UC的服务器代理过一道的流量。代理服务器的流量使用的域名是类似vs12.bjct.u3.ucweb.com的系列，端口为8080：流量确实加密了吧。都是乱码诶，看不懂诶，没关系，下面一步步来把它解出来。至于这个域名是哪里得到的，在启动时相关的流量里，稍微加了点密，很简单，留给大家去分析。本来准备写下具体的分析过程，但是，我不记得怎么分析的了，反正一般都是调试加hook啦，所以老规矩，直接上分析结果。02
—解密UC代理流量的加密实现，印象中在libmissile.so这个库中，而不是在libsgmain.so这个库里，大家感兴趣可以去调调。
UC代理流量的加密，核心是一段异或加密，直接IDA反编译拎出来是下面这段：
signed int __fastcall sub_3F214(int a1, int a2, void *a3, signed int *a4){int v4; // r6@1signed int *v5; // r8@1void *v6; // r7@1signed int v7; // r2@1int v8; // r9@1signed int v9; // r5@2char v10; // r2@2char v11; // r3@4signed int result; // r0@5int v13; // [sp+4h] [bp-2Ch]@1signed int v14; // [sp+8h] [bp-28h]@1signed int *v15; // [sp+Ch] [bp-24h]@1char v16; // [sp+10h] [bp-20h]@4v13 = a2;v14 = (signed int)a3;v15 = a4;v4 = a2;v5 = a4;v6 = a3;v7 = *a4;v8 = a1;v15 = (signed int *)_stack_chk_guard;if ( a2 + 1 >= v7 ){result = -2;}else{memset(v6, 0, v7);v9 = 0;v13 = -;v14 = -;v10 = 0;while ( v9 < v4 ){v11 = *(_BYTE *)(v8 + v9);v10 ^= v11;*((_BYTE *)v6 + v9) = *(&v16 + v9 % 8 - 12) ^ v11;++v9;}result = 0;*((_BYTE *)v6 + v4) = v13 ^ v10;*((_BYTE *)v6 + v4 + 1) = v10 ^ BYTE1(v13);*v5 = v4 + 2;}if ( v15 != (signed int *)_stack_chk_guard )_stack_chk_fail(result);return result;}看着很烦，其实就是循环异或，异或的密钥key为8字节数组“0xee,0xb9,0xe9,0xb3,0x81,0x8e,0x97,0xa7”，想动手的朋友可以直接去实现啦，当然，还需要注意，数据体的前6字节是相对固定的数据，跟解密后的数据类型有关，不用拿来异或解密的。不过，这一步解出来的，有些内容你能看到信息，比如一些规律的HTTP相关的ASCII字符，但这些并不是最终结果，后面的处理还是蛮麻烦的。异或解密出的结果分成多种情况，包括deflate字典压缩，差分压缩，以及正常数据几个类别，可以根据起始字节的值来区分，当然，你得熟悉相关的编码格式。例如，deflate压缩的数据格式，有什么明显的标记，这里给大家留个作业，有兴趣的可以去查查啦。这里的deflate压缩是字典压缩，是有一个字典的，字典有2259字节，贴出来太暴力了，还是有需要的自己去调或者找我要吧。正常数据和差分压缩数据，在下一节继续。03
—差分正常数据和差分压缩数据的格式的区别在于异或解密后的起始字节是0xa0还是0xad，例如下面这段解密后数据，就是差分压缩的：00h: AD 00 18 31 40 34 69 69 75 58 6F 54 36 40 56 6E ; ?.1@4iiuXoT6@Vn10h: 47 75 7A 73 51 6C 40 31 30 33 30 D6 C3 C4 00 00 ; GuzsQl@1030置?.20h: 01 88 06 00 3F 88 06 00 2F 07 03 32 30 31 35 2F ; .?.??./..2015/它是有格式的，毕竟，差分压缩，你得知道每个数据是和谁差分的对不对。这些信息，就在数据格式里写好了，继续用上面的数据来说明，这里面，4iiuXoT6是一段base64，VnGuzsQl是另一段base64，这两个base64是数据id值，同时具备数据校验的作用，其中后面一个是当前数据段的数据id，前面一个是与本数据段关联的差分基础数据段的数据id。而字符串1030是本段的原始数据的长度值，再之后，紧接着的就是差分数据。原始数据需要用这里的差分数据和关联数据id对应的原始数据进行差分获得，怎么差分?当然是用成熟的差分库实现啦，例如，c里面有xdelta3库，下载下来就可以用了。前面的数据id，作为对原始数据校验的作用，这里描述一下，大家将就着理解：对原始数据取MD5值（16字节hex形式），然后取前6字节，再进行base64，则得到这段base64。例如，文件的MD5是：792A2778BEB113F6D7B27B278
则取hex值 79 2A 27 78 BE 96，base64编码得到 eSoneL6W 即为id。
04
—结束UC代理流量加密的基本的算法，这里介绍完了，够干吧，大家还愣着干嘛，赶紧分享吧，给我点鼓励。
这个UC代理的流量，确实加密了，不过可以解密，大家上不好的网站，还是少用它啦。
别忘点“在看”、“赞”和“分享”新的规则，及时收推文要先给公号星标别忘了星标一下，不然就错过了长按进行关注，时刻进行交流。