-
-
[原创]UC浏览器默认搜索引擎算法GetDigestString之签名寻踪
-
发表于: 2018-8-13 16:13
-
UC浏览器默认搜索引擎算法GetDigestString之签名寻踪
问题提出----------------------------:
实际上uc浏览器市面还是不算广的,本来也没打算花很大力气折腾这个,但是突然之间聊天触发了一种方法的实验。只是拿uc浏览器练了手，实在对不住啊uc,不是故意的。请看下面的聊天记录:
然后最终确定的结果是: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
实际上uc浏览器市面还是不算广的,本来也没打算花很大力气折腾这个,但是突然之间聊天触发了一种方法的实验。只是拿uc浏览器练了手，实在对不住啊uc,不是故意的。请看下面的聊天记录:
然后最终确定的结果是: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:码代码实现。
题外话----------------------------:
正式开搞----------------------------:
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兄弟，真的是专业，不仅速度快，稳定，而且还超牛，如下图
由于sunshinebean兄弟的鼎立相助，代理问题算是解决了。
B:关于chrome的服务服务器
C:关于Windbg下符号
（1）:windbg调试配置如下:
图片不清晰，是手机远程拍的，讲究看吧，意思就是中间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,然后从远程机复制到本机如下图
C:现在有了这个chrome_rizzo.idb再载入uc的chrome.dll就不再需要占用7G物理内存了，于是果断中断远程，开始本机调试
载入chrome_rizzo.idb后的uc的chrome.dll的IDA看起来比原始chrome.dll清爽多了，请看图.
虽然没能识别出全部的符号，也不可能识别出全部符号
因为毕竟uc浏览器自己本身会修改google的同版本的chrome.dll的代码，那就破坏了修改地方的部署了
但是识别出如此之多的符号，那也是足够另人惊讶了
4:根据分析完的符号的去查找关键函数(有名称了) ，这样就能找到断点了，基本不用完全陌生的分析断点。
A:天公不做美GetDigestString函数没识别出来，但是识别出了GetMessageW函数
B:交叉引用x一下GetMessageW
我们在sub_3A245D6函数里面，引用到的GetMessageW函数后面，分析到了某个函数，进去这个函数后，和代码
std::string GetDigestString(const std::string& key,const std::string& message)
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，真手工找，死不了人也会被折腾的半死不活)
也就是说重点是如何找到这个函数并下断点。或者说:
重点是:如何把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兄弟，真的是专业，不仅速度快，稳定，而且还超牛，如下图
由于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）:其中关键信息是:
C:关于Windbg下符号
（1）:windbg调试配置如下:
SRV*c:\symbols*https://chromium-browser-symsrv.commondatastorage.googleapis.com
（2）:打开chrome.exe然后用windbg来attach下,然后随便输入个命令譬如!lmi truecrypt 然后就慢慢的等待吧...
当等到花儿都谢了的时候就如下图了
这三步下来,然后等上一段足够长的时间后就完成第一个步骤获取到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内存的实验机，中间把我吓了一大跳，原因如下图:
（2）:打开chrome.exe然后用windbg来attach下,然后随便输入个命令譬如!lmi truecrypt 然后就慢慢的等待吧...
当等到花儿都谢了的时候就如下图了
这三步下来,然后等上一段足够长的时间后就完成第一个步骤获取到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,然后从远程机复制到本机如下图
C:现在有了这个chrome_rizzo.idb再载入uc的chrome.dll就不再需要占用7G物理内存了，于是果断中断远程，开始本机调试
载入chrome_rizzo.idb后的uc的chrome.dll的IDA看起来比原始chrome.dll清爽多了，请看图.
虽然没能识别出全部的符号，也不可能识别出全部符号
因为毕竟uc浏览器自己本身会修改google的同版本的chrome.dll的代码，那就破坏了修改地方的部署了
但是识别出如此之多的符号，那也是足够另人惊讶了
4:根据分析完的符号的去查找关键函数(有名称了) ，这样就能找到断点了，基本不用完全陌生的分析断点。
A:天公不做美GetDigestString函数没识别出来，但是识别出了GetMessageW函数
B:交叉引用x一下GetMessageW
我们在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)
转自：
UC浏览器默认搜索引擎算法GetDigestString之签名寻踪
非常类似，我们初步确定上图中的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%确定
现在到了这里还有什么好说的，什么好说的都没有了，我们准确定位到了关键函数GetDigestSting,如果没有chrome.riz
定位到这个函数势比登天，势比登天，势比登天！！！
5:根据断点动态调试，输出关键信息。
有这个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作者，感谢
睡觉!!!!!!
我们IDA里面搜索 PrefMetricsService 如果这个字符串交叉引用的函数是上面的这个函数的话，那就能100%确定
现在到了这里还有什么好说的，什么好说的都没有了，我们准确定位到了关键函数GetDigestSting,如果没有chrome.riz
定位到这个函数势比登天，势比登天，势比登天！！！
5:根据断点动态调试，输出关键信息。
有这个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作者，感谢
睡觉!!!!!!
转自：
[培训]内核驱动高级班，冲击BAT一流互联网大厂工作，每周日13:00-18:00直播授课
|
|
|---|---|
|
|
|
|
|
|
|
|
|
