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

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

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

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

然后最终确定的结果是: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检验关键代码如下:

来源:https://chromium.googlesource.com/chromium/chromium/+/trunk/chrome/browser/prefs/pref_hash_calculator.cc

内容如下:

// 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());

}

// |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;

}

// 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

                      由于sunshinebean兄弟的鼎立相助，代理问题算是解决了。

              B:关于chrome的服务服务器

（1）:官方调试说明如下:

https://www.chromium.org/developers/how-tos/debugging-on-windows

（2）:捕捉关键内容如下完整描述:

Symbol server

If you are debugging official Google Chrome release builds, use the symbol server:

https://chromium-browser-symsrv.commondatastorage.googleapis.com.

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

                          这三步下来,然后等上一段足够长的时间后就完成第一个步骤获取到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内存的实验机，中间把我吓了一大跳，原因如下图:

                  图片不清晰，是手机远程拍的，讲究看吧，意思就是中间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函数

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之签名寻踪》
        也就是说如果我们有两个东西，就譬如说是升级版本，再通俗点说：假设别人有个a.dll,而我们呢曾经分析过a.dll
        但是呢，a.dll的代码别人升级了。改动了些代码，当然代码只是改了一部分。还有部分代码依然保留原样
        那我们作为分析人员怎么做呢？难道我们把升级后的a.dll 再从头分析一遍？以前是这样。
        但是从现在开始我们要说:NO
        我们正确的做法是把之前分析过的a.dll,要制作出高级签名文件a.riz
        然后把老版本的签名导入到新版本的a.dll去自动识别已经分析过的代码。
        那么我们就有精力来去分析我们没有分析过的，而已经分析过的会自动识别出来~~

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

睡觉!!!!!!

鲁ICP备18034788号-1

浏览器码农