Sözleşmeye Tersine Mühendislik Uygulama

Giriş

Blokzincirde sır yoktur; her şey tutarlı, doğrulanabilir ve herkes tarafından erişilebilirdir. İdeal olarak sözleşmelerin kaynak kodları Etherscan'de yayımlanmalı ve doğrulanmalıdır(opens in a new tab). Fakat, durum her zaman böyle değildir(opens in a new tab). Bu makalede, kaynak kodu olmayan bir sözleşmeye bakarak sözleşmelerde tersine mühendislik yapmayı öğreneceksiniz, 0x2510c039cc3b061d79e564b38836da87e31b342f(opens in a new tab).

Ters derleyiciler vardır, fakat her zaman kullanılabilir sonuçlar(opens in a new tab) üretmezler. Bu makalede manuel olarak bir sözleşmeye işlem kodlarından(opens in a new tab) nasıl ters mühendislik yapabileceğinizi, sözleşmeyi nasıl anlayacağınızı ve bununla birlikte bir ters derleyicinin sonuçlarını nasıl yorumlayacağınızı öğreneceksiniz.

Bu makaleyi anlayabilmek için Ethereum Sanal Makinesi'nin temellerini çoktan biliyor olmalı ve en azından Ethereum Sanal Makinesi'nin derleyicisine aşina olmalısınız. Bu konuları buradan okuyabilirsiniz(opens in a new tab).

Yürütülebilir Kodu Hazırlama

İşlem kodlarını sözleşme için Etherscan'e gidip Sözleşme seçeneğine ve sonrasında İşlem Kodu Görünümüne Geç'e tıklayarak alabilirsiniz. Bir satıra bir işlem kodunun düştüğü bir görünüm elde edeceksiniz.

Bununla birlikte, sıçramaları anlayabilmek için her kodda işlem kodunun nerede olduğunu bilmeniz gerekir. Bunu yapmanın bir yolu, bir Google Elektronik Tablosu açıp işlem kodlarını C sütununa yapıştırmaktır. Önceden hazırlanmış bu elektronik tablonun bir kopyasını oluşturarak sonraki adımları atlayabilirsiniz(opens in a new tab).

Sonraki adım, sıçramaları anlayabilmemiz için doğru kod konumlarını almaktır. B sütununa işlem kodu boyutunu, A sütünuna da (onaltılık olarak) konumu koyacağız. B1 hücresine bu fonksiyonu yazın ve kodun sonuna kadar B sütunun geri kalanı için kopyalayıp yapıştırın. Bunu yaptıktan sonra B sütununu gizleyebilirsiniz.

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

İlk olarak bu fonksiyon işlem kodunun kendisi için bir bayt ekler, sonra da PUSH araması yapar. İtme işlem kodları özeldir, çünkü itilen değer için ekstra baytlara sahip olmak zorundadırlar. Eğer işlem kodu bir PUSH ise, bayt sayısını çıkarır ve ekleriz.

A1'e ilk kayma olan 0'ı koyun. Ardından A2'ye bu fonksiyonu koyun ve yine A sütununun geri kalanı için kopyalayıp yapıştırın:

1=dec2hex(hex2dec(A1)+B1)

Bu fonksiyonun bize onaltılık bir değer vermesine ihtiyacımız var çünkü sıçramalardan (JUMP and JUMPI) önceki itilen değerler de bize onaltılık şekilde verilir.

Giriş Noktası (0x00)

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

Bu kod iki şey yapar:

1. 0x80'i 0x40-0x5F bellek konumlarına 32 baytlık bir değer olarak (0x80, 0x5F'de depolanır ve 0x40-0x5E tamamen sıfırlardan oluşur) yazın.
2. Çağrı verisini boyutunu okuyun. Ethereum sözleşmesi için olan bir çağrı verisi normalde, fonksiyon seçici için minimum 4 bayta ihtiyaç duyan ABI'yi (uygulama ikili arayüzü)(opens in a new tab) takip eder. Eğer çağrı verisi boyutu dörtten azsa, 0x5E'ye sıçrayın.

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

Bu kod parçası bir JUMPDEST ile başlar. Eğer JUMPDEST olmayan bir işlem koduna sıçrama yaparsanız EVM (Ethereum Sanal Makinesi) bir istisna verir. Ardından CALLDATASIZE'a bakar ve eğer "doğru" ise (sıfır değilse) 0x7C'ye sıçrar. Buna aşağıda değineceğiz.

Yani hiç çağrı verisi olmadığında Depo[6] değerini okuruz. Bu değerin ne olduğunu henüz bilmiyoruz, fakat sözleşmenin hiç çağrı verisi almadığı işlemleri arayabiliriz. Çağrı verisi olmadan (bu sebeple yöntem da olmadan) ETH transfer eden işlemler için Etherscan'de Transfer adında bir yöntem vardır. Aslında, sözleşmenin aldığı ilk işlem(opens in a new tab) bir transferdir.

Eğer işleme bakıp Daha fazlası için tıklayın öğesine tıklarsak, girdi verileri de denen çağrı verilerinin aslında boş olduğunu (0x) görürüz. Değerin 1,559 ETH olduğuna da dikkat edin, daha sonra işimize yarayacak.

Şimdi, 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 değiştiğini görebilirsiniz, eğer Onaltılığı Sayı olarak değiştirirseniz değerin, bir sonraki sözleşme değerine karşılık gelen 1.559.000.000.000.000.000'a dönüştüğünü görebilirsiniz, bu değer wei cinsindendir (noktaları kolay anlaşılması için ekledim).

Aynı zaman aralığında diğer Transfer işlemlerinden kaynaklanan durum değişikliklerine baktığımızda(opens in a new tab) Storage[6]'ın, sözleşmenin değerini bir süre takip ettiğiniz görürüz. Şimdilik buna Value* adını vereceğiz. Buradaki yıldız işareti (*), henüz bu değişkenin ne yaptığını bilmediğimizi hatırlatır, fakat bu sadece sözleşme değerini takip etmeye yönelik olamaz çünkü hesap bakiyenizi ADDRESS BALANCE'ı kullanarak görebilirken depolamayı kullanmaya gerek yoktur ve zaten çok pahalıdır. İlk işlem kodu sözleşmenin kendi adresini iter. İkincisi de yığının en üstündeki adresi okur ve bunu hesabın bakiyesiyle değiştirir.

Bu kodu sıçrama hedefinde takip etmeye devam edeceğiz.

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

Eğer Value*, 2^256-CALLVALUE-1'den küçük ya da ona eşitse sıçrarız. Bu, taşmayı engelleme mantığına benzer. Ve gerçekten de, 0x01DE ofsetinde birkaç anlamsız işlemden sonra (örneğin belleğe yazma silinmek üzere) normal davranış olan taşma algılanırsa sözleşmenin geri döndüğünü görüyoruz.

Bunun gibi bir taşmanın oldukça uzak bir ihtimal olduğunu da gözden kaçırmayın. Çünkü böyle bir taşma, çağrı değeri ile Value* toplamının 2^256 wei ya da 10^59 ETH gibi bir değer civarında olmasını gerektirir. Toplam ETH arzı, yazıyla iki yüz milyondan azdır(opens in a new tab).

Eğer buraya geldiysek Value* + CALLVALUE değerini alalım ve kayma 0x75 değerine sıçrayalım.

Buraya gelince de (bu, çağrı verisinin boş olmasını gerektirir), Value*'yu çağrı değerine ekleyelim. Bu Transfer işlemlerinin yaptıkları ile tutarlıdır.

Son olarak, yığını temizleyin (aslında pek de gerekli değildir) ve işlemin başarıyla tamamlandığına dair sinyali verin.

Hepsini özetlemek için işte başlangıçtaki kod için bir akış şeması.

0x7C'deki İşleyici

Bu işleyicinin ne yaptığını bilerek başlığa koymadım. Buradaki amaç, size bu spesifik sözleşmenin nasıl çalıştığını değil, sözleşmelere nasıl tersine mühendislik yapacağınızı öğretmek. Ne yaptığını benimle aynı şekilde öğreneceksiniz, yani kodu takip ederek.

Buraya birkaç farklı yerden geliriz:

• Eğer çağrı verisi 1, 2 ya da 3 baytsa (0x63 kaymasından)
• Eğer yöntem imzası bilinmiyorsa (0x42 ve 0x5D kaymalarından)

Bu başka bir depolama hücresidir, herhangi bir işlemde bulamadığım bir hücre. Bu yüzden bunun ne anlama geldiğini bilmek biraz daha zor. Aşağıdaki kod bunu daha açık hale getirecektir.

Bu işlem kodları Storage[3]'den okuduğumuz değeri 160 bite kırpar, bu da bir Ethereum adresinin uzunluğudur.

Bu sıçrama sadece bir sonraki işlem koduna gideceğimiz için gereksizdir. Bu kod, ulaşabileceği gaz verimliliğine yakın bile değildir.

Bu kodun en başında Mem[0x40]'i 0x80 olarak ayarlıyoruz. 0x40'ı aradığımızda, değiştirmediğimizi görüyoruz; yani 0x80 olduğunu varsayabiliriz.

0x80'den başlayarak tüm veriyi belleğe kopyalayın.

Şimdi her şey daha açık. Bu sözleşme asıl işi yapması için Storage[3]'teki adresi arayan bir vekil(opens in a new tab) olarak hareket edebilir. DELEGATE_CALL ayrı bir sözleşmeye çağrı yapar, fakat aynı depoda kalır. Bu, vekili olduğumuz yetkili sözleşmenin aynı depolama alanına eriştiği anlamına gelir. Bu çağrı için parametreler şu şekildedir:

• Gaz: Kalan tüm gaz
• Aranan adres: Adres-olarak-Storage[3]
• Çağrı verisi Orijinal çağrı verisini koyduğumuz 0x80'den başlayan CALLDATASIZE baytları
• Dönen veri: Yok (0x00 - 0x00) Dönen veriyi başka şekillerde alacağız (aşağıya bakın)

Burada dönen veriyi 0x80'den başlayan arabellek hafızasına kopyalıyoruz.

Yani çağrının ardından dönen veriyi 0x80 - 0x80+RETURNDATASIZE arabelleğine kopyaladıktan sonra, çağrı başarılı olduysa sonrasında tam olarak o arabellekle RETURN yapıyoruz.

DELEGATECALL Başarısız oldu

Buraya, yani 0xC0'a geldiysek, çağrı yaptığımız sözleşme geri dönmüştür. Bu sözleşme açısından sadece bir vekil olduğumuz için aynı veriyi döndürmek ve ayrıca geri dönmek istiyoruz.

Yani daha önce RETURN: 0x80 - 0x80+RETURNDATASIZE için kullandığımız arabellekle REVERT yapıyoruz

ABI çağrıları

Eğer veri boyutu 4 bayt ya da 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ü bu, Etherscan bu özelliği yazdıktan sonra eklendi(opens in a new tab) ve onu 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

Testleri eşleştiren yöntem imzasını buradaki gibi ikiye bölmek, ortalama olarak testlerin yarısından tasarruf etmemizi sağlar. Bu cümlenin hemen ardından gelen kod ve 0x43'teki kod aynı deseni izler: İlk 32 bitlik çağrı verileri için DUP1, ardından PUSH4 (((method signature> uygulayın, eşitliği kontrol etmek için EQ çalıştırın ve ardından yöntem imzası eşleşirse JUMPI komutunu kullanın. Yöntem imzaları, adresleri ve biliniyorsa karşılık gelen yöntem tanımı(opens in a new tab) aşağıda verilmiştir:

Eşleşme bulunamazsa kod, bizim vekili olduğumuz sözleşmenin bir eşleşmesi olmasını umarak 0x7C'deki vekil işlayicisine sıçrar.

splitter()

Bu fonksiyonun yaptığı ilk şey, çağrının ETH göndermediğini doğrulamaktır. Bu fonksiyon payable(opens in a new tab) değildir. Eğer biri bize ETH gönderdiyse bu bir hata olarak gerçekleşmiştir ve o kişiyi ETH'lerini geri alamayacağı bir duruma sokmaktan kaçınmak için REVERT yapmamız gerekir.

Ve 0x80 artık vekil adresini içeriyor

E4 Kodu

Bu bu satırları ilk görüşümüz, fakat bunlar diğer yöntemlerle paylaşıldı (aşağı bakın). X yığınındaki değeri arayacağız; splitter()'da bu Xin değerinin 0xA0 olduğunu unutmayın.

Yani bu kod, yığında (X) bir bellek işaretçisi alır ve sözleşmenin, arabelleği 0x80 - X olan bir RETURN durumuna uğramasına sebep olur.

splitter() durumunda bu, vekili olduğumuz adresi döndürür. RETURN, veriyi yazdığımız yerin adresi olan 0x80-0x9F'deki arabelleği verir (0x130un yukarısındaki kayma).

currentWindow()

0x158-0x163 kaymalarındaki kod, splitter() içindeki 0x103-0x10E'de gördüğümüzle aynıdır (JUMPI hedefi dışında), bu nedenle currentWindow()'un da payable olmadığını biliyoruz.

DA kodu

Bu kod da diğer yöntemlerle paylaşılmıştır. Yani Y yığınındaki değeri çağıracağız; currentWindow()'da bu Y'nin değerinin Storage[1] olduğunu unutmayın.

0x80-0x9F'e Y'yi yazalım.

Ve geri kalanı da yukarıda anlatılmıştır. Yani 0xDA'ya yapılan sıçramalar yığının başını (Y), 0x80-0x9F'ye yazar ve bu değeri döndürür. Bir currentWindow() durumunda, Storage[1]'ı verir.

merkleRoot()

0x158-0x163 kaymalarındaki kod, splitter() içindeki 0x103-0x10E'de gördüğümüzle aynıdır (JUMPI hedefi dışında), bu nedenle merkleRoot()'un da payable olmadığını biliyoruz.

Sıçramadan sonra ne olduğunu çoktan anladık. Yani merkleRoot() Storage[0]'ı döndürür.

0x81e580d3

0xC4-0xCF kaymalarındaki kod, splitter() içindeki 0x103-0x10E'de gördüğümüzle aynıdır (JUMPI hedefi dışında), dolayısıyla bu fonksiyonun da payable olmadığını biliyoruz.

Bu fonksiyon en az 32 bayt (1 kelime) çağrı verisi alıyor gibi görünüyor.

Eğer hiçbir çağrı verisi almazsa bu işlem gelen hiçbir veri olmadan geri döndürülür.

Şimdi de does fonksiyonu ihtiyacı olan çağrı verisini aldığında neler olduğunu görelim.

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

Eğer ilk kelime Storage[4]'ten az değilse, fonksiyon başarısız olur. Herhangi bir gelen veri olmadan geri döndürülür:

Eğer calldataload(4) Storage[4]'ten azsa, şu kodu alırız:

Ve 0x00-0x1F bellek konumları artık 0x04 verilerini içermektedir (0x00-0x1E'lerin hepsi sıfır, 0x1F ise dört)

Öyleyse depolamada, 0x000...0004'ün SHA3'ünde başlayan bir arama tablosu vardır ve bu tablo, her yasal çağrı verisi değeri için bir giriş içerir (Storage[4]'ın altında değer).

0xDA kaymasındaki kodun ne yaptığını zaten biliyoruz, arayan kişiye yığının üst değerini döndürür. Yani bu fonksiyon, arayana arama tablosundaki değeri döndürür.

0x1f135823

0xC4-0xCF kaymalarındaki kod, splitter() içindeki 0x103-0x10E'de gördüğümüzle aynıdır (JUMPI hedefi dışında), dolayısıyla bu fonksiyonun da payable olmadığını biliyoruz.

0xDA uzaklığındaki kodun ne yaptığını zaten biliyoruz, arayan kişiye yığının üst değerini döndürür. Yani bu fonksiyon Value* döndürür.

Yöntem Özeti

Bu noktada sözleşmeyi anladığınızı düşünüyor musunuz? Ben düşünmüyorum. Şu ana kadar elimizde şu yöntemler var:

Ancak diğer işlevlerin Storage[3]'da sözleşme tarafından sağlandığını biliyoruz. Belki o sözleşmenin ne olduğunu bilseydik bize bir ipucu verirdi. Neyse ki, blokzincirden bahsediyoruz ve en azından teoride de olsa her şey biliniyor. Storage[3] değerini ayarlayan herhangi bir yöntem görmedik, dolayısıyla bunun oluşturucu tarafından ayarlanmış olması gerekir.

Yapıcı

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

O işleme ve sonrasında da Durum sekmesine tıklarsak, parametrelerin başlangıç değerlerini görebiliriz. Spesifik olarak, Storage[3]'ın 0x2f81e57ff4f4d83b40a9f719fd892d8e806e0761(opens in a new tab) değerini içerdiğini görebiliriz. O sözleşme, eksik işlevselliği içermek zorundadır. Araştırdığımız sözleşme için kullandığımız araçların aynılarını kullanarak bunu anlayabiliriz.

Vekil Sözleşmesi

Yukarıdaki orijinal sözleşme için kullandığımız tekniklerin aynılarını kullanarak kontratın şu durumlarda eski haline döndüğünü görüyoruz:

• Çağrıya iliştirilmiş herhangi bir miktarda ETH varsa (0x05-0x0F)
• Çağrı verisi boyutu dörtten azsa (0x10-0x19 ve 0xBE-0xC2)

Desteklediği yöntemler:

Alttaki 4 metodu görmezden gelebiliriz, çünkü onları ele almayacağız. İmzaları, orijinal sözleşmemizin kendileriyle ilgileneceği şekildedir (yukarıdaki ayrıntıları görmek için imzalara tıklayabilirsiniz), bu nedenle bunlar, geçersiz kılınan yöntemler(opens in a new tab) olmalıdır.

Kalan yöntemlerden biri claim(<params>), diğeri de isClaimed(<params>) şeklindedir, dolayısıyla bir airdrop sözleşmesini andırır. İşlem kodundan işlem koduna geri kalanların üzerinden geçmek yerine, bu sözleşmeden üç fonksiyon için kullanılabilir sonuçlar oluşturan geri derleyiciyi deneyebiliriz(opens in a new tab). Diğerlerine tersine mühendislik yapmak ise alıştırma olarak okuyucuya bırakılmıştır.

scaleAmountByPercentage

Bu fonksiyon için geri derleyicinin bize verdiği şey şudur:

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

İlk require çağrı verilerinin, fonksiyon 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 durum bu değilse, kesinlikle yanlış bir şeyler vardır.

if ifadesi, _param1 değerinin sıfır olmadığını ve _param1 * _param2 değerinin negatif olmadığını doğrulamaya çalışıyor gibi görünüyor. Muhtemelen paketleme durumlarını önlemek içindir.

Son olarak, fonksiyon ölçeklendirilmiş bir değer döndürür.

talep et

Geri derleyicinin oluşturduğu kod karmaşık ve bunun haricinde tamamı da bizim açımızdan ilgili değil. Bunların bir kısmını atlayıp bize işe yarar bilgi sağlayacağına inandığım satırlara odaklanacağım

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

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

• _param2, bir uint256 olarak tanıtılmasına rağmen aslında bir adrestir
• _param1, şimdi ya da öncesinde currentWindow olması gereken, üstlenilen penceredir.

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

Yani artık Storage[5]'ın pencere ve adreslerden oluşan bir dizi olduğunu ve adresin o pencere için ödülü alıp almadığını biliyoruz.

1  ...
2  idx = 0
3  s = 0
4  while idx < _param4.length:
5  ...
6      if s + sha3(mem[(32 * _param4.length) + 328 len mem[(32 * _param4.length) + 296]]) > mem[(32 * idx) + 296]:
7          mem[mem[64] + 32] = mem[(32 * idx) + 296]
8          ...
9          s = sha3(mem[_62 + 32 len mem[_62]])
10          continue
11      ...
12      s = sha3(mem[_66 + 32 len mem[_66]])
13      continue
14  if unknown2eb4a7ab != s:
15      revert with 0, 'Invalid proof'
Tümünü göster
 Kopyala

unknown2eb4a7ab değerinin aslında merkleRoot() fonksiyonu olduğunu biliyoruz, dolayısıyla bu kod bir merkle kanıtını(opens in a new tab) doğruluyor gibi görünüyor. Bu, _param4 değerinin bir merkle kanıtı olduğu anlamına geliyor.

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

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

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

En alttaki iki satır, bize Storage[2]'ın da çağrı yaptığımız bir sözleşme olduğunu söyler. Oluşturucu işlemine bakarsak(opens in a new tab) bu sözleşmenin 0xc02aaa39b223fe8d0a0e5c4f27ead9083c756cc2(opens in a new tab), kaynak kodu Etherscan'e yüklenmiş bir Paketlenmiş Ether sözleşmesi olduğunu görürüz(opens in a new tab).

Sözleşme, _param2'ye ETH göndermeye çalışıyor gibi görünüyor. Eğer yapabilirse, çok iyi. Yapamazsa, WETH(opens in a new tab) göndermeye çalışacak. Eğer _param2 dışarıdan sahip olunan hesap (EOA) ise, her zaman ETH alabilir, fakat sözleşmeler ETH almayı reddedebilir. Bununla birlikte, WETH bir ERC-20'dir ve sözleşmeler bunu kabul etmeyi reddedemez.

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

Fonksiyonun sonunda bir günlük girdisinin oluşturulduğunu görüyoruz. Oluşturulmuş günlük girdilerine bakın(opens in a new tab) ve 0xdbd5... ile başlayan konuyu filtreleyin. Böyle bir girdi oluşturmuş işlemlerden birine tıklarsak(opens in a new tab) gerçekten de üstlenme gibi göründüğünü görebiliriz; hesap, tersine mühendislik yaptığımız sözleşmeye bir mesaj göndermiş ve karşılığında ETH almıştır.

1e7df9d3

Bu fonksiyon, yukarıdaki claim fonksiyonuna çok benziyor. Ayrıca bir merkle kanıtını kontrol eder, ilkine ETH transfer etmeyi dener ve aynı türde bir günlük girdisi oluşturur.

1def unknown1e7df9d3(uint256 _param1, uint256 _param2, array _param3) payable:
2  ...
3  idx = 0
4  s = 0
5  while idx < _param3.length:
6      if idx >= mem[96]:
7          revert with 0, 50
8      _55 = mem[(32 * idx) + 128]
9      if s + sha3(mem[(32 * _param3.length) + 160 len mem[(32 * _param3.length) + 128]]) > mem[(32 * idx) + 128]:
10          ...
11          s = sha3(mem[_58 + 32 len mem[_58]])
12          continue
13      mem[mem[64] + 32] = s + sha3(mem[(32 * _param3.length) + 160 len mem[(32 * _param3.length) + 128]])
14  ...
15  if unknown2eb4a7ab != s:
16      revert with 0, 'Invalid proof'
17  ...
18  call addr(_param1) with:
19     value s wei
20       gas 30000 wei
21  if not return_data.size:
22      if not ext_call.success:
23          require ext_code.size(stor2)
24          call stor2.deposit() with:
25             value s wei
26               gas gas_remaining wei
27  ...
28  log 0xdbd5389f: addr(_param1), s, bool(ext_call.success)
Tümünü göster
 Kopyala

Asıl fark geri çekilecek olan pencere olan ilk parametrenin orada olmamasıdır. Bunun yerine, her pencerenin üstünde alınabilecek bir döngü vardır.

1  idx = 0
2  s = 0
3  while idx < currentWindow:
4      ...
5      if stor5[mem[0]]:
6          if idx == -1:
7              revert with 0, 17
8          idx = idx + 1
9          s = s
10          continue
11      ...
12      stor5[idx][addr(_param1)] = 1
13      if idx >= unknown81e580d3.length:
14          revert with 0, 50
15      mem[0] = 4
16      if unknown81e580d3[idx] and _param2 > -1 / unknown81e580d3[idx]:
17          revert with 0, 17
18      if s > !(unknown81e580d3[idx] * _param2 / 100 * 10^6):
19          revert with 0, 17
20      if idx == -1:
21          revert with 0, 17
22      idx = idx + 1
23      s = s + (unknown81e580d3[idx] * _param2 / 100 * 10^6)
24      continue
Tümünü göster
 Kopyala

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

Sonuç

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