Bir Sözleşmeye Tersine Mühendislik Uygulamak

Giriş

Blokzincirde sır yoktur, gerçekleşen her şey tutarlı, doğrulanabilir ve herkese açıktır. İdeal olarak, sözleşmelerin kaynak kodları Etherscan üzerinde yayınlanmalı ve doğrulanmalıdır (opens in a new tab). Ancak, durum her zaman böyle değildir (opens in a new tab). Bu makalede, kaynak kodu olmayan bir sözleşmeye, 0x2510c039cc3b061d79e564b38836da87e31b342f (opens in a new tab), bakarak sözleşmelere nasıl tersine mühendislik uygulayacağınızı öğreneceksiniz.

Tersine derleyiciler vardır, ancak her zaman kullanılabilir sonuçlar (opens in a new tab) üretmezler. Bu makalede, bir sözleşmeyi işlem kodlarından (opens in a new tab) manuel olarak nasıl tersine mühendislik uygulayıp anlayacağınızı ve bir tersine derleyicinin sonuçlarını nasıl yorumlayacağınızı öğreneceksiniz.

Bu makaleyi anlayabilmek için EVM'nin temellerini zaten biliyor olmalı ve EVM assembly'sine en azından biraz aşina olmalısınız. Bu konular hakkında buradan bilgi edinebilirsiniz (opens in a new tab).

Çalıştırılabilir Kodu Hazırlama

Sözleşme için Etherscan'e gidip Sözleşme sekmesine ve ardından İşlem Kodları Görünümüne Geç'e tıklayarak işlem kodlarını alabilirsiniz. Her satırda bir işlem kodu olan bir görünüm elde edersiniz.

Ancak atlamaları anlayabilmek için her bir işlem kodunun kodun neresinde bulunduğunu bilmeniz gerekir. Bunu yapmanın bir yolu, bir Google E-Tablosu açmak ve işlem kodlarını C sütununa yapıştırmaktır. Önceden hazırlanmış bu e-tablonun bir kopyasını oluşturarak aşağıdaki adımları atlayabilirsiniz (opens in a new tab).

Sonraki adım, atlamaları anlayabilmemiz için doğru kod konumlarını elde etmektir. İşlem kodu boyutunu B sütununa ve konumu (onaltılık sistemde) A sütununa koyacağız. Bu işlevi B1 hücresine yazın ve ardından kodun sonuna kadar B sütununun geri kalanı için kopyalayıp yapıştırın. Bunu yaptıktan sonra B sütununu gizleyebilirsiniz.

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

İlk olarak bu işlev, işlem kodunun kendisi için bir bayt ekler ve ardından PUSH arar. Push işlem kodları özeldir çünkü yığına eklenen değer için ek baytlara sahip olmaları gerekir. Eğer işlem kodu bir PUSH ise, bayt sayısını çıkarır ve bunu ekleriz.

A1 hücresine ilk ofseti, yani sıfırı koyun. Ardından, A2 hücresine bu işlevi koyun ve yine A sütununun geri kalanı için kopyalayıp yapıştırın:

=dec2hex(hex2dec(A1)+B1)

Bu işlevin bize onaltılık değeri vermesine ihtiyacımız var çünkü atlamalardan önce yığına eklenen değerler (JUMP ve JUMPI) bize onaltılık sistemde verilir.

Giriş Noktası (0x00)

Sözleşmeler her zaman ilk bayttan itibaren yürütülür. Bu, kodun başlangıç kısmıdır:

Bu kod iki şey yapar:

1. 0x40-0x5F bellek konumlarına 32 baytlık bir değer olarak 0x80 yazar (0x80, 0x5F'de depolanır ve 0x40-0x5E'nin tamamı sıfırdır).
2. Çağrı verisi boyutunu okur. Normalde bir Ethereum sözleşmesi için çağrı verisi, işlev seçici için en az dört bayt gerektiren ABI'yi (uygulama ikili arayüzü) (opens in a new tab) izler. Çağrı verisi boyutu dörtten küçükse, 0x5E'ye atlar.

0x5E'deki İşleyici (ABI olmayan çağrı verisi için)

Bu kod parçacığı bir JUMPDEST ile başlar. EVM (Ethereum sanal makinesi) programları, JUMPDEST olmayan bir işlem koduna atlarsanız bir istisna fırlatır. Ardından CALLDATASIZE'a bakar ve eğer "doğru" ise (yani sıfır değilse) 0x7C'ye atlar. Buna aşağıda değineceğiz.

Yani çağrı verisi olmadığında Storage[6] değerini okuruz. Bu değerin ne olduğunu henüz bilmiyoruz, ancak sözleşmenin çağrı verisi olmadan aldığı işlemleri arayabiliriz. Herhangi bir çağrı verisi (ve dolayısıyla hiçbir yöntem) olmadan sadece ETH transfer eden işlemler Etherscan'de Transfer yöntemine sahiptir. Aslında, sözleşmenin aldığı ilk işlem (opens in a new tab) bir transferdir.

O işleme bakıp Click to see More (Daha Fazlasını Görmek İçin Tıklayın) seçeneğine tıklarsak, girdi verisi olarak adlandırılan çağrı verisinin gerçekten boş olduğunu (0x) görürüz. Ayrıca değerin 1.559 ETH olduğuna dikkat edin, bu daha sonra önemli olacaktır.

Ardından, State (Durum) sekmesine tıklayın ve tersine mühendislik yaptığımız sözleşmeyi (0x2510...) genişletin. İşlem sırasında Storage[6]'nın değiştiğini görebilirsiniz ve Hex'i Number (Sayı) olarak değiştirirseniz, wei cinsinden transfer edilen değere (netlik için virgülleri ben ekledim) karşılık gelen 1.559.000.000.000.000.000 olduğunu görürsünüz, bu da bir sonraki sözleşme değerine karşılık gelir.

Aynı dönemdeki diğer Transfer işlemlerinin (opens in a new tab) neden olduğu durum değişikliklerine bakarsak, Storage[6]'nın bir süre sözleşmenin değerini izlediğini görürüz. Şimdilik buna Value* diyeceğiz. Yıldız işareti (*) bize bu değişkenin ne yaptığını henüz bilmediğimizi hatırlatır, ancak sadece sözleşme değerini izlemek için olamaz çünkü hesap bakiyenizi ADDRESS BALANCE kullanarak alabiliyorken çok pahalı olan depolamayı kullanmaya gerek yoktur. İlk işlem kodu sözleşmenin kendi adresini iter. İkincisi, yığının en üstündeki adresi okur ve onu o adresin bakiyesiyle değiştirir.

Bu kodu atlama hedefinde izlemeye devam edeceğiz.

NOT bitseldir, bu nedenle çağrı değerindeki her bitin değerini tersine çevirir.

Value*, 2^256-CALLVALUE-1'den küçük veya ona eşitse atlarız. Bu, taşmayı önlemeye yönelik bir mantık gibi görünüyor. Ve gerçekten de, birkaç anlamsız işlemden sonra (örneğin belleğe yazma işleminin silinmek üzere olması) 0x01DE ofsetinde, taşma tespit edilirse sözleşmenin geri alındığını görüyoruz, ki bu normal bir davranıştır.

Böyle bir taşmanın son derece düşük bir ihtimal olduğunu unutmayın, çünkü çağrı değeri artı Value*'ın 2^256 wei'ye, yani yaklaşık 10^59 ETH'ye kıyaslanabilir olmasını gerektirir. Yazının yazıldığı sırada toplam ETH arzı iki yüz milyondan azdır (opens in a new tab).

Buraya ulaştıysak, Value* + CALLVALUE'i alın ve 0x75 ofsetine atlayın.

Buraya ulaşırsak (ki bu çağrı verisinin boş olmasını gerektirir), Value*'a çağrı değerini ekleriz. Bu, Transfer işlemlerinin yaptığını söylediğimiz şeyle tutarlıdır.

Son olarak, yığını temizleyin (ki bu gerekli değildir) ve işlemin başarılı bir şekilde sona erdiğini bildirin.

Özetlemek gerekirse, işte başlangıç kodu için bir akış şeması.

0x7C'deki İşleyici

Bu işleyicinin ne yaptığını bilerek başlığa koymadım. Amaç size bu belirli sözleşmenin nasıl çalıştığını öğretmek değil, sözleşmelerde nasıl tersine mühendislik yapılacağını öğretmektir. Ne yaptığını benim yaptığım gibi, kodu takip ederek öğreneceksiniz.

Buraya birkaç yerden geliyoruz:

• 1, 2 veya 3 baytlık çağrı verisi varsa (0x63 ofsetinden)
• Yöntem imzası bilinmiyorsa (0x42 ve 0x5D ofsetlerinden)

Bu başka bir depolama hücresidir, hiçbir işlemde bulamadığım bir hücre olduğu için ne anlama geldiğini bilmek daha zordur. Aşağıdaki kod bunu daha net hale getirecektir.

Bu işlem kodları, Storage[3]'ten okuduğumuz değeri bir Ethereum adresinin uzunluğu olan 160 bite keser.

Bir sonraki işlem koduna geçeceğimiz için bu atlama gereksizdir. Bu kod olabileceği kadar gaz açısından verimli değildir.

Kodun en başında Mem[0x40] değerini 0x80 olarak ayarladık. Daha sonra 0x40'ı ararsak, onu değiştirmediğimizi görürüz - bu yüzden 0x80 olduğunu varsayabiliriz.

Tüm çağrı verisini 0x80'den başlayarak belleğe kopyalayın.

Şimdi işler çok daha net. Bu sözleşme, asıl işi yapması için Storage[3]'teki adresi çağırarak bir vekil kontrat (opens in a new tab) olarak hareket edebilir. DELEGATE_CALL ayrı bir sözleşmeyi çağırır, ancak aynı depolamada kalır. Bu, yetkilendirilen sözleşmenin, yani vekili olduğumuz sözleşmenin aynı depolama alanına eriştiği anlamına gelir. Çağrı için parametreler şunlardır:

• Gaz: Kalan tüm gaz
• Çağrılan adres: Storage[3]-as-address
• Çağrı verisi: Orijinal çağrı verisini koyduğumuz yer olan 0x80'den başlayan CALLDATASIZE baytları
• Dönüş verisi: Yok (0x00 - 0x00) Dönüş verisini başka yollarla alacağız (aşağıya bakın)

Burada tüm dönüş verisini 0x80'den başlayan bellek arabelleğine kopyalıyoruz.

Yani çağrıdan sonra dönüş verisini 0x80 - 0x80+RETURNDATASIZE arabelleğine kopyalıyoruz ve çağrı başarılı olursa tam olarak bu arabellek ile RETURN yapıyoruz.

DELEGATECALL Başarısız Oldu

Eğer buraya, 0xC0'a gelirsek, bu çağırdığımız sözleşmenin geri alındığı anlamına gelir. O sözleşme için sadece bir vekil kontrat olduğumuzdan, aynı veriyi döndürmek ve aynı zamanda geri almak istiyoruz.

Böylece daha önce RETURN için kullandığımız aynı arabellek ile REVERT yapıyoruz: 0x80 - 0x80+RETURNDATASIZE

ABI çağrıları

Eğer çağrı verisi boyutu dört bayt veya daha fazlaysa, bu geçerli bir ABI çağrısı olabilir.

Etherscan bize 1C'nin bilinmeyen bir işlem kodu olduğunu söylüyor, çünkü Etherscan bu özelliği yazdıktan sonra eklendi (opens in a new tab) ve henüz güncellemediler. Güncel bir işlem kodu tablosu (opens in a new tab) bize bunun sağa kaydırma olduğunu gösteriyor.

Yöntem imzası eşleştirme testlerini bu şekilde ikiye bölmek, ortalama olarak testlerin yarısından tasarruf sağlar. Bunu hemen takip eden kod ve 0x43'teki kod aynı kalıbı izler: çağrı verisinin ilk 32 bitini DUP1 ile kopyala, PUSH4 (((method signature> ekle, eşitliği kontrol etmek için EQ çalıştır ve ardından yöntem imzası eşleşirse JUMPI ile atla. İşte yöntem imzaları, adresleri ve biliniyorsa ilgili yöntem tanımı (opens in a new tab):

Eğer eşleşme bulunamazsa kod, vekili olduğumuz sözleşmede bir eşleşme olması umuduyla 0x7C'deki vekil işleyiciye atlar.

splitter()

Bu fonksiyonun yaptığı ilk şey, çağrının herhangi bir ETH göndermediğini kontrol etmektir. Bu fonksiyon payable (opens in a new tab) değildir. Eğer birisi bize ETH gönderdiyse bu bir hata olmalıdır ve bu ETH'nin geri alamayacakları bir yerde kalmasını önlemek için REVERT yapmak istiyoruz.

Ve 0x80 artık vekil adresini içeriyor

E4 Kodu

Bu satırları ilk kez görüyoruz, ancak diğer metotlarla paylaşılıyorlar (aşağıya bakın). Bu yüzden yığındaki değere X diyeceğiz ve splitter() içinde bu X değerinin 0xA0 olduğunu hatırlayacağız.

Yani bu kod, yığında (X) bir bellek işaretçisi alır ve sözleşmenin 0x80 - X boyutunda bir arabellek ile RETURN yapmasına neden olur.

splitter() durumunda, bu, vekili olduğumuz adresi döndürür. RETURN, bu veriyi yazdığımız yer olan (yukarıdaki 0x130 konumu) 0x80-0x9F aralığındaki arabelleği döndürür.

currentWindow()

0x158-0x163 ofsetlerindeki kod, splitter() içinde 0x103-0x10E'de gördüğümüzle aynıdır (JUMPI hedefi dışında), bu yüzden currentWindow()'ün de payable olmadığını biliyoruz.

DA kodu

Bu kod diğer metotlarla da paylaşılıyor. Bu yüzden yığındaki değere Y diyeceğiz ve currentWindow() içinde bu Y değerinin Storage[1] olduğunu hatırlayacağız.

Y'yi 0x80-0x9F'ye yazın.

Ve geri kalanı zaten yukarıda açıklandı. Yani 0xDA'ya atlamalar, yığının en üstündekini (Y) 0x80-0x9F'ye yazar ve bu değeri döndürür. currentWindow() durumunda, Storage[1] döndürür.

merkleRoot()

0xED-0xF8 ofsetlerindeki kod, (JUMPI hedefi dışında) splitter() içinde 0x103-0x10E'de gördüğümüzle aynıdır, bu yüzden merkleRoot()'nin de payable olmadığını biliyoruz.

Atlamadan sonra ne olacağını zaten çözmüştük. Yani merkleRoot(), Storage[0] döndürür.

0x81e580d3

0x138-0x143 ofsetlerindeki kod, splitter() içindeki 0x103-0x10E'de gördüğümüzle aynıdır (JUMPI hedefi dışında), bu yüzden bu fonksiyonun da payable olmadığını biliyoruz.

Görünüşe göre bu fonksiyon en az 32 bayt (bir kelime) çağrı verisi alıyor.

Çağrı verisini almazsa, işlem herhangi bir dönüş verisi olmadan geri alınır.

Fonksiyon ihtiyaç duyduğu çağrı verisini alırsa ne olacağına bakalım.

calldataload(4), metot imzasından sonraki çağrı verisinin ilk kelimesidir

İlk kelime Storage[4]'ten küçük değilse, fonksiyon başarısız olur. Herhangi bir dönüş değeri olmadan geri alınır:

calldataload(4), Storage[4]'ten küçükse şu kodu elde ederiz:

Ve 0x00-0x1F bellek konumları artık 0x04 verisini içerir (0x00-0x1E tamamen sıfırdır, 0x1F ise dörttür)

Yani depolamada, 0x000...0004'ün SHA3'ünden başlayan ve her geçerli çağrı verisi değeri (Storage[4] altındaki değer) için bir girdi içeren bir arama tablosu vardır.

Biz zaten 0xDA ofsetindeki kodun ne yaptığını biliyoruz, yığının en üstündeki değeri çağırana döndürür. Yani bu fonksiyon, arama tablosundaki değeri çağırana döndürür.

0x1f135823

0xC4-0xCF ofsetlerindeki kod, splitter() içinde 0x103-0x10E'de gördüğümüzle aynıdır (JUMPI hedefi dışında), bu yüzden bu fonksiyonun da payable olmadığını biliyoruz.

0xDA ofsetindeki kodun ne yaptığını zaten biliyoruz, yığının en üstündeki değeri çağırana döndürür. Yani bu fonksiyon Value* döndürür.

Metot Özeti

Bu noktada sözleşmeyi anladığınızı hissediyor musunuz? Ben hissetmiyorum. Şimdiye kadar şu metotlara sahibiz:

Ancak diğer tüm işlevlerin Storage[3]'teki sözleşme tarafından sağlandığını biliyoruz. Belki o sözleşmenin ne olduğunu bilseydik bize bir ipucu verebilirdi. Neyse ki, bu bir blokzincir ve en azından teoride her şey biliniyor. Storage[3]'ü ayarlayan herhangi bir metot görmedik, bu yüzden kurucu tarafından ayarlanmış olmalı.

Kurucu

Bir sözleşmeye baktığımızda (opens in a new tab) onu oluşturan işlemi de görebiliriz.

Bu işleme ve ardından Durum sekmesine tıklarsak, parametrelerin başlangıç değerlerini görebiliriz. Özellikle, Storage[3]'ün 0x2f81e57ff4f4d83b40a9f719fd892d8e806e0761 (opens in a new tab) içerdiğini görebiliriz. Bu sözleşme eksik işlevselliği içeriyor olmalıdır. İncelediğimiz sözleşme için kullandığımız aynı araçları kullanarak onu anlayabiliriz.

Vekil Kontrat

Yukarıdaki orijinal sözleşme için kullandığımız aynı teknikleri kullanarak, sözleşmenin şu durumlarda geri alındığını görebiliriz:

• Çağrıya eklenmiş herhangi bir ETH varsa (0x05-0x0F)
• Çağrı verisi boyutu dörtten küçükse (0x10-0x19 ve 0xBE-0xC2)

Ve desteklediği yöntemler şunlardır:

Alttaki dört yöntemi görmezden gelebiliriz çünkü onlara asla ulaşamayacağız. İmzaları, orijinal sözleşmemizin bunları kendi başına halledeceği şekildedir (ayrıntıları yukarıda görmek için imzalara tıklayabilirsiniz), bu yüzden bunlar geçersiz kılınan yöntemler (opens in a new tab) olmalıdır.

Kalan yöntemlerden biri claim(<params>) ve diğeri isClaimed(<params>)'dir, bu yüzden bir airdrop sözleşmesi gibi görünüyor. Geri kalanını işlem kodu (opcode) işlem kodu incelemek yerine, bu sözleşmedeki üç işlev için kullanılabilir sonuçlar üreten geri derleyiciyi (decompiler) deneyebiliriz (opens in a new tab). Diğerlerini tersine mühendislikle çözmek okuyucuya bir alıştırma olarak bırakılmıştır.

scaleAmountByPercentage

Geri derleyicinin bu işlev için bize verdiği şey şudur:

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)

İlk require, çağrı verisinin, işlev imzasının dört baytına ek olarak, iki parametre için yeterli olan en az 64 bayta sahip olup olmadığını test eder. Eğer yoksa, açıkça yanlış bir şeyler vardır.

if ifadesi, _param1 değerinin sıfır olmadığını ve _param1 * _param2 değerinin negatif olmadığını kontrol ediyor gibi görünüyor. Bu muhtemelen başa sarma (wrap around) durumlarını önlemek içindir.

Son olarak, işlev ölçeklenmiş bir değer döndürür.

claim

Geri derleyicinin oluşturduğu kod karmaşıktır ve tamamı bizimle ilgili değildir. Yararlı bilgiler sağladığına inandığım satırlara odaklanmak için bir kısmını atlayacağım.

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'

Burada iki önemli şey görüyoruz:

• _param2, bir uint256 olarak bildirilmiş olsa da, aslında bir adrestir
• _param1, talep edilen penceredir ve currentWindow veya daha öncesi olmalıdır.

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

Böylece artık Storage[5]'in pencereler ve adreslerden oluşan bir dizi olduğunu ve adresin o pencere için ödülü talep edip etmediğini biliyoruz.

  ...
  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'

unknown2eb4a7ab'nın aslında merkleRoot() işlevi olduğunu biliyoruz, bu nedenle bu kod bir Merkle kanıtını (opens in a new tab) doğruluyor gibi görünüyor. Bu, _param4'nin bir Merkle kanıtı olduğu anlamına gelir.

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

Bir sözleşme kendi ETH'sini başka bir adrese (sözleşme veya harici olarak sahip olunan) bu şekilde transfer eder. Onu, transfer edilecek miktar olan bir değerle çağırır. Yani bu bir ETH airdrop'u gibi görünüyor.

  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

Alttaki iki satır bize Storage[2]'nin aynı zamanda çağırdığımız bir sözleşme olduğunu söylüyor. Kurucu (constructor) işlemine bakarsak (opens in a new tab), bu sözleşmenin 0xc02aaa39b223fe8d0a0e5c4f27ead9083c756cc2 (opens in a new tab), yani kaynak kodu Etherscan'e yüklenmiş (opens in a new tab) bir Sarılmış Ether (Wrapped Ether) sözleşmesi olduğunu görürüz.

Yani sözleşmeler _param2 adresine ETH göndermeye çalışıyor gibi görünüyor. Bunu yapabilirse, harika. Yapamazsa, WETH (opens in a new tab) göndermeye çalışır. Eğer _param2 harici olarak sahip olunan bir hesap (EOA) ise her zaman ETH alabilir, ancak sözleşmeler ETH almayı reddedebilir. Ancak, WETH bir ERC-20'dir ve sözleşmeler bunu kabul etmeyi reddedemez.

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

İşlevin sonunda bir günlük girdisinin oluşturulduğunu görüyoruz. Oluşturulan günlük girdilerine bakın (opens in a new tab) ve 0xdbd5... ile başlayan konuyu filtreleyin. Böyle bir girdi oluşturan işlemlerden birine tıklarsak (opens in a new tab), bunun gerçekten de bir talep gibi göründüğünü anlarız - hesap, tersine mühendislik yaptığımız sözleşmeye bir mesaj gönderdi ve karşılığında ETH aldı.

1e7df9d3

Bu işlev, yukarıdaki claim işlevine çok benzer. Ayrıca bir Merkle kanıtını kontrol eder, ilkine ETH transfer etmeye çalışır ve aynı türde günlük girdisi üretir.

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)

Temel fark, ilk parametre olan çekilecek pencerenin orada olmamasıdır. Bunun yerine, talep edilebilecek tüm pencereler üzerinde bir döngü vardır.

  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

Yani tüm pencereleri talep eden bir claim varyantı gibi görünüyor.

Sonuç

Şimdiye kadar, işlem kodlarını veya (çalıştığında) geri derleyiciyi kullanarak kaynak kodu mevcut olmayan sözleşmeleri nasıl anlayacağınızı öğrenmiş olmalısınız. Bu makalenin uzunluğundan da anlaşılacağı üzere, bir sözleşmeye tersine mühendislik uygulamak basit bir iş değildir, ancak güvenliğin esas olduğu bir sistemde sözleşmelerin vaat edildiği gibi çalıştığını doğrulayabilmek önemli bir beceridir.

Çalışmalarımın daha fazlasını görmek için buraya göz atın (opens in a new tab).