奇思妙想

Now You See Me: 抽象钱包是如何隐藏真实链上操作的

2025-10-18T00:00:00+00:00

首先声明，这里有些标题党，并不是完全隐藏，而是加大了溯源难度。在文章后半段，我会给出可操作的溯源方法。你有没有遇到过这样的情况：在一些扫链工具里，没看到巨鲸大额砸盘，但自己买的土狗代币价格却已经直线下跌。从链上看，也没发现哪个地址进行了大额卖出。本文用一个例子解释AA 钱包会让授权/发起者/资金流彼此分离，从而让部分传统扫链规则失效，并给出可操作的溯源方法。

背景介绍

先来简单复习一下以太坊的地址种类：

EOA地址：外部账户地址，由私钥控制。
智能合约地址：由合约代码控制，这类地址没有私钥，只有合约代码。

从日常链上交互的视角来看，我们可以大致地把链上买币/卖币分为以下几个步骤：

授权：授权智能合约使用你的代币。
交易：智能合约扣减你的代币，执行卖出。
转账：把卖出得到的代币转到收款人地址。

这里，通常1可以提前做，3则是一个可选项。这里可能会出现很多变体，比如：

Binance / OKX DEX 以及其他路由，可能会先把买的币转到一个中间地址，然后在一个交易内把你买到的代币转给你。
卖出的代币转到指定收款人。

一笔典型的交易如下图所示：

在这里，地址 0x5c6C6BD98573030206E9dfb70F6266FE5892Dbd0 与 Dex Router 交互，是交易的发起人、gas 支付人、收款人。 Dex Router 扣掉 BNB 后，把买的 TST 转给0x5c6C6BD98573030206E9dfb70F6266FE5892Dbd0.

上述基础的链上交互流程，大家应该都比较熟悉，接下来，我们来看一个可能的情况：

你持有 1000 USDC，想买 TST。
你通过混币的方式（跨链/交易所提取等）把 1000 USDC 转账给一个中间地址。
中间地址等待你的指令，当你执行买入，卖出或转账时，中间地址会执行相应的操作。

与上面提到的基础链上交互流程相比，这里直接参与的地址，即：交易发起人、交易 gas 支付人、收款人，都不是代币实际持有者的EOA地址。

此外，收到的代币，在控制人发起转账之前，代币还是放在中间地址的。

这正是 EIP-4337（账户抽象，AA）的工作方式。AA 钱包本质上是一个可充当钱包的智能账户，它允许“签名者、交易发起者、gas 支付者与资金持有者”分离。AA 最初的目标是提升可用性（如无原生 gas 也能交易），并非“隐藏交易”，但也确实增加了解析难度。

一开始是为了即使不在链上持有gas token时也能执行交易，但因为链上解析的复杂性，目前很多链上信息工具，均没有解析这一环节。

这就导致，虽然你在链上没有看到大额卖出，但是价格却已经直线下跌，本质上是因为你盯的是 EOA 的授权与资金流，但真正的卖出发生在一个智能账户里，让传统的扫链规则失效。一笔典型的 AA 钱包交易在这里：

为什么会看不到大额卖出？

回到开头的问题：为什么价格在跌，却在链上看不到“大额卖出”？

传统流程：

EOA地址 0x5c6C6B... ──[1) 调用 Swap 交易]──> DEX Router ──────────> AMM Pool (BNB/TST)
        ^                                                 │                         │
        |                                                 │                         │
        └────────────────[2) 买到的币转回去给EOA地址 ]───────┴─────────────────────────┘

AA流程：

主私钥持有者 ──[签名 UserOperation (离线)]──> Bundler ──> EntryPoint.handleOps ──[校验签名/费率 + Paymaster 检查]──> Smart Account (AA)
(私钥/主身份)                                                 │                                                    │
                                                              │                                                    ├─> (1) Permit/授权
                                                              │                                                    ├─> (2) Swap：调用 DEX Router
                                                              │                                                    └─> (3) Transfer：转给收款人 0xB8aa6c...
                                                              │
                                                          Paymaster ─────> Gas 支付：扣押金/代币结算

传统扫链工具的监控逻辑

传统扫链规则隐含了一个前提：授权者=发起者=gas 支付者=资金持有者=同一 EOA。于是“授权→交易→转账”都能在同一地址时间线上被看见。

监控 EOA 地址的授权交易：当一个地址发起 approve 交易时，标记为”准备交易”
追踪资金流动：监控代币从哪个地址转出、转到哪里
识别交易发起者：通过 from 字段识别是谁发起了交易
关联 gas 支付者：通过谁支付 gas 来辅助判断真实的操作者

这套逻辑对于普通的 EOA 地址交易非常有效，因为：

授权者 = 交易发起者 = gas 支付者 = 代币持有者 = 同一个 EOA 地址
所有操作都会显示在该地址的 Transaction 列表中
资金流向清晰可见

更进一步地说，回到开头，买卖本质就是交易、转账两个步骤的组合，如果扫链工具能正确解析到这两个步骤，就能正确识别出真实的操作者。

AA 钱包如何间接隐藏操作

AA 将“签名/发起/gas/资金归属”拆散：授权可通过 permit 与交易合并，调用经 EntryPoint 内部执行，发起者可能是 Bundler，gas 由 Paymaster 结算，资金暂存在 AA 钱包中并直达另一个收款地址，传统的可见性与归因链条因此断裂。

没有独立的授权交易：通过 Permit 或批处理，授权和交易合并在一次执行中，扫链工具抓不到”准备卖出”的信号
交易不出现在 Transaction 列表：AA 钱包的操作是通过 EntryPoint 合约的内部调用执行的，只会出现在 Internal Transactions 中，大多数人不会专门去查看这个标签页
发起者≠控制者：
- 链上看到的发起者可能是 Bundler 的地址
- 真正的控制者只是签了一个 UserOp，不会直接出现在链上
- Gas 由 Paymaster 支付，与实际控制者无关
资金流特征被打散：
- 代币放在智能合约地址（AA 钱包）中，而不是 EOA 地址，这里通常会被直接过滤掉
- 卖出操作在合约内部完成
- 收款可以直接到另一个地址，不经过原地址

一个具体的例子

以这笔交易为例： https://bscscan.com/tx/0xb12ce0488c5689a6c5ea2582a9bef4259723e57618893f1a32c9a0327c00a7a0 0x4Ed01522D6d4193f98F2be67460cB38078adCaaB 虽然是交易发起者，但他只负责支付gas fee。在该交易中，链上“发起者”仅是 Bundler/gas 支付相关地址；真正的操作者通过 UserOperation 间接完成了授权与卖出，这些关键信息多出现在“Internal Transactions/Logs”，而非“Transactions”列表。

监控不到任何的授权（没有独立的 approve 交易）
在 0xB8aa6c1042F7DA2eA6399fA53b0D58894c754F95 的 Transaction 列表里看不到任何记录
0xB8aa6c1042F7DA2eA6399fA53b0D58894c754F95 的操作在 Internal Transactions 中，容易被忽略
即使看到了链上可见的交易，执行方是 Paymaster，也很难直接关联到对应持有者，除非转账。

这就是为什么看到价格在跌，却找不到是谁在砸盘——因为传统的监控规则失效了。市面上扫链工具的解析逻辑，很多都没解析到这一个环节。

怎么查出是谁在砸盘？

回到最初的问题，怎么查出是谁在砸盘？一个最基本的想法是，直接从 Token 的 Transfer 事件出发，逐一排查转账。然后从浏览器中直接看， bscscan 、debank 跟 oklink 等均能较好直接语义化解析到对应交易，前提是你能找到对应的交易 hash。

但更好的办法是直接从支持的扫链工具入手：能正确解析 AA 的工具（举例，非推荐，调研时间为 2025/10/18）：

OKX DEX
Axiom
BullX

以下工具暂时无法正确解析到 AA 相关交易：

gmgn
AveAI
Photon
Binance Web3 DEX

总结

本文从”看不到砸盘者”这一实际问题出发，揭示了账户抽象钱包的工作原理：

AA 钱包本质：用智能合约代替 EOA 进行链上操作
隐藏效果：部分扫链工具依赖 EOA 交易记录，无法追踪 AA 内部操作
解决方案：使用支持 AA 解析的工具，或直接追踪 Token Transfer 事件

需要强调的是，AA 钱包的设计初衷是改善用户体验（无需持有 gas token、批量操作等），并非刻意隐藏交易。但客观上确实增加了链上监控的难度。

撰文时发现，很遗憾的是， OKX Wallet 去年6月就把 AA 钱包创建功能给关了（也许是因为快人两步导致没人用🤷），虽然不知是什么原因，但比较可惜。上述所有操作均可以通过 Coinbase Wallet 直接创建 Smart Account 直接复现。

附录

AA 钱包发起的 Swap： 0xb12ce0488c5689a6c5ea2582a9bef4259723e57618893f1a32c9a0327c00a7a0
EOA 钱包发起的 Swap：0xf3660c31d65e21912edc3aa5b2aee18ddf6304ce87bd97f8c7d609c6a693af5f

附录2: EIP-4844

解析 EVM Custom Error

2025-10-14T00:00:00+00:00

背景

Solidity 0.8.4 引入的 Custom Error 机制相比传统的 require(condition, "error message") 更节省 gas。当你看到一串十六进制数据时，如何解码出真实的错误信息？假设我们收到这样一段 revert data：

0x6e8698f20000000000000000000000009c5d7cfc31374100b03c0aebe82d5c68df901111

0x6e8698f2 是 Error Selector，0000000000000000000000009c5d7cfc31374100b03c0aebe82d5c68df901111 是 Error Data。

Custom Error

Error Selector 的生成

Custom error 的 selector 是通过对错误签名进行 Keccak-256 哈希，然后取前 4 个字节生成的：

from web3 import Web3

# 错误签名格式：ErrorName(type1,type2,...)
signature = "InsufficientFee(uint256,uint256)"
selector = Web3.keccak(text=signature)[:4].hex()
# 结果: 0xa458261b

ABI 编码规则

错误参数使用 ABI 编码：

静态类型（uint256, address, bool 等）：直接编码为 32 字节
动态类型（string, bytes, 数组等）：使用偏移量指针 + 长度 + 数据

selector 生成

def load_abi(abi_path: Path):
    with abi_path.open("r", encoding="utf-8") as abi_file:
        return json.load(abi_file)


def error_signature(error_entry: dict) -> str:
    input_types = ",".join(argument["type"] for argument in error_entry.get("inputs", []))
    return f"{error_entry['name']}({input_types})"


def print_error_selectors(abi_entries: list[dict]) -> None:
    for entry in abi_entries:
        if entry.get("type") != "error":
            continue

        signature = error_signature(entry)
        selector = Web3.keccak(text=signature)[:4].hex()
        print(f"{signature} -> {selector}")


def main() -> None:
    abi_path = Path(__file__).with_name("abi.abi")
    abi_entries = load_abi(abi_path)
    print_error_selectors(abi_entries)


if __name__ == "__main__":
    main()

所以，这个错误，其实就是TokenNotTradable(0x9c5d7cfc31374100b03c0aebe82d5c68df901111)

USDC CCTP Bridge Investigation

2024-10-01T00:00:00+00:00

背景

跨链转账协议（Cross-Chain Transfer Protocol，简称CCTP）是Circle公司开发的一种无需许可的链上工具。按照官方说法：

CCTP 旨在通过原生燃烧和铸造机制，实现USDC在不同区块链网络间的安全转移。CCTP的设计目标是提高资本效率，并在跨链使用USDC时最小化信任要求。

CCTP 不需要KYC，不需要许可，也没有额外的资金损耗。

CCTP的工作原理可以简化为三个步骤：

在源链上燃烧USDC
从Circle获取签名证明
在目标链上铸造USDC

目前，CCTP支持8个区块链网络，包括Arbitrum、Avalanche、Base、Ethereum、Noble、OP Mainnet、Polygon PoS和Solana，形成了56条独特的跨链转账路径。

支持的网络

主网	测试网
Arbitrum	Arbitrum Sepolia
Avalanche	Avalanche Fuji
Base	Base Sepolia
Ethereum	Ethereum Sepolia
Noble	Noble Testnet
OP Mainnet	OP Sepolia
Polygon PoS	Polygon PoS Amoy
Solana	Solana Devnet
Sui (即将推出)	Sui Testnet

所需确认数

官网提供了一组数据，用于描述不同链上转账所需的确认数和平均时间。

Mainnet

Source Chain	Number of Blocks	Average Time
Ethereum	~65*	~13 minutes
Avalanche	1	~20 seconds
OP Mainnet	~65 ETH blocks*	~13 minutes
Arbitrum	~65 ETH blocks*	~13 minutes
Noble	1	~20 seconds
Base	~65 ETH blocks*	~13 minutes
Polygon PoS	~200*	~8 minutes
Solana	32	~25 seconds

Testnet

Source Chain	Number of Blocks	Average Time
Ethereum Sepolia	5	~1 minute
Avalanche Fuji	1	~20 seconds
OP Sepolia	5	~20 seconds
Arbitrum Sepolia	5	~20 seconds
Noble Testnet	1	~20 seconds
Base Sepolia	5	~20 seconds
Polygon PoS Amoy	1	~20 seconds
Solana Devnet	32	~25 seconds

目标

由于业务需要，想了解从某条链上跨到另一条链时，实际到账的时间。由于上述步骤中的 Step 2 生成签名依赖 Circle 官方API，这个API我们无法感知具体情况，故需要通过其他方式来获取实际到账时间。此外，我们还想了解跨链的实际成本如何。

这里我写了一个脚本，用于获取跨链转账的实际到账时间。

当前做了以下几个方向的调研：

SOL -> EVM
EVM -> SOL

方案是先从源链中获取指定燃烧事件，然后从目标链中获取指定铸造事件，通过时间差来计算实际到账时间。

SOL -> EVM

SOL 中 CCTP Program ID 为 CCTPiPYPc6AsJuwueEnWgSgucamXDZwBd53dQ11YiKX3，其对应燃烧事件为 depositForBurn，事件结构如下：

type DepositForBurnArgs = {
    params: {
        amount: BN;
        destinationDomain: BN;
        mintRecipient: PublicKey;
    }
}

这里，我们采用debridge-finance的第三方工具解析链上数据。

import { SolanaParser } from "@debridge-finance/solana-transaction-parser";
const CCTP_PROGRAM_ID = "CCTPiPYPc6AsJuwueEnWgSgucamXDZwBd53dQ11YiKX3";
const rpcConnection = new Connection(process.env.SOLANA_RPC_URL || "");
const txParser = new SolanaParser([{ idl: CCTPIdl as unknown as Idl, programId: new PublicKey(CCTP_PROGRAM_ID) }]);
  const parsed = await txParser.parseTransaction(
    rpcConnection,
    txSignature
  );
    if (parsed && parsed.length > 0) {
        if (parsed[0].name == 'depositForBurn' && parsed[0].args ) {
            let args = parsed[0].args as DepositForBurnArgs;
            // do something
        }
    }

需要注意的是，TxFee并不包含在DepositForBurnArgs中，需要单独获取。

主函数遍历：

async function getAllTransactions() {
    const txs = await rpcConnection.getSignaturesForAddress(new PublicKey(CCTP_PROGRAM_ID), {limit: 1000});
    //console.log("Length: ", txs.length);
    for (const tx of txs) {
  
        parseTx(tx.signature).catch((error) => {
            console.error(`Error parsing transaction ${tx.signature}:`, error);
        });
        
        // wait 1 second
        await new Promise(resolve => setTimeout(resolve, 1000));
    }
}

对于EVM，我们将mintReceipt 转换为对应的EVM地址即可

function publicKeyToEthereumAddress(publicKey: PublicKey) {
    let hash = (publicKey as any)._bn as BN;
    return "0x"+hash.toString(16);
}

EVM -> SOL

对于 EVM，官方给出了另外一组合约对应的表格：

Chain	Domain	Address
Ethereum	0	0xbd3fa81b58ba92a82136038b25adec7066af3155
Avalanche	1	0x6b25532e1060ce10cc3b0a99e5683b91bfde6982
OP Mainnet	2	0x2B4069517957735bE00ceE0fadAE88a26365528f
Arbitrum	3	0x19330d10D9Cc8751218eaf51E8885D058642E08A
Base	6	0x1682Ae6375C4E4A97e4B583BC394c861A46D8962
Polygon PoS	7	0x9daF8c91AEFAE50b9c0E69629D3F6Ca40cA3B3FE

这里我们采取相同的手段即可，与 Solana 不同的是，EVM需要依靠 Filter Event的方式获取。

let transferFilterTopic = "0xddf252ad1be2c89b69c2b068fc378daa952ba7f163c4a11628f55a4df523b3ef";
let ethereumStandardAddress =  web3.utils.toChecksumAddress(web3.utils.padLeft(targetAddress, 40, '0').toLowerCase());
let padding = web3.utils.padLeft(ethereumStandardAddress, 64, '0').toLowerCase();
const filter = {
            fromBlock: fromBlock,
            toBlock: toBlock,
            topics: [transferFilterTopic, "0x0000000000000000000000000000000000000000000000000000000000000000",padding],
        };

这里，我们还有另外一个需要注意的点，L2有些链的Gas Fee需要把 L1 跟 L2加起来，才是最终消耗的Gas Fee。

async function getL2Fee(chainId: number,txId: string) {
    let method = "eth_getTransactionReceipt";
    let params = [txId];
    let rpcInstanceCfg = getConfig(chainId);
    if (!rpcInstanceCfg) {
        console.error("Invalid chain ID");
        return;
    }
    let url = rpcInstanceCfg.rpcAddress;
    let axiosInstance = axios.create({
        baseURL: url,
        timeout: 10000,
        headers: {
            'Content-Type': 'application/json'
        }
    });
    let data = {
        jsonrpc: "2.0",
        method: method,
        params: params,
        id: 1
    }
    let response = await axiosInstance.post(url, data);
    let l1Fee = response.data.result.l1Fee;
    let l2GasUsed = response.data.result.gasUsed;
    let l2GasPrice = response.data.result.effectiveGasPrice;
    let l2Fee = l2GasUsed * l2GasPrice;
    l1Fee = parseInt(l1Fee);
    if (isNaN(l1Fee)) {
        l1Fee = 0;
    }
    let totalFee = l1Fee + l2Fee;
    totalFee = totalFee / 1e18;
    //console.log(`L1 Fee: ${l1Fee}, L2 Fee: ${l2Fee}, Total Fee: ${totalFee}`);
    return totalFee;
}

总结

通过上述方法，我们可以获取到跨链转账的实际到账时间。

直接给结论。

从 SOL 跨链到 EVM 各链的平均时间/成本如下：

目标链	平均目标链mint成本(USD)	平均目标链Mint时间
Arbitrum	0.014992835	406.6
Avalanche	0.119040534	117.5
Base	0.003440751	131.4814815
Ethereum	9.390838272	161.4347826
Optimism	0.012127123	138.1
Polygon	0.002715731	101.05

以上成本还需加上 Solana 销毁 Tx 的 Gas Fee，约为0.00295 SOL = 0.45 USD

从 EVM 跨链到 SOL 各链的平均时间/成本如下：

目标链	平均目标链mint成本(transfer)	平均目标链Mint时间	官方标称时间
Arbitrum	0.009897	2204.197279	~13 minutes = 780s
Avalanche	0.113491	66.9245283	~20 seconds
Base	0.006112	1797.410072	~13 minutes = 780s
Ethereum	3.431554	1745.436975	~13 minutes = 780s
Optimism	0.002721	5731.428571	~13 minutes = 780s
Polygon	0.007612	602.18273	~8 minutes = 480s

以上成本还需加上Solana Mint Tx 的 Gas Fee，约为0.0000675 SOL = $0.00995 USD。

Chia 折腾手记

2021-06-13T02:49:59+00:00

前言

大约有一年时间没有写博客了，这段时间经历了很多事情，自己的生活也发生了很多以前没有想过的变化。一年间，主要的精力除了上班码代码之外，基本上都花在了投机市场当中。挣了不少钱，也亏了不少钱，但让我感到有些意思的，是这个 Chia 项目，想着如果不写一下的话，之后大约会忘记，于是就此执笔。

什么是 Chia ?

Chia 是一个新的区块链系统，是由 BitTorrent 之父 Bram Cohen 创立的。创立之初是觉得比特币太浪费电了（感觉这说法并不怎么靠谱），于是想搞个绿色数字货币，用硬盘来挖矿。 XCH 是 Chia 区块链系统中的代币，类比的话，大概相当于 XBT。对于 Chia 画下的大饼（智能合约、Chialisp等等）暂时按下不表，先说说他的挖矿，他的挖矿原理其实跟市面上的 FIL 挖矿不太一样，具体来说，分两步。

第一步：计算 Plot 文件（俗称 P 盘），这个过程会使用一种特殊函数（Verifiable Delay Function），根据提供的 Farmer public key 与 Pool public key 预计算一批数字。在计算过程中，需要一块高速缓存盘用于存放临时计算数据，官方推荐 SSD 作为缓存盘。由于 SSD 具有 TBW (Terabytes Written，TB写入量) 的寿命，因此该过程实质上需要消耗大量 SSD。此外，对于 CPU 也有一定要求，CPU cache越大的话，速度也就越快。
第二步：挖矿。与比特币挖矿类似，Chia 区块链的出块权利由应答 Challenge 成功的节点获得。但与比特币不一样的是，Challenge 的结果并不是由矿机计算出来的。取而代之的是，矿机会去扫描所有 Plot 文件，如果里面有能响应 Challenge 的 Plot 文件，则该 Plot 文件对应的 Public Key 获得该区块的打包权利与其对应的奖励。

Chia 的初心是想让大家用闲置的硬盘去 P 盘，并使用这些 Plot 文件去维护 Chia 区块链的稳定性。想法是好的，但在Chia 主网开启的两个月过程中，实际上算力还是逐渐向寡头集结的。截止至2021年5月14日，HPool 的 Chia 矿池算力已经达到2279PB，已经达到了全网的50%。

投机

Chia 的主网启动时间是 3 月 19 日，我大约是 20 日知道的这个消息。忘记是出于什么原因，总之就是想开始折腾，于是 21 号在研究了一番之后，往 OVHCloud 下了第一单测试机。

一、独立服务器挖矿

最开始的想法很单纯，当时主网算力增速较缓，在一番计算过后我发现，如果 Chia 币能维持在 50 美元的话，大概一个月便能收回成本。由于转账功能在 5 月 4 日才开放，本质上是在赌这个币是否能成功，于是我自己并没有花很多钱投入。最后是租了大概三台 P 盘机器，两台 48 T 的存储机器，花了大概一个月时间填满。这期间 SOLO + 矿池断断续续挖了大约 72 个币，使用的解决方案是笨拙的 rsync + bash。原理很简单，写一个监控程序将 P 盘机器中已经 P 完的文件实时传输到存储机的硬盘中，这中间为了加速传输的速度，还购买了 OVHCloud 的 Private bandwidth (虽然最后也好像没有快多少)。

二、云挖矿的尝试

由于瓶颈实际上是在 CPU 上，对于优化的方向，最开始我是想，如果能优化这个算法，提升多线程利用率就好了。在阅读完 chiapos 的源代码之后，感觉优化源代码这个方向的性价比实在太低，于是放弃，决定转向以量取胜，遂开始研究各大云厂商的产品。当时的想法是，Chia 挖矿原理无非是扫盘中的数据进行应答，并且扫盘不可能扫全部的文件内容，所以 OSS 是非常适合这项任务的，再加上云服务器的 CPU 比自己买实体矿机更是要划算许多。核心的思想也非常简单，使用 fuse 将 OSS mount 成系统的一个盘符即可。

AWS

(题外话：在我调研完 AWS 大约一个月后， AWS官方曾短暂放出过一篇 Chia on AWS 的教程，但之后估计因为合规问题删除了，原链接为：https://aws.amazon.com/cn/campaigns/chia-solution/ ，仍然能通过 archive.org 查看) 第一站当然是先调研了 AWS 的 S3 与自家 EC2 的契合度，在经过测试后发现，虽然 AWS 不愧是云服务商的中流砥柱，但价格上相对来说也比较贵，于是放弃。

GCP + GCS

那么谷歌又如何呢？经过研究之后发现，谷歌有一个抢占式实例的服务，这个抢占式实例跟 AWS on demand 差不多，都可以让你用更低（谷歌基本上是半价，AWS则是2折起）运行一个实例，但谷歌的这个实例没有办法自己报价，而且只能运行24小时，但这对我来说并没有什么影响。在前面的benchmark中我计算过，用最低配机器（N2-2vCPU,8G,1Local SSD）跑一个100 G的文件大约是8小时，在谷歌云最便宜的区域us-central1跑折算下来每T只要6.6美元。

存储方面，一开始，我曾经想使用 Google Drive，但后来发现 GD 并不支持随机读取，这就导致不可能使用 GD 进行挖矿，因为如果你想读一个文件的中间部分，也需要把一个100G文件下载下来，这显然不现实。后来就直接选用了谷歌自家的 GCS ，GCS 的收费依据文件的存储时间分四个档次，存储越久的文件，价格越低，但与之相对的，读取文件的价格也越贵。刚开始我选择的是存储最久的 ARCHIVE，事实证明这并不是一个最佳选择，在经过成本核算后改成了 CODELINE。

技术方案中，选择了最稳妥的 gcsfuse，大致运行流程也很简单：

新建一个虚拟机，把自动脚本调试完成，确保这个虚拟机一开机就开始进行 P 盘并上传到 GCS 指定 bucket 中，在这个阶段，我使用的是 rclone。有一点需要注意的是，实例默认创建时是没有 gcs 的权限的，如果遇到权限问题，不妨再检查一下虚拟机对 API 的权限设置。
新建一个虚拟机模版，原型镜像就选上面那个虚拟机，然后把实例类型改为抢占式实例。
新建一个实例组，然后拉满起飞。

由于实例组会帮我们自动维护实例的生命周期，所以如果一个文件完成上传，或者因为抢占式实例被关闭，也能自动重启打开，这就完成了 P 盘第一步。

挖矿方面，也有一些坑需要注意的。

第一个问题就是在bucket的文件超过 500 T 之后，可能经常会遇到超时的问题。

首先，需要把gcsfuse的http2关闭，这是第一个坑，但因为比较少人复现，gcsfuse的issue中并没有人解决这个问题，后来经过debug发现就是http2的问题。

在解决了 http2 后，扫盘也会间歇性的超时，这个问题无法避免，我一开始采用的方案是分 bucket 放文件，后来改了一下 gcsfuse，让每个被 mount 的 bucket 可以有不同的 offset，解决了问题。

最后在折腾了半个月后，我的最终解决方案是 docker + hpool的挖矿程序，每个文件夹独立分配一个docker的容器，然而这个时候 xch 已经从每 PB 10个 xch 跌落到 0.33 个 xch 了。

假算力

// TODO

Secure key establishment and management

2020-04-29T07:30:59+00:00

Agenda

Ad Hoc Network Key Establishment
Key Distribution in Large-scale Network

Ad Hoc Network Key Establishment

What is Ad hoc network?

In a ad hoc network, each device acts as a router. Anyone can join and leave in the middle. The range, location of them can be totally different. It is almost impossible to predict the structure of network. We need to run a routing protocol to discover the path through network. The resources in those node usually has few resources.

Ad hoc network properties

Mobile
Wireless communication
No fixed infrastructure
Participants from different administrative domains
Medium to high computation, memory
Usually human user with each device

Typical Key Establishment

SSL/TLS

Assumption: Browser can authenticate server’s certificate with its local CA root certificates

Large-group key distribution

Assumption: Each client already has a secure connection to key distribution server

The challenge in ad hoc networks: establish keys without any prior trust relationships

Problem definition

Goals

Secure, authenticated communication between devices that share no prior context
Demonstractive identification: ensure to human user which other device they are communicating with

For example, if I have an Apple device and I walk to a room which contains an Epson projector. It is hard to tell whether the projector is the one that I want to connect. There may exists another Epson projector in other room which hijacks and relays the connection.

Conditions

No CAs or other trusted authorities
No PKI
No shared secrets
No shared communication history

The problem reduces to key establishment.

Diffie & Hellman tells us how to share secret.

Diffie-Hellman Key Agreement

Public values: large prime $p$, generator $g$

Alice has secret $a$, Bob has secret $b$

A -> B: $g^a mod p$

B -> A: $g^b mod p$

Bob: ${(g^a mod p)}^b mod p = g^{ab} mod p$

Alice: ${g^b mod p}^a mod p = g^{ab} mod p$

$g^{ab} mod p$ is the final key.

Eve cannot compute $g^{ab} mod p$, even she observe all messages.

But we are not done. The problem is Man-in-the-middle attack.

MitM Attack

Mallory can impersonate Alice to Bob, and impersonate Bob to Alice.

     g^a        g^m2
A --------> M --------> B
  <-------    <--------
   g^m1   m1,m2  g^b

   g^am1         g^bm2

B can listen this message, since it is a boardcast message.

By the time when M is sending the impersonated message, B may said he is already received this message.

How does M prevent it?

ARP posioning. When M send ARP message, A think M is B and B think M is A.
Change wireless channel. KRACK attack (2018). The attacker forces A to use channel 1 and B to use channel 2.

How serious is MitM attack?

Wireless communication is invisible
- People can’t tell which devices are connected
Neighbor can easily execute MitM attack
- If neighbor has a faster computer, it can easily respond faster than the legitimate devices

Easy to perform with high success rate.

Solution to MitM attack

Authentication
Public DH values must be authenticated
Tradeoffs between security, usability, and transparency to the user
- Transparency
  - Does the user realize she is involved in a key establishment protocol?
  - Does the user need to realize this?

Key Agreement in P2P Wiresless Networks

Source: Key agreement in peer-to-peer wireless networks. Mario Cagalj, Srdjan Capkun, Jean-Pierre Hubaux.

Use Diffie-Hellman to establish keys
Present three techniques to combat MitM
- Visual comparison of short strings
- Distance bounding
- Integrity codes
All 3 verify the integrity of DH public parameters $g^A$ and $g^B$

Commitment schemes

Commitment semantics

Binding
Hiding

\[(c, d) <- commit(m)\]

m: message; c: commitment; d: opening value

A want to commit the message, but doesn’t weant to reveal the message. So A send $c$ first to B, and send $d$ after. By sending $d$, A is revealing the message $m$, and also B knows A is commiting the message $m$ by $c$.

Given $c$, infeasible to find the decommitment $d’$

It is infeasible to find $d’$ s.t. $(c, d’)$ reveals $m’ \neq m$

Example

$c=H(m r)$ where $r$ is a random number
$d = m,r$

Simple Protocol: String Comparison

Public values: large prime $p$, generator $g$
Alice has secret $a$, Bob has secret $b$
A -> B: $g^a mod p$
B -> A: $g^b mod p$
Alice and Bob computer: $g^{ab} mod p$
Alice’s and Bob’s devices display last 20 bits of $H(g^{ab} mod p)$ and they manually compare them (5 hexadecimal digits), if they match, the both click “ok”.

Is it a secure protocol?

No! Birthday paradox.

Shortcomings of Simple Protocol

First, Alice and Bob may not really compare the strings, but simply click “ok”, how to avoid this?
Knowing $g^a$ and $g^b$, attack can computer $g^c$ and $g^d$ such that $H(g^{ac}){n} = H(g^{bd}){n}$
- Complexity: Only $ O(2^{n/2}) $, around 1000.

iOS 越狱插件开发

2020-04-29T07:30:59+00:00

https://stackoverflow.com/questions/18776718/jailbreak-app-how-can-i-distribute-my-app-which-need-to-be-install-in-applicat

https://stackoverflow.com/questions/9261945/ios-explore-other-application-folder-with-jailbreak

iOS Nintendo Switch Online app 闪退的解决方法

2020-03-29T09:49:59+00:00

任天堂的 iOS 手机 app Nintendo Switch Online 具有与 switch 联动的功能，但鉴于任天堂一贯对黑客精神的严防，这个 app 在 iOS 上实行了非常严格的越狱检测，甚至连你重启恢复未越狱状态也不行，各种反越狱检测插件自然也不行。

研究了一会，发现唯一的办法就是安装 SnapBack 插件，恢复被越狱修改的 rootfs 分区。具体操作很简单，先安装 SnapBack 插件，然后点击右上角的 + 号创建一个 APFS 快照，然后回退到原始orig-fs中，此时 SnapBack 会进行一段进度条，进度条结束后会黑屏，退出 SnapBack 你会发现所有越狱 app 的名字都消失了，此时直接打开 app 即可。

iOS 越狱史及技术简析 - iOS 2

2019-12-15T20:15:59+00:00

回顾

在上一篇文章中，我们已经提到了苹果对 iOS 1 的安全保护正在一步一步进化中。截止 iOS 1.1.5，从上至下层级排列，iOS 的安全措施如下

名称	出现版本	说明
Secure Boot	iOS 1.0	启动链的每个环节都会负责验证下一阶段的签名
fsroot 只读	iOS 1.0	系统盘 /dev/disk0s1 默认是只读的
AFC Restriction	iOS 1.0	iPhone 通过 AFC 服务与电脑进行数据交换，这个服务默认只允许宿主机访问`/Media`目录
固件加密	iOS 1.1	`IMG2`格式的系统固件通过`Key 0x837`被加密
mobile 用户	iOS 1.1.3	在此之前，所用应用程序均使用`root`权限运行

随后，2008 年 7 月 1 日，苹果推出了 iOS 2 更新，同时推出了 iPhone 3G，更重要的是，App Store 开始内置在 iPhone 内，这意味着用户可以自己下载并安装应用程序了。相对应的，iOS 新增了以下安全机制:

iOS 越狱史及技术简析 - iPhone OS (iOS 1)

2019-12-13T05:27:59+00:00

本文是对自己这么多年以来对 iPhone 越狱学习的一个总结。

总是谈越狱越狱，结果自己连基本核心都没有搞太懂，于是就想从技术角度回顾一下越狱这么多年都做了些什么，也希望能帮到有相同兴趣的人。

iPhone OS (iOS 1.0) - 2007 年 10 月

当时，iOS 还被叫做 iPhone OS ，预装在 iPhone 第一代里面。没有 App Store，只有一些基础应用，当然，也没有办法安装新的应用。

苹果一开始的想法是用户只需要使用 Safari 访问 HTML5 应用就够了，所以他们并没有提供 iPhone SDK。这个阶段越狱团队的工作一方面是逆向 iPhone 自带的应用程序，搞清楚 iPhone 原生应用程序是如何工作的，然后提供一套工具链用于开发自制的第三方应用¹（事实证明，后来苹果发布的 SDK 就是这套东西），一方面是取得系统 root 权限，然后安装自制铃声和应用程序。

一个远古第三方自制程序是这样写的

#import <CoreFoundation/CoreFoundation.h>
#import <Foundation/Foundation.h>
#import <UIKit/UITableColumn.h>
#import <UIKit/UISwitchControl.h>
#import <UIKit/UIAlertSheet.h>
...
void progressCallback(unsigned int progress, unsigned int total, char* formatString, void* application) {
    UpgradeApplication* myApp = (UpgradeApplication*) application;
    [myApp doProgress:progress withTotal: total withFormat: formatString];
}
...
@implementation UpgradeApplication

- (void) applicationDidFinishLaunching: (id) unused
{
    UIWindow *window;
    UIView *mainView;
    struct CGRect rect;
    ...
}

这个时候的 iPhone 的安全机制如下:

安全引导链（每个引导环节，都会由上一个引导环节检查签名，但bootrom此时不会检查LLB的签名²）
fsboot 默认只读
AFC 默认只能访问并读写 /Media（即/var/root/Media)²
lockdownd 激活锁，防止第三方运营商 SIM 卡使用 iPhone

所有应用程序都放在/Application下，并默认以root权限执行，没有代码签名，甚至刷机不会校验 SHSH（iPhone 一代），这意味着你可以随便降级，所以在这个阶段，越狱实际上是非常简单的。

iBoot cp-command

iOS 版本: iOS 1.0 - iOS 1.0.2

利用软件: iBrickr (Windows) / AppTapp Installer (Mac OS X)

严格意义上来说，这并不算一个漏洞，而更像是一个 feature。起因是 Apple 并没有删除恢复模式中的很多命令，比如cp。

流程大致如下：

让设备进入恢复模式，从固件中找出 Restore Ramdisk 和 kernelcache，然后上传到设备上。
创建两个文件 /var/root/Media/fstab 和 /var/root/Media/Services.plist，后者会创建一个新的服务com.apple.afc2，允许通过AFC访问所有文件目录。
将 /dev/disk0s1 挂载到 /mnt1，用户数据/dev/disk0s2挂载到/mnt2，然后把我们上一步创建的两个文件用cp分别替换掉/mnt1/etc/fstab和/mnt1/System/Library/Lockdown/Services.plist
iBrickr 还会安装 PXLDaemon 守护进程，这个守护进程可以与电脑端 iBrickr 通信，安装第三方软件包，替换铃声等等。而 AppTapp Install 则会安装 Installer.app，其功能与前者大致相同。
重启完成越狱。

修复：

在 iOS 1.0.2 后更新 iBoot，删除了cp以及其他一些命令。

libtiff-exploit (CVE-2006-3459)

iOS 版本: iOS 1.0 - iOS 1.1.1

利用软件: AppSnapp / JailbreakMe 1.0

核心原理是经典的 buffer overflow — libtiff 在处理 tiff 文件的时候会发生 buffer overflow，允许任意代码执行，只需要让用户访问一个含有tiff图片的网站就可以完成越狱。

碰巧的是，当年 PSP 也饱受 tiff 漏洞的摧残，这个漏洞应该是从 PSP 的破解中收到了启发。

shellcode 做了一些微小的工作:

将/var/root/Media重命名为/var/root/oldMedia
创建符号链接/var/root/Media/ -> /
重新挂载/dev/disk0s1为读写

    stack.Add(Node(0, Node::PTR));           // r0 = "/var/root/Media"
    stack.Add(Node(1, Node::PTR));           // r1 = "/var/root/Oldmedia"
    stack.Add(Node(20, Node::BYTES));        // r2,r3,r5,r6,r12
    stack.Add(Node(12, Node::STACK));        // sp    -> offset 12
    stack.Add(ldmia_sp_r4);                  // lr = load r4,r7,pc from sp
    stack.Add(rename);                       // pc = rename(r0, r1)

    ...

    stack.Add(Node(2, Node::PTR));           // r0 = "/"
    stack.Add(Node(0, Node::PTR));           // r1 = "/var/root/Media"
    stack.Add(Node(20, Node::BYTES));        // r2,r3,r5,r6,r12
    stack.Add(Node(12, Node::STACK));        // sp -> offset 12
    stack.Add(ldmia_sp_r0);                  // lr = load from r0..pc from sp
    stack.Add(symlink);                      // pc = symlink(r0, r1)

    stack.Add(Node(3, Node::PTR));           // r0 = "hfs"
    stack.Add(Node(2, Node::PTR));           // r1 = "/"
    stack.Add(Node(0x00050000, Node::VAL));  // r2 = MNT_RELOAD | MNT_UPDATE
    stack.Add(Node(8, Node::STACK));         // r3 = **data
    stack.Add(mount);                        // pc = mount(r0, r1, r2, r3)
    stack.Add(Node(4, Node::PTR));           // data = "/dev/disk0s1"

完整代码可以在这里看到。

修复：

更新 libtiff 库。

mknod-vulnerability

iOS 版本: iOS 1.1.2

利用软件： OktoPrep + touchFree

iOS 1.1.2 版本之后，Apple 修复了 libtiff 和 iBoot cp-command 的漏洞，然而，因为前文所提到的，iPhone 第一代可以随便刷机，所以新版的方法也很简单粗暴：先在 iOS 1.1.1 动手脚，然后升级到 iOS 1.1.2 继续搞事情。

具体来说：

在 iPhone 升级之前，OktoPrep 使用mknod /var/root/Media/disk c 14 1直接在用户盘符创建一个字符设备，这句命令的意思是，为主设备号是14，次设备号是1的设备创建一个在/var/root/Media/disk的字符设备，这等同于/dev/rdisk0s1。（可以使用ls -lR /dev查看主次设备号）
升级系统到 iOS 1.1.2，由于升级系统只更改fsroot，而我们创建的文件在用户数据分区中，所以不受影响。
touchFree 检查 /var/root/Media/disk 是否存在，然后创建/var/root/Media/touchFree文件夹，复制必要文件到此文件夹中。
将/var/root/Media/diskdump为rdisk0s1.dmg，挂载这个dmg文件，修改/etc/fstab
往com.apple.syslogd.plist里面添加DYLD_INSERT_LIBRARIES:/var/root/Media/touchFree/planetbeing.dylib环境变量键值对（熟悉逆向的朋友们可能已经猜到了，没错，syslogd在下一次执行的时候会首先被注入这个动态库。）
动态库会将touchFree文件夹里的东西复制到/bin，创建 AFC2 服务，运行/var/root/Media/touchFree/run.sh脚本，然后把自己的注入环境变量删掉。
脚本会继续复制Installer.app和ssh服务，然后给Springboard和lockdown打补丁。

其中，Springboard 补丁是因为当时 Springboard 显示的程序是写死在allowedDisplayIcons里的，所以需要给[SBIconModel addItemsToIconList: fromPath: withTags:]和 [SBIconController relayoutIcons]里面打补丁，让Installer.app能显示在主屏幕，而lockdown的补丁主要是绕过iPhone激活锁。

修复: /dev/rdisk0s1被加上了nodev，所以不能再用mknod创建它的设备文件了。

Ramdisk Hack

iOS 版本: iOS 1.1.3 - 1.1.5

利用软件: ZiPhone & iLiberty

从 iOS 1.1 开始，iPhone 新增了以下安全机制:

新增mobile用户，大部分进程都开始以mobile权限运行。（iOS 1.1.3）
所有固件都被Key 0x837加密了

这意味着即使应用出现了 libtiff 的 userland 漏洞，也不再能一招吃遍天了。

这次出现的漏洞还是在恢复模式中。之前 Apple 把 cp 之类的调试命令删掉了，但是，他们还留了一个boot-args环境变量。我们知道，恢复模式需要挂载一个 Ramdisk，这个 Ramdisk 在一般情况下是需要验证签名的。但如果 Ramdisk 的内存地址超过了0x09C00000，则无论什么情况下都会启动。

这回我们轻车熟路了，以ZiPhone为例：

AFC 复制必要文件到/var/mobile/Media
重启进入恢复模式，设置引导环境变量setenv boot-args rd=md0 -s -x pmd0=0x09CC2000.0x0133D000（以单用户模式、安全模式启动）
发送bootx，让 iPhone 从 Ramdisk 启动

Ramdisk 首先挂载/dev/disk0s1，/dev/disk0s2，然后复制一些必要的文件，同时修改/etc/fstab，开机启动prof.sh

if [ "`/usr/bin/nvram jailbreak 2>/dev/null|/bin/cut -f 2`" == "1" ] ; then
/bin/echo "Starting jailbreak..."
/bin/cp /bin/sh /mnt1/bin/sh
/bin/cp /bin/sync /mnt1/bin/sync
/bin/cp /bin/rm /mnt1/bin/rm
/bin/cp /zib/prof.sh /mnt1/private/etc/profile
/bin/cp /zib/fstab /mnt1/private/etc/fstab
…
fi

重启，prof.sh会完成之后的一系列操作，比如给Springboard打补丁什么的。

修复: boot-args从iOS 2.0开始，在生产环境中不生效。（这一点可以从 iBoot 泄露的源码中看出）

// iBoot/apps/iBoot/main.c
bool
env_blacklist_nvram(const char *name)
{
    static const char * const whitelist[] = {
        ...
#if DEVELOPMENT_BUILD || DEBUG_BUILD
        "boot-args", // factory needs to set boot-args
#endif
        ...
        NULL
    }
    ...
}

总结

本文回顾了 iPhone OS 中大部分已经公开并使用的越狱工具与他们的利用方法，以及苹果的修补方法。

虽然 iPhone OS 离我们已经有一轮年头了，但从上面的做的事情中，我们可以看出，实际上，越狱所做的东西还是没有变化太多。

就以本文所有越狱工具为例，基本上就做这么几件事:

修改 /etc/fstab，挂载系统盘为rw
安装一个软件包管理器(Installer.app)，然后安装第三方软件
给系统打补丁（解锁，换壁纸，铃声）

为了做这些事情，我们需要:

修改系统文件
破坏 iOS 引导链

在之后长达 12 年中，围绕着这两件事情，苹果跟安全研究员们展开了斗智斗勇。

参考资料

[1] https://www.peerlyst.com/posts/ios-jailbreaks-history-part-1-ivan-ponurovskiy?trk=profile_page_overview_panel_posts

[2] https://www.theiphonewiki.com/

[3] http://blog.iphone-dev.org/

iPhone Open Application Development, 2nd Edition by Jonathan Zdziarski ↩
这里的/Media指的是/root/Media而并非我们熟知的/var/mobile/Media，因为mobile用户在iOS 1.0-1.1.2中暂时还不存在，下同。 ↩ ↩²

无SHSH将iPhone5S降级到10.3.3

2019-12-01T07:36:59+00:00

前几天琢磨着写一篇有关 iPhone 越狱的文章，奈何手里没有越狱机器，只有一台 iPhone 5S，但这台机器作为信息转发机早已被我升级到 iOS 13。无奈之下，只好亲自动手开始降级。

我从红雪时代开始就再也没有接触过 iPhone 降级这种事情了，所以遇到了不少坑，在这里我会将这些坑一一记录下来。

0x01 常见疑难解答

Q: 为什么可以降级？不是说 iPhone 一旦苹果服务器关闭某个版本的验证之后就不能刷机了吗？

A: 因为 checkm8 漏洞的出现，使得DFU模式可以传入自制 iBEC/iBSS，从而破坏整个引导链，最后进入刷机。

Q: 为什么不降级到更早的版本？比如iOS 7.1.1？

A: 苹果已经关闭那些版本的激活服务器，如果强行刷入，即使通过越狱删除系统文件进入界面，也会失去通信功能与iCloud相关功能。

同时，这个刷入 iOS 10.3.3 利用的似乎是OTA包，而不是普通的刷机包，所以可以实现无引导启动。如果刷入别的固件，可能需要每次手动进入DFU模式引导才能启动。这是一个猜测，暂时还没有验证。

0x02 步骤

目前市面上已经有不少工具支持降级，其中我使用的是https://devluke.gitlab.io/stablea7/。

这个工具将安装依赖与刷机集成到一个文件中，只需通过一个命令即可以自动下载并安装所有依赖：

bash <(curl -s https://gitlab.com/snippets/1907816/raw)

在实际操作过程中，需要下载所对应设备的10.3.3系统固件，比如我的是iPhone6,1，那么我要下载的固件就是iPhone_4.0_64bit_10.3.3_14G60_Restore.ipsw。

要注意的一点是，这个工具只支持 mojave 和 catalina。

之后根据实际操作进入DFU模式，然后它会要求你选择降级方式，有两种方法可以选择：

Normal/Auto
/rsu

其中方法2需要futurerestore加载额外的dylib，这个方法成功率非常高，但我不知道为什么futurerestore非得读取根目录，由于这个原因，我们需要关闭macOS的rootless功能，并且给予root权限。

之后它会调用ipwndfu尝试进入pwned模式，这个步骤可能会循环很久，因为堆风水并不一定能保证一次成功。总而言之，进入之后，它就会开始发送iBEC/iBSS，如果成功载入上述引导，设备会显示绿色屏幕，然后一路回车直接刷机。（理想情况）

0x03 遇到的问题

一阶段没有显示绿色屏幕/iBEC卡在80%左右（如下所示）

==> Sending test file to device...
[==================================================] 100.0%
==> Sending patched iBSS/iBEC to device...
[=============================================     ] 81.5%

解决方法：换线！

没错，就这么简单粗暴。我是新款MacBook Pro，用了一根usb-c的线，折腾了好久，绝望之下死马当活马医，找来一根usb-a的转换器，换了一根usb-a的线，结果就成功了。

dyld: Library not loaded

umi@umi StableA7 % bin/futurerestore --exit-recovery
dyld: Library not loaded: /usr/local/opt/usbmuxd/lib/libusbmuxd.4.dylib
  Referenced from: /Users/umi/Desktop/1033-OTA-Downgrader/new/StableA7/bin/futurerestore
  Reason: image not found

解决方法：下载libusbmuxd.4.dylib。

这里，如果你安装了高版本libusbmuxd.6.dylib，千万不要自作聪明建立软链接，这样futurerestore可以成功执行，但一旦刷机，就会报错。

卡在Checking filesystem (15)

Personalizing IMG4 component iBoot...
Personalizing IMG4 component RestoreSEP...
Personalizing IMG4 component SEP...
Sending NORData now...
Done sending NORData
About to send RootTicket...
Sending RootTicket now...
Done sending RootTicket
Waiting for NAND (28)
Checking filesystems (15)

解决方法：等

激活iCloud时提示KVS synchronizeWithCompletionHandler failed

解决方法：按下 Home 键，选没有Apple ID，进入桌面后注销重新登录。

Implement a strace equivalent using DynamoRio Framework

2019-10-14T19:41:12+00:00

cs5231的大作业，要求写一个 DynamoRio Client 实现strace的无参数版本，其输出必须与strace一模一样，在实现过程中遇到了不少坑，在这里记录一下。

简介

strace && ptrace

strace 是一个追踪程序系统调用的系统实用工具。

以执行strace date为例，其输出大致如下:

execve("/bin/date", ["date"], 0x7ffe396958a0 /* 57 vars */) = 0
brk(NULL)                               = 0x5599fa9db000
access("/etc/ld.so.nohwcap", F_OK)      = -1 ENOENT (No such file or directory)
access("/etc/ld.so.preload", R_OK)      = -1 ENOENT (No such file or directory)
openat(AT_FDCWD, "/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) = 3
fstat(3, {st_mode=S_IFREG|0644, st_size=86799, ...}) = 0
mmap(NULL, 86799, PROT_READ, MAP_PRIVATE, 3, 0) = 0x7f3e75b65000
close(3)                                = 0
access("/etc/ld.so.nohwcap", F_OK)      = -1 ENOENT (No such file or directory)
openat(AT_FDCWD, "/lib/x86_64-linux-gnu/libc.so.6", O_RDONLY|O_CLOEXEC) = 3
...

strace工具的核心是系统的ptrace。

ptrace也是一个系统调用，只需调用它，即可观察一个程序的系统调用。

详细的说，strace首先fork()一个子进程，然后给子进程设置一个标志PTRACE_TRACEME后使用execve执行目标进程。

之后父进程将会等待，子进程的每一个系统调用都会先返回该系统调用号和寄存器状态给父进程，父进程接着解析并打印相关信息。

DynamoRio

DynamoRio是一个动态二进制分析框架，它可以在程序执行的时候插入额外的分析代码，同时不影响程序正常运行效率。

具体原理是：DynamoRio将程序的执行流由原来的结构转移到代码缓存中，在这个缓存里，代码可以被任意修改，之后再进行模拟执行。

DynamoRio Client

Client 与 DynamoRio 的关系如上图所示。

一个 Client 的运行方式为:

drrun -c libstrace.so -- ls

开工

TL;DR

每个syscall中如果该参数是结构体，那么结构体的指针存在arg->value64中，仅能在event_post_syscall才能拿到

了解了以上信息之后，就可以大概知道我们要干什么了。

获取每个syscall及其相关信息
解析相关信息

实现

DynamoRio 中有一个框架叫做 Dr.Memory，其中的 Dr.Syscall 就是我们所需要的。

首先我们需要声明一个 Client 的 main 函数，注册回调函数。

DR_EXPORT void dr_client_main(client_id_t id, int argc, const char *argv[])
{
    freopen("/dev/null", "w", stdout);
    // 关闭stdout
    drsys_options_t ops = {sizeof(ops),0};

    drmgr_init();
    dr_register_filter_syscall_event(event_filter_syscall);
    drmgr_register_pre_syscall_event(event_pre_syscall);
    drmgr_register_post_syscall_event(event_post_syscall);
    if (drsys_init(id, &ops) != DRMF_SUCCESS)
        DR_ASSERT(false);
    dr_register_exit_event(event_exit);

}

参数处理

之后每次目标程序呼叫系统调用时，DynamoRio都会截取并返回给我们的回调函数处理。

static bool event_pre_syscall(void *drcontext, int sysnum)
{

    drsys_syscall_t *syscall;
    const char *name = "<unknown>";
    if (drsys_cur_syscall(drcontext, &syscall) == DRMF_SUCCESS){
        drsys_syscall_name(syscall, &name);
    }
    
    char* buf = malloc(sizeof(char)*OUTBUF_SIZE);

    drsys_iterate_args(drcontext, drsys_iter_arg_cb, buf);
    char *final = malloc(sizeof(OUTBUF_SIZE));

    sprintf(final,"%s(%s)",name,buf);
    dr_fprintf(STDERR, "%-39s",final);

    return true; /* execute normally */
}

由于需要跟strace的输出保持一致，在这里使用了一个buf来保存最后输出。使用drsys_iterate_args遍历参数，对于每个参数都会调用我们的自定义函数drsys_iterate_arg_cb。

static bool drsys_iter_arg_cb(drsys_arg_t *arg, void *user_data){
    if (arg->ordinal == -1)
        return false;
    //...
}

对于每个参数，其类型存在arg->type中，实测不支持太多Linux类型，所以只能按syscall的大分类一个一个处理过去。

第一个坑是struct。以fstat为例：，他的第二个参数是一个struct stat。如果按照一般类型处理的话，arg->value里面存的应该就是内容，然而如果是struct的话，里面似乎是全是垃圾。

那么来看看另外一个回调函数drsys_iter_memarg_cb，又如何呢？

static bool drsys_iter_memarg_cb(drsys_arg_t *arg, void *user_data){
    char* buf = (char*)user_data;
    sprintf(buf,"[%s]",arg->value);

}

测试了一下，里面是NULL，陷入了僵局。

没办法，看看drstrace它怎么实现的打印struct:

static bool
drstrace_print_info_class_struct(buf_info_t *buf, drsys_arg_t *arg)
{
    char buf_tmp[TYPE_OUTPUT_SIZE];
    drsym_type_t *type;
    drsym_type_t *expand_type;
    drsym_error_t r;

    r = drsym_get_type_by_name(options.sympath, arg->enum_name,
                               buf_tmp, BUFFER_SIZE_BYTES(buf_tmp),
                               &type);
    if (r != DRSYM_SUCCESS) {
        NOTIFY("Value to symbol %s lookup failed", arg->enum_name);
        return false;
    }

    r = drsym_expand_type(options.sympath, type->id, UINT_MAX,
                          buf_tmp, BUFFER_SIZE_BYTES(buf_tmp),
                          &expand_type);
    if (r != DRSYM_SUCCESS) {
        NOTIFY("%s structure expanding failed", arg->enum_name);
        return false;
    }
    if (!type_has_unknown_components(expand_type)) {
        NOTIFY("%s structure has unknown types", arg->enum_name);
        return false;
    }

    if (arg->valid && !arg->pre) {
        if (arg->value64 == 0) {
            OUTPUT(buf, "NULL");
            /* We return true since we already printed for this value */
            return true;
        }
        /* We're expecting an address here. So we truncate int64 to void*. */
        print_structure(buf, expand_type, arg, (void *)arg->value64);
    } else {
        return false;
    }

    return true;
}

static void
print_structure(buf_info_t *buf, drsym_type_t *type, drsys_arg_t *arg, void *addr)
{
    ...
    if (type->kind == DRSYM_TYPE_VOID) {
            OUTPUT(buf, "void=");
            safe_read_field(buf, addr, type->size, true);
            return;
    } else if (type->kind == DRSYM_TYPE_PTR) {
    ...

得，看样子struct的指针存在arg->value64里面，不是我想象的垃圾。

那打印arg->value64地址所在的内存出来看看吧：

fstat,[ordinal1][0x00007f5080f4b7d0]:
-----------------begin-------------------
05 00 00 00 00 00 00 00 91 1a d4 80 50 7f 00 00 
01 00 00 00 05 00 00 00 02 00 00 00 00 00 00 00 
01 00 00 00 90 00 00 00 02 00 00 00 00 00 00 00 
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
------------------end-------------------
[0x00007f50f09c4ad0]:
-----------------begin-------------------
d0 b7 f4 80 50 7f 00 00 05 00 00 00 00 00 00 00 
80 80 99 f0 50 7f 00 00 01 58 a1 f0 50 7f 00 00 
10 a0 9c f0 50 7f 00 00 01 00 00 00 02 00 00 00 
10 00 00 00 00 00 00 00 08 0e d4 80 50 7f 00 00 
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
07 00 01 00 00 00 00 00 00 00 00 00 00 00 00 00 
f0 5f a4 59 fd 7f 00 00 08 00 00 00 00 00 00 00 
f0 5f a4 59 fd 7f 00 00 00 00 00 00 00 00 00 00 
05 00 00 00 00 00 00 00 02 00 00 00 00 00 00 00 
------------------end-------------------

观察到有个很像地址的东西，接着探究，结果发现似乎并不是……

是不是有什么地方看漏了？

回头再看drstrace的源码，突然发现，他在pre_syscall和post_syscall都遍历了一遍参数，而且判断了只有在postcall的时候才去打印结构体。

照葫芦画瓢试试看：

static bool drsys_iter_arg_cb(drsys_arg_t *arg, void *user_data)
{
    if (!arg->pre){
        struct stat* st = (void*)arg->value64;    
        dr_fprintf(STDERR,"st_size=%d",st->st_size);
    }
}

结果正常了。

这个故事告诉我们，要好好看文档。

第二个坑是write

这是自己程序运行cal时的输出

   November 2019write(1, "   November 2019"..., 16)     = 16
      
write(1, "      \nmber 2019"..., 7)     = 7
Su Mo Tu We Th Fwrite(1, "Su Mo Tu We Th F"..., 16)     = 16
r Sa  
write(1, "r Sa  \nu We Th F"..., 7)     = 7
                write(1, "                "..., 16)     = 16
1  2  
write(1, "1  2  \n         "..., 7)     = 7
 3  4  5  6  7  write(1, " 3  4  5  6  7  "..., 16)     = 16
8  9  
write(1, "8  9  \n5  6  7  "..., 7)     = 7
10 11 12 13 14 1write(1, "10 11 12 13 14 1"..., 16)     = 16
5 16  
write(1, "5 16  \n2 13 14 1"..., 7)     = 7
17 18 19 20 21 2write(1, "17 18 19 20 21 2"..., 16)     = 16
2 23  
write(1, "2 _\"..., 11)                 = 11
24 25 26 27 28 2write(1, "24 25 26 27 28 2"..., 16)     = 16
9 30  
write(1, "9 30  \n6 27 28 2"..., 7)     = 7
                write(1, "                "..., 16)     = 16
      
write(1, "      \n         "..., 7)     = 7
exit_group(0)                           = ?

而strace标准输出则是

write(1, "   November 2019", 16   November 2019)        = 16
write(1, "      \n", 7      
)                 = 7
write(1, "Su Mo Tu We Th F", 16Su Mo Tu We Th F)        = 16
write(1, "r Sa  \n", 7r Sa  
)                 = 7
write(1, "                ", 16                )        = 16
write(1, "1  2  \n", 71  2  
)                 = 7
write(1, " 3  4  5  6  7  ", 16 3  4  5  6  7  )        = 16
write(1, "8  9  \n", 78  9  
)                 = 7
write(1, "10 11 12 13 14 1", 1610 11 12 13 14 1)        = 16
write(1, "5 16  \n", 75 16  
)                 = 7
write(1, "17 18 19 20 21 2", 1617 18 19 20 21 2)        = 16
write(1, "2 \33[7m23\33[27m  \n", 162 23  
)   = 16
write(1, "24 25 26 27 28 2", 1624 25 26 27 28 2)        = 16
write(1, "9 30  \n", 79 30  
)                 = 7
write(1, "                ", 16                )        = 16
write(1, "      \n", 7      
)                 = 7
exit_group(0)                           = ?

可以看到，流的顺序完全不一样。

这部分应该再看看strace的实现的，然而来不及了，先把作业交上去，以后再说吧。

代码

Github

macOS 10.15 Catalina 中使用 Apple Watch 进行 sudo 鉴权

2019-10-01T14:41:50+00:00

简介

最近更新了 macOS 10.15，sidecar（官方中文叫随航）确实好用，不过我在闲逛官网的时候发现了另外一个功能，如题图所示。实际测试了一下，效果确实好使。

问题有二：

可以让 sudo 也支持这个功能吗？
Apple Watch 时不时无法连接，需要重启才能连回，有办法检测 Apple Watch 的连接状态吗？

初探

翻看了一些资料，找到了之前使用 Touch ID 鉴权 sudo 的方法：在 /etc/pam.d/sudo 中加入 auth sufficient pam_tid.so。那么这一招对 Apple Watch 是否管用？

一开始，我的想法是，会不会有类似 pam_watch.so 的 pam 文件？

macOS 的默认 pam 文件夹在 /usr/lib/pam，看了看，里面并没有新增什么东西。

我们首先按照老方法直接加入，经过测试之后发现，当拉起 Touch ID 验证窗时，手表也会收到鉴权提示，证明此方法有效。

那么就这么解决了吗？并没有。

当电脑合盖连显示器之后，这个鉴权就失效了，回退到原本的密码输入中，想解决这个问题，还需要进一步探究原理。

macOS 的鉴权机制

macOS 有两套鉴权机制，一套是 pam.d ，另一套则是 LocalAuthentication.framework。

查看源码后我们得知，pam_tid是对后者的一个封装。 https://opensource.apple.com/source/pam_modules/pam_modules-173.50.1/modules/pam_tid/pam_tid.c.auto.html

也就是 sudo -> pam_tid.so -> LocalAuthentication.framework -> 指纹或手表验证，这样一条调用链

观察到这一段：

    /* evaluate policy */
    if (!LAEvaluatePolicy(context, kLAPolicyDeviceOwnerAuthenticationWithBiometrics, options, &error)) {
        // error is intended as failure means Touch ID is not usable which is in fact not an error but the state we need to handle
        if (CFErrorGetCode(error) != kLAErrorNotInteractive) {
            os_log_debug(PAM_LOG, "policy evaluation failed: %ld", CFErrorGetCode(error));
            retval = PAM_AUTH_ERR;
            goto cleanup;
        }
    }

该段代码执行 LAEvaluatePolicy 调起生物识别。找一下 macOS 10.15 的 SDK 头文件:

// LocalAuthentication.framework/Versions/A/Headers/LAPublicDefines.h
#define kLAPolicyDeviceOwnerAuthenticationWithBiometrics        1
#define kLAPolicyDeviceOwnerAuthentication                      2
#define kLAPolicyDeviceOwnerAuthenticationWithWatch             3
#define kLAPolicyDeviceOwnerAuthenticationWithBiometricsOrWatch 4

果不其然，相比 10.14 新增了 Watch 和 BiometricsOrWatch。

那是什么原因导致我们合盖就无法鉴权的呢？

猜测一：Apple Watch 的鉴权和 Touch ID 是同时进行的(and)，当 Touch ID 无法执行时（即合上电脑），Apple Watch 也会返回无法执行。

做个实验：

BOOL can = [context canEvaluatePolicy:kLAPolicyDeviceOwnerAuthenticationWithWatch error:&error];
LABiometryType bioType = context.biometryType;
NSLog(@"%hhd",can);

枚举	状态	返回值
kLAPolicyDeviceOwnerAuthenticationWithWatch	开盖	1
kLAPolicyDeviceOwnerAuthenticationWithBiometricsOrWatch	开盖	1
kLAPolicyDeviceOwnerAuthenticationWithWatch	合盖	1
kLAPolicyDeviceOwnerAuthenticationWithBiometricsOrWatch	合盖	1

证明我们猜测是错误的，而且，用 IDA 打开新版的 pam_tid.so 发现，调用的参数竟然不是 BiometricsOrWatch , 而仍是之前的 Biometric。

if ( (unsigned __int8)LAEvaluatePolicy(v33, 1LL, v31, &v65) || CFErrorGetCode(v65) == -1004 )
                                            ~~~

这是怎么一回事？按照苹果的说法，只有 BiometricsOrWatch 才能实现若指纹识别无法使用的情况下使用Watch。

猜测二：`kLAPolicyDeviceOwnerAuthenticationWithBiometrics` 的真实表现型为 “BiometricAndWatch”，即猜测一，但 Apple Watch 无法检测的话不影响 Touch ID。

打开 IDA，找到 pam_tid.so，跳转到地址 1FBB，此处语句为 mov esi,1，也就是kLAPolicyDeviceOwnerAuthenticationWithBiometrics的枚举值。

选择 Edit - Patch Program - Patch Word，将 0x1BE 改为 0x4BE（即kLAPolicyDeviceOwnerAuthenticationWithBiometricsOrWatch的枚举值）

然后选择 Apply patches to input file,得到新的 pam_tid.so。

由于pam文件经过签名，我们如果直接使用这个文件，会被 Kill 掉，使用以下语句进行签名：

sudo codesign -f -s pam_tid.so

其中， -f 代表替换原签名，-s代表使用 Ad-Hoc 签名。

由于 macOS 的 rootless 机制，我们无法修改 /usr/lib/pam。所以签名完成后，你需要找一个文件夹放置，然后重新将 /etc/pam.d/sudo 里面的so文件指向新的so文件。

测试后发现，无论是 Touch ID，还是 Apple Watch，均能完成鉴权，且在屏幕合盖后，Apple Watch 也能进行独立鉴权。

不过，有一个缺点，Apple Watch 总是断连，这个问题不知道如何解决。

检测 Apple Watch 与 macOS 的连接状态

LAContext* context = [[LAContext alloc]init];
NSLog(@"%hhd",[context canEvaluatePolicy:kLAPolicyDeviceOwnerAuthenticationWithWatch error:&error]);

当 Apple Watch 与 macOS 连接正常时，该值返回 1。问题在于，第一次要求鉴权时，Apple Watch 总是不可用（即返回0），需要等待较久时间才能自动连回电脑。

而 macOS 自带的使用 Apple Watch 解锁基本上每次都能成功，准确地说：

运行上述代码，显示 0。
锁定 macOS。
唤醒 macOS，手表自动解锁。
再次运行上述代码，显示 1。

暂时不知道如何实现的，留作以后探究吧。

结论

由于未知的原因，系统自带的 pam_tid.so 仍然没有更新，而 LAContext 的 canEvaluatePolicy 方法将 kLAPolicyDeviceOwnerAuthenticationWithBiometrics 的默认表现型改为当 Touch ID 无法执行时（即合上电脑），Apple Watch 也会返回无法执行。

以上结论基于实验与猜测，附上 pam_tid.so 的修改版。

OKEX 藏宝图第三关 WriteUp

2019-09-06T21:24:53+00:00

OKEx 在 2019 年 7 月 30 日的时候上线了一个” LTC 藏宝图”的活动，这个藏宝图活动与去年 10 月 310 个 BTC 的活动一样，均为 ctf 的 misc 形式，只不过相比 ctf 比赛的 flag，这个活动将 flag 换成了私钥。玩家需要通过各种手段破解藏在图片中的信息，从而获取正确的私钥来取得奖励，现在活动已经完结，作为一个复盘而言，写一下总归是有价值的。这个游戏做的不错，融合了不少比特币相关的知识。

此为第三关 writeup。

从第二关中我们获得了第二关的奖励地址 LTSYo5LL7oKopwt62Su2wUqUNcykacj4Fw 。

区块链浏览器查一查，发现 LTSYo5LL7oKopwt62Su2wUqUNcykacj4Fw 为 vout0，而 vout1 为 LXd4oah1kaCY1GKzoQVEGxCNrzNVRarcqV。

LXd4oah1kaCY1GKzoQVEGxCNrzNVRarcqV 里面有 100 个 LTC，看来这就是我们的目标了。

嗯？中间还有一笔交易。刚刚的 vout1 被分成七份发送给了七个地址。

有了上次的经验，我们先把金额转换成字符串看看。

import binascii
v = ["0.06250329","0.03175719","0.07759199","0.06697077","0.07234655","0.06832236","0.06709087"]
h = "".join(hex(int(i[2:]))[2:] for i in v)
print(binascii.unhexlify(h))

输出结果为

5f5f5930752776655f6630756e645f68406c665f5f
__Y0u've_f0und_h@lf__

找到一半了，那剩下一半呢？

这里我们有第二个知识点：

根据 BIP-13，比特币地址是这样构成的:

base58-encode: [one-byte version][20-byte hash][4-byte checksum]

而莱特币作为比特币的分叉币，自然也继承了 BIP-13。其中 version 字段，莱特币为 0x30。

那我们来看看对应的比特币地址，如何呢？

utils 文件取自 pycoin

import utils

bytes = utils.b58decode("LXd4oah1kaCY1GKzoQVEGxCNrzNVRarcqV",25)

version, keyhash, chksum = bytes[0], bytes[1:21], bytes[21:25]
print(version.encode("hex"),keyhash.encode("hex"),chksum.encode("hex"))
print(utils.hash2addr(keyhash))

输出

('30', '8800895af18dac1775984e46790118bb8a9c48e4', '8e34a920')
1DQ7YNPBfuxUkTdqdGVvzw8cen1DJLKyXr

然后去比特币对应的地址看看，果然又是7个vout，先将这七个转为hex之后，再与之前的字符串异或。

v1 = ["0.06250329","0.03175719","0.07759199","0.06697077","0.07234655","0.06832236","0.06709087"]
v2 = ["0.05971248","0.06165134","0.06444911","0.03756588","0.01704236","0.03614729","0.01338584"]
h = "".join(hex(int(i[2:]))[2:] for i in v1)
h2 = "".join(hex(int(i[2:]))[2:] for i in v2)
h = binascii.unhexlify(h)
h2 = binascii.unhexlify(h2)
info = ""
for i in range(len(h)):
    c = ord(h[i]) ^ ord(h2[i])
    info +=chr(c)
    
print(info)
print("hex: "+info.encode("hex"))

结果是这个字符串（注意中间有不可见字符）

Bing�20_bYtes_her3�
hex: 0442696e67a91432305f62597465735f6865723387

这个 hex 可以转换为对应的 bitcoin opcode :

Hex	opcode
04	PUSH 4 bytes
42 69 6e 67	[4bytes]”Bing”
a9	OP_HASH160
14	PUSH 20 bytes
32 30 5f 62 59 74 65 73 5f 68 65 72 33 87	[20bytes]”20_bYtes_her3.”

20 bytes！听起来有点耳熟？

看看 (BIP-16)[https://github.com/bitcoin/bips/blob/master/bip-0016.mediawiki] 定义的 P2SH 怎么说吧。

scriptSig: [signature] {serialized script} scriptPubKey: OP_HASH160 [20-byte-hash-value] OP_EQUAL

😯，20 byte 的 hash！不过，是hash什么呢？

要理解上面的内容，我们就要从最传统的比特币转账交易 P2PKH 开始说起。

P2PKH中，上面那两个东西长这样：

scriptSig: [signature] [pubkeyHash] scriptPubkey: OP_DUP OP_HASH160 [pubkeyHash] OP_EQUALVERIFY OP_CHECKSIG

其中， scriptPubkey 是一把锁，scriptSig 是钥匙。

scriptPubkey 代表之前一个交易的发起者，将一部分他的 utxo，通过这个加锁脚本锁了起来。只有 PubkeyHash 的私钥持有者，通过验证签名才能解锁。比特币系统在转账时，会将 scriptSig 和 scriptPubkey 拼接起来，如果完全执行成功，说明解锁成功。

拼接起来长这样: [signature] [pubkeyHash] OP_DUP OP_HASH160 [pubkeyHash] OP_EQUALVERIFY OP_CHECKSIG

举个例子吧，假设 A 转账给你一笔比特币，那么，他需要在输出的 utxo 中，把你的公钥写在 scriptPubkey 上，然后广播出去。这样，所有比特币节点都知道有这么一笔 utxo ，所属权已经转给了 Pubkey 私钥的持有者，如果你有私钥，那么这笔 utxo 你就可以轻松解锁花掉。

不过， P2PKH 有很多局限性，比如他只能将 utxo 移交给一个 Pubkey。为了应对这种问题，P2SH 出现了。我们经常说的多重签名，实际上指的就是他，不过，P2SH 可以做的可不止多重签名。

话不多说，我们先把这两拼起来，看看跟 P2PKH 有什么不同:

[signature] {serialized script} OP_HASH160 [20-byte-hash] OP_EQUALVERIFY

跟上面opcode对一对，感觉 hex 就是这一段 {serialized script} OP_HASH160 [20-byte-hash]，其中构造的script就是42 69 6e 67。

未完待续。

OKEX 藏宝图第二关 WriteUp

2019-09-03T12:55:08+00:00

此为第二关 writeup。

在第一关的最后，我们获得了十二个地址，从这十二个地址转账中我们发现，每一个地址中都有一个交易。这个交易一共有三个 vout 。其中 vout0 为地址的 utxo，vout1为一串可疑的01字符串，vout2为找零。

那么一个很自然的想法就是先把这些字符串整理出来：

Address	LTC	Hash
LgzYLJQxoo6Tzciahyeru3hEx6RsS2bNSf	0.01001010	e92c06e376876e9218ab9126fcc49f04afaf8e8d87372bf6b03becab01d0a021
LU5bQkFBcDMS2At6YG1xe44nWtC8VtP6Ms	0.01010001	624ad997f6bed92c446fe4c6419ce392730f330a409b93394c74468da500c53d
Lh17sPSpzNticZTqPgyywEheV8zVs5EMje	0.01000101	00958d203d2040f66ea8d6b2ee209ee787b7329d459d3948fa157324c498d062
LZD7bL865BGEdtNfsjh32pPtwZZexhcnRc	0.01001011	d223e8271bfb324ae7421ff2ff3561011cfc423a69229733ae65b7f701c24bfc
LMRQquyyxV3x3oKUNi1XVW2soN3hshurkj	0.01001010	15ff37f72dfccb7f15c3f917bf556db810df8da316fc5ceacdb3a06bfff6b925
LXDaymVT3MYxFzxxr8z1yRu786dD8u74B8	0.01010001	c86533737c84426d69c690148a1f6a1ebb6cb8dce8af5fabaa62af5139531b21
LXXASRZp1nojbTGyq1dZrwTRvZyj6QwaMA	0.01000101	acb7447fec1edb10a84f23eaa6de0f098b75d5a87a8d5db87ebc7ebc27969540
LP8kLTRCUDCeKLjDt7hHBrLpozo6GUUoM2	0.01001011	ee61083111270e87291f3a2a362f2699314cfad9421f9ecb5b9845a7c220c28a
LYMR6SmtqfPgj9gBBJz2rzu8UjujTQroMY	0.01001010	b3c91056ae64eb359efb380db3855c791ef37700b9030c59163008150595a3b1
Ldxzgxbsfob3eaouwL1RAVGDtfBvPjr9Zh	0.01010001	34112eb9ad6e86c016453e6505b9618e3858512260fa5750aa60c6d147ec2adf
LfGrSFv1Cg2i93b2KburFicpnuRGMBHtm2	0.01000101	fd6e0b4e962f6bbbc90dddf958296564a9c883b8af2a423e81fbc0ace0fd7e7c
Lbzma9yHoKnvUUPzCSCvXtaz9P9pfMdU7p	0.01001011	975a1397b5d04119c57524ce69a2f98cc5c3b8b7f1c488ee90ce8f6a47a69f11

[0.0100101, 0.01010001, 0.01000101, 0.01001011, 0.0100101, 0.01010001, 0.01000101, 0.01001011, 0.0100101, 0.01010001, 0.01000101, 0.01001011]

转为ascii码为’JQEKJQEKJQEK’

然后我就卡住了。

参考这个地址，写出了剩余的解题过程

https://www.chainnode.com/post/360569-24

首先，我们把每个01字符串看成一个截取规则。例如，0b3e61cc在01001010截取规则下的结果为b6c。

0b3e61cc
01001010
 b  6 c  

然后我们以12个vout1地址为输入，vout1金额为截取规则，输出12个短字符串k。

Address	Vout1
MKE34mPVVaMUbV66vybUY8eKgBy2JbGfFb	0.01001010
MLZDb5gfcnHvuBEHtwquQnVaKw5n1e8qHt	0.01010001
MV3Do2q6NzsteiB5245usYtywF2onkURTw	0.01000101
MFUkMzXQK4hNTv69334W5oik6jX1Q1VFQD	0.01001011
MUmGxvkvJ2b3vTpNFQsLSgqnSPv3Eci5eb	0.01001010
MQQEMy8tyfZBAz76MqDXZ2RbRpT8cdRuP4	0.01010001
MMZXU9Xwad5TPQhppe2jBwrhDs2kkzC4Bq	0.01000101
MB9TKjwtASBsDAr59tLEVXdS7XQJELZFuV	0.01001011
MPMQvnRaiAwHxQLXWNmUpzfqM8TwThZ751	0.01001010
MTwGBRdXL7L1MLTKoY3gcSKCcheKJekdk7	0.01010001
MVtDH3MKoCRke6NwBaZwj7hW63e4GSjyoM	0.01000101
MTCTCKDHGMBwA6uqbCGZpLtaAyKNE1RUyR	0.01001011

addr = ["MKE34mPVVaMUbV66vybUY8eKgBy2JbGfFb",
        "MLZDb5gfcnHvuBEHtwquQnVaKw5n1e8qHt",
        "MV3Do2q6NzsteiB5245usYtywF2onkURTw",
        "MFUkMzXQK4hNTv69334W5oik6jX1Q1VFQD",
        "MUmGxvkvJ2b3vTpNFQsLSgqnSPv3Eci5eb",
        "MQQEMy8tyfZBAz76MqDXZ2RbRpT8cdRuP4",
        "MMZXU9Xwad5TPQhppe2jBwrhDs2kkzC4Bq",
        "MB9TKjwtASBsDAr59tLEVXdS7XQJELZFuV",
        "MPMQvnRaiAwHxQLXWNmUpzfqM8TwThZ751",
        "MTwGBRdXL7L1MLTKoY3gcSKCcheKJekdk7",
        "MVtDH3MKoCRke6NwBaZwj7hW63e4GSjyoM",
        "MTCTCKDHGMBwA6uqbCGZpLtaAyKNE1RUyR"]
vout = ["0.01001010",
        "0.01010001",
        "0.01000101",
        "0.01001011",
        "0.01001010",
        "0.01010001",
        "0.01000101",
        "0.01001011",
        "0.01001010",
        "0.01010001",
        "0.01000101",
        "0.01001011"]
def f(addr,vout):
    result = ""
    vout = vout.replace("0.","")
    for i in range(len(vout)):
        if vout[i] == '1':
            result += addr[i]
    return result

k = []
for kv in zip(addr,vout):
    k.append(f(kv[0],kv[1]))
    
print(k)

最后，以JQEK为密钥，使用维吉尼亚密码加密，得到最终答案。

至于为什么是维吉尼亚密码，需要用到一点密码学的小知识。

观察得到JQEK重复了三次，而维吉尼亚密码中，若密钥不足明文长度的，则重复此密钥直到补足长度为止，所以猜想需要使用维吉尼亚密码。

def encrypt(plaintext, key):
    key_length = len(key)
    key_as_int = [ord(i) for i in key]
    plaintext_int = [ord(i) for i in plaintext]
    plaintext = filter(str.isalpha,plaintext).upper()
    ciphertext = ''
    for i in range(len(plaintext_int)):
        value = (plaintext_int[i] + key_as_int[i % key_length]) % 26
        ciphertext += chr(value + 65)
    return ciphertext
f = []
for _ in k:
    f.append(encrypt(_,"JQEK"))
print(f)
final = ''.join(f)
print(final)
key = network.keys.bip32_seed(final)
print(key.address())

输出:

['TF', 'UTJ', 'E', 'OCBA', 'DNO', 'ZUX', 'VM', 'KAAD', 'YLV', 'CWB', 'EA', 'CSHR']
TFUTJEOCBADNOZUXVMKAADYLVCWBEACSHR
LTSYo5LL7oKopwt62Su2wUqUNcykacj4Fw

看到LTSYo5LL7oKopwt62Su2wUqUNcykacj4Fw有30个LTC，本关结束。

从key里扒拉出私钥吧。

这里有几个自己踩过的坑:

使用vout0地址而不是vout1地址作为筛选输入
使用M开头的找零地址而不是3开头的地址作为输入
- 为了防止与比特币的Segwit地址混淆，莱特币启用了M地址，3地址与M地址是等效的。(例：3D1tksyXYTW3nypCq6c8iVPvMVNaJ6CYdd与MKE34mPVVaMUbV66vybUY8eKgBy2JbGfFb)
- 之前有很长一段时间不能理解为什么攻略作者能顺利筛选出来k，而自己死活筛选不出来，后来发现自己使用的区块链浏览器不支持M地址，白忙活了好久。
维吉尼亚密码不转换数字，因此过滤掉数字filter(str.isalpha,plaintext)
字符串要全大写 .upper()
与第一关不同，每个字符串间不留空格

OKEX 藏宝图第一关 WriteUp

2019-08-07T15:30:00+00:00

此为第一关 writeup。

规则介绍

“关于OKEx上线-LTC藏宝图-活动的公告”

藏宝图中总共藏有142.579436个LTC；
藏宝图中隐藏着3道关卡，需要依次破关；
关卡的答案对应钱包的密钥，参与者在破关成功后可以将奖励直接转走；
藏宝图关卡及奖励分布如下

关数	奖励
第一关	共12.579436 LTC（分布在12个地址内，即最多可有12个用户获得第一关奖励）
第二关	共30LTC（存放在一个地址内）
第三关	共100LTC（存放在一个地址内）

老实说，一开始有点想吐槽最后的“因账户地址包含藏宝图的线索，为保证活动的公平公正，奖励地址会在活动结束后公布“，因为我觉得区块链上的信息应该谁都能获取，对这些信息隐藏没有意义。但实际上我错了，第三关居然用到了这些信息，而隐藏地址显然会增加破解的难度，想要通过区块链上的数据获取目标地址无异于大海捞针。

第一关

图片留意到一段莫斯电码

…/-/./–./.-/-./—/–./.-./.-/.–./…./-.–

解得

steganography

很明显了，上Stegsolve。（实际上我一开始根本没看到莫斯电码，直接就上了）

然后拿到了第一张图片，之后所有的解谜都从这里开始。

首先，我们看到在(400,400)处有一个很小的点，这个代表圆心，周围的点和空白分别代表 0 和 1。

顺时针将这个圆圈上的点都转换为 0 和 1。

代码如下:

import matplotlib.image as mpimg
import binascii
import math
I = mpimg.imread('./solved.png')

s = ""

# r = 400
# (x-450) ^2 + (y-450)^2 = 160000

r = 400
for i in range(360):
    x = r * math.sin(math.radians(i)) + 450
    y = r * math.cos(math.radians(i)) + 450
    x = int(round(x))
    y = int(round(y))
    if I[x,y][2] != 1:
        s+='1'
    else:
        s+='0'
print(s)
print(binascii.unhexlify('%x' % (int(s,2))))

执行结果如下：

010010000100100100100000010011000101010001000011001000000100100001010101010011100101010001000101010100100010000001010111010001010100110001000011010011110100110101000101001000000011001000100000010011110100101100100000010011000101010001000011001000000100011101000001010011010100010100100000010011110010000001001011001000000100010100100000010110000000000000000000
HI LTC HUNTER WELCOME 2 OK LTC GAME O K E X

圆圈这个地方实际上第二天就有人解出来了，然后被直接发在了微博底下。大家都不知道怎么把这些单词与助记词联系起来，我甚至还觉得这个可能只是一个热身，然后对着右下角的点阵图案死磕。

官方在此期间发出的提示有很多：

提示	来源	公布时间
b c d e f g h i j k l a	@OKEx	7-30 14:44
l k j i h g f e d c b a	@莱特币中国社区	7-31 00:31
a c e g i k b d f h j l	@OKEx	7-31 12:56
ab bc cd de ef fg gh hi ij jk ka lb	@OKEx	7-31 16:02
j k l a b c d e f g h i	@莱特币中国社区	7-31 12:03
g h i j k l a b c d e f	@OKEx	7-31 17:06
b d f h j l a c e g i k	@OKEx	8-01 16:16

@OKEx 和 @莱特币中国社区这两个账号要求参加者在对应微博下转发、评论或点赞，达到一定次数时解锁线索。但目前来看，整个区块链生态在微博上应该没有这么高的活跃度，于是不知道哪个大哥去淘宝买了一堆转发，评论和点赞，随着僵尸号把量刷上去之后，这些线索就一个一个地冒出来了。在第七个线索公布时，所有的 LTC 都被拿走，于是线索就没有继续公布。

那么，如何通过这些线索和上面的单词来取得 LTC 呢？

这就涉及到了 BIP-32 了。

BIP-32

首先，BTC 的每个地址都由一个或者多个私钥来控制。但是，若一个人持有多个地址，那么管理对应的私钥则会是一件非常麻烦的事情。 BIP-32 提出了一种名叫 Hierarchical Deterministic Wallets （HD 钱包）的理念，允许一个种子来管理多个私钥。其中，主私钥能够推导出子私钥，反之则不行。

其中， Master key 的生成方法如下: （参考资料:https://github.com/bitcoin/bips/blob/master/bip-0032.mediawiki

我们可以发现，虽然正常HD钱包的生成路径中，根种子是固定位数的，但 HMAC-SHA512 是一个哈希函数，这就意味着，我们的输入长度可以不是 128, 256 或 512。

回过头来观察一下，我们取得了如下字符串:

HI LTC HUNTER WELCOME 2 OK LTC GAME O K E X

刚好十二个，而上面的提示也是十二个字母（或字母对）排列组合。结合一下上面的提示，怎么样？令 a = “HI” , 以此类推。

from pycoin.symbols.ltc import network
s = "HI LTC HUNTER WELCOME 2 OK LTC GAME O K E X".split(" ")
order = "b c d e f g h i j k l a".split(" ")
final = []
for o in order:
    final.append(s[ord(o)-ord("a")])
final = ' '.join(final)
key = network.keys.bip32_seed(final)
print(key.address())

输出

LgzYLJQxoo6Tzciahyeru3hEx6RsS2bNSf

到区块链浏览器看一下，有余额，说明第一关宣告结束。其他十一个以此类推。

seed[0] 从第二个开始:

“LTC HUNTER WELCOME 2 OK LTC GAME O K E X HI”:

地址: “LgzYLJQxoo6Tzciahyeru3hEx6RsS2bNSf”

seed[1] 逆序:

“X E K O GAME LTC OK 2 WELCOME HUNTER LTC HI”:

地址: “LU5bQkFBcDMS2At6YG1xe44nWtC8VtP6Ms”

seed[2] 跳序 :

“HI HUNTER 2 LTC O E LTC WELCOME OK GAME K X”:

“Lh17sPSpzNticZTqPgyywEheV8zVs5EMje”

seed[3] 相邻单词连接 :

“HILTC LTCHUNTER HUNTERWELCOME WELCOME2 2OK OKLTC LTCGAME GAMEO OK KE EHI XLTC”:

“LZD7bL865BGEdtNfsjh32pPtwZZexhcnRc”

seed[4] 从中间开始:

“LTC GAME O K E X HI LTC HUNTER WELCOME 2 OK”:

“LMRQquyyxV3x3oKUNi1XVW2soN3hshurkj”

seed[5] 跳序 * 2 :

“LTC WELCOME OK GAME K X HI HUNTER 2 LTC O E”:

“LXDaymVT3MYxFzxxr8z1yRu786dD8u74B8”

seed[6] 逆序相邻单词连接 :

“XE EK KO OGAME GAMELTC LTCOK OK2 2WELCOME WELCOMEHUNTER HUNTERLTC LTCHI HIX”:

“LXXASRZp1nojbTGyq1dZrwTRvZyj6QwaMA”

seed[7] 用字符串比较的方式排序单词:

“2 E GAME HI HUNTER K LTC LTC O OK WELCOME X”:

“LP8kLTRCUDCeKLjDt7hHBrLpozo6GUUoM2”

seed[8] 反向排序:

“X WELCOME OK O LTC LTC K HUNTER HI GAME E 2”:

“LYMR6SmtqfPgj9gBBJz2rzu8UjujTQroMY”

seed[9] 从第3个单词开始 :

“WELCOME 2 OK LTC GAME O K E X HI LTC HUNTER”:

“Ldxzgxbsfob3eaouwL1RAVGDtfBvPjr9Zh”

seed[10] 从第7个单词开始 :

“GAME O K E X HI LTC HUNTER WELCOME 2 OK LTC”:

“LfGrSFv1Cg2i93b2KburFicpnuRGMBHtm2”

seed[11] 从第9个单词开始 :

“K E X HI LTC HUNTER WELCOME 2 OK LTC GAME O”:

“Lbzma9yHoKnvUUPzCSCvXtaz9P9pfMdU7p”

第一关圆满结束，撒花。

Macbook Pro 与 iPhone 连接抽风的解决方案

2019-03-15T13:25:16+00:00

机器为 2015 Macbook Pro LT2 港版。

经常进行 iOS 开发，在使用机器左右的 USB 接口连接 iPhone 时，有的时候发现连接不正常，具体表现为：

Macbook 能够识别 iPhone 插入并试图进行握手，此后立即断开，然后反复尝试重新连接，中间可能还会伴有提示升级 iPhone 连接固件并失败的现象。
iPhone 进入充电状态，而后在数秒内自行断开。
iTunes 自行打开，iPhone 图标出现后消失。

一开始猜测是电流的问题，于是换了一个 USB hub ，把 iPhone 接在上面之后解决。然后猜测是不是跟线也有关系，于是换了一条原装线，比起之前的品胜线，更大概率能够握手成功，但在调试时断开。

解决方案

打开活动监视器，找到usbd进程，强制停止，之后问题解决。

博客集锦

2019-01-01T00:00:00+00:00

这里会记录一些个人觉得有价值的博客。

https://www.nevermoe.com/

一个安全相关的博客

https://yihui.name/

虽然与技术没有太大关系，但是文笔写的非常好

https://typeblog.net/

技术流博客

https://leemeng.tw/

「ありがとうございます」と「ありがとごさいました」

2018-01-02T16:36:59+00:00

あるコーヒ屋さんでは「ありがとうございました」と言わないで、「ありがとうございます」と言うようにというマニュアるになっているそうです。理由は、「ありがとうございました」だと「過去」のこととしてお客様との関係が切れてしまうという感じになるから、と聞きました。

確かに「ありがとうございました」と言うのは、出来事が一件落着してからです。来店したばかりの客に「ありがとうございました！」と言うのは変です。注文してお金を払って、といった出来事はこれからだからです。感謝の心を持ち続けているから過去形で言わない、という論理はそれはそれとしてわかります。しかし、本当のところはどうでしょうか。

実は、「ありがとうございます」は少し軽いびょうげん表現でもあります。例えば、「あ、ネクタイ歪んでますよ」と指摘してもらったときに、「ありがとうございました」というとおおげさではないでしょうか。普通は「あ、ありがとうございます」などというように思います。

「ありがとうございました」の場合、「感謝すべき事態があった」ということを過去のこととして認識し、しっかり表す点で「重さ」があります。例えば、ちょっと道を聞くような場合、「こっちの道だよ」と指示してもらうだけなら、「あ、どうもありがとうございます」で済みそうですが、「わかりにくいから一緒にいってあげよう」などと大変お世話になったような場合、「本当にありがとうございいました」というのではないでしょうか。お店の方の言葉としても、本格的な料亭などでは、「この度ご利用ありがとうございました。お気をつけておかえりくださいませ」などと言ってもらえそうな気がします。

ですから、「ありがとうございました」は、「過去のこととして関係が切れてしまうような水くさい挨拶」ではなくて、むしろ、「過去のことであっても覚えておくようなしっかりした感謝」ということができるのです。過去形の「ありがとうございました」の気持ちも大切にしたいところです。