当前位置：网站首页>【解密】OpenSea免费创造的NFT都没上链竟能出现在我的钱包里？

【解密】OpenSea免费创造的NFT都没上链竟能出现在我的钱包里？

2022-08-05 02:14:00 【十四君-web3】

内容概要

粉丝反馈，他在opensea无gas免费创建的NFT资产，竟能出现在小狐狸钱包里，而opensea官方声明的此NFT在正式交易前是未上链铸造的，这就很奇怪，中心化应用的资产出现在为去中心化应用服务的钱包里，到底是官方代付gas上链还是乌龙，随我一文揭晓！

目录大纲

1. 背景简述

2. 破案历程

2.1 小狐狸网络抓包

2.2 链上的交易统计

2.3 合约反编译分

3. 破案总结

面向对象

Web3新手，有无技术背景均可理解此文解密过程

背景简述

1.1 opensea 是什么？

全球最大的公链NFT交易平台，也是目前除以太坊链底层外营收最大的web3平台，下文简述为os

1.2 NFT是什么？

可见前文：【源码解读】你买的NFT到底是什么？

1.3 NFT铸造是什么？

可见前文：当奈飞的NFT忘记了web2的业务安全

大意是，只有在链上Mint后的才能认为是资产，且一般用户需要付gas

1.4 os的免费创造NFT服务是什么?

NFT上链成本高，标准ERC721的mint需要8W的gas，约5刀

NFT定制合约难，虽有标准但顶级NFT项目会定制且部分强化功能，例如azuki（出品721A，降低批量mint成本）

因此，易用性一直就是市场的痛点，毕竟艺术家不是合约工程师，需更低成本的试错来探索有价值的艺术品，官方也特别说明过（原文见附录）

在opensea.io上create的NFT，符合ERC1155标准，即使是它们存在于链上之前，这些 NFT 也可以在任何平台上出售，在交易时才上链铸造

破案历程

2.1 案例来源

某粉丝很惊奇发现，自己确实可以在os上按流程进行create，但按官方说法此时是未上链的，但是他尝试在小狐狸钱包里导入资产时发现，竟然已经可见，甚至尝试导入一个自己未create的NFTID时也能导入成功，因此反馈我寻找技术维度的全貌解读

2.2 还原方式

1：os上 createNFT（附录有官方教程）得到合约地址与ID

2：小狐狸上开启NFT检测后，再手动添加收藏品，即出现Shared Storefront

2.3 调查不易

其实查询资产是否上链是个非常容易的过程，用区块链浏览器即可

见前文：当我们在看Etherscan的时候,到底在看什么?

但是由于此os的NFT共享商店的合约并没有做验证。所以无法直接看源码查数据

但使用未经开源以及安全审计的合约，着实让我这从事多年安全行业的职业强迫症有些难受

如果真存在风险，其危害是巨大的

- 如果真未上链，小狐狸钱包去读取中心化平台数据？放在我的资产里？
- 如果真上了链，用户无需gas，则可能官方付费上链，雷同羊毛有被攻击风险
- 未上链的资产，如产生冲突风险，那此NFT属于谁的？

2.4 小狐狸app抓包

首先咱们通过对照实验做手机抓包，发现整体小狐狸会做的事情很多

拉取地址余额，交易，最新块内容，指定地址合约字节码等等

对数百个网络包逐个分析后，发现其小狐狸会使用infura（提供api接口同以太坊节点做交互的平台）的eth-call方法，功能是查询指定NFT合约中标准的balanceof方法

为何我如此肯定？此请求包里没有balanceof呀？

咱们用实验说话双向校验，标准的1155协议的标准函数名及参数为：


function balanceOf(address,uint256)

由于data构建指定函数调用，其生成Mothod-ID的原理是名字+参数类型组合，因此他构建的call方法，data字段的开头必然为00fdd58e

我输入的要添加资产是123号，其data参数末尾对应是7b=(7*16+11=123) 也对应上。

同时发现其缺乏防重放的措施，所以我可以直接编辑参数

重发请求查询其他NFT合约所有权来对比

azuki：721标准，无得到0,有则非0
爱死机：1155标准，无得到0,有则得1
查os共享商店，修改参数尾数（刚才的123）确实会得到值但意义不明

所以这里我得出的一大惊奇猜想是（是错误的）：

链上可查得NFT所有权的值，难道真的上链了吗？

2.5 链上交易统计

如果真上链其实也可以不由用户支付gas，有种“元交易”的技术手法，就是交易发起方和gas支付者不同的形式，并且openzepplin里特地有个content 合约就是用于额外支持元交易产生的msg.sender 可能特殊化的问题

但是，我通过对此合约的链上交易数据统计（etherscan+dune），抽取23号一天出现的交易频率可见下图，都证明了好像并没有固定由官方发起的元交易类型交易

2.6 破局得靠合约反编译

由于官方没有验证合约，导致分析起来费劲多了，但可通过合约反编译来大致摸清逻辑

如果只是openzepplin的标准1155库进行反编译的话，行数是170行

但是此1155则反编译后是1000行，因此必然有较多自定义实现

反编译后整体是吻合1155的数据标准


mapping (uint256 => [uint256]) _balanceOf;
mapping (uint256 => [uint256]) _setApprovalForAll; 
uint256[] _name; 
uint256[] _symbol;
mapping (uint256 => [uint256]) _totalSupply;

但是也显著有不是标准数据部分


mapping (uint256 => [uint256]) owner_a; 
mapping (uint256 => [uint256]) _creator;

由于链上数据读取返回了结果，所以重点分析balanceOf 函数，他整体实现用了30多行，这是很明显重写了原先的标准函数


//此为标准1155协议的balanceOf 函数实现，只是读取指定id和地址的数值而已
function balanceOf(address account, uint256 id) public view virtual override returns (uint256) {
        require(account != address(0), "ERC1155: balance query for the zero address");
        return _balances[id][account];}

由于os他依旧是沿用标准，所以他的两个参数是固定的可以理解为：

Varg0 = 待查询NFTid所有权的用户地址
varg1 = 待查询的NFTID 数字

从反编译程序里看逻辑，他会读取待查地址的_balanceOf总余额数，以及此NFTID是否被_creator等等


//此为反编译os合约的片段（太长不粘来，反编译网址在附录）
function balanceOf(address varg0, uint256 varg1) public payable { 
    require(msg.data.length - 4 >= 64);
    v0 = v1 = _balanceOf[varg0];
    if (address(_creator[varg1]) == 0) {
        v2 = v3 = address(varg1 >> 96) == varg0;
        if (address(varg1 >> 96) != varg0) {
            if (!(0xff & owner_a[varg0])) { 。。。

最关键的一句address(varg1 >> 96) != varg0

由于反编译不会完全按照solidity的语法，所以原本不支持的位移运算符就出现了

不讲复杂的，总之这里将varg1 （NFTID）的其中一部分，和varg0（用户地址）做比较

这也意味着，原来此NFT的ID包含了用户的地址

我顿然醒悟，写个进制转换，将我在os上create得到的NFTid传入，解密得出