何方圜的博客

CTF-MasterChef题目源码;点击 要求是：有一个 MasterChef 合约，它接受 MULA 代币并向质押者铸造 MUNY 作为奖励。 MULA 具有通缩转账税机制，每次转账会销毁 5% 的数量，以有效激励长期持有者。 你的任务是欺骗 MasterChef，使其为你铸造分配给所有质押者的所有 MUNY。你开始时拥有 10,000 MULA。 看到有源代码，和之前的质押合约很像，存款获得奖励，而我们就是要获得这个MdsterChef合约中全部的奖励，看到题目说有5%的手续费，初步想法就是会不会是溢出啥的，但是看到存取代码时，我并没有看见有对5%的手续费的说明 //_pid是流动池的ID function deposit(uint256 _pid, uint256 _amount) public { PoolInfo storage pool = poolInfo[_pid]; UserInfo storage user = userInfo[_pid][msg.sender]; updatePool(_pid); ...

ERC721非同质代币标准 简介非同质化代币（NFT）用于以唯一的方式标识某人或者某物。 此类型的代币可以被完美地用于出售下列物品的平台：收藏品、密钥、彩票、音乐会座位编号、体育比赛等。 这种类型的代币有着惊人的潜力，因此它需要一个适当的标准。ERC-721 就是为解决这个问题而来！ ERC-721 为 NFT 引入了一个标准，换言之，这种类型的代币是独一无二的，并且可能与来自同一智能合约的另一代币有不同的价值，也许是因为它的年份、稀有性、甚至是它的观感。 是的。 所有 NFTs 都有一个 uint256 变量，名为 tokenId，所以对于任何 ERC-721 合约，这对值contract address, tokenId 必须是全局唯一的。 也就是说，去中心化应用程序可以有一个“转换器”， 使用 tokenId 作为输入并输出一些很酷的事物图像，例如僵尸、武器、技能或神奇的小猫咪！ 主要功能协议函数如下： function balanceOf(address _owner) external view returns (uint256);function ownerOf(uint2 ...

CTF-ntf-bonanza题目源代码：点击 要求是：新的 NFT 交易合约 BonanzaMarketplace 已经推出，它允许交易选定的白名单 ERC721 和 ERC1155 代币。您的挑战是获得所有列出的 NFT。 根据源码，可以发现此时的NTF都是ERC721代币，所以了解ERC721非同质化代币标准，会很好的理解。 要获得所列的NTF，就先看看，buyItem函数 function buyItem( address _nftAddress, uint256 _tokenId, address _owner, uint256 _quantity ) external nonReentrant isListed(_nftAddress, _tokenId, _owner) validListing(_nftAddress, _tokenId, _owner) { require(_msgSender() != _owner, "Cannot ...

往往对于一个功能成熟的DAPP，如uniswapV2,多签钱包等，都是通过多个智能合约实现的，那么就多多少少都会涉及到外部的调用，然而这就带来的很大的风险。如果不能确保外部调用的合约是正常且不带恶意逻辑代码，那么对自身合约就是个定时炸弹，不知道哪天就调用了一个不正常的恶意合约，引爆炸弹。 外部调用会引发的一些常见漏洞：重入攻击，外部合约的安全性问题，重放攻击等 具体来看一下代码： function deposit( uint256 farmDeposit, address payable from, address to ) external returns (uint256 shares) { require(farmDeposit > 0, "deposits must be nonzero"); require(to != address(0) && to != address(this), "to"); require(from ! ...

CTF-freebie 题目源码点击 这道题，怎么说，和昨天写的那个CTF-tasty-stake的漏洞原理一样 看到这段代码，经典的委托调用，只不过这次又是不实现它 function deposit( uint256 farmDeposit, address payable from, address to ) external returns (uint256 shares) { require(farmDeposit > 0, "deposits must be nonzero"); require(to != address(0) && to != address(this), "to"); require(from != address(0) && from != address(this), "from"); shares = farmDeposit; ...

CTF-tasty-stake题目源码点击 题目要求： 有个TastyStaking 合约，该合约允许您质押 STEAK 以种植 BUTTER 代币。您的任务是从质押合约中耗尽所有 STEAK 代币。 首先这个合约是个单合约，实现的功能的挺多的，阅读了很久，看了一下它的提示：所有输入都经过了适当的验证吗？ 看来又是参数有问题，来到合约最后，migrateStake合约实现的代币质押的转移 function migrateStake(address oldStaking, uint256 amount) external { TastyStaking(oldStaking).migrateWithdraw(msg.sender, amount); _applyStake(msg.sender, amount); } 但是关键来了。对于这个oldStaking,这个函数并没有有什么检查举动，回想前几天刚做的Safu Valut题，和它有点类似，都是没有对外部调用进行一个检查，那么这个题旧很好的解决了 攻击合约： contract Att ...

CTF-safu-wallet题目源码点击。 题目要求：这是一个多签名钱包，已经有一位顾客存入钱，然后你要将它的钱永远困住在这个钱包里 首先看到合约代码：很清晰的辨别了，SafuWallet合约是代理合约，SafuWalletLibrary合约是逻辑合约，这样分开，就好理解了对于多签名钱包，我的理解就是，不止一个管理员，至少要俩个管理员就可以管理这个钱包了。 逻辑合约里有kill函数，如果能调用，这应该是最便捷的解题方式了 function kill(address _to) onlymanyowners(sha3(msg.data)) external { suicide(_to); } 很遗憾的是，有个onlymanyowners限制，这也就是多签名钱包的魅力了吧。 看到代理合约中，构造函数还是有点东西。 constructor(address[] memory _owners, uint _required, uint _daylimit) { bytes memory data = abi.encodeWithSignature( ...

CTF-free-Lunch题目来源：点击 首先这个代币只有一个合约，还是容易理解。如果对unswap V2有了解的话，会更好的理解合约。发现漏洞。要了解流动池点击, 题目要求是：我们初始有俩个代币，让我们通过这个SafuMaker合约后，翻倍50，并且要耗尽这个合约的资金。 攻击流程（这道题没有思路，或者是说对流动性的了解太少了，看了测试合约，发现这个思路真的让我茅舍顿开，或者是，题目还是做少了）： 添加流动性并获得 LP 代币： 攻击者首先向 SAFU-USDC 流动性池添加流动性，例如存入 10 USDC 和 10 SAFU。这一步使得攻击者获得相应数量的 LP 代币，代表他们在流动性池中的份额。 创建新流动性池： 攻击者使用获得的 LP 代币与 SAFU 代币创建一个新的流动性池。这一步增加了攻击者的流动性控制能力。 转移 LP 代币并进行转换： 攻击者将 10% 的新流动性池的 LP 代币转移到 safuMaker 合约，并调用其 convert 方法。这通常会激活一些机制，例如将 LP 代币转换为 SAFU 代币或其他奖励。 代币交换： 攻击者使用路由合约执行 ...

CTF-game-asserts题目源码:点击 题目说明：GG labs 刚刚发布了他们的 nOtApOnZi 游戏，该游戏允许将多个 WLed NFT 用作游戏内物品。为了集成多个 ERC721 代币，他们有一个包装合约 （ERC1155） 来包装 NFT，允许它们在游戏中使用。用户也可以在使用完 NFT 后解包它们。您的任务是将用户的 NFT 困在包装合约中并使他们无法挽回，从而使用户感到悲伤 这个一实现了游戏里的资产转化，首先AssetHolder合约中，就是资产的说明，具体实现有点多，这里就不深究了，AssetWrapper合约就是我们重点要说的了，他是一个包装合约，因为这个游戏使用的ERC1155代币规则，所以在进行包装的时候，要对用户进行返回代币是，就会触发一个隐藏的接受函数， function onERC1155BatchReceived( address operator, address from, uint256[] calldata ids, uint256[] calldata values, byte ...

ERC1155多代币标准 简介用于多种代币管理的合约标准接口。 单个部署的合约可以包括同质化代币、非同质化代币或其他配置（如半同质化代币）的任何组合。 多代币标准是什么？ 它的目的很单纯，就是创建一个智能合约接口，可以代表和控制任何数量的同质化和非同质化代币类型。 这样一来，ERC-1155 代币就具有与 ERC-20 和 ERC-721 代币相同的功能，甚至可以同时使用这两者的功能。 它改进了 ERC-20 和 ERC-721 标准的功能，提升了效率并纠正了实现中的明显错误。 功能批量传输通过一次合约调用传输多种资产 就是不单是一种代币可以传输，很多种代币都可以传输 来看看，他与ERC20传输合约的比较 // ERC-20function transferFrom(address from, address to, uint256 value) external returns (bool);// ERC-1155function safeBatchTransferFrom( address _from, address _to, uint256[] calldat ...