首页
论坛
专栏
课程

[调试逆向] [原创]UC浏览器默认搜索引擎算法GetDigestString之签名寻踪

2018-8-13 16:13 2044

[调试逆向] [原创]UC浏览器默认搜索引擎算法GetDigestString之签名寻踪

2018-8-13 16:13
2044
UC浏览器默认搜索引擎算法GetDigestString之签名寻踪


 问题提出----------------------------:

        实际上uc浏览器市面还是不算广的,本来也没打算花很大力气折腾这个,但是突然之间聊天触发了一种方法的实验。只是拿uc浏览器练了手,实在对不住啊uc,不是故意的。请看下面的聊天记录:

UC浏览器默认搜索引擎算法GetDigestString之签名寻踪1
        
UC浏览器默认搜索引擎算法GetDigestString之签名寻踪2

然后最终确定的结果是:FLIRT signature只能识别字节码相似的,并且不支持动态链接库,相对来说比较鸡肋.

本来打算着手上文中的高级签名制作了,但是网上一搜,发现有老外大牛已经做过了,仔细看了一下文章,并用小程序做了下实验
实验的结果是:的确可行。而这个插件就叫做:
rizzo 作者介绍 devttys0.com/2014/10/a-code-signature-plugin-for-ida/
其实往往这种时候我总会想:为什么牛的东西都出在老外手里呢。而国内为什么没有呢?或许有,但是都私藏了。哎...省略一万字吧
突然一想,不是有UC浏览器还没搞定吗,为什么不拿来练下手。
我的思路如下:
        1:首先查看uc浏览器的chrome.dll的核心版本我的是55.0.2883.87,然后下载对应版本的也就是
55.0.2883.87版本的google chrome,然后拿到这个版本的google浏览器的chrome.dll.pdb
        2:将55.0.2883.87版本的google的chrom.dll和chrome.dll.pdb一起载入到ida,然后利用rizzo制作出chrome.riz签名文件。
        3:将55.0.2883.87版本的uc浏览器的chrome.dll载入到ida,分析完了之后,导入chrome.riz签名,自动去匹配符号。
        4:根据分析完的符号的去查找关键函数(有名称了) ,这样就能找到断点了,基本不用完全陌生的分析断点。
        5:根据断点动态调试,输出关键信息。
        6:码代码实现。

        




题外话----------------------------:

        我们不管ucbrowser,我们直接看google chrome浏览器,原因是:chrome开源,读代码或许能找到些须思路,关于代码下载也没那么简单,没个一两天想下载完门都没有,而且还得加代理,谁让被墙呢,一点办法都没,于是我们果断搜索,chrome.dll的hash检验关键代码如下:
内容如下:
// Copyright 2013 The Chromium Authors. All rights reserved.
// Use of this source code is governed by a BSD-style license that can be
// found in the LICENSE file.
#include "chrome/browser/prefs/pref_hash_calculator.h"
#include <vector>
#include "base/bind.h"
#include "base/json/json_string_value_serializer.h"
#include "base/logging.h"
#include "base/strings/string_number_conversions.h"
#include "base/strings/string_util.h"
#include "base/threading/thread_restrictions.h"
#include "base/values.h"
#include "chrome/browser/prefs/tracked/pref_hash_calculator_helper.h"
#include "crypto/hmac.h"
namespace {

// Calculates an HMAC of |message| using |key|, encoded as a hexadecimal string.
std::string GetDigestString(const std::string& key,const std::string& message) 
{
crypto::HMAC hmac(crypto::HMAC::SHA256);
std::vector<uint8> digest(hmac.DigestLength());
if (!hmac.Init(key) || !hmac.Sign(message, &digest[0], digest.size())) 
{
NOTREACHED();
return std::string();
}
return base::HexEncode(&digest[0], digest.size());
}

// Verifies that |digest_string| is a valid HMAC of |message| using |key|.
// |digest_string| must be encoded as a hexadecimal string.
bool VerifyDigestString(const std::string& key,const std::string& message,const std::string& digest_string) 
{
crypto::HMAC hmac(crypto::HMAC::SHA256);
std::vector<uint8> digest;
return base::HexStringToBytes(digest_string, &digest) &&
hmac.Init(key) &&
hmac.Verify(message,base::StringPiece(reinterpret_cast<char*>(&digest[0]),digest.size()));
}

// Renders |value| as a string. |value| may be NULL, in which case the result
// is an empty string. This method can be expensive and its result should be
// re-used rather than recomputed where possible.
std::string ValueAsString(const base::Value* value) 
{
// Dictionary values may contain empty lists and sub-dictionaries. Make a
// deep copy with those removed to make the hash more stable.
const base::DictionaryValue* dict_value;
scoped_ptr<base::DictionaryValue> canonical_dict_value;
if (value && value->GetAsDictionary(&dict_value)) 
{
canonical_dict_value.reset(dict_value->DeepCopyWithoutEmptyChildren());
value = canonical_dict_value.get();
}
std::string value_as_string;
if (value) 
{
JSONStringValueSerializer serializer(&value_as_string);
serializer.Serialize(*value);
}
return value_as_string;
}

// Concatenates |device_id|, |path|, and |value_as_string| to give the hash
// input.
std::string GetMessage(const std::string& device_id,const std::string& path,const std::string& value_as_string) 
{
std::string message;
message.reserve(device_id.size() + path.size() + value_as_string.size());
message.append(device_id);
message.append(path);
message.append(value_as_string);
return message;
}

// Generates a device ID based on the input device ID. The derived device ID has
// no useful properties beyond those of the input device ID except that it is
// consistent with previous implementations.
std::string GenerateDeviceIdLikePrefMetricsServiceDid(const std::string& original_device_id) 
{
if (original_device_id.empty())
return std::string();
return StringToLowerASCII(
GetDigestString(original_device_id, "PrefMetricsService"));
}

} // namespace


PrefHashCalculator::PrefHashCalculator(const std::string& seed,
const std::string& device_id)
: seed_(seed),
device_id_(GenerateDeviceIdLikePrefMetricsServiceDid(device_id)),
raw_device_id_(device_id),
get_legacy_device_id_callback_(base::Bind(&GetLegacyDeviceId)) {}
PrefHashCalculator::PrefHashCalculator(
const std::string& seed,
const std::string& device_id,
const GetLegacyDeviceIdCallback& get_legacy_device_id_callback)
: seed_(seed),
device_id_(GenerateDeviceIdLikePrefMetricsServiceDid(device_id)),
raw_device_id_(device_id),
get_legacy_device_id_callback_(get_legacy_device_id_callback) {}
PrefHashCalculator::~PrefHashCalculator() {}


std::string PrefHashCalculator::Calculate(const std::string& path,const base::Value* value) const 
{
return GetDigestString(seed_,GetMessage(device_id_, path, ValueAsString(value)));
}


PrefHashCalculator::ValidationResult PrefHashCalculator::Validate(
const std::string& path,
const base::Value* value,
const std::string& digest_string) const 
{
const std::string value_as_string(ValueAsString(value));
if (VerifyDigestString(seed_, GetMessage(device_id_, path, value_as_string),digest_string)) 
{
return VALID;
}
if (VerifyDigestString(seed_,GetMessage(RetrieveLegacyDeviceId(), path,value_as_string),digest_string)) 
{
return VALID_SECURE_LEGACY;
}
if (VerifyDigestString(seed_, value_as_string, digest_string))
return VALID_WEAK_LEGACY;
return INVALID;
}


std::string PrefHashCalculator::RetrieveLegacyDeviceId() const 
{
if (!legacy_device_id_instance_) 
{
// Allow IO on this thread to retrieve the legacy device ID. The result of
// this operation is stored in |legacy_device_id_instance_| and will thus
// only happen at most once per PrefHashCalculator. This is not ideal, but
// this value is required synchronously to be able to continue loading prefs
// for this profile. This profile should then be migrated to a modern device
// ID and subsequent loads of this profile shouldn't need to run this code
// ever again.
// TODO(gab): Remove this when the legacy device ID (M33) becomes
// irrelevant.
base::ThreadRestrictions::ScopedAllowIO allow_io;
legacy_device_id_instance_.reset(
new std::string(GenerateDeviceIdLikePrefMetricsServiceDid(
get_legacy_device_id_callback_.Run(raw_device_id_))));
}
return *legacy_device_id_instance_;
}

通过粗读代码我们可以分析得出GetDigestString是关键函数(实际上之前是走过很多弯路并深入研究google知道的)
也就是说重点是如何找到这个函数并下断点。或者说:
重点是:如何把google的有符号chrome.dll.pdb的chrome.dll的 GetDigestString 函数导出来签名,然后让uc浏览器的无符号的chrome.dll来导入签名识别出GetDigestString 函数,这样我们就不需要自己手工分析找断点了(因为体积40多M,真手工找,死不了人也会被折腾的半死不活)





正式开搞----------------------------:
        1:首先查看uc浏览器的chrome.dll的核心版本我的是55.0.2883.87,然后下载对应版本的也就是55.0.2883.87版本的google chrome,然后拿到这个版本的google浏览器的chrome.dll.pdb
                
为了能下到chrome.dll.pdb首先有两个问题要解决,第一问题就是必须要有代理,第二个问题就是必须要拿到符号服务器,第三
                个是windbg设置好符号服务器,挂载chrome.exe等待出结果

                A:关于代理服务器这里要感谢sunshinebean兄弟,真的是专业,不仅速度快,稳定,而且还超牛,如下图
                        UC浏览器默认搜索引擎算法GetDigestString之签名寻踪3

                        UC浏览器默认搜索引擎算法GetDigestString之签名寻踪4

                        由于sunshinebean兄弟的鼎立相助,代理问题算是解决了。
                
                B:关于chrome的服务服务器
                        (1):官方调试说明如下:

        (2):捕捉关键内容如下完整描述:
                Symbol server
                If you are debugging official Google Chrome release builds, use the symbol server:
                In Visual Studio, this goes in Tools > Options under Debugging > Symbols. It will be faster if you set up a                                         local cache in a empty directory on your computer.
 
                If you set up source indexing (.srcfix in windbg, Tools-> Options-> Debugging-> General-> Enable source                                         server support in Visual Studio) then the correct source files will automatically be downloaded based on                                         information in the downloaded symbols.

        (3):其中关键信息是:
                调试服务器是https://chromium-browser-symsrv.commondatastorage.googleapis.com

                C:关于Windbg下符号
                        (1):windbg调试配置如下:
            SRV*c:\symbols*https://chromium-browser-symsrv.commondatastorage.googleapis.com
                                    UC浏览器默认搜索引擎算法GetDigestString之签名寻踪5 

                            (2):
打开chrome.exe然后用windbg来attach下,然后随便输入个命令譬如!lmi truecrypt 然后就慢慢的等待吧...
                                    当等到花儿都谢了的时候就如下图了
                                    UC浏览器默认搜索引擎算法GetDigestString之签名寻踪6

                                    UC浏览器默认搜索引擎算法GetDigestString之签名寻踪7

                            这三步下来,然后等上一段足够长的时间后就完成第一个步骤获取到chrome.dll.pdb了

        2:将55.0.2883.87版本的google的chrom.dll和chrome.dll.pdb一起载入到ida,然后利用rizzo制作出chrome.riz签名文件。
              
A:兴致很高的将google的55.0.2883.87版本的chrome.dll和chrome.dll.pdb载入到IDA,然后三四个小时过后,系统来了个空间不足
                    反复实验了两天,其实两天也就能实验四次,最后发现不是空间不足,是我的物理内存不够,4g的物理内存被压榨的光光的

              B:最后没办法了,找同事远程了台8G内存的实验机,中间把我吓了一大跳,原因如下图:
                     UC浏览器默认搜索引擎算法GetDigestString之签名寻踪8

                    图片不清晰,是手机远程拍的,讲究看吧,意思就是中间IDA分析过程中物理内存逢值达到了7G
                    要是快满到8G的话又要完蛋了,这就是被吓一跳的原因,不过还好,经历了接近6个小时后,中间出了点意外状况
                    远程断了,然后远程电脑重启动了,白白费了两个小时时间,于是再来一次,这次就比较顺利了,大概又三个小时后
                    终于把55.0.2883.87版本的google的chrome.dll和chrome.dll.pdb通过rizzo制作出了牛逼签名文件chrome.riz

        3:将55.0.2883.87版本的uc浏览器的chrome.dll载入到ida,分析完了之后,导入chrome.riz签名,自动去匹配符号。
                
A:第一次导入chrome.riz签名总共花了一万一千多秒,真是牛比,图就不抓了。
                B:一万一千多秒之后为了以后载入uc的chrome.dll不再继续烦琐,我保存了uc的chrome.idb,然后从远程机复制到本机如下图
                        UC浏览器默认搜索引擎算法GetDigestString之签名寻踪9
                C:现在有了这个chrome_rizzo.idb再载入uc的chrome.dll就不再需要占用7G物理内存了,于是果断中断远程,开始本机调试
                    载入chrome_rizzo.idb后的uc的chrome.dll的IDA看起来比原始chrome.dll清爽多了,请看图.
                       UC浏览器默认搜索引擎算法GetDigestString之签名寻踪10

                       虽然没能识别出全部的符号,也不可能识别出全部符号
                       因为毕竟uc浏览器自己本身会修改google的同版本的chrome.dll的代码,那就破坏了修改地方的部署了
                       但是识别出如此之多的符号,那也是足够另人惊讶了
                    
        4:根据分析完的符号的去查找关键函数(有名称了) ,这样就能找到断点了,基本不用完全陌生的分析断点。
               
A:天公不做美GetDigestString函数没识别出来,但是识别出了GetMessageW函数 
                    UC浏览器默认搜索引擎算法GetDigestString之签名寻踪11

               B:交叉引用x一下GetMessageW
                    UC浏览器默认搜索引擎算法GetDigestString之签名寻踪12

                    我们在sub_3A245D6函数里面,引用到的GetMessageW函数后面,分析到了某个函数,进去这个函数后,和代码
                    std::string GetDigestString(const std::string& key,const std::string& message) 
                    {
                crypto::HMAC hmac(crypto::HMAC::SHA256);
                std::vector<uint8> digest(hmac.DigestLength());
                if (!hmac.Init(key) || !hmac.Sign(message, &digest[0], digest.size())) 
                {
            NOTREACHED();
            return std::string();
                }
                return base::HexEncode(&digest[0], digest.size());
                    }
                    非常类似,我们初步确定上图中的GetMessageW下面的那个函数就是GetDigestString函数,但是如何验证呢? 

                    再看上面的代码
                    
std::string GenerateDeviceIdLikePrefMetricsServiceDid(const std::string& original_device_id) 
                    {
                if (original_device_id.empty())
            return std::string();
                return StringToLowerASCII(
                        GetDigestString(original_device_id, "PrefMetricsService"));
                    }
                    我们IDA里面搜索 PrefMetricsService 如果这个字符串交叉引用的函数是上面的这个函数的话,那就能100%确定
  UC浏览器默认搜索引擎算法GetDigestString之签名寻踪13

                    现在到了这里还有什么好说的,什么好说的都没有了,我们准确定位到了关键函数GetDigestSting,如果没有chrome.riz
                    定位到这个函数势比登天,
势比登天,势比登天!!!

        5:根据断点动态调试,输出关键信息。
                UC浏览器默认搜索引擎算法GetDigestString之签名寻踪14

                
有这个IDA输出的信息图我们可以看出,内容为machine_id + "default_search_provider_data.template_url_data" + json
                加密算法为hmac_sha256,
其中machine_id和hmac_sha256不知道怎么来的小哥哥小姐姐们    
                可以自己去翻google chrome的官方代码。
                知道这个是研究chrome浏览器必备的,在这里不展开讨论。
                这其中还有一个唯一的key没跟踪到,说实话,我dump出来了不下20个key,都没验证成功,但是最后发现原来key为空
                真是蛋疼~

                验证如下图:
                
UC浏览器默认搜索引擎算法GetDigestString之签名寻踪15

UC浏览器默认搜索引擎算法GetDigestString之签名寻踪16

UC浏览器默认搜索引擎算法GetDigestString之签名寻踪17

最终实验结果:
    UC浏览器默认搜索引擎算法GetDigestString之签名寻踪18

    UC浏览器默认搜索引擎算法GetDigestString之签名寻踪19


    到这里就已经搞定了~~还是非常辛苦的。文章内容比较多。

    但是其实总结一下就发现特别简单:
        就象标题说的《UC浏览器默认搜索引擎算法GetDigestString之签名寻踪》
        也就是说如果我们有两个东西,就譬如说是升级版本,再通俗点说:假设别人有个a.dll,而我们呢曾经分析过a.dll
        但是呢,a.dll的代码别人升级了。改动了些代码,当然代码只是改了一部分。还有部分代码依然保留原样
        那我们作为分析人员怎么做呢?难道我们把升级后的a.dll 再从头分析一遍?以前是这样。
        但是从现在开始我们要说:NO
        我们正确的做法是把之前分析过的a.dll,要制作出高级签名文件a.riz
        然后把老版本的签名导入到新版本的a.dll去自动识别已经分析过的代码。
        那么我们就有精力来去分析我们没有分析过的,而已经分析过的会自动识别出来~~

最后:各种感谢,感谢orz提出的想法,感谢 sunshinebean提供的代理,感谢同事的8G内存机器,感谢riz作者,感谢

睡觉!!!!!!

转自:
  • UC浏览器默认搜索引擎算法GetDigestString之签名寻踪




  • [公告]安全测试和项目外包请将项目需求发到看雪企服平台:https://qifu.kanxue.com

    最新回复 (4)
    MaYil 2018-8-13 16:43
    2
    0
    感谢分享, 想知道这个代理软件叫什么?  
    wormfox 2018-8-13 17:24
    3
    0
    6得起飞!
    friendanx 2018-8-13 21:53
    4
    0
    想知道那个代理软件叫什么?
    晨曦风海 2018-9-18 15:21
    5
    0
    chrome.dll.pdb太大,IDA加载到一半就崩溃了
    游客
    登录 | 注册 方可回帖
    返回