概覽:

????該蜜罐合約的實(shí)現(xiàn)原理并不復(fù)雜，但是分析過(guò)程依賴(lài)較多相關(guān)知識(shí)基礎(chǔ)，才不容易走偏

答題合約簡(jiǎn)介：

????1 合約地址 0xfe255D67Ab85a67b51dd96a4f01f64a98Fdf20A4

????2 合約開(kāi)源，提供管理員方法start 和 普通用戶方法try

????3 步驟

????????管理員創(chuàng)建合約

????????管理員給合約存入一定量的eth

????????管理員調(diào)用start方法，輸入問(wèn)題和答案，如"國(guó)慶節(jié)是幾號(hào)？" "10月1號(hào)"

????????此時(shí)普通用戶調(diào)用try方法（要求攜帶至少1eth），合約校驗(yàn)答案通過(guò)后，自動(dòng)將其中的eth轉(zhuǎn)給第一個(gè)給出正確答案的人

????????????但是實(shí)際不可能有人能回答到正確答案

????管理員在一定時(shí)間后，收回合約里的所有eth并開(kāi)啟下一個(gè)蜜罐（管理員存入的 + 普通用戶數(shù)量 * 每次調(diào)用try攜帶的1eth)

答題合約原理：（結(jié)論前置）

????通過(guò)2個(gè)合約完成操作，即部署答題合約a后，調(diào)用另一個(gè)payload合約b, 在合約b的被調(diào)用方法里，調(diào)用合約a的new方法直接更新答案，導(dǎo)致start函數(shù)實(shí)際無(wú)法更新答案。即合約的答案不是start函數(shù)攜帶的參數(shù)，所以普通人無(wú)法通過(guò)try函數(shù)驗(yàn)證，合約所有者只進(jìn)不出。

????并且其中payload合約b里對(duì)答題合約a的更新，并不是直接發(fā)送給合約a的（雖然調(diào)用了合約a的方法，更新了storage的變量值）, 所以在區(qū)塊鏈瀏覽器的合約a transactions頁(yè)面中，不會(huì)展示該筆交易，從而有了更強(qiáng)烈的迷惑性

分析思路：

????1 先盡可能多的了解背景信息，減少不必要的開(kāi)發(fā)量和分析量

????2 提出多種猜測(cè)，比如可能是在合約部署時(shí)追加額外操作，可能是start函數(shù)有問(wèn)題，可能是try函數(shù)有問(wèn)題, 等等

分析步驟：

????1 整體分析：

????????1 合約本身開(kāi)源，粗略分析后，從合約代碼上看不出什么問(wèn)題

????????2 start函數(shù)未見(jiàn)問(wèn)題

????????3 try函數(shù)未見(jiàn)問(wèn)題

????2 本地部署合約，確定是否合約關(guān)鍵邏輯有隱含的，粗略分析沒(méi)有發(fā)現(xiàn)的異常

????????evm編譯器版本：^0.4.25

????????合約代碼：區(qū)塊鏈瀏覽器上經(jīng)過(guò)驗(yàn)證的源代碼直接部署

????????構(gòu)造函數(shù)參數(shù)：

????????????需要從創(chuàng)建合約參數(shù)里進(jìn)行截取

????????????合約創(chuàng)建交易參數(shù)由3個(gè)部分的字節(jié)碼構(gòu)成：

????????????????init_code

????????????????runtime_code

????????????????construct_params

????????????從合約源代碼可知，構(gòu)造函數(shù)攜帶的參數(shù)是bytes32字節(jié)數(shù)組,

????????????由于構(gòu)造函數(shù)的參數(shù)采用abi.encode進(jìn)行序列化和對(duì)齊，自此我們從部署合約的callData里得到構(gòu)造參數(shù)序列化后的字節(jié)流

????????????????從整個(gè)字節(jié)流的最后往前，按64個(gè)字符（32字節(jié)）為單位往前找，最終截取到最后320個(gè)字符即為construct params

????????????在remix中部署合約

????????????????編譯合約，并在構(gòu)造參數(shù)中填入構(gòu)造參數(shù)，點(diǎn)擊deploy

????????????????????1 start方法有modifier isAmdin, 可以通過(guò)2個(gè)方法繞過(guò)

????????????????????????構(gòu)造函數(shù)的admins數(shù)組中添加abi.encode(msg.sender), 將當(dāng)前地址添加到管理員

????????????????????????或者start方法去掉modifier（建議）

????????????????????2 修改構(gòu)造函數(shù)，添加payable, 方便在部署合約時(shí)直接轉(zhuǎn)賬eth, 減少操作步驟

????3 本地驗(yàn)證合約功能

????????1 解析原有合約的start函數(shù)參數(shù)，并作為參數(shù)調(diào)用本地remix的start方法

????????2 調(diào)用try方法，參數(shù)為上一步解析到的response字符串，發(fā)現(xiàn)能正常命中邏輯，順利走到合約往自己轉(zhuǎn)賬的流程

????????????如圖，尾號(hào)ddC4是管理員，部署合約同時(shí)轉(zhuǎn)賬10eth, 調(diào)用start方法

????????????尾號(hào)5cb2是普通的答題用戶，調(diào)用try方法，成功從合約中獲取10eth

????????3 本地驗(yàn)證結(jié)論

????????????本地重現(xiàn)后，發(fā)現(xiàn)合約邏輯是通暢的，即正確輸入response后能獲取合約中的eth

????????????那么就有可能在start函數(shù)調(diào)用前后，someone通過(guò)什么方法更新了合約內(nèi)部的變量值

????????4 通過(guò)合約storage中的關(guān)鍵字段更新倒推可能存在的關(guān)鍵交易

????????????1 合約本地storage變量

????????????????共有3個(gè)，question字符串，responseHash, admin映射

????????????????其中responseHash是try函數(shù)主要對(duì)比的字段值，所以關(guān)注目標(biāo)即為slot=1, 查看該插槽值變更的情況

????????????2 重點(diǎn)操作的blockNumber

????????????????部署blockNumber : 11136466

????????????????start方法的blockNumber 11136481

????????????3 分析判定：

????????????????如果合約部署完畢就有值，說(shuō)明是在啟動(dòng)流程中進(jìn)行了處理，分析重點(diǎn)應(yīng)該在合約的構(gòu)造參數(shù)中，比如修改init_code字節(jié)碼

????????????????如果過(guò)程中突然有的值，就是可能其他交易隱含的修改了合約里的值

????????????4 代碼實(shí)現(xiàn)

????????????????從11136481到11136466， 通過(guò)web3j.ethGetStorageAt(contractAddress, slotId, blockNumber)獲取每個(gè)block執(zhí)行完成后，slot1的值

????????????????最終發(fā)現(xiàn)，在11136478這個(gè)block執(zhí)行完畢后，合約里開(kāi)始有值。

? ? ????????????換句話說(shuō)，在部署合約后，start函數(shù)前，答題合約里的responseHash就有值了。之后管理員調(diào)用start方法，已無(wú)法更新合約內(nèi)部的response字段

????????????5 定位block11136478里的對(duì)應(yīng)交易

????????????????該塊里有150多個(gè)交易，每個(gè)交易都查看并解析顯然沒(méi)有操作性

????????????????目前2個(gè)方案可選

????????????????????1 通過(guò)geth節(jié)點(diǎn)，恢復(fù)到11136477這個(gè)塊，逐個(gè)重放478這個(gè)塊里的交易，直到答題合約的storage slot1被更新。

????????????????????????主要劣勢(shì)是部署節(jié)點(diǎn)并重放交易較為麻煩

????????????????????2 遍歷478塊里的交易，校驗(yàn)keccak256(fromAddress or toAddress)的值是否等于答題合約的3個(gè)admin之一

????????????????????????優(yōu)勢(shì)就是快，劣勢(shì)就是如果通過(guò)2個(gè)以上的嵌套合約調(diào)用，無(wú)法匹配到任何一個(gè)

????????????????????????最終定位到目標(biāo)交易0xa375511d7ead88c924d3568547bdd238ed39605c90c203e12e85c5ea6885e35e

????????????????????????payload合約地址 ?0xF4e96E2D3b4E27853B5eaBc5b0ddcc664F2b1eD1

????????5 隱藏的internalTransaction分析

????????????分析到這里，我們基本明確了該蜜罐合約的實(shí)現(xiàn)原理，即在start之前，通過(guò)內(nèi)聯(lián)交易更新合約里存儲(chǔ)的responseHash值，最后導(dǎo)致start方法傳入的response參數(shù)無(wú)效。

????????????該合約未開(kāi)源，對(duì)payload合約進(jìn)行反編譯，得到如下

????????????對(duì)關(guān)鍵交易的callData進(jìn)行解析，得到如下

????????????即該函數(shù)實(shí)際為 ?function 0x9278a35a(address p1, uint256 ethValue, bytes callData) public payable, 并最終調(diào)用到了答題合約的new方法寫(xiě)入了responseHash值

寫(xiě)在最后：

????此類(lèi)問(wèn)題一個(gè)較為簡(jiǎn)單的解法是直接在tenderly上查詢(xún)?cè)摵霞s，其中的internal交易會(huì)直接顯示出來(lái)，后續(xù)解析類(lèi)似

????本文的方案實(shí)際相對(duì)復(fù)雜，但也在嘗試探討：假設(shè)沒(méi)有tenderly這個(gè)平臺(tái)，通過(guò)基本功，是否可能通過(guò)其他方式分析出來(lái)該蜜罐合約的異常以及對(duì)應(yīng)的實(shí)現(xiàn)原理？以及tenderly這個(gè)平臺(tái)自身是如何實(shí)現(xiàn)的對(duì)internal tx 在目標(biāo)合約的交易列表里進(jìn)行關(guān)聯(lián)和展示

????????下一步考慮在測(cè)試鏈上重現(xiàn)相關(guān)交易，進(jìn)一步加深理解

ps1 該地址上的蜜罐交易提醒 https://etherscan.io/tx/0xf5a744cf53e87251661dbae13bf243bd22144e6056286206deb1a2bcac010219

ps2 近期類(lèi)似的蜜罐合約地址，有興趣的話大家也可以自己練練手 ethereum:0x20c45165e4821773bf712416bd5044416cae1f03

水平有限，如有錯(cuò)誤，請(qǐng)幫忙指正