链上追踪实录

背景

应老板要求需要对两个恶意钱包地址进行分析。共计给了两个EVM地址。

 

追踪过程

1. 交互的交易所分析

- 分析得到 Gate.io，Bybit，Chain Up，COBO，Kucoin，Nexo

这里面的交易所可以通过司法调证和合作关系得到利用者数据，但是这终究是依赖别人和同事，作为最后手段使用。

- 交易所地址分析

1. 对部分交易所充值地址进行转换比如EVM->TRX，但是没有出现这种情况。

2. 对充值地址的充值进行额外关联，但是未发现其他钱包地址。

 

2. 对地址进行分析

- 时区分析 : 确认为欧洲时区

在追踪前，部门同事有了一个初步结论目标可能为某地区的用户，因此可以对提供EVM交易时段进行分析，得到用户所在时区。

- 直接关联地址分析 : 得到额外 2 个确定相同控制人钱包

对地址的gas fee分析，大额转账分析，充值交易所分析，交易品类分析，对直接关联的EOA地址进行归属权判定。

- NFT 分析 : 目标地址不参与NFT

如果目标用户参与NFT交易，通常可以进入 Discord 群组搜索该NFT id，容易得到目标人群的discord username，曾使用该方案得到某公司内员工的内幕交易行为。

- 搜索引擎分析: 目标地址未在搜索引擎出现

通过对X Google等搜索引擎进行分析，可以得到该地址的使用人账户或者其他讯息。

- 其他DAPP分析: 未发现异常

一些钱包会参与 friend.tech , debank 等应用，可以通过这些应用得到进一步个人讯息。

 

3. 跨链桥分析

- 对地址常用跨链桥进行分析

分析了包括 wormhole,hope,synapse,celer 在内的多种跨链桥，包括在arb链上进入hyper的资金进行深究，最后发现某钱包从 Axelar 得到一部分资金，来源链是 kujira ，只有 Kraken 上了这个币。钱包从 Kujira 早期就开始有交易，中间卖掉部分 Kuji 换成USDC跨链到Ethereum，但是还留了一部分USDC资金最后转走到某个地址中，这个地址是一个突破口，分析没有得到其他任何个人的Kujira地址。

1. 注册 Kraken 充值一部分ETH得到热钱包地址进行比对

https://finder.kujira.network/kaiyo-1/tx/00869efb9b35e1ed1a424082f78d9aacf6782773535804f7d80cb7134bcf7cfa

比对结果不一致，目标钱包未与 Kraken交互

2. Kujira 地址转换探究

Kujira属于cosmos系区块链，可以将地址直接转换为cosmos osmo luna等常见区块链，但是转换后无结果，我推测可能是Kujira没有和Keplr还有mintscan合作，这导致他并没有被Keplr钱包用户使用，因此用户实际上是独立的。 reddit介绍了该背景 https://www.reddit.com/r/TeamKujira/comments/1b3tmse/kujira_in_keplr_wallet/

3. IBC突破

 发现最后转走的USDC交易类型和普通转账不一致，是MsgTransfer，IBC跨链到了 NOBLE，直接到 mintscan 看NOBLE的交易，对NOBLE的地址在此进行关联区块链分析没结果，交易分析得到了一组 Deposit For Burn With Caller 交易，直接翻日志。[13]  Circle Cctp V 1 Deposit For BurnAmountstring 。 原来是CCTP的交易，USDC CCTP跨链协议参数介绍

Field	Meaning
Amount	The token amount being transferred (18999002662 in this case)
Burn Token	The hash of the burned token transaction (on source chain)
Depositor	The original address that initiated the transfer
Destination Domain	5, which maps to Solana in CCTP
Destination Caller	Solana-encoded caller address (Base64-encoded)
Destination Token Messenger	Solana token messenger address (Base64-encoded)
Mint Recipient	Solana recipient address (Base64-encoded)
Nonce	Used to avoid replaying the same message
Msg Index	Index in a batch if batched messages are used

 

 - AI解码之路

1. deepseek

ok，直接将 Mint Recipient 丢到deepseek解码，deepseek犯了严重错误导致我这里耽误了一个小时，deepseek的错误告诉我Domain ID 5 对应 Polygon 主网。但是实际上Domain ID 5对应的是 solana，详见  https://developers.circle.com/stablecoins/supported-domains 在这之后我让deepseek转换为EVM地址，多次失败，deepseek还有很严重过的错误就是evm地址是42位，他给我的结果是30位，我让他检查自己的结果，他说没错就是42位，这里可见ds多有毛病，后来solana的结果也是错误的，也给我的30位的solana地址。

2. grok

grok给了我错误的solana地址，但是比ds好，地址格式是对的

3. chatgpt

chatgpt也给了我错误的solana地址，但是我让他重新分析，他告诉我没登录没办法计算，给我了python 代码，计算得到正确的结果，其实CCTP转换代码很简单

import base64
import base58

# Base64-encoded inputs from your CCTP message
base64_inputs = {
    "Destination Caller": "",
    "Destination Token Messenger": "",
    "Mint Recipient": ""
}

# Decode Base64 to bytes, then encode those bytes to Base58 (Solana address)
decoded_addresses = {
    label: base58.b58encode(base64.b64decode(b64)).decode()
    for label, b64 in base64_inputs.items()
}

# Output the decoded Solana addresses
for label, address in decoded_addresses.items():
    print(f"{label}: {address}")

结果得到了正确地址，分析后发现是做市商 Wintermute , 不过 Wintermute 其实也对外有开放 DEX， 所以和 Wintermute无关。回头继续分析evm钱包在 bscscan 的记录，得到 mirror 的 ustc burn 记录，推测跨链回terra claic了，因此写了个脚本还原terra地址

>>> def evm_to_terra(evm_addr: str) -> str:
...     # 去掉 0x
...     evm_addr = evm_addr.lower()
...     if evm_addr.startswith("0x"):
...         evm_addr = evm_addr[2:]
...     # 转成字节数组
...     addr_bytes = bytes.fromhex(evm_addr)
...     if len(addr_bytes) != 20:
...         raise ValueError("Invalid EVM address length")
...     # Bech32 编码
...     # 先把 8bit 转成 5bit
...     data = bech32.convertbits(addr_bytes, 8, 5, True)
...     terra_addr = bech32.bech32_encode("terra", data)
...     return terra_addr
... 
>>> evm_addr = "0x84**fd"
>>> terra_addr = evm_to_terra(evm_addr)
>>> print(terra_addr)
terra1ss***0y

terra的地址有几十条转账，但是依旧没有关联到交易所账户。

 

结语

这是我分析过最难的地址，因为地址本身是做市商控制的，基本不参与链上defi也不会在社交媒体贴出来，资金的转入转出也很小心，基本是小号或者马甲账户，因此分析起来很难。