Kufanya Uhandisi wa Kinyume wa Mkataba

Utangulizi

Hakuna siri kwenye mnyororo wa vitalu, kila kitu kinachotokea ni thabiti, kinathibitishwa, na kinapatikana kwa umma. Kwa hakika, mikataba inapaswa kuwa na msimbo wake wa chanzo uliochapishwa na kuthibitishwa kwenye Etherscan (opens in a new tab). Hata hivyo, sio hivyo kila wakati (opens in a new tab). Katika makala haya utajifunza jinsi ya kufanya uhandisi wa kinyume wa mikataba kwa kuangalia mkataba usio na msimbo wa chanzo, 0x2510c039cc3b061d79e564b38836da87e31b342f (opens in a new tab).

Kuna vikusanyaji vya kinyume, lakini havitoi kila wakati matokeo yanayoweza kutumika (opens in a new tab). Katika makala haya utajifunza jinsi ya kufanya uhandisi wa kinyume kwa mikono na kuelewa mkataba kutoka kwenye misimbo ya operesheni (opens in a new tab), pamoja na jinsi ya kufasiri matokeo ya kikusanyaji cha kinyume.

Ili kuweza kuelewa makala haya unapaswa kuwa tayari unajua misingi ya EVM, na angalau kufahamu kiasi kuhusu kikusanyaji cha EVM. Unaweza kusoma kuhusu mada hizi hapa (opens in a new tab).

Andaa Msimbo Unaotekelezeka

Unaweza kupata misimbo ya operesheni kwa kwenda kwenye Etherscan kwa ajili ya mkataba, kubofya kichupo cha Mkataba na kisha Badilisha hadi Mwonekano wa Misimbo ya Operesheni. Unapata mwonekano ambao ni msimbo wa operesheni mmoja kwa kila mstari.

Hata hivyo, ili kuweza kuelewa miruko, unahitaji kujua ni wapi katika msimbo kila msimbo wa operesheni unapatikana. Ili kufanya hivyo, njia moja ni kufungua Lahajedwali ya Google na kubandika misimbo ya operesheni katika safu wima ya C. Unaweza kuruka hatua zifuatazo kwa kutengeneza nakala ya lahajedwali hii ambayo tayari imeandaliwa (opens in a new tab).

Hatua inayofuata ni kupata maeneo sahihi ya msimbo ili tuweze kuelewa miruko. Tutaweka ukubwa wa msimbo wa operesheni katika safu wima ya B, na eneo (katika heksadesimali) katika safu wima ya A. Andika kazi hii katika seli B1 na kisha unakili na kubandika kwa safu wima ya B iliyosalia, hadi mwisho wa msimbo. Baada ya kufanya hivi unaweza kuficha safu wima ya B.

=1+IF(REGEXMATCH(C1,"PUSH"),REGEXEXTRACT(C1,"PUSH(\d+)"),0)

Kwanza kazi hii inaongeza baiti moja kwa ajili ya msimbo wa operesheni wenyewe, na kisha inatafuta PUSH. Misimbo ya operesheni ya PUSH ni maalum kwa sababu inahitaji kuwa na baiti za ziada kwa ajili ya thamani inayosukumwa. Ikiwa msimbo wa operesheni ni PUSH, tunatoa idadi ya baiti na kuongeza hiyo.

Katika A1 weka ofseti ya kwanza, sifuri. Kisha, katika A2, weka kazi hii na unakili na kubandika tena kwa safu wima ya A iliyosalia:

=dec2hex(hex2dec(A1)+B1)

Tunahitaji kazi hii itupatie thamani ya heksadesimali kwa sababu thamani zinazosukumwa kabla ya miruko (JUMP na JUMPI) zinapewa kwetu katika heksadesimali.

Sehemu ya Kuingilia (0x00)

Mikataba kila wakati hutekelezwa kuanzia baiti ya kwanza. Hii ni sehemu ya awali ya msimbo:

Msimbo huu unafanya mambo mawili:

1. Kuandika 0x80 kama thamani ya baiti 32 kwenye maeneo ya kumbukumbu 0x40-0x5F (0x80 inahifadhiwa katika 0x5F, na 0x40-0x5E zote ni sifuri).
2. Kusoma ukubwa wa data za mwito. Kwa kawaida data za mwito kwa mkataba wa Ethereum hufuata ABI (kiolesura cha mfumo wa programu) (opens in a new tab), ambayo kwa uchache inahitaji baiti nne kwa kiteuzi cha utendaji. Ikiwa ukubwa wa data za mwito ni chini ya nne, ruka hadi 0x5E.

Kishughulikiaji katika 0x5E (kwa data za mwito zisizo za ABI)

Kipande hiki kinaanza na JUMPDEST. Programu za EVM (mashine pepe ya Ethereum) hurusha hitilafu ikiwa utaruka kwenye msimbo wa operesheni ambao sio JUMPDEST. Kisha inaangalia CALLDATASIZE, na ikiwa ni "kweli" (yaani, sio sifuri) inaruka hadi 0x7C. Tutafikia hilo hapa chini.

Kwa hivyo wakati hakuna data za mwito tunasoma thamani ya Storage[6]. Hatujui thamani hii ni nini bado, lakini tunaweza kutafuta miamala ambayo mkataba ulipokea bila data za mwito. Miamala ambayo inahamisha tu ETH bila data za mwito zozote (na kwa hivyo hakuna mbinu) ina mbinu ya Transfer katika Etherscan. Kwa kweli, muamala wa kwanza kabisa ambao mkataba ulipokea (opens in a new tab) ni hamisho.

Tukitazama katika muamala huo na kubofya Click to see More, tunaona kwamba data za mwito, zinazoitwa data za uingizaji, kwa kweli ni tupu (0x). Kumbuka pia kwamba thamani ni 1.559 ETH, hiyo itakuwa muhimu baadaye.

Kisha, bofya kichupo cha State na upanue mkataba tunaoufanyia uhandisi wa kinyume (0x2510...). Unaweza kuona kwamba Storage[6] ilibadilika wakati wa muamala, na ukibadilisha Hex kuwa Number, unaona ikawa 1,559,000,000,000,000,000, thamani iliyohamishwa katika wei (nimeongeza koma kwa uwazi), inayolingana na thamani inayofuata ya mkataba.

Tukitazama katika mabadiliko ya hali yaliyosababishwa na miamala mingine ya Transfer kutoka kipindi hicho hicho (opens in a new tab) tunaona kwamba Storage[6] ilifuatilia thamani ya mkataba kwa muda. Kwa sasa tutaiita Value*. Alama ya nyota (*) inatukumbusha kwamba hatujui kigezo hiki kinafanya nini bado, lakini haiwezi kuwa tu kufuatilia thamani ya mkataba kwa sababu hakuna haja ya kutumia hifadhi, ambayo ni ghali sana, wakati unaweza kupata salio la akaunti zako ukitumia ADDRESS BALANCE. Msimbo wa operesheni wa kwanza unasukuma anwani ya mkataba wenyewe. Wa pili unasoma anwani iliyo juu ya stack na kuibadilisha na salio la anwani hiyo.

Tutaendelea kufuatilia msimbo huu kwenye kituo cha kuruka.

NOT ni ya kibiti, kwa hivyo inageuza thamani ya kila biti katika thamani ya mwito.

Tunaruka ikiwa Value* ni ndogo kuliko 2^256-CALLVALUE-1 au sawa nayo. Hii inaonekana kama mantiki ya kuzuia kufurika (overflow). Na kwa kweli, tunaona kwamba baada ya operesheni chache zisizo na maana (kuandika kwenye kumbukumbu kunakaribia kufutwa, kwa mfano) kwenye offset 0x01DE mkataba unatengua ikiwa kufurika kutagunduliwa, ambayo ni tabia ya kawaida.

Kumbuka kwamba kufurika kama huko kuna uwezekano mdogo sana kutokea, kwa sababu itahitaji thamani ya mwito kujumlisha na Value* kulinganishwa na wei 2^256, takriban 10^59 ETH. Jumla ya usambazaji wa ETH, wakati wa kuandika, ni chini ya milioni mia mbili (opens in a new tab).

Ikiwa tumefika hapa, pata Value* + CALLVALUE na uruke hadi offset 0x75.

Ikiwa tutafika hapa (ambayo inahitaji data za mwito kuwa tupu) tunaongeza kwenye Value* thamani ya mwito. Hii inaendana na kile tunachosema miamala ya Transfer inafanya.

Hatimaye, futa stack (ambayo sio lazima) na uashirie mwisho wa mafanikio wa muamala.

Kwa muhtasari, hapa kuna chati mtiririko ya msimbo wa awali.

Kishughulikiaji kwenye 0x7C

Sikuweka kwa makusudi kwenye kichwa cha habari kile ambacho kishughulikiaji hiki kinafanya. Lengo si kukufundisha jinsi mkataba huu mahususi unavyofanya kazi, bali jinsi ya kufanya uhandisi wa kinyume wa mikataba. Utajifunza kile inachofanya kwa njia ile ile niliyojifunza, kwa kufuata msimbo.

Tunafika hapa kutoka sehemu kadhaa:

• Ikiwa kuna data za mwito za baiti 1, 2, au 3 (kutoka ofseti 0x63)
• Ikiwa sahihi ya mbinu haijulikani (kutoka ofseti 0x42 na 0x5D)

Hiki ni seli nyingine ya hifadhi, ambayo sikuweza kuipata katika miamala yoyote hivyo ni vigumu kujua inamaanisha nini. Msimbo ulio hapa chini utaifanya iwe wazi zaidi.

Misimbo hii ya operesheni inakata thamani tunayosoma kutoka Storage[3] hadi biti 160, urefu wa anwani ya Ethereum.

Ruko hili ni la ziada, kwa kuwa tunaenda kwenye msimbo wa operesheni unaofuata. Msimbo huu hauna ufanisi wa gesi kama unavyoweza kuwa.

Mwanzoni kabisa mwa msimbo tunaweka Mem[0x40] kuwa 0x80. Ikiwa tutatafuta 0x40 baadaye, tunaona kwamba hatuibadilishi - kwa hivyo tunaweza kudhani ni 0x80.

Nakili data zote za mwito kwenye kumbukumbu, kuanzia 0x80.

Sasa mambo yako wazi zaidi. Mkataba huu unaweza kufanya kazi kama uwakilishi (opens in a new tab), ukiita anwani katika Storage[3] kufanya kazi halisi. DELEGATE_CALL inaita mkataba tofauti, lakini inabaki katika hifadhi sawa. Hii inamaanisha kuwa mkataba uliokabidhiwa, ule ambao sisi ni uwakilishi wake, unafikia nafasi sawa ya hifadhi. Vigezo vya mwito ni:

• Gesi: Gesi yote iliyosalia
• Anwani iliyoitiwa: Storage[3]-kama-anwani
• Data za mwito: Baiti za CALLDATASIZE kuanzia 0x80, ambapo ndipo tulipoweka data asili za mwito
• Data za kurejesha: Hakuna (0x00 - 0x00) Tutapata data za kurejesha kwa njia nyingine (tazama hapa chini)

Hapa tunanakili data zote za kurejesha kwenye bafa ya kumbukumbu kuanzia 0x80.

Kwa hivyo baada ya mwito tunanakili data za kurejesha kwenye bafa 0x80 - 0x80+RETURNDATASIZE, na ikiwa mwito utafaulu basi tuna RETURN na bafa hiyo haswa.

DELEGATECALL Ilifeli

Ikiwa tutafika hapa, kwenye 0xC0, inamaanisha kuwa mkataba tuliouita ulitengua. Kwa kuwa sisi ni uwakilishi tu wa mkataba huo, tunataka kurejesha data sawa na pia kutengua.

Kwa hivyo tuna REVERT na bafa sawa tuliyotumia kwa RETURN hapo awali: 0x80 - 0x80+RETURNDATASIZE

Miito ya ABI

Ikiwa ukubwa wa data za mwito ni baiti nne au zaidi huu unaweza kuwa mwito halali wa ABI.

Etherscan inatuambia kwamba 1C ni msimbo wa operesheni usiojulikana, kwa sababu uliongezwa baada ya Etherscan kuandika kipengele hiki (opens in a new tab) na hawajasasisha. Jedwali la kisasa la msimbo wa operesheni (opens in a new tab) linatuonyesha kwamba hii ni shift right

Kwa kugawanya majaribio ya kulinganisha sahihi ya mbinu mara mbili kama hivi huokoa nusu ya majaribio kwa wastani. Msimbo unaofuata mara moja baada ya huu na msimbo katika 0x43 unafuata mtindo ule ule: DUP1 biti 32 za kwanza za data za mwito, PUSH4 (((method signature>, endesha EQ ili kuangalia usawa, na kisha JUMPI ikiwa sahihi ya mbinu inalingana. Hapa kuna sahihi za mbinu, anwani zake, na ikiwa inajulikana ufafanuzi wa mbinu unaolingana (opens in a new tab):

Ikiwa hakuna ulinganifu uliopatikana, msimbo unaruka hadi kwenye kidhibiti cha uwakilishi katika 0x7C, kwa matumaini kwamba mkataba ambao sisi ni wawakilishi wake una ulinganifu.

splitter()

Kitu cha kwanza ambacho kazi hii inafanya ni kuangalia kuwa mwito haukutuma ETH yoyote. Kazi hii si payable (opens in a new tab). Ikiwa mtu alitutumia ETH hilo lazima liwe kosa na tunataka REVERT ili kuepuka kuwa na ETH hiyo ambapo hawawezi kuipata tena.

Na 0x80 sasa ina anwani ya uwakilishi

Msimbo wa E4

Hii ni mara ya kwanza tunaona mistari hii, lakini inashirikiwa na mbinu zingine (tazama hapa chini). Kwa hivyo tutaita thamani katika staki X, na kumbuka tu kwamba katika splitter() thamani ya X hii ni 0xA0.

Kwa hivyo msimbo huu hupokea kielekezi cha kumbukumbu katika staki (X), na kusababisha mkataba RETURN na bafa ambayo ni 0x80 - X.

Katika kesi ya splitter(), hii inarejesha anwani ambayo sisi ni uwakilishi wake. RETURN inarejesha bafa katika 0x80-0x9F, ambapo ndipo tuliandika data hii (offset 0x130 hapo juu).

currentWindow()

Msimbo katika ofseti za 0x158-0x163 unafanana kabisa na kile tulichokiona katika 0x103-0x10E kwenye splitter() (isipokuwa kwa kituo cha JUMPI), kwa hivyo tunajua currentWindow() pia sio payable.

Msimbo wa DA

Msimbo huu pia unashirikiwa na mbinu zingine. Kwa hivyo tutaita thamani iliyo kwenye staki Y, na kumbuka tu kwamba katika currentWindow() thamani ya hii Y ni Storage[1].

Andika Y kwenye 0x80-0x9F.

Na iliyosalia tayari imeelezwa hapo juu. Kwa hivyo miruko kwenda 0xDA huandika juu ya staki (Y) kwenye 0x80-0x9F, na kurudisha thamani hiyo. Katika hali ya currentWindow(), inarudisha Storage[1].

merkleRoot()

Msimbo katika ofseti za 0xED-0xF8 unafanana kabisa na kile tulichokiona katika 0x103-0x10E kwenye splitter() (isipokuwa kwa kikomo cha JUMPI), kwa hivyo tunajua merkleRoot() pia sio payable.

Kile kinachotokea baada ya ruko tayari tumeshakigundua. Kwa hivyo merkleRoot() inarejesha Storage[0].

0x81e580d3

Msimbo katika ofseti 0x138-0x143 ni sawa kabisa na kile tulichokiona katika 0x103-0x10E kwenye splitter() (isipokuwa fikio la JUMPI), kwa hivyo tunajua kazi hii pia si payable.

Inaonekana kazi hii inachukua angalau baiti 32 (neno moja) za data za mwito.

Kama haipati data za mwito muamala unatenguliwa bila data zozote za kurejesha.

Hebu tuone nini kinatokea ikiwa kazi inapata data za mwito inazohitaji.

calldataload(4) ni neno la kwanza la data za mwito baada ya sahihi ya mbinu

Kama neno la kwanza si dogo kuliko Storage[4], kazi inafeli. Kinatengua bila thamani yoyote iliyorejeshwa:

Kama calldataload(4) ni ndogo kuliko Storage[4], tunapata msimbo huu:

Na maeneo ya kumbukumbu 0x00-0x1F sasa yana data 0x04 (0x00-0x1E zote ni sifuri, 0x1F ni nne)

Kwa hivyo kuna jedwali la kutafutia katika hifadhi, ambalo linaanzia kwenye SHA3 ya 0x000...0004 na lina ingizo kwa kila thamani halali ya data za mwito (thamani iliyo chini ya Storage[4]).

Tayari tunajua kile ambacho msimbo kwenye ofseti 0xDA unafanya, unarejesha thamani ya juu ya staki kwa anayetoa mwito. Kwa hivyo kazi hii inarejesha thamani kutoka kwenye jedwali la kutafutia kwa anayetoa mwito.

0x1f135823

Msimbo katika ofseti za 0xC4-0xCF unafanana na kile tulichokiona katika 0x103-0x10E kwenye splitter() (isipokuwa kwa kituo cha JUMPI), kwa hivyo tunajua kazi hii pia si payable.

Tayari tunajua kile ambacho msimbo kwenye ofseti ya 0xDA hufanya, inarejesha thamani ya juu ya staki kwa mpigaji. Kwa hivyo kazi hii inarejesha Value*.

Muhtasari wa Mbinu

Je, unahisi unaelewa mkataba katika hatua hii? Sielewi. Kufikia sasa tuna mbinu hizi:

Lakini tunajua utendakazi mwingine wowote hutolewa na mkataba katika Storage[3]. Labda kama tungejua mkataba huo ni nini ungetupa dokezo. Tunashukuru, huu ni mnyororo wa vitalu na kila kitu kinajulikana, angalau kinadharia. Hatukuona mbinu zozote zinazoweka Storage[3], kwa hivyo lazima iwe iliwekwa na konstrukta.

Konstrukta

Tunapoangalia mkataba (opens in a new tab) tunaweza pia kuona muamala uliouunda.

Tukibofya muamala huo, na kisha kichupo cha Hali, tunaweza kuona thamani za awali za vigezo. Hasa, tunaweza kuona kwamba Storage[3] ina 0x2f81e57ff4f4d83b40a9f719fd892d8e806e0761 (opens in a new tab). Mkataba huo lazima uwe na utendaji uliokosekana. Tunaweza kuuelewa kwa kutumia zana zilezile tulizotumia kwa mkataba tunaouchunguza.

Mkataba wa Uwakilishi

Kwa kutumia mbinu zilezile tulizotumia kwa mkataba wa asili hapo juu tunaweza kuona kwamba mkataba unatengua ikiwa:

• Kuna ETH yoyote iliyoambatishwa kwenye mwito (0x05-0x0F)
• Ukubwa wa data za mwito ni chini ya nne (0x10-0x19 na 0xBE-0xC2)

Na kwamba mbinu inazounga mkono ni:

Tunaweza kupuuza mbinu nne za chini kwa sababu hatutawahi kuzifikia. Sahihi zake ziko hivi kwamba mkataba wetu wa asili unazishughulikia wenyewe (unaweza kubofya sahihi ili kuona maelezo hapo juu), kwa hivyo lazima ziwe mbinu zilizobatilishwa (opens in a new tab).

Moja ya mbinu zilizosalia ni claim(<params>), na nyingine ni isClaimed(<params>), kwa hivyo inaonekana kama mkataba wa mgao wa bure. Badala ya kupitia zilizosalia msimbo wa operesheni kwa msimbo wa operesheni, tunaweza kujaribu kitenganisha msimbo (decompiler) (opens in a new tab), ambacho hutoa matokeo yanayoweza kutumika kwa vipengele vitatu kutoka kwenye mkataba huu. Kufanya uhandisi wa kinyume kwa zile nyingine kumeachwa kama zoezi kwa msomaji.

scaleAmountByPercentage

Hiki ndicho kitenganisha msimbo kinatupa kwa kipengele hiki:

def unknown8ffb5c97(uint256 _param1, uint256 _param2) payable:
  require calldata.size - 4 >=′ 64
  if _param1 and _param2 > -1 / _param1:
      revert with 0, 17
  return (_param1 * _param2 / 100 * 10^6)

require ya kwanza inajaribu kwamba data za mwito zina, pamoja na baiti nne za sahihi ya kipengele, angalau baiti 64, za kutosha kwa vigezo viwili. Ikiwa sivyo basi ni wazi kuna kitu kibaya.

Kauli ya if inaonekana kuangalia kwamba _param1 sio sifuri, na kwamba _param1 * _param2 sio hasi. Pengine ni kuzuia matukio ya mzunguko wa namba (wrap around).

Hatimaye, kipengele kinarudisha thamani iliyopimwa.

claim

Msimbo ambao kitenganisha msimbo kinaunda ni mgumu, na sio wote unaofaa kwetu. Nitaruka baadhi yake ili kuzingatia mistari ambayo ninaamini inatoa taarifa muhimu

def unknown2e7ba6ef(uint256 _param1, uint256 _param2, uint256 _param3, array _param4) payable:
  ...
  require _param2 == addr(_param2)
  ...
  if currentWindow <= _param1:
      revert with 0, 'cannot claim for a future window'

Tunaona hapa mambo mawili muhimu:

• _param2, ingawa imetangazwa kama uint256, kwa kweli ni anwani
• _param1 ni dirisha linalodaiwa, ambalo linapaswa kuwa currentWindow au mapema zaidi.

  ...
  if stor5[_claimWindow][addr(_claimFor)]:
      revert with 0, 'Account already claimed the given window'

Kwa hivyo sasa tunajua kwamba Storage[5] ni orodha ya madirisha na anwani, na kama anwani ilidai tuzo kwa dirisha hilo.

  ...
  idx = 0
  s = 0
  while idx < _param4.length:
  ...
      if s + sha3(mem[(32 * _param4.length) + 328 len mem[(32 * _param4.length) + 296]]) > mem[(32 * idx) + 296]:
          mem[mem[64] + 32] = mem[(32 * idx) + 296]
          ...
          s = sha3(mem[_62 + 32 len mem[_62]])
          continue
      ...
      s = sha3(mem[_66 + 32 len mem[_66]])
      continue
  if unknown2eb4a7ab != s:
      revert with 0, 'Invalid proof'

Tunajua kwamba unknown2eb4a7ab kwa kweli ni kipengele cha merkleRoot(), kwa hivyo msimbo huu unaonekana kama unathibitisha ushahidi wa Merkle (opens in a new tab). Hii inamaanisha kwamba _param4 ni ushahidi wa Merkle.

  call addr(_param2) with:
     value unknown81e580d3[_param1] * _param3 / 100 * 10^6 wei
       gas 30000 wei

Hivi ndivyo mkataba unavyohamisha ETH yake yenyewe kwenda kwenye anwani nyingine (mkataba au inayomilikiwa na nje). Unaiita kwa thamani ambayo ni kiasi kinachopaswa kuhamishwa. Kwa hivyo inaonekana kama huu ni mgao wa bure wa ETH.

  if not return_data.size:
      if not ext_call.success:
          require ext_code.size(stor2)
          call stor2.deposit() with:
             value unknown81e580d3[_param1] * _param3 / 100 * 10^6 wei

Mistari miwili ya chini inatuambia kwamba Storage[2] pia ni mkataba tunaouita. Ikiwa tutaangalia muamala wa konstrukta (opens in a new tab) tunaona kwamba mkataba huu ni 0xc02aaa39b223fe8d0a0e5c4f27ead9083c756cc2 (opens in a new tab), mkataba wa ether iliyofungwa (weth) ambao msimbo wake wa chanzo umepakiwa kwenye Etherscan (opens in a new tab).

Kwa hivyo inaonekana kama mikataba inajaribu kutuma ETH kwa _param2. Ikiwa inaweza kufanya hivyo, ni vizuri. Ikiwa sivyo, inajaribu kutuma WETH (opens in a new tab). Ikiwa _param2 ni akaunti inayomilikiwa na nje (EOA) basi inaweza kupokea ETH kila wakati, lakini mikataba inaweza kukataa kupokea ETH. Hata hivyo, WETH ni ERC-20 na mikataba haiwezi kukataa kuipokea.

  ...
  log 0xdbd5389f: addr(_param2), unknown81e580d3[_param1] * _param3 / 100 * 10^6, bool(ext_call.success)

Mwishoni mwa kipengele tunaona ingizo la logi likitengenezwa. Angalia maingizo ya logi yaliyotengenezwa (opens in a new tab) na uchuje kwenye mada inayoanza na 0xdbd5.... Ikiwa tutabofya mmoja wa miamala iliyotengeneza ingizo kama hilo (opens in a new tab) tunaona kwamba kwa kweli inaonekana kama dai - akaunti ilituma ujumbe kwenye mkataba tunaoufanyia uhandisi wa kinyume, na kwa malipo ikapata ETH.

1e7df9d3

Kipengele hiki kinafanana sana na claim hapo juu. Pia kinaangalia ushahidi wa Merkle, kinajaribu kuhamisha ETH kwa ya kwanza, na kinazalisha aina ileile ya ingizo la logi.

def unknown1e7df9d3(uint256 _param1, uint256 _param2, array _param3) payable:
  ...
  idx = 0
  s = 0
  while idx < _param3.length:
      if idx >= mem[96]:
          revert with 0, 50
      _55 = mem[(32 * idx) + 128]
      if s + sha3(mem[(32 * _param3.length) + 160 len mem[(32 * _param3.length) + 128]]) > mem[(32 * idx) + 128]:
          ...
          s = sha3(mem[_58 + 32 len mem[_58]])
          continue
      mem[mem[64] + 32] = s + sha3(mem[(32 * _param3.length) + 160 len mem[(32 * _param3.length) + 128]])
  ...
  if unknown2eb4a7ab != s:
      revert with 0, 'Invalid proof'
  ...
  call addr(_param1) with:
     value s wei
       gas 30000 wei
  if not return_data.size:
      if not ext_call.success:
          require ext_code.size(stor2)
          call stor2.deposit() with:
             value s wei
               gas gas_remaining wei
  ...
  log 0xdbd5389f: addr(_param1), s, bool(ext_call.success)

Tofauti kuu ni kwamba kigezo cha kwanza, dirisha la kutoa, halipo. Badala yake, kuna kitanzi (loop) kwenye madirisha yote yanayoweza kudaiwa.

  idx = 0
  s = 0
  while idx < currentWindow:
      ...
      if stor5[mem[0]]:
          if idx == -1:
              revert with 0, 17
          idx = idx + 1
          s = s
          continue
      ...
      stor5[idx][addr(_param1)] = 1
      if idx >= unknown81e580d3.length:
          revert with 0, 50
      mem[0] = 4
      if unknown81e580d3[idx] and _param2 > -1 / unknown81e580d3[idx]:
          revert with 0, 17
      if s > !(unknown81e580d3[idx] * _param2 / 100 * 10^6):
          revert with 0, 17
      if idx == -1:
          revert with 0, 17
      idx = idx + 1
      s = s + (unknown81e580d3[idx] * _param2 / 100 * 10^6)
      continue

Kwa hivyo inaonekana kama toleo la claim ambalo linadai madirisha yote.

Hitimisho

Kufikia sasa unapaswa kujua jinsi ya kuelewa mikataba ambayo msimbo wake wa chanzo haupatikani, kwa kutumia misimbo ya operesheni au (inapofanya kazi) kigeuza msimbo. Kama inavyoonekana kutokana na urefu wa makala haya, kufanya uhandisi wa kinyume wa mkataba si jambo rahisi, lakini katika mfumo ambapo usalama ni muhimu ni ujuzi muhimu kuweza kuthibitisha kuwa mikataba inafanya kazi kama ilivyoahidiwa.

Tazama hapa kwa kazi zangu zaidi (opens in a new tab).