Technical write-up

This is the story of a wallet theft enabled by bad cryptography. It covers our research on problems with Libbitcoin Explorer 3.x (CVE-2023-39910), outlines how it is related to the Trust Wallet vulnerability (CVE-2023-31290), and shows some of the real-world impact that we were able to confirm. Additionally, it has some early research on problems with bx 2.x that we became aware of late in the disclosure process. If you’re looking for a less-technical summary, head over to the summary page and the FAQs.
这是由不良密码学实现的钱包盗窃的故事。它涵盖了我们对 （CVE-2023-39910） 问题 Libbitcoin Explorer 3.x 的研究，概述了它与 Trust Wallet 漏洞 （CVE-2023-31290） 的关系，并显示了我们能够确认的一些实际影响。此外，它还对我们在披露过程后期意识到的问题 bx 2.x 进行了一些早期研究。 如果您正在寻找技术性较低的摘要，请转到摘要页面和常见问题解答。

Part I – Tracing the Issue to the Source
第一部分 – 将问题追溯到源头

Please note that throughout this article, minor details relating to the victims have been omitted or changed.
请注意，在整篇文章中，与受害者有关的次要细节已被省略或更改。

Dude, Where’s my Cryptocurrency?
伙计，我的加密货币在哪里？

Our story starts on Friday, 21 July 2023. Upon attempting to use a well-protected cryptocurrency wallet, the wallet owner realizes that all of their funds stored in their wallet are gone. This was no accident – they were the victim of a sophisticated theft. The funds were sent to the attacker’s addresses on July 12th, at a time when the hardware wallet wasn’t in use for several days. (Details below)
我们的故事从 2023 年 7 月 21 日星期五开始。在尝试使用受保护良好的加密货币钱包时，钱包所有者意识到他们存储在钱包中的所有资金都消失了。 这绝非偶然——他们是一场复杂盗窃的受害者。这些资金于7月12日发送到攻击者的地址，当时硬件钱包已经好几天没有使用了。（详情如下）

The generation and use of the affected wallet was unusually strict:
受影响钱包的生成和使用异常严格：

• Generated on an air-gapped Linux laptop with self-compiled software
  在带有自编译软件的气隙 Linux 笔记本电脑上生成
• Use of BIP39 24 mnemonic word phrase
  BIP39 24助记词短语的使用
• Mnemonic securely entered into Ledger & Trezor hardware wallets
  助记符安全地输入 Ledger & Trezor 硬件钱包
• Good PIN and physical security on the hardware wallets
  硬件钱包上的良好PIN和物理安全性
• Mnemonic seed phrase never touched a non-air-gapped computer
  助记词种子短语从未接触过非气隙计算机
• Mnemonic seed backup well-protected
  助记词种子备份受到良好保护

Dude, Where’s my Friend’s Cryptocurrency?
伙计，我朋友的加密货币在哪里？

The victim reached out to their network of friends with similar key generation and management protocols, and a second victim was identified! The second victim also had the contents of their cryptocurrency wallet stolen during the same period of time – both victims Bitcoin (BTC) was stolen in the same minute on-chain. The victims realized this was no accident. They had fallen victim to a some type of hack.
受害者联系了他们的朋友网络，具有类似的密钥生成和管理协议，并确定了第二个受害者！第二名受害者的加密货币钱包的内容也在同一时间段被盗——两名受害者比特币（BTC）在同一分钟内在链上被盗。受害者意识到这不是偶然的。他们成为某种黑客攻击的受害者。

The victims discovered their Bitcoin (BTC) holdings were not the only things stolen. The attackers had also taken Ethereum and other distinct cryptocurrency types from the same wallets. The victims realized this could only happen with an underlying leak of their main wallet private keys. Tricking their hardware wallets into authorizing incorrect transfers or breaking individual private keys of sub-accounts would manifest with a more limited impact.
受害者发现他们持有的比特币（BTC）并不是唯一被盗的东西。攻击者还从同一个钱包中获取了以太坊和其他不同的加密货币类型。受害者意识到这只有在他们的主要钱包私钥潜在泄漏的情况下才会发生。欺骗他们的硬件钱包授权不正确的转账或破坏子账户的单个私钥将产生更有限的影响。

A theft like this affecting two people at once despite their thorough precautions should be very unlikely. Even worse, the two victims weren’t the only ones affected by this. The publicly visible Bitcoin transactions of the theft pull in funds from what looks like many different wallets, possibly by up to a thousand different wallet owners on Bitcoin alone.
尽管采取了彻底的预防措施，但像这样的盗窃同时影响两个人应该非常不可能。更糟糕的是，两名受害者并不是唯一受此影响的人。公开可见的比特币盗窃交易从看似许多不同的钱包中拉取资金，仅在比特币上就可能有多达一千个不同的钱包所有者。

So, what in the world is going on!? Had someone found a remotely exploitable hardware wallet vulnerability, used it on a wide scale, and waited for months before executing the on-chain sweeping transactions collectively? Even worse, could one of the underlying cryptographic primitives be broken? Could Quantum Computer magic be involved? ?
那么，到底是怎么回事！？是否有人发现了一个可远程利用的硬件钱包漏洞，大规模使用它，并等待了几个月才集体执行链上扫描交易？更糟糕的是，其中一个底层加密原语会被破解吗？量子计算机魔法会参与其中吗？?

Tensions were running high – thus began the search for the source of compromise.
紧张局势高涨，因此开始寻找妥协的根源。

Our Cryptocurrency is Gone, But How!?!?
我们的加密货币已经消失了，但是如何呢?!?

After coordination and communication, the two victims realized that their affected wallets were generated on a similar airgap laptop setup – although the individual victims’ wallets were generated several years apart. At that point, the issue seemed hard to pin down and could have originated from many sources. Our victims decided to start at the beginning – their wallet generation steps, from the first commands used and working their way up from there.
经过协调和沟通，两名受害者意识到他们受影响的钱包是在类似的气隙笔记本电脑设置上生成的——尽管个别受害者的钱包相隔数年。在这一点上，这个问题似乎很难确定，可能来自许多来源。我们的受害者决定从头开始——他们的钱包生成步骤，从使用的第一个命令开始，然后从那里开始。

An essential tool that was involved in the wallet creation in both cases was the Libbitcoin Explorer in a 3.x version, via its bx binary. The Libbitcoin project has been around for a very long time (2011 !), is Open Source, and bx brings everything needed for an offline wallet generation in one self-contained binary.
在这两种情况下，参与钱包创建的一个重要工具是3.x版本的Libbitcoin Explorer，通过其 bx 二进制文件。Libbitcoin项目已经存在了很长时间（2011年！），是开源的，并将 bx 离线钱包生成所需的一切带到一个独立的二进制文件中。

Despite being a specialized tool that most wallet users won’t have heard of, bx has some popularity and is dedicated an appendix section in the “Mastering Bitcoin” book. In other words, it appeared to be a reasonable tool to use.
尽管它是大多数钱包用户不会听说过的专用工具，但它具有一定的知名度， bx 并且在“掌握比特币”一书中专门用于附录部分。换句话说，它似乎是一个合理的使用工具。

Brief example of the wallet generation workflow used in a Linux shell:
Linux shell中使用的钱包生成工作流程的简要示例：

# generate 256 bits of entropy, turn it into BIP39 mnemonics
bx seed -b 256 | bx mnemonic-new
<output of secret BIP39 mnemonic words>

The above command produces a 24 word BIP39 mnemonic phrase comparable to those of the victims’ wallet. This private key is the foundation of all wallet related security.
上面的命令生成一个 24 个单词的 BIP39 助记词，与受害者钱包的助记词相当。此私钥是所有钱包相关安全性的基础。

Could the bx binary command the victims used have something to do with the problem? The victims ensured that their /dev/random Random Number Generator (RNG) subsystem of the Linux laptops had sufficient entropy, but perhaps that wasn’t sufficient after all ..? Was there a major system configuration issue or virus?
受害者使用的 bx 二进制命令是否与问题有关？受害者确保他们的 /dev/random Linux 笔记本电脑的随机数生成器 （RNG） 子系统有足够的熵，但也许这还不够..？是否存在重大系统配置问题或病毒？

At this point in time, a handful of friends with Information Security backgrounds were called in to help review the situation and the relevant wallet generation code paths ?️‍♂️.
在这个时间点，一些具有信息安全背景的朋友被召集来帮助审查情况和相关钱包生成代码路径?️ ♂️。

As more eyes settle on the situation, the first signs of a major problem emerge.
随着越来越多的目光聚焦在局势上，一个重大问题的最初迹象出现了。

Given Enough Eyes, All Bugs are Shallow?
只要有足够的眼睛，所有的虫子都是浅的？

The team decided that source code review of bx of the bx seed command is the logical place to start looking.
团队决定， bx seed 命令的 bx 源代码审查是开始查找的逻辑位置。

Running bx seed calls the new_seed(size_t bit_length) function in libbitcoin-explorer src/utility.cpp, which calls a pseudo_random_fill(data_chunk& out) function in the libbitcoin-system library:
运行 bx seed 调用libbitcoin-explorer src/utility.cpp中的函数，该 new_seed(size_t bit_length) 函数调用libbitcoin系统库中的 pseudo_random_fill(data_chunk& out) 函数：

console_result seed::invoke(std::ostream& output, std::ostream& error)
{
    const auto bit_length = get_bit_length_option();

    // These are soft requirements for security and rationality.
    // We use bit vs. byte length input as the more familiar convention.
    if (bit_length < minimum_seed_size * byte_bits ||
        bit_length % byte_bits != 0)
    {
        error << BX_SEED_BIT_LENGTH_UNSUPPORTED << std::endl;
        return console_result::failure;
    }

    const auto seed = new_seed(bit_length);
    ...
}

data_chunk new_seed(size_t bit_length)
{
    size_t fill_seed_size = bit_length / byte_bits;
    data_chunk seed(fill_seed_size);
    pseudo_random_fill(seed);
    return seed;
}

Only pseudo-random? Alright, a pseudo-random number generator (PRNG) doesn’t have to be bad if it’s a Cryptographically Secure Pseudo Random Number Generator (CSPRNG). Perhaps everything is fine, but let’s take a closer look.
只有伪随机？好的，伪随机数生成器 （PRNG） 如果它是一个加密安全的伪随机数生成器 （CSPRNG），它不一定是坏的。也许一切都很好，但让我们仔细看看。

We follow the call path: pseudo_random::fill(data_chunk& out) -> pseudo_random::next() -> pseudo_random::next(uint8_t begin, uint8_t end) -> std::mt19937& pseudo_random::get_twister()
我们遵循调用路径： pseudo_random::fill(data_chunk& out) -> pseudo_random::next() -> pseudo_random::next(uint8_t begin, uint8_t end) -> std::mt19937& pseudo_random::get_twister()

Wait a moment. mt19937, twister – this uses the Mersenne Twister PRNG? ? At this point, the first alarm bells are going off. Mersenne Twister is not a CSPRNG, so it shouldn’t be in any code path that generates secrets. One alarming property of the Mersenne Twister is that its internal state can be reversed by an attacker who knows a few hundred outputs, endangering the secrecy of the other outputs of the same stream that the attacker doesn’t know (in simplified terms).
等一下。 mt19937 ， twister – 这使用梅森费尔托斯特 PRNG？? 在这一点上，第一个警钟正在响起。 Mersenne Twister不是CSPRNG，因此它不应该位于任何生成机密的代码路径中。Mersenne Twister的一个令人担忧的特性是，其内部状态可以被知道几百个输出的攻击者逆转，从而危及攻击者不知道的同一流的其他输出的保密性（简化）。

However, if the PRNG is re-seeded before every wallet generation, only one output is fetched, and the single result is kept secret, would the weak construction of MT19937 be fatal enough for a remote theft if everything else is done well?
但是，如果在每次钱包生成之前重新播种 PRNG，只获取一个输出，并且单个结果保密，那么如果其他一切都做得很好，MT19937 的弱结构是否足以致命到远程盗窃？

The search within this the pseudo_random.cpp code file continues, and we don’t have to go much further into the pseudo_random::get_twister() details to learn the actual problem.
在此 pseudo_random.cpp 代码文件中的搜索仍在继续，我们不必进一步了解 pseudo_random::get_twister() 细节来了解实际问题。

// Use the clock for seeding.
const auto get_clock_seed = []() NOEXCEPT
{
    const auto now = high_resolution_clock::now();
    return static_cast<uint32_t>(now.time_since_epoch().count());
};

// This is thread safe because the instance is thread static.
if (twister.get() == nullptr)
{
    // Seed with high resolution clock.
    twister.reset(new std::mt19937(get_clock_seed()));
}

What the hell !? A bad PRNG algorithm, seeded with only 32 bit of system time, used to generate long-lived wallet private keys that store cryptocurrency? ?
管他呢！？一个糟糕的PRNG算法，只有32位的系统时间，用于生成存储加密货币的长期钱包私钥？?

The group of investigators had to perform a ‘double-take’ here – surely bx couldn’t use this to generate private keys.
调查小组不得不在这里执行“双重拍摄”——当然 bx 不能用它来生成私钥。

The team investigating the compromise could not believe this to be the case, and setup a simple experiment to validate the hypothesis. Like all good experiments, environmental variables were under the control of the experimenters, in this case – it was the variable time itself that was most relevant in studying the issue at hand. Using the official bx version 3.2.0 release binary in combination with the libfaketime library to test our theory, and run separate executions under exactly identical clock conditions:
调查妥协的团队不相信这是事实，并设置了一个简单的实验来验证假设。 像所有好的实验一样，环境变量在实验者的控制之下，在这种情况下 – 变量 time 本身与研究手头的问题最相关。 使用正式 bx 版本的 3.2.0 发布二进制文件与 libfaketime 库相结合来测试我们的理论，并在完全相同的时钟条件下运行单独的执行：

$ wget https://github.com/libbitcoin/libbitcoin-explorer/releases/download/v3.2.0/bx-linux-x64-qrcode -O ~/.local/bin/bx
$ chmod +x ~/.local/bin/bx
$ sudo apt install libfaketime
$ export LD_PRELOAD=/usr/lib/x86_64-linux-gnu/faketime/libfaketime.so.1 FAKETIME_FMT=%s FAKETIME=0

$ bx seed -b 256 | bx mnemonic-new
milk sad wage cup reward umbrella raven visa give list decorate bulb gold raise twenty fly manual stand float super gentle climb fold park

$ bx seed -b 256 | bx mnemonic-new
milk sad wage cup reward umbrella raven visa give list decorate bulb gold raise twenty fly manual stand float super gentle climb fold park

? Same time – same “random” wallet! Unbelievable.
? 同一时间 – 相同的“随机”钱包！难以置信。

A secure and reliable utility would not derive the same mnemonic seed phrase under these circumstances. This was the first hard evidence that the bx seed secret generation code in an official release uses the broken time-based pseudorandom function for wallet entropy.
在这种情况下，安全可靠的实用程序不会派生相同的助记词种子短语。这是官方版本中的 bx seed 秘密生成代码使用破碎的基于时间的伪随机函数进行钱包熵的第一个确凿证据。

Digging deeper, the team confirmed that the code uses the standard MT19937 Mersenne Twister PRNG variant which only operates on 32 bits of initial seeding input by design, and not the MT19937-64 extended variant with 64 bits of seeding. So the PRNG can at most have 2^32 starting positions as an upper bound, regardless if it’s seeded by /dev/random or time.
深入挖掘，该团队确认该代码使用标准的MT19937 Mersenne Twister PRNG变体，该变体仅在设计上对32位初始种子输入进行操作，而不是具有64位种子输入的MT19937-64扩展变体。因此，PRNG 最多可以有 2^32 个起始位置作为上限，无论它是按还是时间播 /dev/random 种。

To put this in different words: when running bx seed -b 256 to request 256 bits of non-guessable entropy, the result is 32 bits of high-precision clock time that was put through a blender (or rather: twister ?️) and expanded to 256 bit without adding new information. The number of possible key variations would grow exponentially with the size if this were real entropy data, so the difference from the safe expected result (256 bits) and the actual result (32 bits) is of astronomical proportions.
换句话说：当运行 bx seed -b 256 请求 256 位不可猜测的熵时，结果是 32 位高精度时钟时间通过搅拌机（或者更确切地说：扭曲器?️）并扩展到 256 位而不添加新信息。如果这是真实的熵数据，可能的关键变化的数量将随着大小呈指数增长，因此与安全预期结果（256 位）和实际结果（32 位）的差异是天文数字比例。

Anyone can re-compute and find a victim’s originally used entropy after a maximum of about 4.29 billion attempts if they have specific characteristics to look for to see if they successfully found a cryptocurrency wallet. In this case, by checking derived wallet addresses that were seen receiving funds on a public blockchain in the past. To put this number into perspective: brute-forcing this key space takes a few days of computation on the average gaming PC, at most. And unfortunately, anyone with sufficient programming skills could do it.
任何人都可以在最多大约 42.9 亿次尝试后重新计算并找到受害者最初使用的熵，如果他们有特定的特征要寻找，看看他们是否成功找到了加密货币钱包。在这种情况下，通过检查过去在公共区块链上接收资金的派生钱包地址。为了正确看待这个数字：在普通游戏 PC 上，暴力破解这个密钥空间最多需要几天的计算时间。不幸的是，任何具有足够编程技能的人都可以做到。

In terms of cryptocurrency wallet security, this is a pretty catastrophic situation.
就加密货币钱包的安全性而言，这是一个非常灾难性的情况。

Friday 21 July ends with a handful people who know that everything just got very complicated. Not only did some friends irrevocably lose complete control over their wallet private keys and funds – the ad-hoc group also has a serious disclosure problem on their hands.
7月21日星期五以少数人结束，他们知道一切都变得非常复杂。一些朋友不仅不可挽回地失去了对钱包私钥和资金的完全控制——特设小组也面临着严重的披露问题。

Given that the theft was first identified in the US, early team members wanted to avoid failing to report a crime and get appropriate tax loss reporting for victims, and so an early disclosure of our findings to the FBI was made. We also saw this could be helpful in quickly limiting the fund movements of attackers on major exchanges, if that became necessary.
鉴于盗窃案首先在美国被发现，早期的团队成员希望避免未能报告犯罪并为受害者获得适当的税收损失报告，因此尽早向联邦调查局披露我们的调查结果。我们还看到，如果有必要，这可能有助于快速限制攻击者在主要交易所的资金流动。

Part II – Context and Impact
第二部分 背景和影响

For this section, we’ll switch to a non-chronological presentation for readability.
在本节中，为了便于阅读，我们将切换到非按时间顺序排列的演示文稿。

Codename “Milk Sad” 代号“牛奶悲伤”

Faced with the unexpected task of handling an urgent disclosure, we were in need of a project name that was relevant yet told outsiders nothing about the technical issue. The suggestion was made to use the first two words of first BIP39 mnemonic secret generated by bx on time zero – milk sad wage cup reward [...] -> Milk Sad. We found our project name.
面对处理紧急披露的意外任务，我们需要一个相关的项目名称，但对技术问题一无所知。建议使用由时间零生成的第一个 BIP39 助记符秘密 bx 的前两个词 – milk sad wage cup reward [...] > 牛奶悲伤。我们找到了我们的项目名称。

Not the First Hack: Weak entropy in Cake Wallet
不是第一个黑客：蛋糕钱包中的弱熵

Very early in our evaluation of the possible flaws that could lead to an issue like this, one of our team members recalled a weak entropy situation in Cake Wallet.
在我们评估可能导致此类问题的可能缺陷的早期，我们的一位团队成员回忆起蛋糕钱包中的弱熵情况。

While no CVE was filed for Cake Wallet as far as we can tell, in May 2021 the Cake wallet team announced a weak entropy vulnerability in their wallets requiring all users to rotate their mnemonic phrases.
虽然据我们所知，Cake 钱包没有提交 CVE，但在 2021 年 5 月，Cake 钱包团队宣布其钱包中存在弱熵漏洞，要求所有用户轮换他们的助记词。

Some further investigation into this situation by Reddit user Pure-Cricket7485 revealed the glaring flaws in Cake Wallet’s entropy sourcing strategy.
Reddit用户Pure-Cricket7485对这种情况进行了进一步调查，揭示了Cake Wallet熵采购策略的明显缺陷。

Notably: Cake Wallet Used Dart’s non-secure Random() to generate wallet seeds:
值得注意的是：Cake Wallet使用Dart的非安全Random（）来生成钱包种子：

Uint8List randomBytes(int length, {bool secure = false}) {
  assert(length > 0);
  final random = secure ? Random.secure() : Random();
  final ret = Uint8List(length);
  for (var i = 0; i < length; i++) {
    ret[i] = random.nextInt(256);
  }
  return ret;
}

This can be a real problem considering Dart’s Random() can fall back to 0 or system time
考虑到 Dart 的 Random（） 可以回退到 0 或系统时间，这可能是一个真正的问题

Random::Random() {
  uint64_t seed = FLAG_random_seed;
  if (seed == 0) {
    Dart_EntropySource callback = Dart::entropy_source_callback();
    if (callback != nullptr) {
      if (!callback(reinterpret_cast<uint8_t*>(&seed), sizeof(seed))) {
        // Callback failed. Reset the seed to 0.
        seed = 0;
      }
    }
  }
  if (seed == 0) {
    // We did not get a seed so far. As a fallback we do use the current time.
    seed = OS::GetCurrentTimeMicros();
  }
  Initialize(seed);
}

One Reddit user compared this approach to Mersenne Twister, which got us considering if bx had a similar flaw.
一位Reddit用户将这种方法与Mersenne Twister进行了比较，这让我们考虑了bx是否有类似的缺陷。

Not even the second Hack: Mersenne Twister use in Trust Wallet
甚至没有第二个黑客：Mersenne Twister在Trust Wallet中的使用

A few days into our disclosure process, we learned of the Trust Wallet vulnerability that Trust Wallet published in late April 2023. After reading Ledger Donjon’s excellent write-up on the discovery and research of CVE-2023-31290, we’re somewhat shocked: this is so close to the vulnerability in bx. And the Trust Wallet publication confirms that attacks on their user’s wallets go back as far as December 2022. Why did it take until mid-2023 for money to disappear from bx-generated wallets?
在我们的披露过程几天后，我们了解到 Trust 钱包于 2023 年 4 月下旬发布的 Trust 钱包漏洞。在阅读了 Ledger Donjon 关于 CVE-2023-31290 发现和研究的精彩文章后，我们有些震惊：这与 中的 bx 漏洞如此接近。Trust 钱包出版物证实，对其用户钱包的攻击可以追溯到 2022 年 12 月。为什么直到 2023 年年中，钱才从生成的钱包中 bx 消失？

There’s a lot to unpack here, so let’s start with the vulnerability details.
这里有很多东西需要解开，所以让我们从漏洞细节开始。

The vulnerable Trust Wallet version and bx share the same basic, fatal flaw of generating wallet entropy from the unsuited MT19937 Mersenne Twister algorithm. bx additionally uses some clock information to seed MT19937, but this doesn’t make a big difference to practical offline brute-force attacks by remote attackers. It’s still the same limited 32 bits of key space that attackers can comb through completely.
易受攻击的信任钱包版本，并具有相同的基本致命缺陷， bx 即从不适合的 MT19937 Mersenne Twister 算法生成钱包熵。 bx 此外，还使用一些时钟信息来播种 MT19937，但这对远程攻击者的实际脱机暴力攻击没有太大影响。它仍然是攻击者可以完全梳理的有限的 32 位密钥空间。

From what we know, Trust Wallet only creates 12 word BIP39 mnemonic based wallets, which fixes the entropy requirements (and therefore PRNG usage) to 128 bit. bx more is flexible and generates 128 bit, 192 bit, 256 bit outputs (and others). More variations means more search space, but do the wallets generated with bx seed -b 128 overlap with the ones created by Trust wallet?
据我们所知，Trust 钱包只创建 12 字 BIP39 助记符钱包，它将熵要求（因此 PRNG 用法）固定为 128 位。 bx MORE 非常灵活，可生成 128 位、192 位、256 位输出（以及其他输出）。更多的变体意味着更多的搜索空间，但是生成的 bx seed -b 128 钱包是否与Trust钱包创建的钱包重叠？

As it turns out, they do not – due to a nuance in the PRNG usage. The MT19937 Mersenne Twister algorithm used by Trust Wallet and bx is the same, but the output is consumed slightly differently.
事实证明，由于 PRNG 使用的细微差别，他们没有。Trust Wallet 使用的 MT19937 Mersenne Twister 算法 bx 相同，但消耗的输出略有不同。

When filling the entropy array with PRNG data, Trust Wallet consumes one MT19937 output of 32 bits, takes the least significant 8 bits of this output to fill the array, and throws away the other 24 bits via the & 0x000000ff bitwise-and in wasm/src/Random.cpp:
当用 PRNG 数据填充熵数组时，Trust 钱包会消耗一个 32 位的 MT19937 输出，取此输出中最低的 8 位来填充数组，并通过 wasm/src/Random.cpp & 0x000000ff 中的按位丢弃其他 24 位：

// Copyright © 2017-2022 Trust Wallet.
//

[...]

void random_buffer(uint8_t* buf, size_t len) {
    std::mt19937 rng(std::random_device{}());
    std::generate_n(buf, len, [&rng]() -> uint8_t { return rng() & 0x000000ff; });
    return;
}

Due to the C++ mechanisms used in libbitcoin-system for pseudo_random::fill(), its code performs the same 32 bits -> 8 bits truncation, but exactly the other way around – taking the 8 most-significant bits from the PRNG instead.
由于 中使用的 libbitcoin-system pseudo_random::fill() C++机制，其代码执行相同的 32 位 – > 8 位截断，但恰恰相反 – 而是从 PRNG 中获取 8 个最重要的位。

As a result, all generated bx seed outputs are – to our knowledge – in a completely different key space than what the Trust Wallet code would generate, which means the BIP39 mnemonics are also different.
因此，据我们所知，所有生成的 bx seed 输出都与Trust Wallet代码生成的密钥空间完全不同，这意味着BIP39助记符也不同。

To confirm this, here’s a quick experiment. The Ledger Donjon write-up contains a specific example wallet that they describe as follows:
为了证实这一点，这里有一个快速实验。Ledger Donjon 的文章包含一个特定的示例钱包，他们描述如下：

[...]
RNG seed: 0x8ec170a8
Mnemonic:
sorry slush already pass garden decade grid drip machine cradle call put
[...]

If we re-compute RNG seed 0x8ec170a8 with the bx code for a 12 word BIP39 mnemonic, it comes out as the following instead:
如果我们使用 12 个单词 BIP39 助记符的代码重新 bx 计算 RNG 种子 0x8ec170a8 ，它会出现如下结果：

local chef load churn future essence type leave program weird ancient owner

This confirms that the the wallet generation process is indeed different.
这证实了钱包生成过程确实不同。

In Ledger Donjon’s write-up, they close with the following line, which reads a lot like foreshadowing to us:
在Ledger Donjon的文章中，他们以以下行结束，这句话读起来很像给我们铺垫：

During our investigations, we also noticed that a few addresses were vulnerable while they had been generated a long time before the Trust Wallet release. That probably means this vulnerability exists in some other wallet implementations which is concerning…
在我们的调查过程中，我们还注意到一些地址在信任钱包发布之前很久就已经生成了。这可能意味着此漏洞存在于其他一些钱包实现中，这与…

However, we suspect the other wallets seen by Ledger Donjon weren’t wallets generated by bx 3.x versions, unless Ledger Donjon experimented a lot with the PRNG outputs and hit this other usage pattern. The presence of more affected wallets in the 12-word Trust Wallet range suggests there are yet other affected wallet generation tools out there which use MT19937, though. Due to time constraints, we did not investigate this further for the time being.
但是，我们怀疑 Ledger Donjon 看到的其他钱包不是由 bx 3.x 版本生成的钱包，除非 Ledger Donjon 对 PRNG 输出进行了大量实验并达到了其他使用模式。不过，在 12 字信任钱包范围内存在更多受影响的钱包表明还有其他受影响的钱包生成工具使用 MT19937。由于时间限制，我们暂时没有进一步调查。

When comparing our disclosure task on bx with that of Ledger on Trust Wallet, it’s notable that their disclosure was to a single, commercial, evidently well-funded wallet vendor. Based on their publications, Trust Wallet had direct communication paths to individual users that they could leverage to selectively inform them of vulnerabilities related to their wallet. Additionally, their wallet was only vulnerable for a limited amount of time, and the issue was discovered relatively quickly, with many users still regularly using the app.
当将我们的披露任务 bx 与 Trust Wallet 上的 Ledger 披露任务进行比较时，值得注意的是，他们的披露是针对一个单一的、商业的、显然资金充足的钱包供应商。根据他们的出版物，Trust Wallet与个人用户有直接的通信路径，他们可以利用这些路径有选择地通知他们与其钱包相关的漏洞。此外，他们的钱包仅在有限的时间内容易受到攻击，并且该问题被发现相对较快，许多用户仍然经常使用该应用程序。

In their post-mortem, the Trust Wallet team lists the total lost funds as $170,000 USD:
在事后分析中，Trust 钱包团队将损失的资金总额列为 170，000 美元：

Despite our best efforts, two exploits occurred, resulting in a total loss of approximately $170,000 USD at the time of the attack.
尽管我们尽了最大努力，但仍发生了两次漏洞利用，导致攻击发生时总共损失约 170，000 美元。

As we understand, Trust Wallet decided to financially incentivize users to move their funds to safety, as well as reimbursing lost funds for users affected by the theft. Additionally, they paid a significant $100,000 USD bug bounty to Ledger Donjon for the coordinated disclosure.
据我们了解，Trust Wallet决定在经济上激励用户将资金转移到安全地带，并为受盗窃影响的用户补偿损失的资金。此外，他们还向 Ledger Donjon 支付了 100，000 美元的巨额漏洞赏金，用于协调披露。

In our case, unfortunately, most of these factors did not apply. Given the Libbitcoin project’s noncommercial nature, lack of direct communication channels to end users, multiple years of affected wallets and likely widely imported/exported keys and BIP39 mnemonics, the situation was much more difficult on the security researcher side.
不幸的是，在我们的案例中，这些因素中的大多数都不适用。鉴于Libbitcoin项目的非商业性质，缺乏与最终用户的直接沟通渠道，多年来受影响的钱包以及可能广泛导入/导出的密钥和BIP39助记符，安全研究人员方面的情况要困难得多。

With the Trust Wallet & Ledger Donjon write-ups out there, all bx seed private keys compromised, and active on-chain exploitation for bx wallets ongoing, it was clear to us that a long coordinated disclosure was not beneficial. If we wanted to give affected bx wallet owners the chance to recover their funds, we would have to aim for a publication in days, not months. In this situation, time is on the side of the attackers rather than the victims.
随着Trust Wallet和Ledger Donjon的报道，所有 bx seed 私钥都被泄露，钱包的链上积极利用正在进行中，我们很清楚，长期协调的披露是没有好处的 bx 。如果我们想让受影响的 bx 钱包所有者有机会收回他们的资金，我们必须在几天而不是几个月内发布。在这种情况下，时间站在攻击者一边，而不是受害者一边。

Well-established security programs like Google Project Zero have a similar policy for actively exploited vulnerabilities:
像Google Project Zero这样的成熟安全程序对主动利用的漏洞也有类似的策略：

[…] if Project Zero finds evidence that a vulnerability is being actively exploited against real users “in the wild”, a 7-day disclosure policy replaces the 90-day policy. […]
[…]如果Project Zero发现有证据表明漏洞正在“野外”针对真实用户积极利用，则7天披露策略将取代90天策略。[…]

Ongoing On-Chain Thefts – Some Facts
持续的链上盗窃 – 一些事实

We decided to focus on Bitcoin as the main coin network for a limited analysis considering our time constraints. Due to the flexibility of bx seed output, funds on every BIP39 mnemonic (or even just BIP32 seed) compatible coin under the sun could be affected. With regular day jobs to take care of and limited time & compute resources, doing various steps 100x times wasn’t an option. This overview is therefore narrowly focused on Bitcoin, and only presents a partial view of the overall theft actions. Consider the presented figures a lower bound for the overall affected monetary value.
考虑到我们的时间限制，我们决定将比特币作为主要的硬币网络进行有限的分析。由于输出的 bx seed 灵活性，阳光下每个BIP39助记符（甚至只是BIP32种子）兼容硬币的资金可能会受到影响。由于需要处理常规的日常工作以及有限的时间和计算资源，因此无法执行 100 倍的各种步骤。因此，本概述狭隘地集中在比特币上，仅提供了整体盗窃行为的部分视图。 将所提供的数字视为整体受影响货币价值的下限。

For Bitcoin, there are two main clusters of transactions that we think were malicious:
对于比特币，我们认为有两组主要的恶意交易：

1.) The big 2023-07-12 theft:
1.） 2023-07-12 大盗窃案：

We attribute these to one well-prepared actor, who stole around ~29.65 BTC worth upwards of $850,000 USD in Bitcoin alone (8/2023 exchange rate). We think it’s likely this actor also carried out theft of other coins in the same day. At the time of writing, these funds have not moved away from their new location.
我们将这些归因于一位准备充分的演员，他偷走了大约 ~29.65 BTC，仅比特币价值超过 850，000 美元（8/2023 汇率）。我们认为该演员很可能在同一天还盗窃了其他硬币。在编写本报告时，这些资金尚未迁离新地点。

2.) There is a second, earlier pattern of fund movements that we suspect are also thefts:
2.）还有第二种更早的资金流动模式，我们怀疑也是盗窃：

This behavior started May 3rd 2023 and consisted of multiple smaller wallet sweeps which continued until July 15th. In total, we think this sweeping sums up to about 0.33 BTC. The funds have been moved again to further addresses, which differentiates this actor pattern from the first we outlined.
这种行为始于 2023 年 5 月 3 日，包括多次较小的钱包扫描，一直持续到 7 月 15 日。总的来说，我们认为这个横扫的总和约为0.33 BTC。资金已再次转移到进一步的地址，这使这种参与者模式与我们概述的第一个模式区分开来。

We have not seen any reports of stolen funds for these addresses. Theoretically, this special actor may be legitimately moving his funds from many distinct wallets (see further analysis) or he is a malicious actor. The addresses reported below are linked by being spent in the same transaction, which indicates that this a single actor or group.
我们没有看到任何关于这些地址资金被盗的报告。 从理论上讲，这个特殊行为者可能合法地从许多不同的钱包中转移资金（见进一步分析），或者他是一个恶意行为者。 下面报告的地址通过在同一笔交易中花费来链接，这表明这是一个单一的参与者或团体。

Suspected Attacker Addresses:
可疑攻击者地址：

• bc1qdmpx2th8h7l4j0z93sxnrlpuaxfvkkfxlv7n2c (0.1382 BTC)
  bc1qdmpx2th8h7l4j0z93sxnrlpuaxfvkkfxlv7n2c （0.1382 BTC）
• bc1qpnq4q7dcgvpuz8z9dy3d3jp4vuumw0hte4d32n (0.0700 BTC)
  bc1qpnq4q7dcgvpuz8z9dy3d3jp4vuumw0hte4d32n （0.0700 BTC）
• bc1qf9q85mt73sr0vzlqkvy75pyal3g5w2ca7zx3cv (0.0045 BTC)
  bc1qf9q85mt73sr0vzlqkvy75pyal3g5w2ca7zx3cv （0.0045 BTC）
• bc1q5rcm7gcl3n50q93xcwwz5una7xy89unlqhy075 (0.1147 BTC)
  bc1q5rcm7gcl3n50q93xcwwz5una7xy89unlqhy075 （0.1147 BTC）

Here’s a list with some known coins with confirmed thefts (before the publication of this disclosure):
以下是一些已知硬币的列表，这些硬币已确认被盗（在此披露发布之前）：

• Bitcoin (BTC) 比特币 （比特币）
• Ethereum (ETH) 以太坊 （ETH）
• Ripple (XRP)
• Dogecoin (DOGE) 狗狗币（狗狗币）
• Solana (SOL) 索拉纳（溶胶）
• Litecoin (LTC) 莱特币 （莱特币）
• Bitcoin Cash (BCH) 比特币现金（BCH）
• Zcash (ZEC) Zcash（ZEC）

There are likely many more coin types involved, as the additional cost to execute this attack on other coins for the affected wallets is limited to the R&D time required for identification and funds withdrawal. We hope that attackers have some increased risk of getting caught via coin-specific tracing of their identities and methods, but do not have anything to report there.
可能涉及更多的硬币类型，因为对受影响钱包的其他硬币执行此攻击的额外费用仅限于识别和提取资金所需的研发时间。我们希望攻击者通过对他们的身份和方法进行特定于硬币的跟踪来增加被抓住的风险，但没有任何可报告的内容。

Overall, our estimation is that over $900,000 USD worth of cryptocurrency assets were moved as part of the overall theft actions (@exchange rate 8/2023), although some of the drained wallets may have been taken over via other vulnerabilities.
总体而言，我们的估计是，作为整体盗窃行动的一部分（@exchange率 8/2023），价值超过 900，000 美元的加密货币资产被转移，尽管一些耗尽的钱包可能已被其他漏洞接管。

Searching for Wallets – Motivation and Limits
搜索钱包 – 动机和限制

The primary reason for rapidly searching for affected Bitcoin wallets was to assess the overall damage in terms of magnitude of stolen & remaining funds, as well as to provide technical confirmation that the vulnerability was real and the sole explanation for the initially analyzed theft. We had some hope that if we came across any substantial remaining funds, there would be a small but non-zero chance to somehow inform the rightful owner so that they could save their funds. In the planning phase, we were considering options to relay a warning message to the wallet owner via a centralized cryptocurrency exchange used for direct deposits, finding wallet owners with publicly listed addresses, or discovering some other back channels. At the very least, we could extend the disclosure time scheduled in that case while searching for options.
快速搜索受影响的比特币钱包的主要原因是评估被盗和剩余资金规模的总体损失，并提供漏洞真实存在的技术确认，以及最初分析的盗窃的唯一解释。我们有一些希望，如果我们遇到任何可观的剩余资金，将有一个很小但非零的机会以某种方式通知合法所有者，以便他们可以节省资金。在规划阶段，我们正在考虑通过用于直接存款的集中式加密货币交易所向钱包所有者转发警告消息的选项，寻找具有公开列出地址的钱包所有者，或发现其他一些反向渠道。至少，我们可以在搜索选项时延长在这种情况下安排的披露时间。

Ultimately we did not identify any substantial remaining funds above a threshold of $5000 on the Bitcoin network in the analyzed ranges related to wallets generated with bx 3.x versions, as of the disclosure publication date. It’s plausible that larger sums of funds remain on similarly affected wallets of one sort of another, with slightly different derivation paths, but we did not find them with our analysis steps so far. It is also possible that some wallet owners use additional BIP39 passphrases, which provide moderate to strong protections depending on passphrase strength and other factors and make discovery much harder.
最终，截至披露发布日期，在与版本生成的 bx 3.x 钱包相关的分析范围内，我们没有发现比特币网络上任何超过5000美元阈值的大量剩余资金。更大的资金仍然停留在一种类似受影响的钱包中，这是合理的，其衍生路径略有不同，但到目前为止，我们的分析步骤还没有找到它们。一些钱包所有者也可能使用额外的BIP39密码短语，这些密码短语根据密码短语强度和其他因素提供中等到强大的保护，并使发现变得更加困难。

We want to be very clear on the scope of our research-related actions:
我们希望非常清楚地说明我们研究相关行动的范围：

1. The two originally described victims managed to recover a small portion of their own wallet contents that had not yet been stolen, using their regular wallet setup they had before the theft.
   最初描述的两名受害者使用盗窃前的常规钱包设置，设法恢复了尚未被盗的一小部分钱包内容。
2. We did not move any funds on any of the unknown victim wallets, on any coin.
   我们没有在任何未知的受害者钱包上转移任何资金，在任何硬币上。
3. We do not know or are in any way associated with the attacker(s) that stole the funds.
   我们不知道或以任何方式与窃取资金的攻击者有关联。

In summary, none of the group members moved any funds that they were not the legal owner of, or knows the identities of the thiefs.
总之，没有一个小组成员转移了他们不是合法所有者或知道小偷身份的任何资金。

As far as we’re aware, even under ideal hypothetical circumstances, moving other people’s funds to avoid theft by bad actors can become a legal nightmare. Even in the most ideal scenario – where there is a single victim, clear ownership proofs, well-established identities on both sides, single jurisdiction and reliable private communication options – this carries a lot of risk.
据我们所知，即使在理想的假设情况下，转移他人的资金以避免被不良行为者盗窃也可能成为法律噩梦。即使在最理想的情况下——只有一个受害者、明确的所有权证明、双方公认的身份、单一的司法管辖区和可靠的私人通信选择——这也会带来很大的风险。

In our situation, the circumstances were substantially worse than the ideal case in most ways we could think of. Therefore, we saw any scenario that involved us moving anything of any value, which we didn’t own before the disclosure, as opening the floodgates of legal problems. (Remember that we’re not lawyers, and this is not legal advice; We’re also not finance folks, so this is also NOT financial advice)
在我们的情况下，在我们能够想到的大多数方面，情况都比理想情况要糟糕得多。因此，我们认为任何涉及我们转移任何价值的场景，我们在披露之前并不拥有，都打开了法律问题的闸门。（请记住，我们不是律师，这不是法律建议;我们也不是财务人员，所以这也不是财务建议）

For the adventurous reader, who would consider going ahead anyway as a “white knight” in this case, please consider the following dilemma: any attacker can recompute the owner’s private keys, which nullifies the value of any cryptographic signatures with those keys. In any scenario that involves moving a wallet owners’s funds away to a wallet you control, how do you know the person showing up in your inbox (or on your doorstep) asking to get back “their” funds is the legal owner? Particularly if there is no centralized entity, such as a big cryptocurrency exchange, that backs the claim and can provide circumstantial evidence?
对于喜欢冒险的读者，在这种情况下，他们会考虑以“白骑士”的身份继续前进，请考虑以下困境：任何攻击者都可以重新计算所有者的私钥，这会使使用这些密钥的任何加密签名的值无效。在任何涉及将钱包所有者的资金转移到您控制的钱包的情况下，您如何知道出现在您的收件箱（或您家门口）要求取回“他们的”资金的人是合法所有者？特别是如果没有集中的实体，例如大型加密货币交易所，支持这一说法并可以提供间接证据？

That’s a tough situation! And this dilemma doesn’t even touch other problems such as complying with anti-money-laundering (AML) laws, tax declarations, and a host of other aspects.
这是一个艰难的局面！这种困境甚至没有触及其他问题，例如遵守反洗钱（AML）法律，纳税申报和许多其他方面。

In case you are one of the affected victims of the theft: no, we definitely do not have your funds or know of a way to get them back. We’re sorry.
如果您是盗窃的受影响受害者之一：不，我们绝对没有您的资金或不知道取回它们的方法。很抱歉。

If it’s any consolation, we’ve worked hard to give our affected friends and all other victims at least some explanation and closure on why any funds could be stolen in the first place, and help them to avoid getting burned again by the same vulnerability.
如果有什么安慰的话，我们努力为受影响的朋友和所有其他受害者至少提供一些解释和关闭，说明为什么任何资金首先可能被盗，并帮助他们避免再次被同一漏洞烧毁。

You may use the lookup service to check if your wallet was impacted.
您可以使用查找服务来检查您的钱包是否受到影响。

Searching for Wallets – Implementation
搜索钱包 – 实施

Please note that we’re intentionally vague on some non-trivial technical details, since we need to make an ethical trade-off between sharing the technical details that are needed to shine a light on this problem, and giving bad actors an unnecessary technical advantage on day 1. Additionally, while we are big fans of Open Source, we will not release custom code we wrote for parts of the on-chain analysis at this time for similar reasons.
请注意，我们故意在一些不平凡的技术细节上含糊不清，因为我们需要在分享揭示这个问题所需的技术细节和在第 1 天为不良行为者提供不必要的技术优势之间做出道德权衡。此外，虽然我们是开源的忠实粉丝，但出于类似的原因，我们目前不会发布我们为部分链上分析编写的自定义代码。

For our exploratory research, we focused on the BIP44, BIP49 and BIP84 standard address formats and derivation paths. Our primary focus was on finding both formerly used as well as currently used Bitcoin wallets generated by bx seed | bx mnemonic-new on bx 3.x versions with common BIP39 mnemonic word phrase lengths and settings.
对于我们的探索性研究，我们专注于BIP44，BIP49和BIP84标准地址格式和派生路径。我们的主要重点是查找以前使用和当前使用的比特币钱包，这些钱包由具有常见 BIP39 助记词短语长度和设置的版本 bx seed | bx mnemonic-new 生成 bx 3.x 。

Specifically, this covers:
具体而言，这包括：

• 128 bits = 12 words, bx seed -b 128
  128 位 = 12 字， bx seed -b 128
• 192 bits = 18 words, bx seed -b 192 (default)
  192 位 = 18 字， bx seed -b 192 （默认）
• 256 bits = 24 words, bx seed -b 256
  256 位 = 24 字， bx seed -b 256

We used a publicly available list of all Bitcoin addresses historically seen by the Bitcoin network and constructed a bloom filter with a very low false positive rate on the data set. Using this filter, we were able to do quick address lookups to query and discard many unused wallet candidates, for which the relevant derived accounts were never seen by the network, without doing costly lookups to a Bitcoin full node.
我们使用了比特币网络历史上看到的所有比特币地址的公开列表，并在数据集上构建了一个误报率非常低的布隆过滤器。使用此过滤器，我们能够进行快速地址查找，以查询和丢弃许多未使用的钱包候选者，这些候选钱包的相关衍生账户从未被网络看到，而无需对比特币全节点进行昂贵的查找。

We only consider wallets where the first address was used. The standard mandates to scan the first 20 addresses, but computing addresses is a bottle-neck in our search. We also only consider wallets using the standard derivation paths specified by BIP44, BIP49, and BIP84. In total, we discovered over 2600 distinct and actively used Bitcoin cryptocurrency wallets that are based on the bad bx seed entropy.
我们只考虑使用第一个地址的钱包。 标准要求扫描前 20 个地址，但计算地址是我们搜索中的一个瓶颈。 我们也只考虑使用 BIP44、BIP49 和 BIP84 指定的标准派生路径的钱包。 总的来说，我们发现了超过2600个基于坏 bx seed 熵的不同且积极使用的比特币加密货币钱包。

The majority of these wallets, a group of over 2550, has an oddly similar usage pattern with small deposits around the same dates in 2018. We think this is the result of some automatic tool use of bx, and that these wallets may actually share the same owner. We’re not sure what this experiment was about, but they’re all in the 256 bit seed output range and have a BIP49 address type (‘3’ prefix), which helps distinguishing them a bit from other addresses.
这些钱包中的大多数，超过2550个，具有奇怪的相似使用模式，2018年同一日期的小额存款。我们认为这是一些自动工具使用 bx 的结果，并且这些钱包实际上可能共享同一个所有者。我们不确定这个实验是关于什么的，但它们都在 256 位种子输出范围内，并且具有 BIP49 地址类型（“3”前缀），这有助于将它们与其他地址区分开来。

Excluding this large number of special wallets, we’ve identified less than 50 wallets with more individual usage patterns that we associate with likely use by human wallet owners. Those are distributed across the mentioned ranges and address types. We know this survey to be incomplete, as we have not discovered all wallets involved in the sweeps we observed on the blockchain.
排除大量特殊钱包，我们已经确定了不到50个钱包，这些钱包具有更多的个人使用模式，我们将这些钱包与人类钱包所有者的可能使用相关联。它们分布在上述范围和地址类型中。我们知道这项调查是不完整的，因为我们还没有发现我们在区块链上观察到的扫描所涉及的所有钱包。

Within this set of wallets, we were able to find and identify both of the initial victim’s wallets. This gives us confidence that our research into the the explanation for the theft is correct.
在这组钱包中，我们能够找到并识别最初受害者的两个钱包。这让我们相信我们对盗窃解释的研究是正确的。

A decent portion of the discovered individually used wallets did not have any BTC funds on them since before 2023, so no money could be moved away from them by the attackers. However, we still consider them fully affected for two reasons:
自 2023 年之前以来，发现的个人使用的钱包中有相当一部分没有任何 BTC 资金，因此攻击者无法从他们身上转移任何资金。但是，我们仍然认为它们完全受到影响，原因有两个：

1. Any new deposits to them are at risk of immediate, automated theft (as outlined in the Ledger Donjon article).
   向他们存入的任何新存款都有立即自动被盗的风险（如 Ledger Donjon 文章中所述）。
2. Access to the underlying wallet private keys allows reconstructing all derived addresses on all coins, linking the wallet owner’s previous actions on all of them, a significant privacy impact.
   访问底层钱包私钥允许重建所有硬币上的所有派生地址，链接钱包所有者之前对所有硬币的操作，这对隐私产生了重大影响。

Other Confirmed Victims of this Theft
此盗窃的其他确认受害者

Within a few days after the large theft of July 12th 2023, a victim of the theft came forward on Reddit:
在 2023 年 7 月 12 日发生大宗盗窃案后的几天内，一名盗窃受害者在 Reddit 上挺身而出：

1. https://www.reddit.com/r/Bitcoin/comments/158nyuo/mass_hacking_of_over_1000_bitcoin_accounts/

The Reddit user u/0n0t0le provides an interesting data point, since he lost ~0.25BTC but was able to move away and recover over 1.05 BTC that the attackers didn’t find or take at that point.
Reddit用户u/0n0t0le提供了一个有趣的数据点，因为他损失了~0.25BTC，但能够离开并恢复超过1.05 BTC，攻击者当时没有找到或拿走。

We were able to confirm for case 1) that the user had their funds in a vulnerable wallet in the bx seed ranges.
我们能够确认案例 1） 用户的资金在范围内的 bx seed 易受攻击的钱包中。

Please note that BIP39 mnemonic secrets as well as other wallet private keys typically do not contain any clear indication on the software used to generate them. As a format designed to be exportable and importable between different wallet software, it is therefore possible that users do not clearly or correctly recall where a given wallet was created. This can lead to a lot of confusing information on potentially affected other wallet software, and makes fact-finding harder.
请注意，BIP39助记符以及其他钱包私钥通常不包含用于生成它们的软件的任何明确指示。作为一种设计为在不同钱包软件之间可导出和可导入的格式，因此用户可能无法清晰或正确地回忆起给定钱包的创建位置。这可能会导致有关可能受影响的其他钱包软件的大量令人困惑的信息，并使事实调查更加困难。

In the interest of correctness, we’re currently not listing other open leads that we’re following up on, but may update this section at a later point in time.
为了正确起见，我们目前没有列出我们正在跟进的其他未解决的潜在客户，但可能会在以后更新此部分。

Basic Timeline of Thefts and Our Disclosure
盗窃的基本时间表和我们的披露

Please note that this timeline focuses on the main events and is not exhaustive.
请注意，此时间表侧重于主要事件，并非详尽无遗。

Libbitcoin Team Response and Context
Libbitcoin团队的回应和背景

During our accelerated coordinated disclosure to the Libbitcoin team, the Libbitcoin team quickly disputed the relevancy of our findings and the CVE assignment. By our understanding, they consider bx seed a command that should never be used productively by any bx user since it is sufficiently documented as unsuited for safe wallet generation.
在我们加速向 Libbitcoin 团队协调披露期间，Libbitcoin 团队很快对我们调查结果和 CVE 分配的相关性提出了异议。根据我们的理解，他们认为 bx seed 任何 bx 用户都不应该有效地使用命令，因为它被充分记录为不适合安全生成钱包。

We do not agree with this assessment.
我们不同意这一评估。

Please consider the following timeline and linked resources:
请考虑以下时间表和链接资源：

We’re aware of a single warning note in the bx seed documentation page in the wiki:
我们知道 wiki 的文档页面中 bx seed 有一个警告说明：

WARNING: Pseudorandom seeding can introduce cryptographic weakness into your keys. This command is provided as a convenience.
警告：伪随机种子设定可能会在密钥中引入加密弱点。提供此命令是为了方便起见。

The wording “can introduce” is quite weak and a user may not be aware that this produces a seed that is completely insecure and should not be used to store anything of value.
“可以引入”的措辞非常弱，用户可能不知道这会产生完全不安全的种子，不应用于存储任何有价值的东西。

When adding bx seed related workflows to the “Mastering Bitcoin” book appendix, Libbitcoin team members described it as follows:
在将相关工作流程添加到 bx seed “掌握比特币”一书附录时，Libbitcoin团队成员对此进行了如下描述：

Generate a random “seed” value using the seed command, which uses the operating system’s random number generator. Pass the seed to the ec-new command […] $ bx seed | bx ec-new > private_key [...]
使用 seed 命令生成随机“种子”值，该命令使用操作系统的随机数生成器。将种子传递给 ec-new 命令 […] $ bx seed | bx ec-new > private_key [...]

Similarly, in “Mastering Bitcoin” Chapter 4:
同样，在“掌握比特币”第4章中：

You can also use the Bitcoin Explorer command-line tool (see [appdx_bx]) to generate and display private keys with the commands seed, ec-new, and ec-to-wif: $ bx seed | bx ec-new | bx ec-to-wif [...]
您还可以使用比特币浏览器命令行工具（参见[appdx_bx]）生成和显示带有命令 seed ec-new 的私钥，和 ec-to-wif ： $ bx seed | bx ec-new | bx ec-to-wif [...]

Neither Chapter 4 nor the Appendix contain the warning that bx seed does not produce secure random numbers. The examples do not warn the user that wallets created like this are insecure.
第 4 章和附录均不包含不产生安全随机数的警告 bx seed 。 这些示例不会警告用户像这样创建的钱包是不安全的。

We informed the authors of “Mastering Bitcoin” and they will revise the text.
我们通知了“掌握比特币”的作者，他们将修改文本。

The following Libbitcoin documentation includes bx seed:
以下 Libbitcoin 文档包括 bx seed ：

All these examples do not contain any warning that the created wallets are insecure.
所有这些示例都不包含任何警告，即创建的钱包不安全。

Other notable characteristics:
其他显著特点：

• The bx seed -b parameter cannot be configured to output less than 128 bits of binary output size. Related code comments on this limit include The minimum safe length of a seed in bits and These are soft requirements for security and rationality.. It seems strange that the design explicitly prevents the user from creating a seed that is too short, but does not prevent him from creating a seed that has not enough randomness.
  不能将该 bx seed -b 参数配置为输出小于 128 位的二进制输出大小。有关此限制的相关代码注释包括 The minimum safe length of a seed in bits 和 These are soft requirements for security and rationality. 。奇怪的是，该设计明确阻止用户创建太短的种子，但不阻止他创建具有足够随机性的种子。

General notes: 一般说明：

• Dates regarding releases and commits are taken from Git/GitHub timestamp information. This may deviate from the actual dates in some cases.
  有关发布和提交的日期取自 Git/GitHub 时间戳信息。在某些情况下，这可能会偏离实际日期。

Suspected RNG Problems in Older bx Versions
旧 bx 版本中可疑的 RNG 问题

For the main part of our short and busy disclosure, we focused on the Mersenne Twister related issues in bx versions released after March 2017.
对于我们简短而繁忙的披露的主要部分，我们专注于 2017 年 3 月之后发布的版本中的 bx Mersenne Twister 相关问题。

However, we recently observed some behavior on older bx versions before 3.0.0 that indicate other weak random number generator behavior of bx seed, in part depending on the system environment bx is executed on. Specifically, the std::random_device entropy source in combination with std::default_random_engine may not behave securely enough if the random engine uses insufficient seeding and acts as a non-CSPRNG similar to Mersenne Twister.
但是，我们最近在旧 bx 版本上观察到了一些行为 3.0.0 ，这些行为表明其他 bx seed 弱随机数生成器的行为，部分取决于执行的系统环境 bx 。具体来说， std::random_device 如果随机引擎使用不足的种子并充当类似于Mersenne Twister的非CSPRNG，则熵源组合在一起 std::default_random_engine 的行为可能不够安全。

Please regard this as preliminary indications of potential problems. It is possible that some of the public thefts exploit random number generator issues in versions before bx 3.0.0, but we have not confirmed this yet.
请将此视为潜在问题的初步迹象。一些公共盗窃可能利用了以前的 bx 3.0.0 版本中的随机数生成器问题，但我们尚未确认这一点。

We plan to follow up on this with additional research.
我们计划通过额外的研究来跟进这一点。

Part III – Summary and Outlook
第三部分 总结与展望

Basic Lessons Learned 吸取的基本教训

• Use BIP39 passphrases for your wallets, ideally with a complex passphrase based on entropy from a separate source.
  为您的钱包使用 BIP39 密码短语，最好使用基于来自单独来源的熵的复杂密码短语。
• Trust only heavily audited software to be in your wallet generation path.
  只相信经过严格审计的软件在您的钱包生成路径中。
• Document every wallet generation setup for your future self, this may be very important.
  记录您未来的自己的每一个钱包生成设置，这可能非常重要。

Summary 总结

In this article, we presented technical information of a weak entropy generation function in Libbitcoin Explorer, confirmed the practical use of the weak function for over 2600 cryptocurrency wallets on the Bitcoin Mainnet, and connected it to a recent large theft of cryptocurrency funds on multiple popular blockchains that amounts to an estimated $900k of damages. Additionally, we described the close similarities with another actively exploited vulnerability in Trust Wallet, and provided some background on the Libbitcoin Explorer context and overall timeline.
在本文中，我们介绍了 Libbitcoin Explorer 中弱熵生成函数的技术信息，确认了弱函数在比特币主网上超过 2600 个加密货币钱包的实际使用，并将其与最近在多个流行区块链上发生的大量加密货币资金盗窃联系起来，估计造成 90 万美元的损失。此外，我们描述了与Trust Wallet中另一个被积极利用的漏洞的密切相似之处，并提供了有关Libbitcoin Explorer上下文和整体时间表的一些背景。

Future Work 未来工作

• We plan further security research into bx 2.x RNG behavior.
  我们计划对 RNG 行为进行 bx 2.x 进一步的安全研究。
• We may update this page in the next days as more information becomes available.
  随着更多信息的出现，我们可能会在接下来的几天内更新此页面。

Additional References 其他参考资料

• Security bug – Mersenne Twister MT19937 usage in Intel cryptography library
  安全漏洞 – 英特尔加密库中的梅森费尔托斯特 MT19937 用法

Commercial Work 商业工作

We have not received any reward for this research and are not accepting donations.
我们没有收到这项研究的任何奖励，也不接受捐赠。

If you like our work, check out the following commercial services offered by different team members and organizations:
如果您喜欢我们的工作，请查看不同团队成员和组织提供的以下商业服务：

• Distrust, LLC 不信任有限责任公司
  • Infosec firm focusing on high risk clients
    专注于高风险客户的信息安全公司
  • Pentesting, threat modeling, hands-on security engineering
    渗透测试、威胁建模、动手安全工程
  • Full stack security evaluations and advisory retainer contracts
    全栈安全评估和咨询保留合同
  • Covers: Shane Engelman, Anton Livaja, Ryan Heywood, and Lance Vick
    封面：肖恩·恩格尔曼、安东·利瓦哈、瑞安·海伍德和兰斯·维克
• Christian Reitter 克里斯蒂安·赖特
  • Freelance InfoSec Consultant
    自由职业者信息安全顾问
  • Pentesting, Code Audits, Security Research, Fuzzing
    渗透测试、代码审计、安全研究、模糊测试
• Heiko Schaefer 海科·舍费尔
  • Focus on OpenPGP: OpenPGP CA, Sequoia PGP, OpenPGP on HSM devices (OpenPGP card, PKCS #11, PIV)
    专注于OpenPGP：OpenPGP CA，Sequoia PGP，HSM设备上的OpenPGP（OpenPGP卡，PKCS #11，PIV）

Other Notes 其他注意事项

• Included Libbitcoin code snippets are licensed under AGPLv3.
  包含的 Libbitcoin 代码片段在 AGPLv3 下获得许可。
• For other code snippets, see the included copyright notice.
  有关其他代码片段，请参阅随附的版权声明。

Credits 学分

• Core Team  核心团队
  • Distrust  怀疑
    • Anton Livaja – [email protected]
      安东·利瓦亚 – [email protected]
    • Lance R. Vick – [email protected], https://lance.dev
      兰斯·维克 – [email protected]，https://lance.dev
    • Ryan Heywood – [email protected], https://ryansquared.pub
      瑞安·海伍德 – [email protected]，https://ryansquared.pub
    • Shane Engelman – [email protected]
      肖恩·恩格尔曼 – [email protected]
  • Independent  独立
    • Christian Reitter – https://inhq.net
      克里斯蒂安·赖特 – https://inhq.net
    • Daniel Grove – [email protected]
      丹尼尔·格罗夫 – [email protected]
    • Dustin Johnson – [email protected]
      达斯汀·约翰逊 – [email protected]
    • Heiko Schaefer – [email protected]
      海科·舍费尔 – [email protected]
    • James Callahan – [email protected]
      詹姆斯·卡拉汉 – [email protected]
    • Jochen Hoenicke – https://jhoenicke.de
      约亨·霍尼克 – https://jhoenicke.de
    • John Naulty – [email protected]
      约翰·诺尔蒂 – [email protected]
    • Matthew Brooks – *@logicwax.com
      马修·布鲁克斯 – *@logicwax.com
• Special Thanks  特别鸣谢
  • Jack Kearney – Turnkey 杰克·科尔尼 – 交钥匙
  • Several trusted advisors that wish to remain uncredited. You know who you are.
    几位值得信赖的顾问希望保持不可信。你知道你是谁。

原文始发于milksad：Technical write-up