Inżynieria wsteczna kontraktu

Wprowadzenie

Na blockchainie nie ma tajemnic, wszystko, co się dzieje, jest spójne, weryfikowalne i publicznie dostępne. W idealnym przypadku kontrakty powinny mieć swój kod źródłowy opublikowany i zweryfikowany w Etherscan (opens in a new tab). Jednak nie zawsze tak jest (opens in a new tab). W tym artykule dowiesz się, jak przeprowadzić inżynierię wsteczną kontraktów, analizując kontrakt bez kodu źródłowego, 0x2510c039cc3b061d79e564b38836da87e31b342f (opens in a new tab).

Istnieją dekompilatory, ale nie zawsze generują one użyteczne wyniki (opens in a new tab). W tym artykule dowiesz się, jak ręcznie przeprowadzić inżynierię wsteczną i zrozumieć kontrakt na podstawie kodów operacji (opens in a new tab), a także jak interpretować wyniki działania dekompilatora.

Aby zrozumieć ten artykuł, powinieneś już znać podstawy EVM i być przynajmniej trochę zaznajomiony z asemblerem EVM. Możesz przeczytać o tych tematach tutaj (opens in a new tab).

Przygotowanie kodu wykonywalnego

Kody operacji możesz uzyskać, przechodząc do Etherscan dla danego kontraktu, klikając zakładkę Contract, a następnie Switch to Opcodes View. Otrzymasz widok, w którym w każdym wierszu znajduje się jeden kod operacji.

Aby jednak móc zrozumieć skoki, musisz wiedzieć, gdzie w kodzie znajduje się każdy kod operacji. Jednym ze sposobów, aby to zrobić, jest otwarcie Arkusza Google i wklejenie kodów operacji w kolumnie C. Możesz pominąć poniższe kroki, tworząc kopię tego już przygotowanego arkusza kalkulacyjnego (opens in a new tab).

Kolejnym krokiem jest uzyskanie prawidłowych lokalizacji w kodzie, abyśmy mogli zrozumieć skoki. Rozmiar kodu operacji umieścimy w kolumnie B, a lokalizację (w systemie szesnastkowym) w kolumnie A. Wpisz tę funkcję w komórce B1, a następnie skopiuj ją i wklej do reszty kolumny B, aż do końca kodu. Po wykonaniu tej czynności możesz ukryć kolumnę B.

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

Najpierw ta funkcja dodaje jeden bajt dla samego kodu operacji, a następnie szuka PUSH. Kody operacji PUSH są wyjątkowe, ponieważ muszą mieć dodatkowe bajty dla odkładanej wartości. Jeśli kodem operacji jest PUSH, wyodrębniamy liczbę bajtów i ją dodajemy.

W A1 wpisz pierwsze przesunięcie, czyli zero. Następnie w A2 wpisz tę funkcję i ponownie skopiuj ją i wklej do reszty kolumny A:

=dec2hex(hex2dec(A1)+B1)

Potrzebujemy tej funkcji, aby uzyskać wartość szesnastkową, ponieważ wartości, które są odkładane przed skokami (JUMP i JUMPI), są podawane w systemie szesnastkowym.

Punkt wejścia (0x00)

Kontrakty są zawsze wykonywane od pierwszego bajtu. Oto początkowa część kodu:

Ten kod robi dwie rzeczy:

1. Zapisuje 0x80 jako 32-bajtową wartość w lokalizacjach pamięci 0x40-0x5F (0x80 jest przechowywane w 0x5F, a 0x40-0x5E to same zera).
2. Odczytuje rozmiar danych wywołania. Zazwyczaj dane wywołania dla kontraktu Ethereum są zgodne z ABI (interfejsem binarnym aplikacji) (opens in a new tab), co wymaga co najmniej czterech bajtów dla selektora funkcji. Jeśli rozmiar danych wywołania jest mniejszy niż cztery, następuje skok do 0x5E.

Procedura obsługi pod adresem 0x5E (dla danych wywołania niezgodnych z ABI)

Ten fragment zaczyna się od JUMPDEST. Programy EVM (wirtualnej maszyny Ethereum) zgłaszają wyjątek, jeśli wykonasz skok do kodu operacji, który nie jest JUMPDEST. Następnie sprawdza CALLDATASIZE i jeśli jest to „prawda” (czyli nie zero), skacze do 0x7C. Dojdziemy do tego poniżej.

Więc kiedy nie ma danych wywołania, odczytujemy wartość Storage[6]. Jeszcze nie wiemy, jaka to wartość, ale możemy poszukać transakcji, które kontrakt otrzymał bez danych wywołania. Transakcje, które po prostu transferują ETH bez żadnych danych wywołania (a zatem bez metody), mają w Etherscan metodę Transfer. W rzeczywistości pierwsza transakcja, jaką otrzymał kontrakt (opens in a new tab), to transfer.

Jeśli spojrzymy na tę transakcję i klikniemy Click to see More, zobaczymy, że dane wywołania, nazywane danymi wejściowymi (input data), są rzeczywiście puste (0x). Zauważ również, że wartość wynosi 1.559 ETH, co będzie miało znaczenie później.

Następnie kliknij zakładkę State i rozwiń kontrakt, który poddajemy inżynierii wstecznej (0x2510...). Możesz zobaczyć, że Storage[6] zmieniło się podczas transakcji, a jeśli zmienisz Hex na Number, zobaczysz, że stało się 1,559,000,000,000,000,000, czyli wartością przetransferowaną w wei (dodałem przecinki dla jasności), odpowiadającą kolejnej wartości kontraktu.

Jeśli spojrzymy na zmiany stanu spowodowane przez inne transakcje Transfer z tego samego okresu (opens in a new tab), zobaczymy, że Storage[6] przez pewien czas śledziło wartość kontraktu. Na razie nazwiemy to Value*. Gwiazdka (*) przypomina nam, że jeszcze nie wiemy, co robi ta zmienna, ale nie może to być tylko śledzenie wartości kontraktu, ponieważ nie ma potrzeby używania pamięci (storage), która jest bardzo droga, gdy można uzyskać saldo konta za pomocą ADDRESS BALANCE. Pierwszy kod operacji odkłada na stos własny adres kontraktu. Drugi odczytuje adres na szczycie stosu i zastępuje go saldem tego adresu.

Będziemy kontynuować śledzenie tego kodu w miejscu docelowym skoku.

NOT jest operacją bitową, więc odwraca wartość każdego bitu w wartości wywołania.

Skaczemy, jeśli Value* jest mniejsze niż 2^256-CALLVALUE-1 lub równe tej wartości. Wygląda to na logikę zapobiegającą przepełnieniu (overflow). I rzeczywiście, widzimy, że po kilku bezsensownych operacjach (na przykład zapis do pamięci zaraz zostanie usunięty) pod przesunięciem 0x01DE kontrakt zostaje wycofany, jeśli wykryte zostanie przepełnienie, co jest normalnym zachowaniem.

Zauważ, że takie przepełnienie jest niezwykle mało prawdopodobne, ponieważ wymagałoby, aby wartość wywołania plus Value* była porównywalna do 2^256 wei, czyli około 10^59 ETH. Całkowita podaż ETH w momencie pisania tego tekstu wynosi mniej niż dwieście milionów (opens in a new tab).

Jeśli dotarliśmy tutaj, pobieramy Value* + CALLVALUE i skaczemy do przesunięcia 0x75.

Jeśli dotrzemy tutaj (co wymaga, aby dane wywołania były puste), dodajemy do Value* wartość wywołania. Jest to spójne z tym, co mówimy o działaniu transakcji Transfer.

Na koniec czyścimy stos (co nie jest konieczne) i sygnalizujemy pomyślne zakończenie transakcji.

Podsumowując, oto schemat blokowy dla początkowego kodu.

Handler pod adresem 0x7C

Celowo nie umieściłem w nagłówku informacji o tym, co robi ten handler. Nie chodzi o to, aby nauczyć Cię, jak działa ten konkretny kontrakt, ale jak odtwarzać kod źródłowy kontraktów (inżynieria wsteczna). Dowiesz się, co on robi, w ten sam sposób co ja, śledząc kod.

Trafiamy tutaj z kilku miejsc:

• Jeśli dane wywołania mają 1, 2 lub 3 bajty (od przesunięcia 0x63)
• Jeśli podpis metody jest nieznany (od przesunięć 0x42 i 0x5D)

To kolejna komórka pamięci (storage), której nie mogłem znaleźć w żadnych transakcjach, więc trudniej jest określić, co oznacza. Poniższy kod to rozjaśni.

Te kody operacji obcinają wartość odczytaną ze Storage[3] do 160 bitów, czyli długości adresu Ethereum.

Ten skok jest zbędny, ponieważ i tak przechodzimy do następnego kodu operacji. Ten kod nie jest tak zoptymalizowany pod kątem zużycia gazu, jak mógłby być.

Na samym początku kodu ustawiliśmy Mem[0x40] na 0x80. Jeśli poszukamy 0x40 później, zobaczymy, że go nie zmieniamy – możemy więc założyć, że wynosi 0x80.

Kopiuje wszystkie dane wywołania do pamięci, zaczynając od 0x80.

Teraz wszystko jest o wiele jaśniejsze. Ten kontrakt może działać jako kontrakt proxy (opens in a new tab), wywołując adres w Storage[3], aby wykonać właściwą pracę. DELEGATE_CALL wywołuje oddzielny kontrakt, ale pozostaje w tej samej pamięci (storage). Oznacza to, że delegowany kontrakt, dla którego jesteśmy proxy, ma dostęp do tej samej przestrzeni pamięci. Parametry wywołania to:

• Gaz: Cały pozostały gaz
• Wywoływany adres: Storage[3]-jako-adres
• Dane wywołania: Bajty CALLDATASIZE zaczynające się od 0x80, czyli tam, gdzie umieściliśmy oryginalne dane wywołania
• Dane zwrotne: Brak (0x00 - 0x00) Dane zwrotne uzyskamy w inny sposób (patrz poniżej)

Tutaj kopiujemy wszystkie dane zwrotne do bufora pamięci zaczynającego się od 0x80.

Zatem po wywołaniu kopiujemy dane zwrotne do bufora 0x80 - 0x80+RETURNDATASIZE, a jeśli wywołanie zakończy się sukcesem, wykonujemy RETURN z dokładnie tym buforem.

Niepowodzenie DELEGATECALL

Jeśli dotrzemy tutaj, do 0xC0, oznacza to, że wywołany przez nas kontrakt został wycofany. Ponieważ jesteśmy tylko kontraktem proxy dla tego kontraktu, chcemy zwrócić te same dane i również wycofać transakcję.

Więc wykonujemy REVERT z tym samym buforem, którego użyliśmy wcześniej dla RETURN: 0x80 - 0x80+RETURNDATASIZE

Wywołania ABI

Jeśli rozmiar danych wywołania wynosi cztery bajty lub więcej, może to być prawidłowe wywołanie ABI.

Etherscan informuje nas, że 1C to nieznany kod operacji, ponieważ został dodany po tym, jak Etherscan napisał tę funkcję (opens in a new tab) i nie została ona zaktualizowana. Aktualna tabela kodów operacji (opens in a new tab) pokazuje nam, że jest to przesunięcie w prawo (shift right).

Podział testów dopasowania podpisu metody na dwie części w ten sposób pozwala zaoszczędzić średnio połowę testów. Kod, który następuje bezpośrednio po tym, oraz kod w 0x43 podążają za tym samym wzorcem: DUP1 pierwsze 32 bity danych wywołania, PUSH4 (((method signature>, wykonuje EQ, aby sprawdzić równość, a następnie JUMPI, jeśli podpis metody się zgadza. Oto podpisy metod, ich adresy oraz, jeśli jest znana, odpowiadająca im definicja metody (opens in a new tab):

Jeśli nie zostanie znalezione żadne dopasowanie, kod skacze do obsługi proxy pod adresem 0x7C w nadziei, że kontrakt, dla którego jesteśmy proxy, ma dopasowanie.

splitter()

Pierwszą rzeczą, którą robi ta funkcja, jest sprawdzenie, czy wywołanie nie przesłało żadnego ETH. Ta funkcja nie jest payable (opens in a new tab). Jeśli ktoś wysłał nam ETH, musi to być błąd, a my chcemy wykonać REVERT, aby uniknąć zablokowania tego ETH bez możliwości jego odzyskania.

A 0x80 zawiera teraz adres proxy

Kod E4

Widzimy te linie po raz pierwszy, ale są one współdzielone z innymi metodami (patrz poniżej). Nazwiemy więc wartość na stosie X i po prostu zapamiętamy, że w splitter() wartość tego X wynosi 0xA0.

Zatem ten kod otrzymuje wskaźnik pamięci na stosie (X) i powoduje, że kontrakt wykonuje RETURN z buforem wynoszącym 0x80 - X.

W przypadku splitter() zwraca to adres, dla którego jesteśmy proxy. RETURN zwraca bufor w zakresie 0x80-0x9F, czyli tam, gdzie zapisaliśmy te dane (offset 0x130 powyżej).

currentWindow()

Kod w offsetach 0x158-0x163 jest identyczny z tym, co widzieliśmy w 0x103-0x10E w splitter() (poza miejscem docelowym JUMPI), więc wiemy, że currentWindow() również nie jest payable.

Kod DA

Ten kod jest również współdzielony z innymi metodami. Nazwiemy więc wartość na stosie Y i po prostu zapamiętamy, że w currentWindow() wartością tego Y jest Storage[1].

Zapisz Y w 0x80-0x9F.

A reszta została już wyjaśniona powyżej. Zatem skoki do 0xDA zapisują szczyt stosu (Y) w 0x80-0x9F i zwracają tę wartość. W przypadku currentWindow() zwraca Storage[1].

merkleRoot()

Kod w offsetach 0xED-0xF8 jest identyczny z tym, co widzieliśmy w 0x103-0x10E w splitter() (poza miejscem docelowym JUMPI), więc wiemy, że merkleRoot() również nie jest payable.

Co dzieje się po skoku, już ustaliliśmy. Zatem merkleRoot() zwraca Storage[0].

0x81e580d3

Kod pod offsetami 0x138-0x143 jest identyczny z tym, co widzieliśmy pod 0x103-0x10E w splitter() (poza miejscem docelowym JUMPI), więc wiemy, że ta funkcja również nie jest payable.

Wygląda na to, że ta funkcja przyjmuje co najmniej 32 bajty (jedno słowo) danych wywołania.

Jeśli nie otrzyma danych wywołania, transakcja zostaje wycofana bez żadnych zwracanych danych.

Zobaczmy, co się stanie, jeśli funkcja otrzyma potrzebne dane wywołania.

calldataload(4) to pierwsze słowo danych wywołania po sygnaturze metody

Jeśli pierwsze słowo nie jest mniejsze niż Storage[4], funkcja kończy się niepowodzeniem. Zostaje wycofana bez żadnej zwracanej wartości:

Jeśli calldataload(4) jest mniejsze niż Storage[4], otrzymujemy ten kod:

A lokacje pamięci 0x00-0x1F zawierają teraz dane 0x04 (0x00-0x1E to same zera, 0x1F to cztery)

Zatem w pamięci (storage) znajduje się tabela wyszukiwania, która zaczyna się od SHA3 z 0x000...0004 i ma wpis dla każdej prawidłowej wartości danych wywołania (wartość poniżej Storage[4]).

Wiemy już, co robi kod pod offsetem 0xDA, zwraca on wartość ze szczytu stosu do wywołującego. Zatem ta funkcja zwraca wywołującemu wartość z tabeli wyszukiwania.

0x1f135823

Kod w offsetach 0xC4-0xCF jest identyczny z tym, co widzieliśmy w 0x103-0x10E w splitter() (poza miejscem docelowym JUMPI), więc wiemy, że ta funkcja również nie jest payable.

Wiemy już, co robi kod pod offsetem 0xDA, zwraca on wartość ze szczytu stosu do wywołującego. Więc ta funkcja zwraca Value*.

Podsumowanie metod

Czy na tym etapie czujesz, że rozumiesz ten kontrakt? Ja nie. Jak dotąd mamy następujące metody:

Wiemy jednak, że wszelka inna funkcjonalność jest dostarczana przez kontrakt w Storage[3]. Może gdybyśmy wiedzieli, czym jest ten kontrakt, dałoby nam to jakąś wskazówkę. Na szczęście to jest blockchain i wszystko jest wiadome, przynajmniej w teorii. Nie widzieliśmy żadnych metod, które ustawiałyby Storage[3], więc musiało to zostać ustawione przez konstruktor.

Konstruktor

Kiedy przyglądamy się kontraktowi (opens in a new tab), możemy również zobaczyć transakcję, która go utworzyła.

Jeśli klikniemy tę transakcję, a następnie zakładkę Stan, możemy zobaczyć początkowe wartości parametrów. W szczególności możemy zauważyć, że Storage[3] zawiera 0x2f81e57ff4f4d83b40a9f719fd892d8e806e0761 (opens in a new tab). Ten kontrakt musi zawierać brakującą funkcjonalność. Możemy go zrozumieć, używając tych samych narzędzi, których użyliśmy do badanego przez nas kontraktu.

Kontrakt proxy

Używając tych samych technik, których użyliśmy dla oryginalnego kontraktu powyżej, możemy zauważyć, że kontrakt zostaje wycofany, jeśli:

• Do wywołania dołączone jest jakiekolwiek ETH (0x05-0x0F)
• Rozmiar danych wywołania jest mniejszy niż cztery (0x10-0x19 i 0xBE-0xC2)

Oraz że obsługiwane przez niego metody to:

Możemy zignorować cztery ostatnie metody, ponieważ nigdy do nich nie dotrzemy. Ich podpisy są takie, że nasz oryginalny kontrakt sam się nimi zajmuje (możesz kliknąć podpisy, aby zobaczyć szczegóły powyżej), więc muszą to być metody, które zostały nadpisane (opens in a new tab).

Jedną z pozostałych metod jest claim(<params>), a kolejną isClaimed(<params>), więc wygląda to na kontrakt airdropu. Zamiast przechodzić przez resztę kod operacji po kodzie operacji, możemy wypróbować dekompilator (opens in a new tab), który generuje użyteczne wyniki dla trzech funkcji z tego kontraktu. Inżynieria wsteczna pozostałych pozostaje ćwiczeniem dla czytelnika.

scaleAmountByPercentage

Oto co dekompilator zwraca dla tej funkcji:

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)

Pierwsze require sprawdza, czy dane wywołania mają, oprócz czterech bajtów podpisu funkcji, co najmniej 64 bajty, co wystarcza na dwa parametry. Jeśli nie, to oczywiście coś jest nie tak.

Instrukcja if wydaje się sprawdzać, czy _param1 nie jest zerem, a _param1 * _param2 nie jest ujemne. Prawdopodobnie ma to na celu zapobieganie przypadkom przepełnienia (wrap around).

Na koniec funkcja zwraca przeskalowaną wartość.

claim

Kod generowany przez dekompilator jest złożony i nie cały jest dla nas istotny. Pominę jego część, aby skupić się na wierszach, które moim zdaniem dostarczają przydatnych informacji.

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'

Widzimy tutaj dwie ważne rzeczy:

• _param2, chociaż jest zadeklarowane jako uint256, w rzeczywistości jest adresem
• _param1 to okno, z którego odbierane są środki, które musi być currentWindow lub wcześniejsze.

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

Więc teraz wiemy, że Storage[5] to tablica okien i adresów, oraz informacja, czy dany adres odebrał nagrodę dla tego okna.

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

Wiemy, że unknown2eb4a7ab to w rzeczywistości funkcja merkleRoot(), więc ten kod wygląda, jakby weryfikował dowód Merkle'a (opens in a new tab). Oznacza to, że _param4 jest dowodem Merkle'a.

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

W ten sposób kontrakt transferuje własne ETH na inny adres (kontraktu lub posiadany zewnętrznie). Wywołuje go z wartością, która jest kwotą do przetransferowania. Wygląda więc na to, że jest to airdrop 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

Dwie ostatnie linie mówią nam, że Storage[2] to również kontrakt, który wywołujemy. Jeśli spojrzymy na transakcję konstruktora (opens in a new tab), zobaczymy, że ten kontrakt to 0xc02aaa39b223fe8d0a0e5c4f27ead9083c756cc2 (opens in a new tab), kontrakt opakowanego etheru (WETH), którego kod źródłowy został przesłany do Etherscan (opens in a new tab).

Wygląda więc na to, że kontrakt próbuje wysłać ETH do _param2. Jeśli mu się to uda, to świetnie. Jeśli nie, próbuje wysłać WETH (opens in a new tab). Jeśli _param2 jest kontem posiadanym zewnętrznie (EOA), to zawsze może otrzymać ETH, ale kontrakty mogą odmówić przyjęcia ETH. Jednak WETH to ERC-20 i kontrakty nie mogą odmówić jego przyjęcia.

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

Na końcu funkcji widzimy, że generowany jest wpis logu. Spójrz na wygenerowane wpisy logów (opens in a new tab) i przefiltruj po temacie, który zaczyna się od 0xdbd5.... Jeśli klikniemy jedną z transakcji, która wygenerowała taki wpis (opens in a new tab), zobaczymy, że rzeczywiście wygląda to na odebranie środków (claim) - konto wysłało wiadomość do kontraktu, który poddajemy inżynierii wstecznej, a w zamian otrzymało ETH.

1e7df9d3

Ta funkcja jest bardzo podobna do claim powyżej. Również sprawdza dowód Merkle'a, próbuje przetransferować ETH do pierwszego i generuje ten sam typ wpisu logu.

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)

Główna różnica polega na tym, że nie ma pierwszego parametru, czyli okna do wypłaty. Zamiast tego występuje pętla po wszystkich oknach, z których można odebrać środki.

  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

Wygląda to więc na wariant claim, który odbiera środki ze wszystkich okien.

Podsumowanie

Teraz powinieneś już wiedzieć, jak zrozumieć kontrakty, których kod źródłowy nie jest dostępny, używając kodów operacji lub (gdy to działa) dekompilatora. Jak widać po długości tego artykułu, inżynieria wsteczna kontraktu nie jest trywialna, ale w systemie, w którym bezpieczeństwo jest kluczowe, ważną umiejętnością jest możliwość weryfikacji, czy kontrakty działają zgodnie z obietnicą.

Więcej moich prac znajdziesz tutaj (opens in a new tab).